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.