[Estimated Reading Time: 12 minutes]

Today I was fortunate to be present in Auckland at the World Premier of the launch event for RAD Studio XE2.  There is so much good to report that I really don’t know where to begin, so apologies if this post is a bit of a disorganised ramble.  But here goes.

Executive Summary

  • FireMonkey – a scalable vector graphics based GUI framework exploiting GPU capabilities for hardware accelerated cross platform GUI’s.
  • Cross-Platform support – Target Win32 and Win64 with single-source VCL applications or Win32, Win64 and MORE using FireMonkey.
  • iOS support for native code FireMonkey apps !! – Yes folks – use Delphi to build iPhone and iPad apps that even Steve Jobs will be happy to have in his Store!
  • LiveBindings – a way to create ‘live” relationships not just between objects but between individual properties of objects.
  • Native Android apps – using PhoneGap in RadPHP
  • Native Android apps – to come in the future for Delphi (as well as Linux)
  • DataSnap client proxy generation – for Android, .NET, Objective-C, Blackberry, iOS etc etc
  • Starter Edition will be available right from the start along with Pro, Enterprise and Architect.
  • ALL platforms supported by the cross-platform capabilities will be in ALL editions, including Starter!

That’s a lot to cover, even in one whole day.  FireMonkey alone is such a huge advance for Delphi that I could spend this entire post talking about it (even as I sit here wearing the FireMonkey T-Shirt that I got for attending the event).

Yes folks – FireMonkey is big enough to warrant a t-shirt of it’s own!  Get used to hearing that name because I think we are going to hear a LOT more about FireMonkey not just from Embarcadero but from the industry in general.  It is a potentially game-changing technology imho.


Before I get stuck into the meat of the event however, first a couple of apologies.

1) No pictures or video.

I tried, but sitting at the back and with the lighting in the room the way it was, I couldn’t get a decent picture or video and frankly I was too busy concentrating on the content to fiddle too much to try to capture pictures of the content.  As a result this blog post is heavy on words and light on pictures.  But I heartily recommend that you get along to a launch event in your area to see this stuff for yourself.  It will be well worth the effort, I assure you.

2) Heavy on the Delphi, light on C++, Prism, PHP and indeed DataSnap

I am a Delphi developer.  I don’t use RadPHP, C++ Builder or Prism, and I don’t use DataSnap.  Consequently I was not paying as much attention to those areas when they came up, nor does it particularly excite me to talk about those things.  Accordingly the focus in this post will be on Delphi.  And to be fair, most of the event content was focussed on Delphi.  C+ Builder was mentioned primarily in the context of “this stuff in Delphi is also in C++ Builder (and this stuff isn’t, yet)”.  There was quite a lengthy session on RadPHP and deploying a native code Android app derived from a RadPHP project.  Similarly there was a quite detailed session on generating proxies for DataSnap servers for various platforms, including RIM/BlackBerry etc, as well as .NET and Objective-C.

Again, if those areas interest you, you will get even more from the event than I did.  🙂

So with those apologies out of the way let’s get stuck in…

Hang On!  Did you say iOS ?!

Absolutely!  This was the big surprise of the event.  Not only do we get Win32, Win64 and OSX in this release but also iOS!!

The iOS support isn’t yet in as finished state as the OSX support, but it is more than good enough to be usable imho, and improvements to this are high on the list, being expected in the first update pack or not long there-after.

To be clear, the shortcomings are not in the compiler technology but in the integration with the debugger – at the moment you can compile, run and test/debug your iOS app as a Win32 app in the IDE, but if you want to test and debug on the iPhone/iPad simulator itself (or deploy to an actual device) then you have to compile the project in xcode on an actual Mac.  I am not entirely clear on how this works, but suffice to say there is no translation to Objective-C going on – the xcode compiler takes the ObjectPascal from Delphi, compiles it and then allows you to run and debug that ObjectPascal source in the xcode environment itself.

Also, just as with OSX, the iOS support builds on the FireMonkey framework.  This means that – with a little care – you can write an iPhone app today (100% native and thus entirely welcome in the Apple Store – no if’s or but’s) and when the Android compiler support is delivered simply recompile for Android!!

64-bit Windows?

So, right out the gate I think the first question will be whether or not we finally have the long promised 64-bit Windows support in Delphi.  The answer to that is a resounding YES.  Rather anti-climactically though, the demonstrations of 64-bit’ness are spectacular non-events.  It.  Just.  Works.

In the  Project Explorer there is now a new node under each project, entitled “Target Platforms“.  Here you will find an entry initially for 32-bit Windows for existing projects.  Whether you can specify multiple targets when a project is created I am not sure, but even if not, adding a new target is as simple as adding the relevant node to the Target Platforms.  Just add the 64-bit Windows platform, make that the current selection (if not already), recompile and your work is done!

Well, you may have a bit more work ahead of you if you have 32-bit assumptions built into your code, and those will need to be addressed, but other than that, switching a Delphi application from 32-bit to 64-bit really is that simple.

There are some technical considerations that mean you may have to make some adjustments in your code, and I am sure these will be covered in more detail by numerous people over the coming weeks so shall not go into them here (if you know even a little about pointers and integer types then you can guess, or already know, what most of those potential problems are).

Mac OSX ?

Of course, one reason we have had to wait so long for the 64-bit Windows support was the decision to also address Mac support.  Was it worth the wait?

I should Cocoa!!  [sic]

Add Mac OSX to the Target Platform‘s, recompile and off you go.  Right?

Well, no.  Actually in this case things are a little more complicated since the VCL has not been ported to the Mac platform.  Yes, you heard that right.  The VCL is and remains specifically and firmly targeted at Windows.  This means that you will not be able to take an existing VCL application and simply recompile for OSX.

FireMonkey is the new cross-platform GUI framework for building apps that support OSX.  FireMonkey also supports Win32 and Win64, as well as iOS and other platforms to come in the future.  So if you have an existing application that you wish to deploy to OSX you will first have to convert that application’s GUI to FireMonkey.

I will say at this point that I think was the smartest decision Embarcadero have made but will talk about FireMonkey in more detail later.

For now, once you have an application that can target Mac OSX, you compile it in Delphi and can then run it on a Mac to test/debug.  Delphi itself remains a Win32 application, so debugging your Mac OSX app involves deploying the binaries to a Mac host and using the remote debugger (now called: Platform Assistant).  However, with a “Remote Profile” – a configuration entry attached to your OSX Target Platform – identifying a valid Mac host running the Platform Assistant server, this is all entirely seamless from within the Delphi IDE.

“F9 to run and debug” was the goal and it has been achieved.

Describing all this in words makes it sound very mundane and work-a-day ordinary.

Actually seeing it in action is of course very much more exciting.  🙂

So just what is FireMonkey ?

As already mentioned, FireMonkey is an entirely new GUI framework.  I mentioned previously that it replaces the VCL for cross platform applications.  This is not strictly accurate.  The VCL is of course far more than just a GUI framework – all of those classes so familiar to use, such as TStringList, TList etc are strictly speaking part of the non-visual aspect of the VCL, and of course those elements are just as accessible from a FireMonkey application as they are today.

Similarly things like DBExpress are all accessible from FireMonkey.

Indeed, the root class in the FireMonkey framework extends TComponent, not TObject. But a TButton in FireMonkey is a very, very different animal from a TButton in the VCL. (for one thing it resides in the unit FMX.Buttons, as opposed to VCL.Buttons – new namespaces keep the two frameworks apart).

Also, whilst certain components in FireMonkey are provided in the form of specific root classes, the framework also makes extensive use of interfaces to establish contracts, not inheritance.  For example, an interactive control in FireMonkey does not have to extend any specific control base class, but it must implement the IControl interface, which provides methods necessary for focus and input in the FireMonkey framework.

Similarly any component that implements IRoot may act as a top level container, IScene for providing a 2D surface and IViewport3D for implementing a 3D container.

Yes, FireMonkey has 3D support built right in, and this includes being able to apply 3D transforms to 2D surfaces, even if those surfaces contain interactive controls – these aren’t just cosmetic 3D tricks.  You can take a FireMonkey form, rotate it in about the Y-axis (rotating the form surface “into”/”out of” the screen) and it remains fully interactive and fully animated.

Also built in are styles and filters.  You want to make your main form appear visually out of focus when presenting a modal dialog for the user to respond to?  Just go ahead and apply the Gaussian Blur filter on your form at a strength you deem appropriate.  It’s like having PhotoShop built in to your app, except that it doesn’t just work with images but with any element of your GUI, including the GUI itself!

FireMonkey also supports things call “Animations” (and on this point I agree with Malcolm Groves : this name is not very good – at best it isn’t quite accurate).  A FireMonkey isn’t an “animation”, although what they can used to achieve will – more often than not – be graphical animation.

An animation is simply an object attached to some other component which – when activated – will change one of the components properties in some specified way and doing so over a period of time (independent on speed of the underlying hardware) in response to some event (or continuously, if you prefer).  The sorts of transformations that can be applied to the property being “animated” will vary according to the type of animation you configure.

So, for example, you might attach an animation to a button control to change it’s Color property in response to a MouseEnter event, and a second animator to change it back again on MouseExit.  Or you might gradually increase the Width of a panel to cover a larger area.

You can quickly see I think (or rather envision, given the absence of actual pictures in this report! :)) how very slick and sophisticated GUI’s can be readily assembled using FireMonkey.

You can also hopefully see how over-doing animations, filters and the other tricks at your disposal in FireMonkey could quickly result in the worst sort of garish and flamboyant interfaces.

All good things in moderation!  🙂

And what is FireMonkey not ?

FireMonkey is for building rich and dynamic business applications.  If you want a desktop app that has all the flair and panache of apps on the latest glossy touch based devices, the FireMonkey is the way to go.

But it is not managed code.  It is 100% ObjectPascal and is therefore fully compiled to whatever target platform the Delphi compiler supports.  Under-the-hood it exploits GPU power to deliver it’s capabilities, but it accesses the GPU in a platform specific but portable fashion.  On Windows this means that it utilises Direct2D and Direct3D.  On OSX and iOS it uses OpenGL.  You, as an application developer, do not need to concern yourself with this level of detail however (there is a caveat to that statement which I shall come to in a moment).

It is also not trying to be a platform for RIA (Rich Internet Applications).  FireMonkey does not try to compete with  Air or Silverlight.  It is not a framework for entire applications, nor does it spit out HTML 5 or CSS.   FireMonkey is for desktop – and mobile – native code applications.

Similarly it is not trying to be a platform for building games, although depending on the type of game you had in mind, it could be used for that of course.  But this is no different from simply stating the fact that ObjectPascal itself is not designed to build games – there are no language primitives or design tools in the language for creating sprites or isometrics worlds, but this doesn’t stop someone from using ObjectPascal to do those things if they wish.

Similarly there are no such things in FireMonkey.  And no mention was made of any physics engine support in the framework, for example.

FireMonkey is for building applications.

Sounds great!  Why not put all this in the VCL ?

Those familiar with the recent history of Delphi will perhaps be aware that when the cross-platform project was started, the original intention was to build a cross platform derivative of the VCL, very similar to the approach in the ill-fated CLX of Kylix.  Indeed, it was realised only quite late in the day that if they were to continue down that path then the result would be a Curates Egg.  It would involve compromise both by those who had no interest in cross platform development, but also by those who did.  At the same time it was recognised that some existing technologies could be acquired and built upon to deliver something that would be a compelling replacement for the VCL.

If people were going to have to change, give them very good reasons to do so.

When you see what FireMonkey can do and the way is is put together, you will understand completely why the VCL had to be “left behind”.  But when I say that, I do not mean that the VCL is now a dead technology, far from it.  It shall continue to evolve and be supported for a long time to come I am sure.  But I am equally sure that once you see FireMonkey you will never want to write a VCL application again, even if you never intend writing for anything other than the Windows platform.

GPU Acceleration ?  But I/my users don’t have a GPU !

A valid concern, and even worse, you may have a GPU but sometimes it can’t be accessed.  Some VM and/or RDP platforms for example render the GPU inaccessible.  In those circumstances FireMonkey reportedly (these scenarios were not actually demonstrated) degrades.  I use that word advisedly.  There is no graceful “downgrade” built into FireMonkey.  If you use some element of FireMonkey in your application that relies on a GPU then those elements of your GUI will run, but they will not render.  They will be invisible to your users.

So if those scenarios are important to you, you will have to avoid those aspects of FireMonkey.  Again, I am sure more specific details and guidance on this issue will emerge over the next few weeks and months.

So I can gradually move to FireMonkey in my VCL app ?

Sadly not.  Well, not officially.

Being platform independent, the FireMonkey framework does not rely on – nor indeed even directly use – the Windows message loop.  Or rather the way that is uses that message loop is completely and very technically different from the way that the VCL already does.  Also, the VCL contains several architectural aspects which are built very heavily and specifically on that messaging infrastructure in Windows.

Consequently the two do not co-exist very happily.  Apparently it is technically possible to contrive to incorporate FireMonkey in an otherwise VCL application, but it is potentially unstable and – more important – not officially supported.  So if you do try it, good luck and well done if you can make it work, but you won’t get any help from Embarcadero if you can’t and it all blows up in your face.

But whilst FireMonkey cannot site happily alongside the VCL in an application, a lot of the patterns that you are familiar with from the VCL have been respected in FireMonkey where-ever it has made sense to do so, to try to ease the transition from one to the other as much as anything I imagine.

So FireMonkey Means Lots of Change in our GUI ?

Yes.  Being an entirely new framework and being incompatible with the VCL (in terms of co-existence in the same app) means that if you have an existing app and wish to move it to FireMonkey then you will have to rewrite it’s GUI.

I for one think this was the right move.  It means that FireMonkey is architecturally “clean” and not weighed down by any of the baggage that clinging to the VCL would have brought, and this should only continue to deliver huge rewards and benefits in the future.

But what About DataAware Controls ?  Does FireMonkey at least have those ?


Instead we now have LiveBindings.  These are not exclusive to FireMonkeyLiveBindings work in all Delphi code, be that old VCL or shiny new FireMonkey.

Simply put, LiveBindings provide a connection between two properties on separate objects.  So you can for example bind the “Caption” property of a TLabel to the “DisplayName” of a TDBColumn.

But these aren’t just simply property-to-property mappings.  LiveBindings employs an expression engine to evaluate the bound property values, so you could bind that label Caption property to the expression “‘Column Name is :’ + Uppercase( DisplayName )“, for example.  Obviously such a binding is unidirectional – you could use it to set the label caption to the column name, but you could not use it to update the column name from the label as there is no way to easily “unwind” the expression.

But where a simple property-to-property binding is created, these are – or can be (you decide) – bi-directional.

Clearly, with such a framework a specialised “data aware” control hierarchy is unnecessary.  Not only can LiveBindings be used in place of such a specialised data aware framework (removing the need for separate, data aware versions of controls) but you can use these bindings for all sorts of purposes, not just data awareness.

You want to display the value of a selected item in a listbox in the dialog caption ?  Go ahead, make a binding.

And as a bonus, the expression engine that LiveBindings employs can be used stand-alone to evaluate any ObjectPascal expression, dynamically at runtime.

In Other News

RADPHP and PhoneGap

Using jQuery in RADPHP and a technology called PhoneGap, you can now package up a PHP application and deploy it as a native Android application.  I am not entirely clear as to how this works, but it may be of some interest to those using PHP and wishing to target Android.

DataSnap Client Proxies

As briefly mentioned, DataSnap now provides a facility for automatically generating proxies for you to deploy to developers of client applications wishing to access your DataSnap server applications from a variety of other languages:  Objective-C, C#, Delphi Prism, RIM BlackBerry and others.

Probably quite cool if you use DataSnap.

Colour me Excited!

Whew!  That was a mammoth post, and I am sure I have forgotten to mention something even in all that.

Suffice to say that I was not alone among the 60-70 people attending today’s event to be heard saying “this is exciting”.  Everyone there was giving up and entire working day to hear the news of this release, and every single person I think stayed for the entire day and left very, very happy indeed.

These could at last be the exciting times for Delphi that we have long been hoping for.

83 thoughts on “RAD STUDIO XE2: Launch Event Report”

  1. A quick search of FireMonkey on UrbanDictionary provides disturbing hilarity.

    Loved the Auckland launch by the way, as probably the youngest programmer in attendance to 3 of the 5 last years of Delphi presentations in Auckland, I can say I am genuinely excited for the future of Delphi. Hopefully we will start seeing more of the new generation of Programmers excited enough to follow the Delphi path.

  2. 64-bit is for professional developers and is absolutely essential in only a relatively small number of specialist products.

    You couldn’t be more wrong. Most of Microsoft’s products going forward will be 64-bit only. The most obvious use is server computing, but even home computers have far more than 4GB RAM potential these days and coming standard with 4GB. 64-bit is the future of all Windows computing, professional or not. I, for one, would not develop on any platform that doesn’t support 64-bit or waste my time on evaluating it, either.

    Including 64-bit support in a “starter” edition is actually a smart move.

    1. @Shawn – except for one thing… Win32 code will just compile and run on Win64. The nature of apps that a “Starter” developer is likely to produce absolutely won’t *need* 64-bit even if that is what everyone else doing, but even if you are using Starter Edition as your “foot in the door”, you can write your code knowing that (as long as you take sensible precautions that you should be taking anyway) it will simply recompile “as-is” if/when you do upgrade to the Pro Edition.

      Excluding iOS support on the other hand is dumb for the same reason… the sort of apps that Starter Users will be producing will in many cases find a perfect home on iPhone/iPad.

      Even if that were not the case, “Starter Edition” is the recruitment poster for the Delphi range. What better recruitment poster could you imagine than to offer the ease of development that Delphi provides for those slick, sexy iDevices ? (Have you *seen* what is involved in developing for iPhone/iPad using x-code… shudder).

      Your feeling that you would not develop on any platform that did not support Win64 is perfectly valid. But in the case of Delphi that is not actually a valid argument for including Win64 in the Starter Edition. Delphi supports Win64 in the Pro+ editions. By developing in Delphi Starter Edition you *ARE* developing on a platform that supports Win64, you just don’t have that capability in your particular edition. If/When you need it, you can simply upgrade.

      Bottom line: Nobody is likely to use Delphi Starter Edition to develop a video editing or image processing app that requires the > 2GB of memory, even if they *could*.

      By all means support the inclusion of Win64 if you really think it is worthwhile, but no amount of dissembling can make Win64 make *more* sense than iOS support, so if Win64 *is* to be included then iOS should be a shoe-in.

  3. @Joylon: it might be smarter to include the 64-bit compiler in starter additions but just cripple the optimizations.

    1. @Shawn – imho the sort of thinking that leads to “We’ll include XYZ but limit it in some way” comes from regarding “Starter” as nothing more than a paid for trial edition. i.e. “we’ll tease them with this, but if they want the full thing then they’ll have to buy a REAL copy”.

      That is not what “Starter” should be imho. Whatever “Starter” has “in the box” should be full, complete and unlimited and targeted at the type of user to whom the price point is attractive and makes sense. The “Starter-ness” should derive from what is not in the box at all. e.g. A “Starter” user arguably doesn’t need *any* refactorings or modelling tools, but they should get ALL the features of the debugger and (a particular hobby horse of mine…) they should get the VCL source as a crucial learning tool.

      {Note: not intended to be a definitive list, just a couple of examples I pulled out of the air]

      The key is to stop thinking of “Starter” as a trial edition and start thinking of it as, well, what it claims to be.

  4. Hi;

    I have been away from Delphi for 6 years (after 10 vyears of Delphi), now on .Net & Silverlight/WPF. I really miss Delphi.

    This news of Firemonkey has got me very excited. My main question is: When is XE2 going RTM and will this release have Firemonkey in it that supports MacOS and IOS?


    p.s. Hope I can join my old family again 🙂

    1. @Ben – As far as I know, XE2 will be available very, very soon – early September. FireMonkey is 100% ObjectPascal so (assuming that a requisite hardware graphics layer is in place on a particular platform) it will be supported on any platform that the compiler itself supports.

      For XE this means that OSX (Mac) support is in the box, and from everything I have seen and heard, it is a *very* polished level of functionality that has been provided, with seamless and smooth “launch and debug” from with the IDE (the IDE is still a Win32 app, so debugging on a Mac requires either running Windows in a VM – common practice anyway – or an available Mac on the network. Cross platform debugging uses the same technique as the long established and well proven “Remote Debugger”, now dubbed “Platform Assistant”).

      iOS support is not yet as well polished, requiring that code be moved across from the Windows dev environment to the Mac side to be compiled with xcode, using (I believe) the FPC compiler. Debugging when running in the iOS emulator (on the Mac side) is still possible, but involves using the x-code debugging tools, not the Delphi IDE. Being single-source cross-platform, you can of course do a LOT of your debugging entirely within the Windows environment, running and debugging your FireMonkey app as a Win32 process, only doing final debugging and testing that is necessary prior to deployment to iOS.

      The intention is to improve the integration on the iOS side to levels of polish at least approaching that already provided to OSX. Embarcadero aren’t trying to hide the fact that the iOS support is not yet “complete”, but they were pleased enough with what they had, and believed it useful and useable enough, to be worth releasing even in it’s current state.

      For me, I am looking forward to having some fun writing apps for my partner’s iPhone and iPad, but as an Android phone owner I am even more excited to look forward to the Android support that was mentioned as intended for XE3 !!!

      Hopefully you can pull up a chair at the family table again VERY soon. 🙂

  5. Thank you Jolyon for detail answer & positive attitude. 🙂 Here is my plan & intention.

    Write an App for iPad & Android Tablet platform.
    Also, since MSFT is going to be showing Win8 in three weeks at //BUILD conference, which will also show the new Tablet (4 core) made for Win8, I would like to cover that platform (Win8 Tablet) as well.

    Currently, for that Goal to happen, I have to:
    * Use Objective C and iOS to write for iPad
    * Use Java and Java/Android/Eclipse tools for Android Tablet.
    * Use C#/XAML and VS2010 to develop that Win8 Tablet (Windows 64)

    Now Imagine using one tool Delphi XE2 using Firemonkey to look like the new Win8 imersive design.

    How complete are the new components/controls under Firemonkey (not using VCL controls anymore) to build Line of Business application?

    Thank you in advance.

  6. Once Delphi XE2 supports the new Win8 platform & Android, it will grab the attention of many .Net developers, like it did with Delphi 1 as VB killer 🙂

Comments are closed.