Search options (Page 7 of 99)

a link to information on mass storage.
it has a long txt. This was a collaboration.

after ruud posted essentials, I wanted to understand this better so I wrote up stories about learning pains and made a summary of txts I collected..
Jeff posted the essentals in a FAQ.

Kickarse, you have, I think unwittingly, been a great help to better understanding of how subtleties make a HUGE difference, and I think some of these conversations here will get pasted into this motherlode.
http://forum.driverpacks.net/viewtopic.php?id=2461

now, I want yuor insights on this too, because I (we) cannot know what was clear/diffuse/totally not understood.

you see, we still have no academy, and you are  (believe it or not) a teacher without tenure.
---
Goal, a complete scanner

1; we need full scanner, nothing missing, better than util5.
2; standard, WHICH? Sort depends on CSV rows, and util5 is a fine example of a standard.
3; in the past, skipped info we needed in reads were added manually, manually pasted in the correct row. (extra hours)

a full scan is useful for:
sysprep
PE
disc
conflict tuning by expert team (where automation will go awry, the human brain takes decisions)

a half baked scan (no full automatic filtering on at least six rows, location/version/date/OS/hardid/guiclass) is no good for any automated filter.

OUCH.
automated elimination in sysprep?
Let me tell you this;

txtmode vs pnp, a driver *'s  txtsetup.OEM and driver *.INF will most often have different info.
Example: txtsetup.OEM may have a generic or five and two specifics and (possibly) one or two sub-sub-version (txtsetup.OEM rarely lists all. Rarely.. One can, however, find over five hundred hwids in the driver.).
You see?
Those txtsetup.OEM generic will re-appear in the INF (I see that they always do)
When the specifics and subs are the only ones reproduced in the INF, the generic could be automatically rubbed out by an automated prep tool.
(that is, IF a dupe generic is found.)
WHY do that?
Because chances are there are other similar drivers using same generic.

Version metrics (the weighing of value of older/newer) count will show in excell, and in PnP, but you will find that the newer loads in txtmode.
(the older may have the sub, and if the wrong driver is loaded in txtmode, pnp then causes a BSOD)

next;
Consider the difference with sysprep to disc based install;
The INF can have, and most often has, info on a wide variety of subs and some generics.
(take for example a gigabyte driver. Believe me for the example, it has over 214 UNIQUE HWIDs.. and that is after we filtered..)
Its txtsetup.OEM has 8 generic HWID lines. It is a fairly recent driver, but not the latest..

For disc based installs: We've been balancing our INI and we kept driver version in mind.

Now, here is a subtle difference between DriverPacks BASE enhanced and Microsoft's setup.
For LOADING TXTmode, we do not use txtsetup.OEM at all, we use mass-storage.INI.
(I know, the INI MIGHT be based on OEM, but most often it is based on INFs, or, in some cases a combination of filtered HWIDS strings found in drivers of same driver version INF files.)

Life is not easy for SYSpreppers.
SYSpreppers have to filter out all OS dupes by OS because their build cannot have any dupe hwid.
Most drivers have at least  three hwids  duplicated in scan tools.
Some OS sections do NOT duplicate a hwid because the OS has a native driver, OR because the vendor will not support the OS. You cannot just delete an entire OS section when you want to cull dupes. If you do NOT find a hwid in txtsetup.inf or dosetup.sif, you have no support for that hwid. YOU (brainpower) may correctly do this in sysprep, but an automated tool that did not get the OS in the readout.. may delete the wrong line.

did we say this was easy?

erm, I should apologise.
Before my previous holiday I told people I wanted to spend some time in finalising testpacks and releasing those that were up to it.
Well, the personal project I am in used up huge amounts of time.

I am having holidays again.
I am into the fourth day, actually.
1,2,and 3 were spent on shifting stuff and more shelve building/stuffing.
There are another 40 yards of shelves in a shed I need to empty. (and I still have over 11,000 items to move/alphabetise) and I see I need approx 30 yards extra I have to buy.
I will try to do some real work on DriverPacks, tho. Them 11.000 books/movies/CD were in storage for so long that they can wait a little longer?

Question to Jeff
Could the "="=" have nulled that entire driver?

Hi,
I don't know if it will, and say that not only because I have not had Nvidia chipset moboes in-house for quite a bit of time, but also because I (when I have the hardware) I do not always find the time to test all variations and methods, and I (personally) usually try disc based install in live metal.

So, in other words, I do not often run tests for ubcd4win, and (to be brutally honest) when I don't have the suitable hardware, a test I do on an issue about hardware I don't have it is of little use.

However, you are helping us glue together some facts about nvidia, and any workaround is better than none.
Thanks.

I must now ask that people whom CAN truly test PE and UBCD4WIN on nVidia platforms take a look at what causes the issue, and at this workaround.
I know that we do not cover all nVidia controllers because there is a problem in the INF files.
To explain; when I look at all the downloads I see where some section is duped, but another is not completely duped, so I had to make a choice and completely left out one mass storage driver because I see no other way. We are therefore actually missing a driver.
((I did not dare put its HWID into another.))

OK, big deal?
nVidia once had a few support folders in DriverPack MassStorage, and we added some in the last fourteen months, and frankly, it was a uphill battle since.

erm
erm

wpi is not a stage for txtmode

erm
assume this is a selective user.
selected chip and selected mass integrated (after INI° EDITs) (Everybody can, so he might done so.)

after that, warm or sad or disc feed.
-----------------------------------------

access to HDD is mass driver/txtmode so it is mucho imortant.
chipsets.
we have two people in  the world whom know how important they are, and they tested the wayz of integrating chips.
All five of them were right. The twelve of us have concluded that chips had to be rewritten.

(this is not a joke.)

incidentaly

the DPINST  (and most probably) the SAD function will use extracted third party x64.

SAD could use X64 because it uses Microsoft DPins
(Jeff knows there are X64 version for DPinst, and I cannot code...

Hyper-V and DPinst: workstation control. remote contolled IPX, blocked ICX.

there are some things you do NOT want in disc based rollout. Idngadau.

Hi
I would gladly put my iban details up.

@ sp2
support for XP 64bit was and is not coded in DriverPacks BASE

XP64, as much as I personaly like it for speed and stability, has not had a great success in real world roll-outs.
(( fora in the world are going to tell you this or that older program is not working in XP64.  This is the harbinger of success.  ))

I am a hard binger.
I got drunk one day, and while drunk tell a guy what I want in vista.
He showed off.
I say, do you dual boot?
in XP, he showed all but not as slick ( he had to use third party)
in X64?
he got stumped after two questions.
OFF we went, to a vista x64 and XP X64.

XP64 was like a missunderstood mistake edition.
V64 is a powerhouse.

well, realtek drivers writers are most defenately set on covering the entire market, because they include HWIDs for via, nvidia, and intel and they do it in an all generic file, and in others of their multitude of infs.

Let's suppose a user replaces the realtek with the latest download..
That will cause issues when sound_B is also used.
A realtek update is often about just one HWID, but the pruning we had to do is done in a dozen or so files across the two packs, and we also deleted a few inf..

doing a realtek update because there is a new version often means one extra HWID taking something like two hours of work.
1: compare older original( the version that is in driverpacks) to latest update original, find the HWID. (copy it to clipboard?)
2; compare updated files to files in pack. (the merge/compare tool shows what files we deleted, and the sections that were edited. The newest driver gets pruned in that process. )
3: now that is done, run dragdrop tool and collect HWIDS from PRUNED updated driver.
4; import the CSV into new excell tab, paste the HWIDs under the old worksheet.
4, remove old version HWIDS (now duplicated) in the excell sheet.
>> it will also show if that NEW HWID is not duped elsewhere, but you may as well look for a conflict by looking for partial HWID to find out if there is now no generic competing in other driver<<
5; SAVE excell sheet with new name

replace driver in new test pack and build it.
upload to two servers
viola, you spent (at least) two hours on one HWID.

>> excell sheet "what we had" needs to be updated too.. <<
6; collect all hwids from original updated driver with dragdrop
7: replace the section in "what-we-had" sheet.
((what we had can be useful. We may have made a wrong decision in the past, and when updates in other drivers happen we may have to reverse a decision..))

Hi

the SAD option is not so obvious in older release (the cmd tool is there, tho), but it is going to be a gui choice in DriverPacks BASE we are testing.

It is a real cool choice in the latest (80903xx ) beta in test, and there were great improvements written in fora.

(kickarse will see what he did when it kicks the behind away from the circle flies)

I don't want to sound gruff.
that driver is not even wdm? it has two unsigned INF

the cat referred to in them had no hits when I searched.
so?
Kwouters, I think vendors should not cut costs at the expense of you, but the whql and wdm database all vendors should be able to access is apparently not looked at.. they are not doing any other than.

 change line, comment: screw cat, works registry in fix bed, izz OK?, release driver, and internally badly name it too.

edit:::
kwouters
revert to a third party DriverPacks (own build) solution.

I will ban this sort of usb driver in main LAN.