-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
One Windows with an unified app model #829
Comments
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. |
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. |
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.) |
GDI needs to die. It has no place on Hololens or Xbox. |
Opinion: Let's not backport the worst of desktop to HoloLens and XboxIn 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: General API surface: User Experience: 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. |
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 |
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. |
Some questions:
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?
Do you have an example of a few APIs you have in mind?
What tweak are you trying to avoid here? How do you propose these projects reference the Windows Runtime component? |
Maybe #676? But I don't expect to install MSIX packages in Windows PE. |
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. |
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. |
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.
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. |
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. |
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. |
I don't think any app should be rendering GDI on anything other than Windows Desktop. I don't even like Microsoft doing it, and I am hoping the Edge UI will be moved to WinUI ASAP, and the UI used for HoloLens and Xbox should be adapted to suit those platforms.
HoloLens and Xbox are not fully open platforms, and enabling GDI or old Win32 apps, would lead to a poor user experience, and would tarnish those platforms.
WinUI 3.0 is a Desktop Windows release, and future releases of WinUI and Reunion, should be adding support for the Universal platforms, like Xbox. Once Xbox supports WinUI, then devs will be encouraged to move their UWP apps over to it - and it may even enable Win32 apps with a compatible range of API's used - to move to WinUI and Reunion, and then support Xbox. |
There will always be limitations on Applications wanting to support devices like the Xbox, on what API levels are supported. Xbox is a closed system, and there are different expectations from the user. If your app needs greater and greater access to the system or data, the fewer devices it will be able to run on. |
What about new modern Win32 apps? Like WinUI 3 desktop apps, won't they run on other devices? I know WinUI has both desktop and UWP option but my point is the desktop option itself should be universal. If Win32 is a legacy, what technology does Edge use? What technology does the new Skype use? What technology do Microsoft Teams use? What technology does Office use? (UWP Office exist but not actively maintained). I want the UWP/Win32 divide done. They are all Windows apps and should run on any Windows device. Users don't care whether it's UWP or not but they want the functionality working. |
Unoptimized? Notepad just consumes 1MB when opened while these so-called modern UWP text editors consume more than 40MB on idle. Do you call that modern? Do you think that's better? Yes, Win32 lets you access more stuff which means less secure but by MSIX packaging it could be reduced. |
I agree with your sentiment, I would like every app on Windows to use WinUI and abandon GDI. Because GDI is legacy, maintaining support for it for Desktop Windows is important. But putting all that ugly cruft into future platforms and form factors - is hampering the future, and will lead to crappy app experiences for everyone. Microsoft should not be expected to bring legacy frameworks to modern platforms. Lazy Devs need to put some effort into bringing apps to new devices and platforms. Microsoft are going to the effort with Reunion, to make that porting process easier, by trying to sort out the mess that is Win32, through WinMD to encourage devs. |
Just like Surface was the only tablet that can replace your laptop, if Windows Phone wasn't dead, we could have seen something really revolutionary. I do want Visual Studio on my phone. I do want Photoshop on my phone. I do want Blender on my phone. I do want all existing 16 million Windows desktop apps that made Windows great. Maybe not on the phone screen itself but it would've been great on Continuum. How can a XAML UI framework that doesn't even have a data grid compete with existing cross-platform frameworks which wrap on GDI? How will Microsoft convenience Qt, GTK and others to wrap WinUI instead of GDI? I would like to see modern Fluent UI in apps that use those frameworks rather than some old ugly greyish UI not designed for modern hardware. |
This is the kind of optimisation that WinUI exists for QT is not Microsoft's responsibility to support. GTK is also third party. |
Well so if I buy a Windows 10x device, Can't I use services that Microsoft is advertising? Can't I use real desktop Office? Can't I open local documents? (Office online requires all files to be OneDrive).
Skype has become a horrible app. Freezes a lot, doesn't work well with touch has weird keyboard navigation bugs etc. They don't seem to care about user feedback.
Most of them aren't using GDI directly but rather using frameworks that wrap them. Microsoft should work with them to modernize as soon as possible.
But will most developers? Most users and customers just use Windows because their 20-year-old software works in there. (Maybe newer versions but hasn't changed much). Accept it, Windows has lost. I expect most users to switch to Linux or macOS, or ChromeOS or leave PCs altogether and just use their phone. If Windows is still relevant, why most Microsoft software still uses MSI installers? Those apps don't need to be Store apps but shouldn't cause machine rot even if they are distributed on their website. I want to avoid unpackaged apps as much as possible but I failed to do so. |
Also coming to WinUI 3, I don't really know why it's worth it now. Yes, there are some improvements like touch in the past 8 years not available to GDI but for that, I can also just write a Windows 8.1 app or a UWP app not using WinUI. Will support more versions if I down target. The real reason why I wanted WinUI is because I would have amazing UI with smooth animations, reveal effects, acrylic etc... but seems like those are being removed and being replaced with classic change colour on hover tricks. It doesn't feel responsive and smooth. You have killed Fluent in the name of improvement just to make it consistent with your websites where it's harder to implement efficiently. |
10X is gone for now, but the intent was eventually to run Win32 apps in a legacy container, if not at launch.
Microsoft intends for frameworks to build for WinUI. MAUI, React Native, WebView2 are all working to build on top of WinUI, and there are XAML APIs for middleware frameworks to output XAML from their own tooling. This is what GTK or QT should do.
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. |
This again. All the animations are supported, and these will improve over time (Composition, AnimatedVisual, Win2D, ConnectedAnimations, ExpressionAnimations etc) HostBackdrop Acrylic will be there in 3.x, just not there for 3.0 Reveal is something Microsoft is abandoning for a design reason, but who knows what new ideas will come to replace it. Xaml Light is still supported if you want to use it to build UI effects. |
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. |
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. |
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, |
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? |
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. |
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). |
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. |
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.
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.
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). |
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:
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. |
@JaiganeshKumaran @anyone what's the market share of touch based windows 10 tablets? modern app lifecycle or winUI are the benefit for the ecosystem for the users. what would benefit for him as a developer? now let's be practical, do developers care for shiny new features or do they care about their userbase reach ? 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 only then all big apps incl. indie devs with decade old windows programs which are still used today will have |
@JaiganeshKumaran can you please rename the ambiguous title to something specific, title should have been : One App Model, not multiple. |
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? |
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
Scope
The text was updated successfully, but these errors were encountered: