Support creating CoreWindow desktop apps and enable the CoreWindow related apis in Windows App SDK

[EP012014]

Because desktop apps in Windows App SDK only supports the legacy HWND window model instead of the modern CoreWindow model, many features related to CoreWindow(e.g SplashScreen before window content actually loaded, Win+Shift+Enter for full screen) are missing.
So is it possible to bring back CoreWindow in WinUI3 desktop apps?

[castorix]

You don't need CoreWindow to display a SplashScreen or to make a window Full Screen...

[lukeblevins]

Like in any Win32 Desktop app, you can create and display any window anywhere (I tested with the standard CreateWindowEx API)

Since CoreApplication splash screens are displayed by the OS immediately after the user invokes an app from the shell, there is no delay. The approach you're describing still has a small period where users aren't left with feedback.

[seven-mile]

@duke7553 Then it's a performance issue, right?

[lukeblevins]

@seven-mile No, not necessarily. Just an issue of whether the splash screen experience is managed by the shell (which is already loaded in memory) or the invoked application (which is not).

I'll concede that if the WinAppSDK team reduced startup times, the difference here could become negligible.

[dimohy]

I agree with EPO12014.

Currently there is no way to show SplashScreen in WinUI 3.
Castorix's comment is that the SplashScreen can still be displayed in many different ways, but as EPO12014 pointed out, this is not an immediate SplashScreen display as it can only be done after the Window and related preparations are all complete.

As a way to display SplashScreen in WinUI 3 I'm making, I had to launch an app that displays a separate SplashScreen screen made with .NET Framework from the program entry point.

[AzAgarampur]

If anything Window from WinUI 3 can be changed to have a SplashScreen property that is visible while the XAML parser and UI is built, just like UWP apps.

Showing the splashscreen itself is just a simple call to CreateWindowEx and then displaying the icon+color, which takes basically 0 time to do.

[Gavin-Williams]

It's not just about splash screens. What if we don't want to use Xaml? If we don't want the Xaml engine running at all. For example if we are rendering our own custom UI? CoreWindow is suitable for that scenario and it's a glaring omission from Windows App SDK. And seriously ... you still haven't provided a CoreWindow? Why are you so slow at providing 'core' functionality? This has been discussed enough by now, can you please bring the UWP technologies forward and be done with it.

[AzAgarampur]

If you're not gonna use XAML then don't use WinUI 3. Create your own UI with win32 CreateWindowEx and use OpenGL or Direct3D or something else to render your UI.

[Gavin-Williams]

@AzAgarampur That is exactly what CoreWindow is for. Which AFAIK, Windows App SDK lacks, and which UWP did have. CreateWindowEx is a legacy API (it looks pretty nasty compared to CoreWindow), we really should get modern code to do these things. And isn't CreateWindowEX a C API? While CoreWindows is both C# and C++. UWP really got it right by having Windows code common between both languages (C++ and C#).

Are you familiar with CoreWindow? CoreWindow is typically used with DirectX - that's how I work with it. So half of your suggestion is good, but I also need something like CoreWindow.

There is some suggestion that CoreWindow is replaced with WindowsAppSDK AppWindow

This topic contains guidance related to window management, including migrating from UWP's [ApplicationView]/[CoreWindow] or [AppWindow] to the Window App SDK [Microsoft.UI.Windowing.AppWindow]

But it doesn't look right to me, and from what I've seen you need to construct a XamlWindow, then get the AppWindow from that. Doesn't that miss the point? Anyway, I haven't yet worked out how to replace CoreWindow.

And I'm absolutely OK with not using WinUI, as long as Windows App SDK provides a solution. (This is a Windows App SDK suggestion). Unfortunately, it seems like we don't have a proper solution yet.

[AzAgarampur]

If you want modern WinRT-object based system then I do think that maybe in a future update, AppWindow can become the native foundation that WinUI 3's Window class is built upon, and then AppWindow isn't linked to XAML and stuff. Then we can simply use AppWindow the same way CoreWindow is used today.

While CoreWindows is both C# and C++. UWP really got it right by having Windows code common between both languages (C++ and C#).

I mean technically CoreWindow is a WinRT (basically COM) interface, which is why any language can call it. I wouldn't call CreateWindow legacy, it's just the lower-level (the real) implementation that creates windows, as every windowing framework is built on top of that. Same thing goes for the title of this discussion, HWND isn't legacy, its just the lower-level method to accessing windows.

[rkarman]

CoreWindow will not be brought back, it is very specific to the UWP appmodel and does not fit with the Win32 model of WinAppSDK.

That said, we do provide the AppWindow object that is intended to make a lot of Win32 windowing tasks easier, and this is also where we will be adding net new functionality and unlock new scenarios for the windowing space.

There are some limitations and caveats to the AppWindow object/API surface right now though:

• You cannot attach XAML content to a separately created AppWindow. You have to create your XAML window and get the AppWindow from it (see the AppWindow overview article for how to get the AppWindow from a XAML window).

• If you want to attach other types of content (for frameworks/content types that has "Create for HWND" APIs today), you can start with an AppWindow, get the HWND for it, and provide that HWND to these methods (see the windowing samples for how to get the HWND from an AppWindow). Not that since we currently don't provide a way to share the WNDPROC of an AppWindow, you have to either subclass the AppWindow's HWND or create a child HWND inside it, so it might be a little awkward to work with right now.

We're working on closing these (and other) limitations, but we're not yet there for 1.0/1.1.

As for the Splash Screen problem in particular - this is something we've been looking at for a while to see how we can provide a better mapping of this functionality for those coming from UWP and/or who wants that type of experience for their app. Please add your voice to this discussion thread to help inform further design in the splash screen space.

[EP012014]

So what's the reason that you can't port CoreWindow to desktop app model?

[Gavin-Williams]

CoreWindow isn't a particular piece of code. It's an idea. The idea that we can have modern API's to access core window functionality ant that the window exists independently of Xaml. I hope AppWindow can deliver that. So far, it hasn't.

[LB--]

I gave this a quick spin with a little Vulkan graphics test app I have, all I had to do was create an AppWindow like in that sample and hand over its HWND to the Vulkan graphics API, and I was able to render to it. I didn't have to add or use anything related to Xaml.

[Gavin-Williams]

AppWindow is a WinUI class. How do you know the UI engine isn't running?

[driver1998]

I guess the other way to talk about this is: can I manually request ApplicationFrameHost to create a window for my Win32 app?
CoreWindow represents what is inside that host window (CoreWindow is actually a child window of it), but things like the UWP-style splash screens, system-wide fullscreen and that special titlebar all come from ApplicationFrameHost.

[driver1998]

Also you can create a CoreWindow yourself if you know where to look

[DrusTheAxe]

That's because having a CoreWindow is secondary to UWP-style splash screens and other things. In the splash screen case first and foremost it's a matter of Windows' activation code decided to do the splash screen work. LAcking a CoreWindow isn't the primary reason this doesn't happen. You'd need to revise (or provide supplemental alternatives) to that activation flow and other codepaths (often in Windows itself). And then having a CoreWindow may or may not be relevant.

It would likely be more fruitful if, for a specific feature, you posted an Issue for a WinAppSDK enhancement request to provide the net functionality via WinAppSDK. So e.g. a UWP-style splash screen like experience may be possible via new WinAppSDK code/APIs, though whether it involves any, some or none of the mechanisms used by UWP apps depends on the features and designs.

No promises everything can (or should) be provided, but nothing ventured nothing gained.