Tomcat76

OK. You're right. The KB839645 page doesn't say that it replaces KB841356 (which is why I kept it), but now I see the latter only contains an update for shell32.dll for which a newer version exists in the former. I'll also update my pages to the 13th COM+ Rollup for XP and 2K3. Thanks.

Which are the replacing hotfixes?

I can't tell you much about mkisofs. It's renaming files but the question is whether it updates the TOC so any requests for "MSCONFIGx.cp_" (by Windows setup) are redirected to "MSCON000.CP_". Do all those programs install properly?

HFSLIP deletes "junk" files, and sometimes hotfixes are given special treatment. In these cases it's possible that no additional files are left to be copied over after a hotfix has been processed completely. So it's normal. I can only get rid of the "0 files copied" message by disabling all copy output, but I think most people would prefer to see the names of the binaries that are processed.

Yes, it's resolved. I got side tracked by the fact that 414 new files don't end up in the slipstreamed source, which appears to be normal. False alarm, hehe... <offtopic>Kramy... Your links never work for me. Are you using a custom board layout? The last one for example goes to page 41 but post #600 is on page #40 here...</offtopic>

Hahaha... You won't believe this... I tested a USP5-slipstreamed source with 60527b, which had the file copy errors. In 60527c, I fixed another problem related to USP5 and mentioned in the changelog something like "fixed problem with USP5; one more to go". Now I see that that fix actually fixed the main problem, hehe. I got side tracked in investigating this problem because, when you extract the USP5 executable, you can see there are roughly 414 files in that i386 folder which don't end up in the slipstreamed source. This is apparantly normal.

Heh... I think the problem lies elsewhere. Can you do me a favor and try this test release? Just run it and do the first portion of install to see if you get file copy errors. HFSLIP_60529a.7z

If you're referring to USP5, then there's still one more thing we didn't cover. See the executable inside the SVCPACK folder?

Why does it require another dir level? BTW... You MD SPEX\SP but you extract the service pack into SP and the sliptreaming command uses the SP dir as a base without CD'ing into SPEX first. Anyway, I'll check it out. Maybe there's a problem with the folder name "SPEX".

Which browser? If it's IE, you need at least version 5.5. It should work on version 5.0 too but there might be minor display issues. If you're using IE on Windows XP SP2, make sure Active Scripting is enabled (this is blocked by default). I don't know the "minimum" browser versions for Opera and Mozilla-based browsers either but everything works as intended in Opera 9 build 8432, Mozilla Seamonkey 1.5 (20060401) and Mozilla Firefox 1.5 (20051111).

I tested Win2K SP4, WinXP SP1 and WinXP SP2 thoroughly this weekend and everything was OK with MSXML3.MSI. I just did it again to be sure. The MSXML code in the current final of HFSLIP (60528) has been in place since test release 60511b. It was changed a little in test version 60513c but that change only affects the output on the screen. Windows XP SP2 comes with MSXML3 SP5, so the only thing I can think of is that --for some reason-- the version in your CD source is newer than 25-Jan-2005.

Because, as I said, it happens outside of HFSLIP as well. This is the entire code I ran in the "standalone" batch file: MD SOURCE2&XCOPY/DEQ SOURCE SOURCE2 MD SPEX\i386&START/WAIT HF\w2ksp51.exe /Q /X:SPEX\ START/WAIT SPEX\i386\update\update.exe -u -n -o -q -s:"%~dp0SOURCE\" PAUSE

Not really. Aside from the removal of USP5 parts, TommyP added in a change to an obscure section of HFSLIP.

So how does HFSLIP_60528 sound, then?

Yep... That problem was fixed in the 27c release.Either way, the one remaining problem (414 missing files) is not an HFSLIP problem. I suggest we continue that discussion in the other thread. I've sent a new final version of HFSLIP to TommyP a couple of hours ago which is based on 60527c but has the USP5 functionality stripped out. I'll let him decide what we're gonna do...

Well... I tried just about everything. Renamed folders, disabled AV,... Nothing seems to help. At one point I even slipstreamed with just the -s switch. You know what's strange? Slipstreaming takes only about 6 seconds... and then the dialog box appears that the SP was slipstreamed successfully (this only appears when the extra switches are removed, of course).

In addition to those you list, I got these copy errors too (and twice): - win32k.sys - winsrv.dll - ntkrpamp.exe I didn't move on after the first reboot because I figured it wouldn't make sense. As I said above, I ran a batch with three simple lines (outside of HFSLIP) and it still happened so it's nothing HFSLIP does that screws things up. Your folder theory is interesting. I'll test some more....

'K... I removed it again...

Hi. I'm currently working on support for USP5.1 in HFSLIP. The problem I'm experiencing is that not all binaries seem to be slipstreamed into the source. I noticed this after Windows setup complained about 12 missing files. After a file-by-file comparison between the original source, the slipstreamed source and the folder in which USP5.1 was extracted, I saw that 413 new files were missing in the slipstreamed source. That was with the December release. I downloaded the newest version and tried it again, but the updated source was missing 414 files (ie, it got worse). This is the relevant code I use to extract the service pack: MD SPEX\i386 FOR /F %%I IN ('DIR/B HF\w2ksp5*.exe') DO START/WAIT HF\%%I /Q /X:SPEX\ That works. All files are in SPEX\i386. But then I do this to slipstream it into the source: START/WAIT SPEX\i386\update\update.exe -u -n -o -q -s:"%~dp0SOURCE\" After the slipstream is complete, not all new binaries are in the slipstreamed source (eg, faxdrv.dl_). I read the FAQ and saw that you only list the /integrate method as a way to embed it into a Win2K source but that gets me the same result. I also tried to slipstream it outside of HFSLIP (standalone batch file) with equal results. What could be wrong? System: Win2K SP4 English; logged on as Administrator. Thanks.

I'm gonna ask for support on the Hotstream forum. I download the latest version and the same thing is happening. I even slipstreamed (or attempted to slipstream) USP5 outside of HFSLIP...

I'm not sure whether or not you intended that as a joke... From the KB883586 article page: APPLIES TO Microsoft Internet Explorer 2.01

KB833989 (one of the MS04-028 hotfixes) updates VGX.DLL, and HfNetChk wants this file from MS04-028. Either HfNetChk is wrong or the info on the Download Center site is wrong. Fact is: I don't have a clue... @Camarade_Tux: If you get errors during install from a source in which KB833989 was slipstreamed I'll remove it from my list ASAP. EDIT: If you dissect the relevant Download Center page you'll see that something is wrong there. Snippet: Affected Software: Microsoft Windows XP and Microsoft Windows XP Service Pack 1 Non-Affected Software: Microsoft Windows XP Service Pack 2 So far so good. But now the "components" section: Affected Components: Internet Explorer 6 Service Pack 1 Non-Affected Components: Internet Explorer 5.01 Service Pack 3 on Windows 2000 Service Pack 3 Internet Explorer 5.01 Service Pack 4 on Windows 2000 Service Pack 4 Internet Explorer 5.5 Service Pack 2 on Microsoft Windows Millennium Edition This means that the IE-version of the hotfix also applies to Windows XP SP1. But on the download page of the IE hotfix itself, Windows XP SP1 is *NOT* listed. If the IE-hotfix doesn't apply to Windows XP SP1, MS should've added this line under the "Non-Affected Components" section: Internet Explorer 6 Service Pack 1 on Windows XP Service Pack 1 But it isn't there....

USP5 is a strange thing. Kramy already told me the other day he got file copy errors in the beginning of Windows setup and I experienced the same a few hours ago. I traced it down to the slipstreaming of the USP5 service pack itself: some binaries (413 to be exact) are not copied into the source. This can only mean two things: - my w2ksp51.exe file is corrupt - the standard MS service pack switches are not supported by USP5 I checked the FAQ on the Hotstream forum and noticed that only the /integrate method is listed as a supported slipstreaming method. So I tried that, but the result is the same. I'm now in the process of downloading the latest version... Be back in an hour or so...

Win2K with SP4 and hotfixes went OK except that the MDAC 2.5 SP3 hotfix wasn't processed. That's fixed in 60527b. Still to go: Win2K + USP5... @Camarade_Tux: That's great. Thanks

I updated my XP SP1 hotfix lists (thanks Camarade_Tux). I hope everything is OK now...