DriverPacks.net Forum - Driver Count Question

Re: Driver Count Question

null@example.com (compstuff) — Sat, 24 Mar 2012 16:35:37 +0000

I actually used HashCheck http://code.kliu.org/hashcheck/ and have been using it for years since I learned about it on here :-) It also does SHA-1 checks and I could easily reference those as well because I added the whole bunch in the spreadsheet which was the only way I was able to sort them out... and now I will also use Notepad++ as well :-)

Re: Driver Count Question

null@example.com (TechDud) — Sat, 24 Mar 2012 13:57:01 +0000

I've been a fan of Nir Sofer's constantly updated "HashMyFiles". http://www.nirsoft.net/utils/hash_my_files.html

I like the look of Notepad++'s formatting, highlighting differences! That's a pleasant sight for sore eyes.
ooo, 'free beer'! Doh!

Re: Driver Count Question

null@example.com (Helmi) — Sat, 24 Mar 2012 13:35:01 +0000

Yeah, but collisions are more of a theorem of information technology.
While possible, albeit very rare, and of course depending on the checksum method you use, how likely would it be for a file to cause a collision (and we're not talking about CRC32 checks but MD5 at least!) and still maintain the proper file format to count as valid INF file plus be of roughly the same size?
Change just one byte and you get a completly different hash (not simply just one single character alternated).
If you calculate both, say, MD5 and SHA1 hashes, and both are supposed to collide, that multiplies the chances, hence it becomes quite indefinately more unlikely...

Anyway, if you want to manually compare file contents, I suggest you use Notepad++ with its double view planes and compare extension.

Results:

Re: Driver Count Question

null@example.com (TechDud) — Sat, 24 Mar 2012 12:38:24 +0000

Just a 'heads up' before file deletions are committed. A consequence of using MD5 checksums in comparison is the risk of collisions (two or more files with identical checksums, yet differing contents). The odds of this occurring are remote; yet worth noting (& double-checking for).
One possible method of eliminating this factor is to recalculate sums for the matched .inf's utilizing SHA1 (used in .cat files) or preferably SHA256 (noted in nV - NT6.2 .cat files) for final comparison.
There may also exist some Vista drivers that have no equivalent (for HWid's) in either the All or Win7 folders. I hold no examples of this before you presently, yet i must acknowledge the possibility.

Re: Driver Count Question

null@example.com (compstuff) — Thu, 22 Mar 2012 02:24:22 +0000

I was really banging my head against the wall with this one so I did lots of tests and even tracked stuff through some spreadsheets to help make sense but I figured an MD5 check against things was the best bet... you are much better at this stuff than me but I will gladly send the spreadsheet to save you some time if you want... its about time I give back to the forum :-)

mr_smartepants wrote:

compstuff wrote:
As a further example I looked at the Chipset WIN7/Intel/1 files and the ALL/Intel/1 files... all 116 files in the WIN7 folder are exact MD5 matches for the ALL folder... if thats the case why are they both needed?
Really? To be honest I never checked. If that's the case, then we can just get rid of the Win7 folder and keep the All folder instead. That will shave about 100kb from the pack.
I knew the AMD folders had duplicates, I just didn't have time to weed them all out.
Maybe I should revisit that pack eh?

Re: Driver Count Question

null@example.com (mr_smartepants) — Wed, 21 Mar 2012 22:01:59 +0000

compstuff wrote:

As a further example I looked at the Chipset WIN7/Intel/1 files and the ALL/Intel/1 files... all 116 files in the WIN7 folder are exact MD5 matches for the ALL folder... if thats the case why are they both needed?

Really? To be honest I never checked. If that's the case, then we can just get rid of the Win7 folder and keep the All folder instead. That will shave about 100kb from the pack.

I knew the AMD folders had duplicates, I just didn't have time to weed them all out.
Maybe I should revisit that pack eh?

Re: Driver Count Question

null@example.com (compstuff) — Wed, 21 Mar 2012 21:35:22 +0000

Here is a bit of an update along with some questions. I have been testing at least 15 integration's to try and see some patterns and I also ran MD5 comparisons to check drivers duplicates... am I correct that if two inf's have the same MD5 they actually are the same? As a further example I looked at the Chipset WIN7/Intel/1 files and the ALL/Intel/1 files... all 116 files in the WIN7 folder are exact MD5 matches for the ALL folder... if thats the case why are they both needed?

I checked the AMD folder and saw the same drivers in the _svr folders as the non _svr folders so that clearly showed me duplicates.

When all is said and done your "story" in post 2 was worth sticking with :-)

Re: Driver Count Question

null@example.com (mr_smartepants) — Wed, 21 Mar 2012 18:31:20 +0000

That's a good question. I have no idea.

Re: Driver Count Question

null@example.com (TechDud) — Wed, 21 Mar 2012 07:13:07 +0000

How do i differentiate a Premium WHQL signature from a standard WHQL signature versus Authenticode?
http://forum.driverpacks.net/viewtopic. … 820#p47820

http://msdn.microsoft.com/en-us/library … 85%29.aspx
http://msdn.microsoft.com/en-us/library … 85%29.aspx
http://msdn.microsoft.com/en-us/library … 85%29.aspx

Would this mean that drivers from earlier OS's need to be included when no native driver exists?

Re: Driver Count Question

null@example.com (mr_smartepants) — Mon, 19 Mar 2012 19:51:54 +0000

Hey! Welcome back mate! It's been a while.

Re: Driver Count Question

null@example.com (Legolash2o) — Mon, 19 Mar 2012 14:04:11 +0000

What mr_smartepants said is completely true which means W7T needs to detect if a driver is for Windows 7 or not, not sure if that is easy or not.

Re: Driver Count Question

null@example.com (mr_smartepants) — Mon, 19 Mar 2012 06:24:07 +0000

In my testing, having SAD2 delete the unwanted folders prior to executing dpinst does save time. The delete function takes less than a second where the dpinst scan can take several minutes (depending on the speed of the target system).
Remember, DISM is used for offline-image driver integration, DPinst is for online-image driver integration.

compstuff wrote:

In working with only WIN7 images am I correct that I need both the ALL and the WIN7 folders

Yes. The "All" folder contains drivers whose .inf supports multiple OS types.

compstuff wrote:

In the Chipset pack are the intel drivers in the WIN7 1 folder the same as those in the ALL 1 folder

I was never able to conclusively prove that the Intel chipset drivers in the "All" folder were needed for Win7 since they provide a "Win7" folder. To be honest I just didn't have time to investigate.

Re: Driver Count Question

null@example.com (compstuff) — Sun, 18 Mar 2012 22:09:45 +0000

I definitely understand what your describing but isn't that why you changed the packs so you could remove the OS drivers that don't apply? In each of the packs I only left the WIN7 and ALL and that's where the 295 comes from... do you think there are still duplicates in that case?

Do all the drivers get added to the inf folder? Do they all use OEM at the start of the name?

EDIT: In reviewing both the packs more in depth I do see duplicates so now I have further questions.
In working with only WIN7 images am I correct that I need both the ALL and the WIN7 folders
In the Chipset pack are the intel drivers in the WIN7 1 folder the same as those in the ALL 1 folder

Re: Driver Count Question

null@example.com (mr_smartepants) — Sun, 18 Mar 2012 20:16:33 +0000

That's probably because neither utility is reporting the drivers it actually integrates or because some of the drivers are duplicates.
Here's a good example of what I think is going on.
In dpms the manufacturer DawiControl has identical folders for 3 different OS (Vista, Win7 & Server) but each driver is slightly different for each OS.
DISM (which both utilities use) will count all the drivers and this is the first number, then it goes through and picks the drivers that match the OS it's integrating into and that's the second number.
So for DawiControl, we have 3 drivers but only 1 will integrate into Win7, multiply that to the nth degree across all the DriverPacks and you'll see the discrepancy you're reporting.
So while DISM may be counting 295 driver .inf files, only roughly 230 are compatible with Win7. The others may only be compatible with Vista/Server and are skipped.

There are also differences in the Win7toolkit in how it "validates" driver files. I don't use W7T but that's how Liam (W7T creator) describes the process.

That's my story, and I'm sticking to it!

Driver Count Question

null@example.com (compstuff) — Sun, 18 Mar 2012 18:48:50 +0000

Hi Erik,

It's been a long time since I've posted to the forum but I'm still following your work and now I have some questions since I am confused about some integration issues.

I am experimenting with two tools Win 7 Toolkit and GDism ELDI and I am using them to integrate the CPU and MassStorage packs.

When I use GDism it selects the 295 drivers and the log says it successfully installed all 295 but when I look for them I don't see 295 but more like 230

When I use Win7 Toolkit it selects the 295 drivers but it says it installed 231 so I am confused as to whether it should be 295 or 231 and of course why.