Tomcat76

This was a bitter pill... I hope I covered everything.

OK... I can see the error. At least... I hope I found it...

Some codec packages contain files that happen to be part of DirectX9 too. DirectX9 also covers "sound"....

That might help I just started applying the fix to the HFAAO part of HFSLIP but then it occured to me that it just cannot be fixed in all cases. The issue is this... Some codec packages include a file that's also part of DirectX9, but they often include the version for Windows XP. These are the cases it can be detected by HFSLIP: - when it's "loose" inside the HFEXPERT\CODECS folder - when it's "loose" inside an application addon CAB It can be detected but cannot always be fixed when it's inside a CAB inside an application addon (assuming that the configuration file contains a reference to the file in question). It can't be detected if the file is located inside: - a switchless installer - a switchless installer inside an application addon

Hehehe...

@TAiN: Do you have msxml3.dl_ in your SOURCESS\I386 folder? @FDV/Tommy: Is msxml3.dll removed with the FDV Fileset? If not, I see no problem in those HFSLIPWU.INF files.

For the sake of completeness:CDROM_IP.5 = Professional CDROM_IS.5 = Server CDROM_IA.5 = Advanced Server CDROM_ID.5 = Datacenter Server Maybe it's best to suggest both. Some people like XP's better and other prefer the 2K3's. XP's bootfiles seem to load Win2K faster on my dual Athlon64 computer when set to "ACPI Multiprocessor PC".

The fix that's included in version 60304 and up only kicks in when DX9 and codecs are involved. It doesn't take into account possible issues between DX9 and addon packs. I'll see if I can remedy this by tomorrow...

Oops... I completely forgot to notify FDV...

Little note.... Some of the Application Addons may contain a [FileFlags] section in the configuration file. Support for this was added in version 60305.

If it works in WIHU, it means that program is installing .NET 2.0 post-setup. HFSLIP doesn't do that; any additional programs are installed through SVCPACK, before the final reboot.

DirectX 9.0c and WI 3.1 can be slipstreamed, yes. RyanVM's switchless installer won't work. Some people (including me) have had success with Zxian's switchless installers: International / English

It's already fixed for the version that'll be released tomorrow. I noticed it while rearranging the entire Localization section. Thanks anyway for reporting it. "LNG" is not really used for the moment. Could be in the future...

Updated

You just confirmed my assumption on the difference between "Simplified" and "Traditional". Thanks-- Your post has been very helpful. "Chinese(PRC)" should be fine in the current version of HFSLIP but I'll update it tomorrow to add support for "Traditional Chinese".

This is an experimental version. See if this fixes any collision problems with DX9 and codecs (HFEXPERT\CODECS). [-Link removed. Version 60304 contains this fix.-]

Those CABs all contain pre-built executables to be installed during SVCPACK. All HFSLIP (and nLite) can do is install them with the provided command. The problems are related to the inner packages themselves. That's strange. I did three test-installs with Win2K prior to releasing 60301 and DX9 installed just fine. At least, dxdiag.exe told me I got 9.0c and the nVidia nForce drivers didn't complain (which they would if DX7 were installed). Does DX9 get installed if you don't include codecs?

The first is the basic DX9 stuff and the second are additions for gamers. HFSLIP allows the latter to be installed seperately but I don't know if they work in a non-DX9 environment... I'm not a gamer.

Would you mind telling which addons you had problems with? It may not be the author's fault....

The Chinese part needs some improvement. The problem is that the Microsoft documents are conflicting themselves so HFSLIP depends on user input for that. Try the latest version (60302). I made some changes to the localization section.

Application Addons are specially crafted packages in CAB format. HFSLIP (version 60301 and higher) supports these types: - SVCPACK.INF installations - SYSOC.INF installations - those which replace non-protected Windows files The CABs need to be placed in a folder called HFAAO inside the HFSLIP folder. The third type shouldn't matter to you that much as HFSLIP already provides the means to replace existing Windows files through the APPREPLACEMENT folder. The choice is yours. Important notice: since HFSLIP version 60528, you need EXTRACT.EXE if you want to slipstream application addons. Windows XP users can find it on their installation CD in SUPPORT\TOOLS\SUPPORT.CAB. Users of Windows 2000 and Windows 2003 can download it free of charge from Microsoft's web site: http://support.microsoft.com/kb/310618/. After you extract the Cabsdk.exe package to a temporary folder you can find the relevant file in the BIN subfolder. EXTRACT.EXE should be placed in HFTOOLS. For pre-made CABs and info on how to create these yourself: http://www.msfn.org/board/index.php?showforum=132 http://www.ryanvm.net/forum/viewforum.php?f=7

Yep. It was updated several times already... B)

> Q282784 (qfecheck) Is this file still needed? > KB890830 (Windows Malicious Removal) Version 1.13 is the latest. Be sure you use that one. > KB901190 (Windows Media Update) KB901190 is an update for the Korean Input Method Editor, not Windows Media.

You know... I was doing unattended installations of Win2K some two years ago and I could never figure out the serial key stuff either. I can do it on XP but not on 2K. Maybe it only works with specific versions (OEM or retail), or maybe you need to edit SETUPP.INI...

Some of you may have noticed that Windows Update now asks to install the Roots Certificate Update for Win2K. A new package has been released about two to three months ago. Windows Update never asked me to install it in the past two months even though the files in the new package are dated October through December 2005. The files in the package I was using up till today are all dated January 26, 2005. I guess this means MS are working on getting the quirks out of Windows Update... The strange thing is... its file version is equal to the one of the older version, so you'll have to compare the file sizes... Old rootsupd.exe = 219KB (224 568 bytes) New rootsupd.exe = 228KB (234 320 bytes) Or, you can just open the package you got in your HF folder with an advanced extractor (WinRAR, 7-zip, etc.) and check the dates.