Platform transitions are hard, moving from silicon to silicon or operating system to operating system. But there’s one thing that’s harder: moving from one SDK to another. Microsoft is in the middle of a massive transition, away from more than a decade of Win32 code and its various user experience layers to the modern WinRT and Universal Windows Platform (UWP).
That’s a huge project, with billions of PCs and Windows installations of all versions, and with code that’s built using raw Win32, with WinForms, and with WPF. Porting it all to UWP overnight is an impossible demand on an industry that’s focused on supporting existing line-of-business software with only incremental upgrades. And although Microsoft’s Desktop Bridge allows some integration with Windows 10 features, it doesn’t bring them back to software written for Windows 7 or take advantage of new user interface components that have no equivalents in older Windows SDKs.
Improving the UWP desktop UI
With much of the work on delivering the core UWP platform complete, Microsoft is now working on ways of back-porting its features to older SDKs, with the aim of bringing what it calls “modern applications” and desktop applications closer together. Part of that process is a new set of UWP controls that’s more desktop focused, along with ways of embedding those controls in older code and with new deployment models that make it easier to roll out new versions of older applications.
UWP’s window layout inherits much of its control design and spacing spacing from the tablet-first Windows 8 WinRT. With Windows 10’s focus on desktop applications, that’s led to applications with a lot of wasted screen real estate. What might have worked well on a single screen on an 8-inch tablet doesn’t work on a 28-inch monitor, let alone on a 15-inch laptop. If you compare Windows 10’s bundled Mail app with Outlook 2016, you see how much information is lost in UWP layouts.
With the fall 2018 release of Windows 10 Build 1809, a new standard UWP view increases information density by 15 percent. It’s not a huge change, but enough to add a couple more email messages to the Mail list view. And it’s not the only option; there’s also a compact view for UWP controls that lets you add even more information to a screen. You still get access to all the touch and pen affordances in less-dense UWP layouts, but at the same time you can start to replicate the layouts that were possible in older Windows UIs.
Adding UWP components to Win32 applications
Bringing dense layouts to UWP helps with complete application rewrites, but what if you want to get access to UWP features without changing your underlying code? That’s where the new XAML Islands feature comes in. It lets you replace existing WinForms or WPF controls with their UWP equivalents, dropping them into the existing design surfaces, with access to UWP features. With XAML Islands, you can quickly add handwriting features to your existing code, or take advantage of Microsoft’s new Fluent Design language, quickly updating applications without needing to make major changes to them.
Described in a Build 2018 session as an “Easy button,” the UWP XAML for commonly requested controls is wrapped in WPF and WinForms wrappers. There is fallback to older versions, so one binary will still work across Windows 10 and Windows 7 applications; though obviously Windows 7 won’t get the UI or OS-level features available to code running on Windows 10.
One bonus that comes with XAML Islands is that you get access to the new Edge-based WebView control. Because the older IE-based WebView control only gets minimal updates, you can start to use newer HTML and CSS features as well as more modern JavaScript inside your web components. You can also take advantage of new form features, like cloud-based Ink Analysis to add pen support without needing additional code.
You can start using XAML Islands in current Insider builds of Windows 10, with initial support for WebView. Other controls will follow before the final release sometime in fall 2018.
Because Microsoft is working through its existing open community control toolkit design process, much of the work is taking place on GitHub, with the opportunity for developers to influence which controls get XAML Islands support.
But don’t expect all controls to get XAML Islands support; there’s a lot of work required to add the appropriate wrappers to existing controls, and controls where there’s no source control or from long-lost third parties are unlikely to ever make the shift. Microsoft is promising tools to help you wrap your own custom controls, but they’re unlikely to arrive until 2019.
New installers for old code
The final part of this new approach to modernizing desktop applications is a new installer model, and a new way of deploying .Net itself. A key aspect of this approach is a focus on supporting desktop applications in .Net Core 3.0. While the core role for .Net Core remains as a support for UI-less cross-platform applications, its small size and growing roster of support for familiar .Net APIs via .Net Standard makes it an ideal host for independently installed and managed desktop applications.
By bundling .Net Core and any required application code into a single deployment container, there’s no longer any need to worry about maintaining .Net versions of desktop devices: Everything needed to run an app is with the app. If different apps need different versions of the same library, there are no versioning issues, because each app has its own isolated copy of the library.
Closely related is MSIX, a new deployment package, that brings together most of Windows’s familiar deployment tools, with the ability to deploy directly or through the Microsoft Store. Existing MSI and .appx packages can be converted to the new format, bringing older apps forward. IT pros can manage customizations separately from the application package, making it easier to deploy new releases and updates simply by adding a common customization pack to each new MSIX. Code can run in isolated containers on Windows 10, building on the .appx isolation mode, hosting both Desktop Bridge-converted code and UWP apps.
Microsoft’s history of backward compatability makes it hard for it to deliver the benefits of major platform upgrades to developers and users. After all, why should code get upgraded if it will run on all supported Windows releases?
By providing new roads to both application updates and to deployment, there’s now scope to bring existing code forward and to allow both old and new applications to run side by side without conflicts. With this latest round of platform updates, Microsoft may have finally delivered the components needed to encourage organizations to complete their Windows 7 to Windows 10 migrations.