Monday, January 7, 2008

A new year and a fresh start

I've been wrestling throughout the past week with what direction I should be taking this blog in the coming year.  There's a lot of cool stuff coming down the pike for Delphi & C++Builder. I'm just not sure where to start.  There are all the Unicode changes, parameterized types (Generics) for Win32, some VCL enhancements, a Delphi Parallel Library (DPL) and some others that I just cannot talk about.

So, where should I start?  The Delphi Parallel Library stuff is cool and fascinating.  Information to prepare for the transition to Unicode is also important.  So what do you think?  Let's just make this post the official "suggestion box."  I cannot promise I'll cover or answer your question since it also has to pique my interest :-).

 Oh, BTW, the DPL stuff... I just made up that moniker.  This is no official announcement.


  1. Allen,
    please would you give out some information about the new Unicode stuff (e.g. String becomes a UTF16 Unicode string, .....), migration hints, etc.

    Delphi Parallel Library (DPL). Sounds very exiting! My dual core cpu is waiting... :-)

  2. Allen, tell us more about parameterized types and it's implementme chanism please ...

  3. Andreas Hausladen wrote a very interesting langange enhancement for Delphi:

    What features can we see in the near future?

    -File Macros
    -Extended for-in loop
    -Generics for Delphi
    -Multiline Strings

  4. I vote for DPL

  5. I definitely vote for DPL, been waiting a long time for something like that, as I've been using dual processor machines since NT days.

  6. I'm practically salivating to get Unicode support in the VCL, so I wouldn't be disappointed if you started there :)

  7. I wouldn't mind seeing some "teaser" posts about changes we can expect to see in the IDE and VCL. Short, sweet and easy to digest.

  8. The biggest thing for me will be Generics. I've been hollering for that since Delphi 2!!!!

    Multithreaded applications? My applications are end user apps. Multithreading doesn't help much. And where it can, I use a TThread object.

    Unicode? Ok, some use here, but I still need to translate into other languages. At least the UI will handle it transparently now.

  9. 1. DPL,
    2. VCL Enhacements
    3. Generics
    4. the others, you can't talk about. :D.
    5. IDE Enhacements
    6. Debugger enhacements

    Maybe I want to pop the 4, and insert it before 1.

  10. Hi Allen, very good news, DPL and unicode sounds cool, what about the VCL enhances like Ribbon, Theme or skinned application.


  11. Whether the VCL has rewrited with generics?

  12. DPL then Unicode get my vote :)

    Looking forward to your comments; they're always worth waiting for.

  13. Hi Allen,

    I’ve enjoyed the posts you have done regarding DPL, but what I am really interested in is what is in store for the VCL. Frankly, the framework has not kept up and many common control features introduced in Windows XP are still not there, almost seven years later. And many are small – edit banners, balloon tips and the like. Also, the ribbon control was mentioned once long ago (by Nick, I think) and never mentioned again. Then there is the TDBGrid, which still looks like a Win3.1 control. It needs much more work, but a simple re-skinning with support for checkboxes will do wonders.

    Without some of this getting attention, I’m afraid that Unicode, DPL and 64-bit will allow creation of more sophisticated apps – that still look and feel outdated.

  14. DPL, Multithreading, 64-bit stuff. Please.

  15. I totally agree with Cobus. VCL needs a lot of improvments and this is an argument for me to buy new version. For a long time there was not significant progress. And customers look for nice and modern design.

  16. I'd be mostly interested in generics, collections, etc...

  17. I would like to know if there are plans to remove .NET dependencies from the IDE.

  18. Definitely DPL !!!

  19. Unicode changes.

  20. parameterized types (Generics) for Win32.

  21. I'd like to know about Unicode & existing applications, I'm sure compatibility will be great, but my concern is memory requirements, as I use strings & TStringList's, etc. extensively in Parsers, etc. that have no need to Unicode (as it's all internal).

    So suddenly having my string data requiring double the amount of memory for the same application is a bit worrysome - memory consumption was one of the things that made Delphi Win32 better than dotNET but now some of that advantage will be taken away - I wish the Unicode stuff can be implemented in some way without taking away the main advantage of AnsiStrings, i.e. memory consumption... and I'm sure processing Unicode (2 bytes per char) might have an extra speed penalty too compared to Ansistrings (1 byte per char) so some applications will become slower and require more memory for no visible gain (esp. more painful if that application is in no need for Unicode - like an internal parser, or a TStringList of english words, or keywords, etc.)

    So hope the right balance can be reached in the Unicode implementation?

  22. Move DataSnap further. We need a new multitier framework, without COM, for VCL AND VCL.NET.
    I'd like to see Andreas Hausladen's DLangExtensios implemented too.

  23. One thing that I would love to see is some kind of new feature that makes it more easy to create and work with rich graphic applications in Delphi. The standards on how a program should look and feel today has taken another level with the release of Vista and Delphi isnt a very good tool to make good- looking SMALL applications if you use a lot of images,icons and skin parts in your application.

    My suggestion is some kind of complement to the ImageLists. The VCL components that currently use ImageLists (ActionList, Toolbars etc etc) should introduce a new property called ResourceStore or something. ResourceStores are application global and maps to the EXE resources and can contain all kinds of resources.
    Each Action then has a new property called "ResImage" (string) that together with the selected ResourceStore on the ActionList tells the component where to find the image. Then we create a nice editor for the resourcestore where you easily can add/remove resource objects.
    This is just a very short note of how I think this should work. I actually started the design of this but realized that it would never really be of any help if it wasnt implemented into the "in-the-box" VCL components.

    Depricate the use of imagelist in VCL components and create something that aims higher for the entire applications graphic handling.

  24. Unicode, definitely.

    DPL is certainly more interesting and fun to play with, but it should be relatively easy to incrementally add support for it. For those of us who need Unicode we're already using TNT, and my own company is using UTF-8 strings everywhere to get around WideString's lack of reference counting. What, if anything, can we preemptively do to ease the transition?

  25. I'm getting more and more requirements to interface with .NET code. The biggest problem I have is with data types not matching up. Floats for instance. This makes it difficult to seamlessly integrate their dll into my Delphi app, which in turn forces me toward .NET (kicking and screaming).

  26. DPL, then unicode would be my preferences, but I find Magnus' suggestion intriguing.

  27. DPL! (didn't know you guys were already dealing with this stuff)

  28. parameterized types (Generics) for Win32!!!
    Delphi Parallel Library (DPL)!!!

  29. I'm glad to hear new features are firming up.

    My concerns are more along the lines of "how do I take advantage of this without starting a new application"?

    Tiny greenfield apps are great for examples and understanding, but I'd sure like to be able to take advantage of some of this right away.

    That said:
    Impacts of Unicode - do we have a choice to make?
    VCL improvements - especially for Win32 applications
    DPL - implications for client side and server side applications

  30. If you can't tell us about new stuff then please tell us about the past, because then we can better understand the upcoming changes.

    How does (or did) CodeGear (R&D) use source control?

  31. Hi,

    I'd like to hear more about DPL.
    Are you gonna add it to next Delphi release? I hope so!

  32. Hi there Allen,

    My first choice is DPL. I've read a lot of posts/rants about the average programmer not being able to understand how to use the multi processor CPU's that are getting so common. This is a very good start to get everybody in the loop.

    My second choice would be Unicode. Currently I'm residing in the UK, this would mean that the Unicode would not be in my radar... Wrong! I've just stumble upon a major problem on my day job with PHP: Copy/Paste from Word messes up the " and ' in non Unicode systems, so I'm supposing it would do the same to any text box from Delphi.

    Third choice is VCL enhancements. The only thing that does not make me up this to second is the reason I stated there.
    But my main concern about VCL is that the framework is really showing it's age in the graphic landscape. We need a better looking set of components, even if they maintain their actual functionalities, witch are still up to date, in my opinion.

    My last request is that some of the DLang stuff gets into Delphi. Lets face it, Delphi is the ONLY Win32, Native option to speedy apps, so why the hell is it not trying to interest more programmer that have some experience on scripting languages?!?!?
    C'mon, the case-string-of is quite easy to implement and would be a killer by itself, so why delay it then?
    Even .Net has multi line strings, is that so hard to introduce in Delphi?!?!?
    Hoping that someone sees the light at CG and gives some of the DLang stuff a thorough analysis.

    Gustavo Carreno

  33. Please talk about Unicode changes ^^)

    First, I hope there is a new function mapping technique for Ansi/Wide-transaction. For instance, CreateUrlCacheEntry can be mapped to CreateUrlCacheEntryW, when string=Widestring.

    The second thing is the performance between Ansistring and Widestring. Currently Widestring is extremely slower than Ansistring. I hope in next version, this difference can be minimized.

    The third thing is about BSTR and Widestring. It will be great, when Widestring and BSTR become two different types. (And provide some convert-routines)

    The fourth thing is a tool to check, whether there are some Ansi-version data types defined in a Wide-version functions.

    Thanks and look forward to your articles.

  34. Unicode.
    Generics and its use in VCL (New collection framwork? New databinding?)
    MDA future (in D2006 times it was declared as mainstream...)

  35. 1. Unicode
    2. skinning on the VCL, and
    3. PNG support on the Canvas, TImageList and etc. new application (especialy vista applications) are all now using anti-alias/alpha-blending on their graphics image.

  36. 1. As mentioned several times, the VCL clearly shows its age. Using GDI+ instead of GDI would possibly be a good start (antialiasing). Everything looks definitely nicer on .NET (WinForms or XAML).
    TDbGrid looks also pretty outdated and something more DevExpress-like (with fancy editors) would be great.

    2. Unicode is a must-have for me.

    3. Parameterized types (generics) is also a must-have for me.

    4. Threadsafe VCL would be cool too.

  37. just wanna rephrase my post before this...
    we need a nice GUI!!! :) at least the end-user out there can easily differentiate which applications are built using delphi/c++ builder or other language.

  38. +1 for unicode, please!

  39. I guess, all of them are intresting, but Unicode is the most important because insight there could allow to start the preparations for migration when available.

    1. Unicode
    5. VCL improvements
    6. Generics
    7. secret stuff :)
    8. DPL

  40. D2007, we were told, is a "non-breaking" update. So the next version, I assume, WILL be a "breaking" update?

    What caveats should we be looking out for so's not to program something that won't work in the next compiler.

  41. Please improve VCL. Current state is unchanged for a couple of years (GDI+, modern panels, tabs, grids, skins, ...). Visual face with pleasant user control helps to sell application.

  42. Hi,

    -Record destructor
    -FP Optimization
    -Int64 Optimization
    -64 bit compiler (Just a compiler without VCL will do)

    Unicode VCL sounds good, but that should have happened few years ago.
    DPL sounds too much like an M$ buzz word to be good, better, give us record destructor
    so we can make some nice things too. Operator overloading can’t be useful in many places,
    especially if you don’t have a destructor. Compiler should finalize only those which don’t have one.

    So, my vote (in case you did not notice) goes to Record destructor.

  43. Please make the VCL catch C++ exceptions!
    (Look here for a possible implementation:

  44. Please extend VCL.NET support to run on the Compact Framework. I'd also like the idea of a TAction-based ribbon control built into the standard VCL.

  45. 1. UNICODE
    2. Kylix 2008

  46. I've been writing multi-threaded apps for a while - curious to see what DPL is all about!

  47. 1. Kylix 2008.
    2. Unicode.
    3. DPL.
    4. Others.

  48. DPL!
    VCL (Support newer RichEdit dll with "Full Justify" -in M$ DLL since 1999-)
    .Net Compact Framework support
    Speed (More fastcode)

  49. 64 bits support
    VCL enhanced
    Native dbexpress 4
    Persistent Data Objects in native mode like ECO.
    Net Compact Framework support

    There is a lot of things to do and Visual Studio 2008 will be in the shops before a month.

  50. -> DPL
    -> Kylix
    -> Object-Relational mappings in Delphi 2009
    -> Future of Delphi
    ... and please do not narrow down topics of your posts. I really like your recent stream of postings. Very interesting:-)


Please keep your comments related to the post on which you are commenting. No spam, personal attacks, or general nastiness. I will be watching and will delete comments I find irrelevant, offensive and unnecessary.