Craigwi use 2019 toolset

[craigwims]

Prepare for release using internal Microsoft built pipeline, which requires 2019 toolset and some specific settings.

@schinagl, can you review?

[schinagl]

I compiled with recent VS2019 build tools and SDK 18362. Did a quick smoketest in rel/dbg x86/x64 ==> Fine

During compilation and checking the diffs a few things came to my mind

• VerifyResources does not compile in x64
• The version number is still 10.1.4.0. Should it be already 10.2.0.0?
• Debug|Win32 has no /guard:cf : <AdditionalOptions>/stack:15000000 /guard:cf %(AdditionalOptions)</AdditionalOptions>. ok?
• Release|Win32 has no /guard:cf : <AdditionalOptions>/stack:15000000 /guard:cf %(AdditionalOptions)</AdditionalOptions>. ok?
• We dont't need the ControlFlowguard on Exeviewer, VerifyResources, FileSignatureInfo, AddOnSample to make it through the build pipe?

Little limitations of my review

• I can't run it on a ARM Hardware, but I suppose this will work. @all: Is there someone who can give it a smoke test on ARM?

[craigwims]

Thanks @schinagl. VerifyResources doesn't need to compile x64 and I won't be building any of the extra tools in the offical build pipeline. I changed the version number as you saw.

Due to the lack of internal documentation and there being no local build to verify the settings I had to try different combinations until I got success. Win32 uses SEH; x64 uses Control Guard. I could probably remove the <ControlFlowGuard>Guard</ControlFlowGuard> in ClCompile for Win32.

I will confirm the above and create builds to verify.

[schinagl]

Perfect☺️

[malxau]

Is there someone who can give it a smoke test on ARM?

I guess that's me.

Firstly, note that the "ARM" architecture is basically legacy as far as I can tell. Any new ARM device today is ARM64; ARM was for Windows RT, which doesn't officially support Win32 applications. As in, AFAIK, the set of devices that can run WinFile ARM but not ARM64 is zero.

The result of the smoke test is that the binary doesn't run because it's missing vcruntime140.dll et al, the ARM(32) versions of those DLLs are not included in the ARM64 redistributable package, and there's no public ARM32 package (see http://aka.ms/vcredist ). They are included with the compiler, so it's possible to copy files around and execute, but this seems like it will cause problems for users.

I pushed a change that renames ARM to ARM64, and I think we should do something along those lines: https://github.com/malxau/winfile/tree/arm-to-arm64

Some notes:

• This change also sets the SDK to 10.0 (so it can build on my system with 19041 but not 18362.) That's a separate change so I'd understand if people don't want to take it, but it sure makes my life easier.
• I don't have the infrastructure for Store packaging, so the Package.wapproj changes are not tested. See in particular the change to AppxBundlePlatforms.
• Some of the tools weren't previously building as ARM32, and this change doesn't add ARM64 for those (although it should.) Also, as you two hit, VerifyResources doesn't compile as 64 bit and doesn't compile as ARM64 for the same reasons.
• In general ARM64 should have the same configuration as x64. The x64-on-ARM64 layer is implemented using a single set of DLLs with import trampolines, which requires the API surface to be almost identical between the two.
• This gets it out of the business of WOW64 redirection, since ARM64 is the native system architecture.

[craigwims]

yes, let's move to ARM64 without the SDK change (for now).

[craigwims]

The builds work as noted in the upcoming release issue #356.