Windows 10: Microsoft filling in divide between Win32 apps and new Windows APIs

Brink · Oct 29, 2019

Many new and sought-after Windows APIs and features such as BackgroundTasks, Notifications, LiveTiles, Share and more, are either not available or not easily callable from non-packaged Win32 applications. This is due to the programming model for UWP APIs that integrate with the system and have a dependency on the following concepts:

Identity – The need for package or application identity to identify the caller, and an identifier to scope data and resources.

Registration – The need for configuration of machine state during application deployment, which is required by the API and indexed by the package or application identity.

For packaged applications, Identity declared in the Appxmanifest.xml, and Registration is handled by the MSIX deployment pipeline based on the information in the AppxManifest.xml. This allows a simplified calling pattern for UWP APIs where the application code just uses an API. Compare this to a typical Win32 API that requires a register-use-unregister pattern for managing a callback.

We’ve heard your feedback, and in response we’re filling in the divide between Win32 apps and new Windows APIs & features so that you can take advantage of these new APIs & features and enhance your applications. As of Windows Build 10.0.19000.0 we’re introducing the following new AppModel concepts to provide your Win32 app with deeper integration into the OS:

Sparse Package registration
Signed MSIX packages can be installed on Windows today but all content referenced in the package’s Appxmanifest.xml must be present inside the package. A ‘Sparse’ Package contains an AppxManifest.xml but unlike a regular/full package, the manifest can reference files outside its package in a predetermined ‘external location’. This allows applications that are not yet able to adopt complete MSIX packaging to gain Identity, configure state (Registration) as required by UWP APIs and then take advantage of these APIs.

Package ‘External Location’
To support a Sparse Package, a package definition now has a new <allowExternalContent> element. This is what allows your package AppxManifest.xml to reference content outside its package, in a specific location on disk. For example, if your existing Win32 app installs content in C:\Program Files\MyWin32App\ , you can create a Sparse Package that declares the <allowExternalContent> element and during app installation or first run of your app, you can register the Sparse Package and declare C:\Program Files\MyWin32App\ as the external location your app will be using. This way you can continue deploying all your other app artifacts in the locations you do today while taking advantage of the Sparse Package.

Win32 type RuntimeBehavior
To help with compatibility of your existing Win32 app when using a Sparse Package, the app can register to have its application process be run like a non-packaged Win32 app as much as possible. This differs from a fully packaged Win32 app in that it is not subject to filesystem + registry virtualization, lifetime management by the system and other runtime attributes of fully packaged applications. The main runtime similarity between such an app and a fully packaged app is the presence of app/package identity in the running process.

Activation via CreateProcess
The activation path for UWP applications today ensures the app has PackageIdentity in its process token. This is used by UWP APIs to identify the caller and refer to later – either to perform a callback or to look up state that was configured during deployment. Because of this requirement, calling CreateProcess() on a UWP exe will fail as the CreateProcess() pipeline was not enlightened about Identity. In order to support Sparse Packages with an External Location, we leverage the classic Win32 application.manifest to provide Identity in CreateProcess() scenarios.

At their core, these features are about providing a foundation for non-packaged Win32 processes to use our latest APIs and features.

*Please note that these are still new and somewhat advanced development features that do not yet have full Visual Studio integration i.e. there are still some gaps in the end to end authoring experience such as having to create a Sparse Package outside of Visual Studio...
Click to expand...

Source: Identity, Registration and Activation of Non-packaged Win32 Apps - Windows Developer Blog

Tweet

— Twitter API (@user) View on Twitter
Click to expand...

:)

Brink · Oct 29, 2019

Microsoft wants to close the UWP and Win32 divide with Windows Apps

Is Microsoft's UWP going away? Is the Microsoft Store on its way out? Microsoft Corporate VP Kevin Gallo explains the latest twists in Microsoft's long and winding Windows developer platform strategy.

For months, many pundits, partners and customers have wondered aloud whether Microsoft's Universal Windows Platform (UWP) has a future. Officially, the story is UWP is alive and well. But the Win32 platform lives on and seems to be back on Microsoft's radar screen. So what's the real story?

I had a chance this week in Seattle to ask Kevin Gallo, Corporate Vice President of the Windows Developer Platform, for his take on what's going on with the Windows developer platform.

When Microsoft launched UWP in 2015, officials promised that the platform would provide apps with better performance and security because they'd be distributable and updatable from the Microsoft Store. Developers would be able to use a common set of programming interfaces across Windows 10, Windows Phone, HoloLens and more, officials said, when selling the UWP vision. The downside: UWP apps would work on Windows 10-based devices only. Developers would have to do work to get their apps to be UWP/Store-ready. And Win32 apps wouldn't get UWP features like touch and inking.

Arguably, Gallo told me, "we shouldn't have gone that way," meaning creating this schism. But Microsoft execs -- including Gallo -- continue to maintain that UWP is not dead.

Over the past year or so, Microsoft has been trying to undo some of the effects of what Gallo called the "massive divide" between Win32 and UWP by adding "modern desktop" elements to Win32 apps.

"By the time we are done, everything will just be called 'Windows apps,'" Gallo told me. "We're not quite there yet." But the ultimate idea is to make "every platform feature available to every developer."
Click to expand...

Read more:

Microsoft wants to close the UWP, Win32 divide with 'Windows Apps' | ZDNet

Microsoft Confirms UWP is Not the Future of Windows Apps - Thurrott.com

Brink · Oct 29, 2019

Microsoft wants to close the UWP and Win32 divide with Windows Apps

Is Microsoft's UWP going away? Is the Microsoft Store on its way out? Microsoft Corporate VP Kevin Gallo explains the latest twists in Microsoft's long and winding Windows developer platform strategy.

For months, many pundits, partners and customers have wondered aloud whether Microsoft's Universal Windows Platform (UWP) has a future. Officially, the story is UWP is alive and well. But the Win32 platform lives on and seems to be back on Microsoft's radar screen. So what's the real story?

I had a chance this week in Seattle to ask Kevin Gallo, Corporate Vice President of the Windows Developer Platform, for his take on what's going on with the Windows developer platform.

When Microsoft launched UWP in 2015, officials promised that the platform would provide apps with better performance and security because they'd be distributable and updatable from the Microsoft Store. Developers would be able to use a common set of programming interfaces across Windows 10, Windows Phone, HoloLens and more, officials said, when selling the UWP vision. The downside: UWP apps would work on Windows 10-based devices only. Developers would have to do work to get their apps to be UWP/Store-ready. And Win32 apps wouldn't get UWP features like touch and inking.

Arguably, Gallo told me, "we shouldn't have gone that way," meaning creating this schism. But Microsoft execs -- including Gallo -- continue to maintain that UWP is not dead.

Over the past year or so, Microsoft has been trying to undo some of the effects of what Gallo called the "massive divide" between Win32 and UWP by adding "modern desktop" elements to Win32 apps.

"By the time we are done, everything will just be called 'Windows apps,'" Gallo told me. "We're not quite there yet." But the ultimate idea is to make "every platform feature available to every developer."
Click to expand...

Read more:

Microsoft wants to close the UWP, Win32 divide with 'Windows Apps' | ZDNet

Microsoft Confirms UWP is Not the Future of Windows Apps - Thurrott.com

FordGT90Concept · Oct 29, 2019

Microsoft Adds Ability to Block Win32 Apps from Install on Windows 10

I wouldn´t be surprised if some manufacturers start shipping their PCs/laptops with Win 10 Cloud only.
Click to expand...

That's actually a certainty already. Microsoft wants to create a competing product against Chromebook. I'm sure this is one of the features that bring them closer to that.

For which API, UWP or Win32? Care to elaborate?
Click to expand...

UWP is "significantly slower" than Win32. Probably 10-30%. UWP is completely managed (memory pointers are forbidden) like .NET Framework is. They're very closely linked. UWP can be made to run on any processor architecture (ARM, x86, and AMD64 right now). I believe UWP has a path for emulating Win32 too (they demonstrated this in a Windows Phone 10 feature).

Windows 10: Microsoft filling in divide between Win32 apps and new Windows APIs

Microsoft filling in divide between Win32 apps and new Windows APIs

Microsoft filling in divide between Win32 apps and new Windows APIs

Microsoft filling in divide between Win32 apps and new Windows APIs

Microsoft filling in divide between Win32 apps and new Windows APIs - Similar Threads - Microsoft filling divide

How to get the latest DPI of System with win32 API.

How to get the latest DPI of System with win32 API.

How to get the latest DPI of System with win32 API.

Microsoft takes another step to bridge Win32-UWP divide on Windows 10

Microsoft Making Win32 APIs More Accessible to More Languages

[Win32 API] Resizing a borderless window?

Can Windows Defender detect external win32/kernel api calls?

Win32 apps in the Microsoft Store?

Microsoft wants to close the UWP and Win32 divide with Windows Apps