Comment by contextfree | Hacker News Reader

Comment by contextfree | Hacker News Reader

Parent Full thread

WinRT, as in the API/ABI shape, at this point really isn't tied to any aspect of the UWP app model (other than that existing UWP-related APIs tend to be newer and more likely to use it). Third-party WinRT component activation used to depend on app packaging but that dependency was removed last year: https://blogs.windows.com/windowsdeveloper/2019/04/30/enhanc...

In general what used to be various facets of the "monolithic" Win32 vs. UWP divide have been refactored to allow a la carte usage, so not only can you activate your WinRT components without a packaged app, but you can also register your app as "packaged" for runtime purposes without having to install in that format ( https://blogs.windows.com/windowsdeveloper/2019/10/29/identi... ), can install in the packaged format without having to use the sandbox features ( https://docs.microsoft.com/en-us/windows/msix/overview ) can distribute sandboxed apps outside the store ( https://docs.microsoft.com/en-us/windows/msix/app-installer/... ), etc.

The only remaining aspect I'm aware of where there's still a binary decision and coupling is in the windowing model and shell integration; a Win32 process's top-level windows can only be HWNDs and a UWP process's top-level windows can only be CoreWindows. Win32 HWNDs can host both Win32 and UWP UI, but UWP CoreWindows can only host UWP UI; on the other hand, only UWP CoreWindows can make use of UWP shell integration features like fullscreen and picture-in-picture. It would make sense to somehow decouple this facet as well but I'm not aware of any plans to do so.

Thanks this is informative. I think my confusion comes from that many things are introduced as walled-off vertical concepts but later backported at least partially. Also there is no lack of terminology confusion when things can be an API, an app-model or both.

I’m a full time windows desktop dev since 15 years now. And I still find these UI and app model frameworks extremely confusing (which is why I haven’t gone near one after WPF).

Yeah, it's definitely confusing for anyone who hasn't been following all the twists and turns (i.e., the vast majority of developers)

WinUI 3 is planned to have support for "Win32 app model" apps. I'm not sure if this is strictly "CoreWindow" or another class with different features, but you'll be able to write "native" UWP-Style apps in C++ and deploy them as an unrestricted .exe. They're going to show a demo at Build 2020, I heard.

My understanding is the WinUI 3 Win32 model is still going to be basically doing what you can already do with XAML Islands, just packaged more nicely with wrapper classes and Visual Studio templates and so on, so by itself it doesn't change the underlying HWND vs. CoreWindow situation (just wraps it). There are already Win32 apps, like Windows Terminal, that implement a "UWP" UI by doing their entire UI in one big XAML Island.

Rust/WinRT has really triggered my interest. For someone who hasn't been following Windows development for more than almost two decades, what's a good read to understand the different models of app creation and distribution?

Unfortunately it's a bit of a mess right now for reasons alkonaut mentioned in his post upthread. The official Microsoft doc page -> https://docs.microsoft.com/en-us/windows/apps/desktop/ is maybe an ok starting point for someone with a vague memory of Windows desktop development who's curious about what's new, but I could see someone getting lost in a maze of acronyms and links, especially if you're trying to use it with a newly semi-supported language like Rust

> on the other hand, only UWP CoreWindows can make use of UWP shell integration features like fullscreen and picture-in-picture

What are the practical advantages of fullscreening / PIP'ing thanks to UWP as compared to what you can achieve without?

The Shell managed PIP is entirely unique to UWP. In Win32 you can fake it with an always-on-top window, but you don't get the PIP window management gestures out of the box and some other things. From what I recall, where this particularly matters is touch gestures and HoloLens and Windows MR support where Win32 always-on-top is very different from Shell-managed PIP in three dimensions. (Also, Xbox doesn't support Win32 always-on-top.)

I think fullscreening also has some gestures the Shell manages, but I'm not as familiar with them. Similar too that the Shell does very different things in 3D.

There's also the Dual Screen support in CoreWindow that Microsoft has been talking up for Windows "10X".

Reply on news.ycombinator.com