glaurung

I'm poking at W98_Slip some more. For version 0.2, If makecab exits with an error, I want it to generate a file containing the text of that error. That should be easy. I also want to automate the integration of the updated files in the unofficial service pack, and that's a bit more involved. (suggestions for additional changes are welcome, but remember I'm only one person with limited spare time; slipstreaming ie6 is a ways down the road yet). I'm wondering if someone here knows the answers to a few questions about inner workings of the 98 SE service pack. 1. There are 13 files in supp.cab that are updates of files already in the windows source. I know two (shell32.dll and explorer.exe) are in supp.cab because they're resource hacked. What about the other 11? Is there a reason why I shouldn't slipstream them along with the files in sp2.cab? 2. spupdate.inf has a registerocxs section, and invokes regsvr32. I'm assuming that windows setup will handle the registration of any self-registering dlls just fine without my worrying about it. On the other hand, if the newer version of a file is self-registering and the older version wasn't, I would need to worry. Are there any files that I do need to worry about in this regard? 3. I'm not sure what I should do about the rest of the registry entries in spupdate.inf. I could be lazy and assume that none of them are needed for the proper functioning of the fixed files. Or I could just dump all the entries into a [basewinoptions] section somewhere and be done with it. On the other hand, if an important registry entry created during setup is changed by spupdate.inf, I'd have to track that entry down in the original location and change it there (cringes at the work involved ). Spupdate.inf runs runpost.bat when it completes. Runpost.bat invokes a couple of additional inf files, and I've got some questions about those: 4. wuinfo.inf: creates registry entries so windows update will "see" the installed fixes. Suppose I blindly incorporate the registry info in wuinfo.inf into one of the windows setup .infs, and then slipstream the updated files in sp2 and supp.cab. Will windows update be fooled into thinking I've updated something that isn't? Do I need to do anything else to make windows update see all the fixes that have been slipstreamed? 5. preserve.inf: I'm not entirely clear on what this does but I think it has something to do with system file checker. I'm also assuming that if the updated files are slipstreamed, there's no need for this. 6. scr56.inf: this installs the updated windows scripting host. It has entries that wsh.inf does not, but it also lacks entries found in wsh.inf. After eliminating redundancies, can I just put everthing in scr56.inf into wsh, or do I need to take some things out of wsh? 7 Finally, on a minor point of paranoia: I can't remember for sure the rule about white space in inf files. If there's a space before a filename in a filecopy section, does that have any effect, or is it ignored? (why I ask: I've written a bit of minitrue scripting to fix the 265854 issue by fixing the inf files that put smartvsd.vxd in the wrong place. To keep the fix from being applied multiple times, I inserted a space before the relocated file name).

I'd be interested in seeing the documentation. The exe, not so much. Also, I seem to remember once seeing reference to a tool that would look at a cabinet file and automatically recreate the .ddf used to create it. If you found any sign of that in that old Java SDK, let me know.

Edited my original post to add instruction #3a, about how w98_slip expects some unnecessary files, such as setup.txt and setup*wav, to exist in the source.

Thanks for the thumbs-up. Well, that explains the size of the cabs; I suspect that this format, along with the DMF format, have abbreviations in makecab (like the the other floppy sizes) which aren't mentioned in the "documentation." Then again, there's a lot that's not mentioned, or mentioned only in the most obscure manner, in the makecab documentation.

LLXX and other interested parties: check out my post entitled "W98_Slip," in the 98se unofficial service pack subforum. I hope it proves useful to you.

Background discussion: Leaving out all the false starts and frustrating attempts to wrap my head around what passes for makecab documentation, this is a rundown of some of what I've learned doing this project, which may be of use to you if you want to slipstream another version of windows or use it as a springboard to create a more ambitious Windows 9x slipstreaming tool. Using extract /d to list the contents of precopy2 reveals that the first file is carried over from precopy1, which is, mysteriously, located on "disk 2." Doing the same with base5 reveals that the first file is carried over from base4 on "disk 3." (we can safely assume that "disk1" consisted of the uncabbed setup files like setup.exe, *.bin and the like). Looking at the sizes of the cabinet files, most of them are all the same size (1760 k). However, some are smaller; win98_21 is less than 6 k. On the other hand, driver20 plus win98_21 total almost exactly 1760k. More arithmetic shows the other odd-sized cabs also add up to almost exactly 1760k if you group them in numerical order. So it seems that Microsoft used ".Set MaxDiskSize=1802240" in their makecab ddf file. Makecab then fit as much onto each "disk" as it could, resulting in the odd sized cabs. Using maxdisksize doesn't make much sense, because windows 98 was never released on floppy disks. I guess they adapted the ddf file they used for windows95, and simply never bothered to switch from a MaxDiskSize setting to a MaxCabinetSize setting. As to the size they chose: since large cab files take longer to process, Microsoft had to keep the cabs to a relatively small size so that Windows would install in a reasonable amount of time on a 486. On the other hand, I assume they wanted to keep the cabinets larger than the maximum capacity DMF floppy disk to keep people from making copies of the OS on floppy disk (this was in the days before CD-R, remember). (ETA: LLXX tells me that 1760k is the size of a floppy format that Microsoft developed but abandoned due to compatibility problems. Probably makecab supports this format with an undocumented abbreviation, just like it supports the abbreviations 1.44M and CDROM). Opening the source cabs with 7zip shows how the files are grouped in folders (7zip calls them "blocks"). Extracting the files from a single block and re-cabbing them yields cabs of about 1 megabyte. Exactly one megabyte yields folders a little larger than the source cabs; a little experimentation shows that Microsoft used: ".Set FolderSizeThreshold=1000000." This is actually pretty close to optimal: setting the value larger doesn't result in any significant savings. (NB: what passes for makecab's "documentation" has an example where "1m" is used to stand for 1000000. This is wrong: using the abbreviation generates an error). Using extract /a /d to process the entire cabinet chain reveals that precopy* is on one cabinet chain, while catalog3 through win98_74 is on a second cabinet chain. Chl99.cab, Win98_ol.cab, and mini.cab are separate. So it seems that Microsoft created the source cabinets in two passes. First, they created a complete set of source cabs, from precopy1 to win98_74, using dummy layout.inf files. Then they took the layout file generated in that pass, sliced it into three, and ran a second pass to generate precopy*.cab with the real layout.inf files. A closer look at the file dates shows that the following files share the same file date as layout*.inf, which is different from the file date for all the other files. Presumably these differently dated files are linked somehow, since they were all updated together: copy*.inf, del*.inf, ren.inf, and default.sfc. With that as background, there are several hurdles to slipstreaming: 1. Windows setup copies the cabs to a temporary directory on the hard disk before it extracts their contents (remember this was in the age of 1x cd-rom drives). Precopy1 and Precopy2 are hard coded (you can find the strings in w98setup.bin). Cabs from catalog3 through driver20 are soft-coded in copy*.inf, predrv.inf, and setupc.inf, but don't appear to be hard coded. Cabs from win98_21 on are soft coded in setupc.inf. So our makecab script has to ensure that two and only two precopy cabs are made, and that we will always have the same number of cabs regardless of the size of the updated source files. W98_slip does this by setting maxdisksize to CDROM and using new cabinet directives at the same points that new cabs began in the original. It then edits the three soft coded inf files because the resulting fileset was smaller due to some large files spanning several cabs in the original. 2. The layout.infs don't list the [sourcediskfiles] in the order in which they appear in the cabs. I don't know why this is, but it means that using the default layout.inf generated by makecab (which lists the files in the order in which they appear in the cabs) results in "cannot find file" errors during the file copy phase of setup. Again, I don't know why this is, but my best guess: the layout*.inf files are required to be in synch with the other files with the same timestamp (copy*.inf in particular). So our makecab script has to be a relational script, which orders its layout.inf file differently from the order of files in the cabs, using ".Set GenerateInf" directives. 3. Relational .ddfs require all files you're compressing to be unique: you can't put command.com into precopy1.cab and again into base4.cab. This is exactly what Microsoft did (there are 3 files duplicated between precopy and base, and another file duplicated between the list of uncompressed setup files and the cabs). So w98_slip uses the workaround of putting the duplicate files in under different names during pass one, then editing the generated layout file to put the real names back, and putting the duplicates in under their own names during pass 2. 4. Things that may be a hurdle: some of the files in layout.inf have a CRC appended to them. For windows 98se, the CRC appears to be optional. That may not be so for ME. I know it's possible to have makecab append the crc to specified files in layout.inf using the "source_file /x=y" switch, but the makecab "documentation" is even less useful in explaining the /x=y switch than usual. W98_Slip uses minitrue (an alternative to sed) to automatically generate the bulk of the makecab directive file on the fly. The advantage of this (besides tiny download size) is that it should be relatively easy to modify to work on other versions of the OS.

W98_Slip: Slipstreaming Windows 98 SE. About: W98_Slip is a set of batch and script files used to slipstream updates into Windows 9x. Currently it has only been tested with Windows 98se, but with minor modifications it should work with Windows ME, Windows 98 first edition, and (with more extensive modification) maybe even Windows 95. [eta: Its main limitation is that it can only slipstream updated files. New files could be slipstreamed, but it would take editing by hand of the makecab script files.] Credits: W98_Slip is written by Glaurung. This project was inspired by TommyP's HFSlip project. Contact info: For information and support, visit the W98_Slip thread in the MSFN Windows 98se unofficial service pack Forum. Version history: This is version 0.1 (first release). Copyright and credits: These files are open source, released under the GPL. You may use them for any use, personal, non-profit, or commercial. But you do so with the understanding that, 1) these files are experimental, unwarranteed, and you use them completely at your own risk, and 2) using these files may invalidate your licence with Microsoft, and any license issues caused by using these files are totally your responsibility. Currently, these files are entirely my own work; I welcome contributions by others. You may redistribute these files, but if you do so, please give me credit, and leave in the contact information so users know where to go for information and updates. Warnings: These have been tested successfully with my OEM copy of Windows 98 SE. I have used them to do a maximum install from both DOS and within Windows with no error messages whatsoever. However, I don't own a retail copy or a bulk licence copy to test on. These files may or may not work with your copy of the OS. There is no guarantee, and no warrantee. There is no support. This project is something I did in my spare time. I'd like to help you if you have problems, but I may not be able to reply right away or at all. Another warning: My batch file writing skills are pretty basic. Currently there is little error checking or sanity control. If you follow the directions, it should work. If you don't, it won't work. w98_slip: Instructions for use. 0. You will need: 7zip or winzip, to extract updated files from hotfixes or from the unofficial service pack. Makecab (Microsoft cabinet SDK), for obvious reasons. Minitrue, used by W98_Slip to turn file lists into makecab scripts. 1. Unzip the files to a new folder on a disk with 1gb or more of free space. I've always put them in a top-level folder with a short file name. They might work for you if you put them in "My documents/my very long folder name with lots of spaces," and then again they might not. 2. Run w98_slip.bat. It will create some subfolders and display a short version of these directions. 3. Copy the win98 folder from your Windows 98 SE CD to the "source" folder. 3a. W98_slip expects some files to exist that are not required for setup to work properly. If the copy of the setup files that you have handy doesn't include setup.txt or setup*.wav, then when W98_slip tries to compress the updated source, makecab will fail with an error. If you can't find your original win98 CD, just run "makecab /f pass2.ddf" to see the missing files, then create some zero-byte dummy files with the same names. 4. Put the new versions of the files you want to update in the "updates" folder. 4a. If you want Windows Update to see the hotfixes you're slipstreaming as already applied, you need to edit an existing .inf file in the source to add the registry entries that tell windows update that you're already patched on that issue. Sorry I can't be more specific but the exact entries to make will depend on the exact files you are updating. 4b. Two restrictions on updated files: a) the files in the "updates" folder cannot be compressed (extract them first), and B) 98slip will only update files that already exist in the original (ie, w98_slip won't slipstream the q891711 update because it uses new files not in the original). You can add files not found in the original, but you'll have to edit the scripts by hand, and edit inf files in the source to take account of the new file. 5. Put the following programs in the "tools" folder: makecab.exe (downloadable as part of the Microsoft Cabinet SDK), and mtr.exe (part of minitrue, downloadable from http://www.idiotsdelight.net/minitrue/). Also, if you have used 98lite (pay version) to remove the DOS command line utilities from windows\command, reinstall them. 6. Run w98_slip.bat again. The program will pause at various points, both to let you see if any errors popped up and to allow you to cancel out if need be, so it's not possible to run it totally unattended. 7. The slipstreamed install files will be in slipped\win98. 8. If you run w98_slip.bat again, it will ask you if you want to reuse your previous decompressed source. This is mainly a time saving measure, since decompression takes several minutes. It will also ask you if you want to reuse your previous makecab scripts. This is in case you modified the scripts for whatever reason. Finally, it will ask if you want to recreate the entire slipstream or just the precopy.cab files. Again, this is a timesaving measure for people who mainly want to modify the .inf files. Things to note: 1. The install files will not be the same sizes as the originals, and there will be slightly fewer of them. This is because w98_slip is designed to generate the same number of cab files regardless of the size of your updated files. 2. In your slipstreamed install, Sfc.exe may not work properly (I haven't tested it so am unsure), as it contains hardcoded references to specific .cab file names. Fixing this would require hacking the binary file default.sfc. What the files do: pass1.ddf and pass2.ddf are makecab directive file stubs (everything makecab needs except the list of files to compress). The file lists for makecab are generated by w98_slip on the fly using minitrue. mt*.txt are minitrue scripts. mt.txt, mt1.txt, and mt2.txt handle the conversion of the three layout.inf files to makecab directive files. mt_fl.txt and mt_pc.txt handle the conversion of the list of files contained in the cabs into makecab directive files. mt_inf.txt handles the problem that driver19 and driver20.cab don't exist in the fileset w98_slip produces, but are referenced in a couple of inf files. I made it external to help simplify the process of adapting w98_slip to work with other versions of the OS. w98_slip.zip

It may have something to do with the need to match copy*.inf to layout*.inf. I haven't looked in detail, but it appears that "copy" appears to have the same list of files as "layout," and in the same order; it may be that the two have to be exactly in sync. Reproducing copy*.inf with a different file order would be a real PITA, since copy*.inf lists each file followed by its LDID destination, and I can't think of a good way to reproduce that using an automated script. Fortunately, it's relatively easy to force makecab to generate a layout.inf that matches the original's arrangement, using a relational .ddf (see my earlier post in this thread if you haven't already). As to why they stuck the file names into the various layout files in the order they did, I don't know. But remember that windows 98se is the fifth or sixth version of windows to use the same setup engine, and no programmer is going to rewrite an installation script when they can just add on to a pre-existing script. So whatever reason existed for the ordering of files under windows 95 is probably the reason for the ordering under windows 98se.

My best guess is that at some point in the process, setup is only able to see the first layout file, or something stupid like that. So, the list of files in the layout*.infs need to be in the same order as in the original factory generated ones. The way to do this is to use a relational ddf for the first pass. Makecab gives details; basically you list all the files to compress in the order that they are to be put into cabs (using the same order as the originals, which you get by listing the contents of the cabs using extract). Then you list all the files again, this time in the order in which they are to be put in the inf file list that makecab generates. There's a command to insert stuff into the inf as its being generated, .infwrite I think. You can use it at the break points between the layout.infs in the second half of the .ddf, to make your job of slicing and dicing the generated layout.inf into three easier, but the documentation is wrong in this as in several other points: it will not insert a commented line in the inf (drove me nuts for a while until I figured that out). The only "gotcha" to a relational ddf is that you can't have any duplicate files in the compression list, but there are duplicate files (three of them, IIRC) between precopy* and base*. Maybe Microsoft generated the inf using a tool they never released to the public. What you can do is make copies of those duplicate files with dummy names. In pass one, compress the dummy copies to precopy. Then replace the dummy names with the original names when you're cutting the layout.inf into three parts, and in pass two, compress the real files to precopy. Oh, and you don't need the checksums that are in the original layout files for a couple of dozen files out of the six thousand, which is a good thing since the makecab documentation is even more obscure than usual in explaining how you can insert stuff like checksums after a single specified file. As you may be able to tell, I've been down the road you're on myself. Don't worry, it is possible to do this and have an updated set of install files that will do an install with no errors.

I think your problem is cabinet chaining. Setup thinks it's decompressing the precopy cabs but instead is decompressing all 300+ megs worth of files. Solution: In pass two (when inserting the updated layout.inf files) you need to compress only the precopy* cabs (so you need two ddf files, one for the full pass and one for just making precopy*.cab).