All External Packages were updated to provide VS2022 support (via a minor update to vstool.cmd), and as a result, have been rebuilt so that Hercules's reported "HHC01417I Built with..." messages for each now accurately report their actual current repository version.
This is actually just a "cosmetic" update since none of the actual logic of any of the External Packages has actually changed. Only the version strings have changed. Not the actual logic.
This should be a cosmetic change for those who build the External Packages themselves.
For those who don't however (i.e. for those who build and link Hercules with the default ExtPkg lib files that come pre-delivered with the Hercules distribution, this should update all ExtPkgs to their latest and greatest version.
Due to a recently discovered CMake build script bug in the External Packages, the actual cpu architecture of the resulting static libs were all the same (i.e. the so-called 32-bit libs, named libcrypto32.a, libdecNumber32.a, libSoftFloat32.a and libtelnet32.a, were actually 64-bit, not 32-bit).
This commit is to simply update all of the extpkg libs with the latest version, which, having now all been built with the fixed CMake script, are now all for the correct cpu architecture. (Only the *nix '.a' static libs were affected, but I'm committing new versions of all of the Windows VS2017 '.lib' files too in order to pick up the new "HHC01417I Built with..." version strings.)
Previously, I was distributing the VS2008 version since that's the version of Visual Studio that I use. But that causes problems for most others who try building Hercules for themselves since most everyone else uses VS2017 (and the VS2008 Debug static libs I was distributing won't work when trying to debug Hercules using VS2017; see GitHub Issues #104 and #106 for example).
Therefore I am now going to start distributing the *VS2017* version of the External Package static libs instead, which makes it much easier on most everyone else since now all they have to do is download Hercules and build it, PERIOD! They now no longer need to build any of the External Packages at all. I've already done that for them.
The burden is now on *ME* to build my own special VS2008 versions of the External Packages for myself, since I'm the "odd ball" that's still using VS2008 and not VS2017. (Why burden others with my own eccentricities after all?)
1. Each package's extra install files are now unique. This allows all external libraries to be built and installed into the same directory.
2. The EXT_PKGS.msvc makefile fragment has been tweaked to support easily overriding the Hercules default of linking with its own distributed static link libraries to linking instead with your own custom external package static link libraries instead, by simply pointing your "LIB" environment variable to where they are. That is to say, Hercules will now link with YOUR external package static link libraries instead and not its own, as long as your "LIB" environment variable points to where they are.
This makes it easier to override Hercules's distributed default libraries with your own instead, without modifying Hercules's defaults. Hercules's default libraries will now remain untouched if you install your overrides into a separate directory somewhere and simply point Hercules to that directory via the "LIB" environment variable. Doing so now causes Hercules to link with your libraries instead of its own, thereby allowing its distributed default libraries to remain untouched (and Hercules will now report a "clean" version number too (just xxxx), instead of "xxxx-modified" as before).
As of this commit it is no longer necessary to manually build the "Debug" version of any of the external packages if you wish to build a "Debug" build of Hercules. For both normal Release builds as well as for Debug builds, just build Hercules normally just like always.
Move selected functionality out of the Hercules proper and into separate externally built and maintained External Packages, keeping only the resulting static libs.
This is an initial proof-of-concept commit that moves decNumber and SoftFloat out of Hercules and into separate externally maintained repositories. Hercules now only links with the resulting static lib files, thereby reducing Hercules's overall code footprint making it easier to build and maintain (i.e. making it more "nimble").
Other functionality is envisioned to eventually be moved out of Hercules and into separate "External Package" repositories as well (such as the channel subsystem and device emulation for example), eventually reducing Hercules down to its core functionality: accurate emulation of the core architectural instruction set.
The "HQA" commit introduces a new build feature that provides the ability to override Hercules's default build settings without having to modify any of the Hercules header files themselves. (Note: not all build settings may be overridable yet. This is a work in progress.)
To override Hercules's default build settings, define an environment variable called 'HQA_DIR' pointing to the directory where your optional "hqa.h" overrides header file exists, or, instead of defining an environment variable, simply specify, if Linux, the new "--enable-hqa" configure option, or, if Windows, the new "-hqa" "makefile.bat" option.
Then, within your "hqa.h" override header, either #define the 'HQA_SCENARIO' macro to one of the pre-defined values defined in Hercules's "hqadefs.h" header file, or simply #define your own scenario. The values you #define will then override Hercules's default values.
Additionally, on Windows, you can override virtually any of the compiler settings as well, via a 'HQA.msvc' nmake !include override file that, for example, modifies the $(cflags) variable to add, remove, or change whatever compiler option you wish.
Fish (David B. Trout)
Enrico Sorichetti
Enrico Sorichetti
Fish (David B Trout)
Paul Gorlinsky
Roger Bowler