Remember the titans – 2

I was looking for information about Eli Boling and found no info about his whereabouts in regard to Remember the titans, but I have found interesting location on Borland Web-site by Danny Thorpe – this is not a blog, but something similar about projects Danny has been working on during his presence at Borland. I am going to quote it here since I suspect it might disappear after information published 😉 Last record is 2001 where page has been abandoned by the author.

Danny Thorpe, Staff Engineer, Delphi R&D, Borland Software Corporation  

These are the products and internal projects I’ve worked on over the past few years. Historical dates subject to change without notice.

Delphi 6 – May 2001
Most D6 compiler and RTL enhancements were a result of the Kylix efforts. Fortunately, Windows doesn’t inflict PIC codegen on us, but D6 benefited from the new internal assembler, language and directive enhancements introduced in Kylix, and new platform neutrality functions and constants carried over from the Kylix RTL. Function overload resolution got a little bit smarter, so WideString and AnsiString parameters in different function overloads were no longer considered ambiguous.

Kylix – January 2001
Kylix – the first component-based Rapid Application Development environment for the Linux operating system. It’s Delphi for Linux!

I was a founding member of the Kylix Project, with Chuck, Eli, and Allen.

In mid 1999 CEO Dale Fuller said “Take us to Linux” and away we went to grok this “new” platform called Linux, to chart its waters and bring the Delphi ship to its commercially virgin shores.

My involvement with the compiler prior to Kylix had mostly been ad-hoc spelunking to fix some particular bug or issue, or occasionally implement a new feature in a very well defined area. As the Kylix project progressed, I seemed to collect compiler responsibilities like a snowball rolling down Everest.

Markus Armbruster, a classical Unix guru in every sense, kick started the project by passing on a lot of between-the-lines expertise to the team and implementing a prototype linker to emit Linux ELF executables. Markus also designed and implemented resource linking for Linux ELF executables. (There is no standard defined for embedding replaceable resources in Linux. For Kylix, we wanted a single exe solution for simple application deployment. That meant inventing a way to use standard ELF file sections to store resource data, and in a way that the data could be removed and replaced without needing to relink the program.)

Eli Boling was the technical lead for the Kylix compiler stuff, even though he was fully tasked working on another Borland project at the time. Eli implemented Kylix’s IP relative exception info from scratch (there is no language independent exception handling standard in Linux as there is in Windows) and pulled me out of the drink on the many occasions I found myself in way over my head.

Chuck ported the compiler source to compile with Gnu (not as simple as it sounds) and architected a new inline assembler (CHASM) written in portable code. The old BASM inline assembler was monolithic assembler code with no hope of being ported or enhanced. I later fleshed out the rest of the x86 instruction set and addressing modes in CHASM and then (on a roll!) added Pentium III, Pentium 4, MMX and SIMD instruction support. (CHASM is that good). I took over the linker work from Markus and (eventually) implemented linker support for emitting ELF shared libraries and Delphi packages.

By the time the linker was fit enough to emit shared libraries, it was clear that the codegen still wasn’t right for PIC, so I went off to figure out a way to make the code generator understand GOT relative addressing. Which means, I had to go off and figure out what GOT relative addressing really meant, and follow that up with an expedition to figure out how the compiler represents addressing modes internally.

Many thanks to Tagawa-san who fixed the many “register pressure” side effects caused by PIC consuming one of the precious x86 general registers. PIC (Position Independent Code) is really designed for IP relative addressing (referring to a code address as a distance relative to the current instruction pointer), but the Intel x86 instruction set doesn’t provide IP relative addressing modes. There were days when I could have sworn the designers of ELF’s PIC standard must have had ‘make Intel look bad’ as one of their design objectives.

Allen kept me well fed with PIC and ELF related linker issues as a result of his work to get the IDE to load packages dynamically (and survive). I think Allen ended up spending more time debugging the Linux program loader (and implementing fixes submitted to the Linux source maintainers) than debugging the IDE! While the ELF spec was designed to support dynamic loading of shared libraries, the Linux program loader (ld) had a number of issues prior to the glib 3.0 release, particularly in the area of recursive loading at program startup. Doing anything at program startup is difficult in C code, so that area of the loader simply wasn’t well exercised by traditional C programs in Linux. “Clearing out the cobwebs” was a popular curse muttered by the Kylix team.

In the middle of all that, I also ported the Delphi Runtime Library (RTL) to the Linux environment, using glibc as much as possible (no direct kernel calls).

As the Kylix Project dragged on, observers would occasionally express concern at the inordinant amount of time Kylix seemed to be taking. “Delphi releases only take a year or so to crank out. Why is Kylix taking so much longer?”

One word: Infrastructure. To implement the full Delphi development experience in Linux, we had to implement more than just the development tool itself – we had to implement infrastructure that we took for granted on Windows which wasn’t provided by Linux. Embedded, replacable resources. Exception propogation between modules. Nonambiguous external function references.

It’s a credit to Linux’s flexibility and openness that we were able to do all this, to implement the infrastructure that the Delphi development environment needed as a base, and to do it on Linux terms using Linux standard APIs and file formats.

If there’s something you can’t get from the Windows program loader, you give up and look for something else to do. If there’s something you can’t get from the Linux program loader, you complain about it bitterly on several public forums, then you go off and figure out either how to make the loader give you what you want, or learn from the loader sources how to get the information you need through other means.

The Linux community can be myopic and vicious, but the Linux platform is still pretty cool despite their best efforts.

Title upgrade to Staff Engineer. Twice the product in half the time. Whee.
Stone Hammers
Our task was to create the Delphi RAD development experience on the Linux platform. That meant using the traditional Linux development tools (gcc and gdb) to construct a subset of the Delphi tools, then use that subset to construct a larger subset, and so forth until the full development toolset of syntax highlighting code editor, GUI form designer and GUI debugger was up to Delphi customer expectations.

If you’ve ever used a GUI debugger to surf around inside a running program, switching to Linux’s command-line text debugger, gdb, is quite a culture shock.

On one particularly frustrating “bad Linux” day, Dale Fuller popped his head into my office and gave a cheery “How’s my Kylix doing?”

I spun around and vented: “This is going to take forever. It’s like building the Concorde with stone hammers!”

Delphi 5 – August 1999
Threading work in RTL and VCL: threadsafe strings, threadsafe VCL component streaming, better support for multiprocessor threading. IDE form designer: enable & support Eddie Churchill’s work for the new treeview/diagram view data module designer. Miscellaneous work spelunking around inside the compiler. Umm, what else? I can’t remember.

Delphi 4 – July 1998
Senior R&D Engineer. Implemented DBGrid support for new ADT database fields. ADT support driven by new Oracle 8 server release. ADT support also added to Midas and ClientDatasets. Delphi 4 provided better support for Oracle 8 ADTs than any other development tool for Windows… including Oracle’s own tools!

Delphi J-code – Fall 1997
This was a research project to explore the feasibility of compiling Delphi source code into a different machine code format – Java byte code. This was not about translating Delphi source to Java source, but about viewing the Java realm as two distinct entities: the Java source code language, and the Java Virtual Machine. Delphi J-code was going for the machine, not the language. Much later, Microsoft’s J++ would do exactly the opposite: J++ went after Java the language, ignoring or undermining the Java Virtual Machine.

I worked on implementing the core RTL (System.pas and SysUtils.pas), compiler “magic” functions, and compiler-RTL glue code. Oh ya, and a Java implementation of the Win32 variant semantics. Yowza.

This research project was demonstrated at a technology briefing at BorCon98. From the feedback at that conference, it became clear that expectations for the product concept ran much higher than we could afford to invest in the project. The market wanted more than just a command line Delphi compiler that emitted Java byte code. The project was shelved in favor of devoting R&D resources into more promising and lucrative endeavors.

Delphi 3 – May 1997
Right after Delphi 2 shipped, while the development team was out on vacation, I discovered Win32’s DIBSection architecture, and reimplemented TBitmap to use DIBSections instead of device bitmaps. This move was not without costs, but this put to rest once and for all the nasty problem of bitmap images changing format across read-modify-write cycles. Device bitmaps are always in the pixel format of the current video mode. If you load a 24 bit BMP file on a machine running 8 bits per pixel (256 color) video, modify the bitmap, and then write it back to the BMP file, the output will be 8 bits per pixel with significant color loss compared to the original. DIBSections allow you to operate on bitmap data independently of the current video mode pixel format.

There. I’m off my Delphi 3 soapbox now. Oh ya, we also implemented support for creating ActiveX controls in Delphi 3. <shudder>

Delphi 2 – March 1996
After 5 years of developing new ways to break the product, I changed jobs from Senior Quality Assurance (QA) engineer to R&D Engineer in late 1995. First tasks: port Graphics, Grids and DBGrids to Win32.

Delphi 1 – February 14, 1995
Senior QA Engineer. Wrote language and RTL test suites for new Delphi language syntax, exceptions, classes, long strings, etc. Ported Zombie architecture to Win32 using OLE Automation for interprocess marshalling and application probing, in preparation for Delphi 2

Zombie – circa 1994
Designed (with Ramin Halviati) and implemented the (patented) “Zombie” internal testing architecture.

FullTilt! Pinball – August – September 1994
Moonlighting as a contractor for Cinematronics, I designed and implemented the pinball game’s component model and collision physics with Dave Stafford and Mike Sandige. Cinematronics licensed an early version of the pinball engine to Microsoft for the Win95 Plus! Pack’s “Space Cadet” pinball game. Cinematronics was later acquired by Maxis, who published FullTilt! Pinball in 1996 and a sequel in 1998.

The pinball object model and collision physics code were originally implemented in Delphi. (yes, pre-Delphi 1.0) When Microsoft got the hots to license the game engine for the Win95 Plus! Pack, I had little choice but to translate the Delphi code to C/C++ before turning the source code over to them. I don’t know when Microsoft became aware of the Delphi project at Borland, but I certainly wasn’t going to hand it to them on a silver platter.

Considering the great span of time between the principal coding and the retail release, I don’t know how much of my original code survives in the retail release of FullTilt! Pinball. Cinematronics paid me for my time, but that wasn’t really why I opted to work a month’s worth of 9pm to 3am nights, after my 10am to 7pm Borland days. I learned a great deal of codesmithing and performance wisdom from Dave and Mike, and took great delight in inflicting OOP and Windowsisms on poor Mike. ;> It wasn’t a job – it was an adventure!

BTSLite – Fall 1993
Designed and implemented, with Mark Edington, the first Delphi VCL production application and the first Delphi database application: BTSLite. UI prototyping started on an informal basis late October 1993, using a Paradox Engine based database layer that Mark Edington was writing. BTSLite went online six weeks later in early December, 1993. Note that this was six months before the Delphi product had a database architecture! BTSLite was later converted over to using the Delphi database classes and BDE to further test the database architecture prior to Delphi 1.0 release.

After a trial period of a few weeks, the Delphi development team adopted BTSLite as its defacto bug tracking system. Within 18 months, most other development groups within Borland had adopted BTSLite. BTS has been through many revisions since those early days: transformation into a Delphi Midas thin-client app running against a Delphi Midas server with an Interbase SQL back-end by Josh Dahlby, WebBTS client and middle tier server work by Steve Trefethen. Steve also implemented a dynamically loadable package system for BTS (with some design input from me), so that BTS users can load only the functionality they use (engineers typically eject the reporting and project charting modules). BTS is still the most widely used bug tracking system within Borland.

Why was it called BTS”Lite?” The first implementation of a Windows GUI bug tracking system (BTS) was built by Mark using Paradox for Windows. The objective was to implement the feature set and responsiveness of the old Paradox Dos BTS application (also written by Mark). The performance of the PdoxWin BTS on queries and even UI refresh was, um, “suboptimal”, to the extreme that Delphi R&D just plain refused to use it. The Delphi BTS app implemented a subset of the functionality of the PdoxWin version, and ran what seemed like 100 times faster than the Paradox implementation. The Paradox for Windows team believed the bottleneck was down inside the BDE somewhere. Delphi demonstrated that BDE wasn’t the bottleneck. BTSLite got the “lite” label because it was a functional subset of the original BTS, and also faster. After deployment of BTSLite, the Paradox for Windows BTS system was fondly referred to as “BTSHeavy”.

Turbo Pascal for Windows 1.5 – Spring 1993
Point release of TPW to synchronize with the release of Windows 3.1

Borland Pascal 7.0 – November 1992
BP7 was the pinnacle of Dos development tools. Everyone on the Pascal development team was intensely proud of the BP7 release, for its unprecedented feature set, quality level, and completeness as a development environment. Though never spoken, I think everyone on the team realized that this would be the last release of the Dos tools line. Dos was out, Windows was in. If there had to be a conclusion to the long history of Turbo Pascal products for Dos development, BP7 was the ideal grand finale. Salut!

Turbo Pascal for Windows – Fall 1991(?)
Turbo Pascal’s first major paradigm shift. Painful lessons learned in the development of OWL and the TPW IDE would shape the design of the future Delphi project.

Turbo Pascal 6.0 – November 1990
My first Borland product. Hired straight out of college by Pascal QA manager Eberhard Waiblinger, Borland dunked me head first into the school of total immersion OOP, Software Quality Assessment / Quality Assurance, risk metrics, and commercial software development processes.

How confident and ready-for-anything I must have seemed at the job interview (In my dressed-to-kill new suit. Thanks, Mom!). After all, I had been programming professionally for five years for a state agency while in high school and college! In only a matter of weeks I would discover just how vast my ignorance could be. “Great googleymoogley, these guys are the pros! There’s Anders somethingberg, who builds compilers with his bare hands! And Chuck somethingski, who juggles objects and polymorphs like an air traffic controller!”

The fun part about programming, and working at Borland, is that you never really shake that feeling of virtual vertigo. The more you learn, the more you discover you don’t know.