Previous month:
January 2020
Next month:
March 2020

Launching Delphi - Feb 14, 1995

Booth Delphi 1.0 launch Feb 1995It was twenty-five years ago today that Anders Hejlsberg and I got up on stage at the Software Development '95 conference and launched Delphi to the world. The joke was that all 1,500 of us were geeks who couldn't get a date even on Valentine's day. 

We knew Delphi was a good product. Maybe even a great one. Our beta testers loved it, the team was excited and we had a 32-bit version in the works for the upcoming Windows 95 OS that would be bigger, better and faster. But the scale of Delphi's success took us by surprise. The Borland booth was mobbed at the conference. Delphi, with the help of DavidI and Charlie Calvert, gave birth to an ecosystem of third party books, magazines, component libraries and more. I've met countless developers over the years who told me Delphi enabled them to learn Windows development, build their career, their business.

Anders Delphi 1.0 launch Feb 1995So what made Delphi so good? You gotta give credit to Anders. He is probably one of the ten best programmers in the world and certainly the best developer I've ever worked with. He had more than ten years of compiler experience under his belt when we built Delphi. He knew exactly what tradeoffs mattered in language design to balance programmer productivity with machine performance. Delphi compiled to machine code at the speed of 35,000 lines per minute on a 90 mhz pentium. I have no idea how fast that is on today's machine. But you could load a demo program, hit the run button and by the time you clapped your hands together it was running. And I clapped my hands together ever time I gave a demo, just to make the point. 

As Anders pointed out that night on stage, Delphi was written in Delphi. So the team that built Delphi (and it really was a team: Anders, Gary, Chuck, Dave, Allen, Hank, Ray, Marc, Danny, Charlie) used it every single day. We made it great because Delphi was the tool that we wanted to use. It was pretty mind-blowing when Anders loaded the Delphi project source code into Delphi and compiled itself. 

The Delphi project was not an easy one though. It came at a tough time in Borland's history. The company was sued by Lotus in 1990, acquired Ashton Tate in 1991. By 1993, the company essentially sold off Quattro Pro and Paradox to Novell after Microsoft decimated the standalone spreadsheet and end-user database market. Oh yeah, and the founder and CEO, Philippe Kahn left to create Starfish Software a month before we launched. Philippe helped protect Delphi as a skunkworks project when we started and he coined the codename VBK (ahem) which none of us liked, but all of us believed in. 

We knew if Borland was to stay relevant in developer tools, we needed to build something better than Visual Basic. We never saw Delphi as VB Killer, but certainly a VB Kompetitor. How would we compete with that behemoth? Well, we weren't cocky, but we also weren't afraid of Microsoft. We had to make Windows programming easy enough that a DOS programmer could do it. And in that regard, our prior efforts with Turbo Pascal 7, missed the mark. Borland had a couple of other internal efforts that never saw light of day (Monet, anyone?) and at some point, Gary, Anders and I came to the realization, someone had to make it happen, and that someone was us. Having a native code compiler meant that Delphi would have a huge performance advantage over interpreters. It also meant Delphi developers would be able to create their own reusable objects without having to learn a different language. That gave us huge extensibility. 

We also learned there was another change on the horizon and that became our opportunity. Borland VP Rob Dickerson had highlighted the need for the company to build a client/server development system. Again, we looked around and we realized Paradox wasn't going to do it, dBase wasn't good enough, C++ was too hard. And so I put up my hand and convinced Gary and Anders not only did we need to make Windows development easy, we had to take on Client/Server development at the same time. Luckily they agreed, not knowing what Client/Server development meant. I didn't either, but I trusted we would figure it out. Ultimately this became our biggest differentiator in the market. While our performance over VB could be 2-3x faster, compared to SQL Windows or PowerBuilder, Delphi was 5-50x faster, and sometimes 800x faster. 

When we first started, we thought the project might take a year, but that Client/Server stuff was a lot harder than we expected. One of the developers working on that area eventually left the company and when Chuck and Anders looked at his code they just about barfed. That cost us about six months. I'm pretty sure every single person working on the project came to see me and said: "Can't we forget that Client/Server thing and just ship the desktop Windows version?" But my answer was always the same. I drew a curve of what Delphi desktop revenues would be. Then I drew a second line for Client/Server below the first one but growing at a steeper angle, eventually eclipsing the desktop revenues. I don't know if anyone believed me (and I honestly didn't know if I believed it myself) but it put an end to the discussion.  

Zack Delphi 1.0 launch Feb 1995I knew that the Client/Server product was more important strategically for the company because it would expand our market beyond Borland's traditional base. Ironically, at some point my boss VP Paul Gross asked why we were working on the desktop product, suggesting we skip that completely. I told him Delphi desktop revenues would be $30 million in the first year (a number I made up on the spot) and he nodded and said "good point."  

Delphi's first year revenues were $70 million (far higher than we'd expected) and grew from there. That's about $118 million, adjusted for inflation. And the Client/Server revenues really did eclipse the desktop revenues in the second year. To say Delphi saved Borland was not an overstatement. 

We also made a good bet on shipping a 16-bit version of Delphi first, rather than jumping straight to 32-bit. It was a safe assumption that Microsoft would slip Chicago (Windows 95). So we had a stable 16-bit compiler and operating system and could work on that without having to worry about the ground moving beneath our feet. We were fortunate to get the 32-bit compiler under development in parallel, shipping it just about 12 months later as Windows 95 was gaining market share. Delphi 2.0 boosted performance another 3-4x giving us an even bigger lead.

When we built Delphi we never thought it would last so long or have as much impact as it did. We were grateful for the support and feedback from our customers and third party developers. While we weren't obsessed with press coverage and awards, we were happy that it helped get the word out. I still have the Jolt Cola award on my bookcase. I figured if Delphi lasted to version 3.0, that meant we did a good job. But twenty-five years? Who could have guessed?

Looking back on Delphi 1.0, much of those two years is a blur of sixty hour weeks, late evenings and occasional setbacks. But the memories that stand out were about the team. We were committed to building something great, something that we would use. Gary and Anders (and Chuck, and Danny...) all had great taste. So there was a kind of aesthetic to the product. It's hard to explain, but we knew it as "it works the way you hope it would." Delphi wasn't just fast, it avoided the limitations of many Rapid Application Development (RAD) tools that ran out of gas when you pushed hard. 

I've done a lot of interesting things in the last twenty-five years, but Delphi is the product I'm most proud of. It was a magical time in our lives when we were experienced enough to do good work and young and foolish enough to bite off more than we could chew. We solved some hard problems that mattered in a market that we understood and the market responded. It shaped my thinking about how to build products in ways that I continue to use and teach to this day.

I'm grateful to Anders and Gary that we took on the project. Gary is the best engineering manager I have ever worked with and I was glad to get to work with him again at MySQL. Anders, of course, has gone on to do even greater things architecting C#, .Net and TypeScript. I'm proud of the many developers, writers, and testers, product managers and marketers (Lance, Diane, Ben, you were awesome), who built on the early success of Delphi 1.0 to create a legacy that has withstood the test of time.

And thank God we finally got that darned Language Reference Manual out. 

Zack gary anders 2011

Got a recollection of Delphi 1.0 or a story about Anders, Gary or me? Post a comment below...

Delphi Informant: Giving Birth

This article appeared in Delphi Informant magazine in April 1996 discussing the development of Delphi 1.0.

Zack Delphi 1.0 launch Feb 1995One of the most fun things I’ve done in my career is to help build the “1.0” version of Delphi. Okay, 2.0 was pretty fun too, but, as they say, there’s nothing quite like the first time.

When we started building Delphi 1.0, it was hard slogging. A lot of the tools out there, like PowerBuilder, SQL Windows, and Visual Basic were pretty good. Long before we even had a prototype up and running, I was on the road talking to developers to understand the problems they were facing. Most of them were pretty happy. I remember particularly thinking that the VB corporate users by and large were just the happiest bunch of developers I’d ever met. Heck, they were even having fun! I remember one particular meeting with about a dozen developers from a major airline. They told a not uncommon story of how a senior VP had decreed that they would use Visual Basic after he prototyped an application on a weekend. The developer told me that he didn’t want to have any association with — ugh — Basic, but after trying it out for a while, he changed his mind.

Another time, I was meeting with a development team at a Wall Street foreign exchange. They showed me this tremendously impressive application for monitoring currencies — written in SQL Windows. It was beautiful. I thought, “Oh no, another satisfied customer. Time to move on.” So after a demonstration I asked how they liked the application. His answer: “It’s a dog.” The response time was simply too long to even be considered for production use. After all, Wall Street practically defines the phrase “Time is money.”

I saw these scenarios repeated in meeting after meeting, city after city. On the surface, customers seemed pleased with the productivity gains of “Rapid Application Development” tools. But as I delved further, I found the love affair often came to a bitter end when they tried to move from prototype to production. I found lots of spaghetti code out there, and DLLs written in C to make up for performance bottlenecks in applications written in PowerBuilder, SQL Windows, and VB.

It was some nine months into the two years of the development of Delphi 1.0 before we showed it to potential customers. There were two reasons for that. First of all, Delphi was an underground project that was truly secret. Heck, for the first year we had more code names than beta testers! Secondly, and perhaps more importantly, I wanted to make sure we understood customers problems rather than simply gauging a reaction to a demonstration. That way we could ensure we were building the right product, rather than fine tuning the wrong one.

When we finally started showing Delphi to customers, the reaction was dramatic. After all, we were solving the problems they had told us about. Our mantra: “Performance, Reuse, RAD, and Scalability.” This helped us to not only define the product, but to communicate the benefits to the customer.

Oddly enough, one of the problems we faced was how to name the product. As Jerry Coffey pointed out in this column [“Symposium,” Delphi Informant, January 1996], we were experimenting with all kinds of names. Although we had early on decided that “Pascal” should not be included in the name since it wasn’t really meaningful except to long-time fans, we really hadn’t made much progress on the name until a few months before its release.

Leading contenders included “Visual AppBuilder” (luckily, it was taken) “Application Architect” (too much like a CASE tool), “Client Builder” (sounds like a sales prospecting package), “Object Vision” (ahh, we used that already, didn’t we?) and just about every combination of the words “Visual”, “Power”, “SQL”, “Application”, “Object”, and “Builder” (“Visual Power SQL Application Object Builder” anyone?)

As we were in the late stages of selecting a name, whenever I’d do a presentation, whether to potential customers, sales reps, or third party vendors, I’d always ask them what they thought of the proposed names like “AppBuilder.” Invariably, the response was lukewarm. Then they’d ask, “Why don’t you just call it Delphi?” So in the end, we did.

Danny Thorpe, then on the QA team, now currently part of the R&D group, had came up with the original code name “Delphi” since it was to be a client/server tool connecting to the likes of Oracle among others. We had to come up with a code name for our first beta test and everyone felt that Delphi was acceptable. We had many later code names for internal use, external use, different countries, and at one point, I must admit, I randomly made up a new code name for every presentation, so that if there ever was a leak, we’d know from where it came.

Delphi 2.0 has come a long way since then. Our original goal was to address a few of the usability issues and also migrate to a 32-bit compiler and take advantage of platform features like OLE automation, OCXes, etc. Along the way, we introduced several major innovations like Data Module Objects and Visual Form Inheritance that increased code reuse.

The 32-bit compiler itself was actually started way back when the original 16-bit version of Delphi was started. At the time it seemed like a safe bet that “Chicago” (Windows 95) would slip out of 1994 and that Windows 3.1 would still be a viable development platform for Delphi 1.0. We were able to have most of the VCL ported to 32-bits and running with the new compiler prior to the release of Delphi 1.0. So we were quite confident that the architecture would ensure compatibility with most code from Delphi 1.0, assuming it wasn’t dependent on 16-bit data assembler, data structures, or unsupported API functions.

Although it’s a bit too early to announce plans for the next version of Delphi, we’re certainly working on a number of fronts to further reduce the amount of code folks need to write, and make it easier to support very large projects.

Zack Urlocker is Director of Delphi Product Management at Borland International. The views expressed here are his own. He can be reached on CompuServe at 76217,1053.
(Well not anymore!)

Danny Thorpe: Why The Name "Delphi?"

by Danny Thorpe

This article originally appeared on the Borland museum website. 

Danny thorpe"Delphi" started out as a beta codename for a closely guarded skunkworks project at Borland: a next-generation visual development environment for Windows based on Borland's Object Pascal programming language. The codename hatched in mid 1993, after the development team had been through about 6 months of deep research, proof-of-concept exercises, and market analysis. Members of the then Pascal development team were hanging around R&D Manager Gary Whizin's office brainstorming clever codenames to use for the new product. It was not a large office, but it was not a large team either - about 10 people between R&D, QA, Pubs, and Marketing. It would have been odd not to see Anders Heilsberg, Chuck Jazdzewski, Allen Bauer, Zack Urlocker, Richard Nelson, myself, and several other regulars jawing away on some topic or another in Gary's office. For the codename jam sessions, there may have been some overflow into the hallway.

Borland has a long history of "unusual" codenames, some with catchy slogans or backgrounds that tie the odd name to the market or product focus. A codename should have no obvious connection to the product, so that if an eavesdropper overhears the name in conversation it won't be too obvious what product is being discussed. The difference between an everyday disposable codename a great codename is the pithy passphrase behind it. The most memorable for me was the codename for Quattro Pro 4.0: "Budda". Why? It was to assume the Lotus position!

So we were sitting in Gary's office, kicking around weird and wacky codename possibilities. The strategic decision to make database tools and connectivity a central part of the new Pascal product had been made only a few days before, so Gary was keen on having a codename that played up the new database focus of the proposed product, and of its development team. The database shift was no small matter - I remember having grave reservations about "polluting" the Pascal tools with database arcana that took me almost a year to shake off. It was a big gamble for Borland, but it was very carefully measured, planned, and implemented. In hindsight, making Delphi a database product was exactly what was needed to break Borland's Pascal tools out of the Visual Basic - C++ market squeeze play and set Delphi head and shoulders above traditional Windows development tools.
Gary kept coming back to the codename "Oracle", referring to SQL connectivity to Oracle servers. "Oracle" didn't fly with the group, though. Aside from the obvious confusion with the same-name company and server product, the name itself implied server stuff, whereas the product we were building was (at that time) a client building tool, a way to talk to Oracle and other servers.

How do you talk to an oracle? "The Oracle at Delphi" was the word association that popped into my head. So I offered up "Delphi": If you want to talk to [the] Oracle, go to Delphi.
The suggestion wasn't an instant hit. It's an old name, an old place, a pagan temple in the ruins of a dead civilization. Not exactly an inspiring association for a new product! As some press articles later noted, the Delphic Oracle was particularly infamous for giving out cryptic or double-edged answers - not a great association for a data management tool. Asking a question of the oracle was free to all, but having the oracle's answer interpreted and explained (compiled?) cost a pretty drachma. (The marketing guys liked that part)
Overall, though, the "Delphi" codename had a classier ring to it than the sea of spent puns that littered the room. Pascal is a classic programming language, so it just felt fitting somehow to associate a Pascal-based development tool with a classical Greek image. And as Greek mythologies go, the temple at Delphi is one of the least incestuous, murderous, or tragic ancient Greek icons you'll find.

We went through a lot of codenames during the development of that 1.0 product, coining a different codename for each press or corporate briefing of the beta product. This was an effort to limit rumors and allow us to track the source of leaks. The last thing we wanted was for you-know-who to get wind of what we were up to. Through all these disposable codenames, the Delphi codename stuck. Towards the end of the development cycle, marketing started using the Delphi codename across all prepress and corporate briefings, and as the codename for the final beta releases. That got the rumor mills talking to each other, and the tools industry was abuzz with talk about this secret project at Borland codenamed "Delphi". J.D. Hildebrand wrote a whole editorial in Windows Tech Journal about the "Delphi buzz" months before the product was launched. (paraphrased: "I can't tell you what it is, but I can tell you this: Delphi is going to change our lives.")

When it came time to pick a retail product name, the nominations were less than inspiring.. The "functional" name, a name that describes what the product actually does and is therefore much easier to market and sell, would have been AppBuilder. This name actually still appears in some IDE internal class names, such as the class name of the IDE main window. (R&D caved in to the functional name pressures and set about implementing it early) But AppBuilder didn't light up people's imagination. It didn't work well internationally - functional names are only functional in their language of origin.

Thankfully, a few months before Delphi was scheduled for release Novell shipped their own product called Visual AppBuilder. There was much rejoicing in the Borland halls, for at last the "AppBuilder" debate was laid to rest. With the functional name taken out of the running, suggestions started coming from all quarters to use the Delphi codename as the product name.

Delphi wasn't home-free yet. The lead marketing person had legitimate concerns about the extra effort that would be required to build name recognition in the marketplace for an "iconic" (opposite of functional) product name, so he requested a vote of the development team. There was only one vote against (guess who?). Much to our chagrin, someone came to the conclusion that the development team's views were not an accurate representation of the marketplace ("sample error" was the phrase I heard), and pressed for a survey of the beta testers. When that poll didn't produce the result he wanted, the survey was broadened again to include Borland's international subsidiaries, press, market analysts, stock analysts, corporate accounts, software retailers, and probably a few K-Mart shoppers. It became a bit of a comedy: the harder people tried to dismiss "Delphi" for the product name, the more it gained support.

"Delphi" has a classical ring to it. It has a consistent meaning/word association worldwide in all languages. It has no embarrassing vulgar slang meanings in other languages (that I'm aware of). Most of all, the marketing guys had done a marvelous job of building up market anticipation and buzz around the "Delphi" name. The market was primed and ravenous for this thing called "Delphi".

And that, boys and girls, is how the Delphi product got its name.

Danny Thorpe  joined Borland in 1990 around the same time I did. He worked on the QA Team for Turbo Pascal and later as part of the original Delphi team. Danny came up with the Delphi name and later worked on key parts of the compiler, VCL library and IDE.   

.EXE Interview with Anders Hejlsberg on Delphi (1995)

To commemorate the 25th anniversary of Delphi on Feb 14, 2002 here is a transcript of an interview with Anders Hejlsberg, Chief Architect of Delphi conducted by .EXE Magazine editor Will Watts from 1995. Anders discusses the design and development of Delphi and the then forthcoming 32 bit version for Windows 95. This was the most detailed technical interview published about Delphi at the time.

Q. How did the idea for Delphi evolve from Turbo/Borland Pascal? At what stage did you decide to add the environment, database support etc?

Delphi andersA. The key idea was to design a tool that combines visual development environment, Client/Server database support, and a native code compiler. Before Delphi, you always had to make a choice. Do I go for the performance of a native code compiler, or the ease of use of a visual development environment? Do I go for a powerful object-oriented language, or a proprietary 4GL Client/Server tool? What programmers really want is all of the above, in one package. That's what we set out to do with Delphi.

What it really boils down to is productivity--we wanted to design a tool that would make developers more productive, all the way from prototype to production code. Other products lure you with visual tools, but once you get halfway through your project, they let you down because of sluggish performance, lack of extensibility, or general stability problems. The competition talks about adding extensibility and improving performance. That's a fundamental difference between their products and ours. Extensibility and performance was on the white-board the first day we started designing Delphi, and it permeates the entire product. For example, if you want to design a new component in Visual Basic, you have to write it in another language, such as C or C++ (or Delphi, for that matter). None of your VB skills can be reused, you have to learn a different language, and you can't easily inherit from any of the built-in components. Delphi, on the other hand, allows you to write new components in Delphi, and you can inherit from any of the built-in ones. That's true extensibility, and it translates into a substantial productivity boost.

Another key aspect of Delphi is its versatility. Other tools tend to focus either on Windows application development or on Client/Server development, and one always trades off the other. Delphi is equally adept at both, as is evident from the kinds of applications our customers are building. They range from shrink-wrap Windows utilities and multi-media games, through desktop database applications, and all the way up to multi-user enterprise-wide Client/Server solutions. The point is that almost any Windows application needs some form of database access, and any database application needs some form of Windows specific programming--to be productive, you need a tool that does both.

Delphi really leverages a lot of very mature database technology from Borland including ReportSmith, the Borland Database Engine, SQL Link native drivers for remove servers and the Local InterBase Server. Just the InterBase server alone is a tremendous technology that gives developers the ability to use full ANSI-92 SQL in their applications so they can begin exploring SQL and client/server development all on their local PC.

Q. You emphasise Delphi's versatility as an advantage, but surely it is also a drawback? If one needs to build a client/server application, PowerBuilder offers better CASE/database management facilities than Delphi.

A. There's an inherent advantage to being versatile. Look at the computer on my desktop. Do I need a dedicated word processor, a PC for my spreadsheets and a terminal with access to my customer records? No, I've got one PC that's versatile enough to do all these things.

A very large American retail chain--one of the largest--just standardized on Delphi over PowerBuilder precisely because their engineers can do 85% of all their work using Delphi versus 60% of their work using PowerBuilder. That saves them enormous amounts of money and complexity, including in ways you may not have considered. As an example, skills and techniques learned writing a small utility are directly applicable to client/server projects. A lot of today's programmers started out by writing those little command-line utilities in the good old days. It's a great way to experiment with and master the use of data structures, object-oriented techniques or learning about the Windows API. Consider, also, how using the same tool for a broad range of applications provides a company with a neat training path: Someone can start writing non-database programs and then gradually move onto projects dealing with valuable corporate data.

There's no end to the components and views you can add to Delphi. The population of programmers who can build components in Delphi is much larger than with any other tool on the market. We're back to the days when one programmer in one room can build and test something that can be used by tens of thousands of other people. Can you imagine what the
availability of specialized component sets will be like in six months? In a year?

I think the entire point of combining a component-based visual development environment with an object-oriented compiler and database technology is to make sure you never run out of gas. That's not a bug--it's a feature.

Q. If you want a quick and dirty hack, surely it makes sense to use Visual Basic, because everybody can use it without having to master a scary, complex language like Pascal. If you are doing multi-media or real time work, why mess around with a system which delivers slightly slower performance, and requires you to hand-translate all the header files for any DLLs you may need, when you could just use C++?

A. As we like to say, "It's not your father's Turbo Pascal any more". We made sure that the Object Pascal code you have to write is as easy as BASIC but without limitations.

We've taken great pains to make sure that when you're interacting with components, the code you write is as simple as possible--but no simpler. Many reviewers have remarked that they thought they were coding in Basic when they first started using Delphi. It's that easy. When they want to do something more interesting and start using the richness of the language, they usually start remembering how much they like Pascal.

In fact, I think you miss an essential advantage of Delphi. Anybody who has used a compiler--especially one that supports good type-checking--knows that a compiler is really a programmer's best friend. When it tells you it's probably not a good idea to take the square root of your Window caption, it's showing you a logic error in your code and saving you time. Is it an advantage that BASIC will perform automatic type conversions in that circumstance instead of giving you an error? I wish my spell checker program could complain about the logic of a paragraph I've written in the same way as our compiler warns you about illogical programming statements. Our 32-bit compiler goes even further and offers you all sorts of hints about problems it detects in your program. This kind of help is invaluable and one of the things that makes programming in Delphi very productive.

Q. What is the secret of Delphi's fast compile/link cycle?

A. Borland has over ten years of experience in building the world's fastest compilers, and we've put that knowledge to good use in Delphi- -it compiles at about 350,000 lines per minute on a 90 Mhz Pentium. A number of factors comtribute to this throughput. Delphi units (code modules) compile to .DCU files, which you can think of as a combination of a C++ precompiled header file and an .OBJ file. (It's funny how the hot topic in the C++ community is pre-compiled header files and incremental linking--Borland's Object Pascal technology has had these features for more than eight years.) Delphi units specify what other units they depend on through USES clauses--sort of like C++ #include's of header files. By analyzing the USES clauses of each unit in a project, the compiler can automatically perform minimal builds with no need for a make file. The net result is that the compiler never compiles more than it has to, and it never compiles the same thing more than once. Finally, the clean syntax of Object Pascal allows for very fast parsing.

Q. Is the compiler engine itself written in Delphi? How much does it differ from the Borland Pascal 7 compiler?

A. The compiler is written in assembly language. It is fully backwards compatible with BP7, and we've added lots of object-oriented extensions such as class references, virtual constructors, and the IS and AS operators. We did a lot of work to enable declaring, registering and filing properties and we generate run-time type information that's used to communicate published property, event and method information to the development environment. You'll see some interesting applications of that capability in our 32-bit release. One very unique enhancement was our use of bound method instance pointers to implement event delegation. They're very efficient and fit nicely into the language. And of course we did a lot of work to add structured exception handling. In addition, there are lots of little niceties that people have requested, such as support for C calling conventions.

Q. Delphi implements objects in a manner similar to Apple's Object Pascal, with all objects allocated on the heap. Previous versions of Turbo/Borland Pascal used a more C++ like approach, with the ability to alocate objects on the stack and statically. Can you explain the reasoning behind this change in approach?

A. It really is a question of features vs. complexity. The philosophy of Delphi's Object Pascal language is to deliver the RIGHT set of language features, as opposed to any language feature ever known to mankind. It's the well known 80/20 rule: You can get 80% of the power for 20% of the complexity, but squeezing out that last 20% of power makes the whole thing five times as complex to program. Mixing static and dynamic allocation of objects is one of those features that fall into the latter group. By implementing a pure reference model we were able to simplify the entire Delphi component library, and do away with a lot of the pointer management that plagues other products. Even though Delphi objects are allocated on the heap, in a typical Delphi application you never have to deal with allocating and freeing them.

Q. I find this answer quite surprising and counter-intuitive. You had already implemented mixed static/dynamic allocation, and therefore presumably cracked the problems involved, so why go to the trouble to revert to the Apple Object Pascal approach which you had initially rejected? Is, say, a stack allocated object, with constructors and destructors automatically called as the thing moves in and out of scope, really more complex than a heap allocated object, where you must make special provision to kill the thing off at the end of its life? I would have thought that the fact that the component library *mostly* frees objects automatically but *sometimes* doesn't would tend to add to rather than reduce the application programmer's burden. Also, the change in model must confuse both existing BP programmers and also migrating C++ users.

A. Again, we didn't revert to anything because we really started with a clean slate. Our class reference model is sufficiently powerful and flexible, so having only one sort of class is actually an advantage. Once you give someone two ways to do the same thing, you have made your product less usable and you have to now help them understand when to use a statically allocated class versus a dynamically allocated one. We're quite happy with the choice we've made. It's simple to understand, efficient, and allows us to add garbage collection in some future release. And, of course, if you've got old code from BP7 that uses old style objects, you can still compile it from within Delphi.

Q. Exception-handling - what were the major influences on your design?

A. We looked at a number of languages and implementations, and were most influenced by C++ and Modula-3. Delphi is like C++ in that exceptions are classes, but more like Modula-3 in terms of the supporting language constructs.

Exceptions are a quiet revolution--they truly simplify the way you write code. For the most part you can write your code as if errors will never occur, instead of spending the bulk of your time trying to determine if an error occurred, and if so, how best to clean up and back out of what you were doing. Delphi's Visual Component Library was designed from the ground up with exception handling built in, and that is a large part of the reason why Delphi and applications written in Delphi are so fault tolerant. One of my favorite demos is a little two-liner that, on the click of a button, assigns NIL to a pointer, and then dereferences the pointer. Each time you click the button, Delphi reports that a General Protection Fault exception has occurred, but because of the built-in exception handling logic, the app keeps running instead of bringing itself down.

Q. I'd like to draw you out a bit to expand the answer above with a few specifics.

A. As in C++, an exception in Delphi is simply a class, which means you can take advantage of the inheritance mechanism to handle whole sets of exceptions easily. For example, Delphi declares the following classes which deal with floating-point exceptions:

 EMathError = class(Exception);
 EInvalidOp = class(EMathError);
 EZeroDivide = class(EMathError);
 EOverflow = class(EMathError);
 EUnderflow = class(EMathError);

As you can see, EMathError is the ancestor of the other exceptions. Here's an example of a TRY..EXCEPT statement that handles floating-point exceptions 

 on EZeroDivide do ...;
 on EMathError do ...;

If the PerformCalculations procedure raises an EZeroDivide exception, it is handled by the first handler. If it raises any other EMathError exception, the second handler takes care of it. Since there is no ELSE clause, no other exceptions are handled--they are instead propagated to an enclosing exception handler.

Q. Delphi's ability to handle GP faults is indeed one of it's neatest tricks. Was it difficult to implement?

A. It wasn't too bad, but it did take some nitfy use of TOOLHELP.DLL which implements the Windows low-level system tools interface. We basically register an interrupt callback function which maps processor faults into Delphi exceptions. The reason that it all works, though, is that VCL was engineered from the ground up to be exception aware. Because
of that, when a GP fault occurs and is mapped into an exception, the operation that was in progress will automatically know how to back out and clean itself up.

Q. Can we expect any other major syntax additions/changes, for example Eiffel style assertions?

A. We're always evaluating new language features, and surely there will be some in the upcoming 32-bit version. I'd rather not get into specifics, but as a rule, we don't really think about language extensions in the abstract. Instead we look at the language as part of a bigger picture (class library, component model, visual environment) that must evolve as a whole to support new technologies and improve ease of use.

Q. Can you give Delphi programmer's any guidance on how best to write applications that will be portable to the 32-bit version of Delphi? The new "Cardinal" data type has arrived almost completely unnoticed. Are there any other issues we should be aware of?

A. Delphi's Visual Component Library was designed with portability in mind. As long as you stay away from in-line assembler, 16-bit pointer atrithmetic, and Windows 3.1 API functions which aren't supported in the Win32 API, your apps should port with little or no modification.

The Cardinal and Smallint types were introduced to facilitate portable code. Of the built-in types, Shortint, Smallint, Longint, Byte, and Word have identical representations in 16- and 32-bit code. The Integer and Cardinal types, on the other hand, represent the most efficient signed and unsigned integer types of the particular platform. In the 16-bit version they are 16-bit entities, and in the 32-bit version they are 32-bit entities. In general, you should use Integer and Cardinal whenever possible, and Shortint, Smallint, Longint, Byte, and Word only when the exact storage representation matters.

Any 64K limitations found in the 16-bit version will disappear in the 32-bit version. For example, the 32-bit version allows you to declare arrays and allocate heap blocks of any size up to 4GB!

Q. What is the current state of the 32-bit version? Will it support 16-bit VBXs, like BC++? Delphi 16-bit code runs somewhat slower than C++ - are you doing anything about this for the 32-bit version?

A. Delphi was written to be portable--we've been working on the 16- and 32-bit versions in parallel since day one. The 32-bit version is in field test now, and it will ship shortly after the commercial release of Windows 95. Yes, there is a foundation of 32-bit VBX support technology available in-house, but our primary focus is OCX controls. That's what the competition is working on, and that's where we see the market going. With respect to better code generation, Delphi-32 generates the same high-quality code as Borland C++ 4.5--in fact, they use the same optimizing back-end code generator.

Q. Are there any plans for Borland produced or badged add-ons for Delphi, in addition to the Visual Solutions Pack?

A. We just released the RAD Pack for Delphi, which includes Turbo Debugger for Windows, Resource Workshop, the Resource Expert, Visual Component Library source code, the--much requested--Language Reference Manual, and Visual Solutions Pack 1.1. We did have some quality problems with the initial release of VSP, but those have been resolved, and we now have a Companion Products group to provide Borland-quality add-ons, such as Notes support for Delphi programmers and other often requested components.

Q. Delphi is a terrific tool for rapidly developing state of the art software, but a number of shareware authors have expressed a wish that executables could be made smaller. Is it technically feasible to create a DLL-based version of VCL? Surely this must be possible since COMPLIB is a DLL which is used by the Delphi design environment?

A. It's something we're looking at, and certainly some of the 16-bit complexities with respect to multiple DLL clients are gone in 32-bit land. At this point I can't really comment on specific solutions, other than to say that we're actively looking at ways to make our executables even smaller.

Q. A long-standing and major criticism of Borland Pascal is the proprietary nature of the object file format. It's appreciated that going to the OBJ file format would be a retrograde step, but why won't Borland at least document the file format? That way, developers can create their own tools such as disassemblers, C to Pascal linkers and so forth. Again, it's understood that the file format changes with each release of the compiler, but documenting the changes with each new version would enable other developers to create conversion tools even if Borland don't want to do this. At the moment, if you don't have the source code, all your units become useless each time the compiler is updated.

A. We're well aware of these issues, and the 32-bit version will address them in a number of ways. What I can tell you at this point is that the 32-bit compiler has an option to produce
.OBJ files, which can be linked with .OBJ files produced by other compilers.

Q. A related issue: the move to Windows has diluted the importance of the OBJ issue, because you can now call DLLs. But the Delphi user has still to translate the (typically) C/C++ headers into Delphi import units, an exercise which is at best tedious and time consuming and, if you happen not to have had C++ experience, quite hard. It's the sort of job best left to a machine. Given that Borland has a lot of C++ parsing expertise lying around on the ground, have there ever been any plans to create such a tool?

A. Well, I'm not sure which C/C++ headers you're talking about.
We've already translated all the Windows and OLE 2 API header files, and corresponding interface units are included with Delphi. But you're right, if you have a 3rd party DLL that was previously only interfaced to C/C++, somebody will have to do the translation. Usually, it's not that bad and I think you'll see an increasing number of vendors providing Delphi interface files for their DLLs. Also, I think you'll see more and more products take advantage of the OLE 2 ITypeLib and ITypeInfo interfaces, and we'll provide a tool that takes that information and produces a Delphi interface unit.

Q. The ability to create a single EXE for redistribution is very attractive, but somewhat spoilt by the need to include the BDE with database applications, even if they only want to access the odd DBF. Any plans to clean this up?

A. We're working with several third parties, including SAX Software, Eschelon Development, Sterling Software, Great Lakes Software, and Shoreline Software. They have, or will soon have, products to help you deploy your Delphi database applications. In addition, we're making a deployment kit available, via CompuServe and Internet.

Q. Also on data access: is it possible to modify/inherit from the data access controls to provide, for example, 'native' access to FoxPro/Clipper databases? If so, are any such products being developed by Borland or Third Parties?

A. I know of several Third Parties working on native access to FoxPro/Clipper as well as B-Trieve. Some of them are in beta at this point. You can contact them for additional information on the DELPHI CompuServe forum or find out about them in the Delphi "Power Tools" catalog.

Just to clarify: Sax, Eschalon, Sterling etc do install/setup tools that work with Delphi and the Borland Database Engine. There are other companies creating components that provide direct access to BTrieve, Fox, and other database formats.

Q. What is Delphi's main niche in the developer tools market? Compared with, say, Visual Basic, PowerBuilder and C++?

A. Delphi is a general purpose Windows RAD (Rapid Application Development) tool. The point is that Delphi is NOT a niche tool. From the onset, we've designed Delphi to be able to take you from prototype to production, be that whether you're targetting a Client/Server environment or just writing a Windows application. I hear our competitors say that you can use their tool for rapid prototyping, and then port your app to C++ for production. But you know, rapid application development isn't really rapid unless you can go from prototype to production, all using the same tool! I also hear how competing products will address performance issues by generating C or C++ source code. This idea of building the application with one tool, and then having it generate C or C++ source files that have to be run through another tool, is ludicrous. How are you expected to debug the final code? Requiring users to find bugs in machine generated C++ code, and understand how that maps to the original 4GL code, just doesn't make sense. We've been shipping development environments with integrated compilers for 12 years--I think the time is gone when programmers would accept anything else.

Q. How have Borland's recent troubles affected Delphi's development and its take-up? Was the absence of a Language Reference Manual in the initial product a consequence of these troubles? (You had to mention the Language Reference Manual?  My mistake, I'm sorry! --Zack)

A. In the two years we were developing Delphi, the company did go through some difficult times. That was all resolved before we shipped. Now the entire company is focused on development tools, we've won the Lotus lawsuit, we've launched Delphi and Delphi Client/Server worldwide, and both products continue to sell well above expectations. In fact, I understand that Gray Matter reports that Delphi is the #1 selling development tool in the UK. The Delphi development team is 100% intact, and focused on Delphi for Windows 95.

We really underestimated the demand for the Language Reference Manual. (You're telling me! --Zack)  It will be included in Delphi for Windows 95. Meanwhile, we've made good by uploading an Adobe Acrobat version to CompuServe and our WWW page, and a printed version is now also available from Borland.

Q. We are all pleased you resisted the opportunity to christen a product Power Visual Turbo Pascal Objects for Windows - but how did it come to be called `Delphi'?

A. We actually tried to call it "Power Visual Turbo Pascal Objects for Windows", but that name was already trademarked :-). One of the senior guys in QA (Danny Thorpe) dreamed up Delphi as a code name quite early on, and everytime we did a market survey of product name candidates, everyone said "well, those are ok, but we really like `Delphi'". So in the end, we kept it.

Q. Which part of Delphi are you most proud of? ... and which part least?

A. The thing I'm the least proud of is probably the initial lack of a Language Reference Manual. But that's taken care of now. (Dammit, I said I was sorry already! --Zack)

What I'm most proud of is the fact that the energy we invested in foundation technologies like extensibility and exception handling enabled us to build Delphi in itself. Can
you imagine VB or PowerBuilder written in themselves? By building Delphi in Delphi, we really got to feel on our own bodies what was right about the product, and what needed fixing. I sometimes hear frustrated users comment "The programmers that wrote this %&##$ thing should be forced to use it themselves!". Well, we did, and we're really proud of the result.

-------- CHRONOLOGY --------

  • 1960 Anders born in Copenhagen, Denmark.
  • 1979 Enrolls at the Danish Engineering Academy. Co-founds PolyData, one of the first Danish microcomputer companies.
  • 1980 Releases his first Pascal compiler--a 12K Pascal subset in ROM for the British NASCOM Z-80 based kit computer. Eventually sells the rights to this product to Lucas Logic.
  • 1982 PolyPascal for CP/M-80 released. Product is now a complete implementation of the Pascal language.
  • 1983 Sells the Borland founders (Niels Alex Jensen, Ole Henriksen, Mogens Glad, and Philippe Kahn) on the idea of a Pascal compiler with an integrated editor. In November releases Turbo Pascal 1.0 for CP/M-80, CP/M-86, and MS-DOS. The newly formed Borland company, essentially penniless, places an advert for Turbo Pascal in Byte, bluffing the Byte Ad executives into giving them credit. The compiler is priced at $49.95 and is an instant smash hit.
  • 1986 Turbo Pascal 4.0 released, featuring an Integrated Devlopment Environment--the first of its kind for the PC environment--and introducing modular compilation (previously Turbo Pascal programs had to be compiled all in one go and could be no larger than 64K unless overlays were used). CP/M support is dropped.
  • 1988 Turbo Pascal 5.0 released, featuring integrated debugging and VROOMM (Virtual Runtime Object Oriented Memory Manager) overlay management technology.
  • 1989 In response to Microsoft's object oriented QuickPascal, Borland releases Turbo Pascal 5.5, which has its own OOP extensions. Microsoft later drops QuickPascal from its product line.
  • 1990 Turbo Pascal 6.0 features a new, much improved Integrated Development Environment, and includes the Turbo Vision object-oriented application framework.
  • 1991 First release of Turbo Pascal for Windows. Features a Windows hosted IDE and the ObjectWindows Library (also known as OWL).
  • 1992 Borland Pascal 7.0 includes both a DOS and a Windows hosted IDE, and allows developers to target DOS, DOS Protected Mode, and Windows.
  • 1995 Delphi and Delphi Client/Server released on schedule on February 14th.


This interview originally appeared in EXE, the UK's leading programming magazine. If someone can send me a .EXE cover or logo, that is appreciated!
Thanks to Ben Riga for sending it to me. Thanks for also not mentioning the Language Reference Manual.