In Chapter 1, I described how the Registry evolved from its humble parentage of INI files. A surprising number of Windows 2000 and NT installations are still running 16-bit Win 3.1 applications that don’t support the Registry, and a surprising number of 32-bit applications still rely on the old INI file structure, despite the fact that using the Registry is one of the requirements for getting the coveted “Designed for Windows” logo from Microsoft.
Since there’s no way to upgrade skanky old 16-bit applications to use the Registry,[49] you might think that you’re stuck forever with the mess of tracking, backing up, and protecting a mess of INI files. Not so. Windows NT included a feature called initialization file mapping (I’ll call it just “mapping” from now on) that allows you to force Registry-unaware programs to load and save configuration data in the Registry instead of in an INI file. Windows 2000 implements mapping too, using the same techniques and keys originally made available for NT.
The default OS install already includes mappings for several system components, including the Windows clock desk accessory, the bundled backup application, and even RegEdt32 . Mappings aren’t just for 16-bit applications; rather, they’re for any application--16- or 32-bit--that doesn’t include code to read and write Registry data. Of course, mapping’s not required; applications that depend on INI files can work just fine without having the files mapped. In fact, unless you explicitly take action to map these files, they remain unmapped, and their normal INI file usage continues without interruption.
Mapping works because Windows 2000 and NT trap the private profile API routines I mentioned in Chapter 1. Windows applications and components ordinarily use these calls to get and set data stored in INI files, but when there’s a mapping entry, the kernel first checks for the presence of a mapping key. If one exists, and if it points to a key that contains data, that data is returned to the caller. If there’s no mapping key, or if it points to an empty or non-existent Registry key, the kernel tries to read the data from the INI file. The caller need never be aware that the data didn’t come from the requested file.
Mapping occurs only when there’s a mapping key in place. These
keys are stored beneath the HKLMSOFTWAREMicrosoftWindows
NTCurrentVersionIniFileMapping subkey. If you look there,
you’ll notice a number of subkeys with names such as
Clock.INI, regedt32.INI,
and ntbackup.ini. These keys tie sections of the
old Win 3.1-style INI files to keys in the
Registry so that older components continue to find their settings.
Application programmers and administrators are free to create new mappings between any INI file and any key in the Registry. This allows you to move settings data to the Registry where it properly belongs. Once it’s there, you can edit, save, massage, and manage it using the skills you’ve learned throughout this book.
Time for a real-life story: a client had licensed several hundred seats for a popular email application. This app had a 32-bit version, but it didn’t use the Registry. I created a mapping for the program’s settings, then built a system policy template (see Chapter 6 for details) so they could centrally control how users set up their mail clients. Everyone walked away happy.
In an ideal world, all the applications on your computers would be 32-bit, Registry-aware, Windows 2000-savvy programs. Unfortunately, relatively few people have that luxury. For the rest of us, though, it’s easy to add mapping keys to stealthily allow those applications to use Registry keys instead of sections in an INI file; best of all, you can do so without any changes to the application that owns the INI file.
If you’ve ever opened an INI file, you know that it’s divided into sections. Section names are enclosed by square brackets, and they contain name/value pairs. The whole arrangement looks like this sample from an imaginary data security package’s INI file:
[Encryption] DefaultSigAlgorithm=RSAWithSHA1 DefaultEncryptionAlgorithm=DES3-EDE-CBC WipeFilesWhenDone=1
In this example, “Encryption” is the section name, and “DefaultSigAlgorithm,” “DefaultEncryptionAlgorithm,” and “WipeFilesWhenDone” are the value names.
You may map any or all sections of any INI file to a Registry key. To do so, you must add a new subkey to HKLMSOFTWAREMicrosoftWindows NTCurrentVersionIniFileMapping. This subkey should have the same name as the INI file you’re mapping; for example, to remap a file named ccmail.ini you add a new subkey with that name to the IniFileMapping key.
If you just add a new mapping key by itself, nothing will happen. This is because the named subkey just tells Windows 2000 to watch for access to the INI file with the same name; it doesn’t tell where the data are actually stored in the Registry. You specify the location (or locations) by creating values underneath the key. Each of these values should have a name that matches a section in the INI file. These section names are combined with the name of the parent key to help the profile API routines figure out what data you’re requesting.
To map the key in the previous example, create a new key named HKLMSOFTWAREMicrosoftWindows NTCurrentVersionIniFileMappingCrypto.INI. Under that key, add a value named Encryption. The combination of these two values indicates that any attempt to access the “Encryption” section of crypto.ini should instead look in the Registry.
The value you give to these section keys tells the OS where the real data is stored in the Registry. Let’s say that our data security program stores its data in HKLMSoftwareCryptoCurrentVersionSettings. To complete the mapping started in the previous paragraph, use this Registry path as the contents of the Encryption value. By adding values under HKLMSoftwareCryptoCurrentVersionSettings with names that match the value assignments in the INI file (e.g., DefaultSigAlgorithm, WipeFilesWhenDone, etc.), you can achieve the equivalent effect of actually using an INI file.
When the application attempts to open thecrypto.ini file, the mapping key under CurrentVersionIniFileMapping redirects the PrivateProfile calls to the Registry key specified. Calls to fetch profile settings from the Encryption section are redirected to HKLMSoftwareCryptoCurrentVersionSettings.
There are a couple of tricks that apply to building mapping key entries. First of all, you can specify a default value that handles any sections that don’t have explicit mappings. Going back to our data security program example, if you added an Encryption key, Windows 2000 still wouldn’t know how to map requests for data in the “Signature” section. However, by adding a default value (which appears as “<No Name>” or “Default”) to the root of the subkey, you can tell the operating system which key to use for any sections that don’t have their own section keys defined.
There are also several special symbols to use in the values of section keys. Table 9-1 shows these symbols; you’ll see them in action in the next section.
Table 9-1. Special Strings for Initializing File Mappings
|
Symbol |
What It Means |
|---|---|
|
SYS |
Store data under a path relative to HKLMSoftware; for example, SYS:Netscape expands to HKLMSoftwareNetscape. |
|
USR |
Store data under a path relative to HKCU; for example, USR:SoftwareQualcommEudora expands to HKCUSoftwareQualcommEudora. |
|
! |
Store data for this named section both in the Registry and the INI file; when data is written to one, it will be written to the other. |
|
@ |
Never read data from the INI file, even if no matching data is found in theRegistry. |
|
# |
When a new user logs in, copy the section’s settings from the INI file into the specified Registry location. |
The Entrust data security package from Entrust Technologies (http://www.entrust.com) comes in both 16- and 32-bit versions, as well as versions that run under Unix and the MacOS. To preserve a consistent set of source code, the Entrust engineers decided to stick with INI files instead of using the Registry. Here’s the process I followed to build a set of mappings to replace Entrust’s INI files with Registry data.
I created a new subkey named
entrust.iniunder HKLMSOFTWAREMicrosoftWindows NTCurrentVersionIniFileMapping.Since Entrust settings are user-specific, I created a new key, HKCUSoftwareEntrust, to hold the settings data. I also added subkeys named Other and EntrustSettings to actually hold the data.
The interesting user-specific data in the Entrust INI file is all in the “Entrust Settings” section. To map it, I added a subkey named Entrust Settings under entrust.ini and gave it a default value of @USR:SoftwareEntrustEntrustSettings. This makes Windows 2000 map data stored in the “Entrust Settings” section to the key of the same name; the @ prevents the mapping code from reading data from the INI file.
I gave the
entrust.inisubkey a default value of #USR:SoftwareEntrustOther. This forces Windows 2000 NT to copy the INI file’s data for new users and to store data for all other sections ofentrust.iniin HKCUSoftwareEntrustOther.
As a finishing touch, I saved the mapping keys to a .REG file using RegEdit so I could quickly distribute them to users throughout our network.
[49] Chapter 5 of Inside the Windows 95 Registry actually explains how to use the Win95 Registry from 16-bit and DOS apps, but there’s no time machine that allows unmodified applications to do so.