Tomcat76

I think I cracked it down. HFSLIP was doing the work on that hotfix based on the existence of "ARA_mmc.exe.mui", but localized versions of KB917008 do not contain these MUI files. As a result, createcab.cmd was not deleted and the INF file from the hotfix wasn't edited. The new test release (70504a) doesn't check anymore for the existence of "ARA_mmc.exe.mui" as a rule to remove createcab.cmd. It is now "just removed"...

Which problem specifically? WU getting stuck? Sometimes (not always) it is necessary to start IE, close it, then start it again in order for WU to work properly the first time. Also, you need to wait until the site loads completely before clicking the button to start the check. Failure to do so may result in the following issues: - WU doesn't check your system - closing IE takes longer than expected - you need to log off & log back in (or reboot) to have WU working again The latter doesn't apply to IE7 in my experience (only IE6 and below). These are general problems that are not related to HFSLIP.

This has been the case since IE7 was added to the list. KB917344, KB928090, KB929969 and Windows Script 5.6 are removed when you check IE7.

Assuming that you still have the same hotfixes... As Kiki already said, the IE6 hotfixes need to be removed (WindowsXP-KB928090 and WindowsXP-KB929969 in your case). And you are missing IE7-KB928090 (cumulative IE7 update).

Network installs require that all files that are to be installed later are cached first. Providing the necessary source IDs in HFSLIPWU.INF is not enough; they need to be copied into the temporary install folder during txtmode copy (1,,,,,,,,3,3). This is not the case for a local CD-based install. Personally, I consider this a bug in Windows setup. I should've covered them all by now, though.

HFSLIP.CMD looks fine. Still assuming it's a path issue, there are two possibilities left: 1) Are the files in the default location on the CD? (X:\I386\SVCPACK) 2) Do you have a folder named I386 in the root of one of your hard disk partitions?

I wouldn't trust that installation (source) too much. Files may have been renamed in other places as well.

Certain new files for IE7 and WMP11 need to be copied into the Program Files folder. This can't be done from TXTSETUP.SIF so they must be copied into Program Files at a later stage of Windows setup through an INF file (HFSLIPWU.INF in this case). However, the INF file must know what the source location of these files is and one of the CD tags is used to determine which "drive" they are contained in. I don't know exactly how you install from your new source but it's important that the CD tags are present in the SOURCE folder while running HFSLIP so it can hardcode a tag name into HFSLIPWU.INF. HFSLIP even blocks slipstreaming of IE7, WMP and WM codecs if a CD tag could not be determined. Also, the i386 folder as well as the CD tags should then be placed in the root of a drive.

I just figured out that createcab.cmd comes from KB917008 and it's referenced to from the inf file that's copied over. The latest test release strips out any instance of "createcab.cmd" which should fix the problem you're having. But it's strange that you have that file in your source as HFSLIP deletes it. Is it possible that you have another MMC hotfix in your HF folder?

I don't know what could be so different about a CHT installation. Run HFSLIP with everything in HFSVCPACK. Install that. In your next post, attach the HFSLIP.CMD file from the SVCPACK folder. I'll provide further instructions then.

StormRage-- I need to see HFSLIP.CMD from SOURCESS\I386\SVCPACK because that can only be a path issue.

The main source of the problem is this: CDTAG - undefinedPlease rectify that first by copying the tag files (WIN51, etc.) from the CD into the SOURCE folder.

Are you installing the MUI CD? This hotfix was a pain to code in. It contains many files that surpass the 8.3 file naming standard. That's most surely the problem. The original filenames are hardcoded into HFSLIP.CMD so if they are renamed by whatever tool you use to create the ISO, they will not be found anymore during installation. I suppose KB917008.CAT is not renamed because it follows the 8.3 file naming standard.I have switched to UltraISO a long time ago but I'm sure WinISO should have a setting to disable automatic file renaming.

It may depend on the setup. I've just prepared a system for someone with only FF2 and JRE 1.6.0_1 and the error message did not appear. The Java Console was disabled automatically, though, and, after applying the patch, the Java Console would appear again. On my own PC, I have the following folders in Program Files: Mozilla\Firefox 2.0 Mozilla\Firefox 3.0 Mozilla\Seamonkey 1.1 Mozilla\Seamonkey 1.5 It may be that something in this setup is causing the error message to appear. It's definitely not a "default browser" setting since Opera 9.20 is set to default on my PC. This is a known issue, though. Check this thread on the MozillaZine forums.

I use MS Virtual PC 2004. By contrast with other experiences, I find VMWare to be obnoxiously slow. Windows XP installs in roughly 25min on VPC whereas it needs over an hour and a half on VMWare. I have reinstalled VMWare a few times, tried different configurations, partition sizes, but nothing helped; starting up Windows takes more than 5min and even the BIOS section is horribly slow. MS VPC is great for me and I don't need the "missing features" others have named above. Host: Win2K Pro SP4 / Athlon64 X2-4800.

Firefox 2.0.0.1 (and up) spits out an error message every time you start it up if you have Sun's JRE 1.6.0 installed. The information file for the "Java Console" extension for Firefox (installed when you installed Sun's JRE) lists "2.0" as the maximum version it is compatible with. This excludes "2.0.0.1" and up as being "too new." That's why you get the error message, and the Java Console is disabled if you continue. Here's a script that ups the maximum version setting to "5.0", allowing you to startup Firefox normally again until it hits version 5.0.0.1. The script checks your registry for the various Firefox installation paths on your system and updates the Java Console information files it finds in those. A backup of the original information files is created as well. If you run the script a second time, it will ask if you want to restore the backup. USE AT YOUR OWN RISK! Download: Firefox Java fix.zip

You mean you want HFSLIP to use more RAM? I don't know how to control that...

createcab.cmd? What's that? Are you using nLite or similar after HFSLIP?

HFGUIx.EXE Can I have a look at the new TXTSETUP.SIF and HFSLPGUI.CMD?

Sorry, but this hotfix is not supported. It's a complete mess and I don't understand how it works. Two main installations should occur but I have no clue as to when the second should be executed. Also, why are seven x86 files included twice (once in the root and once in the i386 folder)? Why is there an amd64 folder containing 3.54MB worth of binaries when this hotfix is for x86? Doesn't make sense...

Still haven't had access to a machine with a Realtek chip, I'm afraid. The only thing I can do is install the hotfix manually somewhere and check if anything is done under the hood (like with IE7). I'll be back...

A1: Are you making a multiboot CD? When HFSLIP prompted you for the path, what did you enter? A3: Did you place the files in HFEXPERT\DRIVERCAB and did you use compression types A, B or C (not D, E or F)?

This thread may or may not stay alive. Its purpose is to collect names of hotfixes which don't appear on Windows Update and to see if HFSLIP supports them. Write a post here with the non-WU hotfixes you wish to use and I'll check if they are supported or not (if I have the time). The list in this post will be updated and your post removed. No off-topic chatting, please. IE7-KB931278-WindowsXP supported (replaced by KB931768) IE7-WindowsXP-KB929798-v2 supported * (replaced by KB931768) IE7-WindowsXP-KB932044 supported * (replaced by KB931768) IE7-WindowsXP-KB933006 supported * (replaced by KB931768) IE7-WindowsXP-KB933133 supported * (replaced by KB931768) IE7-WindowsXP-KB933264 supported * (replaced by KB931768) IE7-WindowsXP-KB933873 supported * windowsmedia10-kb888656 supported (superseded by KB921134 + Aug'05 wmfdist95.exe) windowsmedia10-kb895316 supported windowsmedia10-kb900399 supported (superseded by Aug'05 wmfdist95.exe) windowsmedia10-kb902344 supported (superseded by Aug'05 wmfdist95.exe) windowsmedia10-kb905592 NOT SUPPORTED (conflicts with Aug'05 wmfdist95.exe) windowsmedia10-kb910998 NOT SUPPORTED (conflicts with Aug'05 wmfdist95.exe) windowsmedia10-kb917821 NOT SUPPORTED (conflicts with Aug'05 wmfdist95.exe) windowsmedia10-kb921108 NOT SUPPORTED (conflicts with Aug'05 wmfdist95.exe) windowsmedia10-kb921134 supported (replaces KB917734; partially replaces KB888656) windowsmedia10-kb922042 NOT SUPPORTED (conflicts with Aug'05 wmfdist95.exe) windowsmedia10-kb922814 supported WindowsMedia-KB891122 NOT SUPPORTED (wmfdist95.exe ignored if inside hotfix) MSXML3SP7-KB919587 NOT SUPPORTED (replaced by KB924191, v8.70.1113.0) StepByStepInteractiveTraining-KB898458 NOT SUPPORTED (doesn't update Windows components) WindowsXP-KB319740-v5 supported WindowsXP-KB884020 supported (replaced by KB917953) WindowsXP-KB884883-v8 supported WindowsXP-KB885222-v2 supported (replaced by KB904412-v2) WindowsXP-KB886677 supported WindowsXP-KB886716-v2 supported (replaced by KB910678-v2 + KB917140) WindowsXP-KB887742 supported (replaced by KB916595) WindowsXP-KB888113 supported (replaced by KB920670) WindowsXP-KB889527-v3 supported (supersedes KB886185) WindowsXP-KB889673 supported WindowsXP-KB890831 supported (replaced by KB935214) WindowsXP-KB893357-v2 supported (replaced by KB917021-v3) WindowsXP-KB894395 supported WindowsXP-KB895115-v2 supported (replaced by KB928255 + KB900725) WindowsXP-KB896256-v4 supported WindowsXP-KB896427-v3 supported (replaced by KB914389) WindowsXP-KB896626-v2 supported WindowsXP-KB897338-v3 supported WindowsXP-KB897663 supported WindowsXP-KB898900-v2 supported WindowsXP-KB903234 supported WindowsXP-KB904412-v2 supported (supersedes KB885222-v2) WindowsXP-KB906569-v2 supported WindowsXP-KB907265 NOT SUPPORTED (contains binaries which need to be renamed) WindowsXP-KB907803 supported WindowsXP-KB907865 supported WindowsXP-KB908521 supported WindowsXP-KB909095 supported (replaced by KB931784) WindowsXP-KB910678-v2 supported * (supersedes KB886716-v2 if used with KB917140) WindowsXP-KB912436 supported WindowsXP-KB913460 supported WindowsXP-KB913538 supported WindowsXP-KB914437 supported (replaced by KB928255) WindowsXP-KB914841-v3 supported WindowsXP-KB917140 supported * (supersedes KB886716-v2 if used with KB910678-v2) WindowsXP-KB918005-v4 supported WindowsXP-KB918093 NOT SUPPORTED (replaced by KB931836) WindowsXP-KB918766-v2 supported (replaced by KB923694) WindowsXP-KB920889 supported WindowsXP-KB922668 supported (COM+ rollup 14; supersedes KB912817-v2) WindowsXP-KB927436 supported WindowsXP-KB928494 supported (for IE6; replaced by KB931768) WindowsXP-KB929755 supported (replaced by KB933876) WindowsXP-KB930597-v2 supported WindowsXP-KB931192 supported (supersedes KB899587) WindowsXP-KB932043 supported (for IE6) WindowsXP-KB933684-v2 supported WindowsXP-KB933737 supported (for TS Client 5.1; DO NOT USE WITH KB925876, which is TSC 6.0!!!) WindowsXP-KB933876 supported (supersedes KB929755 and KB930916) WindowsXP-KB934205 supported WindowsXP-KB935192 supported WindowsXP-KB935210 supported WindowsXP-KB935214 supported * fully supported with HFSLIP 1.4.4

HFSLIP doesn't impose a limitation there, but DOS may. I'm not sure how deep a directory structure DOS can handle off the top of my head. But I'll say it again just in case: HFSLIP takes all files out of the various folders and places them "loose" inside DRIVER.CAB, so be sure not to have duplicate file names. Also check against the files that already exist in the standard DRIVER.CAB and SP#.CAB.

Please try the latest test release. It fixes a bug with registration of files which may have caused your problem.