Understood, thanks. I'll donate a little something.

At http://driverpacks.net/legacy/updatechecker there's an INI file that includes the line "; This is provided for legacy purposes! Please migrate to the new APIs!".

I can't find any new API anywhere.

Maybe there's a command-line or INI file argument for DP_Base? But if I run DP_Base (with or without administrative privileges) and try to use the Update item, all I get is "<driverpack> is currently unavailable".

Maybe I should continue to use the original link? Or what?

Here's a couple of questions ...

Not all the HWIDs that appear in section [C] appear in CPQ32FS2.inf. How are we sure that this one new driver replaces all new hwids?

Should I just mimic the process of setting up and then evaluating the BartPE plugin. Or would one of the pointing it to the I385 directory tha's being built be better? When this script runs, all files that get copied from the source have already been copied.

Well, it's looking as if the best thing to do is to start from scratch and build the script based on your DPs_Base. Once it's done it will be miles ahead of the BartPE plugin smile.

I don't understand the problem ...

Suppose I deleted the [C] section completely before processing. Would that cause problems?

That's effectively what I'm doing. Haven't seen a crash yet.

BartPE is stone age! smile (I used it for years but moved on long ago). And UBCD4Win isn't sufficiently customizable for my needs. I do outsourced IT and in-home computer repair, so I see a wide range of hardware. The ultimate goal is to be able to boot from CD/DVD/Flash drive and see the local disks.

I'm doing both PE1 and PE2, but the current issue is with PE1. I'm using WinBuilder, which has a pretty powerful scripting language. The current issue is a script that inserts the drivers at build time into a txtsetup.sif that's originally copied from the source. I suppose it could be changed to slipstream into the source, but I'd want to have a reliable method of detecting what has been slipstreamed in.

Right now I'm just skipping the driver with the blank hwid, which may be acceptable since it's seldom critical that the most recent driver be available, what's really required is a driver that works.

I don't quite see a good algorithm for processing that section. It appears that I have to read, parse, and store all the information in that section before I can process the information. I might have chosen to put the non-blank hwid string at the end rather than at the beginning so a program would see the blank hwid first and trigger special processing. But what's done is done.

Thank you. I'm working with a program someone else wrote, which incorporates the MassStorage driverpack into a WinPE build by copying the appropriate files and modifying txtsetup.sif. It didn't understand the blank hwid and inserted an invalid entry into txtsetup.sif so the result wouldn't boot. Now I need to figure out how to remove the drivers.

I'm no expert on ini and if files, but I can figure out some things. But this noe has me stumped.

In DriverPack_MassStorage_wnt5_x86-32.ini I see:

[C]
ms_count=3
ms_1_deviceName="Compaq HP ProLiant SCSI"
ms_1_tag="symc8xx"
ms_1_sysFile="CPQ32FS2.sys"
ms_1_hwids="PCI\VEN_1000&DEV_0001,PCI\VEN_1000&DEV_0003,PCI\VEN_1000&DEV_000a,PCI\VEN_1000&DEV_000b,PCI\VEN_1000&DEV_000c,PCI\VEN_1000&DEV_000f,PCI\VEN_1000&DEV_0012"
ms_1_isBusExtender=false
ms_1_exc_skipIfOS="w2k"
ms_1_exc_replaceIfOS="wxp,w2k3"
ms_2_deviceName="LSI Logic C8100 PCI SCSI Host Adapter"
ms_2_tag="symc810"
ms_2_sysFile="CPQ32FS2.sys"
ms_2_hwids=""
ms_2_isBusExtender=false
ms_2_exc_skipIfOS="w2k"
ms_2_exc_replaceIfOS="wxp,w2k3"
ms_3_deviceName="LSI Logic C896 PCI SCSI Host Adapter"
ms_3_tag="sym_hi"
ms_3_sysFile="CPQ32FS2.sys"
ms_3_hwids=""
ms_3_isBusExtender=false
ms_3_exc_skipIfOS="w2k"
ms_3_exc_replaceIfOS="wxp,w2k3"

What does ms_2_hwids="" mean? Use the hwids listed previously? Or what?