[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. Pingback: Ger
  2. Thanks for the info, it sounds like all those threads we’ve been hearing about for years are finally going to be drawn together in this release.

    Was there any mention of the TDataSet or TClientDataSet and how it relates to FireMonkey apps?

    1. @Lachlan: Yes, in fact on of the demo’s specifically involved a TClientDataSet and FireMonkey, demonstrating how LiveBindings replaces the need for data aware controls. As I tried to convey in my coverage, a FireMonkey app is still a Delphi app – the VCL is still there in terms of many, many non-visual aspects of that VCL. The part of the VCL that FireMonkey replaces is specifically the Windows platform specific and GUI parts. Hence TClientDataSet and TDataSource are still there, but the way you use them to get “data awareness” with FireMonkey is very different.

      Also note however that you have the option of using that alternative approach – i.e. LiveBindings – in a 100% VCL app too. LiveBindings is not exclusively part of FireMonkey.

  3. 10x, absolutely a refreshing deep-dive from such a bitter critic as you !!!The best post covering XE2 and Firemonkey so far …

    I took the chance and post it over DZone [ http://www.dzone.com/links/r/rad_studio_xe2_launch_event_report_delphi_revival.html ] and on Twitter [ http://twitter.com/#!/devstonez/status/99023044504330240 ]

    So you seams to be a really “Delphi Lover” now (after all the constructive criticism in past !) … 🙂 … when the “Delphi Haters” are still busy: http://delphihaters.blogspot.com/2011/08/qa-dept-reused-ksdev-demos.html

    BTW: The fastest way to follow the XE2 & FireMonkey news/blogs is on Twitter ( http://twitter.com/#!/search/%23xe2 , http://twitter.com/#!/search/%23firemonkey )

    1. @Stonez – I was never a hater, though yes the characterisation as a “bitter critic” is not entirely undeserved. 🙂 Thanks for the compliment on the post. Malcolm Groves and Damien Bootsma (not to mention Richard Vowles, Sue Sparkes and no doubt others) put in a lot of work to bring us this event… sharing my enthusiasm seemed only fair in return. 🙂

    1. @Andre: I can only report what we were told. If there is a software rendering option it wasn’t mentioned, or it may be that this just wasn’t covered and went unspoken (i.e. if you are using GPU features [and do not enable software rendering] then they won’t render when the GPU isn’t available). I don’t know any more than that at present though, sorry (tho I admit I was surprised that there was no option to simply bypass the GPU from a practical p.o.v I can also see that it simply might not be feasible to provide viable software replacements for everything that the GPU is/can be used for). more information will undoubtedly emerge.

  4. All very good news Jolyon. The lack of 64 bit issues is VERY heartening. I had still been holding my breath for some caveat such as “preview” or “console only” etc…

    FireMonkey sounds very promising. I’ll be interested to see what features can’t be used in a Remote App / RDP session. Given the nature of FireMonkey, what were your impressions as to the number and depth of the components provided out of the box i.e. buttons, grids, labels etc… It sounds a rich encironment for component makers, was there any news from the likes of TMS talking about providing FireMonkey equivalents of their component sets? If it has the potential I’m hearing, then it sounds like any component provider would be shooting themselves in the foot by not opening themselves up to cross platform toolsets…

    Talking about component providers, was there any third party names dropped at the event who would be ready at launch day with 64 bit enabled versions of their offerings ?

    Finally, nothing concrete about an actual release date I suppose ? My thinking is for early September, just before the “live” event. The “win a copy of XE2 before it is available to the public” closes at the end of August, so it can’t be before then…

    Although I’m initailly only concerned about 64 bit, if the cross platform support lives up to the hype, it can only bring Delphi firmly back onto the Radar.

    1. @Paul T: Yep, 64-bit is fully “prime time”, as is OSX (altho it was mentioned in a break-out that the compiler is currently emitting only 32-bit OSX code – 64-bit is still to come on the Mac side for some reason).

      Several component venders were named… one thing I forgot to mention was that there is a[nother] new bundled report engine: Fast Report. But note that Rave is still in the box too.

      Because of the way 64-bit has been handled (single source) any component library that is in the box I have to presume is both 32-bit and 64-bit and other component vendors really shouldn’t have much work to do to get to a state where they can provide 32/64 confidently.

      Oh, one other FireMonkey thing – Steema have already done a lot of work to provide a FireMonkey version of TeeChart !! (this wasn’t demonstrated, only mentioned).

      Also, it was mentioned that the aim is for Indy to be cross-platform by the time of release (i.e. you will be able to use Indy in a Win32/Win64/OSX/iOS single source app!)

      As for release date, it is set to go “gold” at the end of this month, so your “Early September” guess was pretty much spot on I’d say. 🙂

      Did I mention yet that I am excited ? 🙂

  5. This is all great news.

    Andreano Lanusse from Embarcadero published two post about XE2 and FireMonkey, but didn’t mention iOS, probably it was the big Embarcadero surprise.

    Here some additional links about XE2


    Finally Embarcadero in the right track.

  6. Great write up, thanks for all the information. I know you didn’t follow the C++ stuff much, but did you ascertain whether or not the C++ compiler emits 64 bit code on Windows?

    1. @David: I honestly don’t remember for sure, but I *think* so, yes. As more information about XE2 is released you should find concrete confirmation of that soon – one way or the other. Sorry I can’t be more certain of it myself at this stage. Too excited by all the Delphi stuff 🙂

  7. Jolyon thanks very much for your very informative post. Just a question in the Delphi XE2 presentation any mention to the vcl styles?

    1. @Rodrigo: yes the VCL gets styles too, but the impression I got was that they are quite a bit more limited than those in FireMonkey.

  8. Good post, Jolyon. This is good news for Delphi, but there are important caveats around FireMonkey that we will need to take into consideration. As I commented here https://plus.google.com/111874043401122099650/posts/gi7RVxmzjBn – If FireMonkey do things in the same way on any platform, without fully catering for the native methodology for each GUI – we may end up with applications like Lotus Notes. On Windows, it appears to be a Windows App – but it just doesn’t behave as one in all respects – something that is very annoying and confusing for the users.

    We should still take care to make sure our apps are fully Windows/iOS/OSX compliant – and not just look and behave the same on all platforms.

    1. @Laws: Absolutely, and I think I expressed similar concerns in the past. But I think that was a far bigger danger with a CLX like approach. With FireMonkey the onus is on us… we can write a single gui that works well on all platforms or we can write a separate gui for each, but using the same rich toolkit in each case, complete with the additional features that offers us that are not present in the native gui toolkit of any of those platforms. 🙂

  9. Thanks for your post Jolyon. Always valued your opinions, even the critical ones. This is one very excited Delphi dev. 🙂

  10. @Jolyon Smith on August 4, 2011 at 21:35: Do you now if Fast Report can be easly used in FireMonkey application?

    1. @Pol: Funny – it only just occurred to me that the whole question of printer support/reports didn’t come up in relation to the cross platform support at all, let alone FireMonkey. Whoops.

  11. Jolyon, thank you for your comprehensive post.
    Really great news for Delphi developers, in particular I’m exited for FireMonkey and iOS compiler!

  12. Regarding FireMonkey hardware and software rendering:

    1) Delphi and C++Builder HD forms – uses Direct2D on Win32/64
    2) Delphi and C++Builder 3D forms – uses Direct3D on Win32/64
    3) Delphi and C++Builder HD/3D forms – uses OpenGL on OS X
    4) Delphi on iOS – uses OpenGL/ES

  13. Is the starter edition freely available like Microsoft’s Express suite of products?

    1. @Kris: All that was mentioned w.r.t pricing was that it was unchanged from XE. If so, then Starter Edition is/will not be free, but it a minimal cost – US$149 I think was the price for XE Starter.

  14. You pulled off quite a scoop with this article 🙂
    Glad to see the right attitude in your previous comment re Lars’ comment about one GUI not necessarily being great for all platforms. It is our responsibility as developers to provision for platform-specifics, be that as necessary in our “Business Logic”, or in the GUI.

  15. Thanks so much Jolyon. Great post. And very perceptible and communicative excitement…
    How come you guys down there were the 1st to get the launch event and not us here “at home”! 😉

  16. joylon wrote – ALL platforms supported by the cross-platform capabilities will be in ALL editions, including Starter!

    There will be differences between what you can do in the Architect, Enterprise, Professional and Starter editions. The Feature matrix will be up on our site before the end of the month.

    Starter edition will be Win32 only and will include VCL and FireMonkey.

    1. @David I: Some differences between editions is fair enough. But to limit Starter Edition to Win32 is not only crazy but is absolutely not what we were told yesterday.

      FireMonkey and the new opportunities this delivers for Delphi are amazing, but they are useless if they are out of the reach of the people who are most excited by it. Yes, big corps and enterprises are rolling out iOS apps, but I think it’s fair to say that the majority are being developed by enthusiasts and hobbyists. Getting Delphi into the hands of those people would be the biggest shot in the arm for Delphi in years. Indeed, this was a recurring theme among those expressing excitement yesterday – not just for their own development projects, but that Delphi was “cool” again and could see an influx of new blood on the back of the ease of iOS development that it offered.

      I do hope that Malcolm was right and that you are somehow mistaken on this particular point.

  17. Does FireMonkey work on Windows XP (since Direct2D is not supported on this platform)?

    1. @Marko: I don’t know about XP support. It wasn’t specifically mentioned that it was NOT supported, but then it was not mentioned that it did. I don’t draw anything from that other than we will perhaps have to wait to find out a bit more. 🙂

  18. First, I got to the office, and there was an invitation to to go Ice Skating with Satan in Hell.

    Then, a complete squadron of small pigs started flying around my office.

    Then, I read the above post and realized that it was a positive post — almost fanboy-ish! — about Delphi and Embarcadero from Jolyon.

    This is a strange day. 😉

    1. @Nick: I’ve always been a Delphi fan from the very start, which is why I was/am/and will be critical when I see (from where I sit) it being mishandled/mismanaged.

      Friends tell you when you are doing things wrong, but they remain your friends and will still be there to applaud when you get things right. 🙂

  19. That’s quite an accurate summary of the event Jolyon, you must have been taking notes – well done. I can’t wait to get my hands on a copy of XE2, as with everyone else at the event. Delphi XE was a bit disappointing, but Embarcadero have certainly over-delivered with this release.

    1. @Alister: Thanks, and yes I did scribble a few notes, but most of it was so momentous that it sunk in without those aides memoire. 🙂

      In a stroke of serendipity my new work iMac arrived yesterday, so today I’m having fun getting that all set up ready for XE2 in a few weeks time. Happy Days. 🙂

  20. I couldn’t agree more with Jolyon re the limitation of Starter edition!

    “Starter edition will be Win32 only and will include VCL and FireMonkey.” – David I

    Seriously, this is a HUGE mistake! Please send the Marketing Manager who made that decision to the UK so I can personally bitch-slap him upside the head with a wet haddock!

    As Jolyon has said, Starter Editions exist to bring “new blood” to Delphi (something we’ve sorely missed in recent years). Not only is this beneficial to Embarcadero (more revenue etc.), not only is this beneficial to the third-party Component & Tools developers, it’s beneficial to the ENTIRE Delphi Community!
    If you place such a massive restriction on Starter Editions as to omit the entire point of its release, you’re going to seriously alienate the “new blood”.

    Nobody wants to buy a pie without at least having a hint of what it tastes like! You can’t just say “well lick the crust” when the crust always tastes the same! They want to sample the meat! Let them sample the god-damn x64, OSX and iOS meat!

  21. Re the Starter edition limitation I agree entirely with Jolyon. If you want a buzz and want one of the next ‘surprise big hits’ in the iPhone (or eventually Android) app space to be written in FireMonkey then you need the Starter edition to include full cross app support.

    That niggle aside it was a great event and thanks for the nice writeup Jolyon.

  22. Thanks for the write up, I was supposed to go to the presentation but had to pull out at the last minute, though from what you’ve said it sounds a must do and gives me a good excuse to catch one of the ones in Aussi next week 🙂

  23. I’ll highly concur with the suggestions on Starter, if you want visibility ofr FireMonkey apps, you at the very least need to have iOS in it.

    Even a super-pretty Windows block-buster FireMonkey app won’t have anywhere near the impact a moderately successful iOS app could achieve in terms of image.

  24. I think the starter edition is targeted just right. You can get your experience with FM and produce working code.

    64-bit needs no learning, if I understand Joylon correctly. Not if It. Just. Works. So why include it in a Starter Edition?

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

    1. @Ken: Leaving out Win64 might make sense on that basis, but equally what harm does it do to leave it in?

      But iOS and OSX ? Those absolutely HAVE to be in the box.

      And even with Win64, we’re talking about not just beginners but hobbyists and amateurs… those people will positively want to share their code with others… others who WILL be using 64-bit. So those amateurs and hobbyists will have to release their code untested on that platform.

  25. Hi, my name is Adriano Santos and I’m Delphi specialist. I’m also very excited
    with Delphi XE2 and I can’t to wait to launching event on Brazil. For sure, I belive that this is version better of all times. I published in my blog about the Delphi Tour from Brazil event. Delphi? Go go go, 🙂


  26. Agreed. Please consider including all of the platform support, including iOS in the Starter edition.

  27. For info after a bit of `googling` there is a demo of what seems to be the basis of the firemonkey gui controls at

    [link removed – gave 403 forbidden]

  28. You are talking about a “game-changing technology”. You have this “game-changing technology” for years with Lazarus. 😉

    1. @Peter: Well the same could be said of the cross-platform aspects. But if the “game” is serious commercial development I’m afraid that as much as I applaud the effort that goes into FPC and Lazarus it’s not really playing that same game imho.

      On numerous occasions I have looked at FPC and Lazarus over the years and sadly every time I have come away disappointed. ymmv.

  29. Dang,

    First you have the Delphi XE2 preview then the All Blacks win….Honestly, this is exciting. Can’t wait for the roadshow on Wednesday (10 Aug) here in Sydney. Let me see three more sleeps….

  30. I was at the same launch event and I was seriously excited. I am still buzzing today 3 days later. And not just because we trashed the Wallabies 🙂

    IMHO these changes have the potential to really get Delphi back to where it belongs as a market leader. I cannot wait to see what can be done with FireMonkey. While it is not designed to make games having cross platform access to a GPU accelerated canvas certainly offers great possibilities. Currently we write many casual games in Delphi using various DirectX libraries but the idea that I maybe able to make entertaining software and have it come out on PC, Mac and iOS with little extra effor is just too exciting.

Comments are closed.