Tomcat76

I don't know where you got your info from but it's incorrect for the most part. Windows2000-KB896358-x86-ENU.EXE: "Supported Operating Systems: Windows 2000 Service Pack 3; Windows 2000 Service Pack 4" Windows2000-KB899591-x86-ENU.EXE: "Supported Operating Systems: Windows 2000 Service Pack 4" KB899591 is superseded, btw. There is one hotfix on my Win2K list that's intended for Server 2003, and that's the time zone update. Microsoft did not release a version for Windows 2000 but HFSLIP supports both the XP and the 2K3 version of KB931836 in any circumstance (any source) so that's why my 2K list shows the Server 2003 version. I originally linked to the XP version but Microsoft later decided to make it a WGA download so I switched to the 2K3 version.

This could prove to be a very difficult changeover. Currently, HFSLIP is using cmdow.exe for: - HFSLIP.CMD (CMD file called from SVCPACK.INF at T-13) - HFSLPGUI.CMD (the file that installs things at first GUI logon -- a complex construction) - when the updated IE7 installer is installed (T-13 and first GUI logon methods) The last one's easy, but the first two are not.

I was working on a simplified version of HFSLIP for 64-bit versions of XP and Server 2K3 (AMD and Intel) from Dec 27 to Dec 29 last year but I never got around to testing it. I don't have the time. I'm self-employed so I have more bills to pay than the average worker. It will arrive some day, but don't ask me when. I don't know.

Not sure if this is the same problem but I think I read on a KB article page for Visual Studio that if you install MSXML6 SP1 and then Visual Studio, the MSXML6 SP1 files will be overwritten by the "SP0" versions that come with Visual Studio. You may have to slipstream updates into SQL Server Management Studio Express Edition that work around this issue if possible.

This isn't really the right forum if you want to reach the people that know about this sort of thing. All I can say is that I'm aware iTunes insists on installing the full Quicktime application even if Quicktime Alternative is installed with all encoders/decoders. SoundForge is not so stupid (can export to Quicktime when QT Alt is installed) but that knowledge doesn't help you any further. Maybe a simple registry hack can fool iTunes but you're better off asking about this in another forum.

1) You did not follow the instructions 2) You are including more hotfixes than those that are known to be supported 3) You are using a very old version of HFSLIP which isn't optimized for XP Media Center Edition 4) You have edited the HFSLIP log file I can't help you before these are rectified.

@Kiki As far as the error dialogs go, those often appear when disabling SFC. TommyP noted somewhere that the HFCLEANUP feature is only optimized for Win2K. The error for flash.ocx is a known issue and you should complain to Macromedia/Adobe for that. Part of the standard registration process just fails. At least it's a "silent" error, so I decided not to do anything about it. For Win2K, though, the error is not silent so I made Windows setup register flash.ocx at a later stage (T-13) for Windows versions that don't come stock with Flash (2000 and 2003). I don't remember if that also gets rid of the error note in setuperr.log -- I need to check again.

I did those checks on VM installs that had IE7 slipstreamed. So I don't really know what to say. You tried slipstreaming IE7 without slipstreaming XPize? What if you leave out the IE7 hotfixes? BTW... A T-13 install only works with installation sources that are pre-activated or don't require activation.

Well, I tested this on my "real" computer (as opposed to a VM which isn't a good test platform because it simulates a single CPU setup) and Windows Update did not propose KB929338. I have an Athlon64 X2 (dual core). KB896256, KB916199 and KB929338 were slipstreamed. I removed KB896424. No errors in setuperr.log except for the usual (Flash and msxml2r.dll).

Are you including any hotfixes that are not on my list? Are you instructing HFSLIP to change the default handling of IE7 via HFANSWER.INI? Where did you get that dotnet2.exe file from? If it's RyanVM's, it won't work (from svcpack.inf) as mentioned on his download page and here. I wouldn't experiment with the HFCLEANUP files until everything works as intended.

HFSLIP appears to be doing the right thing (taking the newest files). I'll have to test further in a VM to see why Windows Update is nagging. BTW... If you include both KB912919 and KB916199-v2, you no longer need KB896424.

KB896256 also contains halmacpi.dll so you still need both. But it suprises me that Windows Update wants to install KB929338 again. The files in this package are nearly 2 months newer than those in KB896256 so they should be the ones on the new source.

They are both supported

And they still are in the current final. We are talking about KB928388 and KB929120. But there have been many more IE6 updates...

I'd have to test that to be sure. Meanwhile, I have already checked my VM test installs of Windows XP (without XPize) and the *.msc programs open as intended when called from the Run box. So whatever problem you are having now, it cannot be attributed to IE7 this time, hehe.

XPize modifies IE files or IE7 files? Either way... HFSLIP slipstreams IE7 first, then the hotfixes, and then XPize. If XPize changes ieframe.dll but the mod is only compatible with IE6 then I can only conclude XPize is not compatible with an IE7 slipstreamed source.

I know it would make things easier for you but it's not feasible. The "black list" would have to be updated every time new IE hotfixes are released and I'd have to do a long investigation to find all the IE hotfixes which have been released in the past. It's easy for Windows 2000 because there the IE version is always mentioned in the executable's name. But then the user can deal with it too.

A few milliseconds... No; you're the first. I think I read about this on some site recently but I may be wrong. I'll have a look into it.

Those files (hdaudbus.inf and hdaudbus.sys) don't exist in the Windows source so HFSLIP should normally force Windows setup to copy them over into the intended location (new SYS files are copied into %windir%\system32\drivers and new INF files into %windir%\inf). I'd like to have a look at your HFSLIP.LOG file (to see if there's a naming problem) and the TXTSETUP.SIF file from SOURCESS\I386 (to see if HFSLIP did what it's supposed to do). Please put them together in one ZIP file and attach it here. Thanks.

The HFEXPERT folder may still not be what you're after. Those files are copied into the intended location during txtmode copy, but Windows setup purges the temp folder at the end. Also, if I remember well, at one point I have tried a few times to copy files into the temp folder and later access these at T-13, which failed. This may indicate that the temp folder is purged more than once. But you can always try...

Try this: C:\SP2\i386\UPDATE\UPDATE.EXE -u -n -o -q -s:C:\ That's what HFSLIP does and it's working for me. I get all the "root files".

It is recommended not to extract anything because if I need to explain which hotfix goes where and which is obsolete in which case it would make things too complicated for the average user. Also, executables in HFGUIRUNONCE are installed without switches from HFSLPGUI.CMD so it wouldn't be a silent run; they need the /quiet /norestart /n switches. If you insist on doing it manually.... * KB900325.exe goes in HFGUIRUNONCE * the Media10 hotfix goes in HF but is only applicable to WMP10 (XP MCE without upgrade to WMP11 or regular XP with upgrade to WMP10) * wmfdist95.exe goes in HF but does not apply to WMP11 * KB888795 goes in HF but KB912024 supersedes it * the rest of the files contained in the main KB900325 package goes in HF Also, be sure you know what you're doing changing the reboot properties of the last MCE hotfix. The MCE updates are installed through HFSLPGUI.CMD at an early stage of first GUI logon, and other (internal) Windows setup components follow after that. This is the reason why HFSLIP doesn't include an auto-reboot mechanism.

Kiki... Can you *please* do one attempt without XPize, extra MSI files and addons? If that doesn't help, reduce the hotfixes so only those that are on my list remain.

Either the xml has no records for KB923689 or HfNetChk is under the impression that everything's fine. I think the former is more plausible because HfNetChk checks file versions.

HFSLIP supports MPSetup.exe and wmfdist.exe in the HFSVCPACK_SW folder but if you want them slipstreamed they need to be placed in HF. My update lists have been showing them in the HF folder for quite some time now. I don't know... It's working for me. I have Q282784_WXP_SP1_x86_ENU.exe in the HF folder. Are you using HFSLIP 70316a?