One of RegEdit ’s unique features is its ability to store Registry data in a human-readable format, then import data in that same format to repair or recreate existing data, or even create new keys and values. Better still, you can create your own files, so you can automate Registry changes needed for your particular network or computing environment. You can also store multiple sets of Registry data and switch between them as needed. This is often useful for system administrators who need to develop their own management tools.
The .REG file format is simple to understand. Fortunately, that makes it simple for programs to parse, too; in Chapter 8, you’ll see some Perl scripts that manipulate .REG files. In the meantime, let’s examine the format that RegEdit uses so you’ll be able to make sense of it when you see it.
Here’s a snippet gleaned from my desktop machine’s Registry:
REGEDIT4 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser] "Type"=dword:00000020 "Start"=dword:00000002 "ErrorControl"=dword:00000001 "ImagePath"=hex(2):25,53,79,73,74,65,6d,52,6f,6f,74,25,5c,53,79,73, \ 74,65,6d,33,32,5c,73,65,72,76,69,63,65,73,2e,65,78,65,00 "DisplayName"="Computer Browser" "DependOnService"=hex(7):4c,61,6e,6d,61,6e,57,6f,72,6b,73,74,61,74,69, \ 6f,6e,00,4c,61,6e,6d,61,6e,53,65,72,76,65,72,00,4c,6d,48,6f,73,74, \ 73,00,00 "DependOnGroup"=hex(7):00 "ObjectName"="LocalSystem" [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Linkage] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Linkage\Disabled] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters] "MaintainServerList"="Auto" "IsDomainMaster"="FALSE"
The first line in the file identifies the file as a .REG file. If this string’s present, RegEdit attempts to interpret the rest of the file as a set of keys and values; if it’s not present, RegEdit complains that the file you’re importing isn’t really a .REG file.
The next interesting line identifies the full path to a key. In this case, the key is HKLM\SYSTEM\CurrentControlSet\Services\Browser. There are two noteworthy things about this key path. It’s enclosed in square brackets (which RegEdit looks for as delimiters), and the root key is spelled out: HKEY_LOCAL_MACHINE instead of the more convenient HKLM.
The remaining lines for this key specify its values as name/value pairs. The general syntax looks like this:
"name"=[type:] ["]value["]
Each value has a name. Keys can have a special value whose name is empty; RegEdit displays this value with a name of (Default), but in .REG files the special name @ takes its place. The name must always be in double quotes to accommodate the fact that Registry value names can contain spaces.
Next comes the optional data type specifier. The specifier is necessary to preserve all the details of the values. Even though RegEdit can only directly edit binary, DWORD, and string values, its export and import commands must correctly preserve the entire state of the keys and values they’re operating on. When the value is a standard REG_SZ string, RegEdit omits the type specifier; otherwise, it uses the values shown in Table 4-2. Note that if a type specifier’s used, the colon that follows it is required.
The value’s actual value is the next item in the name/value definition. Standard REG_SZ strings are easy to identify, because they’re always between double quotes. DWORD values are written as 32-bit hex numbers, including leading zeros but without any kind of type identifier (such as the “0x” prefix that RegEdt32 uses). The other data types are all represented as a comma-delimited list of hex bytes, as you can see in the previous code snippet. Since all these data types can be of arbitrary length, the actual number of bytes can vary from value to value. RegEdit allows you to use the backslash character as a line-continuation character; when present at the end of a line, the backslash indicates the following line should be considered part of the current line.
Blank lines aren’t significant to RegEdit ; however, if no value definitions follow a key definition, that key is created without any values, as with Browser\Linkage and Browser\Linkage\Disabled in the previous example.
You can export any key and its subkeys, from the root keys on down. When you export a key, all the data necessary to recreate it is stored in a .REG file that you can archive, print, or edit like any other. You can also reimport the file. As you learned in Chapter 3, this capability gives you a useful way to back up and restore individual keys within the Registry.
The Registry→Export Registry File... command actually does the exporting; when you invoke it, you see the dialog box shown in Figure 4-9. If you have selected a key in the key pane, the Selected branch radio button is selected, and the currently active key appears in the associated text field. If you’d rather export the entire Registry, you can use the All radio button to do so.
Once you’ve supplied a filename and chosen exactly what you want to export, RegEdit writes out the selected data to your file, using the format described earlier in What’s in a .REG File?
Once you’ve exported a .REG file or created one by hand, RegEdit allows you to load it back into the Registry. As you read in the preceding section, the .REG file contains enough information for RegEdit to load key and value data from the file and place it in the proper location in the Registry. However, the program is indiscriminate; once you tell it to load a file, it happily blasts the entire file’s contents into your Registry, with no further opportunity for you to limit the scope of its replacements.
When you select the Registry→Import Registry File... command, RegEdit displays the standard Open File dialog box so you can choose a file. If you select a file that’s not in .REG format, you get an error dialog box telling you that the file you chose can’t be loaded. If, however, the file is in valid format, RegEdit imports it, displaying a progress dialog box to tell you how far along it’s gotten. There’s no way to cancel or interrupt the loading process from within the program. Forcing RegEdit to quit during an import operation (by using the Task Manager, a process manager such as PVIEW, or other tools) can leave your Registry looking like the front yard of your local college’s Fraternity Row after a football game--don’t do it.
Once the import operation’s finished, you see a confirmation dialog box that tells you RegEdit did in fact import the entire file. It also includes the pathname of the imported file so you’ll know exactly what file got imported (just in case you’ve forgotten).
One caveat: when you import data with a .REG file, RegEdit adds any keys that are in the .REG file but not in the Registry, and it changes the value of any keys that appear in both places. It doesn’t remove keys that are in the Registry but not in the .REG file, so you can’t use RegEdit to clean out an accidentally added key or remove keys that have been added since the time the .REG file was created. If you import a key whose path contains components that don’t exist, RegEdit creates any subkeys needed to complete the entire path to the new key.
Even though RegEdit can generate .REG files, there’s no reason why you can’t generate your own files. In fact, this is a handy strategy when you need to make the same set of Registry changes on more than one machine. You can create a .REG file, test it and tweak it on a single machine until you’re satisfied that it does what you want, then import it using RegEdit on each machine you want to modify.
Windows 2000 Server includes the File Server for Macintosh (FSM) package, which lets a Windows 2000 server serve NTFS volumes to Mac clients. To the Mac, these FSM volumes look just like native Mac disks, and they preserve the Mac-style file type and creator information needed to associate files with the applications that created them. Unfortunately, NTFS doesn’t support these type and creator codes; instead, FSM keeps a table that translates PC-style file extensions to the corresponding type and creator codes. This enables both PC and Mac users to recognize files with names such as chapter04.doc as Microsoft Word files.
Windows NT 4.0 had the same feature, but it was called Services for Macintosh (SFM) instead.
Microsoft helpfully provides a default set of type/extension mappings with FSM. That’s the good news. The bad news is that it doesn’t include many of the most useful file types.[24] Even if it did, the exact mix of file types you use depends on what programs your users are running. FSM provides a dialog box for associating types and extensions, but it’s a tedious task at best. RegEdit provides an ideal solution: once you have a set of file extensions built on one server, you can easily replicate it to other FSM servers by importing a .REG file. In fact, you can easily do this with new servers in your domain, too, making it easy to maintain and upgrade your file services without undue effort on your part.
One especially handy use for these files is to let you fine-tune your .REG files without endangering the rest of your Registry. You accomplish this by building a file that contains the values and keys you want to modify, but that puts them beneath a different key than the original. For example, if you’re writing a .REG file you want to apply to HKLM\Software\Netscape\Netscape Navigator, you can safely fiddle around with your .REG file without fear by following these steps:
Export the key you’re going to modify using RegEdit ’s export facility. This gives you a .REG file that overwrites the existing key’s contents when reloaded, restoring the original contents.
Make a note of the path that contains the keys you’re modifying. For example, if you’re modifying keys that live under the HKLM\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping tree, your .REG file contains code that looks like this:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\IniFileMapping\Clock.ini] @="#USR:Software\\Microsoft\\Clock"
Use a text editor to change all instances of the key’s path to a new, unused value. For example, you might change from HKLM\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping to HKLM\Software\Microsoft\Windows NT\Testing\IniFileMapping. Of course, you must use one of the root keys as the base, but you are otherwise free to improvise a path, since RegEdit creates any keys or subkeys that need to be created to complete the import.
Load the new .REG file; its contents will then appear under the key you’ve specified.
You can now edit the .REG file to your heart’s content. When you’re satisfied with the changes it makes, you can reverse Step 3 to put the original key path back in place so the changes go where you want them to, then use, distribute, or store the .REG file however you’d like.
Why does this work? Applications and system components look for Registry data in a particular path. If the data isn’t in that precise location, the application won’t find them. This is akin to what would happen if your postman put your incoming snail-mail under your doormat: it would be delivered, but when you checked your mailbox, you wouldn’t find your mail. Likewise, if you take the Browser service’s settings from HKLM\System\CurrentControlSet\Services\Browser and copy them to HKLM\Software\TestBrowser, you can still see your changes, but the system component they’re intended for won’t.
Get Managing The Windows 2000 Registry now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
