[-] Meaning of a blank hwid in DriverPack_MassStorage_wnt5_x86-32.ini? (Page 1 of 2)

Well, technically I think it means "all" or "any".  dpms 901 had the hwids filled, but they were empty starting with 1006.  I don't know why.
Is it causing a problem for you?

Read BEFORE you post.  HWID tool   DriverPacks Tutorial   DONATE!

Not all heroes wear capes, some wear Kevlar!

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.

BartPE is stone age! (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.

Last edited by JonF (2011-01-21 04:58:24)

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.

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 .

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.

Hi OverFlow,

thanks for all clear replies (specially to post 3)

just to verify:
so CPQ32FS2.SYS file copied with names SYMC8XX.SYS , SYMC810.SYS , SYM_HI.SYS to overcome 1 driver instead of 3 native driver issue, instead same file with 3 names . Can you confirm this is intentional ?
(also re-tested with untouched pebuilder311a , DPs_BASE_1006 , DP_MassStorage_wnt5_x86-32_1101)

some comments about things on this topic:
yes, pebuilder is best reference, since it is stable , trustable, and great work of Bart Lagerweij which shows his accurate far sight I admire a lot.
Heh, comparing with winbuilder, winbuilder have oppositely famous with its unstable and untrustability, but sadly for today it is what many have at hand.
(I hope one day a good programmer provide a better pe-build-scripting tool, hope never ends )
anyway,
we, nt5x fans, want more
I am making pe1x64 builds since ~2009-10 along with multi language support (chinese etc.) already integrating some custom x64 drivers but sadly we do not have a mass storage package for today.
Is there any hope (take this as a honest request) to have DP_MassStorage_wnt5_x64..... one day, which I believe increase popularity of both pe1x64 and xpx64 .

Thanks, that was what I was expecting too
Than only reporting: dps_base - bartpe plugin do not delete these files and entries in txsetup.sif (tested with all default pebuilder etc.), instead it overwrites the way I explained on previous post.
ps: I do not know pebuilder syntax well....

Sorry for taking time and thanks for the reply.
I guess in the end, one day, we would have to make a small package to support pe1x64 :>, probably following great DriverPacks arrangements .

edit:
further, I tested integrating to winxpsp3enu cd, DPs_BASE_1006 - DP_MassStorage_wnt5_x86-32_1101.7z
this one worked better than bartpe plugin and deleted all entries from txtsetup.sif (leaving only symc8xx entries as it was explained before)
still,
SYMC810.SY_ ve SYM_HI.SY_ exists in final result (inside each file there is CPQ32FSFS2.SYS file) , so not complete removal
also SYMC8XX.SY_ contains CPQ32FSFS2.SYS but I guess SYMC8XX.SY_ should be containing SYMC8XX.SYS (actually CPQ32FSFS2.SYS)

from both results my conclusion is:
DriverPacks mass storage package arrangements finished but dpsbase application not updated following these changes which cause confusions, minor things we all living through time to time, I hope next dpsbase utility will clear all possible confusions.

Last edited by Lancelot (2011-02-01 22:04:32)

I do not think any bug report for bartpe or anyone asking why new unused files on windows cd since both will work on the field nicely.
I understand (agree , fine.....) your decision not updating dps_base, not urgent at all.

YES,
Your explanations %500 cleared all confusions and shines our way ,
Thanks a loooot for Strong Support.

If those HWIDS are missing from

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"

Then it is a mistake / BUG ... (MR_smartEpants! HELP!!!)

I had that right when i fixed the bug... They must have gotten dropped (again) diring a subsequent update of DriverPack MassStorage.

GOOD EYE my man!!!! We'll get that fixed!

Normaly we say please "help us to help you"  BUT...
Now i think i have to say "Helping you has helped us!" Thank you.

Jeff

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!

The DriverPacks, the DP_Base program, and Support Forum are FREE!.

Thanks OverFlow , Thanks mr_smartepants

also keep in mind to check missing (not replaced)
PCI\VEN_1000&DEV_0012&SUBSYS_001b0e11 = "sym_hi"
PCI\VEN_1000&DEV_000b&SUBSYS_60040e11 = "sym_hi"
entries too
(maybe they are not required anymore, but better a 2nd check made by you guys to be sure ....  , well I am pretty sure you will make a clean check....)

All Credits to Olegpov, who catched missing hwids with his well known sharpe eagle eyes.
And thanks to JonF and Saydin77,
We had some days of confusions since JonF figured out things 18-Jan , I am very happy now everything related will be back to normal.

Overall,
THANKS TO GREAT DP TEAM.

I deeply know and fully agree OverFlow,

"Team Work" is the key to many things, I am always happy writing to dp since everytime I write so far, things solved with good topic posts , self-proving how nice you maintain Good Team Work.

we are a small community here too having full team spirit, feeling the same with you.

just one mini thing I noticed to underline since things will be fixed on next release,
on all tests, CPQ32FS2.SYS compressed inside SYMC8XX.SY_  (I mean inside SYMC8XX.SY_ file there is CPQ32FS2.SYS file with CPQ32FS2.SYS name)
With not being an expert like you guys, I do not know if name mismatch cause trouble.... only noticed and reporting here .

Thanks again.