Some of my friends suggested that it might be interesting for me to tell you the story of Bbuuzzb and how it came to be. In case you do not know, Bbuuzzb is the Future Lab GPL database engine.
In the early part of 1995, my good friend Chris and I were discussing database engines and came to the conclusion that the world needed yet another database engine :-). We agreed that current database engines were too bloated and were also too restrictive. Chris and I have many years of experience with databases and especially admire the following database characteristics:
Chris and I agreed that it would be nice to have a compact database engine that had all the features mentioned above. I told Chris that I would embark on creating this engine.
The initial versions of the engine were build to run under native DOS using the Turbo C/C++ V3.0 compiler. I coded the engine in C to remain compact, portable and fast.
By the end of 1996, I had a feature rich, fairly stable version of engine. Or so I thought.
In the beginning of 1997, I decided I would like to create a client/server version of the database and having already worked with and admired QNX, I decided to port the engine to QNX.
As soon as I began to compile and run the engine under QNX, it became quite clear that the foundation of the engine was unstable because as I added more features, the engine began to crumble. I had experienced this before where a DOS application would compile and run properly but when moved to a Unix OS, the application would become unstable. The reality is that Unix is a protected OS that does not allow the application to misbehave. DOS, on the other hand, has no protection whatsoever. QNX, in particular, is very protective and does not allow any monkey business from applications.
For about a year, I went through the cycle of adding new features which would cause the engine to become unstable. I would then hunt for these new bugs, swat them, and the cycle continued. I still had the impression that some parts of the foundation had problems but I could not put my finger on anything in particular. This is very typical of memory allocation bugs. Very frustrating!
In 1998, I hit upon the idea of a validation suite. A program that would randomly pick a database operation code and execute it. This seemed a good way of making sure that the engine was stable and was doing what it should be. This is how the dbstress application was created.
As the development continued, I wanted a way to create client/server versions of the engine and applications for other platforms but I did not know how to do this. The only client/server version I had at that point was the QNX version which uses QNX message passing as its IPC (interprocess communication method).
As luck would happen, in March of 1998, I started a new job for a company that is involved in building software for about 20 different platforms. This gave me an excellent opportunity to learn about other IPC's. This company uses TCP sockets, RPC and XDR to communicate from one machine to another, no matter what the platform.
I spent months researching TCP sockets and finally figured out how they work and how RPC and XDR factor into this. I decided that I would use TCP sockets for interprocess communication but that I would not use RPC or XDR for the following reasons:
I then went about porting the QNX code to Windows 32bit using WinSock. I soon ran into the problem that WinSock is not really the same as the Berkeley socket under Unix which is the model I was studying. By late 1998, I had the Bbuuzzb engine, server and applications running under Windows 32bit using WinSock.
In early 1999, I then ported the Windows code to HP-UX. I wanted to port first to Linux but did not have Linux running and lacked enough hardware to get this going. It was, at this point, that I ran into the most difficulty with sockets trying to make my Bbuuzzb client/server API's multiplatform so that one code set can be used for all platforms that use sockets.
Within a couple of months, I had everything functioning under HP-UX. At this point, I bought an old Pentium 166 and turned this into my Linux machine. I choose Red Hat because of RPM (Red Hat package manager) and the idea that, some day, I would develop Red Hat packages.
Once the Linux machine was installed and configured and I had worked out the name resolution issues, ported the Bbuuzzb code to Red Hat Linux in July 1999.
The last item I should explain is the name. During most of its life Bbuuzzb was simply referred to as dbeng which stands simply for database engine. When you look through the C code, you will still find plenty of references to dbeng. As I was getting closer to packaging the GPL software, Chris asked me what name I was going to use for the database. He suggested DickBase as an obvious pun on my name (and other things :-). I liked the name but thought it had, shall we say, other overtones. I thought of the custom license plate that I have which is bbuuzz referring to a nick name of mine. I took this and added the b onto the end to indicate base. Pretty stupid huh! I now have one or two interesting names that I can use but I will leave it this way as a reminder of what happens when you are in a hurry.