Tomcat76

I forgot if it was OS or language dependent. But I confirm that all is fine with Win2K/US.

Windows Update may ask to install MSXML6 SP1 (tagged with KB934268) even though it's been slipstreamed by HFSLIP. I've been aware of this issue for some time and did some extensive testing on different PCs about two weeks ago trying to find out what Windows Update wants "more" in order to regard it as installed but failed. It's definitely not the registry -- at least not what's added to the registry after installing this by hand. Workaround: place msxml6_x86.msi in HFSVCPACK_SW (HFSVCPACK_SW1 in HFSLIP 1.5.0+)

Kiki... With the current test release and upcoming version 1.5.0... - executables which are supported by HFSLIP and msxml*.msi go in HF (just like before) - Type 1 hotfixes which are not supported by HFSLIP and MSI files except msxml*.msi go in HFSVCPACK_SW1 - Type 2 hotfixes which are not supported by HFSLIP go in HFSVCPACK_SW2

Actually, it does work if the host OS is not Win2K. I use Win2K as my main OS and figured it may be a Win2K-only problem when I first wrote the code but never got around to trying it out on WinXP/2K3. I did now. RC4 handles the exe.

I think you didn't read the entire changelog. If my hunch is correct, your problem should be fixed when using RC3.

Hi Luciano. Welcome to the forums. Do you have the same problem using cdimage.exe? Remove mkisofs.exe when using cdimage.

I suppose you're talking about MSN Messenger or Live Messenger; Windows Messenger 4.7 is part of Windows XP. You'll need to extract Install_Messenger.exe and place the MSI files you wish to have in HFSVCPACK_SW (HFSVCPACK_SW1 in current release candidate). MsnMsgs.msi is the core app; the rest are addons.

That's actually a good idea. I'll have HFSLIP check for the existence of all three extra CABs before proceeding with them. Glad you found the prob

You shouldn't worry about msxml2r.dll either; it's just like that. If the error message bothers you, remove msxml2.msi from the HF folder. The resource file doesn't have to be up-to-date. KB911164 is an internal hotfix for MSIE6 that was released after SP2 came out and is present on many new XPSP2 sources. If I'm not mistaken, it's dated somewhere early 2006. It has long been superseded so if you slipstream the latest IE6 cumulative update (or IE7), you won't be needing it. That hotfix is accompanied by some CAT/DAT files in the same folder.

Can you run the 1.5.0 release candidate with all files in place, then ZIP up HFSLIP.CMD from SOURCESS\I386\SVCPACK and post it here? I'm gonna modify it a little to see if I can get the %HFSLIP% variable to work over a network.

The current release candidate no longer supports RCLOCAL=1 but you can add it yourself.

The last couple of Flash OCX files from Adobe have a broken OLE registration section. This is nothing to worry about as nothing wrong will happen; you just get the error in setuperr.log. The next version of HFSLIP will work around that. What file is getting the signature error flag?

Two questions.... >> HFSLIP Path - C:\Profiles\Administrator\Desktop\HFSLIP\ Which OS are you running HFSLIP on? >> WARNING - Previously Patched Source Detected This is more than likely the culprit. Remove the SVCPACK folder from SOURCE\I386.

Can you be a bit more specific? What does "broken updates" mean?

Since Socket 939 is being phased out, I suggest you get a real good one. My personal vote goes to the LANPARTY UT NF4 SLI-DR Expert. Advantages over the one that TAiN linked to: - one more PCI slot (3 total) - 4-phase PWM This is an overclocking bomb. I got my X2 4800+ running at 10x250 for a couple of months now and never experienced any problem. The memory (Corsair TwinX XMS 2GB) is in sync.

It's mentioned in the changelog

Someone said in another thread that "the big one" is an SDK and that is correct. It appears that CAPICOM-KB931906-v2102.exe contains the full "viewer" just like the hotfixes for MSXML4 and 6 contain all files needed for the full MSXML4/6 parsers. BTW... You're a day late: there's already a newer test release...

Where did you put .NET 1.1 in this scenario? You will have problems if installing .NET 1.1, .NET 2.0 and programs that depend on .NET in one go. For you, they should be installed in this order:SVCPACK: .NET 1.1 1st GUI logon: MCE updates and then .NET 2.0 or 3.0 So place a silent .NET 1.1 installer in HFSVCPACK, a silent .NET 2.0 or 3.0 installer in HFGUIRUNONCE and the MCE hotfixes in HF. Your first post in this thread links to the "HFSLIP and .NET 1.1/2.0/3.0" thread. Please read the first post in that thread; you'll find a link to a tool that creates silent installers including hotfixes and language packs for .NET.

<offtopic> It looks like they screwed up on the updated x86 2K3 version (v5). The download page says it's for SP1 and SP2, the KB article page doesn't mention a Service Pack requirement, and updatebr.inf leaves no doubt about the original intention (SP1QFE and SP2QFE). Yet, it only contains "SP2GDR" and "SP2QFE" folders. As a result, it's not supported by HFSLIP for 2K3 SP1, and version 3, which my hotfix list is currently linking to, is no longer available. KB916089 isn't available anymore either so 2K3 SP1 users are stuck. Good going... </offtopic>

If it works with those switches then yes.

You can try the latest test release if you like. It uses HFSVCPACK_SW1 and HFSVCPACK_SW2 instead of HFSVCPACK_SW. For KB923800, you have two options: 1) place it in HFSVCPACK_SW1 2) create a folder called _EXTERNAL in your HFSLIP working folder, move KB923800 into _EXTERNAL, and extract HFSLIP_PRE_KB923800.zip (version #3) into HFTOOLS The second will have it slipstreamed into the source. Do NOT put KB923800 in HF!

I just did a test with only that hotfix and can't reproduce your problem. Your HFSLIP.LOG file shows you haven't read the instructions: the CD tag is missing. But it isn't important to slipstream just the rollup so that can't be it. Can you ZIP these files and attach it here? HFSLIP.CMD (SOURCESS\I386\SVCPACK) HFSLIPWU.INF (SOURCESS\I386) TXTSETUP.SIF (SOURCESS\I386) If those files come out fine too, these are the only possible culprits: 1) Your system drive and/or the partition on which your HFSLIP working folder resides is somehow corrupt (running chkdsk may help) 2) You don't have enough hard disk space to create a complete second source 3) Something went wrong during the CD/DVD burning process 4) Your CD/DVD is corrupt 5) Your CD/DVD-ROM drive went bad

The /makelocalsource switch can be added by HFSLIP based on the existence of an entry in HFANSWER.INI but I need to know if it does the job before I insert it. According to the documentation, it is intended to copy the entire source to the hard disk which isn't really what we need...

Ignore what? It's already done in internal builds. I think this is useful because there are more Type 1 hotfixes than there are Type 2 hotfixes. In fact, I haven't seen anyone put a Type 2 hotfix in HFSVCPACK_SW in a long time. It used to be there for stuff like the WMP6 codecs but HFSLIP has long been capable of slipstreaming those files if placed in HF. The reason I let MSI be placed in HFSVCPACK_SW is so the folder wouldn't appear to be dead to most users. The proposed folder names are HFSVCPACK_SW1 (for Type 1 hotfixes and MSI files) and HFSVCPACK_SW2 (for Type 2 hotfixes). The only thing I'm not sure of is whether the second folder should be created automatically or only if there are executables in the original HFSVCPACK_SW (files are copied from HFSVCPACK_SW into the new folders based on their extension and then HFSVCPACK_SW is removed).

I don't think that would help. I think the problem is the %HFSLIP% variable in the beginning of HFSLIP.CMD. The FOR %%I IN (C D E...) doesn't pick up network drives.