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.