Understanding The Windows 95 Registry

Understanding The Windows 95 Registry Julian Moss examines the function of the Windows 95 Registry and highlights some areas where problems can develop. Windows 95 stores all information about system configuration in a database called the Registry. This replaces the use of text-based configuration files like WIN.INI and SYSTEM.INI, though these files are still present in truncated form for compatibility with 16-bit applications, which expect to find them. Unlike the INI files, the Registry stores information in an indexed, treelike structure. It cannot be viewed or modified directly using a text editor, only by the special tools Microsoft provides. Microsoft requires 32-bit applications to use the Registry instead of creating their own INI files. As you migrate to Windows 95 you will therefore need to become familiar with the Registry and the tools used to maintain it. One of the prime reasons for the change from the simple INI file to the more complex Registry is to cater for the fact that many users are networked and mobile, and may want to access their network from different places using different machines. Keys are used to access the information held in the registry, and these keys can point to different sets of data depending on the hardware configuration chosen or the name of the user of the machine. Settings related to the local hardware and settings that relate to user preferences are stored separately in the Registry. In fact, they are stored in separate files. User information is stored in the file USER.DAT, in the \WINDOWS directory. By default the user settings apply to all users of the PC, but by selecting customised user profiles from the Control Panel Passwords applet, you can have separate settings for each user. If you do this there will be a separate USER.DAT for each username, stored in directories named \WINDOWS\PROFILES\- username. You can also choose to store USER.DAT in the user s network login directory so that wherever they access the network from, their own preferences for desktop colours, shortcuts and so on will be used. [A detailed article on Windows 95 User Profiles is currently in preparation for publication in PCSA shortly - Ed.] System-specific information is kept in SYSTEM.DAT. Since this contains configuration details relating to the hardware and software installed in the machine there is a single copy per machine, which is located in the \WINDOWS directory. "One of the prime reasons for the change from the simple INI file to the more complex Registry is to cater for the fact that many users are networked and mobile." Backing Up INI files had their shortcomings, but they also had the advantage of simplicity. Being text-based, you could easily view them and edit them. If you wanted to see what changes had been made by a program you could simply compare two versions of the file side by side. The Registry doesn t lend itself to quick hacking with a text editor, so it s even more important to take backups of it and know how to recover from them in case Windows 95 gets into a state where it won t load. Windows 95 itself creates backup copies of the two registry data files called SYSTEM.DA0 and USER.DA0 each time it successfully loads. To undo changes made to the Registry during the last session, boot to a command prompt (press F8 when the "Starting Windows 95" message is displayed and choose the Command Prompt option) and copy SYS- TEM.DA0 and USER.DA0 to SYSTEM.DAT and USER.DAT before running Windows. Both the.dat files and their backup copies have the system, read-only and hidden attributes so you will need to use the ATTRIB command on them before you can copy them. Although the Windows backup mechanism is useful, it is better to take backups of the registry that relate to known stable configurations. It might not be until after you have rebooted a couple of times that you realise you would be better off reverting to the original state, by which time the Registry copies you want will have been overwritten. During a Windows session, information is being read from and written to the Registry all the time. Software installation programs update it, Update 86 Page 3 File: O0138.1

"Although the Registry is two files, it is treated as a single logical entity by Windows. Information within it is organised as a tree-like structure with two main branches." If the key is not found, it then looks in HKEY_LOCAL_MACHINE/Software to obtain the default value. Because HKEY_CURRENT_USER always points to settings that are specific to a user, different users can use one machine and the software will always use their own personal settings. Similarly, a user can access a network using different machines and the software will adopt their personal preferences. changes that you make using the Control Panel and other utilities to customise the environment are stored in it, and applications can also use it to store their own settings. Unsurprisingly, the files are quite large: SYSTEM.DAT is typically around 500 KB while USER.DAT is about 100 KB. Although the Registry is two files, it is treated as a single logical entity by Windows. Information within it is organised as a tree-like structure with two main branches. HKEY_USERS is the name (or key) to one branch, which represents the information stored in USER.DAT. HKEY_LOCAL_MA- CHINE is the other branch, which represents the information stored in SYSTEM.DAT. Each branch is broken down into sub-branches, much as a directory is broken into subdirectories. At the end of each node is a uniquely addressed item of information, which may be a string, a binary value or a 32-bit number. User Settings HKEY_USERS may have several branches, each of which contains a set of information relating to a particular user of the machine. When a user logs on, a key HKEY_CURRENT_USER is set to point directly to the branch - in effect the USER.DAT file - corresponding to that user. During a session, HKEY_CURRENT_USER is the root key used to access all the user-specific information. Several distinct areas of information are held in branches under HKEY_CURRENT_USER. For example, the subtree AppEvents holds details of the user s preferences for the sounds that are played when various system events occur. Subtree Control Panel holds the various Control Panel settings such as the colour preferences, keyboard delay and repeat rate and mouse speed settings. Network holds details of persistent and recent network connections. The Software subtree holds information about the user s personal software settings. It is broken down by software company name - Microsoft, Lotus and so on - and then by application name, version number and application-specific categories. This information is equivalent to that which would have been stored in the applications own INI files by 16-bit Windows applications. The Software subtree is interesting because it is related to a similar subtree in the HKEY_LOCAL_MACHINE branch. When software is installed on a machine, its default settings are written under the HKEY_LOCAL_- MACHINE/Software branch of the Registry. This is logical: software is an attribute of the machine, not personal to the user. When a user changes any of the default settings through using the software, however, the defaults are not overwritten. Instead, the changes are recorded in the HKEY_CUR- RENT_USER/Software branch. When Windows obtains the value of a particular key, it looks first in HKEY_CURRENT_USER/Software. System Settings Like HKEY_CURRENT_USER, the HKEY_LOCAL_MACHINE branch of the Registry also holds several distinct categories of information under a number of subtrees. The Config subtree holds details of different hardware configurations, called hardware profiles, which specify which hardware devices are available and which default settings are to be adopted at start-up. All systems start off with a configuration 0001. New hardware profiles can be created using the Control Panel System applet. An example of where this would be useful is in the case of a notebook PC, which might need a different display resolution when attached to a docking station, or different printer drivers when used at home or in the office. The root key HKEY_CUR- RENT_CONFIG provides a direct route to the currently selected configuration. The Enum subtree is used by a type of device driver called a bus enumerator, which finds out what equipment is installed in the system. It is unlikely that you would ever want to modify, or even look at, the information kept here. The same is true of the Hardware subtree, which holds very little information. The Network subtree holds information about the network connection, XXX (default) "XXX_auto_file" XXX_auto_file (default) "Example File" XXX_auto_file\shell (default) (not set) XXX_auto_file\shell\open (default) "" XXX_auto_file\shell\open\command (default) "<path>\runxxx.exe %1" Figure 1 - Registry information to specify how a file is opened. File: O0138.2 Update 86 Page 4

Windows 95 Registry "The Network subtree holds information about the network connection, such as the primary network type, the default username, and data relating to system policies." such as the primary network type, the default username, and data relating to system policies. Policies are another new Windows 95 concept. Essentially they define what a user or group of users is allowed access to. Changes to this section are made using the network icon in Control Panel, or using the System Policy Editor, POLEDIT. There is also a separate Security subtree which is used if you have security options in force. The Software subtree contains information about the software installed on the machine. One of the most important sections is the subtree HKEY_LOCAL_MACHINE\Software\Classes. This has entries for all the types of file which are recognised by the system, including the associations between file types and applications. We will look at this section in more detail later on. Much of the data held here is the same as that which was held in the old Windows 3.1 Registration Database. For compatibility with this the class data can be accessed directly using the key HKEY_CLASSES_ROOT. Other subtrees of the HKEY_LOCAL_MACHINE\Software branch are used to hold information relating to specific applications: the equivalent of the old INI files. As already mentioned, the HKEY_LOC- AL_MACHINE\Software is where the default settings are recorded when an application is installed. User modifications are recorded in a similar hierarchy under HKEY_CUR- RENT_USER/Software. Microsoft has specified that applications should store information in subtrees of HKEY_LOCAL_MACHINE\Softwa- re\companyname\productname- \Version. As an example, Lotus s new word processor WordPro stores its configuration data under HKEY_- LOCAL_MACHINE\- Software\- Lotus\WordPro\7.0. In this example, Lotus has actually named subtrees of this branch after the.ini files that would be used by the 16-bit version of the software. Some other application vendors have chosen to use CurrentVersion in place of a version number. The key HKEY_LOCAL_MACH- INE\Software\Microsoft\Windows- \CurrentVersion contains data which is broadly equivalent to what would have been stored in WIN.INI by Windows 3.x. Some of it is exactly the same. The Extensions subkey, for example, contains the contents of the Extensions section of WIN.INI at the time Windows 95 was installed. However, the file associations listed there appear to be neither updated nor used. One useful subkey here is App- Paths. Adding keys here will allow applications to run without the need either for them to be on the DOS path or for the full path to be given. You create a subkey with the application s name, for example,..\app- Paths\APP.EXE, and enter its full path as the default string value. Now you can run the application simply by choosing Run from the taskbar menu and typing APP. You can also eliminate the need for related executable files like DLLs to be either in the application s own directory or the Windows search path by specifying a path for them as a string value with the name Path. So the subkey for APP.EXE might look something like:..\apppaths\app.exe (default)- "c:\myapp\app.exe"path"c:\myapp- \dlls;" This doesn t work with 16-bit applications, though, as they don t know about this search method. Another useful subkey to know about is SharedDLLs. Applications which install DLLs in the Windows SYSTEM directory are supposed to add a binary value to this subkey with the name of the DLL and a count of 1. If the value already exists, applications are supposed to increment the count. The purpose of this is to allow uninstall programs to check whether any other program uses a shared DLL before removing it. Hopefully once Windows 95 is established, programs will comply with this behaviour more consistently than many beta programs I have seen. System The final major subkey under HKEY_LOCAL_MACHINE is System, which has a subkey called CurrentControlSet. This is further divided into two levels, Control and Services. These subkeys are where a lot of hardware setup data resides. This data is used by Windows at startup....\shell\print...\shell\print\ddeexec...\shell\print\ddeexec\ifexec...\shell\print\ddeexec\application...\shell\print\ddeexec\topic (default) (not set) (default) "<DDE macro to load, print & close file>" (default) "<DDE macro to load, print & close app>" (default) "<application name for DDE communication>" (default) "<topic name for DDE communication>" Figure 2 - Entries for printing via DDE. Update 86 Page 5 File: O0138.3

One key of interest is..\control\vmm32files, which holds a list of all the virtual device drivers (VxDs) which are to be loaded at startup. Microsoft cautions against changing any of the data in the System section using Registry Editor (REGEDIT.EXE). One occasion when you might need to is if you install software which installs VxDs and later remove it. If references to the VxDs remain in the Registry then you will see messages warning that the VxD could not be loaded when Windows starts. The only solution in this case is to delete the offending entries. The best way to find the keys to delete is to use REGEDIT s Find facility to search for a string such as the name of the VxD concerned, since it is difficult to be sure that you have found all the references by searching manually. Data In RAM HKEY_DYN_DATA is a root key to information which is held in RAM because it is rapidly changing. There are two subkeys by default. HKEY_DYN_DATA\Config Manager is used by the Plug n Play Configuration Manager and holds information about the devices that are currently installed and running. HKEY_DYN_DATA\PerfStats contains various network statistical information. Virtual device drivers can create their own keys and provide dynamic data which can then be easily accessed by applications via the Registry. File Associations Figure 3 - REGEDIT in Action. "Microsoft cautions against changing any of the data in the System section using Registry Editor (REGEDIT.EXE). One occasion when you might need to is if you install software which installs VxDs and later remove it." The key HKEY_LOCAL_MA- CHINE\Software\Classes, which as already mentioned can be accessed directly as HKEY_CLASSES_ROOT, holds the data that tells Windows what to call files of a particular type, which icon to use for them, and what to do if a user opens or prints the file. This is an extension of the concept of file associations which simply told Windows what program to run if you double-clicked on a file icon. When Windows 95 is installed over an existing Windows installation, any file associations in the Extensions section of WIN.INI and in the Windows 3.1 Registration Database are automatically added to the Registry Classes data. However, if you install Windows 95 into a new directory, or if you subsequently install a 16-bit application that only creates a WIN.INI association record, no file associations other than the Windows defaults will be set up. The most simple way for a user to set up an association for a file, other than by running an application s Setup utility, is to try opening it. Windows 95 displays the "Open With" dialog, from which the program needed to open the file can be selected. The dialog also allows a descriptive name to be entered for the file type. Windows creates all the Registry keys needed from the information entered in this dialog. For a file with the extension XXX, which is to be opened using RUNXXX.EXE and given the description Example File, Windows would create subkeys of the Classes section as listed in Figure 1. From this you can see that the entry for the file extension holds an internal description of the file type, "XXX_auto_file". This is the name Windows makes up when the "Open With" dialog method of creating an extension is used. If a different icon from that of the associated application has been specified for the file, its source is held in the DefaultIcon subkey. The internal file description is itself a key at the same level in the Registry hierarchy. These keys are used like a chain which leads eventually to the data Windows wants about the file. When the internal name XXX_auto_file is looked up in the Registry it yields the description "Example File". This is the description that would appear next to the file s entry in a Details view of a folder or in its Properties sheet. File: O0138.4 Update 86 Page 6

Windows 95 Registry "The Shell subkey points to a whole set of branches that tell Windows how to open a file in various circumstances." Shell The Shell subkey points to a whole set of branches that tell Windows how to open a file in various circumstances. The command in the subkey...\shell\open\command is the command that launches the application associated with the file. The filename is passed as a parameter, which is substituted for %1. This is treated by most programs as a file to be loaded, so the opened file is displayed in the application s window. If you examine the HKEY_CLASSES_ROOT tree for some other file types such as "wrifile", the internal name for.wri files, you will see that other subkeys can appear under the Shell subtree, such as print and printto. The value of shell\print\command is the command which is used if you print a file by dragging its icon to the printer shortcut. This facility was supported in the Windows 3.1 Registration Database so many 16-bit applications already have a print association set up for them. Some programs are not capable of being instructed to print a file from the command line, however. An alternative method for opening or printing a file - also supported by the Windows 3.1 Registration Database - is to use DDE commands. If DDE is to be used, the subtree shown in Figure 2 is created. The application and topic names ensure that the commands are sent to the right part of the right application. The macro specified in ddeexec is run if the application is already loaded. If it is not loaded, the one in ifexec is used instead. The main difference is that the ifexec DDE commands close the application on completion. If you know the DDE macro commands to use you can enter them in the "Open With" dialog after checking the "Use DDE" checkbox. Usually, though, they are set up by the Setup utility of the application. The shell print mechanism has one major limitation which is that it can only print to the default printer, while many users have at least two: a printer and a fax card. If a user drags a file to the icon of a printing device that is not the current default, Windows 95 offers to change the default printer to the one selected, but it will not change it back afterwards. Though this achieves the desired result it is undesirable as it could lead to files printed from within an application being sent to the wrong device later on. Windows 95 supports a new shell command, printto, which supporrts printing to multiple printer devices. If present, the printto shell command is used in preference to the print command when a file is printed using drag-and-drop. The following parameters are passed to the command line of the program named in shell\printto\- command: %1<document path> %2<printer name> %3<printer driver> %4<device name> The last three items of information are what is needed to change the output device under program control. For example, when the document TEST.DOC is dragged to a printer and a fax icon respectively, the parameters passed might be: C:\DOCS\TEST.DOC Olivetti JP 250- JP350.DRV LPT1: C:\DOCS\TEST.DOC Microsoft Fax- WPSUNI.DRV FAX: Windows 95-aware applications should be written to recognise these extra parameters and provide a means of switching to the specified device if they are present. Likely as not, other applications that you have may not support them. However it may prove possible to use an application s macro language or DDE commands to get the command line parameters and change the printer selection to the requested device. Creating New Documents Another new facility of Windows 95 is the ability to create new documents directly in a folder or on the desktop. If you right-click on a folder and select New from the popup menu, you will see a list of file types like Text Document or Bitmap Image. If you choose one of these, Windows will create an empty file called "New Text Document" or "New Bitmap Image" in the folder. You can then simply change the name and open the new file. This feature, combined with the long filename support, goes a long way towards making PCs easier to use for non-technical users by allowing them to think in terms of documents and folders instead of files and directories. Unfortunately few applications, and none that isn t a Windows 95 application, make use of the facility. However, it is quite easy, with the aid of REGEDIT, to set up some new document types. The key which tells Windows what to do to create a new file of a particular type is the ShellNew subkey to the file extension key in the Classes section. If this has a value named NullFile, with a null string value, Windows creates an empty file called "New <file description>" in the target folder. For an example, look at the entry for a text file (.TXT), which contains the following keys: HKEY_CLASSES_ROOT\.txt (default) "txtfile" HKEY_CLASSES_ROOT\.txt\Shell- New (default) (not set) NullFile"" If you use REGEDIT to delete the NullFile value you will find that the Text Document option has disap- Update 86 Page 7 File: O0138.5

peared from the popup menu. You can remove any other of the default file types that you would rather not have on the menu in the same way. Unfortunately it is no good creating a null file for the majority of applications which have their own specific file format. If you try to open an empty file with most word processors or spreadsheets the applications will probably try to import it as a plain text file, and then display an error message when it fails. For applications like this you must set up an empty document template. Document Templates New document templates are stored in a hidden subdirectory to the Windows directory called ShellNew. You can create one simply by saving an empty document using your application. Then create a ShellNew subkey to the Registry entry for the application s file extension, and add a value named FileName, which should hold a string giving the name of the template you have created. An example for the fictitious "SuperWord" document type might look like: HKEY_CLASSES_ROOT\.doc (default) "swfile" HKEY_CLASSES_ROOT\.doc\Shell- New (default) (not set) FileName - "superwrd.doc" If you used REGEDIT to add the ShellNew key and the FileName value you would find that SuperWord Document (or whatever the text description of a.doc file, found by looking up the swfile key, has been defined to be) would appear on the menu of new document types. If you select this menu item, Windows 95 looks up the key for.doc in the Registry and then looks to see if there is a ShellNew subkey with a File- Name value. As there is, it copies the template document named there from the \WINDOWS\SHELLNEW directory and renames it "New SuperWord Document". The new file can then be renamed and opened in the usual way. This is all well and good, but you will probably find it more useful to have a choice of pre-formatted document templates rather than a single option of a blank document, available from the menu. The problem is that there is a one-to-one association between file extension and document type. A file type can only have one description and one ShellNew File- Name entry. One solution that suggests itself is to define new file extensions for each document type. This is a little cumbersome as you have got to create a complete set of Registry entries, including Shell Open commands, for each new type. Another problem is that the new document types will not automatically be associated with the application that created them on other systems that have that application, unless the special associations have been set up. The ShellNew subkey can have a third value option, Command. If this value is present, the program specified is run when the user chooses a new document of this type from the menu. This is the solution adopted by Microsoft in Office 95. A dummy file type with the extension.ofn is created in the Registry, with the internal name Office.FileNew, and the description Other Office Documents. When "Other Office Documents" is selected from the menu, the program MSOW.EXE is run, which presents a tabbed dialog showing all the document templates available. However, choosing one opens it in the Office application: the user must still use File Save As.. to save the new document to the correct location. Windows passes the path of the new document, eg, "C:\WIN- DOWS\DESKTOP\New SuperWord Document.doc" to the program if the parameter %1 is added to the command line, as in this example: HKEY_CLASSES_ROOT\.doc (default) "swfile" HKEY_CLASSES_ROOT\.doc\Shell New (default) (not set) Command "c:\utils\winscr.exe template %1" Here, a Windows batch language has been used to offer a choice of document templates, one of which will be copied to the path passed in the parameter %1. With a little effort, even your non Windows 95-aware applications can be more closely integrated with the new desktop, making life easier for your users. Conclusion Editing the Windows 95 Registry with REGEDIT isn t something you should have to do every day. Wherever possible, it is easier and safer to use the configuration tools that Microsoft provides. However, direct editing can provide a way to recover from problems caused by defective setup or uninstall programs. It can also enable you to take advantage of Windows 95 features that your applications may ignore. It s certainly worthwhile to know how the Registry is organised and what data is stored there. But before you get too carried away with tinkering, take a backup. The Author PCSA Julian Moss is a freelance writer specialising in PC technology, and developer of the Windows batch language WinScript which is on this month s PCSA Utility Disk. You can contact him on jmoss@cix.compulink.co.uk. File: O0138.6 Update 86 Page 8