Search options (Page 5 of 99)

Hi,
I figure you rolled back to XP from a custom OEM vista?

jeesh, 37x.. Highpoint?

not via, but same problem.
SP3 has changed support to highpoint.
OverFlow once wrote a exception and later on, in testpacks, it got diluted or abandoned.

Hi, SP3 integrated XP will conflict to VIA 370, because there is no known good fix between PnP overrule in SP3 and SP2 (and gold, for that matter.).

Or, XP-SP2 had native support for a version of via 37x and it did not clash with a HWID sub sys dropped in the DriverPack MassStorage release after sp3.

Or, XP-Sp1 (and gold..) natively supported generic via, no longer supported by their last ""generic via 4-in-1"".

Or, Via chose to totally change the mask and build of an old chip, and let it still report its old GUI/HWID combo and sub sys, thinking that there are no old computers with older hardware capable of running XP.
(I still support a client running a Piii EB600 and it is running a chip with 37x)

Can you imagine?
What took many hours of unforgiving edit work in PHP files now gets done on the fly.
The only disadvantage I saw so far was that the list will reflect what is there, showing/or not showing brand name info.
In the past, we did not always use the brand info INF had for this or that. (Sometimes, it is not in the INF. Period. We got it from the dowwnload site.)
The Brand name (and reBranded names) info was often in old supported device list, and the supported hardware we once had had those as 'see this, see that' because we had that info. A automated scan cannot output what's not there.
I don't see this bit of cool 'dev' work as a way to "not totally inform" you, though.
I say, Thank Heavens for such a time saver.
OTOH, wth? It looked totally different.
(I personally think the details of what is supported is not looked at by majority of users, but the supported devices/brands list was useful and keeping it up to date used up (or ate) a lot of time.. )

Some Brand names (eg. rebranded devices.) may no longer see a google hit, tho.

should be fixed now.. dl DL

Hi,
welcome to DriverPacks.

the main page has a news page, and the latest release candidate for the stream util ( DriverPacks BASE ) has been wanting to do what you want.

UBCD4Win and Bart_PE plug in builder have been improved, but... DriverPack MassStorage betas have not (not yet ) been extensively proofed and found to be always good for PE type installs.
(had that happened, it had been a proven release at UBCD4win.)

DriverPack MassStorage as we have it on release was not bad, but it is kinda old now?
JakeLD (whom looks at PE/prep/UBCD4win/-single-machine-disc improvements.. and its conflicts.. ) has been updating DriverPack MassStorage in testing forum, and your hardware is unknown to us.
I suggest you hang on, and you give us some more detail about your hardware.

For what it is worth, I would keep the old.
Build a new PE style DVD (ubcd4win or PE with the latest DriverPack MassStorage build to update its plugin by DriverPacks).
There are recent testpacks for you to try, but I would first look at Jeff's tute (a link in his an my signature), and then cruise the forum for the improvements on DriverPack MassStorage.. The hardware you have could be easy as fudge, or part of an easy upgrade we missed, or a hard nut we are trying to crack.

We have over 150.000 unique HWIDS covered, and five nuts.

Hi eethball, welcome the flux.

I would like you to be part of what makes us get into a structured improvement move. We are in a flux.. we are NOT fluttering.

Your testing of what is "in flux" will benefit all when you tell us
1; what you did (all the steps)
2: what you expected
3: what result you had

examples:
When you report GOOD or bad, while testing against known DriverPacks issues in drivers, the generated logs help.

If you have a niggle with the GUI or orher DriverPacks Base function and NOT a HWID conflict.. Please, PLEASE tell us what you expected to see in the interface (DriverPacks GUI) or what you had expected to see when you changed option, or as result after you ran it with your options.

for logs, we should have a FAQ.
simple; (gui in CPL for folder options) unhide all system,  and unhide system known extentions.
OR (the dark DOS screen aka cmd console)
CD\
dir /s /e /h *.log
dir /s /e /h *.ini

edit....  (forget set=) forget MsDos.

OTOH, this is too long to be in a sig and not beyond basic. I just wonder why so many do not know how to post those relevant logs.
we gonna havta have a faq?
find logs and INI by cmd or path, as shown in signatures by the DriverPacks gurus

A prepper (or a hardware wilderness in single-image wishful-thinking-head)  looking for speed gain by automated un-duping of ORIGINAL drivers needs a tool.

And you guys are developing it.

There are still enough people using XP roll-outs for us to have that effort work for DriverPacks as is now, and I already hear clamor for filtered vista and 2008. (what the heck.. One of the guys at the MsViP meet was pleased when he heard about DPinst and the possibility it worked on 98pack.. w/i, faik, still available on Third Party DriverPacks.)

Standardised (INF=> CSV) scanner (s) are our future.
How they work out the OS and version is important. VERY much so.
OS caused dupes help us write the INI.
QUITE a few scanners cannot, because the INF does not have the OS info properly SCANNABLE, output PROPER (true) dupefiltered output.

the spotlight did not attempt to remove dupes.

edit for RogueSpear. (and wsnow)
edited above (why real OS aware dupe eliminatition is a kettle of worms.) for warmsnow and roguespear.

The problem are the writers.
DriverPacks, so far, can reduce hands on work by a huge factor, and I think that was done by the fine people at DriverPacks.
Most of it was eyeballing outputs. (sometimes comparing output from one scanner against another output.. Or the TXT of the INF.. when you scan a file and have zero HWID output and you look at the INF and it had a gumption of unquantifiables?.)

I will ask the entire DriverPacks community to help us document known WHQL conflicts in same class drivers, and ask that they pay attention to /Hwid and 'GUI class' / conflicts.

not just pci/hwid.

you look at the INF and it had a gumption of unquantifiables?.

Hi,

The "short" HWIDs are indeed the major cause of conflict. The shorter they are, the more generic, and there are quite a few WHQL signed drivers which have some "super generic" in them, interfering with proper install of a "slightly-older" with (originally) same generic in it.

Many moons ago we did a quite radical thing to Sound Packs. In Sound, we used the VBS from SpotlightUtility05, its output is CSV.
(that spotlight tool does not eliminate doubles).
CSV was imported into Excell and then manually filtered.
It was a huge task, but we made it possible to load sound A and B without the thousands of conflicts it once had.
(as an aside, had I been using Excell 2007 THEN, I/we would probably have a slightly different result, with a LOT less manhours put in. We used a hilite formula in excell 2000 back then..)

Anyway, the spotlight tool was not written by Microsoft, but was written by techheads at technet, and is apparently free for all.
I asked the DriverPacks community to improve on it more than once, because it came to my attention it has (a rare few) blind spots.

Why did I not keep using the automated dupe-eliminator we had posted in other scripts?
Well, there are (a few) drivers that have different lists..(when you look at the support in same driver for 2K, XP, 2003, vista, the tally or values found in listed HWIDS are not neccesarily same.)

Nobody said this was easy.
The better we can document conflicts, the better.
I think there is a possibility that people at WHQL labs will look at output from scanners like those..
I told people at Microsoft HQ Belgium about the problem caused by duplicate generics and what grief it causes people doing roll-outs, and was amazed that in the little group we had together there some people actually testified to the usefulness of DriverPacks.

I mentioned angles and dangles because that is the first thing one does before one takes a real ride in a ssn.
(I like Clancy. A lot.)

We like you to take testrides with what our team puts up, and we learn a lot in the process.
Jeff and cdob (and some other, please forgive me for not having your name available to my brain for now.) have made a strong point about the version dance.
Chips, Lan, graphics and Mass sometimes share common origin when we get an update download, and I agree to the common sense of the finding.

Discord in version was apparently not such a big issue until we had to add those hard to add.

here is a note I would like to put out to all active bug hunters.

Do not just lurk.
Help us by showing what a difference a filtered DriverPacks made when you installed a machine, or rolled out to many.

In the discussion at Microsoft HQ Belgium I sorta dropped a stick in a henhouse, or.. I stuck out my neck.
I noticed there were several people there taking note and some knew quite wel what the WHQL problem was about. There were some there giving testimony to the usefulness of DriverPacks. NO kidding. I was awestruck when that happened (More of that was then discussed in after session 'dinner', and some seniors took more notes when that was going on.)
I knew DriverPacks was on the map for some peers worldwide, but I had no idea  there were such a high percentage aware of us in the EMEA MVP group. Our users made a buzz.

get buzzing about sysprep conflicts. Or whatever.. You are not only helping us help you, you will eventually make somebody write a notice to some slapsmuck so he gets his act together and cleans up his INF for us. (hopefully)

welcome to DriverPacks.
We think there is no perfect automated tool.
I bet that when we leave this sys file out there are some reg entries for PnP calls getting a null.
There are a good many INF where you would see very few HWIDS and calls, and the driver has a baker's dozen of INI.
The INF and the INI are looked at and I see an INI call another INI.

in one of those, I see that file mentioned.

the short take.
I see a sys.
I look up reference in txt
aha, in that ini and in there too.
I don't scrubbit.

I am a mecanic.
I am not mechanised nor automated.