Nazgul

Looking at the .cat file is indeed much more foolproof than what I was doing.

You can test it, but make sure you use a fresh XP SP2 with Ryan's pack integrated, but doesn't have a previous DriverPack integrated, because then the required files are already missing.

Which language is Fedit written in? If it's in C# you can force reading/writing in a specific codepage (for instance 1252) like this: Dim sr As System.IO.StreamReader = New System.IO.StreamReader("TestFile.txt", System.Text.Encoding.GetEncoding(1252)) Dim line As String = sr.ReadToEnd() My guess would be that their files are written with codepage 1252 (MS is a US company after all) and your program now tries to interpret them using the systems default codepage. So reading (and writing) them using the method above should be enough to fix the problem.

I haven't tested it, but this should work: Change this to Edit: small fix in the code caused by my stupidity

Those files are part of KB888111, which get integrated if you include Driverpack Sound A. When you run RUN_ME.cmd it will always remove these files if they exist It the copies them again only if you included Sound A Normally this shouldn't be a problem, because RUN_ME also restores the previous DOSNET.INF and TXTSETUP.INF, which don't contain the references to the files. The only case where this goes wrong is if your DOSNET.INF and TXTSETUP.INF already contained the entries for KB888111 before the backup of DOSNET.INF and TXTSETUP.INF were made. I'm guessing you integrated RyanVM's pack before integrating the DriverPacks? Because his pack also adds those entries. It could be solved by BTS by only removing those files if they weren't referenced in the TXTSETUP.OLD and/or DOSNET.OLD So in conclusion: Using RyanVM's pack in combination with BTS' DriverPacks without DP Sound A gives an uninstallable setup.

BTS, it think it has something to do with the codepage in which those files are stored.. Because the US and Western Europa both use the 1252 codepage we don't notice this, but the people experiencing this issue are from Romania, Russia, ... which use a different codepage. I know from personal experience that editing a file with codepage a which was saved in codepage b seriously messes up the contents.

Ill try to explain. Driverpack massstorage contains the following files: - M\P\2\fasttx2k.sys - \M\P\2\A\fasttx2k.sys During the integration of the Driverpacks both files have to be copied into the I386 directory, which isn't possible because one would overwrite the other. To solve this BTS 'renamed' the second file, while compressing it, to aftx2k.sy_. Because the files now have different names both can be placed in the I386 folder. During setup Windows will determine which drivers to install based on their hardware ID's. It will expand the relevant files (for instance aftx2k.sy_) to their original filenames (fasttx2k.sys), thus making the drivers work, because they have their old name back.

A quick browse throught that logfile shows the following: It shows that the first edit of DOSNET.INF by fedit appears to succeed and each subsequent edit fails with a 'Could not open file.' error. The same also applies to the other files being edited. It appears to be the same bug in Fedit mentioned here.

Not a bug. It's a workaround, because another driver also includes a file called fasttx2k.sys. This allows the files to coexist next to each other.

You can't, because it doesn't have files as such. When you format a normal disk, you format it using a filesystem (usually FAT12), which creates a kind of index on your disk so the operating system knows where and how to find/store files. In the case of your memory test program it was written raw to your disk, without the use of a filesystem. The tool can't be run from within Windows anyway, because it needs more direct access to your hardware than Windows (and most other Operating Systems) will allow, so they had to create a bootable program to circumvent the use of an OS. Not using a filesystem for such a bootable program saves a lot of overhead for the people who created it, because they don't have to write filesystem support. (Which would be pure overhead because they don't need it.) (The above is an oversimplification, but should get the point across) You can copy the entire disk from within Windows by using disk imaging tools like rawread and rawrite.

I already posted that one.

I usually do this by given the dropdown box the focus and then 'type' the first few letters of the item I want selected (enough letters to uniquely identify the item).

There's a huge topic about problems with portcls.sys in the Device Drivers forum. I'm assuming you've integrated SoundMax drivers into your install? According to that topic you have to use the SoundMax drivers from the manufacturer, instead of the general SoundMax drivers, because the general driver doesn't recognize all SoundMax chips, thus resulting in this error.

It never hurts to try. But because you said you already had that problem before SP2 and Microsoft states only SP2 as affected I think it won't solve your problem. Microsoft still officially supports SP1, so I think that if it was also affected they would have provided a patch for SP1 as well.

I've been busy trying to create my own Multi-Boot DVD using the Creating a Multi-Boot DVD tutorial. One of the things that annoyed me with that was the given method to create a Boot Folder, because I think messing with you boot.ini doesn't really win a price for elegance. So I started looking for an alternative method. As a result I created a small application (which requires the Microsoft .NET 1.1 Framework) of about 32 KB, which creates the Boot Folder for you. It asks for a folder containing the Windows files for which you want to create a Boot Folder, for example: D:\AIO-DVD\SETUP\XP\Professional. And it asks you to select a folder that you want to use as a Boot Folder, for example: D:\AIO-DVD\PRO1\. If you then press the 'magic' button, it automatically copies the required files to that folder. The application can also be used from a script: start /wait BootFolder.exe /u /f SourcePath DestinationPath Switches: /u Unattended - Don't show the GUI and start the process directly (Note that the GUI does pop-up in case of errors or invalid parameters) /f Force - Don't verify that the ouput folder is empty (Note that this option isn't available through the GUI, but it will affect the GUI) SourcePath The folder which contains the Windows files for which you want to create a bootfolder TargetPath The empty folder where you want to copy the bootfolder files to I've tested it on the following Windows versions, but it should work on others as well: - Windows XP Professional SP2 English - Windows XP Professional SP2 Dutch - Windows Server 2003 English History: BootFolder13.zip

A new Non-Critical XP SP2 Update: KB896626 -› Windows XP TV tuner program stops responding or displays corrupted video Download -› 595 KB (May 13, 2005) Switches: KB896626.exe /q /n /z

Would it be possible to add command line switches, so it can be used from other scripts? I created a custom batch file that unpacks my base XP ISO, slipstreams SP2, RynaVM's pack and BTS' Driverpacks and would love to be able to include this one as well.

Microsoft released v2 of their Windows Installer 3.1 to fix some problems. You can download it from here.

I think it would be wise to remove you ProductKey from your post!

I also noticed Microsoft removed Windows Installer 3.1 from it's download site, Windows Update and that it's no longer available through SUS. After some searching I came accross KB894199, which states:

It was a plain rar .... strange enough ... ← It bounced, because Gmail doesn't allow RAR archive attachments.

Midiboy, the amount of editing is quite small, as I've made a small batch script that does these steps for me. Everytime BTS releases an updated pack I just download them into a predefined folder, execute my script and the new version is integrated.

I have about the same setup and I use this routine: 1. Execute BTS' slipstreamer. 2. Copy the content of the resulting UWXPCD_ROOT to your X:\Setup\XP\Professional folder. 3. Execute the RUN_ME.CMD in that folder. 4. Move the OEM folder to X:\ 5. Copy the now modified WINNT.SIF and TXTSETUP.SIF from X:\Setup\XP\Professional\I386 to your X:\Pro1 folder. 6. Copy copy_sys_files_to_temp.cmd from BTS' pack to X:\Setup\XP\Professional and run it. (you can delete the file afterwards) 7. Copy the resulting files from C:\BTS_DPM_TEMP to your X:\Pro1 folder overwriting already existing files. Also don't forget to modify your SetupSourcePath in your TXTSETUP.SIF file if you haven't already.

I also have a batch file to generate my unattended DVD's. I just do a few automatic search/replaces to select the method and disable KtD on BTS' batch files and then call them from my file to generate the UWXP folder, which I then move to my working directory from within my script and I conclude by automatically running his RUN_ME.cmd. To be more specific: echo Integrating DriverPack md %WORKDIR%\DRVTMP cd %WORKDIR%\DRVTMP xcopy %DRIVERDIR%\*.* %WORKDIR%\DRVTMP\ /E /V /C /I /Q /R /H /Y > NUL attrib -R -H %WORKDIR%\DRVTMP\*.* /S /D copy BTS_DPs_Slipstreamer_V?????.cmd Dummy.cmd > NUL %DOSSR% Dummy.cmd ":STEP1" "GOTO Method_2" %DOSSR% Dummy.cmd "PAUSE" "ECHO." %DOSSR% Dummy.cmd "pause" "ECHO." start /wait Dummy.cmd del /q Dummy.cmd > NUL %ADDLINE% UWXPCD_ROOT\RUN_ME.cmd "DEL /Q CABfiles_DPM.cmd slipstream_DPM.cmd add_to_winntsif.txt nircmd.exe 7za.exe RUN_ME.cmd AddLine.exe RemoveAll.exe" "EXIT" %DOSSR% UWXPCD_ROOT\RUN_ME.cmd "PAUSE" "ECHO." %DOSSR% UWXPCD_ROOT\RUN_ME.cmd "7za.exe RUN_ME.cmd AddLine.exe" "7za.exe AddLine.exe" xcopy UWXPCD_ROOT\*.* %XPWORKDIR%\ /E /V /C /I /Q /R /H /Y > NUL cd %XPWORKDIR% start /wait RUN_ME.cmd del /q RUN_ME.cmd > NUL del /q I386\dosnet.old > NUL del /q I386\winnt.old > NUL del /q I386\txtsetup.old > NUL del /q I386\drvindex.old > NUL move OEM %WORKDIR%\ REM Manual fix for bug in 4059 %ADDLINE% I386\txtsetup.sif "[SourceDisksFiles]" "aliide.sys = 1,,,,,,3_,4,1,,,1,4" cd %WORKDIR%\DRVTMPThis is the code I use to integrate it. DOSSR is a small command line search and replace tool. Please note that it is based on Base 4.05.9, because I haven't had time to update, so it won't work out of the box with the current version.

Ameisez, how did you slipstream those hotfixes? You could try RyanVM's update pack, because it replaces the original files on the CD instead of patching during setup, which is the normal Microsoft way. This saves some additional space, because the CD doesn't contain both the old and the new version of the fixed files.