Slipstreaming Drivers

[tommyp]

The fixes aren't a big deal. I'm doing some tests now and plan to release in a little bit.

[Lilla]

This is my first attempt at adding drivers, I have a question.

My everyday and workbench computers both run Win XP Pro (OEM), but the video cards are different. Can I add both video drivers to the same build, or do I need to prepare a different build for each machine?

Thanks, Lilla

Edited February 21, 2010 by Lilla

[tommyp]

I'm sure that you can have both, as long as the filenames (sys's, dll's, inf's) aren't the same. Give it a whirl and report back.

[Lilla]

I'm sure that you can have both, as long as the filenames (sys's, dll's, inf's) aren't the same. Give it a whirl and report back.

Well, I slipstreamed 3 drivers. Two worked, one didn't. The video driver I slipstreamed didn't install; instead Windows installed the older video driver bundled with Windows XP.

Perhaps it didn't install because the driver (obtained by DriverMax) was a bit odd as it had a sub-folder (whereas, the other two drivers did not). Should I have moved the contents of the sub-folder up to the root folder, and then deleted the sub-folder?

Also, there were two .xml files, one in the root and one in the subfolder. I deleted the one in the root folder (where the .inf was located), and left the one in the subfolder. Should I have deleted both .xml files?

In any event, I am happy to have two drivers (LAN and Sound) integrated.

Thank you,

Lilla

Edited February 25, 2010 by Lilla

[tommyp]

The xml files aren't needed. The binaries and inf for a driver should be in it's own folder, additional subfolders isn't any good. If the driver isn't installing correctly, you may need to mess around with the setup inf file a bit. I've found that drivermax isn't 100% perfect. Once looking through a driver setup inf, I saw that some binaries weren't copied over to the folder. Copying them manually fixed that prob.

One thing that could hurt slipstreaming drivers is the windows certified drivers (I could be wrong with the terminology used). I'm not sure how to work around that. I guess one way to work around that is through experimentation.

[Martin H]

Yes, if not removing drivers(hfcleanup), then "built-in" drivers(which are signed by msft), takes priority over non-whql drivers(which all added drivers are with this method; the INF edits breaks whql) even though the added drivers are newer... Windows setup ranks non-whql drivers with a lower rank than WHQL/msft provided ones(higher actually as lower is better...), even if the version/date is newer on the added ones...

MSDN: How setup ranks drivers: http://msdn.microsoft.com/en-us/library/aa477008.aspx

Edited February 23, 2010 by Martin H

[bphlpt]

I know this might be a dumb question, but is there any way to "sign", or create the right key, or in some other way convince Windows that the new drivers are WHQL "certified" so they can be used automatically? Just a thought.

Cheers and Regards

Edited February 24, 2010 by bphlpt

[Martin H]

I'm affraid not, sorry... The CAT file of the driver-package is the file which is WHQL-signed and in that CAT file, then there's checksums of all the files in the driver-package(including the INF file), and when then editing the INF file, then the checksum of that INF file isn't matching the one stored in the CAT file and hence, the driver will not be accepted anymore as a WHQL-signed driver...

I believe that a workaround would be to find out which exact name the msft INF for the requested driver has, and then name your own updated drivers INF that way, which then should overwrite the msft INF in the INF folder.