Delphi programming

When I wrote the QC entry about Datasnap 2010 HTTP client missing proxy support, I marked it as a bug. It was later changed by a sysop to an "enhancement request". That simple change shows why Delphi is in the actual state. It's a problem of mindset. Embarcadero people still lack the mindset to deliver applications made for the 2010s.

To this StackOverflow question, I simply answered to forget D2010 Datasnap because IMHO it is only half-backed and lacks several needed features and is not flexible. Two people commented my answer was not helpful, and wrote Datasnap is absolutely flexible (later one comment was withdrawn). I am going to explain in details why the "new" Datasnap is not a usable solution for remoting in Delphi, and while the "old", DCOM based one is under several aspects far more powerful although DCOM is a complex beast to use, and Delphi doesn't exploit its power fully.

I've complained a lot about the security (or better, lack of) of Datasnap 2010. The usual answer was that I was wrong, and anyway filters could be used to implement it. Now Bob Swart - who wrote the Delphi 2010 Datasnap white paper - filed two QC entries about Datasnap security. The first asking for HTTPS support, the other reporting a serious performance issue when using filters.

In the "global" market of today, with the Internet enabling you to sell you software everywhere in the world, you may think great care would be given to localization tools. Delphi ones reached a barely usable state in Delphi 7, and you may think BorCodeDero could only improve it since then. No. They did and still are doing the best to ensure Delphi can't localize applications by itself.

Lately I started to ask myself if all the cheerings about Embarcadero being the right home for Delphi were wrong. I do not mind they killed the CodeGear brand, I never believed in it. And being Italian, I have no problem to spell Embarcadero. I just feel almost nothing is changed from Borland days, and new issues look to arise.

In the last year often pop up articles, blog or forum posts (like this), asking for a very low cost of free edition of Delphi. Most of them build up a business case for the use they would made of it, although noone tries to build a business case for Embarcadero to demonstrate releasing a free edition is sutainable and won't impact revenues, or increases them. Let's analyze the motivations most advocates of a free release bring.

In these days I was working on tracking down a bug causing a service of ours to stop processing data. It didn't happen often, and was not simple to reproduce - it may take hours or days to appear, and was easir to see it on test/production machine than on my own development PC. Inspecting a system with SysInternals ProcessExplorer (after configuring it to download Windows symbols), showed in all processing threads a call stak like this:

In the past days I hit another DCOM issue: callbacks do not work if "Simple file sharing" is enabled (Settings → Control Panel → Folder Options → View). That's because the full name of that option is "Simple file sharing and ForceGuest". When enabled, Windows will ignore incoming calls credentials and will authenticate everybody as "guests".

While trying to undestand why a Delphi DCOM server was properly instantiated while set up to run as "launching user", but hung when run using "this user", I found out - comparing the setup on a machine where it works and one where it doesn't - that if the server exectable name is longer than eight character the server may get registered with a mix of long and short filenames in the registry.

In the past few days I had many troubles making our application work when the client was installed on a PC outside the application domain. It was due to several Delphi 2007 issues with DCOM.