Tomcat76

The latest version of what? HFSLIP? The latest versions of HFSLIP add a line into HFSLIPWU.INF to satisfy HfNetChk as far as KB839645 for XPSP1 is concerned. Is that line with "ProtocolDefaults" present? If not, do you have the proper CD tags in your SOURCE folder? KB914798 is installed during SVCPACK (HFSLIP doesn't integrate it or even open it). I could add in the registry line you need but it will be overwritten when the hotfix installs itself so it's pointless.

Yes and no. Your question is a bit too general.If you set FORCEDELCATS to 1, HFSLIP will silently delete the CAT files that come from hotfixes. But an option to silently *not* delete CAT files (in the event you have modded SFC*.DLL files or USP5) doesn't exist. In this second case, your only option is to use the prompt (ie, don't set FORCEDELCATS to 1). Yes. The original source is restored when using that option (1=ask for backup, 2=execute backup without prompting). But this is tied to slipstreaming a Service Pack. So if a Service Pack doesn't need to be slipstreamed, a backup is never made.

Actually, Kiki, you got four options, not two. #1 HF\WindowsXP-KB905474-ENU-x86_4bafa8793e8cdcaf4ba4ffc494df32d496154544.exe FIX\LCC.dl_ #2 HFCABS\LegitCheckControl.cab FIX\LCC.dl_ #3 HF\WindowsXP-KB905474-ENU-x86_4bafa8793e8cdcaf4ba4ffc494df32d496154544.exe HFEXPERT\APPREPLACEMENT\LCC.dll #4 HFCABS\LegitCheckControl.cab HFEXPERT\APPREPLACEMENT\LCC.dll I forgot about the last two options, where you can leave the file uncompressed...

TXTSETUP.SIF instructs Windows setup to copy LCC.dll to system32 and rename it to LegitCheckControl.dll. HFSLIP adds this line into TXTSETUP.SIF if you include LegitCheckControl.cab or KB905474. If you put LCC.dl_ into FIX, HFSLIP will copy it into SOURCESS\I386 near the end of the HFSLIP run, overwriting the already present LCC.dl_. To compress LCC.dll, you can put this line in a CMD file, save it in the same folder as LCC.dll and run it (then delete the CMD again). MAKECAB /D CompressionMemory=21 /D CompressionType=LZX LCC.dll

Don't know... I'll see if I can duplicate it. But it should work when you rename the file to LCC.dll, compress it to LCC.dl_ and put it in FIX. Then include LegitCheckControl.cab in HFCABS (and remove LegitCheckControl.dll from HFEXPERT\WIN\system32). Are you using the RVM Update Pack?

I saw problems with it too yesterday so I temporarily discontinued MC2. I'll check it out again in a few days.

For individual binaries, HFSLIP does something similar to what GreenMachine posted. If that fails for you, *none* of the newer binaries would be copied over to your SOURCESS\I386 folder. I find it strange that only browseui.dll is giving you problems...

I know all about mothers and computers. Sometimes I wonder if it was a good move to teach her the shift+Delete action... Your source file seems to have the correct date. The only thing I can think of is that you're including the wrong file: KB916281 for XPSP1: IE6.0sp1-KB916281-Windows-2000-XP-x86-FRA.exe KB916281 for XPSP2: WindowsXP-KB916281-x86-FRA.exe

HFSLIP wasn't made for DOS installs. I cleared some of the "problems" in that domain in the last few months and intend to continue this so if "d1,disk1" fixes it for you I'll see if I can implement it.

@glentium... That's good to hear. Well, not good... @the_guy... That appears to be Tux's problem but I can't duplicate it. @Camarade_Tux... What file date does BROWSEUI.DL_ have in your SOURCE? If it's more recent than June 18, 2005, it won't be updated.

That you get the message for SP4.CAB is odd. HFSLIP doesn't mess with that file. I'm gonna try to see if I can work around this problem by using the same "file copy error fix" that's in use now for Windows XP.

@Camarade_Tux: #1... The key is being inserted if you use HFSLIP 60618a. I'm still wondering why it fails. Do you have this key at least: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB839645 That's the other reg key created by the hotfix. #2... Heh. It looks like HFSLIP already puts this hotfix in SVCPACK. Where are my thoughts? HFSLIP lets this hotfix install itself so there's nothing that can be done (at least not easily). If I just insert a reg key from HFSLIPWU.INF it will be overwritten when the hotfix installs. It's strange that HFNetChk complains about something that the hotfix does... #3... Fixed. The IE6 cumulative updates for XPSP1 need the RTMQFE binary versions. I forgot to update HFSLIP for the new cumulative update.

I need to set a few things straight... 1) Don't use Aserone's installers with MC2. MC2 only handles the original files from Microsoft and the silent installers from RyanVM. 2) The problem you're having with the .NET 2.0 language pack is not a problem with HFSLIP. The purpose of the HFSVCPACK folder is to have the executables in it installed from SVCPACK.INF, which is done at T-13 during Windows installation. The language file is present in SOURCESS\I386\SVCPACK, and SOURCESS\I386\SVCPACK.INF contains the line to install the language pack. This is all HFSLIP does and this is all that needs to be done. If your language pack still fails to install, it's a problem with the installer itself. So understand that the help I'm giving is beyond my "HFSLIP duties". I still need to actually test the output files from MC2 during a Windows installation. It's possible I'm doing something wrong but I've no idea what it is just by dissecting the output files. Everything *looks* fine. At this moment, I don't have the time to test this. A new version of HFSLIP needs to be released ASAP because the current final doesn't support all of the current hotfixes and that has priority.

@Camarade_Tux: #1 is odd. HFSLIP copies the installation INF from the hotfix package, and it contains the registry entry you need. So it's strange that the key isn't created. This is the relevant line: HKLM,"Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults","shell",0x10001,0x0 It could be that the "0x0" makes it fail but I'm not sure. #2 is a problem. This hotfix doesn't contain any updated binaries and the installation INF has a name (update_SP1QFE.inf) which is normally associated with an installation folder called SP1QFE which isn't present. These hotfixes are given special treatment but for some reason this fails. The installation INF (which contains the necessary info) is not handled (or at least doesn't end up in SOURCESS\I386). I also see this installation INF is doing some special stuff which is beyond the scope of a "default" install. I'm going to have it installed from SVCPACK but not before I found out why the INF is not processed for such hotfixes. I still need to check #3.

@Kiki: I already explained where the "0 File(s) copied" comes from.... The only reasons I can think of:1) You don't have NETMAP.INF in WINNTUPG 2) WINNTUPG is not in the right place (it should be in I386) 3) You have an I386 folder in the root of a local partition (eg, C:\), and there is no NETMAP.INF in there HFSLIP instructs Windows to execute the standard installation command, but with the /unattend switch added to it to make it silent.

In case you're still interested... Version 60617b allows you to have spaces in the path while parsing HFEXPERT\WIN...

60617b is "the RC", people. If no new problems have been introduced over 60528, this will be released as the new final on Sunday evening.

If your silent installer is present in SOURCESS\I386\SVCPACK and if it is referenced from SOURCESS\I386\SVCPACK.INF, then the problem doesn't lie with HFSLIP. HFSLIP only does a copy & paste... ie, it assumes that people include silent installers that work at T-13. No special treatment is given to them. It is possible, though, that the .NET 2.0 language pack suffers from the same unattended installation problem (at T-13) as .NET 2.0 itself. In that case, the MC2 script is the only way right now to make it work for you. I'm doing my best here...

That was when HFSLIP supported dotnet2.exe in the HF folder. It would be installed from HFSLIP.CMD then. But it's no longer supported so the lines you are looking for are no longer in HFSLIP.CMD. Any executable you put in HFSVCPACK ends up referenced from in SVCPACK.INF. FYI... I updated MC2 once again. I fixed the problem with merging .NET 1.1 and .NET 2.0, and I use only one extra file now instead of two.

I was about to ask to remove the space. HFSLIP doesn't use the whole path for the most part but sometimes it's necessary. It is circumvented wherever possible by quoting the paths. Most likely, the part that would take care of folders like HFEXPERT\WIN\SYSTEM32\DRIVERS doesn't accomodate for spaces in paths. BTW... I tried to edit your post but there doesn't seem to be a way anymore to get a scrollable box. So I just put it back to how it was.

Really odd. I ran HFSLIP with just one file in HFEXPERT\WIN\SYSTEM32\DRIVERS and HFSLIP responded as intended. Do you have spaces in your HFSLIP path? It's possible that the part that deals with subdirectories of WIN other than SYSTEM32 and with subdirectories inside SYSTEM32 doesn't handle spaces. That little script section is a bit over my head (neither TommyP nor I wrote it) so I can't say for sure if that's the case. Can you post your HFSLIP.LOG file, please?

Don't know why you are posting this. HFSLIP doesn't open files so the content is irrelevant. I'll try to duplicate it.

I see there are some problems in MC2 060616b. Please download MC2-060617a.

You can find it here. Take the first download (00dNET20.exe). This file is probably not compatible with MC2 so don't try it instead of the RVM dotnet2.exe. Use it directly in HFSVCPACK as noted in my post above.

If that fails, the best option you got is this: DNF11.EXE (from MC2) DNF20a.EXE (Aserone's silent .NET 2.0 installer) DNF20b.EXE (your silent .NET 2.0 language pack installer) If this doesn't work, I don't know what your problem is. MC2 *attempts* to do what the Aserone installer does, with the only difference that the Aserone installer relies on REG.EXE while the file made with MC2 accesses the registry through a normal INF file.