Windows: Firebird 3.0 installer build fails due to hardcoded msvc_version = 10 in FirebirdInstall_30.iss

[tomneko]

Windows: Firebird 3.0 installer build fails due to hardcoded msvc_version = 10 in FirebirdInstall_30.iss

Description
When building the Windows installer for Firebird 3.0 (B3_0_Release branch),
the process fails for two independent reasons:

1. FirebirdInstall_30.iss always assumes MSVC 10
2. BuildExecutableInstall.bat uses a hardcoded GNU md5sum path

Both issues prevent the installer from being generated on a modern Windows build environment.

1. Hardcoded msvc_version = 10 causes Inno Setup to fail
   FirebirdInstall_30.iss contains the following line:

#define msvc_version 10

This forces the installer script to run the VC10‑specific code paths, such as:

• looking for msvcr100.dll
• expecting vccrt10_Win32.msi and vccrt10_x64.msi
• attempting to include VC10 runtime files in the installer
  However, Firebird 3.0.x is built with MSVC 15 (Visual Studio 2017 or later),
  so none of these VC10 runtime files exist in the build output.
  As a result, Inno Setup stops with errors like:
• msvcr100.dll not found
• vccrt10_Win32.msi not found
• vccrt10_x64.msi not found

Proposed fix
Set:
#define msvc_version 0

This disables all VC10‑specific #if blocks, which matches Firebird 3.0’s design (no bundled MSVC runtime).

2. BuildExecutableInstall.bat fails before reaching Inno Setup
   The batch script contains:

%GNU_TOOLCHAIN%\md5sum.exe ...

This fails on systems without a GNU toolchain installed,
preventing the installer build from even reaching Inno Setup.
Proposed fix
Use the existing abstracted MD5 command:

%MD5_COMMAND% ...

This aligns with the rest of the Firebird build system and works on standard Windows setups.

Result after applying both fixes

• x86 and x64 installers build successfully
• No missing DLL/MSI errors
• No md5sum.exe dependency
• Behavior matches Firebird 3.0’s actual MSVC15 build environment
• Changes are minimal and isolated to Windows installer scripts

[tomneko]

The original submission had two parts. I’m closing part 1, but leaving part 2 active.

I realized that automatically collecting the VS2010 runtime in a VS2022 environment is quite difficult, so handling it manually is the more practical approach. I assume this is how others are doing it as well.