What Kind of Packaged Process Is It?

As previously discussed, we can divide processes into the two broad categories of packaged vs unpackaged, based on if the process HAS or LACKS package identity.

Packaged processes can be divided into three broad categories:

• Universal
• Centennial/Desktop Bridge
• Win32alacarte

All three have package identity, but they make different tradeoffs between compatibility and modern packaged behavior.

RuntimeBehavior

Packages specify how an application process is created and runs via multiple properties in AppxManifest.xml. The RuntimeBehavior attribute clearly expresses this:

RuntimeBehavior = <windowsApp | packagedClassicApp | win32App>

RuntimeBehavior="windowsApp" is a Universal app. It was first introduced in Windows 8¹. New lingo appeared with it, initially referring to unpackaged vs (Universal) packaged apps as ‘Classic’ vs ‘Modern’. The latter evolved through several codenames and formal product names over the years:

Modern
➔ Tailored
   ➔ Immersive
      ➔ Metro
         ➔ Modern
            ➔ Universal Windows App (UWA)
               ➔ Universal Windows Platform (UWP) app

This naming history explains why the Settings app uses the package name windows.immersivecontrolpanel. It also explains why Windows stores it in %windir%\ImmersiveControlPanel.

Universal apps are built on the Windows Runtime (WinRT) application model, using CoreApplication, historically use CoreWindow, and run in an AppContainer.

RuntimeBehavior="packagedClassicApp" identifies a Centennial app. MSIX introduced it in Windows 10 version 1607 (build 14393, aka RS1). Later, Microsoft released it under the official name Desktop Bridge. These are essentially classic Win32 (unpackaged) applications with a WinMain() or main() entrypoint, use HWNDs, can be console applications and can run in an AppContainer but not required (and often don’t). Although ‘Centennial’ was the original codename, it’s persisted in common use as it rolls off the tongue more easily than the alternatives.

MSIX introduced RuntimeBehavior="win32App" in Windows 10 version 2004 (build 19041, aka 20H1). This was originally codenamed ‘win32alacarte’ because it aimed to allow packaging behaviors to be selectively enabled for compatibility. Many people still informally refer to this as ‘Win32alacarte’ to avoid confusing RuntimeBehavior="win32App" with traditional unpackaged Win32 applications.

Win32alacarte is similar to Centennial in mechanism (WinMain()/main(), HWND, …) but with a very different guiding principle.

Centennial vs Win32alacarte

The difference between Centennial and Win32alacarte is very simple:

Centennial’s goal is “Be a good Windows citizen” vs Win32alacarte’s focus is “Compatibility”.

Centennial

Centennial processes behave differently from classic (unpackaged) Win32 processes to be more secure, reliable, cleanly uninstall and generally be better behaved (and with less effort by the developer).

For example, DLL Search Order for unpackaged apps encompasses 18 ways to resolve DLLs vs 8 for Centennial apps.² By excluding locations such as the current directory and entries from PATH, Centennial applications reduce the risk of accidental or malicious DLL hijacking.

For another example, Centennial’s I/O virtualization (aka Flexible Virtualization) is enabled for Centennial apps, vs non-existent for unpackaged apps. This helps applications cleanly uninstall because writes are redirected to package-owned locations instead of being scattered throughout the system.

Centennial makes it easier to write well behaved applications, but these differences can be problematic for some (especially older) applications.

Win32alacarte

Win32alacarte focuses on compatibility, even if the result is less well behaved than desired. The primary goal of Win32alacarte is to provide package identity with a high degree of compatibility.

For example, a Win32alacarte app supports all 18 DLL search mechanisms. It also doesn’t provide I/O virtualization. This is especially useful for older codebases that can’t run as Centennial apps, or can’t be migrated in a timely manner.

The spectrum of unpackaged compatibility to good citizen can be visualized as:

Compatibility ◄──────────────────────────────────────────────► Good Citizen
              ├───┬──────────────────────────────────────────┤
      unpackaged  Win32alacarte                             Centennial

Comparison

¹ The MSIX packaging platform originated as APPX in Windows 8 and has evolved substantially over time.

²See 3.1.5.2. Packaged Processes for more information.