Jump to content

DRVIDX/DRVDATA format documentation


oerg866

Recommended Posts

Hi,

 

as for some reason nobody believes me when I say Win9x does have a 2MB DRVIDX.BIN limit (yes, it's true, try it yourself by bombarding windows with tons of extra INF files...), I decided to investigate this issue myself, rather than waiting for someone else to patch it :P

 

The first step was to get a general idea of what this format looks like. Here's what I was able to come up with. Excuse the crudeness, it's 8AM and I haven't slept yet :P

drvidx.bin layoutNote: short means 16-bit integer and int means 32-bit integer.char* means '\0'-terminated string.Header:0x0     short   61 6E   Magic number, always starts with this0x2     int     amount  of entries in this index file0x6-0xf ????After the header there are all the entries, one after another.The first entry is located at offset 0x10.An entry consists of these attributes:short   total size of this entry in bytesint     pointer to the PnP ID stringint     pointer to the device class stringint     pointer to the device name stringint     pointer to the hardware vendor stringint     pointer to the driver vendor stringint     pointer to the end of the string data(the above pointers are relative to the start of the entry, including the header)int     number of this entry in the fileint     unknown (version??)int     Offset in DRVDATA.BIN at which the information        corresponding to this entry is located        (see below for details)-----dosdate file date of the driver. It is a two-byte date format from MS.Format description from MSDN:Bits    Description0-4     Day of the month (1–31)5-8     Month (1 = January, 2 = February, and so on)9-15    Year offset from 1980 (add 1980 to get actual year)Some examples (remember, little endian)97 26 = 23 April 1999 (Win98SE RTM date)BD 40 = 29 May 2012  (This was a VMware driver )-----char*   Device identifier (PnP ID)char*   Device Classchar*   Device Namechar*   Hardware Vendorchar*   Driver vendorint     always 0========================================================drvdata.bin layoutThere is no header, all the entries are next to each other.An entry looks like this:short   length of this entryshort   offset in entry of INF-file name stringint     always 0dosdate same as in DRVIDX.BINint     pointer to string containing the section        that defines this entry in the specified INF fileshort   unknownchar*   INF file namechar*   INF section name

I have started disassembling SETUPX.DLL and found some promising leads. If the stars align, I might have a patch ready by this weekend ;)

Link to comment
Share on other sites


Oh, shh :P

 

There is not a definitive answer, of course. It depends on how many PnP IDs an INF adds to the system. 

 

Here is a random bundle of INFs that will generate a >2MB DRVIDX.BIN. Transfer it to a windows 98 installation and set HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion, OtherDevicePath to where you unpack them (in my case "C:\W\D") and let windows rebuild its driver database. It should do that automatically, if it doesn't you need to delete C:\WINDOWS\INF\*.bin.

 

http://oerg866.titandemo.de/f/random_infs.zip

Edited by oerg866
Link to comment
Share on other sites

Thanks. :)

 

But my question was not really "can you provide a ton of random extra .inf's, enough to make DRVIDX.BIN grow beyond 2 Mb?".

 

It was more like "WHY one would add a ton of extra.inf?" or "In which (I guess particular) condition does it happen that the .inf are so many to make DRVIDX.BIN exceed 2 Mb?".

 

jaclaz

Link to comment
Share on other sites

Well, the POINT of said MSBATCH.INF/REGentry is (as I said before) SPECIFICALLY DESIGNED for OEM Installs (per MACHINE-Model. You have been going outside of that (not-OEM). There's also an OEM Preinstall Kit, as I said somewhere else as well. I have an IMAGE of one that actually asks if you want to install Win95 -or- Win98 and "acts accordingly". :crazy:

 

Basically, you're trying to go outside of the intended use. Good luck with your "new project".

 

O/T (slightly) - UBCD was NEVER intended to be an all-encompassing - keyword there is UNATTENDED. The Drivers were an afterthought.  ;)

Link to comment
Share on other sites

Now I see. :yes:

A sort of drivers-pack integrated Windows 98 "universal" install media, right? :)

 

jaclaz

 

 

Yes, exactly.

 

And I think if I keep reading submix8c's posts I will have a heart attack :D

Link to comment
Share on other sites

:w00t:

Basically, you're trying to go outside of the intended use. Good luck with your "new project".

And I think if I keep reading submix8c's posts I will have a heart attack :D

Please don't  :ph34r: - simply clarifying. You seem to be another one of those "touchy" individuals. :yes: It does seem "odd" that -just- INF-files would cause that. :crazy:

Link to comment
Share on other sites

Basically, the goal is to fix this bug that prevents one from making a huge pack of drivers. This is probably very interesting for people collecting and testing old hardware.

Link to comment
Share on other sites

Good luck finding the patch! Any limitation in 9x is worth overcome. Just please bear in mind possible differences between files of other language than English, if possible, so the patch could work universally.

Link to comment
Share on other sites

I wouldn't mind seeing that 2mb limit increased. I just scanned my systems to see how big drvidx.bin is, and in one case it was 1.15 mb and another was 1.590 mb. But in terms of making an updated universal installation CD, I thought that just adding new inf's and drivers to one of the directories on the CD would accomplish the same thing in terms of Win-98 finding all required drivers during installation. No?

Link to comment
Share on other sites

  • 1 year later...

Hello,

 

The 2MB driver database limit has been eliminated.

 

All you have to do is replace SETUPX.DLL and COMMCTRL.DLL with their Windows ME variants.

 

The problem did not seem to be that it had problems READING a big driver database, but something faulty was generated in those unknown fields in the header causing it to have issues later on.  

 

After replacing the DLLs, it still would crash reading the DRVIDX.BIN file from before. Generating it from scratch, it had no problem even with 3 MBs worth of information :P

 

Kind of disappointing fix, considering the hours I've wasted debugging this with SoftICE and IDA (It always seemed like some sort of issue with COMMCTRL's implementation of dynamic pointer arrays being buggy, but considering the latest findings that seems to have been a side effect??).... But I can finally lay this nightmare to rest :D

Edited by oerg866
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...