Open JaiganeshKumaran opened 3 years ago
JaiganeshKumaran
commented
3 years ago 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.
JaiganeshKumaran
commented
3 years ago 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.
JaiganeshKumaran
commented
3 years ago 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
commented
3 years ago GDI needs to die.
It has no place on Hololens or Xbox.
lukeblevins
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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 https://github.com/microsoft/ProjectReunion/issues/676? But I don't expect to install MSIX packages in Windows PE.
JaiganeshKumaran
commented
3 years ago 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.
JaiganeshKumaran
commented
3 years ago 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
commented
3 years ago 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
JaiganeshKumaran
commented
3 years ago 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.
JaiganeshKumaran
commented
3 years ago 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.
JaiganeshKumaran
commented
3 years ago 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.
mdtauk
commented
3 years ago 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.
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.
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.
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.
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.
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.
mdtauk
commented
3 years ago 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.
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.
JaiganeshKumaran
commented
3 years ago 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.
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.
JaiganeshKumaran
commented
3 years ago 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.
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.
mdtauk
commented
3 years ago 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.
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.
- Some of those use Electron. That is currently Win32 GDI with a Chromium engine. This wont work outside of Desktop.
Skype I believe is React Native, currently on top of Win32 GDI, but eventually will work on WinUI 3.X
Once WinUI 3.X is out in the wild and stable, we can hope that Microsoft will move all their apps to it. Those apps which are cross platform with Android and iOS, will need to share as much code as possible. React Native on WinUI could do that.
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.
JaiganeshKumaran
commented
3 years ago 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.
mdtauk
commented
3 years ago 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.
This is the kind of optimisation that WinUI exists for
QT is not Microsoft's responsibility to support. GTK is also third party.
JaiganeshKumaran
commented
3 years ago
- Some of those use Electron. That is currently Win32 GDI with a Chromium engine. This wont work outside of Desktop.
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 I believe is React Native, currently on top of Win32 GDI, but eventually will work on WinUI 3.X
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.
- Once WinUI 3.X is out in the wild and stable, we can hope that Microsoft will move all their apps to it. Those apps which are cross platform with Android and iOS, will need to share as much code as possible. React Native on WinUI could do that.
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.
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.
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 is 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.
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.
JaiganeshKumaran
commented
3 years ago 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.
mdtauk
commented
3 years ago 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).
10X is gone for now, but the intent was eventually to run Win32 apps in a legacy container, if not at launch.
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.
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.
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 would 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 installer. Those apps don't need to be Store apps but shouldn't cause machine rot. I want to avoid unpackaged apps as much as possible but I failed to do so.
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.
mdtauk
commented
3 years ago 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.
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.
JaiganeshKumaran
commented
3 years ago 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
commented
3 years ago 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.
JaiganeshKumaran
commented
3 years ago 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
commented
3 years ago 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.
JaiganeshKumaran
commented
3 years ago 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.
JaiganeshKumaran
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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.
JaiganeshKumaran
commented
3 years ago 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.
JaiganeshKumaran
commented
3 years ago 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).
JaiganeshKumaran
commented
3 years ago 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
commented
3 years ago @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.
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
commented
3 years ago @Jaiganeshkumaran can you please rename the ambiguous title to something specific,
title should have been : One App Model, not multiple.
JaiganeshKumaran
commented
2 years ago 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