ultra_code

(I will update this original post with updates and other things over time when necessary) GitHub page: https://github.com/TheUltraCode/ReSNM --- Brief Introduction I already did a pretty-thorough write-up on the GitHub page, so I'll spare a lot of details here. After my work on HFSLIP 1.8, I was curious if I could improve SNMsynth too, so I started work back in February of this year (2026). The final result is ReSNM. ReSNM is a Windows batch script meant to create customized .NET 1.1, 2.0 SP2, 3.0 SP2, and 3.5 SP1 installers targeting all 32-bit NT5 OSes (Windows 2000, XP, and Server 2003). It can process all updates and language packs meant for each version (including Service Pack 1 for .NET 1.1), and output self-extracting installers as well as T-13 and RunOnceEx add-ons meant for use in nLite and RVM Integrator. The first iteration of the script called SNM was authored by @Tomcat76, and supported up-to .NET 2.0/3.0 SP1 and 3.5, ending development in 2008. When Tomcat76 stopped development, @strel picked-up the torch, renaming the project to SNMsynth and adding support for .NET 2.0/3.0 SP2 and 3.5 SP1, continuing development until 2010. Finally, @Zilver (with the help of @gora) released a minor update to SNMsynth in 2013, but development never picked-up in earnest after strel. Biggest Changes Compared to SNMsynth Here's a quick run-down of the biggest changes made in ReSNM: Massive refactoring while improving/fixing existing logic. Standardized processing as much as possible between different .NET versions. Removed dependency on Oleg Scherbakov's third-party "7zSD.sfx" file, instead now uses official 7-zip one. While features like a hidden console are lost, we benefit from all of the advancements made by 7-zip in the past 15-years, as well as avoiding anti-virus false flags. Rewrote part of the created "INSTALL.cmd" script to support 4 flags/parameters and be more dynamic. The exact number of parameters supported is arbitrary and can be easily changed. Added requirement of text files that list the order in which updates are applied. This was one of the first changes I made to SNMsynth. Added requirement of "\HFXS" and "\MSTS" directories. Keeping things orderly. Mandate latest Service Packs for each .NET version. This allowed me to shrink the codebase. Considerations and Credits There are still questions I have regarding some of the code inside ReSNM, so if you are interested in helping me check out the TODO's I left inside the script. I also have left plenty of comments scattered all around the code to help you understand it better. Thanks to Tomcat76 for creating the original script, and strel, @YumeYao, and all those who contributed to this project prior. Older Download Links If you are curious about looking at the older versions of SNM, here are links to where you can find them: SNM (original by Tomcat76) SNMsynth (updated fork by strel) SNMsynth (2013) (update by Zilver & gora)

I've now posted my work to GitHub. Links in the first post.

(I will update this original post with updates and other things over time when necessary) GitHub Release! (Aug. 7, 2025) I've made a few changes and now released everything to GitHub! No more "beta." https://github.com/TheUltraCode/HFSLIP_1.8 https://github.com/TheUltraCode/HFSLIP_TOOLS --- 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 (deleted beta; refer to GitHub page) 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.