Is Application::OnLaunched call asynchronously?

[amtopel]

I've been trying to understand the timing of Application::OnLaunched. I don't understand if it's called asynchronously by default. The actual code that starts the application and message loop is something like this:

    winrt::Microsoft::UI::Xaml::Application::Start(
        [](auto&&)
	{
	    winrt::make<winrt::MyProject::implementation::App>();
	}
    );

The lambda suggests that something asynchronous is happening, but I'm not sure.

What I'd like to know specifically is this: I've converted a WinUI project into an out-of-process COM server, with the help of ATL. ATL registers the class factories in the pre-message-loop, and then I use the above-quoted code as the message loop. Everything by default is single/apartment-threaded. I'd like to know whether, when a client first instantiates one of my server components, triggering COM to load up my server, whether there's any logical guarantee that Application::OnLaunched will have been called when the COM component is instantiated. Or stated in a different way: is it all conceivable that the out-of-process client has instantiated one of my server's classes, before Application::OnLaunched has been reached? I want to make sure all WinUI resources are available when the COM classes get instantiated and start doing things.

It seems like the message loop will necessarily have started, because otherwise the client wouldn't be able to call into the class factory code to instantiate the class.

And anecdotally, it seems that Application::OnLaunched is always reached first, which is good. But I don't know if there's a race condition lurking in there somewhere.

Thanks for any help or thoughts.

[DarranRowe]

From what I remember, Microsoft.UI.Xaml.Application.Start works in a way that can be described as follows. It isn't exact, but it is good enough for describing this.

1. Create a dispatcher queue using Microsoft.UI.Dispatching.DispatcherQueueController.CreateOnCurrentThread.
2. Initialise the Xaml runtime using Microsoft.UI.Xaml.Hosting.WindowsXamlManager.InitializeForCurrentThread.
3. It then calls the callback provided as a parameter for Start.
4. Runs a message loop on the thread, it should be equivalent of Microsoft.UI.Dispatching.DispatcherQueue.RunEventLoop.

It is not asynchronous at all. The lambda is just a convenient way to provide the start callback without having to write an extra function.

void start_callback(const winrt::Microsoft::UI::Xaml::ApplicationInitializationCallbackParams &)
{
	winrt::make<winrt::MyNamespace::implementation::App>();
}

int APIENTRY wWinMain(_In_ HINSTANCE, _In_opt_ HINSTANCE, _In_ LPWSTR, _In_ int)
{
	winrt::Microsoft::UI::Xaml::Application::Start(start_callback);

	return 0;
}

The lambda is essentially equivalent to this.

[amtopel]

Thanks a lot. So where does OnLaunched fit in? Is it also called synchronously, before the message loop starts?

Or maybe I should just ask when the WinUI resources can first be used.

[DarranRowe]

I will not go too deeply into the underlying implementation, since it is about WinRT components and that can be confusing and not fun.

Anyway, it is called synchronously after the callback has completed but before the message loop starts. OnLaunched should also be the first user accessible place that WinUI resources can be used.
Because of the whole WinRT component thing, the App object is actually constructed inverted, so the App object first, then Microsoft.UI.Xaml.Application. No resources are available until after Application has been created, so the App constructor is just unable to use WinUI 3 resources.

[amtopel]

Thanks a lot for the info. So I infer that, since the message loop starts only after OnLaunched has been called, then server objects can only be instantiated afterward, too. And so server objects, when they're instantiated, can rely on all WinUI resources being available.

[DarranRowe]

So I infer that, since the message loop starts only after OnLaunched has been called, then server objects can only be instantiated afterward, too.

No, remember that the instance of Window is instantiated in OnLaunched. Window is a WinRT component too. In fact, in a more raw Xaml Islands situation, where you are not using the Xaml compiler to generate the code. You can load XamlControlResources after Application has instantiated but before the message loop is actually running. Try loading XamlControlResources in OnLaunched before you create the instance of your window. Interestingly, if you use a subset of the controls and don't load the resources, you don't even need an application instance for Xaml Islands, the only important thing is that a DispatcherQueue exists for the thread.

STA objects in COM are the same. When you have the direct interface pointer, you can do direct calls on it without the message loop running. It is only really when UI components and marshalling are involved that the loop is needed.

[amtopel]

Yes, just to clarify, what I meant was that any server objects that are requested by clients from the outside will be constructed only after the message loop starts. For example, as noted in these docs:

A COM server that registers multiple classes typically calls CoRegisterClassObject with REGCLS_LOCAL_SERVER for each CLSID it supports. After it has done this for all classes, the server enters its message loop. For a single-threaded COM server, all activation requests are blocked until the server enters the message loop.

My main concern was that if an outside client requests creation of one of the exe's objects, and COM starts up my exe, that whatever object is created in my exe server is assured that OnLaunched has already occurred, and all of the WinUI resources are available, when it's constructed and starts doing things.

[DarranRowe]

Well, for STA threads, marshaling is done using the windows message queue. So a server is unable to service requests when there is no message loop running on the thread.
Otherwise you can always register the server using the suspended flag and then call CoResumeClassObjects when the process is ready to start serving for that apartment.