Embarcadero is pretty much in the business of soaking customers locked into Borland's old products for as much as they're willing to pay, hence why the IDEs cost an arm and a leg while competitive products are relatively cheap or free.
this whole borland/delphi approach is rather similar to how Visual Basic for Applications still works inside of Excel or Outlook, and is still used by big companies all over the world as i type this.
Looks like C++ Builder is still available. Its way expensive and the licensing for community edition is very prohibitive...if you make more than 5k or you have more than 5 people on your team you need to pay up. And you practically need to sell a kidney to afford it. That sucks because this IDE looks really neat, but its def not worth the money in my opinion unless you are a larger company already
Is $500/year really the going rate for a kidney? That's like the price to rent some GPUs for an overnight training job. I think it's perfectly reasonable that Embarcadero makes their software free to use until it's helped you earn at least 10x that much revenue, on top of it being a flat rate. Most companies just divide their offerings into strictly commercial / non-commercial.
If you make 5k 500 is 1/10 of your yearly income. That is a pretty big amount, especially when you take out taxes and operating expenses. Thats why I said it isn't worth it UNTIL you are a bigger business.
Well, as a beekeeper if you wanna sell some honey you need to buy some bees first, no?
You’d probably spend more money getting tools and equipment for a one-person neighborhood lawn mowing business…
They have abandoned community editions - it is several years behind the pro edition, broken on high-DPI monitors, no code-completion/navigation. No plans to release a new version.
Doesn't sound like a winning strategy long-term. From other comments it sounds like they are focusing entirely on customers that are already locked in with them. Eventually though, those customers are either going to go out of business as all businesses eventually do, or they are going to have to move on to other tools eventually.
If community edition is never updated, IDK how they can expect to grow or gain new customers. Thats why Visual Studio updates their community edition so often, because that helps people get familiar with the tools and companies are more likely to adopt them.
Good tools come with a price, and that applies to all industries, not just programming. The most comparable offering would be Microsoft Visual Studio: free up to 5 users for smaller companies. If you have more than 5 users, it’s $45/user/month (for the cheaper Professional edition, but it would be good enough for most). And if you’ve got >250 PCs or >$1M in annual revenue, the 5 free users do not apply.
My main problem with delphi: it is "too proprietary". It was a very productive IDE in the 90's or early 2000's but lost their path and never recovered.
Some new versions broke compatibility with previous version's components. There was the case where you paid a good amount of money on some proprietary components and they simply wouldn't work in the next version: you were imprisoned in an obsolete IDE. By not being multi-platform (I heard it improved lately) you could only use it with/for win32 so it lost servers, embedded, cloud and mobile. By not being open-source nobody could improve it.
Then it had to compete with "native tools". Whoever develops for windows wouldn't quit ms' tools to use it, whoever develops for mac wouldn't quit apple's tools to use it, whoever develops for android wouldn't quit google's tools to use it, whoever develops for linux was mostly ignored after kylix.
Note that I didn't even mentioned price and license.
They improved it later, I heard. But seems more like the old case of too little too late. Most successful programming languages today are open source and multi-platform. Delphi was dependent on win32 for too long and it still is "too proprietary". You do the world a favor by porting your project to lazarus.
what I want is terminal based turbo-C++ ide with the plugin architecture of vscode and solid integration of code browsing. & yes I can do it with vim or emacs but I dont wanna.
I worked with Delphi for several years, and it was the first IDE I used professionally. It was truly brilliant for developing Win32 and WinForms applications. I can honestly say that Delphi 5 was a better tool for building Windows apps than the latest versions Visual Studio, at least in terms of usability, responsiveness, and debugging.
But man are you ever right about the compatibility issues! Upgrading from Delphi 5 to the (then current) Delphi 2005 was a total nightmare. Our codebase was about 600k lines, and I will never forget the trauma of trying to get it to just build in the newer version.
The comparison with .NET codebases that "just work" from version to version is night and day, and sadly it's worth putting up with a laggy beast of an IDE to have that security around your projects.
Did anyone see it as “not native” in its native environment, Windows? Weird. It was a straight continuation of Turbo Pascal and Borland C++, both as native as anything could be since DOS and Windows 3. I think you're just plain wrong there. I don't know anyone who saw Delphi and C++ Builder as “not native”.
There are a couple of telltale signs for Delphi in older apps: one is the use of TBitBtn control which adds an image to the buttons, the other is the use of icons in menus. While both can be done via "raw" Win32 (or MFC), they are much more cumbersome whereas with Delphi it is done by simply picking an icon from the visual designer - especially for the button one since Windows does not have a control like that (it is a custom control by Delphi). In general my first thought whenever i saw a GUI with lots of icons at the time was that it was made using Delphi.
Other toolkits added this sort of functionality so it doesn't look as out of place nowadays, but especially icons on buttons was kind of a Borland sign.
In Win3.1 times it was even more apparent since Borland OWL had its own sort of "theme" for dialogs that had a textured and chiseled look with large 3D controls, so these apps stood out more. This was toned down in 32bit versions of OWL though it still used custom controls (check the button shape here[0] and how it looks a bit off compared to other buttons).
Also Borland had a tendency to make their own icons for stuff that other programs used standardized icons for, often with very different symbols which also made them stand out and look weird. For example in the screenshot i linked at the first two icons are for open and save and the bolt icon is for running - those are from OWL. In Delphi the save was different (but still not a floppy) and the new and open icons were identical, a shining page of paper, except the open had words on it. Their "undo" icon was a red circle with a crossed line that in other apps would be something like "delete".
Also FWIW i noticed that Neverwinter Nights' editor was made in Borland C++ Builder (i wrote the linked post) because the arrow icons used in it (visible in the screenshot in the post below the 3d viewport) are straight out of Borland C++ Builder. Though Bioware did make their own icons for other stuff.
Again, nowadays these things do not stand out much, but back in the 90s/early 2000s when the Windows world was more uniform and developers did care about making applications that had the "Win9x" look they did.
> There are a couple of telltale signs for Delphi in older apps: one is the use of TBitBtn control ...
Yeah, but those are signs of it being not Microsoft, not "not native". At least back in those days, "native" meant "compiled into an .EXE file that runs directly on the hardware" (as opposed to, say, bytecode that runs on a VM (that is an .EXE that runs the hardware)).
Don't use delphi, the rad sucks for everything but dragging and dropping components. The drag and drop is also a pain in the ass because it will constantly adjust the layout, making every commit be filled with noise.
Maybe all frontend is this bad though, I don't have much experience with other tools.
In the dfm(the UI declaration file) the positions of elements are always absolute with relation to the forms top left point, they are just recalculated on the fly when a change in the form causes them to resize. Using alignment is great but it doesn't solve the problem. Not really that big of an issue in the big picture, just makes diffing forms annoying.
It's been a long time, so things might have changed... I doubt it anyway.
What you write about sounds very much like you could solve easily changing the default behaviours. There was some "autoalign" property, or something similar, that you can disable.
I won't install a demo to check, I'm afraid, but knowing that there's a solution could help?
The described issue exist in Lazarus so i think it'd be the same in Delphi and C++ Builder.
There are tools for automatic alignment, Lazarus has both an align property (align to the parent's left, right, top or bottom edge or to the remaining area in the center, which is good enough for many layouts) and an anchor system (allowing to either "anchor" an control's edge in place so it gets resized with the parent or to place an edge relative to another control's edge or center point) as well properties for margins, min/max size and a bunch of special-case containers that layout their children like page/flow, etc.
However the controls still have their left/top/width/height properties, the layout functionality just updates those. And since forms are just serialized objects that store a property's value if it is different from the default value, the left/top/width/height properties are always stored in the form even if they'd be overridden later by the automatic layout mechanisms (object serialization exists at a lower level than that, it doesn't "know" about forms or anything like that - in Lazarus it isn't even part of the LCL framework but instead part of Free Pascal's FCL framework on top of which LCL was written and technically these are two separate projects).
The end result is that if you open a project and for some reason the controls get resized (e.g. you have a different theme than the last time you opened it which would cause some buttons to be smaller/larger and in turn cause other layout changes), when you save the project the files in which the forms are serialized in will have different values than previously for their left/top/width/height properties - and that will show up in a diff when you have the project in version control.
This is can be a bit annoying since when you want to see what changed in a form you have to mentally ignore all the position and size changes. Though TBH in practice personally i never thought much about it.
The end result is that if you open a project and for some reason the controls get resized...
I used a graphical diff tool that showed both versions and allowed to revert unwanted changes with a couple of clicks. I think it was WinMerge. Also, I never opened the DFM designer unless I was going to make a change.
Top and Left need to be published properties, even for non-graphical components, so the designer can place them somewhere without covering one another. That's why they're declared so deep in the hierarchy.
The serialization code is one of the nicest parts of the framework. I was tasked once with translating an old and messy application. Translation tools, including the one by Borland, included in the enterprisey versions, were utter crap. I hacked the serialization code to extract the relevant strings into an Excel that we sent to the guy doing the translation and then use his output to create different DFM sets, all of them included in the exe, and selected when starting the application.
Actually everything about the IDE was great, there was a comprehensive API to make plugins ("experts") for the IDE, mostly undocumented, but Ray Lischner wrote a couple of great books about it and some nice guys created a set of useful utilities with source.
I think Borland is great example of what happens when you don't care about backward compatibility and try to milk your customers all the time.
Even since Turbo Pascal, and with Delphi, every new version (5->6->7) of a compiler/tool required new compiled libraries/components. Eventually a lot of shops (and Delphi and C++ builder were huge in xUSSR, for example) stopped to care and moved on to Java/C#.
I use the newest version (Alexandria) of C++ Builder everyday in my job since other developers in the company have legacy software from the 90s.
You can't really open old projects in new versions of the software. Some devs use VMs to develop on the old versions of Builder.
The documentation and the example code for the C++ side are horrible, because they are focused on Delphi. You must know Delphi to figure out how to use the libraries in C++. The documentation for Delphi also feels very light and outdated. The latest books about it are from the begining of the 2000s and there are very few Youtube videos about it.
Sometimes Intellisense stops working and you don't know why. Sometimes some access violation happens and the debugger gives you no hint why.
The price is also expensive. I think my company spent 2300€ for a single license and they expect you to renew every year.
It’s better to port cppbuilder with ui code to Mfc.that’s what we did at last when we were absolutely done with it. As a fellow developer who’d been in this situation before ,my advice would be to start doing it now
I have a vague memory of a Borland C++ coming bundled with a rather funky Smalltalk-inspired container library - this was pre-STL and in fact pre-templates even. Perhaps another old fart can confirm or correct?
I think early Borland container libraries had a "Object" base class for everything, pre templates. All that went away as C++ compilers started supporting templates more. I remember this era as always making tradeoffs between code size, memory consumption, standardness and performance. Not sorry those days are over...
My first IDE when I started to be excited about programming! I vividly remember a book that was about teaching C++ to kids; I devoured it and spent a glorious summer just fiddling with what I thought was very complex code at the time. How time flies...
Yep, I'm pretty sure Borland C++ was what I used in college in my first "real" programming class. The nice thing about the older IDEs was how easy it was to get started programming: start it up and you're looking at a blank source file; often you can compile and run without even officially saving it! Made it really easy to try things out. The only "IDE" that comes close to that level of immediacy today would be something like Processing.
For DOS development, I loved Borland Turbo C++. But for windows development, Borland's OWL never really clicked with me. I eventually got into windows using MS Visual C++ and MFC.
I thought the original OWL with the proprietary syntax for event handlers was great but by the time the second version came around we'd grudgingly switched to MSC++/MFC.
Yeah I think the jump from DOS to Windows, procedural to event-driven, lite framework to rich framework, and barely-C++ to very-C++ was just too much for me to tackle at the same time.
Truthfully I first dipped my toes into Windows development using Visual Basic, then jumped to MSVC++ & MFC after I quickly outgrew VB. Having smart colleagues [hi Keith!] and great MFC books [hi Mike Blaszczak!] around certainly made it easier.
There are many posters that complain about Borland Builder´s price tag, but what they may not realize is what Microsoft charged back then for Visual Studio C/C++ (plus the MSDN subscription fees) was likewise a lot.
You got piles of books and piles of floppy disks (later piles of CDROMs) for that.
Only recently, free development tools have become available that rival commercial offerings.
But most serious developers do not care about a few thousand dollars in tooling cost, because the main determinant of software cost is developer salaries and nothing else. Since they are typically six digit dollar amounts, the cost for tools like editors, IDEs, compilers and libraries pales in comparison or becomes a rounding error.
For companies I think you're right; but a price tag of a few thousand dollars was a strong deterrent for students or hobbyists/learners to get into doing those development. I think the web was great for learners in the 90s/00s because no special tools were necessary. All you needed was Notepad and a browser. If you did some CGI/Perl or PHP you may also need a $5-$20/mo web host account, that's about it.
And todays students will shape the future. If something not relevant with student’s now, it will not relevant with student’s future.
Finally that thing will be forgotten.
Borland's prices were much cheaper. Check the price list[0] from 1997, when the original BCB was made. The cheapest (Standard, the version that i used in the linked blog post) was only $99.95 (which remained the same until around 2003 and BCB5). Nowadays the cheapest is $1599[1].
Delphi also had similar prices.
In comparison Microsoft's prices for Visual C++ 97 were much higher, at least according to this old post[2]. The cheapest might have been $99 like Borland's but that was for the learning edition which could only be used by students for non-commercial purposes (Borland's $99 versions of Delphi and BCB did not have that restriction) and the next cheapest was $499 - practically five times more expensive.
Since then i also tried Qt Creator and while it feels more clunky than even the original Borland C++ Builder, especially with the form designer (which i think is basically the standardalone Qt Designer embedded in it) and how it doesn't feel like a coherent product but a mashup of different bits and pieces, it is probably the closest you can find in open source for a RAD(-ish) C++ IDE (big caveat that i have only used it sparingly, never made anything more than a few toy apps with it). I am a bit worried that you're still relying on the Qt company which has shown hostility towards the open source community several times but i think that between Embarcadero and Qt company, relying on the latter is better and it is popular enough for external developers to pick it up in case it gets abandoned (the benefit of it being FLOSS).
But at the end i still think Lazarus is better when it comes to a RAD IDE and framework (i am taking all three of these combined, not separated) for desktop applications, assuming you do not mind using Free Pascal as the language. Of course that is with my big bias since i learned programming on Turbo Pascal, used Delphi in the 90s, use Lazarus since the 2000s and in recent years even contribute to its development. Someone starting nowadays will most likely have a harder time getting used to it and the documentation could certainly be better.
54 comments
[ 3.8 ms ] story [ 121 ms ] threadAnd maybe by .NET 9, all the kinds of Delphi workloads will be finally supported by Native AOT and low level coding capabilities.
All enterprise products cost an arm and a leg, and at that level it hardly matters, license costs aren't where usually project budgets get burned.
If I take look on roadmaps and apply developer velocity of MAUI, WinForms and WPF it will take many more versions.
The component palette was identical to Delphi (and was still Object Pascal code). You could use Delphi UI components with it.
C++ support was a bit buggy in places, but not terrible. I had worse problems compiling C++ on AIX.
Delphi and C++ Builder were simply the best native UI creation tools I've ever used.
Community edition: https://www.embarcadero.com/products/cbuilder/starter
Professional https://www.embarcadero.com/products/cbuilder
https://www.embarcadero.com/app-development-tools-store/cbui...
If community edition is never updated, IDK how they can expect to grow or gain new customers. Thats why Visual Studio updates their community edition so often, because that helps people get familiar with the tools and companies are more likely to adopt them.
They don't. The business model is to milk existing customers for all they have got.
https://visualstudio.microsoft.com/vs/pricing/?tab=business
https://visualstudio.microsoft.com/wp-content/uploads/2020/0...
My main problem with delphi: it is "too proprietary". It was a very productive IDE in the 90's or early 2000's but lost their path and never recovered.
Some new versions broke compatibility with previous version's components. There was the case where you paid a good amount of money on some proprietary components and they simply wouldn't work in the next version: you were imprisoned in an obsolete IDE. By not being multi-platform (I heard it improved lately) you could only use it with/for win32 so it lost servers, embedded, cloud and mobile. By not being open-source nobody could improve it.
Then it had to compete with "native tools". Whoever develops for windows wouldn't quit ms' tools to use it, whoever develops for mac wouldn't quit apple's tools to use it, whoever develops for android wouldn't quit google's tools to use it, whoever develops for linux was mostly ignored after kylix.
Note that I didn't even mentioned price and license.
They improved it later, I heard. But seems more like the old case of too little too late. Most successful programming languages today are open source and multi-platform. Delphi was dependent on win32 for too long and it still is "too proprietary". You do the world a favor by porting your project to lazarus.
But man are you ever right about the compatibility issues! Upgrading from Delphi 5 to the (then current) Delphi 2005 was a total nightmare. Our codebase was about 600k lines, and I will never forget the trauma of trying to get it to just build in the newer version.
The comparison with .NET codebases that "just work" from version to version is night and day, and sadly it's worth putting up with a laggy beast of an IDE to have that security around your projects.
Did anyone see it as “not native” in its native environment, Windows? Weird. It was a straight continuation of Turbo Pascal and Borland C++, both as native as anything could be since DOS and Windows 3. I think you're just plain wrong there. I don't know anyone who saw Delphi and C++ Builder as “not native”.
Other toolkits added this sort of functionality so it doesn't look as out of place nowadays, but especially icons on buttons was kind of a Borland sign.
In Win3.1 times it was even more apparent since Borland OWL had its own sort of "theme" for dialogs that had a textured and chiseled look with large 3D controls, so these apps stood out more. This was toned down in 32bit versions of OWL though it still used custom controls (check the button shape here[0] and how it looks a bit off compared to other buttons).
Also Borland had a tendency to make their own icons for stuff that other programs used standardized icons for, often with very different symbols which also made them stand out and look weird. For example in the screenshot i linked at the first two icons are for open and save and the bolt icon is for running - those are from OWL. In Delphi the save was different (but still not a floppy) and the new and open icons were identical, a shining page of paper, except the open had words on it. Their "undo" icon was a red circle with a crossed line that in other apps would be something like "delete".
Also FWIW i noticed that Neverwinter Nights' editor was made in Borland C++ Builder (i wrote the linked post) because the arrow icons used in it (visible in the screenshot in the post below the 3d viewport) are straight out of Borland C++ Builder. Though Bioware did make their own icons for other stuff.
Again, nowadays these things do not stand out much, but back in the 90s/early 2000s when the Windows world was more uniform and developers did care about making applications that had the "Win9x" look they did.
[0] https://i.imgur.com/0KqRLuA.png
Similar to how many Delphi applications could simply not use TBitBtn (its use isn't forced) but they did use it anyway.
Yeah, but those are signs of it being not Microsoft, not "not native". At least back in those days, "native" meant "compiled into an .EXE file that runs directly on the hardware" (as opposed to, say, bytecode that runs on a VM (that is an .EXE that runs the hardware)).
To me, it still does.
What you write about sounds very much like you could solve easily changing the default behaviours. There was some "autoalign" property, or something similar, that you can disable.
I won't install a demo to check, I'm afraid, but knowing that there's a solution could help?
There are tools for automatic alignment, Lazarus has both an align property (align to the parent's left, right, top or bottom edge or to the remaining area in the center, which is good enough for many layouts) and an anchor system (allowing to either "anchor" an control's edge in place so it gets resized with the parent or to place an edge relative to another control's edge or center point) as well properties for margins, min/max size and a bunch of special-case containers that layout their children like page/flow, etc.
However the controls still have their left/top/width/height properties, the layout functionality just updates those. And since forms are just serialized objects that store a property's value if it is different from the default value, the left/top/width/height properties are always stored in the form even if they'd be overridden later by the automatic layout mechanisms (object serialization exists at a lower level than that, it doesn't "know" about forms or anything like that - in Lazarus it isn't even part of the LCL framework but instead part of Free Pascal's FCL framework on top of which LCL was written and technically these are two separate projects).
The end result is that if you open a project and for some reason the controls get resized (e.g. you have a different theme than the last time you opened it which would cause some buttons to be smaller/larger and in turn cause other layout changes), when you save the project the files in which the forms are serialized in will have different values than previously for their left/top/width/height properties - and that will show up in a diff when you have the project in version control.
This is can be a bit annoying since when you want to see what changed in a form you have to mentally ignore all the position and size changes. Though TBH in practice personally i never thought much about it.
I used a graphical diff tool that showed both versions and allowed to revert unwanted changes with a couple of clicks. I think it was WinMerge. Also, I never opened the DFM designer unless I was going to make a change.
Top and Left need to be published properties, even for non-graphical components, so the designer can place them somewhere without covering one another. That's why they're declared so deep in the hierarchy.
The serialization code is one of the nicest parts of the framework. I was tasked once with translating an old and messy application. Translation tools, including the one by Borland, included in the enterprisey versions, were utter crap. I hacked the serialization code to extract the relevant strings into an Excel that we sent to the guy doing the translation and then use his output to create different DFM sets, all of them included in the exe, and selected when starting the application.
Actually everything about the IDE was great, there was a comprehensive API to make plugins ("experts") for the IDE, mostly undocumented, but Ray Lischner wrote a couple of great books about it and some nice guys created a set of useful utilities with source.
Even since Turbo Pascal, and with Delphi, every new version (5->6->7) of a compiler/tool required new compiled libraries/components. Eventually a lot of shops (and Delphi and C++ builder were huge in xUSSR, for example) stopped to care and moved on to Java/C#.
You can't really open old projects in new versions of the software. Some devs use VMs to develop on the old versions of Builder.
The documentation and the example code for the C++ side are horrible, because they are focused on Delphi. You must know Delphi to figure out how to use the libraries in C++. The documentation for Delphi also feels very light and outdated. The latest books about it are from the begining of the 2000s and there are very few Youtube videos about it.
Sometimes Intellisense stops working and you don't know why. Sometimes some access violation happens and the debugger gives you no hint why.
The price is also expensive. I think my company spent 2300€ for a single license and they expect you to renew every year.
Truthfully I first dipped my toes into Windows development using Visual Basic, then jumped to MSVC++ & MFC after I quickly outgrew VB. Having smart colleagues [hi Keith!] and great MFC books [hi Mike Blaszczak!] around certainly made it easier.
You got piles of books and piles of floppy disks (later piles of CDROMs) for that.
Only recently, free development tools have become available that rival commercial offerings.
But most serious developers do not care about a few thousand dollars in tooling cost, because the main determinant of software cost is developer salaries and nothing else. Since they are typically six digit dollar amounts, the cost for tools like editors, IDEs, compilers and libraries pales in comparison or becomes a rounding error.
Delphi also had similar prices.
In comparison Microsoft's prices for Visual C++ 97 were much higher, at least according to this old post[2]. The cheapest might have been $99 like Borland's but that was for the learning edition which could only be used by students for non-commercial purposes (Borland's $99 versions of Delphi and BCB did not have that restriction) and the next cheapest was $499 - practically five times more expensive.
[0] http://web.archive.org/web/19970605053133/http://www.borland...
[1] http://web.archive.org/web/20230220010556/https://www.embarc...
[2] https://www.itprotoday.com/windows-78/microsoft-sets-pricing...
Some minor updates since then:
Since then i also tried Qt Creator and while it feels more clunky than even the original Borland C++ Builder, especially with the form designer (which i think is basically the standardalone Qt Designer embedded in it) and how it doesn't feel like a coherent product but a mashup of different bits and pieces, it is probably the closest you can find in open source for a RAD(-ish) C++ IDE (big caveat that i have only used it sparingly, never made anything more than a few toy apps with it). I am a bit worried that you're still relying on the Qt company which has shown hostility towards the open source community several times but i think that between Embarcadero and Qt company, relying on the latter is better and it is popular enough for external developers to pick it up in case it gets abandoned (the benefit of it being FLOSS).
But at the end i still think Lazarus is better when it comes to a RAD IDE and framework (i am taking all three of these combined, not separated) for desktop applications, assuming you do not mind using Free Pascal as the language. Of course that is with my big bias since i learned programming on Turbo Pascal, used Delphi in the 90s, use Lazarus since the 2000s and in recent years even contribute to its development. Someone starting nowadays will most likely have a harder time getting used to it and the documentation could certainly be better.