Inki

I may be mistaken, but it seems to me, that the latest ini inside the 11.1.102.55 cabinet attempts to register Flash11c.ocx rather than Flash11e.ocx. P.S. I might also add, that although I have moved on from HFSLIP to manually updating my XP install CD (which has actually allowed me to slipstream several updates not doable with HFSLIP), I greatly appreciate the efforts undertaken to maintain update listings and especially these Flash packages. Concerning Flash, and just for your information, I have noticed that after installing a slipstreamed source, I never see the control panel applet correctly reporting the installed Flash version. Still, I guess that is unlikely to be of any major relevance, and it is probably just a case of some specific registry setting not getting updated (unless it is my manual updating missing something). I have not really bothered about it, because Flash seems to work fine, and eventually one will update Flash through the net anyway, and the issue then becomes moot.

By the way, as I was examining SNM Synth to come up with my own gap-filling, work-around script (in the previous post), I came up against some questions, that were not critical, but for which I had no answers. So, out of pure curiosity, I wonder if anybody could comment on them: 1) If the target system is not Win2k, the installers created by SNM Synth examine the "System Setup In Progress" flag in registry. If the flag is set, the installers: (a.) temporarily reset the flag for the duration of the installation, and (b.) first clear some DW (Dr Watson, I presume) registry settings and afterwards set the registry to contain location information for DW20.exe. Now, I figured the DW stuff is related to the O2K3 debugger though I noticed that the registry manipulations are not linked to whether the debugger is present in the installers or not. Anyway, as I use the installers in an unattended installation CD, and don't use the O2K3 debugger, no DW stuff is present at runtime, so I left out the DW registry manipulations, because I prefer not to have location information for nonexistent files entered into registry. I did, however keep the SSIP flag manipulation, because I don't really know what that is for and thought that at least it would not do any harm. So the question here is: Can anybody comment on what the precise purpose of these registry manipulations by the installers could be? 2) On a general level, I understand that the .mst files contained in .7z archives that are packaged together with SNM Synth are used to manipulate installation instructions/detaíls stored inside .msi files. However, I have no clue as to what these instructions/details specifically are. So I wonder: Are there any publicly available tools for examining or manipulating the content of .msi or .mst files at that level of detail? Edit: Nevermind the second question after all. Being the complete amateur that I am, I had some apprehensions about finding tools for the purpose. However, voicing the question motivated me to search around, and I found some SDK's that contained orca.msi and mstview.exe, which seem adequate to satisfy my curiosity. Still, on first examination, transforming msi's seems to be a complicated business, not be entered lightly.

This is essentially input for bphlpt and his quest. It is a straightforward script, that I have made for my own use to be able to create .NET installers with the latest updates. It is heavily based on what I found inside SNM Synth, though much simplified and modified in parts, and I am only presenting it in case it might contain anything that would be useful for the next generation. (Also, as I have benefited from using SNM Synth, and feel indebted to it, I felt it was only proper to share this, whether or not it is of use to anybody. I am likewise grateful to anybody, whose contributions have helped to develop SNM Synth, and I certainly don't want anybody to perceive the script below as a rip-off.) Its essential features are: - It does Win2k and WinXP - It does 1.1SP1 or (20SP2+30SP2+35SP1) or both in one installer. (of course not going beyond 20SP2 for Win2k) - It does not do languages - The installers are switchless, passive, and assume an msi.dll of at least 3.x on the target (2k vanilla has 2.x) - There is no ini file, a reasonable (for me) set of options is hard-coded in (e.g. VC8/9 removed) though easily editable - Selection and ordering of hotfixes has to be done by editing lists within the script itself. To try it one begins by placing all .NET source files (including the _*.7z archives) in a .\SRC subdirectory, running the built-in extraction utility, and editing lists inside the script itself to match extracted source .msp's. As it's purpose is to be input for bphlpt (or others), and I have no interest in supporting anybody to use it, no further instructions are provided. _DNFMAKE.zip

FYI, regarding update KB952013 for XP : HFSLIP does not appear to support slipstreaming SmartCard_XP_x86.exe (renamed as WindowsXP-KB952013-x86-xxx.exe), which therefore should be placed into HFSVCPACK_SW1 rather than HF. When run manually, the update places its driver file wudfusbcciddriver.dll into windows\system32\drivers\umdf\, where the accompanying wudfusbcciddriver.inf then expects to find it if and when a device comes around that needs it. (See line #85 of update.inf extractable from the update exe as well as line #122 of wudfusbcciddriver.inf). HFSLIP does not have specific coding to handle this special location (it is not an essential fix after all), and attempting to slipstream the update places the driver file into windows\system32\, where it most likely is useless. ( I don't have any suitable smart card device to conclusively verify this in practice.) (Still, as this update is not likely to be needed in most cases, a reasonable person might opt not to install it at all unless truly needed.) P.S. I thought I could still mention, that not being a reasonable person myself, I do slipstream even this update, but to make it proper, I have to make the following manual modifications to TXTSETUP.SIF before burning my install CD: New line under [WinntDirectories]: 1010 = "system32\drivers\umdf" Modified line under [sourceDisksFiles] ('2' replaced by '1010'): wudfusbcciddriver.dll = 1,,,,,,,1010,0,0

I checked to see what would happen, if I ran the latest original flash player installer via InstallWatch after having first installed XP from a disk created with HFSLIP using Swflash.cab. Attached is a listing of new registry entries that InstallWatch recorded when the flash player was manually installed on top of an installation where it was already HFSLIPped in. Most of the items in the listing clearly look like useless "installation overhead". Still, there are some, that my limited understanding doesn't allow me to classify with any confidence. I wonder if someone with a better understanding could look at the listing and comment on whether there is any need to be concerned over HFSLIP+Swflash.cab creating all the essential entries. Listing.zip

Thank you for your suggestions. I am afraid that /integrate: is not the solution. And just to be sure, I did run it and then used Winmerge to see what changes were made to the source. As I suspected, the changes were of the kind that I guess /integrate: typically does, which lead to the hotfix being applied during installation, but do not change the text-mode setup in any way. For it to work, I suspect that the drivers have to be manually slipstreamed. Your second suggestion seems to me much more promising, and I think it is a clever notion to exchange FAT32 and exFAT. However, my gut feeling is that it might require more than changing that one entry, and I don't really trust myself to be able to implement the idea properly. The most that I have been able to do is integrate some SATA drivers into the source by following instructions on how to do that, and I feel that this might require some deeper understanding just to experiment effectively. Edited addition: Hmm, I just realized, that the initiator of this thread seems to have been banned, for whatever reason. Well, I didn't pay any attention to his/her status when I did a search for exFAT, and found that the thread title and the content of the previous posts matched my issue exactly. It is not something that I would normally expect to have to check for, and I am not sure if it should matter. So, I will just hope that it doesn't discourage anybody from contributing to this issue, which I think is interesting and potentially useful. Still, if it is more desirable, I can of course always start a new thread.

I am under the impression, correct or not, that exFAT would be the preferred formatting for a Solid State Drive, when used as a boot/system drive (or even in general), because exFAT would tend to shuffle less overhead data on the disk, thus extending its life expectancy. I experimented by using KB955704 on XP to format a small, old hard drive with the exFAT file system (no problems doing that), and then trying to install XP on that drive. The experiment failed at nearly the very beginning of the installation process, because XP would not recognize the drive as having a compatible file system. That was not really unexpected, of course, but I had to try it. The interesting question is, whether there might be any possibility of bringing exFAT litteracy to the text-mode installation phase of XP. If possible at all, I suspect it might require modifying Txtsetup.sif (and Dosnet.inf) to make the exFAT driver files available at the beginning (as may be done to integrate SATA drivers), and possibly modifying registry entries in Setupreg.hiv (as may be done in Win2k to enable 48bit LBA support at installation). Unfortunately, however, I am capable of only suspecting these things. I wonder, if anybody has more or better information on whether, and how, one might use an exFAT-formatted boot/system drive with XP?

I am not sure if it is of any interest to anybody, but along the lines of my previous posting, please allow me to summarize my understanding of the nature of some WMP6.4 hotfixes: The following patches for WMP6.4 are apparently more or less like other basic OS patches in the sense that the component to be patched is by default present: - KB925398/MS06-078 for 2kSP4 - KB954600/MS08-076 for 2kSP4, XPSP3 - KB974112/MS09-052 for 2kSP4, XPSP3 - KB975025/MS09-051 for XPSP3 For WinXP, even the names of the hotfix installers follow the basic WindowsXP-KBXXXX.... structure. For Win2k, the names of the installers are typically like WindowsMedia6...., which may lead one to think that they are more optional than what is the case. Perhaps one might add some other hotfixes to that list, like what My2GirlsDad initially brought up, but I am not sure how the separating line between WMP6.4 and other system components might run. On the other hand, the following patches are optional in the sense that they are actually patches to wmp6cdcs.exe, which itself is optional and installs WM9 codecs for WMP6.4: - KB969878/MS09-051 for 2kSP4, XPSP3 - KB975025/MS09-051 for 2kSP4 It is easy to be mislead into thinking that they are somehow related to WMP9, but that would be incorrect. The most intuitive way to group these hotfixes would be together with wmp6cdcs.exe as optional add-ons to WMP6.4. Anyhow, without wmp6cdcs.exe it makes little sense to include them in HFSLIP. Incidentally, it is possible to install wmp6cdcs.exe also on WinXP, though I am not sure how practical or useful that might be. On Win2k I did once come against a .wmv video file, that to my surprise launched WMP6.4 rather than WMP9, and the apparent reason was that the codec in question, (not a legacy codec, but a fairly recent one) was not available for WMP9 on Win2k, but was included in wmp6cdcs.exe. Ok, that is how I see this thing. Of course, it is always possible that I may have missed or misunderstood something, as I am no IT expert. Addition: About KB977816/MS10-026. It seems to have two parts to it. The first, WM64 part, updates l3codecx.ax, which is an original WMP64 codec, (which would place the hotfix in the first category listed at the beginning). The second, WM9 part, updates l3codeca.acm, that comes with WMP9 (and is presumably also used by WMP11).

???My humble understanding is, that MP6.4 is not replaced by WMP7/8/9/10/11 in 2k/XP, and it remains alongside whichever later version is also installed, whether that be manually or through HFSLIP. Thus, unless I am gravely mistaken, it would only be natural, that MP6.4 might feel a bit cross if everything else gets hotfixed while it is left hanging high and dry. To test this, try launching 'Mplayer2' via the 'Run' command in the start menu and see what happens. Maybe you can remove it altogether, if somebody has reliably identified what binaries to prune, but I am not aware of such a method.

Two brief comments concerning both WinXP update lists (also applicable to Win2k), to the best of my understanding: WindowsMedia9-KB969878-x86-ENU.exe (DirectShow WMA Voice Codec / MS09-051) contains an updated version of wmavds32.ax, which apparently originates from "[Windows Media 9] Codec Installation Package for Windows Media Player 6.4" (wmp6cdcs.exe). Thus, it is linked to MP6 rather than MP9, and it is probably pretty much useless without wmp6cdcs.exe. Also, wuweb_site.cab is probably unnecessary, as it contains an older version of wuweb.dll than what exists in the latest version of windowsupdateagent30-x86.exe. (I managed without.)

These are some things I came up with and thought I'd share for the heck of it, even though interest for Windows 2000 seems to be rapidly dwindling. Currently there are three security updates for Windows 2000, that can not be properly slipstreamed by merely placing then into the HF folder, and the recommendation is to place them into HFSVCPACK_SW1. However, there may be some workarounds that allow full slipstreaming, or so it seems to me with my limited understanding. (These things seem to work for me.) 1. KB958470 (MS09-044) Remote Desktop Connection thingy If RDC is not installed, and I guess there seldom is good reason why it should, the hotfix essentially only sets a few ActiveX killbits in the registry, and it is much "lighter" to slipstream those separately rather than to have the whole hotfix in HFSVCPACK_SW1. So, assuming that you don't actually have RDC installed, copy the following lines into a new text file called KB958470.reg (or whatever.reg), and place it into HFSVCPACK, then remove the actual hotfix file from your setup. ------------------------------------------ Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{9059f30f-4eb1-4bd2-9fdc-36f43a218f4a}] "Compatibility Flags"=dword:00000400 "AlternateCLSID"="{971127BB-259F-48c2-BD75-5F97A3331551}" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{7584c670-2274-4efb-b00b-d6aaba6d3850}] "Compatibility Flags"=dword:00000400 "AlternateCLSID"="{6A6F4B83-45C5-4ca9-BDD9-0D81C12295E4}" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{4EDCB26C-D24C-4e72-AF07-B576699AC0DE}] "Compatibility Flags"=dword:00000400 "AlternateCLSID"="{54CE37E0-9834-41ae-9896-4DAB69DC022B}" ----------------------------------------- 2. KB973904 (MS09-073) Text converters for Wordpad The update wants to add completely new files alongside Wordpad.exe, and there is apparently no standard method for doing that with HFSLIP. However, you can extract wordpad.in_ into wordpad.inf and edit it so that where it used to merely say: -------------------------------- [WordPadCopyFiles] wordpad.exe -------------------------------- you add new lines before and after, resulting in: -------------------------------- [sourceDisksNames] 3 = "Windows CD",\CDROM_IP.5,,\I386 [sourceDisksFiles] mswrd6.wpc = 3 mswrd8.wpc = 3 write.wpc = 3 [WordPadCopyFiles] wordpad.exe mswrd6.wpc mswrd8.wpc write.wpc ------------------------------ This instructs the system to copy the missing files from the CD to the correct location while it is doing the same to wordpad.exe. Rename the modified file into wordpad.in_ (or compress it into a cabinet) and place it into REPLACE\I386. Place the hotfix file into HF. (Note: \CDROM_IP.5 is merely the name of a tag file to identify the CD. I am not sure if it is needed, and if it does not match your CD, you can try changing or removing it from the line.) 3. KB975560 (MS10-013) Update for DirextX 9 Apparently msyuv.dll contained in this hotfix has a poorly configured header, which causes the system to choke during text-mode file copying. To correct it, get hold of modifype.exe, extract msyuv.dll from the hotfix, place them together in some directory, and run 'modifype msyuv.dll -c'. Then you can rename the modified file into msyuv.dl_ (or compress it into a cabinet) and place it into REPLACE\I386, while you place the hotfix file into HF. I guess it would not do any harm to also cross one's fingers and hope, that nothing else is at fault with the file. P.S. Those code snippet boxes really seem quite awkward. Well, I don't know any better, and I have a hard time dealing with this new system anyway. - Ended up replacing them with a lot of hyphens.

Sorry to hear that, but OK and no sweat, if you say so. You're the Boss. And thanks for the tip, I will be sure to try it out.... No joy, though, but that's cool.

Sorry to be a party spoiler, but there may be a possible issue with Windows 2000 + DirectX 9 and KB975560/MS10-013 (quartz.dll, msyuv.dll) (Unless, of course it is a glitch by MS or I fouled something up): Installing Windows2000-DirectX9-KB975560-x86-ENU.exe manually presents no problem. However, when installing from a HFSLIP-based installation CD, the text-mode file copying phase is interrupted by the following error message: The file msyuv.dll was not copied correctly The file Setup placed on your hard drive is not a valid Windows 2000 system image. If you are installing from a CD, there may be a problem with the Windows 2000 CD. - To retry, press ENTER. - To skip this file, press ESC. - To quit Setup, press F3. Choosing the option to skip allows the installation to proceed, and once it is done, the file msyuv.dll on the hard drive is exactly the same as after a manual installation or what can be extracted from the hotfix installer. (Tried this with two CD burns, using betas F and G) HFSLIPLOG.ZIP

There are many people on this forum, who are immensely more knowledgeable than myself, but I am doing nothing important and feel helpful at the moment, so for what it's worth: The whole point of HFSLIP is to provide a slipstreamed and optimized installation source for doing a full/clean/fresh installation with many fixes/updates already included in the installation source. To add updates to an existing system I believe you would preferably run the installers manually or use some other tool, e.g. Windows Update. I may be mistaken, but it appears to me that you may have attempted something that seems a bit strange, and is unlikely to generate many constructive suggestions.

Wow, some coincidence then, that I ran into this while building up my set of slipstreamed XP drivers before adding HFCLEANUP to the setup. Thank you very much for looking into it and clarifying what it is about. For me personally, it would be quite enough just to know that using HFCLEANUP neutralizes the effect. I hope that removing the issue fully does not end up being too cumbersome. By the way, did I already mention, that I am very happy with this functionality overall.

Oh, I do slipstream more stuff. I merely reduced it to this test case for easier troubleshooting. When I had a look comparing the two TXTSETUP.SIF files myself, I searched for what you pointed out, but I thought I found HSP56MR.INF = 1,,,,,,,20,0,0 & JVCDSC.INF = 1,,,,,,,20,0,0 under [FileFlags] rather than [sourceDisksFiles], on the last two lines of the file from 1.7.10 beta E. Since I happen to have previous 1.7.10 beta versions, I tested them and noticed that I get this anomaly in TXTSETUP.SIF since beta A. Out of curiosity, I then compared the 1.7.9 and 1.7.10 beta A HFSLIP.CMD files, although I don't understand much about them. I did notice that "CALL :HFEDRVCAB" had changed location in the overall structure, and at great risk, not knowing at all what I am talking about, I wonder if that might have anything to do with it. Sorry, maybe I really should not have spoken about what I do not understand. Hmm... On the other hand, if this were an issue that impacted XP since 1.7.10 beta A, it might be a bit strange, if I were the only one to encounter it. So, perhaps the wisest thing for me to do is to cease to mess this thread, and see if I can get my issue sorted over time.

But of course, here you are. TXTSIFx2.zip

It seems that my troubles above are due to something being broken in 1.7.10 beta E. The problem vanished when I resorted back to 1.7.9, which I should have done earlier, as that was what I had used for 2k. I compared the resulting SOURCESS directories from the two versions, and it turns out that files DOSNET.INF, TXTSETUP.SIF, and HFSLIPWU.INF have differing contents. Anyway, I am pleased that my troubles apparently were nothing serious, as I am very happy with this method of slipstreaming drivers. My apologies for causing any unnecessary anxiety, and for messing this tutorial thread with what seems to be a beta issue after all. Oh, and just to mention it: When adding new drivers, I am also making good use of HFCLEANUP to eliminate conflicting native ones. Still, I am progressing exteremely cautiously with that feature, and may hope to perhaps use it more once I get my favourite drivers in place.

Well, I didn't try to have the names capitalised, but they certainly were inf files. Maybe I should try that.I tried quite a few things, going back to nothing but a plain XP SP3 source and just one or two drivers. Unfortunately I don't immediately have a representative log file available. I can come back to it, but I have a substantial turnaround time in doing these runs and just now I have some things pressing. ======== Some time passes ========== Ok, attached now is the log file from a simple test case. It contains two drivers, one is for the on-board modem on my old junky test rig, and the other is just a single inf file, that invokes the system-supplied usbstor.sys to create a USB-connection with my video camera. Neither inf file gets copied to Windows\inf on installation. If I copy the inf files manually from the install CD to Windows\inf and then launch Device Manager to update the drivers, everything works fine, and the drivers get installed. Could this be a case of XP refusing to cooperate with this method as a question of principle? HFSLIPLOG.ZIP

Well, as far as I can see, this seems to work excellently for Windows 2000, and I was apparently able to integrate all the system, net, audio, video, and other drivers that I wanted. This includes fully working "2k-latest" Catalyst and Geforce drivers (with some additional inf editing). However, moving on to XP SP3 I seem to have hit a brick wall. I get a nice install CD with all the driver files nicely A-cabinated and all the inf files in \I386 as they should. But on installation none of the new inf files get transferred to Windows\inf on the target system. I have tried double checking that the drivers and inf files are valid, and I have even tried all the modified dll's prescribed for HFCLEANUP (RyanVM's & fdv's, though not simultaneously) to see if they might make a difference, but nothing gives. Anyway, I am no expert on this and may well have missed something obvious or simple, but I am quite perplexed by so different an experience on 2k and XP. Any hints would be appreciated .

My thanks to tommyp for this tutorial. I have not previously had the courage to try driver integration, but I tried this method on Win2k with some AGP and net drivers, and it seems to work nicely, so I may be slowly getting a hang of this. I was also pleased to notice, that when I start with the original driver package using DriverMax to verify the right selection of files, but leave out the .cat file and comment out any reference to it in the inf, then after installation, Drivermax apparently can't tell any difference between the new drivers and other windows-supplied ones, as it did with the .cat reference intact. I may be wrong here, but it seems to me that DriverMax classifies them as signed by default.

OK. From what you are saying I get the impression, that rather than fully adapt the hotfix to 2k, they may perhaps have imposed an ad-hoc XP-style file organisation onto 2k instead. If so, that would seem a bit disappointing and understandably pull the rug from under slipstreaming efforts. Well, hopefully they didn't break anything. Anyway, thanks for looking into this.

It seems that after installing the OS from the HFSLIPped CD, relevant files on the machine are updated as single copies in what I guess are "standard locations" for such files: C:\Program Files\Common Files\Microsoft Shared\TextConv\ contains html32.cnv, msconv97.dll, mswrd632.wpc, mswrd832.cnv, and write32.wpc. C:\Windows\System32\ contains mswrd6.wpc, mswrd8.wpc, and write.wpc. However, after installing the hotfix manually, it seems that most of these files can also be found at additional locations, and these new locations match copy entries in KB973904.log, as you cleverly suspected. KB973904LOG.zip

First, my great appreciation for HFSLIP. I recently made a new Windows 2000 install CD with hotfixes up to January 2010 using HFSLIP 1.7.9. Everything seems to be fine apart from both MBSA and WU nagging about KB973904/MS09-073 (Vulnerability in WordPad and Office Text Converters) until I install the hotfix manually. As my typical setup contains several non-critical updates, which may be distracting, I made a trimmed-down demo run with the attached log file, that shows the same symptoms. The source is pre-slipstreamed with Gurgelmeyer's USP 5.1 containing IE 6 and some other stuff that might seem to be missing from the log. Some additional observations concerning the Windows 2000 Post SP4 hotfix list: KB951748/MS08-037 has been replaced by a V2 version of the same, and this updated hotfix now also appears to replace KB945553/MS08-020. One can apparently remove KB976749/MSA 977981 (IE 6 Fix for MS09-054), as it seems to be included in KB976325/MS09-072 (IE 6 Cumulative Security Update). Quoting from MS09-072: "This security update also addresses the vulnerability first described in Microsoft Security Advisory 977981". Perhaps there may or may not be a case for considering KB955759 (aclayers.dll) and KB976138 (quartz.dll, replaces KB971633/MS09-028), both from MSA 954157 (Indeo codec vulnerability), as WU brings them up as high priority updates. HFSLIPLOG.zip

Yes, USP 5.1 is pre-slipstreamed, HFSLIP.LOG: "OS in SOURCESS - Windows 2000 Professional SP4 (USP5.x) English" That is how it has worked for me over several years, and it slightly reduces processing done by HFSLIP. Now, I have not run HFSLIP for several months prior to this June, but I did run 1.7.9_beta_d in January, though, without incident. Of course, if a pre-slipstreamed USP5 is no longer supported, I can change my setup accordingly and see if it helps. Update: Well, I tried it with a pure SP4 source and w2ksp51.exe in HF. There was no difference in outcome (going through a full installation). I also made a file-by-file comparison of the content of the resulting iso's (using Winmerge), and found that the only truly differing file was hfslip.log, that now listed w2ksp51 in the HF folder, and also mentioned that it was slipstreamed into the source by HFSLIP. (For the sake of completeness: bidibtrx.in_, dxbda.in_, swflash.in_, and sysoc.in_ were also different, but only because the identical .ini files contained within had different time stamps.) I am planning to test some older HFSLIP versions to see if that would make a diffence. Update 2: I have now also tried 1.7.8, and the only difference seems to be that a couple other updates, for which support has since been added, are not properly installed. So, I guess, that in a nutshell this just boils down to the latest ie6sp1 cumulative update (MS09-019 / KB969897) somehow not being fully installed.