Wednesday, December 11, 2013

Modernize your codebase: Inspiration to Ditch your Ancient Delphi Version

I still see a lot of people running old versions of Delphi, the most common one people freeze at is Delphi 2007, because of the Unicode changes to String types, but I have also seen the odd one stick at Delphi 7, or even Delphi 6.

Here are some suggestions on getting out of those Don't-Upgrade-Ever Tar-Pits.

1.  You may lack motivation. You may not realize how much you need a modern Unicode String type.  You start by believing you can upgrade your AnsiString-forever, or shortstring-forever codebase. Yes, yes you can.  The internet is Unicode, and every computer is connected to the Internet 24/7.  WideString is not enough.  The modern String (UnicodeString) in Delphi is fast, flexible, and internet ready.   I've spoken to people who aren't upgrading because they assume the new String is slower. On some benchmark code (Sieve of Eratosthenes and some string crunching code), the latest Delphi XE5 is actually faster at UnicodeString (String) operations than Delphi 7 was at AnsiString (String) operations, and basic IntToStr and StrToInt functions.

2. Upgrade for Productivity boosts. The IDE INSIGHT feature is fantastic.  Once you get used to it, I find it hard to use a version of Delphi that lacks it.  It's google for your IDE.       I like to supplement it with the GExperts file open dialog, but the combination of the two is magic.

3.  You've been down the Ancient Delphi Codebase road, and you know what a pain things like Z-Order bugs are.  If it helps you decide to move up,  remind yourself that the VCL in 2007 and later supports proper Z-Order parenting, so if you're on Delphi 6, or 7, it's time to say goodbye to silly Z-Order bugs. (Window A behind Window B).  If your code is not Unicode ready yet, you can get XE5, and it will entitle you to a Delphi 2007 license (previous versions access), get your Z-Order bugs fixed, then continue to work towards proper modern Unicode readiness in your codebase.

4. Maybe you don't really need 64 bit Delphi, but having the possibility open sure is good, right?  Or maybe you would like to build something 64 bit? Running Windows 64 bit? Want to access lots of memory? Want to write a shell extension?  32 bit may be great for lots of things, but having 64 bit in your bag of tricks is worthwhile.  64 bit Windows will be so mainstream eventually that (like Unicode) the whole Delphi world will eventually move to it, and Win32 will eventually fade away. Yes. Yes, it will.  Do you still want to be building Win32 apps when Win32 goes the way of Win16? Remember NTVDM? WOW is the new NTVDM. It isn't where you want your apps to live, is it? Inside the backwards-compatibility box?  So be ready.

5.  Mac OS X support. You can write apps for OS X with Firemonkey.  Maybe this isn't a "need" thing, but it's nice to have in your tool-belt.    Being on a modern Delphi version means having this around when you want it.

6.  iOS support.  You can write native iPhone apps with either RAD Studio XE 5 or Delphi XE5 + the mobile add-on.   Your kids will think you're cool, if you make them a little App for Christmas. Right? Of course right.

7. Android support.  You can write Android apps using the Delphi compiler for native ARM and Android NDK.  

8.  If you're stuck on a version prior to 2010 you don't have proper platform support for Windows 7, and Windows 8.  Things like the file-open dialogs, etc, changed at the Vista level, and that support was never in Delphi 6,7 or 2007.  I think it's kind of funny that Delphi grew proper Glass (DWM) support, and then Microsoft suddenly yanked Glass out of windows 8.  But maybe it will come back in Windows 8.2.  You think?  Anyways, the core VCL on modern versions like Delphi XE5 is a lot less painful to support Windows 7, 8, and 8.1 on, than the creaky old version you're using, if your version is older than, say Delphi XE.

9. VCL styles.  This is an amazing way to add a "face lift" to your VCL application without rewriting it.  There is a bit of work involved, but a lot less than you'd think.   The amazing third-party add ons like RRUZ's awesome helper library make it easy to make your VCL app look great.  If you haven't got at least Delphi XE2, you don't have this great feature.  To go with that pretty Style support, add some VCL gesture support.  Support touch gestures on a  touch-screen laptop or Windows Surface Pro tablet, using VCL gestures. Swipe, pinch, or make your own custom touch gestures.  Combine this with the VCL styles and you can modernize your look, and functionality from "90s" to "up to date" pretty quickly for your core Win32 desktop apps.

10.  Delphi Language Evolution. If you're still on Delphi 6 or  7, and you don't have Generics, or modern RTTI, or the new module grouped-naming system (Unit Scopes), you might be surprised how much nicer and more readable these things make your code. For example, I love my Uses clauses to be grouped with all the System units first, then VCL units, then my third-party library units. The ones that have no dots in the namespace are either primitive third party libraries, or my own units. It's amazing how convenient and nice and "expressive" these longer names are. I love them.

I hope this list gives someone the motivation they need to kick themselves in their own butts and get their codebases out of Delphi versions that should be retired, and moved onto a modern Delphi version.  You'll thank me.

Oh. And how do you actually DO it when you get the nerve?  I'll write more about that later.   But for starters, I suggest you try to write some Unit Tests.  Remember that while you are in progress of modernizing your codebase, you can do it without ever breaking your application or introducing unknown behaviour.  I'll write more about that approach, in an upcoming post.


Update:  If someone is sceptical about the value of updating, I ask them, what does it hurt to download the trial and try it?   You can do almost anything you want to try with the demo version, get your code mostly ported, try to port your components up,  get stuck, and post questions on StackOverflow. If you really love Delphi 7, great. It was a great version.  Enjoy it until the heat death of the universe, or at least, until the sun goes super-nova. No problem.  But most of us moved on long ago, and I just wanted to let you know why we did.

21 comments:

  1. (Point) 10 was what used to drive me nuts, while working somewhere that would not upgrade from Delphi 7, especially when I had my own (at that time) Delphi 2010 license. I rewrote my PF using generics from the D7 version and it was so much cleaner. RTTI and custom attributes would also have been a great help in their codebase. But sometimes you are just not given a choice, so in the end I left...

    ReplyDelete
  2. This is the synopsis my clients have been waiting for. Excellent work, Thank you!

    ReplyDelete
  3. As a hobby programmer, I don't need to make money with this product but love to use it, hence I still use Delphi 2009. I've ordered D2009 because it was the first version to support Unicode natively.

    So far the current (Euro) price while upgrading to XE5, Professional, btw, and the need to upgrade several libraries like TMS Component Pack (license already ran out) or Absolute DB, holds me from upgrading to XE5.

    ReplyDelete
  4. From your blog earlier this year...

    http://delphicodemonkey.blogspot.com/2013/04/hey-marco-heres-how-to-fix-delphi-make.html

    Have any or all of the points you raised been addressed with XE5?

    ReplyDelete
  5. I'm going to benchmark XE5 using the "no waiting" rules I mentioned in that post. If it's broken, I'm going to make a reproducible example available to Embarcadero. Because I believe everything I said in that post. No they haven't ditched the Document Explorer yet. The online help is slower than just using the docwiki, but here's the thing; Even with those complaints, XE5 is still the fastest, and best IDE for Delphi developers that I have yet used. Incidentally, I have some more things to say about those freeze-ups and what to do about them, until then. Stay "tooned", okay?

    ReplyDelete
    Replies
    1. >XE5 is still the fastest, and best IDE for Delphi developers that I have yet used.

      Isn't that sort of a back-handed compliment, since we're locked into using the provided IDE? LIke VCL and FireMonkey being two of the best frameworks for Delphi? :-)

      Or perhaps you mean it's the best version of the IDE yet. But even then, as someone reminded me in an argument we were having about the state of documentation for a product, being better than other products isn't the same as being objectively good. Unless we're giving up, Delphi isn't just competing against its last version. It's competing against a host of other products and Visual Studio, IntelliJ, Eclipse and other IDEs. Contrary to what an Embarcadero marketer suggested a few months ago, Delphi users aren't locked into Delphi forever and someone looking to incur the financial and time costs of advancing their code base to a new version of Delphi may look into other platforms for new development work as well. We can't just be "better than Delphi 7", we need to be "better than Visual Studio" or IntelliJ. FireMonkey doesn't just need to meet or exceed VCL, it has to surpass Qt, etc.

      Delete
  6. No it's not a back handed compliment. What I mean is that (A) Delphi is the best language I've ever used, and the best IDE, and that (B) XE5 is the best version of it that I have ever used.

    It would be sort of like saying "If you like Delphi, and you like Delphi 7, you would probably like XE5 even more, once you get over the unicode and component migration hurdles".

    W

    ReplyDelete
    Replies
    1. >What I mean is that (A) Delphi is the best language I've ever used, and the
      >best IDE, and that (B) XE5 is the best version of it that I have ever used.

      Are you interested in writing some blog posts illustrating in detail where Delphi surpasses the other languages you've used, how Delphi is superior to IntelliJ and Eclipse and VS, etc.?

      Delete
    2. Essentially, I have already, I think. Delphi has three unique strengths; The designtime+runtime component model including its absolutely unparallelled designtime capabilities, the object pascal language itself, and the framework (VCL). If your job is to write Windows applications, there is nothing better. If your job is to write Web Services for a Bank, maybe you would find Java + IntelliJ works better for you. If your job is to write web-apps you might find Notepad (or Visual Studio) and JavaScript, more up your alley.

      Delete
    3. Warren, that's the thing.

      > the object pascal language itself, and the framework (VCL).... If your
      >job is to write Windows applications, there is nothing better.

      I haven't seen a comparison of the VCL to the standard libraries of Java and .NET since their very beginnings; highlighting specific functions/capabilities that you believe superior would be very informative.

      And as for the language - obviously given the market share that would be considered an "extraordinary claim" by most of the rest of the development community. And if we're honest we must admit that Delphi lacks many modern concepts such as memory management and operator overloading of classes (on desktop), list comprehensions, type inference, design by contract, lambda, tuples, etc. If you believe there are still specific language features of Delphi that are superior to the Big Three, that would be a fantastic article and arguably the most important Delphi blog posts to exist in the last several years! It would draw some attention to Delphi and accomplish what EMBT's own marketing honestly doesn't even try to attempt.

      I obviously can't make you write something like that :-), but I feel that an honest comparison of the *specific* features/constructs of Delphi to at least the Big Three (C++. C#. Java) and maybe on the RAD end Python or Ruby and on the GUI framework side Qt would be fascinating.

      Delete
    4. Alcade; Name me one technology or tool that in your mind is suitable for building applications on Windows, and I'll tell you if I've used it, and what I think is wrong with it. Java is a horror, a monstrosity. I hate garbage collection, I hate hate hate the Java libraries. I think Intelli-J, however, and the Java ecosystem are amazing, it's just sad that it's built on top of a pile of rubbish (the JVM). Python is an amazing language for open source applications and scripts and is completely inappropriate for commercial line of business applications on Windows. C# is fine if you're making a shopping list application for your grandmother or so called "Enterprise" database applications, which are frankly, not a very demanding thing. The only other language out there that can touch Delphi for Windows development is C++, and C++ is a horrific over-complicated mess. That's the short short version.

      Delete
  7. Well, sometimes you just do not need newer Delphi version. Honestly I am feeling that after Delphi 7 most of the features are half-baked(Generics) or overbloated (new RTTI).

    Just not to mention a mess introduced to RTL because of iOS and Android support.

    You can still create amazing applications in Delphi 7: http://tower22.blogspot.com/2010/01/movies.html

    ReplyDelete
    Replies
    1. I read C++ there. Is a real delphi 7 app? What engine is using?

      Delete
  8. Upgradeing OwnerDraw code, can realy be a hurdle :(

    ReplyDelete
  9. Esmar : OwnerDraw code usually should rely only on TCanvas, which has a very stable api! If that OwnerDraw code is hard to upgrade, it needs to be ditched and redone properly!

    ReplyDelete
  10. I have been using Delphi since version 1. I am aware of the several issues around. But seems that it is related mostly on how the program was created. In my case I mantain a half million lines code with no problem. I was stuck on delphi 6 for many years, afraid of moving on. Then I bring it with a lot of difficulties to XE2, after some months it was fantastic! XE2 is stable (sp4) and few issues. But my code permit that... Now I moved to XE5, mostly because I was using Windows XP with XE2 and wanted to get better performance on my VM. What a good thing I made!!!! In windows 8 and XE5 (sp2) it works fast and nice.

    I am so used to have problems with so many software that many little problems can be solved or turned around. I came from a background of the first CPM computer where everything was just wild.

    People complain just too much. Of course better quality is always welcomed.

    But I see that XE5 is valueable for those that are using old delphi versions.

    ReplyDelete
  11. This comment has been removed by a blog administrator.

    ReplyDelete
  12. I have upgraded from 2007 to XE6 and have to say, 2007 is still the best version.

    I need my apps to behave the same wherever they are operated in the world, that means Ansi strings, decimal points (not commas) and date times always formatted the same. XE6 manages to screw them all up.

    Yes WIndows may be Unicode, but windows interfacing is less than one percent of what my apps do. My apps need to talk to machines, devices through LAN and dedicated hardware and they all want to talk in 7 bit ASCII. XE6 Ansi string support is terrible, no Ansi stringlists, no Ansi numeric conversion routines.

    Seriously, what was going through the programmers heads when they did this conversion?

    I think very little was going on in their heads, its this kind of thoughtlessness that kills off programming systems.




    ReplyDelete
    Replies
    1. >I need my apps to behave the same wherever they are operated in the
      >world

      Shouldn't your apps behave according to the preferences the user has set in the operating system? Why would you override user preferences? Moreso, why would users let you?

      >My apps need to talk to machines, devices through LAN and dedicated
      >hardware and they all want to talk in 7 bit ASCII.

      And unfortunately you want to talk to them with strings because Delphi never made clear the distinction between bytes and characters. These devices speak in bytes, not characters. On the other hand, you're using strings because Delphi also never gave users a simple and powerful structure to deal with bytes ("Array of byte" is not it). What you need to demand from Embarcadero is a new data structure to deal with bytes, not the preservation of many string types and the confusion that causes.

      What Delphi needs is one string type, Unicode encoding/decoding at the edges only ("What encoding is this string?" is a meaningless question as bytes <> characters), but an addition of a bytearray type to make working with bytes easier. Python's bytearray type should be the model, as based on long discussions at the Delphi forum it's most similar to what users want. It has most of the properties of a string along with several of a list.

      In [1]: test = bytearray(b'Warren')


      In [3]: len(test)
      Out[3]: 6

      In [4]: test[0]
      Out[4]: 87

      In [5]: test2 = bytearray(b'Delphi')

      In [7]: test3 = test + test2

      In [10]: test3.replace(b'e', b'7')
      Out[10]: bytearray(b'Warr7nD7lphi')

      Delete
    2. No they absolutely shouldn't behave differently in different locals, tha'ts a crazy idea. Imagine what would happen to your pascal code if it interpreted differently in every country ? It just wouldn't work.

      and machines work with ASCII strings terminated by a cr and/or lf and these instruments have to work the same in every country. I can create code easily with delphi 2007 to do this, XE is a complete nightmare to do the same job.

      Its just a crazy idea, to have information corrupted by the local, completely nonsense. Instrumentation use the same control language structures wherever they are used in the world. Numerical formats are standardised.

      The windows platform has become the standard for engineering business and systems, its the defacto standard embedded RTOS in most equipment, and the hardware all talks to each other in ASCII strings, not unicode.

      I can't understand why embarcadero have not even provided the basic numeric conversion routines for Ansi strings and made the stringlists so slow and inefficient for Ansi text, when I load a 100Mb text file, I don't need it to consume 200Mb of memory.

      Surely it would not be so difficult to cater for those who need to use Ansi strings? I mean they already had the code to do it in 2007, I don't really care whether Unicode is used or not for VCL controls, as I said before, user GUI is just a minor part of applications.




      Delete