Tomcat76

Visual C++ 2005 slipstreaming requires quite a bit of file renaming (long file names) and one file needs to go in Program Files. If I ever add support for this, it will be from an external HFSLIP_PRE*.CMD file. I forgot about the "I have read the instructions" bit. Create a file named HFANSWER.INI in the HFTOOLS folder and add this in it: RELEASE=AUTORUN AHTEST=i have read the instructions SBOOTPATH=1 Then run HFSLIP with the special command.

IE6.0sp1-KB833989-x86-ENU.exe - not supported - replaced by IE6.0sp1-KB938127 IE6.0sp1-KB887797-Windows-2000-XP-x86-ENU.exe - replaced by OE6.0sp1-KB923694 IE6.0sp1-Windows2000-Q831167-x86-ENU.exe - not supported - replaced by IE6.0sp1-KB937143 js57nen.exe - is this a renamed scripten.exe? Windows2000-KB829558-x86-ENU.exe - replaced by KB891861-v2 (rollup) Windows2000-KB896422-x86-ENU.EXE - replaced by KB891861-v2 plus KB923414 Windows2000-KB917344-56-x86-ENU.EXE - don't use when slipstreaming WSH 5.7 Windows2000-KB924867-x86-ENU.EXE - replaced by KB935839 Windows-KB870669-x86-ENU.exe - not supported - replaced by IE6.0sp1-KB937143 WindowsMedia9-KB891122-x86-Global-ENU.exe - not supported - you need wmfdist.exe from this update if you want the latest codecs WindowsMedia9-KB911565-x86-ENU.exe - replaced by WindowsMedia9-KB936782 WindowsMedia-Q828026-x86-ENU.exe - replaced by KB891861-v2 plus WindowsMedia9-KB936782 wmv9VCMsetup.exe - not supported It's not outdated; it just doesn't update any files. Well... The purpose of HFSLIP is to update Windows components. That would be beyond its scope. There's a command you can use but there's no visual output (you don't know when HFSLIP has finished):hfslip-70901a.cmd >> output.txt

I don't look at the MS pages for that. I checked the files that are inside those hotfixes, and the update rollup (KB891861-v2) contains newer versions of these. I don't actually know if the newer file versions from the rollup fix the bugs that are described in KB820888 and KB822831, but I do know that if I added support for these HFSLIP would take the newest files, which are the rollup files. The outcome would be the same.

The drive letter shouldn't make any difference. I suggest you run a chkdsk /r on your F: drive.

Is this HFSLIP-related?

The WMP11 package is a Type 2 hotfix.

I think it wouldn't help that much: js56nen.exe -- replaced by KB917344-56 KB820888 -- replaced by the rollup update KB822831 -- replaced by the rollup update Q818043 -- updates rastapi.dll to 5.0.2195.6738 (other files are replaced by SP4, the rollup update and KB911280-v2) Q817472 -- updates atapi.sys to 5.0.2195.6741 So basically, only those two Qxxxxxx hotfixes remain. They are supported in the HF folder if you use HFSLIP test release 70901a (which also removes the useless subfolder named "56bit"). If you prefer to use a final version, you have two options: 1) Copy those two Qxxxxxx hotfixes in the HF folder and rename them so they have the word "Windows" in their name OR 2) Create a folder named NOREG inside HF and place those two hotfixes in there; there's no need to rename them as HFSLIP treats files in this subfolder as Type 1 hotfixes by default HFSLIP 1.6.2 doesn't yet remove the useless "56bit" subfolder so you'll have to do that yourself. Hope this helps....

Try this special version of HFSLIP. It detects when the TEMP folder was not deleted after processing a hotfix and creates TMPDIR.TXT which contains a directory listing of the TEMP folder. Please ZIP TMPDIR.TXT and attach it to your next post.

It's still the same version. MS just likes to update the dates on their download pages once in a while. Thanks anyway....

Sounds like MS... Thanks for the heads up.

MS are now pushing the latest version of MUWEB_SITE.CAB (July 30, 2007). Just download it again; the link is still the same. Concerning KB935448... Do you have a Realtek or similar sound chip?

I don't see no difference either. The digital signature is still the same as well.

This usually means that the last hotfix which "appeared" to be processed correctly is corrupt. See where the problem starts and look at the name of the hotfix that was handled just before that. Delete it and download it again.

The handling of I386 subfolders was changed not so long ago because someone had the opposite problem you have. Try the latest test release (70828a). It replaces both the compressed and non-compressed versions of binaries (if they exist) in I386 subfolders.

HFSLIP doesn't work on Vista because it thinks you are not running as administrator even when you are. Aside of that, modifyPE.exe doesn't work on Vista but that file (utility) is needed in some situations.

Right. There's a problem with RunOnceEx in the base IE7 package and MS (partially?) fixed this in the updates.

Do you have both a CONTROLS.MAN and a CONTROLS.MA_ file in the original I386\ASMS\60\MSFT\WINDOWS\COMMON\CONTROLS folder? Do you notice a difference when you compare the new file in the SOURCESS folder after running HFSLIP 1.5.0 with the new file after running HFSLIP 1.6.2?

If you're using special characters that might explain things.

This source is modified with BCD and other things. If the SVR_2003 folder contains the original source, you should copy the content of SVR_2003 into the HFSLIP\SOURCE folder. Any other scenario is not supported by HFSLIP. The hotfixes in the SVCPACK folder are non-public so I can't check if they are supported or not. Either way, they won't install if you leave them in the SVCPACK folder. Move the executables into HFSLIP\HFSVCPACK_SW1 (provided those are Type 1 hotfixes). You can remove the entire SVCPACK folder and the SVCPACK.INF file as well but that's not a necessity.

In theory, yes, but some adjustments may be in order to support it properly. Is there an SPX.CAT file in the I386 folder? If not, a WIN51XX.SPX file in the root? Do the executables in the SVCPACK folder also contain the separated CAT files?

Just be careful... I haven't looked into that yet. Should've mentioned that in my previous post... Sorry...

I may revert to KB885626-v2 on my list. I'll think about it. BTW... Uninstalling KB936357 is irrelevant in the context of HFSLIP as I386\UPDATE.SY_ is replaced directly.

You can use test release 70821a, but in your case I'd strongly recommend to remove the update that contains EasyCDBlock.inf (KB913800) because it's for WMP10. Worse: it contains quite a lot of the binaries that make up WMP10 and I'm sure you don't want HFSLIP to leave you with a mix of WMP10 and WMP11 core files...

That update is not on my list. It looks "standard" to me but I'll have to test this.

HFSLIP renames the new danim.dll to danim2.dll and places that in the new source. At T-13 during Windows setup, danim2.dll replaces danim.dll. Your problem is something else. Can you give me the HFSLIP.LOG file?