Managing the Registry

The registry is two files User.dat and System.dat (with third file Classes.dat in Windows ME) that are hidden in the Windows base directory. They are structured binary files, and not amenable to casual direct editing! If you break the index structure of these files, Windows 9x will destroy them on the next startup, replacing them with older versions if possible.

The structure is (as far as I am aware) undocumented, and no tools exist to repair them at a structural level. RegEdit.exe is the editor, and can also be used to export, import, and rebuild the registry from DOS Mode. Windows 98 and later also include ScanReg.exe, a Windows-only utility that checks the structure for errors and can mimic the DOS Mode RegEdit procedure of rebuilding the registry from a full registry export.

Using RegEdit in Windows

RegEdit offers interactive editing of the registry in Windows only. RegEdit is an unforgiving place that puts you squarely in the driving seat; it's the one place where you are left to do as you like, with no "Are you sure/mad?" tut-tutting from Windows. It's crucial to understand how RegEdit differs from other editors you may be used to:

• All changes are "live", i.e. are effected immediately! So you can't hack around and then choose not to save changes on exit (e.g. as you usually can in CMOS Setup) and there's no Undo either.
  
  
• Being an index-structured file, every entry has a secondary role in facilitating the indexing of other entries. When an entry is "deleted", its space is still there to fulfil this indexing role and the files don't shrink. The only way to shrink a bloated registry is to rebuild it, either using RegEdit in DOS Mode or using ScanReg with appropriate parameters.
  
  
• There's no way to comment entries in RegEdit, as there is no standard syntax as there is for .ini files; it's up to the process that creates the entry to interpret it. Generally, unanticipated content is ignored, but adding fluffware as comments is a bad idea as it bloats the registry (see the point above this one).
  
  

Instead of commenting registry entries within the registry itself, you should export content that is about to be changed. That way, changes to values can be reversed by importing the .reg file you created - and you can comment .reg files, conventionally, by preceding a comment line with a semicolon (";"). Note that importing a .reg file will not delete any new entries created since the export was made, so you should make a note of any additions so you can remove these manually.

Tips for working with .reg files

• You must use a pure ASCII text editor to edit .reg files, such as Notepad or the "DOS" Edit utility. The latter is better, as you can work on up to 9 files at once, it has better Search and Replace than NotePad, and it works with files over 32k or 64k in size instead of switching over to WordPad.
  
  
• When exporting an entry that is about to be changed, always select as "low" in the registry tree as you can, so that you don't save as little as possible beyond the scope of what you are working on.
  
  
• Edit newly-exported .reg files to trim away material that is outside the scope of your changes; that way, if something else makes changes there, the changes won't be reversed should you import the .reg to undo your own changes.
  
  
• Remember to leave a blank line (extra "enter" keystroke) at the end on a .reg file, else the last line will be omitted from a merge (it's a RegEdit bug).
  
  
• The default action for .reg files is "Merge", which makes them hi-risk indeed. For this reason, you should spoof the extension so that you don't accidentally import (merge) a .reg file (e.g. when trying to select it to move/copy/delete).
  
  

This last point is particularly crucial with full registry exports as used to rebuild the registry; they are very dangerous to leave lying around! Be careful also of .reg files from other computers, which may restore inappropriate hardware settings if merged into the wrong system's registry.

Don't ever use WordPad to edit ASCII (plain text) files! This is dangerous because it may insert formatting characters such as Bold, Italics, font directives, etc. WordPad, Word, etc. are not ASCII text editors and should not be used as such.

Because .reg files will enter the registry if "opened", you may want to manage this risk by changing the default action for .reg files from RegEdit.exe to, say, NotePad.exe; that gives you some protection against malicious .reg that may be dropped into the startup axis or, sent to you as emaul attackments.

Using RegEdit in DOS Mode

The same RegEdit.exe works within DOS Mode as well, but not interactively; use RegEdit.exe /? to see the syntax, and make sure you know exactly what the various parameters do before use. You can use DOS Mode RegEdit to export and import ("merge") .reg files, and you can create the registry afresh from a .reg file.

Warning: DOS Mode RegEdit in Windows 95 original and SP1 cannot handle registry keys larger than 64k, so often fails to export these properly. In which case, the registry rebuilt by RegEdit /C will be broken, and you will not be happy. It is reported that you can use the RegEdit.exe from Windows 95 SR2 to work around this bug.

Compacting the registry

The registry grows as the system ages, and because "deleted' entries remain in place to maintain index integrity, it doesn't shrink after uninstallations or cleanup. It will probably become fragmented at the file level, as the registry is always "in use" and so may not be defragged by Defrag. That not only slows access to the registry, but also increases the risk period during which a crash, reset or power off will interrupt the process of directory writes and thus corrupt the file.

For this reason, it is sometimes advisable to compact the registry. In Windows 98, there's a utility called ScanReg that will do that; in fact, if the system detects too much "dead space" within the registry, ScanReg may perform this task automatically. But in Windows 95, you have to do this by hand using RegEdit in DOS Mode, as follows:

1. Get out of Windows, into pure DOS Mode
2. Make a backup copy of the hidden User.dat and System.dat files
3. Use RegEdit /E C:\Some\Path\SomeName.reg to create an export of the entire registry
4. Use RegEdit /C C:\Some\Path\SomeName.reg to destroy the original registry and rebuild from the export
5. Rename the saved C:\Some\Path\SomeName.reg to (say) SomeName.txt for safety
6. Exit back to Windows
7. If fails, go back to DOS Mode and restore your backup copy of User.dat and System.dat

Make sure you do not skip step (2) above, as this process may well fail and leave you with no working registry at all. Ignore step (5) at your peril - you have been warned!

The rebuild process also generally excludes structurally damaged entries, as these may not be exported to the .reg file; for this reason, compacting the registry is sometimes worth doing as part of troubleshooting rather than purely for performance or safety reasons.

Backing up the registry

You don't have to be in DOS Mode to do this, although you should be if you want to restore older registry files (as opposed to importing .reg file data, which can be done in both DOS Mode and Windows).

The registry files have hidden, system and read-only attributes set, so with default settings, they won't be visible in Windows. You can use the following command sequence to make backup copies:

C:
CD %WinDir%
Attrib -r -s -h User.dat
Copy User.dat C:\Some\Path\UseName.dat
Attrib +r +s +h User.dat
Attrib -r -s -h System.dat
Copy System.dat C:\Some\Path\SysName.dat
Attrib +r +s +h System.dat
Attrib -r -s -h Classes.dat
Copy Classes.dat C:\Some\Path\ClasName.dat
Attrib +r +s +h Classes.dat

If you paste the above into Notepad and save as a RegBack.bat file, it should work - as long as you use meaningful values for C:\Some\Path, of course. You may want to precede with an @Echo Off statement for cosmesis, and use your own name for Attrib.exe if you have renamed that file as part of your risk management.

If all else fails, remember that parts of the original (fresh-install) registry are usually preserved as System.1st and Classes.1st in the root of the C: volume. Use these only in extremis as you will lose all references required by all subsequently installed software or drivers.

(C) Chris Quirke, all rights reserved - January 2001

Back to index