Added version and manifest resources to the windows build.

cfehse commented 3 years ago

Scope

The scope is to add version and manifest resources for the created binaries on the Windows platform. Therefore the cmake integrated methods to detect and run the appropriate resource compiler for the chosen toolchain/platform is used. To build the needed version information the values in cconf.h are used respectively cconf.h.in is extended to provide the necessary defines.

What has changed?

Source Files:

CMakeLists.txt

Added a variable DIAG_TEST_PROGNAME to have defined names for both binaries.
The current version scheme uses a minor version with a leading 0. This leads to warning messages with the MinGW resource compiler windres.exe. So a pair of additional variables are introduced to build the version value for the version info without the leading zeros.
Turned off the autogenerated manifests for the MSVC compiler/linker.

scantool/CMakeLists.txt

On Windows define and add the resource scripts to the source lists and enable the RC language in cmake.
Use the defined program name variables from the main cmake file to define the executable names.

cconf.h.in

Populate the defines used in the resource scripts.
Moved these additional defines under the _WIN32 define because this is the only platform where they are needed.

freediag.rc freediag.manifest diag_test.rc diag_test.manifest

Added for both binaries a pair of resource scripts and manifest XML files. The resource script will include the manifest during the compilation process and assemble the data into the resource section of the PE binary.
The manifest files are the same for both binaries (this may change in the future). They request execution level asInvoker and signal compatibility for Windows Vista, 7, 8, 8.1 and 10 to the loader.
The version information uses a different format to define strings (due to that the additional defines were introduced in cconf.h.in) and defines all version fields from variables set in the main cmake file.

Tested Environments:

All changes where tested using these environments:

Visual Studio 2019 (x86/x64) (integrated cmake and cmake 3.19.3)
Visual Studio Code on Windows (MinGW, MinGW64, BCC, MSVC) (cmake 3.6.0 and higher)
Visual Studio Code remote on WSL (cmake 3.13.4 default installation debian)
Debian (cmake 3.13.4 default installation debian)

Perhaps you like the changes and accept this merge request.

Thanks!

@fenugrec @nsajko

fenugrec commented 3 years ago

Would those new manifests prevent a 32-bit build from running on XP ? If the effort is minimal like adding 1-2 lines, I'd like to try to keep XP as the absolute minimum requirement for a little while longer. Some people might still have old "garage" laptops running XP, and until now it hasn't required any special effort to keep supporting it .

All changes where tested using these environments:

Visual Studio 2019 (x86/x64) (integrated cmake and cmake 3.19.3)

Visual Studio Code on Windows (MinGW, MinGW64, BCC, MSVC) (cmake 3.6.0 and higher)

Visual Studio Code remote on WSL (cmake 3.13.4 default installation debian)

Debian (cmake 3.13.4 default installation debian)

Thanks for testing all those! I don't suppose I could convince you to help setup a CI / autobuild config to continuously compile and run the project ?

cfehse commented 3 years ago

Would those new manifests prevent a 32-bit build from running on XP ?

No the manifest do not prevent the binaries from running on Windows XP. There purpose is to prevent the Windows loader from "cheating and shiming" - which means no compatibility layers for system APIs are applied for the binaries with the appropriate manifest. The schema urn:schemas-microsoft-com:compatibility.v1 was introduced with Windows Vista. Windows XP will process the manifest but ignores that tag.

From my experience not including a manifest can under some circumstances (this is all not that well documented or explained) lead to very "strange" behavior of some Windows API calls - for example "false positive calls" calls that succeeded where they should fail - e.g. registry or file system calls where permission should have been denied and you end up with handles pointing somewhere in the wild. Over the last 10 - 12 years these manifest have helped me a lot. gg

What I just discovered is that the binaries build with Visual Studio 2019 will in fact not run on Windows XP. The included v142-Toolset (complier, linker) will produce PE images, that are no longer executable on Windows XP or earlier. This is independent from any embedded manifest (there was a change in the PE format starting on Vista a believe - cannot find the documentation right now - and the current MSVC tools create this newer version PE images). One can integrate v141-Toolset in VS 2019 but that's includes the older compiler which is not fully c99 or c11 complaint.

So the status for Windows XP is (just tested on my VMs)

Visual Studio 2019 builds will not run on Windows XP but will run on 7 and higher (I have no Vista VM anymore but I am pretty sure they run on Vista as well).
Both MinGW versions and Borland do run on Windows XP
The Borland binaries will even run on Windows 2000. The MinGW binaries not - they have a relocation error in the msvcrt.dll which could be cured but I tried it just for fun.

cfehse commented 3 years ago

I don't suppose I could convince you to help setup a CI / autobuild config to continuously compile and run the project ?

For this simple build system we have here that cannot be that hard. I take a look in my fork what to do to use the Circle CI provided here by github.

fenugrec commented 3 years ago

What I just discovered is that the binaries build with Visual Studio 2019 will in fact not run on Windows XP.

Ah, good to know. Thanks for the clarifications, I'll include some of your comments in the docs somewhere.

* Both MinGW versions and Borland do run on Windows XP
Excellent also - until now I've been using mingw to prepare the releases (which reminds me, I'm way overdue for a new release...)

fenugrec commented 3 years ago

merged in https://github.com/fenugrec/freediag/commit/d951f4c7d5795a5d94b3b5f87da3ffc7e2b4017f , thanks ! I opened #65 to discuss CI if you're interested.

fenugrec / freediag