Tomcat76

The only advise I can give is to use ONLY the very latest version of the Outlook Express Cumulative hotfix for the version of Outlook Express you are using. However, I've only experienced this problem with the previous Cumulative update for Outlook Express 5.5 for Windows 2000 (that's what you have when not upgrading to IE6). I can't remember having this issue with Windows XP or Windows Server 2003... and I'm even doing a complete slipstream (binary replacement).

If you install .NET 1.1 and .NET 2.0 (included in .NET 3.0) in the same go, applications that rely on .NET 2.0 will think .NET 2.0 isn't installed yet until the system is rebooted. The .NET 3.0 "extras" won't get installed either. Either install .NET 1.1 way at the end of your CMDLINES.TXT or install it at first GUI logon. It's not necessary to edit the registry to install .NET 1.1. Something aside... The WebClient service will be broken if you install .NET 3.0 at T-13. I don't know if that's also the case if installing it at T-12.

It has a higher priority: if you set both to "1" then only INCALLSKINS will be taken into account since there's no need to copy the Classic skin twice.Just note that all HFSLIP does is copy them over into the skins folder. Whether or not they are compatible with WMP 9, 10 or 11 is something else. Perhaps if I understood their intended purpose... This feature is mainly for people who don't have a lot of disk space but wish to create different outputs. Instead of creating --say-- five HFSLIP working folders each containing a copy of the CD source, you can now have five working folders with only one containing the CD source. The FDVFILES, HF, HFCABS, HFCLEANUP and HFTOOLS folders are also cumulative (they only exist in the "main" working folder alongside the source). FIX, HFEXPERT, HFSVCPACK, HFSVCPACK_SW and HFGUIRUNONCE can exist in both the main working dir as well as in any alternate working folder you create.

You should be seeing four files, but it should be these: HFGUI1.EXE HFGUI2.EXE HFSLPGUI.CMD HFSLPGUI.INF

@Super-Magician 1) Do you have any files in HFGUIRUNONCE? 2) Is HFSLPGUI.INF present in SOURCESS\I386? 3) Do you see any references to HFSLPGUI.INF in SOURCESS\I386\TXTSETUP.SIF? 4) Is "1200 = HFSLPGUI" defined in SOURCESS\I386\TXTSETUP.SIF? I just finished a test with a fully updated XPSP2 source including .NET1/2/3, Adobe Reader 8.0, JRE 6.0, four addons (Sidebar, FGCBA Handler, VistaUAP and VAIOXP-b2) and some dummy INF and CMD files... Works as intended...

Hope the new version is better...

Is it the same problem? I don't think TommyP uses HFSLPGUI.INF. BTW... You are the second person for whom the GUI stuff runs at T-13. I don't get it... This NEVER happened to me. I'm aware of some problems and they'll be fixed.

@TommyP I did that intentionally because I noticed that the CMD file that runs at first GUI logon (HFSLPGUI.CMD) would quit too soon if I didn't use START/WAIT for every line. I assumed that the same problem might occur with HFSLIP.CMD at T-13. Does this break installation of INF files? Another thing... The syntax rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 filename.inf seems to produce an error message at first GUI logon. I'm forced to do it like this: rundll32.exe advpack.dll,LaunchINFSection filename.inf,DefaultInstall Shouldn't it be done like this in HFSLIP.CMD as well?

If that were the case that would be my problem but I think it's not the case so it's not a problem

given this setup, dotnet1 & 2 would install before 3 this one calls for placement in HFGUIRUNONCE, right?When installing .NET 1.1 and .NET 2.0 without rebooting in between, .NET 2.0 is not capable of identifying itself as being installed to other programs. This means that if you insist to install .NET 1.1 too, you only have three options:Option 1: SVCPACK = .NET 2.0 + applications that depend on .NET 2.0 first logon = .NET 3.0 extras and .NET 1.1 Option 2: SVCPACK = .NET 1.1 and .NET 2.0 first logon = .NET 3.0 extras and any applications that depend on .NET 2.0 Option 3: SVCPACK = .NET 2.0 + applications that depend on .NET 2.0; and way at the end .NET 1.1 first logon = .NET 3.0 extras Note: ".NET 3.0 extras" = "Vista extensions" = .NET 3.0 without .NET 2.0 .NET 2.0 is part of the .NET 3.0 package you download from Microsoft so I decided not to make the output file's name longer than necessary. If they check for it during installation they will fail to install, but I don't know of any that require the .NET 3.0 extras. If they require .NET 1.1 they will succeed; if they require .NET 2.0 they will fail.Options 1 and 3 as mentioned above are your best bets. Of course, you can also use Option 3 without .NET 1.1....

At this point I'm more interested in comments on the "alternate input folders" feature. At the current rate of interest it won't make it into the final...

@dziubek It's possible but it might slow down the HFSLIP process. I'll think about it.

Right. Nothing has changed in the way HFSLIP handles CAB files so they go in HFCABS, yes... FEB2007_XACT_x86.cab is new in this package.

Downtime... or FDV removed it. Use this: http://hfslip.org/images/hfslip-small.png

Sorry, guys. I forgot to upload it. It should be there now...

Amazing. A hotfix wrapped in a Type 1 executable, in turn wrapped in a Type 2 executable. How original... Extracting the Type 1 out of it wouldn't be enough; you'd also have to rename it. The latest test release (70203b) supports WindowsXP-KB905474-ENU-x86-Standalone.exe as is, so no need to extract or rename anything. I haven't included KB905474 in a while and haven't seen it on Windows Update lately so I'd consider it "optional".

Out.

If I were you I'd wait until it's released...

@Super-Magician... LOL... I saw that... Don't worry... B) @kenlau... Well yeah... Me...

@S3pHiroTh...

Do you have iexpress.exe in your Windows's SYSTEM32 folder? This is mentioned in the changelog. Editing HFSLIP.CMD isn't necessary if you enter the path when prompted. But this is only required if anything is going to be installed by HFSLIP.CMD.

Support for %SYSTEMDRIVE% may be added at some point but it's not top priority: installing apps can be done from HFSVCPACK and HFGUIRUNONCE. As far as I can see, the only thing you may have to do is remove the paths inside install.cmd (if you're using that).

What? They exist too?Why can't they stick to something and keep using it? I can understand them using 7z, but RAR is payware and so is ZIP. Next thing you know they'll make them in TAR and ACE... OK... I'll add support for ZIP...

@kenlau If you create a multiboot CD you need to specify the path to the I386 folder when prompted to. If it will be located in X:\Professional\i386, you need to specify Professional\ (including the backslash).

I suppose this has to do with HFCLEANUP. If that's the case, I'm the wrong person to ask: I don't manage that part of the code. I never used or tested HFCLEANUP either so I'm not entitled to give any comments.