|
|
|
By John Woram
Click Here to see a
70.2KB bitmap image of artwork
which goes with this article, entitled:
What's In Store
TAKE A LOOK at page 967 of the Microsoft Windows 95 Resource Kit, and you'll find this statement: "The Registry simplifies the operating system by eliminating the need for AUTOEXEC.BAT, CONFIG.SYS and .INI files." Right. And the check is in the mail.
If you believe either of these modern folktales, then this month's column might not be for you. It's true that the Registry often makes it possible to do away with CONFIG.SYS and AUTOEXEC.BAT, but the .INI file is going to be with us for a long time. In fact, it's not unusual to find 25 to 75 .INI files on a machine that had no previous version of Windows installed. Many of these were created by Windows 95 itself, and others by applications designed to run only under Win95. If you need hard evidence, just go to Explorer Tools/Find and search for all .INI files on drive C: . You'll discover the .INI file is alive and well, even under Win95.
As for the Registry, here's a closer look at how it "simplifies the operating system," if not always the operator's life. In fact, life gets a bit complicated when said operator tries to figure out how the Registry stores its information. As we shall see, there's more than one way to do it. I'll begin here with a quickie overview, and then discuss some specific storage details.
Each of the Registry's six sections is identified as HKEY_SectionName, which immediately suggests a pop quiz to separate the power users from the rest of us: What's an HKEY? Hotkey? Hierarchical key? Neither. It's a programmer's handle to a key (hence, HKEY) in which configuration information is stored. Each key leads to a long series of subkeys and sub-subkeys that contain the information formerly found in .INI files.
Here's a comparison of a key and its familiar WIN.INI counterpart, which looks like this:
[Desktop]
Wallpaper=C: \WINDOWS\PLUS!.BMP
In the Registry, the [Desktop] section header becomes a desktop (usually a lowercase "d") subkey under the HKEY_CURRENT_USER\Control Panel subkey. If the desktop subkey is highlighted, the Contents pane shows the following information:
Name Data
Wallpaper "C: \WINDOWS\PLUS!.BMP"
In other words, it's the same old data, but in a brand new format. For legacy applications unaware of the Registry, this particular example remains in WIN.INI as well. If you change wallpaper from within Win95, WIN.INI retains the old wallpaper specifications for the moment, even though the new wallpaper appears on screen. But the next time Win95 opens, it checks the Registry, then rewrites WIN.INI as required to bring it into conformity with the Registry. If your system is configured for two or more users, Win95 rewrites WIN.INI every time it starts, so that it contains the current wallpaper (and much other) information appropriate to the current user.
Now, let's take a closer look at the information as it appears in the Registry Editor's Contents pane. But first, forget everything you learned about the English language: In Microspeak, each horizontal row in the Contents pane is referred to as a value. Thus, the information in the two columns is referred to elsewhere as the Value Name and the Value Data, even though the word Value doesn't appear here in the Contents pane. To keep things confusing, the Edit menu's Find option lets you search any or all of three categories: Keys, Values and Data. The first and last are self-explanatory, while the Values check box really refers to the Name column only.
In each Contents pane row, the icon at the left side of the Name column indicates the format of the information in the Data column, and is immediately followed by a descriptive name for that data. The Registry Editor treats the icon and name as a single entity under the Name column.
The format of the information in the Data column is indicated by the icon at the beginning of the row. However, any resemblance between that icon and the way the data looks is sometimes coincidental. For example, here are some sample lines from various Contents panes. Quiz time: Which are binary, and which are string format?
Name Data
Available "1"
Enabled "0"
InitWndRight 0x000003c1 (961)
ViewView 1c 00 55 81 01 . . .
Wrong. If the Data column shows a binary 0, 1 or anything else enclosed in quotes, it's a string. But if it shows a hexadecimal number, it's binary. In other words, a hexadecimal number is binary, and a binary number (in quotes) is a string. What could be simpler?
If you're having format anxiety, double-click on any Contents pane icon. The Edit window's title bar will show one of the following legends, revealing the format of the data in that row:
Edit DWORD Value
Edit Binary Value
Edit String
To explain the difference between dword and binary values, the former always begins with 0x followed by a 4-byte nonspaced hex number and then its decimal equivalent in parentheses. The latter is any other hexadecimal sequence, with a space between each byte and no decimal equivalent at the end. Thus, you might reasonably guess binary data that can be expressed in 4 bytes will show up as a dword, and if it requires more or less than 4 bytes, it will be expressed as a binary value.
Guess again. Search the Registry for EditFlags and you'll find many 4-byte sequences expressed as binary values rather than as dwords. There doesn't seem to be any consistent pattern to the choice between these formats, other than perhaps the personal preference of the programmer du jour. For instance, the composite Registry example (What's In Store ) shows how various Win95 applications store the same information. To create the top illustration, I sized three application windows so their dimensions were the same, then placed them one on top of another so that all three occupied the same portion of the screen.
With the Registry Editor window at the top of the heap, I opened each application's subkey so that I could examine its Contents pane. Needless to say, I could open only one key at a time, so the illustration required a bit of cut-and-paste to show all three in a single Contents pane. Also, the illustration shows only those items pertaining to the position and size of each application window.
Note that Hewlett-Packard's Position subkey reports the height and width of the window, followed by the x, y coordinates of its upper left-hand corner. In this example, the window's height and width are 544 and 803 pixels and the upper left-hand corner is at x = 158 and y = 92 pixels, measured from the left side and the top of the screen.
The window height and top (544 + 92) mean the bottom is at pixel 636, while the window width and left side (803 + 158) would place its right side at pixel 961. That's just the way the WINDOWS Magazine Wintune 95 utility reports the information in its Settings subkey. Note that both utilities require four data entries to report the windows' size and placement, but use different names for their subkeys and within the Contents pane's Name column. The applications do, however, use the same dword data format to report their values.
And now for something completely different. The subkey for Microsoft's own Registry Editor window is tucked five levels down, in the Regedit subkey. If you examine its Contents pane, you'll find nothing that even vaguely resembles the previous two utilities. It turns out Microsoft stores the equivalent information within a 60-byte binary data entry named View. Because the data extends well beyond the window border, just double-click on the View name or icon to open the Edit Binary Value window, which also appears in the illustration. Look closely and you'll see the 0x0000009e dword for the upper left-hand corner in the other two applets hides out here at bytes 1C-1F, where it's stored in reverse format as 9E 00 00 00. It's followed by the other three dwords found in the WINDOWS Magazine Settings subkey. Note that the same hexadecimal letters appear as lowercase a-f in the Contents pane's Data column, but as uppercase A-F in the Edit window.
To help keep score, I drew a series of lines from one applet's data to another's, to show how the data in one will appear in the others. For general information, the final four dwords in the Edit Binary Value window define the Registry Editor's split bar position (7E 01 00 00), the width of the Name (8A 00 00 00) and Data (26 01 00 00) columns, and finally, the condition of the status bar at the bottom of the Registry Editor window (01 00 00 00 = enabled).
Some Microsoft applets and applications specify their window size as just described, while others don't. For example, Word for Win95's Data subkey has a single entry named Settings; its Data column contains a 2KB-3KB binary sequence that includes the window specifications and much else, such as a list of recently opened document files. By contrast, the Internet Explorer's Document Windows subkey defines its own window by specifying its height, width, x and y data. But they're not dwords. Instead, the Explorer writes the data as binary values--that is, as separate 4-byte entries, each written in the reverse hexadecimal format found within the Registry Editor's View entry.
The point of this little excursion through the Registry was to illustrate how different formats may be used to record the same information. And the moral of the story is: If you've seen one subkey, you definitely haven't seen them all.
I mentioned earlier that Win95 checks the Registry as it opens, then rewrites some WIN.INI entries to match the current Registry data. As an interesting reversal of this procedure, Win95 also checks the [fonts] section of WIN.INI to see if any legacy application installed fonts during the previous session. If it did, the lines are written into the Registry and removed from WIN.INI. In the case of TrueType fonts, the matching filename.FOT file is deleted because Win95 doesn't need it.
So, if you see something in an .INI file immediately after installing a new application, and whatever it is has disappeared the next time you look, it's probably been relocated to a Registry subkey.
By the way, the status bar legend in the illustration begins with "Pentium 590" instead of the ubiquitous "My Computer." That's because the REGEDIT.EXE file was edited to replace the latter expression with the former. If you don't mind risking total system trash, and possibly annoying some people in Redmond, you'll find your own "My Computer" begins at byte 0001A3BA. It's stored in Unicode format, that is, as M.y. .C.o.m.p.u.t.e.r., where each period represents a null (00) character. Just make a backup copy before experimenting. With luck, you won't need it.
Senior Contributing Editor John Woram is the author of Windows Configuration Handbook (Random House, 1993). Contact John in the "Optimizing Windows" topic of the WINDOWS Magazine areas on America Online and CompuServe. To find his E-Mail ID Click Here
|
|
|