Support for Windows 7

[kennykerr]

A number of projects need to support building a single binary that can run on Windows 10 all the way down to Windows 7. Strict requirements are placed on what these binaries may do to achieve this and the only mechanism that is allowed for light-up of features is LoadLibrary/GetProcAddress. Notably, the Anaheim (Edge) browser team need to use C++/WinRT but require this capability as they have a very rigid build system and cannot change the way the browser is built or add any new dependencies. All of their light-up must happen via LoadLibrary/GetProcAddress.

In order to support Windows 7 in this way, C++/WinRT is being updated to avoid linking to any Windows 8+ API functions directly. For example, the RoOriginateLanguageException function is now loaded via LoadLibrary/GetProcAddress and if that fails a fallback is provided. This works for all Windows 8+ functions with the exception of hstrings where performance necessitates an inlining of the hstring implementation. As C++/WinRT has done in the past with WinRT implementations like generic GUID calculations, C++/WinRT now includes a Windows 10 compatible implementation of hstring support that is inlined into the base library and can thus run down to Windows 7 without hurting Windows 10 performance.

This also includes support for reg-free activation, not only on Windows 7 but also on Windows 10 without requiring a manifest or package identity. If OS activation (via RoGetActivationFactory) fails to find the requested factory or this function fails to load because you're running on Windows 7, then C++/WinRT attempts to use LoadLibrary to load the factory. As an example, if the class Microsoft.Kitchen.Spoon is requested then C++/WinRT will attempt to load Microsoft.Kitchen.dll and if that fails it attempts to load Microsoft.dll. Provided the DLL exports the standard DllGetActivationFactory function required of a WinRT component DLL, activation will work automatically.

[MikeGitb]

Is there a performance regression expected when targeting Win10? If so, are there any benchmarks in place to quantify it?

[kennykerr]

Is there a performance regression expected when targeting Win10

No. Thanks to inlining of hstrings the performance on Windows 10 is at least as good as before (slightly faster in fact). The functions that are loaded dynamically are all in slow paths (e.g. error handling or behind the factory cache) where it doesn't matter.

[MikeGitb]

Great to hear thanks.

[DefaultRyan]

This project has reached the point that I think we need to beef up our testing strategy. Specifically, we need to figure out how to run our tests on multiple OS versions, like Win7, so that we have an automated way to ensure we don't break compat going forward.

I'm not going to block my review on this, but this should be strongly prioritized and done soon.