Tomcat76

It's any hotfix that has a internal subfolder called "ip" that was affected. The "ip" folder is used for files that are specific to XP Pro. Those three hotfixes are the ones I use in my source.

I don't see the MSOOBE hotfix in your list. It's required when slipstreaming WMP11. See on the HFSLIP site > Guidelines > Media Player 11 (WinXP).

Check which versions of HFSLIP you used (Add/Remove Programs or WINDOWS\inf\HFSLIPWU.INF). This started with test release 80116a; version 80101a was still fine.

I suppose it's easier if I give you some hotfix names. From the ones I use (my full list + some others), these are affected: WindowsXP-KB897338-v3-x86-ENU.exe WindowsXP-KB922120-v5-x86-ENU.exe WindowsXP-KB925876-x86-ENU.exe You may want to reinstall the ones you tried to slipstream.

OK... Thanks.

>> 1. HFEXPERT\WIN\system32\drivers\etc\hosts HFEXPERT\WIN is not intended to replace existing files in the source; you could run into problems with floppy or network-based installs. This should work for CD installs, but it will cause Windows setup to copy your file twice since it already exists in the source and is handled by TXTSETUP.SIF through a different destination folder ID (17). The REPLACE folder is better suited for this. From the HFSLIP guide: "New entries are created in TXTSETUP.SIF and DOSNET.INF so only use this for NEW binaries." >> 2. REPLACE\I386\HOSTS This should work. >> 3. HFEXPERT\APPREPLACEMENT\drivers\etc\hosts It should be placed in HFEXPERT\APPREPLACEMENT; HFSLIP doesn't look in subfolders. This is only necessary if Windows setup complains about an invalid file. >> 4. FIX\system32\drivers\etc\hosts This won't work as this folder structure doesn't exist on your CD. The proper location is FIX. But this won't work in the future when HFSLIP won't automatically move items from FIX to REPLACE\I386 any longer.

@eryen: Thanks for pointing that out. Please try the latest RC. @ctpooon: Your problem may be fixed with the latest test release.

Thanks, eryen.

That happened because HFSLIP was checking for the existence of cdromsp5.tst in the SOURCE folder when generating that line into HFSLIP.LOG, which would fail if a source backup was made because the backup is replaced before HFSLIP.LOG is created. There's an updated version which searches for cdromsp5.tst in the SOURCESS folder.

They should be supported seperately, because that's what HFSLIP is doing internally (expand cabs into HFCABS, process cabs, remove cabs).

I wouldn't know what could be causing that apart from an update. I can't suggest anything else than to try eliminating WMP11 hotfixes from the HF folder.

Swedish and Danish added. That looks to be a new download pool. I changed the other links too, though it wasn't really necessary.

Any problem/suggestion mentioned here should be fixed/included in the hfslip-1.7.4beta_80116a test release. Thanks

You probably know this, but I wanna point it out for completeness: different binaries are taken from the SP6a package depending on the edition (WS or SVR) -- some even need to be renamed -- and the same goes for the registry edits. Also, I would've rewritten the SP6a installation INF file (ie, write a new heading like HFSLIP does), execute it after installation, and then fire up InstallRite to install SP6a on top. This way, only the registry edits that are not mentioned in the INF file are recorded which should make it a lot easier to convert from REG to INF.

Remove the WMP11 subfolder and run HFSLIP again. Does HFSLIP remove it after creating it again? I think the most probable cause of your problem is that you browsed into the HF\WMP11 folder that HFSLIP created and didn't get out of it before HFSLIP tried to delete it. DOS can't delete a folder if it's opened in a window at the same time; it will only remove its content. Super-Magician... The only problem with your suggestion is that "IF EXIST HF\WMP11\*.*" always returns "true" and "IF NOT EXIST HF\WMP11\*.*" always returns "false" even if the folder is empty. It's sort of a known limitation of DOS. You need to specify more than that, like "HF\WMP11\w*" or "HF\WMP11\*.exe", though that doesn't really tell us whether the folder is empty or not. One way to do that (without causing an error message to appear) is to create a dummy file, then set a variable based on whether there are any other files in the folder besides the dummy file and delete it afterwards but that would take things too far. So I could use "HF\WMP11\*.exe" but I'm not sure if it's really that important. Making this change would require adding the line "IF EXIST HF\WMP11 RD/Q/S HF\WMP11" between the brackets, otherwise people might get an error message like "Folder already exists" when HFSLIP tries to create it. This adds an extra IF condition and I'm not sure it's really worth it.

I'm either using InstallRite from Epsilon Squared or ART (Advanced Registry Tracer) from Elcomsoft. According to the info on their web sites, both programs are compatible with NT4. I see Epsilon Squared also has a program called InstallWatch but I never tried it yet. As far as ART goes, I normally use version 1.5, which is free, but doesn't work in a VM. The latest versions work in a VM but they have a 30-day trial period.

The HFCABS folder is only for CAB files with specific names. But even if you repacked everything into a CAB file with a supported name it wouldn't work because the three packages mentioned above need to be placed in a special folder, in packed and unpacked format. Personally, I see no reason to add support for these CAB files into HFSLIP (at least not into the main HFSLIP utility) because they are downloaded automatically, and because they are rechecked every time. HFSLIP only supports the files jvidal mentioned so the user doesn't need to do anything extra.

If the source is XPMCE and you're slipstreaming WMP11, the latest test release will take EasyCDBlock.inf, wpdtrace.dll and the CAT file from KB913800. How does Windows Update react to that?

OK. Windows 2000 will only register the file if "RegisterOCXs" is used. Neither Windows 2000 nor Windows XP show a problem if both "RegisterOCXs" and "RegisterDLLs" are used so I updated the package so both registration methods are used. Thanks for the heads up

I can confirm this. It's probably due to the recent change in the custom package from "RegisterOCXs" to "RegisterDLLs". Windows 2000 seems more strict. I'm going to test if all Windows versions accept BOTH a RegisterOCXs and a RegisterDLLs section. Meanwhile, you can work around this by running regsvr32 %WINDIR%\SYSTEM32\Macromed\Flash\Flash9e.ocx from the Run prompt.

I hope you checkmarked IE6, DX9, WMP9, and any other upgrade you want to do on my hotfix list page before comparing the resulting list with what you have....

The Dutch link is in the list. It's below "Chinese (Traditional)" in the dropdown list. Thanks anyway

KB870669 is not supported because it is a Type 2 hotfix while HFSLIP generally treats hotfixes with "Windows" in their name as Type 1 hotfixes. Support for "exceptions" is added as necessary. Adding support for KB870669 isn't necessary because that hotfix adds a killbit which is also added by the latest cumulative update for MSIE. This means that you don't need KB870669 anymore when installing the latest cumulative update for MSIE. The problem with your approach is that Windows Update shows you all hotfixes it has ever shown for your OS base, including those which have been replaced by newer hotfixes or a combination of newer hotfixes. My hotfix list doesn't show the ones which are replaced. When a hotfix requires "additional attention" (such as KB870669), support may be added into HFSLIP, but when such hotfix is later replaced by a newer hotfix (as is the case here) the "additional attention" for the older hotfix is removed from HFSLIP over time. Examples: - most workarounds for the problems with the first version of the Update Rollup are removed because they were fixed in the second version - additional support for Type 2 hotfixes for MSIE and MSOE was removed because they are all replaced by newer Type 1 hotfixes So slipstreaming all hotfixes that Windows Update shows you is a bad idea. Just use my list. Windows Update may be dumb enough to show you all updates, but at least it's smart enough to not show you old updates if you have the newest installed.

The only thing of importance that KB946627 does is add one value into the registry: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_PROTECT_DECOMPRESSION_FILTER_FROM_ABORT_KB942367] "*"=dword:00000001

HFSLIP - Basic how-to HFSLIP - Windows update lists