While writing these posts revisiting the old days at Atari Corp., it’s occurred to me to note how many things we take for granted in modern operating systems that we just didn’t have back in those days.
For example, I can’t help but think how useful it would have been to have some sort of a system-wide database similar to the registry in Windows. That might have some of you who don’t care much for Windows doing something of a spit take, but when you get down to it, both Linux and Macintosh OS X have similar constructs.
It could have been something relatively simple, like a .INI file, for example. Microsoft Windows got away with a simple setup like that for many years.
The DESKTOP.INF file was arguably an embryonic version of a system registry. This file was used strictly by the desktop to store desktop settings and a few bits of information from the control panel. It could have been used for much, much more, but there was no system API to access it.
How much easier, might it have been, to have all of the information for things like the DESKTOP.INF file, ASSIGN.SYS file, and so forth, all in one place and managed by a common API, rather than in a variety of separate files? And since these files were used to store configuration information even in the early days when they were loaded from floppy disk, I can’t help think that some attempt at making it into a more general purpose system registry would have been a huge advantage.
Not long after I started working there, Atari decided to come out with a new Control Panel which supported the idea of plug-in modules. This way individual applications, utilities, or new system features could have a nice centralized location where users could go to set various options. However, one of the problems we had early on was figuring out a method to allow the modules to retrieve or store their information. We didn’t want them creating individual configuration files everywhere, but what was the alternative? It was finally decided to have them write any info they wanted to persist between sessions into the data segment of their own executable file.
I know, I know. But this was 1990-1991 or so and it seemed like a good idea at the time. But imagine how much easier that situation would have been if we had a system-wide registry.
As goofy as that may sound, the way that programs had to read Control Panel information at run time was arguably even goofier. In order to make it accessible to applications, TSR programs and Control Panel modules could store information in a little block of memory which we called a cookie (no relation to modern web browser cookies, though the concept is arguably similar).
To find the cookie information that was available, a program would access a predefined memory location to get a pointer to the start of the cookie list. Then it would simply walk the link list of cookie blocks to find all of the information available.
This was 20 years ago, remember?
The cookie idea worked, but it was kind of a kludge and programs had to do a lot of work to support it. They were expected to be able to do things like allocate new memory for cookies as needed and link that into the existing list. The bottom line is that it was overly difficult to maintain, especially considering there really should just have been a couple of API calls to handle the whole mess. A system-wide registry would have been able to easily manage something like this.
Oh well, you know what they say about hindsight.