One Windows with an unified app model

[jaigak]

Proposal: One Windows, not multiple

Today there's a lot of clear difference that distinguish app models, UI frameworks and OS editions. I'm proposing this to unify the Windows platform. There should be only one Windows and apps built for Windows should be equal and should be able to access the features. API sets should be unified (not just ones for low IL apps but APIs for other apps eg: GDI and should be available on devices even if they won't or can't be used by new UWP or Win32 apps so that existing apps will become universal easily.

Summary

Let Win32 desktop apps become universal. They can be packaged or not but should be installable and runnable on all Windows 10 devices. This will open doors to millions of existing Win32 desktop applications. Most APIs should be available on all devices, unless if they're really legacy, even if it doesn't make sense for a particular device similar to how most UWP APIs works. Those APIs don't necessarily need to be for UWP but for Win32 apps running on non-desktop platforms using those APIs, they should just work. Unless specified, everything should work everywhere out of the box eg: all new Reunion APIs should be for all devices unless it clearly says it's for desktop only or it's for Xbox only.

Rationale

• Unify the Windows platforms so users and app developers can think of Windows as one platform
• Provide Reunion functionality for everyone

Scope

Capability	Priority
This proposal will allow end-users to install and developers to deploy Win32 desktop apps (packaged or unpackaged) on all Windows devices	Must
This proposal will allow end-users to install UWP and Win32 packaged apps on all SKUs and devices including Windows PE	Must
This proposal will bring all APIs present on desktop to other SKUs and vice versa unless it's really meant for a specific device category	Must
This proposal will allow developers to build Windows Runtime components that can be referenced from both UWP and Win32 projects inside Visual Studio without manifest/project file tweak	Must
This proposal will allow developers to detect the supported features and security context and work accordingly	Should

[jaigak]

It may seem like this is what Reunion is for but Reunion hasn't yet mentioned Win32 being universal which is really needed. All new Reunion APIs should be available on all devices unless it's specified not the other way around which says these APIs are universal.

[jaigak]

Microsoft Edge is able to run on Xbox even though it's not a CoreApplication based low IL app. This functionality should be available for third-party app so Edge doesn't have an unfair advantage. Maybe not unpackaged apps but packaged desktop bridge apps should be definitely able to run on other devices specifically if they are Store apps. Users shouldn't worry whether an app will run on a non-Desktop device or not. Any Store app should run on any Windows device as long as it has been compiled for the specific architecture and meets version requirements. This would need shell modifications as I assume other device shells were created with CoreWindow in mind but anyway. Also making APIs universal here doesn't mean bring them to UWP apps so UWP apps will still not be able to access banned APIs but they will be available on devices for desktop apps.

[jaigak]

UWP was built on the Windows Runtime app model introduced in Windows 8 which wasn't popular and still isn't popular compared to Win32 although Windows 8 was a great OS and Windows 10 is also great. What Windows really needs now is a Universal Windows Desktop platform. Many apps including internal Microsoft ones have become Win32 now and they won't run well on other devices due to lack and differences in APIs, and the shell itself which assumes that all apps are UWP. Instead of this being a special internal capability, let all Win32 apps become universal easily without any dependency on CoreApplication. It may or may not need code changes however all new stuff should be universal unless it doesn't make sense to be universal. There are many legacy Xbox only APIs which may not need to become universal with Reunion for example because they won't be used by new, modern apps unless users really request them however most stuff that everyone uses should work everywhere. It may sound like a security risk but if you make those other device SKUs like Windows 10S, that chance would be reduced however I don't think it makes sense to lock down certain SKUs like Xbox. However, on such SKUs, non Store apps are already allowed so anyway. Also, it should be simplified for developers. You don't write a UWP or a Win32 app, you write a Windows app that would work anywhere unless you manually disable that option since you want to use Xbox specific or desktop specific stuff for example. Windows Runtime has a rich version/edition adaptive code system that can be used using Windows.Foundation.Metadata.ApiInformation class. It could also be updated to check whether a particular non WinRT API exists on the system however I'm not sure how it would work since flat C APIs have no metadata but it could be possible. Also in WinRT components, all Win32 APIs even banned ones for UWP should be accessible out of the box but not in an app project because you clearly know it's a UWP app but in a component or DLL, you don't know who is going to use it and since it could be also used by a desktop app but if the API is banned in UWP apps, there could be a way to check whether it's supported under AppContainer or not or catch exceptions if it throws (well at the ABI layer mostly everything returns an HResult or a Boolean in case of a classic C style API that's not exposed through the COM or WinRT ABI) if the app happens to be a UWP app. (Currently there's no reliable way to clearly distinguish a UWP app from a desktop app and a UWP app may not even use a CoreApplication instance and have a CoreWindow because now UWP console app exists.)

[mdtauk]

GDI needs to die.

It has no place on Hololens or Xbox.

[lukeblevins]

Opinion: Let's not backport the worst of desktop to HoloLens and Xbox

In my opinion, it doesn't seem right to have unpackaged apps that have a completely unmanaged lifecycle and unoptimized UI paradigm on systems like HoloLens and Xbox. Those platforms don't suffer from the compatibility guarantee of Windows 10 desktop. Rather than bring pure Win32 everywhere, let's build off of the improvements the Windows platform has seen.

Packaging with MSIX:
I think Project Reunion was the perfect approach for this. Sure, it seemingly goes a bit too far with the promises for unpackaged apps, but it would be a win if developers adopt just some modern platform technology. MSIX was a great start, but developers want to see that app package format improved upon. We know Microsoft is working with these developers already.

General API surface:
Rather than bring fundamentally-unnatural Win32 APIs everywhere there needs to be more momentum around adding WinRT abstractions of those APIs to Project Reunion. Maybe at some point, Microsoft will accept a broad array of contributions from the community on this, but it seems like platform polyfill work is often necessary.

User Experience:
Microsoft must make pragmatic improvements to GDI like they did prior to Windows 8. Users expect apps that look coherent, while developer expectations must be managed in a way that incentivizes WinUI use where it makes sense. Why should developers of a desktop app that will never be designed for non-traditional scenarios have to use WinUI when the existing framework suits them well?

Another equally ridiculous notion is that GDI should be supported on Xbox and HoloLens. I believe that platform XAML (and WinUI over the long term) is the best UI stack for those apps.

[mdtauk]

Desktop Windows can keep it's legacy compatibility and over time sanitise and componentise it to keep the modern core of Windows as lean as possible.

Newer form factors and devices wont have the expectation of supporting legacy stuff, so in time, business will know what SKU it needs to maintain support, and retail consumer markets can embrace the new.

WinUI for legacy code bases, will be the ideal way to continue existing in consumer spaces, and for device compatibility you can move code over to use Reunion and WinRT APIs

[orcmid]

WinUI for legacy code bases, will be the ideal way to continue existing in consumer spaces, and for device compatibility you can move code over to use Reunion and WinRT APIs

As an observer, I am torn between "one ring to rule them all" which I suspect is doomed and the problem of just one-more Windows platform concept, which tends to be likely, along with a trend to complexification. I suspect that Reunion cannot please everyone, and an effort to do so will have an incoherent result.

Is there a place to find some governing architectural principles for this effort? Even knowing the 5 R's would be helpful. Something about the lifecycle of Reunion and its evolution over time would be valuable also..

Color me Johny-come-lately.

PS: Architural layer block diagrams do not address these concerns. It situates Reunion without saying what it is and what it unifies.

[riverar]

Some questions:

This proposal will allow end-users to install UWP and Win32 packaged apps on all SKUs and devices including Windows PE | Must

Microsoft restricts Windows PE usage to a very limit set of functions, e.g. it may not be used for any purpose other than deployment and recovery. Can you provide more information on why you mentioned Windows PE specifically? Is the idea here to address the widest spectrum of devices running Windows?

This proposal will bring all APIs present on desktop to other SKUs and vice versa unless it's really meant for a specific device category | Must

Do you have an example of a few APIs you have in mind?

This proposal will allow developers to build Windows Runtime components that can be referenced from both UWP and Win32 projects inside Visual Studio without manifest/project file tweak

What tweak are you trying to avoid here? How do you propose these projects reference the Windows Runtime component?

[driver1998]

Microsoft restricts Windows PE usage to a very limit set of functions, e.g. it may not be used for any purpose other than deployment and recovery. Can you provide more information on why you mentioned Windows PE specifically? Is the idea here to address the widest spectrum of devices running Windows?

Maybe #676? But I don't expect to install MSIX packages in Windows PE.

[jaigak]

GDI needs to die.

It has no place on Hololens or Xbox.

GDI already exists on HoloLens and Xbox, just hidden artificially. I would hope all new apps use WinUI however millions of desktop apps exist that require GDI to run. Even on desktop, I don't want GDI anymore but I'm afraid new WinUI desktop apps may not be able to run on other devices as they are not CoreApplication based.

[jaigak]

Desktop Windows can keep it's legacy compatibility and over time sanitise and componentise it to keep the modern core of Windows as lean as possible.

Newer form factors and devices wont have the expectation of supporting legacy stuff, so in time, business will know what SKU it needs to maintain support, and retail consumer markets can embrace the new.

WinUI for legacy code bases, will be the ideal way to continue existing in consumer spaces, and for device compatibility you can move code over to use Reunion and WinRT APIs

So you mean Microsoft can run their Edge Chromium which isn't a WinUI app on other devices but I can't run my own executable on a device that I own? This is monopolistic practice. They can run Windows desktop apps natively on the device but others can't.

[mdtauk]

GDI needs to die.
It has no place on Hololens or Xbox.

GDI already exists on HoloLens and Xbox, just hidden artificially

It should be excised totally, and certainly never encouraged to actually be used. Specifically for HoloLens and Xbox.

GDI will be backwards compatible for Desktop Windows sure, and overtime pushed into its own secure box, discouraged from use, and pushed more and more into Legacy territory.

Any frameworks dependent or built on top of GDI, must be pushed into moving to WinUI.

So you mean Microsoft can run their Edge Chromium which isn't a WinUI app on other devices but I can't run my own executable on a device that I own? This is monopolistic practice. They can run Windows desktop apps natively on the device but others can't.

Chromium was inherited by Microsoft, so hopefully it will move on to WinUI in time. GDI is a legacy framework. Plus Chromium is internally using Web based rendering in a Win32 GDI/DirectWrite surface IIRC

[jaigak]

Chromium was inherited by Microsoft, so hopefully it will move on to WinUI in time. GDI is a legacy framework. Plus Chromium is internally using Web based rendering in a Win32 GDI/DirectWrite surface IIRC

However, it's running at full trust without a container like VAIL. Don't you think other apps should be able to do this? This is making Edge a monopoly because other browsers will run slower because they need a container while they are able to run directly without being a UWP app and access features only for them. This isn't like the old Edge which was a system app. New Edge is a separate cross-platform app that happens to be preinstalled on Windows computers. It shouldn't have access to private APIs and some weird capability that lets it run natively unlike other apps giving them an unfair advantage.