Changed handleapi feature link library from kernel32 to WindowsApp to…

[angelortiz1007]

While doing builds of ipc-channel and using windows 10 api CompareObjectHandles() I received an unresolved message for CompareObjectHandles().

Reading Microsoft link: https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis I changed build.rs, handleapi link time library from kernel32 to WindowsApp.

After testing locally on my ipc-channel build and using my patched winapi v0.3.0 I removed the link time unresolved error and all ipc-channel tests passed.

… address/fix #781.

[retep998]

If WindowsApp.lib were linked to, depending on order in the linker many functions will end up resolving to various api-ms-win-core dlls rather than older dlls. For example GetLocalTime could end up coming from api-ms-win-core-sysinfo-l1-1-0.dll instead of kernel32.dll. This will absolutely break support for older Windows that do not have the api-ms-win-core dlls such as Windows 7.

If we had the raw-dylib feature then this would be a much easier problem to solve but unfortunately we won't for a long time.

I'm not entirely sure how to solve this issue, and for now my recommendation is to just load the function via GetProcAddress or a crate that wraps that.

[jdm]

Good to know that that's a possible workaround. Thanks!

[angelortiz1007]

The LoadLibrary() of api-ms-win-core-sysinfo-l1-1-0.dll followed by GetProcAddress() should work.

Obviously, if ipc-channel - which uses CompareObjectHandles() - is mondified to use LoadLibrary()/GetProcAddress() 1 test will still fail if ipc-channel is used on non-windows 10 systems.

[retep998]

Because this leads to other undesired changes, this PR cannot be merged.