Tomcat76

A couple of notes on IE8.... 1) Because IE8 is still in beta, its handling by HFSLIP64 may change when a newer version of IE8 is released 2) IE8 is slow to start the first time 3) If you want to check the Windows installation with Microsoft Update, click the "Emulate IE7" button on IE8's tab bar, click OK, close all Internet Explorer windows and then go to Microsoft Update (in whichever way you prefer). This is necessary because Microsoft Update doesn't support IE8.... Too standards-compliant, maybe? 4) Don't slipstream IE8 beta 1 for anything else than testing purposes; future betas, release candidates and finals of IE8 may not be able to correctly update a source that has a previous version of IE8 installed

Thanks for the heads up. The only thing is that I'm not sure if this method of integration is really that favorable. It may look nice, but it's not very upgrade-friendly. Silverlight 1.1 is too different from Silverlight 1.0, and uninstalling Silverlight 1.0 (integrated with this plugin or addon) via Add/Remove Windows Components after you have manually installed Silverlight 1.1 could cause problems.

Thanks, jimmsta. Over time (HFSLIP 2.0) we'll be moving away from the custom SWFLASH.CAB format but that's still a while to go.

And in NT4Alive it's called "DUMP"...At least it makes sense... On 2K, I thought to notice a minor speed decrease with the files from Server 2003 compared to the ones from Windows XP, but I never really timed it. What I did notice was that, with the files from Server 2003, I suddenly got those white blocks at the bottom again which are not there when using XP's files. I *hope* you don't mean "merging DRIVER.CAB with SP*.CAB"...

Uh... no. The FIX folder (replace files in SOURCESS\I386) was replaced with the REPLACE folder (replace files in entire SOURCESS folder) with HFSLIP 1.7.1 released December 2007.

So this run was fine? I'm confused now...

wpdshxr.dll is a temporary name for wpdshextres.dll from WMP11 but there is only an English and a Japanese version of the file inside the WMP11 package. You get the copy error because HFSLIP64 hardcodes an entry for it in TXTSETUP.SIF and DOSNET.INF. So you can't slipstream WMP11 with the enforced LCIDD setting for the moment.user32.dll comes with WindowsServer2003.WindowsXP-KB925902-x64-xxx.exe. See if removing this update helps. That's odd... You said it was fine before. What errors are you receiving? As far as I know, this is correct. A search on the Internet reveils that "Windows Media Player[strings]" is an existing subfolder of the 32-bit Program Files folder. BTW... npds.zip is a Netscape 4 Java plugin that's used for scripted interaction with Windows Media Player 6.4 (LiveConnect).

Languages at this point are a bit of a mystery to me. Windows XP x64 and Server 2003 x64 only exist in English and Japanese. Service Pack 2 is supposed to "add support" for 9 other languages, but only for Server 2003 and I haven't figured out yet how that works. The only thing MS have to say on it is this: "Service Pack 2 contains 9 new localized language support for Windows Server 2003 x64 SKUs. Without SP2, Windows Server 2003 only supports English and Japanese. New languages for Windows Server 2003 x64 include German, French, Korean, Chinese Traditional, Chinese Simplified, Spanish, Italian, Russian and, Portuguese (Brazilian). These language packs are not available for Windows XP Professional x64 Edition which will continue to be supported in only English and Japanese." That's all the relevant information I could find. You could try setting LCIDD=3082 (for Spanish) in HFANSWER.INI but the outcome of that is unverified. I have no plans for XPIZE, and MUI isn't planned for now (at least not for 1.0, which is scheduled for Tuesday or Wednesday).

I just remember that there is a bug in RogueSpear's installer causing the program to fail to install properly on a regular Windows 2000 system. Extract reg.exe from SOURCE\SUPPORT\TOOLS\SUPPORT.CAB and put it in HFEXPERT\WIN\SYSTEM32. Then run HFSLIP again. I think that should fix the problem. If this also fails, it's because RogueSpear's installer doesn't call reg.exe with a full path; in that case, you need to put RogueSpear's installer in HFGUIRUNONCE. But try in HFSVCPACK first.

.NET 2.0 SP1 is a full .NET 2.0 package, not just SP1. If Windows Update still prompted you to install .NET 2.0 after including RogueSpear's .NET 2.0 SP1 silent installer, it either failed to install or you downloaded the wrong package (addon instead of silent installer).

Are there any updates there that are not on my list?

I suppose you mean "REPLACE"... At least, I hope...

WMP11 should be supported now for XP. IE7 appears to work for Server 2003 as well. Weird... I have no plans for SNMx64 for the moment.

You could use RogueSpear's from his runtime collection page. You need to register to access that forum page, though.

If hotfixes came with subfolders they are only copied over into the SOURCESS folder if they already existed. At least, that's the case with HFSLIP for 32-bit OS's. HFSLIP64 would recreate non-existing subfolders in SOURCESS and copy over the new binaries in such case.

1) vcredist_x86.exe is not a Windows core component. I suppose there are a few silent installers you can find here on the forums. 2) The easiest way is to rename mpeg2data.ax to mpg2data.ax, and then put mpg2data.ax and PsisDecd.dll in HFEXPERT\APPREPLACEMENT. You will also need modifype.exe in HFTOOLS. There will be an extra PsisDecd.dl_ in the SOURCESS\I386 folder, but you can safely delete it.

MFPLAT.DLL is a WMP file. Can you zip HFSLIP.LOG and attach it here?

KB946538 is for Windows 2000 Server, Advanced Server and Datacenter Server only; not for Professional. Also, KB946538 = KB943484 and KB947890 = KB943055. Windows2000-KB943484-x86-PTB.EXE Windows2000-KB943055-x86-PTB.EXE REPLACE works like this.... REPLACE --> SOURCESS REPLACE\I386 --> SOURCESS\I386 REPLACE\SUPPORT --> SOURCESS\SUPPORT etc. So winnt.sif goes in REPLACE\I386.

It doesn't really matter. Executables in HF with "Windows" in their name are treated as Type 1 hotfixes, apart from a few that are blocked or filtered out as Type 2 hotfixes.

I removed KB931374 from the Windows XP SP2 hotfix list because it doesn't apply. It's an update for ADAM, which doesn't come stock on a Windows XP installation CD. Slipstreaming the hotfix is harmless, though. You will end up having a useless DLL (adamdsa.dll) in the wrong place (C:\WINDOWS\system32 instead of in C:\WINDOWS\ADAM), and the registry entries are just identification keys that aren't even used by Windows/Microsoft Update.

It's supported with test release 80331a, but you need to use this version because the one on the Download Center is too old. *Edit* Forgot to mention... When not slipstreaming IE7, you should also include WindowsXP-KB915865-v11-x86-ENU.exe (xmllite.dll). This is required.

@RudigerMK2: thanks; I updated the list @ricktendo64: it's always here

OK... I can see why that's happening. HFSLIP64 sets the value to "21" in the beginning, and then HFANSWER.INI is polled but the default HFANSWER.INI I had online (v1 and v2) blanks it out again. Please set the value to 21 (or any value between 10 and 21) in HFANSWER.INI or grab v3 of the default HFANSWER.INI. I'm in the process of improving the code that handles DRIVER.CAB and SPX.CAB a bit. I'll also try to find a way to work around the problem you're having should the user have manually entered an invalid value.

As far as I can remember, that's always been the case for the full package. The standalone KB917344 update is not (because it's a security update). (Note aside: I used to have a link to standalone update on my XPSP2 hotfix list until a few weeks ago when I replaced it with KB942840. This newer update is not intended as a security update (it's only built on top of KB917344) and so this one does require validation. I made the switch on my list anyway because Windows Update wants you to have it.) But the main problem remains: why haven't MS fixed the problem with Windows Script 5.7 after confirming it? It's just impossible to slipstream it.

Well... It isn't the AutomaticUpdates setting (at least, that's what you said earlier). But the DriverSigningPolicy variable could be a problem now that I think about it. HFSLIP has always set Driver Signing to "Ignore" at T-13 via a registry edit (so actually you don't need to do that) but I once tried to have it injected into the registry through an INF file that is installed from TXTSETUP.SIF (at the end of txtmode copy). When I did that, I got all sorts of error messages during Windows setup. So I think Windows setup can't handle "tampering" (as Microsoft calls it) with the Driver Signing Policy setting at such an early stage if hotfixes are slipstreamed. It seems to be OK at T-13.