One of the features that bites me over and over again is the ZEROBASEDSTRINGS that got introduced in Delphi XE3 and is by default ON in mobile compilers and OFF in Desktop compilers.
Back then, Mark Edington showed a small example of the effects:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
The XE3 RTL source code has been refactored to be string index base agnostic. In most cases this is done by utilizing string helper functions which are always zero based.
When it is necessary to traverse a string, the Char[] property is often used to access the individual characters without concern for the current state of the compiler with respect to zero based strings.
In addition, the “Low” and “High” standard functions can now be passed a string variable to provide further flexibility as needed.
When zero based strings are enabled, Low(string) will return 0, otherwise it will return 1. Likewise, High() returns a bounds adjusted length variation.
The problem is the non-existent forward compatibility of the other compilers (Delphi XE2 and lower).
So if you have library code that needs to work in Delphi versions, you cannot use the High and Low to make the code ZEROBASEDSTRINGS neutral.
Many Delphi developers regularly skip many Delphi versions, so these are still popular:
Delphi XE1 and XE2 (the last 2 compilers before Delphi really started to support mobile)
Delphi 2007 (the last non-Unicode Delphi compiler)
Delphi 7 (the last non-Galileo IDE)
The result is that library code is full of conditionan IF/IFDEF blocks like these:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Using Delphi build-events (see my post Delphi prebuild/prelink/postbuild events), you can automate the process of signing your Delphi executables with a digital certificate.
Below the steps for signing Windows executables.
Prerequisites:
You have your digital certificate in a PFX file.
(for testing you can use a self-signed certificate, for the real world you want a certificate leads to a CA).
But even if you go without that extra base class the cool thing is that you don’t need to restrict your classes to be a TInterfacedObject but specify the interface they need to implement (yay, compiletime type safety) and then you can get rid of the Supports call and directly assign the result of the ctor call to the sut variable.
Before Delphi 2007, you had to fiddler with project groups and dependencies to fake pre-build and post-build events. For an example see Pre and Post-Build Automation in Delphi.
I was creating installation instructions for getting new development machines set-up
The new machines had to either have a minimum subset of installed Delphi versions + components, or the maximum superset of all the existing development machines
Sifting through the installed Packages in the IDE, or registry by hand was cumbersome