Tomcat76

The latest test release supports a setting to disable this functionality.

You're right. The one I'm linking to now is the same as the old one I had. There is a new version (containing binaries from Dec 2006 and Jan 2007) for Win2K which is downloadable from the link I USED to have in my hotfix list, but that one can't be extracted from DOS as I pointed out in the initial post. Luckily, Windows Update doesn't ask for it. I suppose I didn't bother or forgot to check the file dates in the 2K roots update I'm linking to now...

Thanks. Link corrected. And please only use it with HFSLIP 70211a or higher...

Answered in the other thread. Yes; WindowsXP-KB922120-v5-x86-ENU.exe. Yes. And also for feedback on the usability of the "alternate input folders" feature.

As explained in the main topic of this thread, the complete merged installer installs the components in the following order:1) .NET 2.0 2) .NET 3.0 extras 3) .NET 1.1 A reboot is required if you want to install any .NET 2.0-dependent programs afterwards. HFSLIP questions are answered in the HFSLIP forum.

There are several problems with HFGUIRUNONCE in the previous test releases that have been fixed. Please use the latest version. Any issues with HFGUIRUNONCE should be posted in this thread until this feature is available in a "final" version of HFSLIP. After that, start a separate thread. The main post in the .NET 1.1/2.0/3.0 thread is intended as an informative post. Any hotfix goes in HF except otherwise noted. This is mentioned on the Basic how-to page and in several other locations. So the Power Shell installer goes in HF, and .NET 2.0 must be placed in HFSVCPACK. HFSLIP will instruct Windows setup to install Power Shell at first GUI logon. HFSVCPACK_SW is for installers that need switches. TimeZoneSetup.msi and UFDSetupWizard.msi require .NET 1.1. A limitation in HFSLIP requires you to place .NET 1.1 in HFSVCPACK and those two MSIs in HFGUIRUNONCE. I'll fix this in the next version so that you can place those MSIs in HFSVCPACK_SW. Windows Desktop Search is unsupported as a hotfix. All binaries inside this executable need to go into Program Files and a lot of them exceed the 8.3 file naming standard, so support would have to be hard-coded into HFSLIP. You should try to find an addon. I'll make one if I have the time. Don't know about 6). Try the latest test version with every file in the correct place. MSIFIRSTLOGON won't return because it's less powerful than the HFGUIRUNONCE folder.

@the_guy Check out the HFSLIP Preparation Tool

Download HFSLIP-prep.zip This tool slipstreams a Service Pack if required and merges DRIVER.CAB with SP#.CAB. Advantage: if HFSLIP doesn't encounter any updated driver binaries and you selected merging option A, B or C, DRIVER.CAB will no longer have to be merged with SP#.CAB because the latter doesn't exist. Supported Service Packs: any that's supported by HFSLIP except USP5. This will be supported in a later release. Your CD source goes in a folder called SOURCE and the Service Pack installer (network installer) goes in HF. For safety, also copy over the files that exist in the root of your CD. - HF - SOURCE - HFSLIP_prep.cmd If you already have an existing HFSLIP folder structure, just copy this tool into the same folder. NOTE Some people seem to have problems slipstreaming updated driver binaries coming from hotfixes into the source that's created with this tool. If you're getting several occurances of "0 files copied" while the new driver binaries are processed by HFSLIP (a bit after DRIVER.CAB is expanded, when the message "Adding updated driver files from hotfixes" appears), then you should revert to your previous source and don't use this tool again. I can't duplicate this problem so it's unlikely it will be fixed any time soon.

S3pHiroTh... The download link for the version for WinXP/2K3 is in the first post of this thread. The updated version for Win2K is in my 2K hotfix lists. There's no need to rename it.

I don't see a problem with that hotfix. Have you tried downloading it again?

KB896344 is only needed for English and Japanese versions of Windows. You don't need it. You can safely use the English version of KB928089 because the files that it updates (ieapfltr.dll and mshtml.dll) are not localized. This update is optional, though.

If IE7 hotfixes are found in the HF folder, a new IE7 installer is created in which those hotfixes are slipstreamed. This is done with iexpress.exe, but Windows setup won't allow the output file to be copied over from CD to the hard disk if it isn't modifyPE'd first. ModifyPE is only really needed if doing a non-SVCPACK install (not specifying IE7SVCPACK=1) of the newly created IE7 installer but I decided to keep things more simple by making it a prerequisite either way.

Funny... When I tested it, Windows Update complained about KB929120, not KB928388. Either way, the new update is cumulative so the latest test release of HFSLIP uses a registry hack to keep Windows Update quiet about KB929120. Looking clean to me....

HFSLIP doesn't slipstream any .NET version (or update), but silent installers are supported. .NET 1.1 from RyanVM or RogueSpear Location: HFSVCPACK or HFGUIRUNONCE .NET 2.0 from RogueSpear Location: HFSVCPACK or HFGUIRUNONCE .NET 2.0 from RyanVM Location: HFGUIRUNONCE .NET 3.0 from RogueSpear Location: HFGUIRUNONCE Notes... RyanVM's .NET 2.0 cannot be installed at T-13, so don't put it in HFSVCPACK. If you install .NET 1.1 and .NET 2.0 in one go (ie, put both in HFSVCPACK or both in HFGUIRUNONCE) then any applications which rely on .NET 2.0 and are placed in the same folder will fail to install. Possible solutions: 1) Don't include .NET 1.1 2) Place .NET 1.1 and .NET 2.0 in HFSVCPACK, and all programs that need .NET 2.0 in HFGUIRUNONCE 3) Place .NET 2.0 and all programs that need .NET 2.0 in HFSVCPACK, and .NET 1.1 in HFGUIRUNONCE If you need the language packs as well, you're better off creating your own silent installers. You can use this tool for it.

In his first post, he wrote: the language pack for Internet explorer when you visit a foreign websites They aren't called language packs, but OK. These can be installed during Windows setup already. On the Regional Settings dialog, click the Languages tab and tick the checkboxes that need to be checked: * complex script and right-to-left languages * East Asian languages I don't know how this can be done unattendedly. Someone else will have to drop in for that.

I suppose Windows Vista doesn't have the registry key that I'm looking for. And if OPUC.DLL won't copy, it means modifyPE.exe failed to run. It's probably not compatible with Vista (yet). I need to buy a copy of Vista (Home Premium or higher) for my father so I'll be able to experiment a little in a few days.

I think only Oleg can help you with this or the people at the places where he got all the info from. I never experimented with this myself and I don't have an Intel machine at my disposal either.

bbmak is talking about the extra languages you can install during Windows setup (Asian, etc) for Internet Explorer.

You can check out the latest test release if you like, or wait till the next final. Your call...

70207a, at your service... Sir!

OK... I see the problem. Good idea to ask you for the TXTSETUP.SIF file...

That's alright. You think the HFSLIP code is clear? I'll make another test release and then we'll hear it soon enough if it breaks DOS-based installs, but I personally doubt it if the files are still present in the [Files] section.

Ah, you copy them... So not this: [FloppyFiles.2] d1,SYSFILE1.SYS d1,SYSFILE2.SYS But this: [Files] d1,SYSFILE1.SYS d1,SYSFILE2.SYS [FloppyFiles.2] d1,SYSFILE1.SYS d1,SYSFILE2.SYS

Super-Magician... You can test something for me but I'd first like to see the TXTSETUP.SIF and DOSNET.INF files from SOURCESS\I386. I need to make sure everything's alright there.

Hey Jazkal... 1) Just the SYS files? 2) That won't break a local, DOS-based install?