This started as a change to upgrade the compiler to Visual Studio 2022.
Background
Although Winfile doesn't need it, Microsoft requires projects to use supported toolchains in our build environment. For now using Visual Studio 2019 is fine, but at some point projects need to move forward. I initially hoped to do this before a release, but looking at the changes now it seems better to wait until afterwards.
Intentional changes here
Upgrade the compiler to Visual Studio 2022
Change the SDK version to 10.0.whatever. Currently Winfile won't work with the oldest 10.0 SDKs, due to missing reparse tag definitions; but any SDK that is installed by Visual Studio 2022 should be fine. The real motivation here is to let people develop with whatever tools they have, since Winfile doesn't really need the latest-and-greatest.
Share build settings. Visual C++ by default duplicates build configuration into each binary/architecture/configuration. This repo has 5 binaries, 3 architectures, and 2 configurations, so things like compiler version would be specified 30 times. This change stores it once in property files that are used by all binaries, and attempts to apply architecture specific or configuration specific things once too.
Remove a lot of preprocessor defines. Some of these, like the _M_ family, should be automatically set by the compiler. Some of them didn't appear to be used.
With one set of build settings, some of the tools are compiled with different options. Most notably, with stdcall. That required some explicit cdecl changes around main.
In Winfile.vcxproj, stack size and control flow guard were set by passing arguments to the linker. This change uses the MsBuild XML representation instead, so the linker arguments don't need to be customized.
This started as a change to upgrade the compiler to Visual Studio 2022.
Background
Although Winfile doesn't need it, Microsoft requires projects to use supported toolchains in our build environment. For now using Visual Studio 2019 is fine, but at some point projects need to move forward. I initially hoped to do this before a release, but looking at the changes now it seems better to wait until afterwards.
Intentional changes here
_M_
family, should be automatically set by the compiler. Some of them didn't appear to be used.stdcall
. That required some explicitcdecl
changes aroundmain
.