by Brian Grainger: brian@grainger1.freeserve.co.uk

This article was first published in the ICPUGSE Newsletter Number 107.
Have a look at the ICPUGSE web pages for details on how to join ICPUGSE

 

INTRODUCTION

In the Editorial (of the ICPUGSE Newsletter) last time it was mentioned that a member had asked for an article to answer the questions:

What exactly is the Registry?
What does the Registry do?
Why does it sometimes appear that the Registry is not necessary at all?

I thought the answer was obvious. Ever since Windows 95 appeared we have been told that the Registry is a secret area that is so dangerous we must take every precaution under the sun before we even look at it. I used to think that way but I have mellowed as I have slowly grown to understand the Registry. Things have not been made easy for us. Information available on the Registry has been small and hidden away. Special tools are needed to do anything with the Registry, even to view it. When viewed, portions of it consist of incredibly long hyphenated numbers and bits of it appear to be duplicated. However, some information is out there and I will use this, together with my own experience, to try and answer the original questions as well as provide some useful information on Windows 95. I am afraid there are lots of things to which I do not know the answer but something is better than nothing. I am also going to assume the reader has a reasonable knowledge of Windows and how to use it. The Registry is an advanced topic so, as the training courses say, some prior knowledge of Windows is assumed!

WINDOWS 3.1

To start at the beginning the original title of the Registry was 'the registration database'. This tells us immediately that the Registry is a database and is something to do with registration. A database is a collection of data with some sort of structure imposed. The data in the Registry is concerned with anything that is registered with Windows, i.e. anything that Windows needs to know about to operate correctly. The data may relate to hardware, software or peopleware (that's users). The registration database has been with us since the days of Windows 3.1 although nobody was too concerned about it then! In those days it was used solely to keep information about applications so that Windows could successfully perform Object Linking and Embedding (OLE) options. Any application that supported OLE was registered and the registration entry identified:

1. the document file types associated with the application
2. how the document was opened by the application, e.g. via the File menu by selecting Open
3. how the document was printed by the application, e.g. via the File menu by selecting Print.
4. if Dynamic Data Exchange (DDE) was used for (2) and (3) then the appropriate DDE command strings.

The concept of document file types was well known, as was the ability to register file types using File Manager. In this way all *.DOC files could be associated with Microsoft Word, *.WPD with WordPerfect, *.WRI with Write, etc. You may also know that such associations could also be seen in the [embedding] section of WIN.INI. However, it was a mistake to think that you only had to alter WIN.INI to make it work. The [embedding] section in WIN.INI was provided for backwards compatibility with applications written for Windows 3.0. An application written purely for Windows 3.1 used the information in the registration database.

Now OLE was only one function of Windows 3.1. Windows needed to know information for other functions. Where was that information stored? In Windows 3.1 it was stored in SYSTEM.INI, WIN.INI and all the other *.INI files! The ini files were relatively easy to play with since they were text files. Any text editor could be used to view or amend them. Backup was a straightforward matter and deletions, carried out with a text editor, would truly reduce the size of the file. There was even some information with the standard Windows 3.1 installation on what the INI files contained. If you bought the Windows 3.1 Resource Kit you got a quite comprehensive section on the contents of SYSTEM.INI and WIN.INI.

As time went on a couple of problems with the INI files became obvious. To those of us at home the prime problem was you never knew for sure which INI file contained the information you were looking for. If the data related to an application was it in the WIN.INI or in an application.ini. A general rule of thumb was that SYSTEM.INI contained information relating to the system, generally hardware and set up. Win.ini contained information specifically tied to Windows and primarily software related. However these general rules could not be relied upon.

A second problem became much more apparent if you were involved with installing Windows on a network, where more than one user might use a particular PC, or a user might want to log on from the PC they happen to be nearest to at the time. We all know that Windows can be customised to our own predilections so if, for example, you liked purple desktops with red text displayed on it that could be achieved. However, it was unlikely that everyone who used your PC would share your colourful outlook on life. Also, when you moved to another PC it may come up standard black on white. How does one cope with this. Somehow each user had to have their own specific ini files and Windows would use them when the user logged on. This is possible to do but a nightmare to administer, especially when changes were required. Things would be easier if user specific parameters and machine specific parameters were in separate files. Then the file specific to the machine could stay with it and the file specific to the user could roam with them. Unfortunately, this was not the way SYSTEM.INI and WIN.INI were structured.

Then one day along came Windows NT. This was Microsoft's first real attempt at a true networking operating system. (I discount LAN Manager as it never really achieved critical mass). Along with NT came the concept of the Registry and its structure. It is this concept that has now passed on to Windows 95 and future Windows versions. The rest of this article relates to the Registry as implemented in Windows 9x.

ANSWERING THE QUESTIONS FOR WINDOWS 9X

What, exactly is the Registry?

It is a collection of data on hardware, software and users that has been registered with Windows. It provides a unified, centralised database for storing system and application configuration data. The database is in a hierarchical form, which means that data can be stored in a folder like way and sub folders can be supported. The Registry is roughly equivalent to the INI files used under Windows 3.x, with each key in the Registry similar to a bracketed heading in an INI file and with Registry values similar to entries under the INI headings. However, because of the Registry's hierarchical form the Registry keys can contain sub keys, while INI files do not support nested headings. Registry values can also consist of binary data, rather than the simple strings used in INI files.

What does the Registry do?

It provides the data to Windows, as required, to enable Windows to perform its various functions. Because the Registry contains all settings required to configure memory, hardware peripherals and network components it is no longer necessary to configure settings in start up configuration and initialisation files. Because settings are stored in a central location, local and remote support for system configuration can be provided using Windows 95 tools.

The Registry enables the following benefits to be achieved:

• A single source provides data for identifying and configuring the hardware, applications, device drivers, and operating system control parameters. The configuration information can be recovered easily in the event of system failure.
• Users and administrators can configure computer options by using standard Control Panel tools and other administrative tools. These are GUI based so reduce the likelihood of syntactic errors in configuration information.
• System administrators can examine configuration data on remote networked computers.
• The operating system automatically backs up the last good configuration used to start the computer.
• Because user specific Registry information can be maintained on a central network server users can have access to their own customisation preferences when logging on to any computer, and preferences for multiple users can be maintained on a single computer.

Why does it sometime appear that the Registry is not necessary at all?

I don't understand the question! I would like to have an example of this phenomena. Without the Registry Windows 95 would not have its data and the functionality would break down. Perhaps the questioner is referring to the self repair capability of the Registry but more of that later.

IMPLEMENTATION OF THE REGISTRY

The Registry is physically implemented in two binary files called:

SYSTEM.DAT
USER.DAT

User-specific information is contained in USER.DAT. The information in this file is reflected in user profiles. Hardware specific and computer specific settings are contained in SYSTEM.DAT. This information is reflected in hardware profiles and in the settings displayed in Device Manager.

The Registry files are stored by default in the Windows directory and have system, hidden and read only attributes set. However, the two files can be located in physically different locations. For example, if user profiles are enabled, SYSTEM.DAT can be stored on the local hard disk and USER.DAT stored in each user's logon directory on the network. This allows "roving" users to maintain the same desktop preferences wherever they log on to the network.

As far as the user is concerned the two files are inseparable and are manipulated as one through special tools.

In operation Windows writes data to the Registry when a flush occurs - that is, when something happens after changed data has aged more than a few seconds or when an application intentionally flushes the data to the hard disk.

When Windows starts it detects the hardware configuration and checks it with the values in the Registry. If there is a difference the hardware update procedures go into action. When Windows starts SUCCESSFULLY the operating system backs up the Registry, by copying the current SYSTEM.DAT and USER.DAT files to SYSTEM.DA0 and USER.DA0 respectively. These DA0 files also have their hidden, system and read only attributes set. The user should ignore them unless there is a problem starting Windows.

CONCLUSION TO PART 1

This time I hope I have managed to give an idea of what the Registry is about and how it is implemented. Next time I will look at tools for viewing and manipulating the registry. In addition I will look in detail at the top level structure of the Registry.

In preparing this article I have used the following data sources and thanks are given to the individuals concerned in their preparation.

Windows 95 Resource Kit (initiated by Microsoft)
Windows 95 Registry FAQ (initiated by Kent Daniel Bentkowski)