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