The Registry is a centralized, system-defined database in which applications and Windows system components store configuration data. In the past, applications based on Microsoft Windows 3.1 stored such information in the WIN.INI file or some other application-defined INI file, while the system stored its configuration data in SYSTEM.INI. Because this information was stored in ASCII files, a user could edit and view it in any simple text editor, such as Notepad. In the new Registry, the data is stored in binary files. Instead of using text editors to update the information contained in the Registry, applications can either use the Registry functions supplied by the system or create registration (REG) files that contain information to be stored in the Registry. These REG files are ASCII files that can be created with any text editor. The Registry Editor (REGEDIT) can read these files and store the information in the appropriate places in the Registry.
Why the change from easy-to-use ASCII files to more complex binary files? In the past, Windows-based applications used the GetProfileInt, GetProfileSection, GetProfileString, WriteProfileSection, and WriteProfileString functions to store information in the WIN.INI file. As more and more applications were written for Windows, however, problems with this method became apparent.
One big problem was the scope of the WIN.INI file. Each application was storing information in this file, and no rules governed what could be added or where it could be located. Data was placed in WIN.INI in no particular order. When the file was opened, it was hard to find or change an item. It was also difficult to determine exactly what needed to be changed and whether all the necessary changes had been made. In addition, INI files in Windows were limited in size to 64 KB, so if the file became too large, you were just out of luck.
One recommended solution was to have applications store their information in private INI files rather than in WIN.INI by using the GetPrivateProfileInt, GetPrivateProfileString, and WritePrivateProfileString functions. This got around the size issue and the potential confusion over which application uses what, but it didn't prove to be such a great plan. Because applications used different files, they were unable to share configuration information and other data easily. This caused problems for applications that were using dynamic data exchange (DDE) or OLE, because these applications need to share server names.
As a result, the registration database was created for version 3.1 of Windows. This database is the basis of the Registry now implemented in both Microsoft Windows NT and Windows 95.