This site doesn't describe the internals of Borland's Turbo Pascal compiler. It describes a compiler written in Turbo Pascal that can compile some subset of Turbo Pascal's language.
Borland's Turbo Pascal compiler was written in 16-bit x86 assembly, mostly by Anders Hejlsberg.
There is an explanation of this on the front page of the site, but it's not clear from the headline.
(I used to work at Borland on the Delphi compiler, and had access to the source of tpc.exe.)
.. thats the story I was hoping to read, and have been waiting for, for many years.
I went from the necessity of A86 assembler, thru the desperation of GW-Basic .. finally finding Turbo Pascal, which was a revelation at the time, just this phenomenal product and superb piece of engineering.
Pulldown text menus, draggable text windows, editor out of the box .. fast compilation, wow - to me its one of the great monuments of computer history. I feel intensely nostalgic looking back on it now.
And their manuals were first rate.. classy all round.
My dad, who knew nothing about computers, saw an article in the Wall Street Journal about this guy with a new business model for selling software. On a whim, he got me a copy for my birthday. It was TP version 1.
I stuck with TP through version 5, and even convinced my college teachers to let me use it for my programming assignments rather than whatever was on the college mainframe.
The manuals were indeed a huge asset. You didn't really need to know anything about the OS, or go digging for third party documentation online, which was important because there was no online.
Ah, yes. Now I get it. I'm kinda slow on the uptake sometimes. ;-)
I stopped with TP5. At that point, I was up to my ears in my thesis project, and was not going to change any of my tools. Plus I'm a real tightwad. By the time I finally finished my degree, got a new job, and a new computer, it was an Apple Mac. And the modern OS's kind of killed my interest in programming for a while.
Be glad you had that one. The other BASICs of those times where much more limited! GW was a little bit of awesome in it's own way. Oh, and POKE and PEEK.
I have very fond memories of just how blazingly fast Turbo Pascal was at compiling on my Mac. It stunned me every time. I remember spending most of one summer writing a text adventure game with it, based in the Australian Gold Rush. It even had NPCs which was quite advanced for text adventures of the day (I think the only NPCs in adventure games that I had encountered up to that point were those in the Hobbit, and of course the bloody thief in Zork (although he wasn't really an NPC, but was implemented as a bunch of semi-random encounters)...
Good times. In particular, I remember having to implement my own strings, because for a text adventure you often want to have access to strings longer than 255 characters...
Sadly, I never managed to make the jump from writing console applications with TP to writing proper Mac GUI apps. But "Inside Macintosh" cost an absolute fortune at the time (for a 10 year-old kid at any rate), so I ended up scraping enough money together to buy another text book whose name escapes me. I must have read the first few chapters about a million times - they talked about handles and graphics ports etc, but I could never get any code from them to run in TP (I think they were assuming that you would be using MPW?).
Which brings me to the point of this long rambling message - did TP really support graphics programming on the Mac? I know my version of TP was an official bought copy, so we had the manual, but I don't remember ever seeing anything that explained GUI programming in there.
Well you also had Apple's Object Pascal as the original OS system programming language, which was the inspiration for the OOP approach Turbo Pascal adopted.
With that one, you could surely do graphics programming on the Mac.
As for Turbo Pascal itself, I wasn't aware it was available on the Mac as well.
A more popular alternative to Apple's MPW on the mac was the 3rd party Lightspeed Pascal (later renamed THINK Pascal), which in many ways was quite similar to Turbo Pascal on the PC.
IIRC TP was just a quick port & had a very short life on the mac.
I didn't realize Turbo Pascal was ever released for the Mac. Apparently (according to Wikipedia) it was, but it was soon discontinued. Lightspeed/THINK Pascal/C ruled the roost on the Mac for a long time (thanks in large parts to just how horrible working with MPW was) until the PowerPC when Metrowerks took their place.
I remember at the time that C was more compelling specifically because of the limited strings in Turbo Pascal. At least TP had variable length strings.. older PASCALs did not have this (they had space filled strings instead).
The Turbo Pascal compiler was based on the Blue Label Pascal compiler originally produced for the NasSys cassette-based operating system of the Nascom microcomputer in 1981 by Anders Hejlsberg. Borland licensed Hejlsberg's "PolyPascal" compiler core (Poly Data was the name of Hejlsberg's company in Denmark), and added the user interface and editor. Anders Hejlsberg joined the company as an employee and was the architect for all versions of the Turbo Pascal compiler and the first three versions of Borland Delphi.
That's correct, I even have a version of it for the Z80 Softcard on the Apple II. Even in that day, the license was still only for 1 CPU and you had to mail in a license registration card to be able to use the software (I don't think that sort of EULA is legally enforceable, though)
The book just told you to mail in the registration card with strong language. I don't think it was legally enforceable in any way. There wasn't a license key or anything.
I think you're misremembering things. I'm pretty sure I ran CP/M Turbo Pascal as a kid and the page you link says:
The final step in November 1983 - Turbo Pascal v1.0 is created for Borland International, Inc. Distributed on a single floppy disk, Turbo Pascal integrated the Pascal compiler, Wordstar-like text editor, runtime library, run in memory, and creation of .COM programs - all within 131,297 bytes in the TURBO.COM file. The whole product was 33k bytes in size and ran in 64k bytes of memory. The product was delivered for CP/M-80 (Z/80, 5.25 and 8 inch floppy disks), CP/M-86, and MS-DOS/PC-DOS.
Blush. I'm delighted to be corrected as I didn't know this.
A 15 year old version of me met The Man himself at a trade show where he was demoing COMPAS Pascal, running a maze generator. I've learned a lot from using and disassembling his software.
According to the author, it is not just a subset and actually produces the same binary files as actual TP would (with the exception of debug info). I can't currently verify that claim, but here's what he says on the downloads page:
"It can compile any source code compatible with Turbo Pascal 7 syntax. It will generate the same executable file and unit files as the original Borland compiler."
It's unlikely to be 100% bug compatible with TP 7. There are various obscure bits in most languages that have been around for a while, where the implementation choices are a bit arbitrary and interaction between different features can turn up unexpected behaviour.
Turbo Pascal was a much smaller language than what Delphi became, so I can't point you out examples off the top of my head. If I were looking into compatibility issues, I'd play around with things like alignment and packing rules, TP's various hacks to get around Standard Pascal's fixed length strings (e.g. OpenString {$P+}), etc.
Turbo Pascal was also available on CP/M (so 8080/Z80 8-bit). It was the most powerful language on Amstrad CPC 6128, the only 8-bit low cost computer to offer CP/M compatibility.
IIRC from the stories I heard, Anders retargeted the compiler to x86 in the course of a single weekend. I don't remember what it targeted first, but it wasn't x86; it might have been Z80, I don't recall.
You're right, in Europe the Amstrad was less expensive than the Commodore and hence far more popular. The CPC 6128 was probably at this time the less expensive computer to run Turbo Pascal.
The Apple II has an optional Z80 card, but the total price was not for everyone, at least in Europe.
I don't remember the 6128 being cheaper than the C128, and the prices I've found online doesn't seem to support that either. I'm sure it might have been the case in some markets, or some configuration (since the C128 could be bought without a hard drive and without a monitor) but it seems far from universal.
Amstrad also sold far less than C128. The whole Amstrad CPC line sold about 3 million vs 5 million C128's. I don't know the breakdown between the Amstrad CPC models, but I'd bet a substantial percentage of that was the 464.
I'm sure the Amstrads were more common for CP/M, though. Of the few people I knew with C128's, most used it as a glorified C64, and nobody used the CP/M mode.
(Incidentally you could also get CP/M support for C64 through a cartridge that housed a Z80...)
The floppy disc reader was required for CP/M (and a 80 column monitor), so the comparison is with the C128 + 1571 or with the C128D.
If in 1985 the C128 had been cheaper than the 6128, I'd have bought the Commodore instead.
I rememeber the CP/M floppy ... I booted it once or twice but did not know what to do with it, so I ignored it. I usually booted my C128 in C64 mode to play games.
If you had a disk drive, that is. Many if not most MSX machines were typically used as game consoles running games from cartridges.
On CPC6128 the disk drive was standard (and yes, it was that strange 3" variant, not using the 3.5" disks that would later be known as the "3D model of the save icon".)
Interesting! Any stories you could share from your time at Borland ?
I started programming with Turbo Pascal pretty much (if one doesn't count a small bit of BASIC before). I also have a vivid memory of Delphi, both programming in Delphi (which was a breeze) and reverse engineering programs written in
Delphi (which was a nightmare).
When I got to learn C, already had Turbo Pascal 3, 4, 5.5 and 6.0 on my toolbox.
Compared with Turbo Pascal, the only thing C had going for it was being available in other systems. Everything else was meh.
No memory safe handling, no bounds checking, no units (modules), no namespacing, no proper strings, no OOP support, arrays decaying into pointers, no type safe enumerations, no sets, no generic array indexes...
At least C++ allowed me to get some of those Turbo Pascal features back.
I loved playing with the OO "Turbo Vision" framework back then and getting to learn about OO. Only programming Qt in C++ was equally enjoyable. The modern web is difficult to stand in comparison (though Anders is involved in Typescript).
And that big fat stack of manuals you got with Borland Pascal (which I recall buying used for perhaps equiv of $60 in 1993 - same price as the used 2400 bps modem).
Pascal was off time. A lot of these traits are really worthy, but it wasn't attractive at the time .. was it as 'performant' as C too or was it a very nice environment to craft sound code productively whereas C code could allow you to tap into hardware more aggressively no matter how much headaches that would give you ?
Pascal and C compilers produced similar code quality back then.
Everyone praises C compiler quality nowadays. On those home computers, C, Pascal and Modula-2 were good enough for general purpose applications, if one wanted real speed, Assembly was the only way to go.
Turbo Pascal, as well as any other Pascal dialects, had the same capabilities to access hardware as C offered.
Also the MS-DOS game development scene and the demo scene tools were heavily based in Turbo Pascal, besides the usual Assembly stuff.
Oh right, I remember inline asm in TP now. I smile at how easy this thing was, I didn't even know how many thing happened under the cover, I just typed so glyphs (I didn't know the language) and hit F5 IIRC. Only recently I heard how they designed the compiler to be so fast you didn't see the build step.
I think people who were using computers in the 1980s have their baseline for speed as Assembly and anyone from the 1990s on have C as their baseline of speed.
Man I hated reading or figuring out other's Assembly code and Turbo Pascal was a dream in comparison (And Fortran also)
C compilers tended to be atrocious back then. I remember "porting" some code from C to assembler by compiling it, disassembling it, and then patiently going through several thousands lines of asm output and adding labels etc. as well as deleting on average every second instruction or so, because the compiler was so bad at optimizing register usage.
Seeing disassembled code like that kept me from learning C for years...
Given the caveat that performance is always a question of how well the implementation performs inside the limits given by the language: Yes Turbo Pascal produced fast code. About as fast as Turbo C. Which was really quite fast. Also, the compilation process itself was very fast compared to other Pascal compilers.
About the question you didn't specifically ask: There's no reason (apart from optional stuff, like array bounds checking) that a Pascal compiler couldn't produce code of equivalent speed as a C compiler. (There is one language with a potential speed advantage over Pascal/C/equivalents and that's Fortran.)
Worse is Better seems to be an ongoing theme in the programming industry. (Pascal was much more readable and safe than C, and about the same speed - e.g., I could cobble up pointer arithmetic in TP if I have to with the address-of operator and increment/sizeof pseudo-functions)
First it was shitty C code in the 90s, and now the Java language. At least I'm not totally burned out on Javascript yet :-)
Very. Gabriel might go back and forth but I was sold on the concept first read of paper. Let's take Turbo Pascal or even Delphi. People were griping at one point about all C's problems and C++'s similar + new problems. They wanted a more productive, safer, easier-to-integrate systems language. I cited Wirth already built half a dozen and Borland industrialized them. Hell, even industrial BASIC's had less problems that C development with similar safety, readability, and dev speed.
What's the market do? Push all effort into C and C++. Results of that are still with us. (sighs) Go and Rust give me some hope in that they're first mainstream languages that solve some problems. On non-mainstream, Julia is an awesome development that might be re-applied to systems programming. Not to mention Racket's metaprogramming combined with C or assembler generation for a high-level use of low-level, fast language. Ivory language does that with Haskell, for example.
> What's the market do? Push all effort into C and C++. Results of that are still with us.
Not to mention the amount of money spent writing band aids for them., in form of static and memory analysers and more recently CPU instructions (Intel MPX).
Which not everyone uses, because either it isn't available on their platform, or they choose not to use them anyway.
Just like coders that despite C++ safety improvements over C, use it as C with C++ compiler.
Yeah the band aids add up. We'd need things such as static analysers anyway for spotting problems, optimizing, etc. However, an extra problem with C/C++ is that the languages are so complex to analyse that people get friggin' PhD's for certifying or formalizing even a subset of them. And the average programmer working against the clock is supposed to make something robust with such a tool? That's ridiculous.
" because either it isn't available on their platform"
I tried to solve that with my tools (lang X) using X-to-C compiler w/ seemless FFI for 3rd party code. Encouraged other languages to do that with many having done it before I got on the scene: Modula, Oberon, Ada, LISP/Scheme, and so on. Let them use good language with hardware/OS of choosing. Ignored it as you said.
"Just like coders that despite C++ safety improvements over C, use it as C with C++ compiler."
David Thornley brought this up on Schneier's blog when he said he was distrusting about those who mentioned "C/C++" as if they're same thing. That using modern C++ prevents many C issues if it's used correctly. Now, I abandoned C++ as anything but a compiler target after all the 90's empirical evaluations showed it was garbage. I think my critique that it lets you shoot yourself in foot easily and is hard to analyse probably still applies like it did when I cited them together. It's why I do.
Nonetheless, I honestly don't know how modern C++ developers code when they're doing it "right" with style guides, newer language features, peer review, etc. I think it would be fair in these discussions to do some new, empirical studies comparing proper C++ to Free Pascal, Go, Rust, Ada, etc in various attributes like was done in 90's. Critical that it's used as pro's say it should be so as not to mislead readers about effectiveness (i.e. C++ used like C didn't work). You know any resources I could use to catch up on topic that capture most or all of how pro's do C++ with modern features? Not necessarily most recent standard but what has been used at least past 5 years maybe 10.
The problem is making sure there aren't some guys in the team doing C style coding.
Nowadays C++ is still my language to go when I need to step out of Java and .NET.
The problems faced by Turbo Pascal and other languages to keep up with the OS vendors SDKs teached me to only invest on first class languages for production code.
Effective Modern C++, Tour of C++, Elements of Programming and From Mathematics to Generic Programming are all good books, where safe modern C++ is used.
Thanks for the summary and references. Will be helpful if another honest language comparison is done of C++ against safe, systems languages. Or C++ developers against others on realistic, example programs.
"The problems faced by Turbo Pascal and other languages to keep up with the OS vendors SDKs teached me to only invest on first class languages for production code."
It makes sense. My solution was a auto-generating that from a better language and wrapping their libraries. That does take some serious tooling support, though.
The funny thing is, I have actually come to like Unix, compared to the alternative. But C is NOT an applications programming language - it really is just portable assembler.
So much programming machismo:
* Bounds checking is a little slower, so safeties off!
* Multiprocessing with explicit IPC is slightly slower than thread pools, so safeties off!
* Parameters and explicit return values to functions are a little slower than DATA-DIVISION / instance variable mutation whack-a-mole code, so safeties off!
It's a portable assembler plus a structure for programs. LLVM IR is a portable assembler. I like your examples of their machismo, though. The machismo concept particularly: "Real programmers don't need all those safety mechanisms! Get out of here kid and take your training wheels with you!"
Funny part is they say this even when alternative languages or libraries implement safety tricks without a performance penalty. Then we see clearly that their resistence isn't technical. ;)
Turbo Pascal was fast (produced decently fast code and compiled in a flash compared to C compilers) and very common with the game and demo coders of the time. They did liberally use inline assembly code, though.
30 years ago, the AP Computer Science test was given in Pascal. I thought it was perfect for its time. I think it moved to C few years after I took it, then eventually Java.
Turbo Pascal was my first contact with compiled languages in school, after starting off with Commodore Basic as a kid and graduating to Amos and some other Amiga stuff later. TP was my first contact with real PCs, too. After school I moved to Delphi, which was basically a thin wrapper around the Win32 API with Object Pascal syntax and the nicest IDE I had ever used (and probably will ever use).
Delphi really paid my bills as a newbie commercial programmer. That was around the time when the internet took off, and I wrote my first CGI servers in Pascal to make dynamic websites. The Pascal/Delphi language and environment were incredibly versatile and you could write some really fast code with it.
Fond memories. In many ways, TP leveled me up as a programmer.
I think a lot of people would have claimed that the Amiga was the more powerful Personal Computer. In many ways, it was more interesting than the Mac or Windows computers. It simply didn't have the software support from Microsoft, for example.
In most alternate universes, the Amiga would never could have been a competitor to the PC or even the Mac.
The secret to the PC's success was not just the clone market, but the open architecture that permitted endless permutations on interexchangable components: motherboards, graphics cards, hard drives, etc. were all pluggable.
Amiga's custom chipset and architecture gave it a huge edge (mostly in multimedia), but the tight coupling made it an evolutionary dead end. Even if they licensed the OS and opened the architecture to clones, the hardware dependency wouldn't have been able to follow suit.
Absolutely, it took a long time until the games I made on my Amiga could be replicated on the PC. But by the time I was moving away from Amiga, it was clear that its time had passed.
I was working at a software store during the mid-late 80's (Babbages if anyone knows it) and had a customer come in asking for a small, lightweight editor... You know like "turbo pascal but w/o the compiler part". First time I ever heard of it and, tbh, had no idea what he was talking about. I later used it to do some work for in my CS class (highschool was teaching programming via Pascal). It's a good language to learn after basic and before C/C++.
IIRC correctly, TP used a yellow font (well ascii) on a black background (default)? Didn't it also have some quick key combinations (I recall a ctrl+k for some reason but I'm sure it's just memory...)
> Didn't it also have some quick key combinations (I recall a ctrl+k for some reason but I'm sure it's just memory...)
Exactly. So-called WordStar combinations, which lot of the editors of the time were using. AFAIK, it is still used on some quite popular text editors on Linux (joe?).
Turbo Pascal was the first language I was taught in school, although I had already taught myself BASIC on a BBC B Microcomputer as a child.
I loved Pascal and wrote a race management program for my local sailing club when I was 16. Fond memories. The whole experience was a voyage of discovery, as I had to write my own "windows" style UI using ASCII codes.
I used Delphi later on in university along with Modular2, and C++. I never felt the same passion for these languages as I had had for Turbo Pascal.
I later moved on to VB and VBscript, and didn't like them at all but they paid the bills.
The next time I felt that same type of passion was for C#. Somehow it just clicked. I think it is about what you can achieve productively with the language, as well as the language itself.
You will then be pleased to know that C# development team is led by Anders Hejlsberg, the same Anders mentioned in the article that created what went to become Borland Turbo Pascal. IIRC, he also led the development of Borland Delphi and its language, Object Pascal.
He is really a prolific language designer, one of the unsung heroes of that area.
Object Pascal was originally an Apple invention (with help from Wirth), and made some strides towards ISO standardisation. However it used a value-based OO model that made vtables optional until you added the first virtual method, permitted object slicing, had no common ancestor for all classes, had an odd syntax for calling constructors (using extra parameters to New), etc.
Delphi introduced a new object model while retaining the old object model for backward compatibility. The language was renamed to Delphi some time later to reflect this; while Object Pascal in practice meant the language that the Borland compilers compiled, its technical and historical meaning is both broader (more compilers) and more limited (a smaller language with different features).
Yes, quite some time back they split the languages and compilers part out and the rump of Borland became an application lifecycle management company, or something like that.
The bit you're probably looking for is at http://www.embarcadero.com/ now. Some of the old people like David Intersimone are still there.
I worked with Delphi for a long time, through versions 3, 5 and 7 (the odd numbers were always better). When .NET came, the whole situation went crazy and never recovered. I can't remember the twists and turns now, but I think they released a .NET only RAD Studio which was awful, then they added the Win32 bits back but Delphi.NET was still awful. Then they dropped .NET and incorporated Remobjects Chrome/Oxygene as Delphi Prism, which was an Object Pascal inspired .NET language. Now they've split again, and Radstudio is all about Firemonkey, a cross-platform UI library. Remobjects are doing their own thing.
I've been working with Delphi for the last 18 months; previously Java and .Net many years before that, but Delphi in the distant, distant past.
In my opinion, Delphi needs to just die, and the people/companies that have code bases built on it need to rewrite. There are lots of choices for software development these days, I don't think Delphi stands out for any particular use case in the modern world. But hey, maybe I'm just bitter after RAD Studio crashed on me one too many times...
Compared to VC++, it was easier to learn, read, write, make reliable apps, and extend. I could teach anyone a Wirth language. The Go community is learning the benefits of Pascal-style design. People wanting a new Delphi should probably use Go. Just because Delphi stagnated and died off.
Anyone wanting Pascal/Delphi today should use Lazaurus IDE w/ Free Pascal Compiler. Compatible with Delphi where it mattered, aiming for better in other areas, open-source, and cross-platform. Best use case is a C or C++ replacement that's safer, easy to read, and supports computers with little resources. Go's not there yet on runtime side.
> People wanting a new Delphi should probably use Go. Just because Delphi stagnated and died off.
Or, for that matter, Nim, which also has a huge amount of Pascal heritage.
Go is a hybrid of Oberon and C (with semantics leaning more towards Oberon and syntax more towards C, but they're both mixed in), and Nim is Modula-3 semantics married to Python syntax (with the best parts of a bunch of other languages thrown in). Both Oberon and Modula-3 are descended from Modula-2, which in turn is descended from Pascal.
Personally, I'm more in the Nim camp, partially because I prefer Modula-3 to Oberon, partially because I prefer Nim's Pythonesque syntax to Go's C/Oberon mashup syntax, and partially because Nim's metaprogramming features are truly beautiful.
Modula-3 semantics married to Python syntax. Now that sounds potentially great. :) Even more so since I've recommended each language. Modula-3 was the second time (since Turbo Pascal) that industry types took Wirth's design ideas, ran with them, and produced an industrial implementation that kicked ass. Was used in SPIN OS w/ type-safe linking where OS and linked code leveraged type system for protection. Python syntax's benefits are well known.
I was a bit concerned about the maturity, compiler complexity, available libraries, and so on about Nim. I figured it might be in alpha quality or something given it's so new. So, I was hesitant to try it. I might give it a go sometime soon reading comments like yours.
Btw, do you have experience with its macro system? Any take-it-to-next-level language needs at least good macros and preferably great ones. Top contenders of my recent research are Racket, Julia, and Red. If Nim is more like Modula3/Python & has good macros, then it might be a credible contender due to mainstream programmers being able to pick it up more easily than really weird languages.
Go might have a few Oberon influences, and it was what made me look at it in first place.
However, even Turbo Pascal was more expressive than Go in terms of language features (not taking the GC into account). Delphi even more so, specially if one takes into consideration the VCL and IDE.
But, it would be nice to see someone come up with a System 3 Gadgets library for Go, or an environment like BlackBox Component Builder.
I totally agree. Blackbox is particularly kicking butt in Russia. I recommended Go because it's mainstreamed with all benefits that entails for developers and employers.
Most people writing Delphi code in 2015 do it to maintain legacy Windows desktop applications. I don't think you can do that with Go. The most logical replacement would still be C# (or another language running on .net) with WinRT (or more likely WPF: I mean if you are still using Delphi you are probably not using Windows 8/10...).
Funny you say that cuz I picked it for future proofing. I specifically wanted it to be the legacy language instead of C++ in case the talent was short many years down the line. That proved out haha. ;)
Yeah, Delphi needs to die. I used it for a long time, and it was an excellent product for developing Windows applications when compared to the main alternatives, i.e. Visual C++ with MFC (the horror!) or VB6.
It was fast, efficient, easy to use, with a great community, good tooling and the picky type system tended to find a lot of potential bugs at compile time (once you got used to it).
Now there are a lot of alternatives and to be honest, I can't really think of a reason you'd choose it any more - even if you /did/ want to create Windows native apps.
How about: Using win32 means your application works without any problem and any third-party dlls or weird installs on anything from win2k to windows10 and winRT (any non-arm version). Making a single .exe that works across all of them isn't very hard. Making one that also works on linux and even android and ios is possible, but isn't nearly as seemless. Needless to say, you won't achieve this with either webapps, C#, java, or any of the other languages.
It's incredibly fast. You know how Go and C++ start with tiny applications ? The app starts up 0.2 seconds after you've finished typing the command. Delphi does that for 150000 lines applications. Your executables are decently sized (2-5 megabytes for large apps, kilobytes for small games and the like. Especially Go and C++ have problems with executable size. Go's hello world is still > 2 megabytes, and large go apps have huge binary sizes (dozens of megabytes), despite not containing spectacular amounts of code. Large C++ binaries, statically linked, are dozens to hundreds of megabytes (and God help you if you turn on debug info. I've known compiling a webserver + database app in C++ that actually failed to compile due to the single binary filling up the disk that had ~18 Gigabytes of free space (the binary, once compiled was 1.8 gigabytes, the rest was intermediate files)).
The number of add-ons, controls, database connectivity, install software, ... available for Delphi defies belief and they're extremely high quality.
It's extremely unlikely to change in backwards incompatible ways. Your code will keep working, and will keep looking and working the way it does now (compared to java or shudder the web, it's heaven)
Of course, there are downsides : manual memory allocation is a bit inconvenient (but very fast), HTTP/JSON communication is tricky. Nobody trusts .exe files anymore (for good reason, of course, but ...). It's unlikely to impress when judged on the last buzzwords.
Borland decided that the new shiny thing was "enterprise client/server middleware" — whatever that was. The new Inprise products were oriented towards building distributed client/server database apps using DCOM and the all-too-obviously-dead-on-arrival CORBA.
This was right around the time the web took off, but before the inane "enterprise Java application server" market exploded. Borland had a hard time competing with Java, and they started to neglect the stuff that had made Delphi such a powerful proposition in the first place.
I used Borland C++ Builder and their version of it in the XP - Windows 7 days, when they released Codegear 7. As far as I knew many of the developers left after they renamed themselves Inprise ("integrating the enterprise" whatever that means), decided to produce odd products that targeted an entirely different audience and after they ditched all the development work on C++ Studio (I think that was what it was called).
I remember them introducing Kylix and the disappointment of it being based on Qt and Wine so slow on my old Linux box. The VCL stagnated too (horrible flicker on XP as I recall, to begin with so hacks to disable theming via the application manifest were needed) and the compiler let you do illegal things in C++ in Codegear's C++ Builder 7 (must dig out an example). The installer for C++ Builder 7 took FOREVER to run and also required you keep all of your setup files in your temp directory for later updates to work (???? insane eh!)
I remember them releasing a paid PHP editor etc. at the time when you could just grab Netbeans and use that for £0.00 - difficult to compete with that!
> Anders Hejlsberg developed Blue Label Pascal... This compiler was later licensed by a software company Borland which added user interface and editor, changed the name to Turbo Pascal and offered it for a competitive price.
Nooo... Another account of TP origins was that it was written by Philippe Kahn (the founder of Borland), back when he was just a one-man operation running from a small office on top of a Jaguar car service shop. But apparently it wasn't. Damn.
The implementation size breakdown for the 12k compiler was: Compiler - 5.5k, On-Screen editor - 1.5k, Runtime library - 4.5k, and Control program 0.5k.
I took over maintenance of an in-house application written in Delphi/ObjectPascal about 18 months ago (as one of my many tasks - I have spent maybe one or two weeks working on it since), and I thought Lazarus was a neat way of getting me started, having no prior Pascal experience whatsoever. Alas, the IDE crashed on me so frequently both under GNU/Linux and OS X that I gave up within a couple of days. Either it is not very stable or I was mistreating it somehow, although I don't know how.
The documentation was very helpful, though, in getting to know Pascal. Taking over maintenance of an application written in a languange you can read but hardly write (whatever bad things people might be tempted to say about Pascal, cryptic syntax is not among them, I am certain) is a strange process.
I'm triggered by the lack of diversity in that story. I am pretty sure Niklaus Wirth was actually black, but that fact was hidden by white male zealots.
Borland's Turbo Pascal compiler was written in 16-bit x86 assembly, mostly by Anders Hejlsberg.
There is an explanation of this on the front page of the site, but it's not clear from the headline.
(I used to work at Borland on the Delphi compiler, and had access to the source of tpc.exe.)