The value in _X_REQUIRED_WINDOWS_BUILD normally forces a fetch of the
latest windows_build components that are available. This value might
not be updated before the local system's Visual Studio tool chain is
updated. When this Visual Studio is a version that isn't supported by
the locally available windows_build, it is worth checking to see if
windows_build has already been updated to support the newest Visual
Studio version.
- windows-build now supports the latest Visual Studio 2022 17.14.3
Fix: #1216#1216 reports problem with 17.14.2, but MS had already released 17.14.3
as of 5/28/2025, so that version is what is now supported.
This whole array VS2022 problems comes from the fact that Release
builds of certain static libraries are rejected at link time as
incompatible with those libraries produced by any prior Visual Studio
version. This problem has existed for a very long time (going back to
at least VS2017). The earlier strategy implemented with simh builds
was to not support the latest Visual Studio tool set until it stopped
changing. That was sort of OK when Visual Studio versions changed
every 2 years, but since VS2022 was dragging on with frequent changes
support for intermediate versions was added some 3 years back.
- Pre-Pre-Build-Event.cmd now dynamically determines the available
compiler version along with any alternate toolset which may be part
of the build environment and makes the appropriate windows-build
library support available for linking.
- build_vstudio.bat now supports VS2022 and will dynamically adjust
the converted VS2008 project files to leverage any available XP build
support which might be installed so that the generated executables
will support all versions of Windows from XP onward. The VS2008
generated executables automatically support all versions of Windows
from XP onward.
When git is available, remove manual steps to maintain and update the
windows-build support even for cases where windows-build may have
previously extracted from a downloaded zip file.
Some git capable environments on Windows don't honor the installed git
hook scripts in the repository. Now that, if we're working within a git repo,
we force a working version of git to be installed in the runtime path. We
leverage that to force a validation of the commit id on each build.
- All projects use identical include directories, library definitions and
library directories.
- Remove attempts to add XP support to projects that were converted to
.vcxproj for post VC2008 versions of Visual Studio.
- Require that git be available when building within a git repository
working directory.
