Tea Leaves for 64-bit Delphi

Your reviewer was looking at the KSDev purchase and thinking...


Pesky 32-bit assembly and legacy issues.The whole VCL is peppered with 32-bit legacy code, some going even back to 16-bits, such as aliases for WinProcs, WinTypes.


Judging from the last version of KSDEV library before Eugene pulled it from his website, the latest XE codes with some unusual 64-bit codes, some parts of the Embarcadero wiki before they removed it from public view.


Here is your reviewer's take about the current state of Delphi/64.Delphi 64-bits requires a full compiler rewrite. That means, only the language stays the same, everything else doesn't matter.


For example, if the definition of "program", "for", "if", "while", "being", "end" stays the same or similar, it is considered Delphi or Pascal language.


In a liberal sense, that is how RemObjects does it: With RemObjects Prism, the NET library is the main library instead of VCL, there are compatible constructs to make porting code from Delphi/Win32 to NET/Prism.


In order to code for Delphi 64, the whole entire VCL needs to be re-written to first remove the assembly parts and make it as "compiler magic" or in-line assembly routines that is linked to the final 64-bit EXE file.


The first part is easy. Making equivalents to the original Delphi/Pascal codes: Go back a few versions where the IntToStr, and other routines were not converted assembly and use the original codes.


The second part is not-so-easy: The Delphi VCL is limited to Win32 only and nothing for Mac or Linux.


The trick is to make the final result language compatible. Remember the QT/Kylix library, where the Delphi 6/7 had an alternate implementation called QT(whatever).


QT and WxWidget are both respectable libraries, except the fact that the Borland C++ compiler is so far "out of the C++ loop" that it could never hope to have the same respect Microsoft Visual 2008, 2010, Intel C++, GCC and Digital Mars C++ compiler have today.


C++ Builder XE
Talking about C++ Builder is like talking about an athlete who claims it is the "best", won many former awards, with lots of boasting, pomp and grandeur - because of the corporate sponsor decided to stop the athlete from training, making it fat and lazy. The corporate sponsors then decided to silenced the critics by threatening NDA or humiliating them publicly.


In the past 10 or so years, there were certain critics who went to presentations with floating point performance reviews but was stopped last minute because of NDA or Borland threatened lawsuits at them. Some of the critics were so vocal and so disappointed about it, many of them are University professors -- they went and subsequently switch from Delphi to Visual Studio for their teaching syllabus and never looked back.


(To rub insult to injury, C++ builder is almost 90% slower than Visual C++ or even Intel C++ compiler. You can find out easily by running SpecInt, LinPack or the recently compatible Crypto Library to find your own conclusions.)


In relation to QT and WxWidget, there is no or very little documentation about QT for C++ Builder 2010/XE or even WxWidget for C++ Builder 2010/XE.


After heckling with trying to get WxWidget or QT to compile, developers face Interesting problems with C++ Builder: Intellisense sucks, very long compile times, even longer than Visual Studio or Intel C++ compiler, inability to compile code that compiles with Visual Studio/GCC/ICC.


What your reviewer thinks about Delphi XE2 (Delphi Exorcist Edition II)Delphi 32-bit version would have a new VCL library called the UCL library along with the current VCL side-by-side.


In order to make a 64-bit EXE file, the person would have to use UCL exclusively.


Remember how Kylix did it? They had pascal files with QT(whatever) and since Borland could not control the language or state of QT includes, it lead to three completely unusable versions of Kylix.


Since UCL would be cross-platform, it meant instead of TButton, the person would have to re-code their application to use UForm, UButton, URadioButton, UGrid, then to stop the users from doing stupid things, like screwing up the 64-bit registers or doing stupid 32-bit tricks (such as modifying the ES:DI) or the usual assembly code that peppers a VCL application.


The no-assembly issue would make sense. For instance, OSX 64-bit calling conventions or memory management is completely different from Win32 memory management.


Kryukov Software DevelopmentThis would make Mr. Eugene Kryukov, founder of Kryukov Software Development (or KSDEV) very happy person. For many years, the KSDEV VCL libraries does not have a good report writer, good grid and good edit controls. You can be sure DevExpress, Nevrona, Report Builder, LMD, TMS would then make superb components (each sold separately, like toys) built on-top of Eugene's components.


Since the most popular cross-platform libraries would not be used (because of C++ builder issues, GPL licensing issues), Embarcadero decided to use KSDEV because it Mr. Eugene Kryukov was the last person who knew how to write a cross-platform component library and cheap enough for Embarcadero to buy over.


DevExpress is estimated to be worth at least US$20 million, almost the same price as Embarcadero Delphi purchase, making it too expensive for Embarcadero to buy over.


How did Borland value Delphi at almost 70% less than the original US$100 million it sought, when it sold to Embarcadero? The answer itself lies in the way how Borland treated it customers and those on the newsgroup alike: Very shabbily, ignoring complaints and enforcing a SA-damn subscription or annual Delphi updates and payments.

Delphi's Last StandEmbarcadero promises 1st half of 2011 to deliver a working 64-bit compiler. Will they deliver? If the momentum to port Delphi codes to NET, C#, C++ and leave Delphi continues, and they still don't have a working usable 64-bit compiler and library anytime soon, it will be game-over.


It will be game-over because the new Delphi/64 will come with a new UCL component library and everything needs to be rewritten for it to be compatible with Delphi/64. That means -- other component vendors, if they are not in good graces or fell out with Embarcadero (like leaking out Delphi 2010, Delphi 2009 beta builds or uploading Delphi beta builds to chinese FTP sites) will be in for a big surprise.


Those hardest hit will be the component vendors because they need to rewrite their codes to be UCL compatible, the report writer guys need to update the libraries to 64-bit compatible, the grid guy needs to update the grid, the database guy needs to update their database-code and so on...


Those programs which contain custom components needs to be upgraded too, don't forget. Those old libraries which are still used, but the vendor went out of business, they will not be compatible and need significant porting effort to make them work with 64-bits (like making TurboPower Abbrevia, TurboPower Opherus UCL compatible).


Unless you patched KSDEV code before, or posted heavily on KSDEV forum formerly about issues and advised on work-arounds, or wrote Delphi components..., it is going to be tough work doing the code migration...


Most of the Delphi developers don't reach this level because they are so lazy and just buy one component pack after another to solve their problems...


Then, there are the usual gang of idiots who uses warez and pirated cracks, hacks and Delphi-Lovers who use all pirated crap to avoid paying for their libraries. Those people will really feel "Delphi-Love", when, the company went out business, they used a cracked or hacked version of their VCL products and will soon start begging for a non-existent 64-bit version of the same VCL codes. This will become reality soon.

Please see article Tea Leaves for 64-bit Delphi Part 2

:)