Mastering PowerBuilder

Need For Registry

You are probably wondering why the change from something so easy to use (ASCII .INI files) to something that sounds more complex (binary files). In the past, Windows-based applications used the GetProfileString() and SetProfileString() functions to store information in the WIN.INI file. However, as more and more applications were written for Windows, it became apparent that this method had some problems.

One big problem was the scope of the WIN.INI file. Remember, each application was storing information in this file, and there weren't any rules that stated what could be stored and where to store it. Thus the WIN.INI file became confusing because items were added to it in no particular order. When the file was opened, it was hard to find or change something. It was also difficult to determine exactly what needed to be changed and whether all of the changes had been made.

Because there weren't any rules as to what could be stored, WIN.INI could potentially become very large; however, there was an internal limitation of 64K for .INI files in Windows. So if the file became too large, you were just out of luck. This, we can all agree, is simply not an acceptable situation.

To get around these problems, it was recommended that applications begin storing their information in private .INI files rather than in WIN.INI. Okay, so this got around the potential confusion as to what application uses what and the size issue. But this didn't prove to be such a great solution either. Because applications used different files, they were unable to share configuration and other information easily. This was a big problem for applications that were using dynamic data exchange (DDE) or OLE, because these applications needed to share server names.

As a result, the registration database was created in Windows 3.1. This database is the basis of the Windows NT and Windows 95 registry.

Home	Previous Lesson: Windows Registry Next Lesson: The Structure Of the Registration Database