Time to sit back and peer into the screen and see where the rendering shortcuts were taken. I checked for any books on the shelf that had to do with insecta. A yellow/brown version, with a hive on the front is the obvious choice. Opening it up exposes a set of strange and sometimes fearful collection of disconnected stories about The Registry.

The registry is a most curious place, inhabited by many things, some living, some not. Access to it is by a limited number of paths, such as, VideoPortGetRegistryParameters(…), VideoPortSetRegistryParametrs(…) for use only by the miniport, and RtlQueryRegistryValues(…) for those outside the video environs (or for those video types that know how to sneak out without letting Mom knowing what’s going on). The registry, of course, can be the repository for tons of adapter specific information, usually packed away in a service’s (or driver’s) Parameters subkey. But the registry also serves a global function of coordinating activities with various settings and resources, a facility that GDI and the VideoPort drivers enjoy.

In the graphics portion of the DDK, there is some mention of the uses of the registry, like names and memory sizes, which can be displayed with the Control Panel Display applet. Setting values here will cause some satisfaction. But, there are some more interesting keys, sub-keys and values that the good GDI person might want to know about.

First, how does some of that stuff get in there?  Besides installation procedures, what are there other conduits? Through the magic of assembly level WinDbg stepping (something everyone should try at home), one can find that some registry settings are done during VideoPortInitilaize(…), called from our own miniport driver. The registry information that is written is actually some identifier aliasing. VideoPortInitialize(…) creates some entries in the \HKEY_LOCAL_MACHINE\Hardware\DeviceMap\Video key. The values in this key are “pointers” to the currently active display devices (yes, device*S*). These are of the form \Device\VideoN, where N is an ordinal value 0,1,2, etc. The data for each value is a string that points to the service (um, miniport) that is \Device\VideoN. It’s a sad thing, but given this \Device\VideoN value, one might think (with a quick look via WinObj) that one might be able to open \Device\VideoN and chat to the miniport. Well, unfortunately, you can’t. The device object was created as an “exclusive device” (see IoCreateDevice(…)) and, once NT (like maybe Win32K.sys) hooks up to this device, no one else can open it! Anyway, looking at this table of video devices, we can see exactly what graphics miniport and \Device\VideoN are associated. Remember, however, that \HKEY_LOCAL_MACHINE\Hardware\  is volatile and will be re-generated after each boot.

So, let’s scurry on over to \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services and check out our service, (well, miniport driver). In our service key, we have the usual values of Start, Tag, Type, Error Control and Group. Depending upon installations, others may appear.  One common visitor is ImagePath, which defines the path to where the miniport driver actually exists (careful, folks, because things like drive letters are probably not around when the miniport gets loaded). DisplayName may be another value. This is the string to be displayed in the Devices applet for this miniport. If the DisplayName value is missing, the service name is used.

In addition to these values, this key probably has a couple of subkeys. Of course, there could be the ever popular Parameters subkey, which is completely driver writer specific. A most interesting one is the one that matches what was found in the DeviceMap\Video key, that of DeviceN. Depending upon the miniport author, the DeviceN subkey may have a profusion of values, some of which are standard values like VgaCompatible. This signifies that the miniport is based on the MS VGA miniport driver, with any necessary extensions. In most modern drivers, this is set to FALSE (or zero).

This DeviceN subkey is also where display applet information is stored. These are of the form HardwareInformation.<stuff>, where <stuff> is ChipType, DacType, MemorySize and AdapterString. Except for MemorySize, these are actually null terminated string values, but they’re stored as REG_BINARY, just to make sure we can’t read it very well. Also falling into this category is Device Description, which is stored as a human readable REG_SZ.

A very interesting DeviceN value that sometimes does not appear is the InstalledDisplayDrivers.  This is a list of display drivers that are can be used with this miniport driver. So, you can have a list of GDI display drivers that are tried, in order, to see if they support the starting display mode (display configuration). So, somewhere these starting display mode values must be saved. These saved values are in \HKEY_LOCAL_MACHINE\System\CurrentControlSet\HardwareProfiles\Current\System\CurrentControlSet\Services\<miniport_service>\DeviceN. (Yes, it is, unfor-tunately, a very long path, with a space between Hardware and Profiles). What GDI does at startup is to read these default settings as the “mode of the day”. It will then go to each display driver in the InstalledDisplayDrivers list and poll it (by loading the display driver) to see which one will support this mode. When it finds one, you’re in business and pixels start flowing. If not, it tries the next one in the list. If we get to the end of the list and no one is a match made in heaven, then Mr 16-color VGA will be used.

Another interesting registry vantage point is \HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers. This key usually has some sub-keys that seem to serve as flags to the system. If you boot with /BASEVIDEO, a BaseVideo entry will show up. It’s not entirely clear what this means (to my brain, anyway). What does happen is that the VGA display driver will be loaded (essentially polled) to see if it can handle the current display mode. If not, then the “normal” installed display driver will be installed. Of course, if the mode is correct, then the VGA driver will load – provoking the appearance of the NewDisplay and RebootNecessary sub-keys.

There are other tantalizing and mysterious settings that have been reported to the underground: PrimaryDevice, RelativeX/Y, MirrorDriver (which seems to be used for NetMeeting), and the ever-enticing MultiDisplayDriver. Ah, but like Toy Story II, information is limited. Guess we’ll have to wait for W2K to solve these riddles for us.