Tomcat76

I don't think it would be difficult but I'd suggest a different folder (eg, HFext). That would allow people to write their own CMD plugins and give them the power to name the files as they please. Or, if the HFTOOLS folder really needs to be used, a standard naming convention such as HFSLIP*.CMD should be maintained so they can be easily filtered out. We could maybe "expand" it with a way to let people integrate plugins at three stages: beginning, mid & end... if that would be of any use.

Thanks for the info. A quick note on #1... HFSLIP actually only accepts the default EXPAND.EXE that comes with Windows. The "fix" you see is NOT to accept alternate versions of EXPAND.EXE. There are people who have "updated" the EXPAND.EXE file with another (non-Microsoft) version that doesn't understand the switches we use. Since we're into replacing files ourselves (just look at the long list on FDV's page), I figured it would be nice to accept the fact that people replace it and to offer them a way around it without the need to put the Microsoft EXPAND.EXE in its original location (overwriting the alternate version). At first, HFSLIP only looked for it in the HFTOOLS folder but now these people can place it anywhere they like (provided they enter the correct path in the answer file). In other words, the only thing that changed is that HFSLIP allows people to have the NORMAL version of EXPAND.EXE in a different place than the default. On the rest... It's doable to turn some things into external "addons"... Hehe. But if I have to choose between having people download 20 HFSLIP plugins into the HFTOOLS folder on the one hand and having a second, "lightweight" version on the other hand... I'd pick the latter.

Other than simply double-clicking the file to see if it installs you rely on the maker telling you it's a (silent) switchless installer. Not really. It's for Microsoft Type 2 hotfixes; I don't know of other programs that can be installed with the /Q:A /R:N switches. It would work if only the INF file is involved. If all files should end up in the WINDOWS/WINNT folder (or a subfolder of it), you should use HFSLIP\HFEXPERT\WIN. Anything that's to end up in the WINDOWS/WINNT folder should go in HFSLIP\HFEXPERT\WIN. You can add folders into it (like SYSTEM32)... even folders that are not created by Windows setup (like Media\BLAHBLAH). The files you put there are copied into the I386 folder (so make sure the file names are unique); the setup installation file is updated to tell Windows setup where all the files should go. Place the installation INF in HFSVCPACK. You can use HFSLIP\HFEXPERT\WIN\SYSTEM32 instead.

At this point, it doesn't really matter whether you use the old or the new names. It's only a problem if you use both. HFSLIP renames the old folders but that function is going to be removed over time. HFSVPK *or* HFSVCPACK: switchless installers HFSVPK_SW *or* HFSVCPACK_SW: programs to be installed with the /Q:A /R:N switches plus WMP10

Sorry... I didn't see that post.I did some quick testing on an XP box and it looks like the standard Type 2 switches are accepted so I'm using these in the new version (60510b). It should work now. At worst, you'll get a wizard...

TommyP is the boss so I won't speak on his behalf. If you want my opinion... I'm gonna say the same thing the Opera browser devs reply to comments about Opera turning into "bloatware"... 1) We're talking of a ~140kb text file 2) When you include just hotfixes and a service pack, HFSLIP still just processes those and nothing else; the added functionality doesn't slow everything down when it's not used

OK... I see nothing wrong there except that you got duplicate entries in SYSOC.INF because you included both version 1.0 and version 1.1 of the VistaCG addon. But you said you tried it with only one version too and the result was the same. HFSLIP did what it had to do so I don't know what's wrong. Not sure what you want me to do here. HFSLIP doesn't support the RVM Update Pack...

60510a does Adobe/Macromedia Flash Player from SWFLASH.CAB. HFSLIP slipstreams it properly but I wasn't able to verify yet if Windows setup complains about a "non-standard system file" and if it's actually being installed.

I actually wonder if it's still needed if you install Flash 8 (or even Flash 7). The hotfix is dealing with version 6,0,84,0... Why they're calling it a hotfix for "Macromedia Flash Player from Adobe" is beyond me. I thought this takeover happened recently...

Yeah, I noticed that too. I'll have to find out how it installs. The other hotfix (KB913580) is OK. It replaces KB902400 on Win2K.

Kiki... HFSLIP doesn't support MUI updates. I don't think anyone here knows where all those *.mui files should go and there are 8 of each in that hotfix. Do you have an MUI version of XP? General: Is it actually possible to make a regular WinXP source an MUI-enabled one out of the box?

@Kiki (2) Which hotfix? (4) I think not. I'll have to check again. (5) I'll have to see the TXTSETUP.SIF and the SYSOC.INF from that run. If everything's fine there, the problem is with the addon.

I don't intend to mess with the duplicates that MS add themselves; they might be in I386 for a purpose. What I'm going to try to achieve with HFSLIP: - updated binaries should be in DRIVER.CAB (as is the case now) - updated binaries for driver files that co-exist in I386 should be updated (as is the case now) - updated binaries for driver files that only existed in DRIVER.CAB previously should NOT be added into I386 (this behavior would be new) - binaries for driver files that didn't exist at all should only be added into DRIVER.CAB unless they are required in I386 (this behavior would be new) The above is for merging options A/B/C. With the other merging options, the cab file to deal with is SPX.CAB.

OK. 60507b installs Q832483 via SVCPACK again like before.

This could be the old MDAC update. What's confusing is that the error description mentions OLEDB32R.DLL while its title speaks of OLEDB32.DLL. The latter comes with that MDAC update but the former does not.

It's not a must to have it, but if you want wmfdist95.exe you need to extract it from KB891122 or KB900325 using an advanced decompression tool like WinRAR or 7-zip. Then put it in the HF folder. Just an FYI... Sorted by date (oldest first): - codecs in MP10Setup.exe - wmfdist95.exe from KB891122 - wmfdist95.exe from KB900325 The wmfdist95.exe package contained in the Windows Media Connect 2.0 installer (wmcsetup.exe) is identical to the one in KB891122 so if you're including WMC 2.0 there's no point in including wmfdist95.exe from KB891122.

See how difficult it is?

Q892944 - Fixed Q899589 - Fixed Q833989 - vgx.dll is not part of this hotfix. Q911565 - wmpui.dll is part of WMP8 but not of WMP9 or 10. When you upgrade to WMP9 or 10, WMPUI.DLL is not updated; it isn't even used. Q911562 - dbnetlib.dll is not part of this MDAC hotfix. Try again with 60507a. Maybe it'll solve your OLEDB32R.DLL problem.

Just to be sure that we're on the same page... Camarade_Tux correctly noticed that all new driver cab binaries are copied "loose" into SOURCESS\I386 as well even though some of them (possibly the majority) don't have to be. HFSLIP doesn't delete them from the working folder after they are added into DRIVER.CAB or SPX.CAB.

@Camarade_Tux Yes, there are a couple of dupes. It's just that so far nobody ever tried to figure out which files can be deleted and which not. There are several files that have to be both in SOURCESS\I386 and in DRIVER.CAB/SPX.CAB. It's very time consuming to check this for all OS versions and all SP levels so it's not really "top priority".

You can basically use two folders but they each have their own purpose: FIX-- - these files are copied into SOURCESS\I386, overwriting existing files - if the file to be replaced in SOURCESS\I386 is compressed, the file in FIX should be too HFEXPERT\WIN-- - these files are copied into a temporary HFSLIP working folder - since the files in the temporary working folder are not compressed yet, you don't need to compress your modded files either - limited to the WINNT/WINDOWS folder and its subfolders - if the file already exists in the temporary working folder, it will be overwritten if the new file has a newer file date; nothing will be done if the new file is older - if the file doesn't exist, an entry will be added into TXTSETUP.SIF so Windows setup knows where to copy it to; this depends on where you put the file (see next point) - you need to know the name of the destination folder and place your files accordingly; eg: WINDOWS = HFEXPERT\WIN WINDOWS\SYSTEM32 = HFEXPERT\WIN\SYSTEM32 WINDOWS\FONTS = HFEXPERT\WIN\FONTS etc. The safest is to place all those modded files in the FIX folder, but they need to be compressed (eg, LOGONUI.EX_) with MAKECAB if the files to be overwritten are compressed too.

This is what the hotfix is adding; you can just copy and paste it into HFSLIPWU.INF after running HFSLIP without that hotfix: HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB840374","Installed",0x10001,1 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB840374","Comments",0,"Windows XP Hotfix - KB840374" HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB840374","Backup Dir",0,"" HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB840374","Fix Description",0,"Windows XP Hotfix - KB840374" HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB840374","Installed By",0,"" HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB840374","Installed On",0,"" HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB840374","Service Pack",0x10001,2 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB840374","Valid",0x10001,1 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB840374\File 1","Flags",0,"" HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB840374\File 1","New File",0,"" HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB840374\File 1","New Link Date",0,"" HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB840374\File 1","Old Link Date",0,"" There are hotfixes with "ENU" in their name which are OK to be slipstreamed in a non-English source, like the MSXML4 update if MSXML4 doesn't exist in the source language. Also, all Malicious Software downloads are identical so I'm just copying over the "ENU" version to the Dutch, French and German HFSLIP folders. To do what you want, HFSLIP would have to search for every hotfix with "ENU" in their name and then filter out a few like MSXML and Malicious Software. This "filter list" will have to be updated all the time. I'm in the process of making a general HFSLIP answer file. Maybe something similar can be incorporated then.

You mean after installation of Windows? I don't know, simply because I don't know which files (other than the two mentioned above) are being updated. I don't fully understand what's going on inside that hotfix (especially after reading the installation INF file) which is why I just let the hotfix install itself through SVCPACK now. But if you're removing Help Center with nLite you shouldn't be including this hotfix in the first place... I don't think that's feasible. Some hotfixes with "ENU" in their name are OK to have and HFSLIP would have to be updated every time a new hotfix like that is released.

The helpctr.exe and hscupd.exe files were properly updated but there's a lot more to that hotfix...

@Kiki Version 60505a no longer checks for duplicate entries in TXTSETUP.SIF. There's no real need for doing that and it may have been responsible for your TXTSETUP.SIF problem. Please try this release and tell me two things before you install it: - the file size of TXTSETUP.SIF in SOURCESS\I386 - the name of the hotfix that adds the "04" folders to SOURCESS\I386