Upgrade Windows projects to VS 2019

[ivan-mogilko]

Fix #2241

What's done:

1. Updating MSVS solutions is a trivial action, the solution and project files have same format, only few values change inside.
2. Updated PlatformToolset from v140 to v142, Windows SDK version from 8.1 to 10.0. I can at least tell that the compiled programs still work on Windows 7 with these settings.
3. As a separate change, I modified the env variable names in prop files to have "_VS19" postfix. The reasoning for this is to be able to keep both VS2015 and VS2019 version of the project, at minimum while we have to go back to fix bugs in previous release, or compare them. It may be convenient to have separate variables pointing to separate static library paths, where libs are built either with VS15 or VS19.
   Examples: AGS_SDL_SOUND_LIB -> AGS_SDL_SOUND_LIB_VS19, AGS_SDL_SOUND_LIB_X64 -> AGS_SDL_SOUND_LIB_VS19_X64.
   And alternative to this would be to use separate library names with "_vs19" prefix, for example.

TODO:

1. Find out which VC Redist should be included into installer.
2. Find out if "_xp" build configurations still work. The last PlatformToolset that has support for WinXP (it seems) is v141_xp related to VS2017, so that's one I set there. I have got a feeling that this may be removed in the newer/future versions of VS.
   OTOH, I do not think that winxp support is important at this point, as in all the time since it was moved to a separate config, not a single user have asked for this build.
3. Update CMake for Windows.
4. Update CI scripts (or should be done after this PR?)

[ericoporto]

As a separate change, I modified the env variable names in prop files to have "_VS19" postfix

Those are binary compatible - from VS 2015 to VS 2022. There is no need for this.

The last PlatformToolset that has support for WinXP (it seems) is v141_xp related to VS2017

I don't think this toolset is available in VS2022

Update CMake for Windows

I don't think these change at all

Update CI scripts

These have to be made before or this will break the builds. I need at minimum a week to look into these. The big thing here is the Windows Docker image that has to be redone.

[ivan-mogilko]

As a separate change, I modified the env variable names in prop files to have "_VS19" postfix

Those are binary compatible - from VS 2015 to VS 2022. There is no need for this.

I don't think it's related to Visual Studio itself, it may be related to switching a toolset from v140 to 142 and/or Windows SDK from 8.1 to 10.0. The engine refused to link with previously compiled static libraries. I might try again to be certain.
Unless you mean that the previous toolset and SDK should be kept?

[ericoporto]

Uhm, that is weird, I don't yet know until I test more things. Maybe is something C++ specific? Like, SDL2 we use in Windows comes from SDL binary releases and they use the latest MinGW - which I have no idea how it relates to the MSVC stuff, other than that it works?

Also in theory if building our dependencies using MinGW is better I can set it up like that.

[ivan-mogilko]

SDL2 is dynamically linked, that's a different thing compared to statically linking. When we link dynamically then only the public API must match. (For the same reason very old plugin dlls can link with the modern Windows engine.)

[ericoporto]

Hey, I asked a person that has more insight on VS development and they gave me the following information

You can mix VS 2015/2017/2019/2022 toolsets across OBJs, LIBs, DLLs, and EXEs, as long as you obey a couple of important restrictions:
The toolset used to perform the final link must be the newest toolset involved (or newer).
The VCRedist you run against (whether installed system-wide or app-local) must be from the newest toolset involved (or newer).
Full documentation: https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170
If you can upgrade all the way to VS 2022, that's ideal. Regardless of which version you upgrade to, the more libraries you can rebuild with the toolset, the better (as they'll receive correctness and performance fixes). Upgrading your WinSDK shouldn't be a problem for bincompat. (You will probably have to deal with source compat issues from the compiler upgrade, even with our /std:c++14 and permissive mode mitigations, as well as possibly from the WinSDK upgrade.)
VS supports targeting old systems, to a certain extent. VS 2022 has dropped support for XP/Vista targeting, as they are totally unsupported by Microsoft and not even receiving security updates for many years. (Chrome, Firefox, Edge, and Steam have all done the same thing.) I believe XP was actually dropped by VS 2019 mid-cycle when we stopped being able to sign SHA-1 certs. VS 2022 will continue to support Win7 for the remainder of its lifecycle but the next major version "Dev18" will increase the minimum system requirement to at least Win8 and possibly Win10 (no further for sure though).

I guess the Dev18 is the future VS2025. I asked about the use of multithread flag (/MT). I also mentioned about the desire of Win7 compatibility

Yeah, static linking (/MT) is totally self-contained, and is a good option if your application is monolithic.
To clarify, VS 2022 17.x will support Win7 throughout its entire lifecycle, so that’s not a reason to stick to VS 2019.

I guess I can use VS2022 on the CI and it should work with the VS2019 projects while keeping the desired compatibility. But I think WinXP and Vista are out.

[ericoporto]

@StephanTLavavej (the person I mentioned in the previous comment) gave me a nice reference for the Win7 support being kept in VS2022 (17.x) and removed only in next version (Dev18): microsoft/STL#4857