News

Project Reunion Preview: Because 'Windows Development Is Hard'

In an expansive effort to point its developer tooling at everything from the cloud to mobile to web to IoT to gaming to whatever, Microsoft may have neglected one obvious target: Windows.

"Windows development is hard," said Microsoft's Thomas Fennel in explaining why the company is touting Project Reunion, which just shipped in a v0.5 preview. In talking to enterprise customers, Fennel said, "we have heard that Windows development is hard. It's harder than it should be. It's harder than it needs to be."

It's hard for a variety of reasons, including varied Windows versions that complicate the rollout of enterprise apps with new features, along with the need to accommodate older "down-level" Windows versions.

The idea behind Project Reunion is to alleviate that difficulty, in part by bridging two disparate Windows desktop development schemes that have arisen: Win32 and Universal Windows Platform (UWP). The Win32 API (used for what is often called "classic Windows desktop development") was the original C/C++ platform for native Windows apps, providing close-to-the-metal performance with direct access to system hardware.

Then along came UWP, a "modern" take on Windows development, providing a common type system and application model and APIs for all Windows 10 devices. UWP effectively containerizes these apps with lower privilege levels and package identity delivered via an MSIX installer.

That resulted in today's two distinct desktop dev camps that Project Reunion seeks to unify. Basically, it will lift those two sets of APIs out of Windows, decoupling them from the OS and transferring their underlying functionality into a Reunion SDK, served up by NuGet.

Project Reunion
[Click on image for larger view.] Project Reunion (source: Microsoft).

"Project Reunion empowers all Windows apps (not just UWP/MSIX) with modern Windows UI, APIs and platform features, including back-compat support, shipped via NuGet," the project's GitHub site states.

The effort has a definite enterprise focus, and in these early stages Microsoft is mainly attempting to get the unification ball rolling and collect feedback on how to proceed, mainly from enterprise customers who are contacted at community events, one-on-one meetings and other outreach.

That part of the project kicked off with this week's introduction of Project Reunion 0.5, where Microsoft says, "Project Reunion provides a unified set of APIs and tools that can be used in a consistent way by any desktop app on a broad set of target Windows 10 OS versions.

"Project Reunion does not replace the existing desktop Windows app platforms and frameworks such as .NET (including Windows Forms and WPF) and C++/Win32. Instead, it complements these existing platforms with a common set of APIs and tools that developers can rely on across these platforms."

In a video, Microsoft's Fennel addressed the complexity of enterprise Windows app development and explained the spiritual reasoning behind Project Reunion's attempt to bridge Win32 and UWP in an exceedingly long sentence.

"We'll bring those worlds together, and we'll just be thinking about Windows apps and libraries built on the Project Reunion SDK, versioned independently and at a speed that works for you, and decoupled from the OS, so that we can make everybody's life, hopefully, a lot easier and bring Windows back to the place it used to be where it was easy and creative and people could build complex and powerful things on it without having to worry about which version of the operating system they were tied to."

On the more practical side, one key to the reunification project is WinUI 3, which uses Fluent Design to provide a native user experience (UX) framework for both Win32 and UWP applications.

Reunion Component
[Click on image for larger view.] Reunion Components (source: Microsoft).

Two other components of v0.5 are MRT Core and DWrite Core.

Microsoft says the MRT Core component streamlines the Windows Resource Management System used to index all app resource variants at build time and then detect user and machine settings at run time to load the resources to fit those settings.

DWrite Core, meanwhile, is a customized version of DirectWrite, used to support high-quality text rendering in modern applications.

Also available, according to the project GitHub site, are C++/WinRT, Rust/WinRT and C#/WinRT language-native projections. These projections are used to translate the COM-based Windows Runtime interfaces to natural, idiomatic patterns specific to individual languages.

Another component ready for use is MSIX-Core, which helps developers package applications for distribution to Windows Desktop machines via the Microsoft Store or their own delivery pipelines. Microsoft says MSIX-Core lets coders reuse parts of the MSIX packaging story on older versions of Windows.

So developers can start using all of those bits right now in Project Reunion 0.5, which Microsoft warns is a developer preview. "You are encouraged to try this release in your development environment. However, be aware that Project Reunion will change in many ways between now and the 1.0 release. Project Reunion 0.5 Preview is not supported for apps that are used in production environments. Project Reunion is a code name that may change in a future release."

According to the roadmap, that v1.0 release is scheduled for the fourth quarter of this year, with a v.0.8 release on tap for the second quarter.

Project Reunion Roadmap
[Click on image for larger view.] Project Reunion Roadmap (source: Microsoft).

Fennel provided another take on the roadmap going forward for the rest of the year after this week's milestone release. He described top-level pillars "for where we want you to be able to use and invest from features that we create in Project Reunion." These pillars are not tied to releases and serve as buckets of functionality to focus on, including:

  • Coherent, modern interactions and UX design: WinUI 3, WebView 2, modern windowing
  • Great system performance and battery life: application lifecycle, notifications, background tasks
  • Optimized for the device hardware: ARM64 support, inking, input
  • Hassle-free app discovery and management: enhanced app packaging, framework package deployment, auto update for all apps

Samples available to help developers get started include:

As noted, however, Microsoft at this stage is all about collecting developer feedback about what features to include and where to take the project next. The company says its preliminary roadmap isn't set in stone, rather acting as an initial framework that will be amended and evolved largely by community input.

That community contribution process -- filed issues, questions, discussions, feature proposals and more -- is explained here.

About the Author

David Ramel is an editor and writer at Converge 360.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube