Development

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.

After a long time, I've released a new version of the Message Compiler Editor. This release comes with a setup and a help file. Only minor changes has been made to the editor, now comments are written to the message text file, the options dialog is shown before each compilation, and the OutputBase parameter is now supported. Manifest file are not supported - support is planned for version 3.
Message Compiler Editor is available here.

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:

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.

More and more in the past weeks while working with Delphi on the next release of out main applications, I started to ask myself if Delphi can still be considered an "enterprise" level development tool. Codegear's site says the "enterprise" features are:

While enabling a Delphi application to connect to its remote server using a TSocketConnection and not only a TDCOMConnection, I found ian ssue while I was returning Int64 data. It worked flawlessy via DCOM, but not via the easier-to-setup socket connection. What was happening? Well, in SConnect.pas there is this declaration:

VariantSize: array[0..varLongWord] of Word = (...)

It is used in TDataBlockInterpreter.ReadVariant() to get the data size to be read from the stream the socket connection uses to pass data around: