The official MS documentation states...As such I provided an implementation using the new system. The old implementation is supported but intended to be eventually removed.
But since we are going to support OSes not having the new API, there is no point in implementing the new for a handful of developers compiling Simutrans themselves, while the world at large uses something else. In fact, it may run against itself, because they will not notice if something is wrong with the old API that everyone else is actually using. Had it been a runtime switch, it could have made some sense, but Microsoft has so far never removed an API. Windows 10 happily detected that one of the games I had used DirectPlay, and automatically installed it without complaining. 32-bit Windows still supports the 16-bit Windows API from the 1980s, and while just taking the source code for such a program and compiling it with Visual Studio 10, it probably won't be API differences that cause compilation to fail (if the right typedef-ed types were used, at least).
If what you say is true then possibly the old registry implementation can be discarded. (since anything after 2000 supports the SHGetFolderPath implementation).
At least the GDI build no longer supports non-NT, since it uses the Unicode API and we no longer link against unicows, and I think NT 4.0 would be a very rare find on the home market. And again, since you wrote compile time switches, only the oldest code would be used for our releases anyway. The newer code would just be wasted. I don't think there is much point is confusing the players even more with releases for different Windows versions. Having both GDI and SDL seems to cause enough trouble, as they have no idea what they downloaded when seeking technical support.
From what I have read NTDDI_VERSION is the newest version macro and it does everything including specifying specific service packs (important as they add support for some features). Although still used _WIN32_WINNT is deprecated now and is checked for consistency with NTDDI_VERSION (they both should match). WINVER is obsolete, it is (or should be) automatically set based on _WIN32_WINNT for legacy support.
I don't understand what Microsoft is up to with all these version macros. The distinction between WINVER and _WIN32_WINNT I get, because there were two pretty different implementations of WIN32 in the 1990s, but what's this NTDDI_VERSION. The name NTDDI doesn't make any sense to me. When I first saw it, I thought you had been confused and used one of the macros for the DDK (driver development kit). Maybe they felt they couldn't use a name line _WIN32_WINNT anymore because the concept of Windows NT is slipping into the mists of time, and because they plan to deprecate the entire Win32 API (and native code in general).
Could people better explain the relationship of Simutrans with MinGW? I mean I thought the nightly servers were Linux but were linking for Windows. If they are Windows servers why can they not use MSVC compilers for the build? Or is it that they need that support to build the Linux builds from Windows?
Prissi has explained to Simutrans is properly built with GCC on all platforms, because the handwritten assembly deemed necessary for performance uses GCC syntax. A Linux build server can cross compile for all supported platforms, or at least the three major ones, using GCC, though that may be a nice consequence rather than by design for all I know. I'm not sure what OS the nightly build server is, but if there is only one (most likely), it probably isn't Windows, as setting up cross compilers there isn't as easy. (You have to use cygwin, I guess. I don't know how it's package manager is or how up-to-date it's packages are.)
Some of the developers also don't like IDEs, and Microsofts compiler toolset is not as powerful on their own as the GCC toolset is (especially make is stuck in the 70s or 80s), but I don't know if they use Windows at all, so that point might be moot. And historically, Visual Studio didn't have a free version that could make proper executables. (I remember the first I ever knew was only Visual Basic, and could only make ActiveX components.)