Tomcat76

The T-13 installation is the best method I'd say because there are no "serious" issues with it, except that it may take a little longer to install compared to the installation at first GUI logon. I haven't actually checked yet if some of the registry tweaks fail with that method but I think they do. I'm beginning to suspect that they fail when that small Windows Update box in the top left corner at GUI logon which does the final internal updates to IE among other things, is doing updates for IE7. The final internal updates to IE occur at these times: - when slipstreaming: at first GUI logon - when using the T-13 method: at first GUI logon - when using the first GUI logon method: after the second reboot The registry tweaks that you put in HFGUIRUNONCE are always executed at first GUI logon, and during my testing they never failed using the last option so I'm starting to believe that there's a conflict if the final internal updates that Windows does at first GUI logon are for IE7. If you let HFSLIP instruct Windows setup to install IE7 at first GUI logon (the default), then the Windows Update box at first GUI logon doesn't update IE; it is deliberately postponed by the IE7 installer, so there's no conflict there. But that's just a theory...

I don't think it's feasible or possible for hotfixes that are slipstreamed. The required registry entries to make these updates appear in Add/Remove Programs are not created by the INF file included in the hotfixes but by their setup program. Also, HFSLIP is meant to be used for any language of Windows so I can't have "Update for Windows XP (KB929969)" shown on a Spanish version of Windows. For the most part, HFSLIP does what slipstreaming a Service Pack does. You don't see an entry in Add/Remove Programs for the Service Pack when you had it slipstreamed...

I don't see any other just by looking at your files. The only thing I can suggest at this point is that you do a test run without addons, and only the hotfixes that are on my dynamic list. The entry in Add/Remove Programs is one way to verify if things went OK. Not creating that entry removes that check.

The hotfixes that are slipstreamed don't show in Add/Remove Programs. The few updates that are not slipstreamed but installed "normally" during or right after Windows setup (MDAC 2.8 SP1, Malicious Software Removal Tool, etc.) are installed with the /nobackup option. The ghost entry in Add/Remove Programs for the hotfix for MDAC 2.8 SP1 is removed if using HFSLIP 1.4.0 or newer because it can't be uninstalled. The only Add/Remove Programs entries you should see are for the files you include in HFSVCPACK, HFSVCPACK_SW and HFGUIRUNONCE (like MSI files). I believe there's also a ghost entry for Internet Explorer 7 if it wasn't slipstreamed but installed at T-13 or at first GUI logon.

@Glentium Still the same: version 1.6d released April 27, 2005. This is about the third or fourth time. I don't know what's going on there...

Remove 5er_WMPLyricsPlugin_Addon.7z (asks to put "WMPLyric.dl_" in TXTSETUP.SIF and DOSNET.INF instead of "WMPLyric.dll"). There is something wrong with the Foxit addon you're using. Get this one instead.

Did you makecab msobmain.dll before putting it in the FIX folder? You don't need the English version of the hotfix if you have the Italian files, btw. The INF file within the hotfix only adds info into the registry confirming that this particular hotfix was installed, something that would be necessary if KB898543 (or whatever hotfix the msobmain.dll file that you are using is coming from) appears on Windows Update, but Windows Update doesn't show it so all you need is the Italian msobmain.dll and the accompanying CAT file. Theoretically, it should work with the compressed DLL in FIX and the CAT in SOURCE\I386\SVCPACK; just ignore the warning about having an unclean source. But remove the English hotfix from the HF folder.

There is something wrong there, but whatever I was thinking of didn't cause it. It seems as though the system on which you are running HFSLIP doesn't have FIND.EXE in the system32 folder.

You get the "directory already exists" message because I didn't anticipate you running the script more than once. It shouldn't cause a problem but if you want to get rid of it, change the 3rd line to: IF NOT EXIST D:\_drivercab MD D:\_drivercab Try changing the value of CompressionMemory from 21 to 18. This could indicate a memory issue...

I think I may have a clue, then. Can you run HFSLIP again WITH swflash.cab, then ZIP SWFLASH.IN_ from both the SOURCE\I386 and the SOURCESS\I386 folder (you can rename them), and attach the ZIP here? Thanks...

It could be the combination of these three: WindowsXP-KB905474-ENU-x86.exe WindowsXP-KB905474-ENU-x86-Standalone.exe LegitCheckControl.cab Remove the first and see if it helps.

StepByStepInteractiveTraining-KB923723-x86-KOR.exe is not supported because it's an update for Step By Step Interactive Training which is not part of Windows. I see you use SPXCAB. Did you change the reference to driver.cab in all INF files to spx.cab?

Well... From the INF file of KB928470: This Hotfix can be installed only on Windows PrePaid or Subscription SKU. And it checks for the existence of HKLM, "SYSTEM\WPA\PreOrSub", Installed, 0x00010001,"==",1 or HKLM, "SYSTEM\WPA\PreOrSub", Installed, 0x00010001,"==",2

Don't forget to read this, then:Handling of Windows Internet Explorer 7

You can try this CMD file: @ECHO OFF SETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION MD D:\_drivercab ECHO>CABBER.DDF .Set Cabinet=on ECHO>>CABBER.DDF .Set Compress=on ECHO>>CABBER.DDF .Set CompressionType=LZX ECHO>>CABBER.DDF .Set CompressionMemory=21 ECHO>>CABBER.DDF .Set FolderSizeThreshold=5000000 ECHO>>CABBER.DDF .Set MaxDiskSize=CDROM ECHO>>CABBER.DDF .Set CabinetNameTemplate=DRIVER.CAB ECHO>>CABBER.DDF .Set DiskDirectory1=D:\_drivercab FOR /F %%I IN ('DIR/B D:\files') DO ECHO>>CABBER.DDF D:\files\%%I MAKECAB/F CABBER.DDF DEL/Q/F CABBER.DDF SETUP.INF SETUP.RPT

Now I'm confused. Didn't you say that .NET 3.0 didn't install?

If you are referring to the HFSLIP entry... You could consider it a confirmation that HFSLIP was used to update your CD. If you used a recent version of HFSLIP, you can easily remove it by clicking the Change/Remove button. ModifyPE.exe is mandatory in some situations:- when integrating IE7 (not slipstreaming) [this is actually not the case for Windows XP in the current final; I should rectify that] - when slipstreaming Office Update engine (OPUC4.CAB) - when one or more of these HFEXPERT folders are used: CODECS, APPREPLACEMENT and WIN

yes it did ... quite sometime actually would this be bad?No; this is normal, and it indicates that HFSLPGUI.CMD is executed at the right time. But .NET 3.0 is not in Add/Remove Programs afterwards?

The last few test releases rename that file (as mentioned in the changelog). It's supposed to happen. From the INF file:[MSI31.System32.files] msi.dll,SP2QFE\msi31.dll Well... I'm lost then. All files are in the new source, TXTSETUP.SIF and DOSNET.INF are instructing Windows setup to copy them over during txtmode copy, and HFSLIPWU.INF has the correct info to install them. I don't know what could be wrong with your set up, and especially why all of the sudden the HFSLP200~ files cannot be found by Windows setup either. these all came up after window to register ...OK. Did these .NET 3.0 components take a while to install?

HFGUIRUNONCE supports .REG files. They are executed after the Welcome screen, but before the desktop, Themes, etc. are set up. If the .REG file needs to be executed AFTER that, you're out of luck. Remember that if you import registry settings through HFGUIRUNONCE that require a reboot, you'll have to reboot before they take effect. It just occured to me that I forgot to document the HFGUIRUNONCE folder on the HFSLIP site once it became final... Will be fixed, hehe...

I think you don't understand me too well... The ONLY time HFSLIP looks for "a CD with Windows on it" is to extract the boot image. HFSLIP creates a list of drives which have the I386 folder in the root and uses the last one encountered. All drives are checked except the C: drive. So if Z:\I386 exists, HFSLIP will attempt to get the boot image from there. The version of Windows is not important (nor is the language).

450... When slipstreaming WMP11, you need WindowsXP-KB898543-v3-x86-ENU.exe in the HF folder as explained here. MSOOBE will be broken if you don't. With KB898543, you will see the text "Please wait..." below the big Windows logo after the final reboot of Windows setup, but it's only once. MSOOBE is fixed and that is the important thing. If you want the Japanese text to be displayed, you need to contact Microsoft by phone because KB898543 is not public for non-English languages.

No... Are the files physically present on the CD from which you installed your HFSLIPped copy of Windows? Open the CD, go in the I386 folder and see if hfslp101.inf through hfslp103.inf are in it. Seems OK. For DNF30.exe, you should've seen the installation dialogs pass by (Windows Presentation Foundation, Windows Communication Foundation and Windows Workflow Foundation). If you've seen these, was that at T-13 or at first GUI logon?

I mean: are HFSLP101~103.INF still present on the CD from which you install? That codec package contains the WM10 versions of the files you mentioned so it isn't compatible with a WMP11 slipstream. Well... If you have DNF30.EXE in HFGUIRUNONCE, you can easily find out if something went wrong by checking if the WebClient Service is working properly: Control Panel > Administrative Tools > Services. Based on my testing, the WebClient service will fail to start if .NET 3.0 is installed at T-13. What exactly does this mean for us?I don't know yet. I changed a few things and did some tests but so far had no success. A search on the Internet didn't come up with anything useful either. I prefer to have this fixed before the next final, of course.

Updated "known issues" list for IE7 slipstreaming: PNG transparency doesn't work. --> showstopper