What is WindowsAppSDK purpose?

[orion160]

Windows App SDK is a set of libraries, frameworks, components, and tools that you can use in your apps to access powerful Windows platform functionality from all kinds of apps on many versions of Windows. Windows App SDK combines the powers of Win32 native applications alongside modern API usage techniques, so your apps light up everywhere your users are. from

If I would want to create a Console Application or a Library that exposes windowing features and other capabilities is this SDK planned for this.

I want to consume C++ Win32(Desktop) compatible WinRT APIs, and also abstract platform functionality.

It is possible to use WindowsAppSDK without XAML?

And use a programmatical interface like

int main()
{
    auto w = Window("SOME_TITLE",  OTHER_CONFIG)
}

to be a replacement of WIN32 API, and use this api for window creation and handling, and consume APIs like XAudio2, GameInput

My usecase is to integrate a Graphics engine to Windowing.

DirectX Example
As noted in this example, WINUI 3 windowing is not an alternative when I need HWND Interoperability with DirectX12/Vulkan

[DarranRowe]

I think one of the biggest issues for part of this question is not understanding what is available through the Windows SDK and the Windows WinRT API available through the UWP namespaces.

There tends to be two major problems getting in the way of using anything in the Windows.* namespaces. The first is the runtime classes that represent features available only in an UWP application and the second is features that require a package identity. The second problem is what MSIX/App Packages are there for. But this means that there are a lot of runtime classes usable from desktop applications, and more are actually being made available. Information on what is available is documented.

One area that can be a little confusing is runtime classes available in the Windows App SDK may only be there to support the Windows App SDK Xaml classes, and this means they are not intended for use in non Xaml applications. There are two examples of this. The first is the Microsoft.UI.Composition namespace, this is missing the CompositionTarget runtime class. A desktop application that isn't Xaml based which wants to take advantage of composition would actually need to use Windows.UI.Composition. This has the CompositionTarget runtime class, and more importantly, the Desktop sub namespace has the DesktopWindowTarget that allows you to attach it to a HWND. The second example is Microsoft.UI.Input. The PointerPoint runtime class doesn't have any way to get the current pointer. Windows.UI.Input on the other hand has a static member which allows you to get the PointerPoint.

Anyway, the Windows App SDK is available in application types other than the Xaml project types. What you normally need to do is just add a couple of NuGet references:

For a C++ these are recommended. It is potentially possible to get away with less than this, but that would mean doing some manual steps, and they can be annoying. For library projects, it is possible that the usual C++ issue is at play, that would be C++ classes on the ABI boundary. You can get the interface out of the C++/WinRT class, but you should be prepared. But when you are working with projects like this, a couple of things don't work automatically. It is mostly centred around the generation of the resources.pri file or the generation of the binary xaml files though, so the Windows App SDK is very usable.

Finally, for using statements like:

auto w = Window();

Why aren't you doing that already? It is quite easy to use a template class using crtp to have a class wrapper around the Windows API. One basic example that I know of was by Kenny Kerr all the way back in 2014, when he was writing about the DirectComposition interfaces. The article took advantage of the fact that CreateWindowEx allowed you to pass in any value as the last parameter of this function. If you used this to pass in the class' this pointer, then you could make the connection between the window and the class. It then used WM_NCCREATE to make the connection between the class and the window. But if you want to know if it is possible to bypass this work entirely? The AppWindow runtime class isn't complete enough to do this without sub classing the window procedure, it is also final, so you can't derive from it to modify the behaviour. The only other window class available is the Xaml Window class, but this is meant to be the Xaml host. You can get the HWND to this window, but since it is meant to be used with Xaml, the composition engine will just draw over everything else. While WinUI 3 does allows for graphics interoperability via DXGI, in particular the DXGI swap chain, if the engine is written to only want HWNDs then this makes WinUI 3 unusable.

Finally, one question. When you say you "need" HWND interoperability, is this due to some game engine you are using will only target a HWND or is this down to you not knowing about the composition engine?