Detect UWP environment and use its APIs instead of kernel32.dll
Fixes #700
I think it's great. I would just add a new UWP project to more easily test that platform, if possible. Thank you. I hope it will please both @migueldeicaza and @tig.
This is indeed great and I agree with @bdisp is there any simple way to test and use that scenario? Should we have documentation for the users on how to use this?
@migueldeicaza There is no extra effort required to use this. We pick the preferred bindings based on the environment. Win 10 and above use Win 10 SDK bindings, older versions use Win32 bindings.
A way to test this would be to have a copy of UICatalog defined as UWP app and built with .NET Native tool chain.
It would also be nice to test this on Win 8 but I can't find a VM anymore. Microsoft seems to have removed their IE test VMs and left only Win 10 here.
I think that just adding a solution with a UWP Console project that you already have at https://github.com/InvictusMB/TerminalGuiUwpInputBug and adding a reference to the Terminal.Gui project would be enough for users using this platform. Like the FSharpExample solution that exposes another type of language.
I am not very good at Windows.
So how does a console app determine that it can use the UWP APIs vs the Win32 ones?
So how does a console app determine that it can use the UWP APIs vs the Win32 ones?
Based on Environment.OSVersion.Major. If we are in Win 10 environment we use UWP APIs from Win10 SDK otherwise we stick to Win32.
However, as I've mentioned in #700 I'm not able to validate if using UWP APIs has any impact at all. So the real fix here seems to be only ReadConsoleInput marshaling.
I have no way to verify if there are any Win 10 environments where kernel32.dll is not available.
I also ran Windows App Certification Kit and got successful reports for both Win32 and UWP bindings.
@migueldeicaza Could you ask one of Microsoft gurus to enlighten us on this topic and benefits (if any) of using UWP bindings over kernel32.dll?
@clairernovotny points out that her https://www.nuget.org/packages/OSVersionHelper library provides the properties you need to check. The source is at https://github.com/novotnyllc/OSVersionHelper
The environment variables lie depending on the manifest for compat.
@KirillOsenkov @clairernovotny Thank you very much!
Could you elaborate if using these APIs has any benefits over consuming kernel32.dll directly or if it affects the certification for MS Store in any way?
So far I'm not convinced it does and therefore the version check itself might not be necessary.
Is it safe to depend on kernel32.dll directly and only verify that a given API is listed as available for UWP apps?
I think the store will block use of the kernel32... I had to do similar for SkiaSharp just to LoadLibrary.
https://github.com/mono/SkiaSharp/blob/master/binding/Binding/GRGlInterface.cs#L183
I cheated with UWP and created a uap dll, but this should just be a matter of checking the major version. Although, I believe it will still fail if that import makes it to the final package. Not sure if the linker knows to remove the extern.