jimmsta

As for Windows Installer 3.1, as long as you slipstream KB893803, you'll have it in the source, which will allow you to slipstream .NET 2.0. Personally, I prefer using RogueSpear's .NET packages, which I put in the GUIRUNONCE folder, and works perfectly for me - Available here: http://www.doitrightconsulting.net/forum/. Integrating applications... You can use some addon application packages - take a look at the advanced features - http://hfslip.org/extras.html. You can use nLite with HFSLIP - Just grab the files in this thread: http://www.msfn.org/board/Utility-Collect-...IP-t105761.html And copy the contents of NEWBIN.TXT into nLite's KEEP files in the Removal dialog. I've used nLite to remove the Windows Tour, and MSNExplorer, to save on space where I needed drivers and couldn't fit it all on a dvd due to system constraints (i.e.: no dvd drive). Worked fine for me.

I've been using the following files in my hfexpert folder: Files in your HFEXPERT folder: C:\XPHFS\HFEXPERT\STORAGE\a320mgt.cat C:\XPHFS\HFEXPERT\STORAGE\a320mgt.inf C:\XPHFS\HFEXPERT\STORAGE\a320raid.cat C:\XPHFS\HFEXPERT\STORAGE\a320raid.inf C:\XPHFS\HFEXPERT\STORAGE\a320raid.sys C:\XPHFS\HFEXPERT\STORAGE\aac.cat C:\XPHFS\HFEXPERT\STORAGE\aac.inf C:\XPHFS\HFEXPERT\STORAGE\aaccin.dll C:\XPHFS\HFEXPERT\STORAGE\aacevt.exe C:\XPHFS\HFEXPERT\STORAGE\aacmgt.inf C:\XPHFS\HFEXPERT\STORAGE\aarich.cat C:\XPHFS\HFEXPERT\STORAGE\aarich.inf C:\XPHFS\HFEXPERT\STORAGE\aarich.sys C:\XPHFS\HFEXPERT\STORAGE\aichmgt.cat C:\XPHFS\HFEXPERT\STORAGE\aichmgt.inf C:\XPHFS\HFEXPERT\STORAGE\DriverLanguageMap.xml C:\XPHFS\HFEXPERT\STORAGE\hraidsk1 C:\XPHFS\HFEXPERT\STORAGE\iaahci.cat C:\XPHFS\HFEXPERT\STORAGE\iaahci.inf C:\XPHFS\HFEXPERT\STORAGE\iastor.cat C:\XPHFS\HFEXPERT\STORAGE\iastor.inf C:\XPHFS\HFEXPERT\STORAGE\IaStor.sys C:\XPHFS\HFEXPERT\STORAGE\IDECOI.DLL C:\XPHFS\HFEXPERT\STORAGE\license.txt C:\XPHFS\HFEXPERT\STORAGE\NVATA.CAT C:\XPHFS\HFEXPERT\STORAGE\NVATA.SYS C:\XPHFS\HFEXPERT\STORAGE\NVATA_4.INF C:\XPHFS\HFEXPERT\STORAGE\NVATABUS.SYS C:\XPHFS\HFEXPERT\STORAGE\NVCOI.DLL C:\XPHFS\HFEXPERT\STORAGE\NVIDE.NVU C:\XPHFS\HFEXPERT\STORAGE\NVUIDE.EXE C:\XPHFS\HFEXPERT\STORAGE\raidisk1 C:\XPHFS\HFEXPERT\STORAGE\readme.txt C:\XPHFS\HFEXPERT\STORAGE\storage.ini C:\XPHFS\HFEXPERT\STORAGE\Version.txt This integrates the majority of the drivers that DELL includes on all of their XP installation CDs. I integrate these drivers using HFSLIP, and have never had a problem with them working with their associated hardware. I recommend to anyone that's working with multiple systems to try this.

Thanks for moving my topic. It seems that the server is up and down lately. Hope to find out what's up.

Is hfslip.org down for anyone else? I haven't been able to view the site in the past few days (the past 3 days or so).

An NTFS read-only driver is fine for reading ntfs volumes. I went ahead and researched to see if it would be possible to run 9x on top of an NTFS filesystem. In short: maybe. Long version follows: First and foremost, a lot of this research was conducted over a year ago, so I might be a bit rusty bringing all the things I learned together into a simple, easy-to-read post, but here goes... If we were to write an NTFS driver for Windows 9x, we'd have to be able to add it as a service (or VxD), at vmm32.vxd's load. This means that we'd have to write a simple DOS-based NTFS read/write driver (TSR application), and a corresponding 32-bit VxD to be loaded within Windows. The problem with this approach, however, is that you're still relying on DOS to handle loading the OS through NTFS. I got to thinking about this issue. I know that right when win.com is called by io.sys, Windows loads vmm32.vxd, which loads up a 32-bit dos layer on top of the 16-bit dos. From there, it loads up any remaining VxD files found in SYSTEM\IOSUBSYS\, and loads user.exe/user32.dll, krnl386.exe/kernel32.dll. So, there's a space of time where the system is in 16-bit mode, then loads up VxD services, and enters protected mode. A hack to win.com would be preferable, possibly re-packing vmm32.vxd with an NTFS driver would work, but I haven't the time nor the patience (or know-how) to try that out. There's also the possibility to replace the io.sys DOS layer with a 32-bit DOS layer, created by taking certain files from a Windows 95/98 installation, and making the system to boot directly into 32-bit mode (DOS VM mode, to be precise). Then, from this 32-bit environment, patch win.com to load only the krnl386.exe file and all remaining startup items (as vmm32.vxd and all system services are loaded as part of the 32-bit dos layer. So, to conclude, yes, there's probably a way to update Windows 9x to support NTFS. It's not probable to happen, though, especially since it's very complex to implement (and probably very very incorrect according to my post here).

What are we supposed to do with the resulting file? I dumped my results into the 'keep files' dialog in nLite, which ended up working perfectly - is this what the utility is for? Perhaps some instructions in the OP would help the uninformed.

They also released the IE administrators kit, which seems to work quite well creating CD versions of IE7 -- I've saved myself a bunch of mouse clicks by making the IE7 CD today.

Looks like a few files have changed, but seem to retain the original timestamps. Weird.

Take a look at the contents of HFSLIP.CMD. In mine, I've got this line: "IF EXIST %SYSTEMROOT%\HFSLIP.TMP GOTO :PART2", which indicates that the script is supposed to be run at least once already. I think what you're seeing is normal. Also, even though I know this issue has been addressed to death, but having underscores in addon names could be causing problems. I myself use RogueSpears' runtimes, and haven't had any problems in the local policy settings. Strange.

I'll just give you my 2 cents: For older systems that need new drives, due to drive failure, or low disk space, I will sell an 80GB drive, and clip it using the jumpers on it. If the system is so old that it does not allow 32GB clipping, I will use the Drive Overlay software, which usually comes with all retail packages of hard drives. The Drive Overlay software is software that will translate the full hard drive's size in LBA back down to CHS measurement. It does have the side effect of costing a few more CPU cycles for every byte read, but provides the end user with the ability to handle at least 128GiB - and with the 48-bit LBA patch, I'm somewhat certain that you could see the whole drive for what it is. Albeit, formatted with FAT32. I realize that this doesn't help any, especially if you're really after the older 10-20GB drives. I've been unable to get drives that small for years now. Perhaps grabbing a few 2.5" notebook drives + adapters would be appropriate - you'll probably have better luck finding a new 20GB 2.5" IDE drive than a 3.5" drive.

Drop them in the FIX folder, I think. I did that, and it seemed to work fine. I'd recommend doing that for Windows 2000, seeing as it cuts down 3-10 seconds on boot-time.

Just as a heads-up, version 5.10 is in development. I will be re-releasing the whole package once it is all ready to go. I'll update this thread with more info as it comes closer to completion.

Looks like Microsoft re-released 16535. Perhaps they fixed the package for each OS. Still same download link as before, but now it's dated 8/24/2007.

In my experience, yes, WHS is supported, BUT the normal setup routines won't work - as in, the Windows PE-stage of the installation will exit out with a random error code. If you take a look at "The art of OEM" (http://www.msfn.org/board/index.php?showtopic=95271&st=0), you'll see that there is a way around this problem.

I wandered into VMWare and ran a Windows 95B virtual machine. I enabled debug logging, and watched the log fill up - it seems that VMM32 is what controls the CPU functionality in 9x. There's this topic over on boot-land: http://www.boot-land.net/forums/index.php?...d&pid=15326 which is essentially how to make your own 32-bit DOS using Win9x files. I went ahead and created this 'new' DOS... When used, it is essentially what happens when you create a dos-box in Windows 95 - Windows 95 initializes a new DOS session, in protected memory. An actual multi-tasking 32-bit DOS. Of course, the limitations are still present - it seems that the services within VMM32.VXD in windows 95 hold the key to how the kernel gains access to the CPU. I'm certain that such a project IS possible, but it would take YEARS to get it working. And what definition of 'working' do I mean...

The Power Pack is just a collection of patches. Nothing much more than that. It contains the Revolution Pack 7, and various other patches. It is considered to be a package for those in a hurry, or those that don't want to go through the stickys and grab the right files for their OS. It can also be easily updated through its W9xBuild.bat script. It is a separate product, intended for use on a separate CD from the Windows CD. I hope that I've answered all your questions.

Personally, I prefer RogueSpear's .NET 1.1/2.0/J++ package, plus his .NET 3.0 Lite package. The main reason is because all the new .NET patches from Microsoft for version 1.1 and 2.0 have been slipstreamed into the pack, so there's not as many conflicts or screwups that can occur when installing those patches. RogueSpear posts on ryanvm's forums as well (I think).

I've released a new version to correct some broken files and various little bits that needed updating. This new version also adds the unofficial nVidia drivers that have been released for all nVidia GeForce cards. To update from an older version: Run W9xBuild.bat, and type 2 at the prompt: Press enter, wait for the ~4kb patch to download and extract, then choose option 1 at the prompt: Wait a bit, and it'll be ready for use in a little while - the total patch size is approx. 20MB in size. You can also grab a base version to build a new copy of the software off of, here- http://www.win9xpp.org/library/w9xppv505.zip. Follow the instructions in the original post for more info.

Take a look at my download script, and you'll get an idea (it uses wget for windows) - http://www.win9xpp.org/library/w9xppv501.zip The main file is W9xBuild.bat, and all the URLS files. They are plain-text files with all http/ftp websites that I get my files from.

Link is broken. How do you update to the latest release again? --iWindoze Oh crap. Fixed in op. - http://win9xpp.org/library/w9xppv501.zip

Works fine now. Thanks for the heads up on the underscore - that was certainly the issue... although, despite the fact that the files in the original build were in the HFGUIRUNONCE folder, they ran at T-13, instead of first bootup. Now, with the new build (see attached hfslip logfile), it all runs at the proper time - on first bootup, with no errors at all. * I did replace the older Dot Net 1.1 + Dot Net 2.0 exe files with RogueSpear's integrated 1.1sp1/2.0/j++ package, and renamed that to dotnet.exe. * Again, I praise everyone that is developing this script. It's truly a timesaver, and despite the issues I've had with it, I will continue using it for a long, long time to come. HFSLIP.zip

What I mean is, if there's a multi-cpu enabled DOS, there would be some way to enable the second CPU in non-protected mode. VMM would need to be hacked to allow for the second CPU to come up at boot time. I'd bet that since the 98DDK has become available again, someone MIGHT want to try and write a driver to enable the x CPU to be booted...

Is there even a DOS out there that supports multiple CPU's? I'd think that that'd be the first place to start. Obviously, MS-DOS does not support that functionality, and you'd need to re-write the entire 9x kernel to support multiprocessing, as it was not designed with MP in mind. I'm betting that someone, somewhere, in the mid-90's created a driver for 9x that enabled the use of 2 or more processors, but there's a good chance that it was not free, and was not intended for use with today's 'x86' CPU's. * Most x86 CPUs nowadays are virtualized x86 implementations on top of another architecture - Intel has the Core/Core2 arch, and AMD utilizes the DEC Alpha 9 arch.

Here you are: TXTSETUP.zip

Hmm... I'm having an issue getting silent installers renamed from their original names to their HFSlip'd names. As in, the original file name was 0_dotNET11SP1.exe, in the (HFGUIRUNONCE folder) but in I386 of the SOURCESS folder, it is changed to HFGUI1.EXE. The only problem is that the setup files still have the original file name, instead of the HFGUI1.EXE, so setup fails to load the files properly. Attached is my hfslip.log, zipped up. HFSLIP.zip