BRICK WALL AFTER BRICK WALL, INFINITE LOOP EDITION
The cause ended up being simple. This library is part of the windows SDK beginning with version 6.1 but my VS 2008 install gave me 6.0a that does NOT support 64 bit fully. The solution took a while to sort out.
When I installed Service Pack 1 onto my VS 2008, I found that it did not give me 6.1 but did enhance things a bit in the SDK. That, however, did not include bcrypt.lib so I had to look elsewhere. Microsoft does not provide older SDK like this one online and I had the hardest time hunting down a copy that I could install. I have to fault the SoftDevLabs build instructions for Hercules on Windows as they do NOT describe this as a pre-requisite but it definitely is.
I decided to leapfrog to the Windows 10 SDK and install it on my system, then provide the path to VS2008 in the desperate hope that it would allow a build to complete and then have a version of Hercules that works properly. Like all other Windows products, this bloatware took an eternity to install.
I then had to modify the search path for lib files in VS2008 for my project and try once again. Fail! After searching there is no bcrypt.lib in the Windows 10 SDK. More hunting on the web, where I found a hint that it is instead included in the Windows Driver Kit (WDK). Grrrrrrrr. I located and downloaded WDK 7.1.0 - another heap (860MB) of bloatware chewing up bandwidth, disk space and precious time.
The damned file wasn't there! Recycled that and hunted some more. I found a github project that had the file as part of it, inside its win32 section which probably means that this is the 32 bit not the 64 bit version, but I nonetheless downloaded it and stuck it in the project folder.
I once again tried to point VS 2008 at the library section and complete the build. I got much further but failed with unresolved references to BCryptGenRandom, BCryptOpenAlgorithmProvider and BCryptCloseAlgorithmProvider which are all functions in the bedamned bcrypt.lib file but clearly not in the version I downloaded.
Time to massively capitulate and install an even more bloated product (2GB or more, more than 320 packages) - VS 2019 Community - in the increasingly desperate hope that I can find a workable bcrypt.lib file for 64 bit code.
More tomfoolery. I try to build the project but immediately receive an alert that I need to install SDK 7.1a first. Another search, another download and install. What fun. Included an iterative error that I needed a new .NET 4 Framework before I could add the SDK before I could use VS2019. Another 137MB of crap. Another delay.
Found that I had installed the developer framework, but that wasn't what the SDK wanted. It wanted the run time version. Delete, search, download, install. Complains that .NET 4 is installed already. Delete it but still get the error. Reboot f**king windows.
SDK installer fails to work because it sets up an invalid path for install - superficially looks okay but not valid. Overrode it and it still failed to load ANYTHING. I am not the only one to find this Keystone Kops comedic behavior, but the solutions involve things like Registry key overrides after swapping permissions. Can't Microsoft do anything right? Sheesh.
Once I gave myself ownership and full control to the registry key entries, I modified the .NET framework version to the single value that the SDK installer believes is valid - 4.0.30319 - and then ran the installation successfully. Once done I had to reset the versions to the proper 4.8.03752 version and unwind the permission changes. Still failed to install anything.
I hunted down the SoftDevLabs web pages where they discussed how to get Hercules to build using VS 2019. They point me to an optional installation feature in VS 2019 that creates the win32.mak file that the older code needs, without having to run the SDK installer at all. Thanks Microsoft.
In fact, this did install SDK 7.1A although it is labeled as a deprecated support for Windows XP on the VS 2019 installation option list. I find that it has everything I need - bcrypt.lib in both 32 and 64 bit versions, as well as the win32.mak file that nmake needs. I have finally been taught the secret magic spell that solves the problem, I think.
There are a couple of environmental variables that had to be added and a configuration choice changed in VS2009, but once those are done it is rumored that I can build Hercules at last. The environmental variables were easy, but the two property sheets weren't found.
I suspect that the compiler somehow wasn't installed, so back to the VS 2019 installer once again. I found a subtle optional feature along the lines of C lang support which was not selected in spite of my having picked the major choice of C++ Desktop Development. I don't see how you can do that without a compiler. Added the compiler in, since it only tied up another 830MB of space and burned 40 minutes.
Still no property sheets. I searched everywhere for them on my disk. Must be another 'optional' feature that I need to select, so back to the installer once again. I never did find those property sheets either by name nor in the directories they specified, but I found a way to update the include path in VS2019 itself.
I brought up VS 2019 and attempted, yet again, to build Hercules. This time it ran to successful completion. Finally! I I fired it up and verified that it appears to work properly. Now it is time to move it over to work with my MVS 3.8J system.
REPLACING MY CURRENT HERCULES WITH THIS VERSION
When I downloaded the turnkey MVS 3.8 image it came with a copy of Hercules installed in its folder tree. I had to figure out what to disentangle, store the old version safely elsewhere and put the newly built Hercules in the turnkey folder location.
I copied the original folder elsewhere, then moved the executable files from my build into the Hercules spot in the MVS 3.8J turnkey site. I fired up Hercules and it seemed to work okay. It was now time to run a more complete test to be sure that I didn't foul up something in the build.
VERIFYING HERCULES OPERATION USING TERMINAL EMULATOR SOFTWARE
Up came the system, I connected by Vista TN terminal emulator software to Hercules successfully, and attempted an IPL of drive x148 which is the SYSRES volume of MVS. It failed, but for a legitimate reason - the disk volumes are compressed using ZLIB but I didn't configure that into my build.
Therefore my next task is to build or grab ZLIB, then do a rebuild of Hercules. I will attempt this tomorrow, as I have burned the entire day and more fighting with Visual Studio in its several guises. I consider this a successful stopping point for tonight.
GOING TO HAVE TO GRAB A VERSION OF HERCULES WITH THE BSC 2703 CODE
Since I have learned that the SoftDevLabs version of Hercules doesn't work well with the SyncDongle designed by Mattis Lind, I can't use the code I created for the SDLC link. Instead, I have to secure a Hercules image for the BSC link, one whose 2703 emulation code works properly for BSC.
No comments:
Post a Comment