ultra_code

(I will update this original post with updates and other things over time when necessary) Introduction "Who is this guy? HFSLIP 1.8? Did he do anything new? Any improvements? What spurred this development on?" Let me introduce myself a bit - I used to be somewhat active on VOGONS, but slowly moved away from retro PC building per se onto overclocking, which includes overclocking retro platforms. I'm not the most experienced programmer, but I have a good enough grasp of things. And, I like challenges. As of late, I wanted to create fully-updated ISOs of different versions of Windows (with official updates at least for now), and back in July-ish of this year I thought I would start with Windows 2000. HFSLIP was going to be the tool I used... but the way the program was left by @evgnb in 1.7.11 (practically non-functional for 2000) left more to be desired. The Work I decided to go through carefully throughout the entire script, revert decisions made by @Acheron somewhere in 1.7.10K and @evgnb in 1.7.11 back to how things were in @tommyp's original 1.7.8 (a version of the original HFSLIP I could find) and later @tomasz86's HFSLIP2000 (which my guess is a fork of Acheron's 1.7.10K before he made some crucial changes in the code that broke things in 2000) while of course keeping improvements made by said authors, homogenizing the formatting and syntax of the code (i.e. cleaning and reformatting the code), fixing a couple of bugs/logic-based issues, and writing fairly extensive documentation on the code (more like various breakdowns of how the code is structured than explanations on how particular things work). Mind you, the majority of testing/focus was aimed at making sure it "worked" for Windows 2000, with XP and 2003 not really a concern. Perhaps the changes made by later authors are better suited towards XP, but at the cost of 2000 compatibility. Moving forward, compatibility with all OSes should be maintained. At this point, though, I'm "done" working on HFSLIP for now. My mission was getting it back to a working-enough state, and that's done. I'm not knowledgeable enough to understand how everything works, and not smart enough to add new game-changing features. My hope is that I have at the very least brought HFSLIP out of a less-than-ideal state into a more agreeable one and made it so if someone wants to continue this project they are in a better situation to do so. I would like to act as the overseer of new additions and changes to the script, but I do not want to personally contribute anything new as of now. Conclusion What did I get out of this project? Well... nothing really, actually, besides a better understanding of how annoying legacy batch scripting can be (surely Powershell is 10x better, if not a bit more verbose/boilerplate-ty). For now, I still don't have a fully-updated ISO for 2000, because the specific order of how I want updates to be installed isn't supported in HFSLIP yet (a specific WMP 6.4 update, KB954600, should ideally be installed prior to the installation of WMP9). As for XP, well, I just don't use HFSLIP for anything. Instead, I use WMP11Slipstreamer, RVM Integrator, and nLite for getting in all the updates I want, and then manually install the latest DX9C redist and all supported .NET versions post-setup. Contributing and Download If you would like to make changes, please try to keep things in the style I have it (there are more specific guidelines laid-out in the script itself) and run them by me here or in a DM, so then I can add them to the script and reupload it. Obviously how HFSLIP is currently being distributed is not ideal, so if there's traction I'll upload it to GitHub. If there's ever a point where the script crashes, most likely it's because I missed a space somewhere, usually between an IF statement and its following parentheses, or esoteric batch parsing behavior. Testing of the script was originally mainly done in a Windows 7 VM once I learned of some of the weaknesses of the NT 5.x environment, but currently all testing is being conducted under a Windows 8.1 VM. I have left a bunch of TODOs throughout the script for an intrepid developer to investigate and comments of my own, some of them just denoting what code of @evgnb's I reverted. I have also included prior versions of the script and my documentation in separate folders. Here's the download link from my mega account being used for something for once : https://mega.nz/file/hJ8gQDTZ#JA_-tIBNr8wveT9Z-Imyy6hrHwkzA9BmWeJmvkX5X1g The password is "beta" - I encrypted the zip file so that there's less-likely a chance for your AV to flag/remove the file cmdow.exe from the HFTOOLS directory, although if the ZipCrypto algorithm provided by 7-zip is not enough, I will instead use the AES-256 algorithm for future releases. Ideally someone reimplements @evgnb's ideas left in the code to remove the need for cmdow.exe so this isn't a problem anymore. I would recommend running this script in a VM, disabling UAC, running it from an Admin prompt, and piping text output normally sent to the console to an output file defined in HFANSWER.ini in HFTOOLS (this consistently reduced the run time of the script by over a minute from over 3 minutes to under 2 in my test cases). Final Thoughts I have gotten the feeling working on this project that NT 5.x slipstreaming is more of a hack than an semi-official method for adding updates pre-installation as is the case with NT 6.x and later (Vista+). There are several different utilities for slipstreaming different updates/components into NT 5.x, and I think perhaps they do better jobs at their niches than HFSLIP does. Thus, the big issue is that there is no one program that covers everything for NT 5.x (like NTLite is these days). Thanks to @Tomcat76 for humoring me.