It’s so long back I almost forgot it myself. Three days and 20 years ago, the 26th of November 1986, Gekko Software was founded. Coming from a biological background (hence the Gekko) I started my adventures in the world of professional software with an Olivetti M24 (known as the AT&T 6300 in the US) a copy of Turbo Pascal 2.0 and a copy of dBase III 1.0. Turbo, more specifically its creator Anders, has been the main theme over all the years. Had it included standardized database support from the start (it took Delphi to reach that point) all my sidesteps into dBase, Clipper and Access would not have been necessary.
When it comes to databases a standardization (from the code’s point of view) has been pushed away in xml-datasets or whatever other object you can map them into. But not all data my customers work with is fit for databases. A lot of projects include the generation of documents. When you’re lucky your reporting tool will generate the document. These days a lot of them offer out of the box exports to most popular (Office) applications. When the specifications of the document get really nitty-gritty you’re back to good old coding by hand.
20 years ago I had a book File formats for popular PC software. It described every byte of a document file. It took a lot of tedious programming but you could create very detailed documents that way. But the moment the consuming application had a new version it usually took a lot of work to get your output comprehensible again. A big step forward was OLE automation in MS office which hid the document format behind a giant object model which you could program against. It worked but had its drawbacks. One of them was performance. When programming against the user’s Word processor takes crossing a process boundary on every call. Given the hardware of those day (Pentium I with 8mb) generating a document from code was not much faster than typing it in by hand. Advances in speed are not the prime benefit of IT, but having to wait all afternoon for your documents was too long.
You can automate an Office application in-process and forget about the UI. An interesting scenario became generating documents on a document server. This still had drawbacks. You had to install Office on the server; which could be done but needed a lot of explanation to the IT staff. What’s worse is that an Office application expects an UI. Which will hit hard on you when the document generation process hits an exception. The exception pops up on the server screen. The server itself is locked in a closet; nobody notices the dialog and the whole thing hangs.
These days generating documents from code is more interesting than ever. A very promising direction is the new document formats for (open) Office. Basically they are compressed XML documents. The internals of the document format are no longer hidden behind an api but instead they are published in an XSD. Which could mean you no longer need an Office application to create the document, all you need is the schema and you can code away. In real life it’s more complicated than that. My neighbor, fellow blogger, has dived into the details and published an open source library on sourceforge. It’s dazzling!
So the story doesn’t stop here. I’m looking forward to another 20 years. But after that it will be enough, time for retirement. Which I will enjoy with open XML everywhere in everything.