as a comunity we are at our strongest
good questions lead to good answers, and that leads to documentation.

the wealth of knowledge here is tremendous... but is not complete, and you (all of you reading) are a part of that wealth.

INIU is all about the YOU (er "U") !

This is a serious question.
DriverPacks univarsity gets seeded by user questions.
(I hear elementerary school kids in the flanders learn to write proper english. I write my way of Flemish.)

Richard?
Ask for a comment by JakeLD.

I am sure he can whittle down his work on DriverPack MassStorage in a flash. (probably has a couple dozen rollouts sets saved)
He was taught to add drivers per OS.
He knows what syspreppers do.
He was shown our ways and he showed us his ways.

For a customised txtmode.
first do trimming and maybe do load order.
We will ask that you show us how you were adding your own, AND WHY you killed those you killed.

We see people telling us this version/vs/that vs/other, and sometime, they tell us the modi.
in graphs. 70 Hz is not applicable to many widescreen. The driver defaults to 70.

in mass, we like to not allow a non-popular generic being boss.

DriverPack MassStorage mass INI is filtered.
For one OS, it shall not have a duplicate HWID between the delims.

IF you find dupes in INI for same OS. YELL°.
In the ideal world, it shall not have any generic HWID. If you find a generic HWID conflict, YELL°.

enter WHQL.
it HAS generics.
it has dupe subs.
it has versions.
it has a txtsetup.OEM with five generics, and 218 subs in an INF it calls.

in sound, a INF can call an INI and that INI calls another INI.
in mass, an INF does not call a console (not that I know of). (In graphicks and sound, it often will.)
(DriverPacks is fun to work on)

yes i am Jeff and am the current coder for DriverPacks base and i'm an oldtimer

the mass storage ini is the key to what you are trying to do renameing like named files so they can coexist.
the base program uses the TAG name in teh ini to choose what name to use when they are injected...
it is VERY IMPORTANT to note this only applies to TEXTMODE setup. the PNP drivers must be as they are proveded from the OEM. or they will fail with a 7B BSOD after the reboot into the WinPE phase of setup. so you need two copys of the drivers one for textmode (injeced into the I386 folder and txtsetup.sif) and an original copy that is in the oempnp search path.

taht should get you started..

Anyway, I had actually read that faq. But it didn't really cover what I was trying to understand... basically I use MDT and the MDT behavior for mass storage drivers is incorrect. Eitherway it is a little more dynamic and complex than making a mass storage pack as it uses driver injection to scan the hardware and determine what drivers it needs... that said, it has a bug... its not the first, wont be the last. I was gonna fix it, but I needed to understand how it is that the txtsetup.oem is processed... the documentation is hard to find and inconsistent as it applies to using them with unattend. (This became clear when OverFlow (Jeff?) explained that the documented behavior is for pulling the drivers off of a floppy, but once they are pulled off my xp/2k3 setup they all get dumped in the same folder causing the problem I was trying to get around.

Anyway, gonna read through it again after I get some sleep tonight... even though it seems more applicable to DriverPacks, it still looks to have some very good info...

Probably what I will do is modify the script so that if it comes up with driver sets with overlap it will at least prompt for intervention. Since it is injecting only what are required it should be pretty seldom. the biggest problem was just a complete lack of any kind of logic in the script for determining which mass storage drivers are injected... I think they figured, just inject all that have any sort of match at all and let the windows setup sort them out?

Anyway, I'm gettin learned... I am indeed... one day I may even know something about something...

Thanks for all of the info and patience...

Richard

INIU classes in mass storage 101 starting daily!

Anyway, I am looking for the post about something about missing a comma or using another number in the file (in which a driver copy/load process had an error).

the 'how do I customise' FAQ was one of the things Jeff wanted you to read, I guess.
(see signature for link.)

the 'AHA' moment... ding...

IE the problems occur after the copy to the dest not at their locations on the source disk

But I still hold MS partially accountable... even if there were none with the same file names, and even if there were none with overlapping hardware ids, I would prefer not to put all of my mass storage drivers drivers all in one big folder together and on top of that the documentation implies that it is supported...

http://msdn.microsoft.com/en-us/library/ms794587.aspx

http://msdn.microsoft.com/en-us/library/ms794606.aspx

it is th fact that hardware providers have not figured out how to correctly use HWID's
they allow more than one piece of hardware to share a HWID with another (very bad)
they also use the same filenames for "new" drivers that no longer support the old hardware ID's
(if you are going to drop support forr a HWID then you must change all the file names too - silly OEM's, Tricks are for kids)

well on second thought it is partialy MS fault for giving out WHQL to drivers that conflict with thier own older versions
not a very thorough testing team at MS to allow such glareing errors to get past them time and time again.

You can't resolve name conflicts by different path

"Well, thats not the answer I wanted, but at least it confirms that I am not crazy..." wait... retract that statement... try again... "...but at least it confirms I wasn't crazy, with regard to this." Thanks for the feedback...

hahaha, been down that road for regular pnp drivers... for a time I strongly considered making it a policy to modify all drivers... I don't mind having unsigned drivers, my problem is that once they are unsigned, if you have a lesser match that is still signed, pnp will choose that one... Solution... make them all unsigned and only put the hardware ids you want to support with a given driver, in its inf file... forced selection... also = management nighmare. I was gonna write some code to automatically import, compare, modify, etc all new drivers... but before I could I left the company I was with and had to start over.

lol, how did I know that was coming... but it's certainly a valid suggestion and one I will give thought too.

hah, yeah, well, even if it were hard but worked according to the MS documentation more people would be doing it... I've got to hand it to you guys, you definitely found the Achilles’s heel of MS Deployment, it is getting better with MDT, SCCM and driver injection, but they still had a long way to go with getting XP/Server '03 type installs where they need to be, and they have all but abandon it now for the Vista/Server '08 wim based installation methods.

I might surprise you... wait a minute... I've got enough work to do already... sorry, no free time for, stuff like sleep, so no time for new projects...

But seriously... Thanks for the help,
Richard

If it were easy, everyone would be doing it...

there is not a set of instructions that will work in every case...
we use a variety of solutions to address identical names, all with varied degrees of adverse side effects
do some searches here for SI3112 or Nvidia to see what i mean. (the battle for Silicon Hill has been raging for years.)

perhaps you can help us

PS we don't use Unattend.txt or TxtSetup.oem but there are similarities to txtsetup.sif and winnt.sif
you may get some ideas/help by looking at the mass storage tutorial (how to make a mass storage pack)
http://forum.driverpacks.net/viewtopic.php?id=2461
{ why is it people  NEVER  bother to read the FAQ before posting?... } grrr