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.

[jaigak]

Maybe not the full GDI stack but you should definitely allow non-CoreWindow based windows created using CreateWindow or CreateWindowEx. It shouldn't be restricted to just a second party app. All WinUI 3 desktop apps should be universal by default unless the developer turns off the option to do so. Win32 apps using custom UI (not GDI) should also be able to run on all devices.

[jaigak]

At least on Windows RT, if you went to the Windows Store and saw an app if it was compiled for ARM, it would work most of the time. However on Windows 10x, if you went to the Microsoft Store and saw an app, even if it's compiled for the target architecture and meets version requirements, it may not work. Reason: many apps now are using full trust components which don't scale everywhere. In the future, most WinUI 3 apps are going to be full trust so there will be a situation where most apps won't work on most devices.

[jaigak]

QT is not Microsoft's responsibility to support. GTK is also third party.

Microsoft OneDrive desktop app uses Qt and if Windows needs to be consistent, Qt also needs to update. Qt has an open-source version so why Microsoft not contribute?

[mdtauk]

QT is not Microsoft's responsibility to support. GTK is also third party.

Microsoft OneDrive desktop app uses Qt and if Windows needs to be consistent, Qt also needs to update. Qt has an open-source version so why Microsoft not contribute?

That's a question for Microsoft, OneDrive is a cross platform app, so it may end up being moved to MAUI or React Native in the future. WinUI has not been finalised yet, so you can't expect everything to support or use it at this stage.

[jaigak]

Microsoft is maintaining legacy support for desktop Windows, which runs on the same kinds of form factors that existed 20 years ago. No reason for them to keep that legacy on new form factors. Adding a more modern way to access Win32 APIs through WinMD, and making future Windows APIs (WinRT) and future Windows UI Frameworks (WinUI) accessible to developers still working with Win32 codebases, is what Reunion is doing. But Devs will need to either change their UI or fit into the device lifecycles and policies - if they want to bring their apps to future form factors, and future variations of Windows.

I know what Reunion is doing in letting Win32 apps use modern tech instead of older ones but it seems like they are going in two separate directions. If you want a WinUI 3 universal app, you need the UWP version which is still not very mature but then you don't get the latest dotnet. If you want the latest dotnet, you can't run on Xbox or HoloLens or Surface Hub.

[mdtauk]

Microsoft is maintaining legacy support for desktop Windows, which runs on the same kinds of form factors that existed 20 years ago. No reason for them to keep that legacy on new form factors. Adding a more modern way to access Win32 APIs through WinMD, and making future Windows APIs (WinRT) and future Windows UI Frameworks (WinUI) accessible to developers still working with Win32 codebases, is what Reunion is doing. But Devs will need to either change their UI or fit into the device lifecycles and policies - if they want to bring their apps to future form factors, and future variations of Windows.

I know what Reunion is doing in letting Win32 apps use modern tech instead of older ones but it seems like they are going in two separate directions. If you want a WinUI 3 universal app, you need the UWP version which is still not very mature but then you don't get the latest dotnet. If you want the latest dotnet, you can't run on Xbox or HoloLens or Surface Hub.

WinUI 3.0 is targetting Win32 apps for Desktop.

WinUI 3.X will target UWP apps, and other SKUs like Teams, Xbox, Holographic.

.NET 6 will coincide with these versions, so .NET 5 support is being skipped.

[jaigak]

WinUI 3.0 is targetting Win32 apps for Desktop.
WinUI 3.X will target UWP apps, and other SKUs like Teams, Xbox, Holographic.
.NET 6 will coincide with these versions, so .NET 5 support is being skipped.

So what should I do now if I want a rich .NET 5 UWP app? I can't wait. I need to ship. Yes I can use WinUI 2.x will continue support even after WinUI 3 but can I use .NET 5? Can I use all the C# 9 features? Even WPF which is a legacy technology gets .NET 5 but not the state of the art technology that you have encouraged for the past few years and now you are betraying us.

[jaigak]

There are rumours that UWP is dead. I strongly oppose that but I'm really confused what's the plan. I can understand WinUI's situation which needs desktop first because it's the first time the WinRT XAML framework is available for desktop apps but what about other APIs introduced with Reunion? I don't want to see an attribute that says it's universal, instead I want an attribute that something isn't universal. Everything must be universal unless it's clearly mentioned that it's not, not the other way around,

[riverar]

I think we're getting off track here.

It appears @Jaiganeshkumaran's core ask here is to allow the deployment and execution of Reunion apps on tailored devices (e.g. Xbox, HoloLens, IoT).

I have some outstanding questions above and I'm still confused as to which APIs developers would use on these devices though. Is the ask to document the native API primitives on the devices and let folks figure it out themselves? Or tailor WinUI to these devices somehow?

[driver1998]

Edge Chromium is running full trust on 10X/Xbox/Hololens 2, with the restricted "deployFullTrustOnHost" capability and custom "shim" to provide basic Window functionality. But I don't think it uses GDI.
Opening up the magic glue used here can be a good idea, but might also be very dangerous.

[driver1998]

The other Reunion APIs (app lifecycle, MRI resources and DirectWrite) are already available in UWP, just being ported to Desktop apps, so I am not worried about the Reunion version does not work (yet).
MRT Core should be working in UWP if WinUI 3 relys on it, not sure about DWCore.

[jaigak]

Anyway, my whole point is if Win32 apps were able to run on all devices, then we wouldn't have to worry about whether it's universal or not and having all the same APIs everywhere will reduce a lot of effort for developers building universal apps.

[jaigak]

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 not packaged apps but WinUI 3 should definitely work on Windows PE so Microsoft can easily replace the Metro-style Windows Recovery Environment and the Aero Windows setup with a modern Fluent one with the same UI as new WinUI 3 apps and OEMs and WinPE recovery solution builders can do the same and use modern Fluent UI under Windows PE.

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?

Actually many APIs in shlwapi.dll is already universal but they aren't allowed under UWP. Some of them have no reason to not be available under UWP while others may be a security risk. StrFormatByteSizeEx is a very simple function that has nothing to do with security yet not available for UWP but actually already universal but for full trust apps which only Microsoft can create other than on desktop. Another example is SHGetLocalizedName which is already universal but not available under UWP. It seems like IStorageItemProperties::get_DisplayName() does wrap it but some apps don't use WinRT Storage APIs and they want to be able to still get the localized name.

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?

Today if you directly reference a WinRT component in Visual Studio, it won't work in desktop projects as the template assumes it's going to be used under AppContainer which isn't always true. A new template for a WinRT component/DLL should be provided which can be referenced from both types of project (essentially PCL but native).

[jaigak]

I'm proposing a new AppTypeInformation static class to know what kind of app it exactly is so a Windows Runtime component can work accordingly (Win32 means more access). Here's how it could look in MIDL:

namespace Microsoft.ApplicationModel.Core
{
	enum AppType
	{
		WindowsDesktop, WindowsUniversal
	};
	
	[default_interface]
	static runtimeclass AppTypeInformation
	{
		static AppType DetectForCurrentProcess();
		static AppType DetectForProcessId(Int32 processId);
	}
}

It should return WindowsUniversal if the app is CoreApplication based or if it's a UWP console app, else WindowsDesktop should be returned. Libraries can use this information to call the right API based on the app type. This is needed because packaged doesn't mean UWP and since partial trust exists we can't surely know whether it's an app using CoreApplication or not.

[ghost]

@Jaiganeshkumaran
you seem like asking what I proposed around 7 months ago
Question: will All Project Reunion APIs be able to run on future and existing other windows powered platforms (eg : Xbox/Hololens) ?

@anyone
let myself put forward the same scenario above which went unanswered .

what's the market share of touch based windows 10 tablets?
not every windows developer is a MVP or cse student wanna work at ms type or enthusiast type who wants to take advantage of Modern App Lifecycle or WinUI or latest features. a large chunks are enterprise devs or indie devs who most probably have to web/mobile/other platforms by now.

modern app lifecycle or winUI are the benefit for the ecosystem for the users. what would benefit for him as a developer?
windows developers who hadn't updated his app in decades , why would they suddenly want to update his app with PR?
because of backward compatibility their app just keeps working till the latest version of windows , for what reason they will be botherd at all to touch the codebase ?
what will be the motivation factor for developers to update their decade old winform or wpf or MFC apps ?

now let's be practical, do developers care for shiny new features or do they care about their userbase reach ?
without their userbase growth potential , why would they be bothered at all? userbase growth potential comes only when their apps can run on universally on other windows platforms like xbox/hololens.

regarding WinRT advocates, a winRT apis which sit on top of win32 api for their existence, what benefit this winRT/COMv2 apis thing brings to table other than async wrappers of several win32 apis or some easy coding benefits? all win32 limitation like 255 char path+file limit limitaions are inherited to thing winRT thing in 2021. though I support winRT but it still very immature , perf of strorageItem apis is nightmare for devs.

UWP ? that metro apps could not save windows RT , windows phone, now windows 10X. you exclude win32 apps, instantly windows will become useless for most people. heck the browser is even raw win32 app.

dreaming is nice and all, but it doesn't change reality.

I have to be constructive/feedback based here, so what do I propose?

tell win32 devs your app will become universal provided that you take advantage of
1.winUI
2.MSIX
3.do some include-exclude modifications of api usage for platform targets.
Edit : 4. AppContainer

only then all big apps incl. indie devs with decade old windows programs which are still used today will have
justifiable reasons enough to rethink or comeback to windows.

[ghost]

@Jaiganeshkumaran can you please rename the ambiguous title to something specific,

title should have been : One App Model, not multiple.

[jaigak]

If Windows App SDK is really about Reunion, what's the reason behind not allowing Windows App SDK NuGet to be installed and used with UWP/WinUI 2.x XAML Island apps when every other app using older frameworks such as WinForms and WPF can install and use it?