Delphi 10.4.1 is an Inadequate, Last-Ditch Effort

I think this image metaphorically illustrates the situation surrounding Delphi 10.4.1. High-speed police chases… they happen basically every day. They all end the same.

The “bad guys” always seem to have such confidence when they are speeding down the highway at 90mph. Unfortunately for them, they are typically not looking into the sky, and therefore do not notice that they are royally f*cked by the chopper following them with infrared cameras. They also are unaware that the cops have already coordinated spike strips 10 blocks ahead, and they are about to lose their tires.

Arrogant and ignorant, they barrel on as-if they believe they can get away and evade judgement…

Of course, the spike strips hit their mark… causing their car to lose all traction, and it is only a few blocks later that they spin out of control. As-if they are 100% sure they’ll get away, they make one last ditch effort to lose the cops on foot, arrogantly believing that they can outrun police cars and police dogs and police helicopters… we all know how this ends…

This is basically where Delphi 10.4.1 is. They’re making a last-ditch effort to escape judgement. They’ve pulled their bullshit for decades. The neighborhood always knew there was some shady stuff happening on their corner. They eroded the trust of the community. The community has judged them and encircled them… yet here they are… hoping to climb over a fence, change their shirts, and get a chance to say “It wasn’t me, he went that-a-way!” One more chance… one more bug-riddled release… one more con, so that finally they’ll be able to get on a raft and escape to Cuba or something…

Delphi 10.4.1 Fixes a few problems. It makes an effort to fix the most Embarrassing broken “feature” of Delphi 10.4. I put “feature” in quotes because… really it was a bug fix that was 10 years over due that they sold us as a bill of goods. We of course bought it hoping that they finally fixed that bug…. but it wasn’t fixed… and now with 10.4.1 they wanted more money to “really” fix it. I’m of course speaking of the “code insight” bug fix.

In 10.4, Code Insight was (allegedly) finally updated to support language features added to Delphi in the last 10 years, but the implementation of it was horribly, horribly, broken at every turn. Maybe they should have been proper stewards of the product and upgraded it gradually over the years so they wouldn’t have a huge mess on their hands in 2020… but they didn’t. In fairness, I will say that Code Insight, on first glace, seems to finally work in 10.4.1 (yay.) But unless you have a support agreement, they’re trying to sell it to you — as-if fixing a bug that they said they fixed 6-months ago… that they should have fixed 10 years ago is a “new feature” or something!. And still…

Castalia drop-downs bust immediately upon writing code with new language features.

In typical Delphi fashion… they forgot this little thing, ripped from Castallia, which breaks IMMEDIATELY the first time you put any inline var declaration in any unit. For this reason, my boss has continued to veto our adoption of 10.4’s new language features. I don’t use these little drop-downs very often myself… but my boss uses them habitually. So for us… Delphi 10.4.1 is basically a no-go on the new language features introduced in the last several years.

But even if that little drop down worked, Embarcadero has still outright refused to fix (or completely ignored) major bugs, including a huge, critical bug relating to the declaration of records with inline var syntax. This IMO is the most major compiler bug existing in the last several releases… and the first thing I test when getting a new Delphi release.

As-if completely perverse, they are, all-the-while, trying to promote inline var records as a new, sellable feature to unsuspecting, trusting customers through blogs and marketing. This bug has been existed since the introduction of the inline var declaration… several versions back, and it results in seriously broken ASM code generation.

Good ASM generation of a record defined in a “classic” var section within a function

Shown above is an example of what should happen. This is the ASM that is generated if you declare a record inside a var declaration the way we’ve all done it for the last 25+ years. I declared TSomeRec (yellow box) before the first begin of my function. In this scenario, the compiler generates a call to @InitializeRecord. This is to make sure that any strings and dynamic arrays declared in the record are properly initialized to 0. If this is not called, there could be potentially anything in that memory. Delphi strings and dynamic arrays are essentially pointers.

If this memory is not 0, the first time you access that string or dynamic array will result in that pointer being chased, potentially crashing your program… or worse, trashing memory, corrupting data… you name it…. virtually anything can happen. If you are really really unlucky, it could even reformat your hard disk.

Bad ASM generation when records are used in an “inline var” declaration.

Above we can see that when the record is declared in an inline var style… the generated ASM code lacks a call to @InitializeRecord. I can verify that this is a big problem… that it crashes my apps if I don’t carefully avoid it… and I have been complaining about it for several releases now, filing multiple bug reports, and complaining about the treatment of the bug reports that already exist.

Delphi 10.4.1 is still not even close to a finished product. And the initiative to fix bugs and do well by customers is clearly still missing from the company. I’m sure there are a few really smart people over there. But I’m also convinced that those really smart people are also overworked and probably underpaid… and the rest of them are either not very smart, or not very motivated. Additionally, those who are setting the agenda don’t seem to have plotted a course to offering us a “complete” product. Honestly, maybe they need to have someone new setting the agenda over there. This tool suite needs help. It needs to be feature complete. It needs new controls, new APIs, fixed controls, fixed APIs, the latest platform support, including the latest platform features. I, for-one, had to hack the hell out of the FMX libraries to get proper stylus support for Android devices such as the “Galaxy Note” series of devices. I also had to build my own custom controls for things like TButton just to get proper multi-touch support in the Windows VCL. There are heaps of features and APIs horribly missing from Delphi. It barely seems to support TCP/IP anymore it seems… the Indy project is holding on by a thread with just one guy volunteering his time on github…. like.. if you were going to ever fund an open source project, fund Indy for god sake! Or at least fund a good replacement for it with all the proper protocols, security, and encryption that modern apps demand.

And what about the all the horrible coding practices that are encouraged by the fact that there’s no built-in framework for running your Business Logic in a non-gui thread (certainly it can be done, and I do this stuff using a host of inherited forms and classes, but come on… take some leadership and build some stuff into the VCL and FMX libraries to demonstrate some good coding practices around this stuff instead of just running SQL queries in TButton.OnClick events as-if this were 1995 or something. All the examples offered up over the last 20-years have been pretty janky…. a fish database lifted from Paradox tables in 1993… great in 1993, but not in 2020.

Regardless… we’re on this sinking ship… the lifeboats are gone… it’s been nice playing with you all… but this can’t keep going on the way it has been going…. once the ship sinks, we’re going to be stuck in the middle of the ocean without a lifeboat… not a great place to be. I’m hoping to do more C# work in the meantime so that I’m not completely skill-less when the time comes that support for this dead language is officially over.

I am not so narcissistic so as to promote my own blog on social media. So if you’d like other people to read this blog, please share it wherever you share stuff.

2 Replies to “Delphi 10.4.1 is an Inadequate, Last-Ditch Effort”

  1. Yep Delphi features and bugs are pretty nasty and historical gui/business logic mixing is bad, we’re stuck with all of that for the moment though but the problems push up the case for a replacement more and more.

    Code insight still doesn’t work for me with 10.4.1 most of the time – it appears to work on small projects. I can’t remember if it’s worked alright for any of the 10.xx series.

    Very frustrating that we need to deliberately avoid Delphi libraries (TCP, JSON, threading….) as the problems we’ve encountered are so numerous.

    1. It’s like watching a trainwreck, huh? The persistence of these bugs feels almost deliberate at this point. Have you found any workarounds for the code insight issue, or are you just living with it?

      @Rinzwind: I feel that pain too, Big Brain or not. You’re spot on about companies needing to bail on Embarcadero. FreePascal and Lazarus have been pretty stable for me. Anyone else jumping ship?

  2. Funny how Big Brain was mentioned in a blog post about dev c++, but only once. Maybe to do with this 😉

    They really should value expert opinions and work with you instead of against you. Im having the suspicion the only reason Embarcadero publishes Delphi is because they know its a sinking ship and dont want to fix it and just squeeze more and ore money out of vintage solutions/companies/programmers. Object Pascal deserves better than this. I would say: screw Embarcadero and go support FreePascal. If every company invested in Delphi starts supporting Lazarus youll get somewhere…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.