Tomcat76

I see your point, but it may be difficult to work around it because HFSLIP is slipstreaming USP5 like a Service Pack. Also, HFSLIP generally assumes that a source (with or without Service Pack) contains files that may be overwritten so there is no date check performed when copying hotfix binaries into the new source. This is OK for regular Service Packs because hotfixes are always made for a certain Service Pack level. But, as you noticed, this is not OK for USP5 because it contains unofficial hotfixes too. For the file dates to be taken into account, HFSLIP would have to treat USP5 as a giant hotfix. I'll have to see if that is at all possible. However, I think most people won't like the thought of HFSLIP treating it as a hotfix because then it would need to be done every time you run HFSLIP which kind of defeats the purpose of USP5. It would've been better if Gurgelmeyer separated the non-official hotfixes into a separate package, or made two versions of USP5...

OK. Thanks. Do you know any specifics? Are you updating the headers?

I didn't have this problem with Opera 9.21 until a few days ago so it's definitely not a problem with Opera. Also, when I make a reply and go to the subforum in which that thread resides, that thread isn't displayed at the top and the name of the previous poster is still displayed in the "Last post by" column. I have to press F5 to get the page to update. This also never happened before.

Your wish has just come true...

Alright. The new test release is in the wild. Please try it and let me know how it goes...

OK. Please stop testing for now. I rewrote all sections that handle HFSLIP.CMD and SVCPACK.INF, and am now testing if everything still works as intended on a regular CD-based install. I'll post a new test release later. For network-based installs... * silent executables will work for sure * msi files, the roots update, AutoIT scripts, reg files and inf files is still a question mark (that's for you to tell me ) * installation of Recovery Console won't work

Confirming the original problem. Opera 9.21 / Win2K.

This isn't an HFSLIP problem, you know. I can work around the "administrative privileges" prompt but that's it. The fact that OPUC.DLL has a bad header is MS's fault, and I'm not the author of modifype.exe so I can't make a version that's Vista-compatible. There are other files that need to be modifype'd too.

I'd like to have a look at HFANSWER.INI, and TXTSETUP.SIF from SOURCE and SOURCESS (to compare). Preferably those from the minimal setup.

OK, but did either .NET 2.0 *or* the roots update install? Is it needed? The PUSHD command is supposed to assign a drive letter to a network share; I'm then using DIR /B to determine the path and store it in the %HFSLIP% variable. I wish I could test this better myself but I haven't been able to find out yet how I can browse the network through a command prompt like with My Network Places.

There is one thing I don't understand. Are you including the SATA driver with your "minimal" setup too?

damian666-- I'm not really sure what you want me to do with that file. I checked English.ini in the TClock folder and don't see anything language specific. It all seems "internal code" to me and not something I'd get in a dialog window or something. The only thing I'm not sure of is the locale. My system locale is English US, but the user locale is English UK. The ini file here uses 1033 which is English US. Is that intended or doesn't it really matter? I haven't tried changing it to English UK (or to 1043 as in Dutch.ini). Other than the locale, the only difference between your Dutch.ini and my English.ini is the paths but they seem OK to me. BTW... In Safe Mode, the system doesn't hang. That's where I was checking English.ini from. I also noticed that if I use Ctrl-Alt-Del in "normal" mode, I get two "End program" boxes that could be relevant; one is for the TClock program and the other for AutoIT.exe.

Well... Here's what happens with SVCPACK.INF/SVCPACK.IN_... 1) Whatever is in your SOURCE folder is copied over to SOURCESS; this includes SVCPACK.INF/SVCPACK.IN_ 2) When the SVCPACK items are processed, any SVCPACK.IN* files in the SOURCESS folder are deleted and a new one is created This has been the case for a long time. So basically, you can leave SVCPACK.INF or SVCPACK.IN_ alone. The SVCPACK folder should be deleted manually if using the latest final. This isn't the case anymore with the current test release. HFSLIP doesn't mess with SVCPACK.DL_. I wouldn't touch that file.

Your list is fine except that it doesn't include 4 security updates from this month and one update for Windows Installer. Three hotfixes are replaced and you're advised to remove msxml2.msi. Which version of HFSLIP is this? Can you be a bit more specific about the error messages? Is Windows setup actually asking "Where's Arabic?" or is it looking for files with a certain name? When does Windows setup ask for these?

I can't believe this... I had it in my test file... Thanks @CharlyBrown: try the attached file. It will pause to display whether the variable could be defined or not, but will continue after that even if the variable couldn't be defined. HFSLIPCMD.zip

Is your Windows CD in your CD/DVD-ROM drive while running HFSLIP? This is necessary if you don't have BOOT.BIN.

That's HFSLIP 1.4.1 - not 1.5.0...

That was to be expected. The batch I gave you quits if the HFSLIP variable couldn't be defined.This is a bummer. I read on a page on the MS server that the PUSHD command was supposed to temporarily map a network folder to a drive letter. Apparantly not (or I don't get it). EDIT-- Super Magician has something. I'll give an updated batch below.

It could also be a new or revised hotfix containing ASMS files (corrupt or simply buggy), or a CD that isn't burned correctly. Make sure you allow path depths beyond the specification when burning a CD; a Windows source breaks the standard spec.

It isn't just dotnet2.exe or the roots update that fails with a network install, but anything in HFSLIP.CMD that refers to files in the Windows source. The path to the I386 folder is determined (among other things) by checking for a drive letter from C to Z, which won't do the trick for a network install. Executables used to install fine in the past because they were installed from SVCPACK.INF. But this was changed because people wanted the ability to install .NET before any MSI files that require .NET. MSI files must be installed from a batch file so the only (easy) way to accomplish this was to install the executables from the batch file as well. Replace HFSLIP.CMD in SOURCESS\I386\SVCPACK with the one that's in the attached ZIP file. Then start the network install. This HFSLIP.CMD file doesn't hide. It gives some output while the path to the I386 folder is determined in the old way, and, if necessary, in a new way. Please let me know what you see. The plan was to get this done for 1.5.0 but you're the first "network installer" to give me an HFSLIP.CMD file to work on. HFSLIPCMD.zip

Nothing special there. I hope InstallRite comes up with something...

Alright. These are clearly updates for .NET 3.0. I will update the SNM script for this when I have the time. It shouldn't be too hard to add support for them.

There's more to KB911164 than just the ActiveX fix. If you remove it but don't slipstream the latest cumulative update, setuperr.log will be riddled with errors for certain binaries. Basically, Windows setup doesn't accept its own files (those in I386). Go figure. Letting HFSLIP remove the SVCPACK folder or doing it manually is the same thing. You only need to make sure you update IE (latest cumulative IE6 or slipstream IE7). When including IE7 but not slipstreaming it (ie, first GUI logon or SVCPACK methods), it's better to also include the cumulative IE6 update to avoid the errors in setuperr.log.

Can you zip HFSLIPWU.INF and TXTSETUP.SIF from SOURCESS\I386 and attach it here? If you really feel like checking what installing the rollup afterwards does... I use a program called InstallRite. Are you familiar with it? You basically install the rollup from within that program and build an "install kit". You can then see which changes were made (files & registry). It's important you reboot after installing InstallRite (before installing the rollup through it) to keep the amount of unrelated changes at a minimum.

That would be version 1.3.0 (Feb 16, 2007).