This is the blog of Brian Long, Windows, Mac & mobile trainer, trouble-shooter and consultant.

Friday, 14 September 2012

Delphi happenings

Well, I turn my back for a mere month and when I turn round again all sorts of occurrences and shenanigans have happened in the world of Delphi and RAD Studio! Here’s a summary for anyone who has also been distracted with other matters over recent weeks:

RAD Studio XE3 is released and available

RAD Studio XE3 world launch tour in progress

Delphi XE3 and C++Builder XE3 have Windows 8 support, but not necessarily in the form you might expect

Delphi compiler maintainer leaves Embo

Now you can’t do client/server apps in Delphi Professional. Oh, but now you can

The world-wide launch tour is well underway and the UK launches are to be on Tuesday 18th September in London at the Natural History Museum (although registration is already closed for this event due to very high demand and limited seating) and on Thursday 20th September in Manchester at the City Tower. Alas I have some personal matters that have to be attended to on Tuesday so I have had to miss out on this launch.

Windows 8 was also released to manufacturing on 1st August and made available to developers via MSDN Subscriber Downloads shortly afterwards. It will be made available to the general public towards the end of October. I’ve written a lengthy post that conveys my impressions and opinions of it, having played with it for a little while.

Thanks to the finalisation of Windows 8 at this time, Embarcadero had something of an obligation to add some form of Windows 8 support for RAD Studio customers in a new version coming out soon after. Metro apps (oops, I mean Modern UI apps, or maybe I mean WinRT apps) can be built, according to Microsoft, using three environments: native (C or C++), managed (.NET, so C# or VB) or JavaScript. The underlying WinRT subsystem offers Windows Runtime Projections (or bindings) for those environments.

Embarcadero Prism XE3 (aka Oxygene for .NET 5.2) fully supports the .NET WinRT projection and so with it you can build true Modern UI apps aka Windows 8 apps aka WinRT apps aka Windows Store apps aka Metro apps. Such apps will work just as well on Windows 8 as they will on the forthcoming ARM tablets running Windows RT (this version of Windows entirely removes support for developer-built desktop apps – Windows RT will have a desktop, but populated only by Microsoft’s apps).

Delphi and C++Builder also support Metro. Well, to be precise, let’s see the marketing blurb:

With Delphi’s new Metropolis UI, you can easily create apps with the new Windows 8 UI styling, including, touch enablement, live tile support, tablet sensor components, and more to run on Windows 8 desktops and x86 Surface and Slate tablets - and run on previous versions of Windows from XP to Windows 7. Delphi XE3 also lets you easily migrate existing FireMonkey and VCL applications to the new Windows 8 Style UI.

So you can see that Delphi (and C++Builder for that matter) don’t quite support building real Metro apps, instead they use styles to make them look like Metro apps (that’s the Metropolis UI) and can be installed into the Start screen. But they will still be traditional Windows apps, which is why they can run on earlier versions of Windows.

Firstly, is this a problem? Well, it depends on your point of view. On the one hand, if you want to build a true Metro app and partake in the whole Windows 8 UI, working with the Search and Share charms and so on, you won’t be able to do so with a Metropolis UI app. Though that said, I read that use of the TLiveTile component does give real live tile support on the Windows 8 Start screen. This is achieved by spawning an actual WinRT live tile process that then communicates back to the Metropolis desktop app via HTTP/REST.

On the other hand if you just want your existing or new desktop apps to look like they were designed using the same design spec as Windows 8 apps then Metropolis is where it’s at. Metropolis is a desktop flavour of the Windows 8 UI style compatible with existing codebases (VCL and FireMonkey). Check out the Metropolis UI documentation.

Other vendors are already modifying the style of their desktop apps to look like Windows 8 apps, taking on the simpler, minimalist look and feel. AVG anti-virus software seems to have an overhaul in this general direction, Visual Studio 2012 has had a large makeover to give it a whole new look and feel and the upcoming Office 2013 will similarly have this look and feel.

So, was this decision caused by lack of time or inclination? Well, no. The Embo R&D peeps had little option. There has been quite some activity about this on the various discussion fora over recent weeks. Initially, research into building native WinRT apps in Delphi was ticking along quite nicely, if these posts by Thom Gerdes from December 2011 are anything to go by (unfortunately much of the actual code is of little or no use now, thanks to so much in the WinRT API changing over the various pre-release versions):

Alas Thom left Embarcadero early in 2012 so further research was taken on by someone who wasn’t so into posting about it.

Things seem to have got rather tricky when the Embo R&D guys saw how tightly sandboxed the WinRT APIs are. As Embo’s Allen Bauer says in a forum post in August, talking about off-limits but eminently useful APIs such as VirtualAlloc or RtlUnwind, the kinds of APIs that the Delphi RTL kinda needs to use in order to do its job:

Any calls to those APIs from your application will automatically disqualify your application from being an “official” WinRT app capable of being delivered through the MS app store.

Visual C++ is a native code compiler and it can successfully make WinRT apps. However it can do this because any WinRT app built with Visual C++ has to be linked to the Visual C++ RTL DLL. The Visual C++ RTL DLL makes all the calls to the forbidden APIs and this works out because the Visual C++ RTL DLL has been given special dispensation in Windows 8 and is allowed to get away with it. As long as the off-limits APIs are called from within the VC++ RTL DLL and not from the app itself then the app is perfectly okay.

Simply making use of the VC++ RTL DLL in Delphi is far from trivial thanks to differing object models and exception management and propagation behaviour. And then there would be the issue of licensing the use of the VC++ DLL. And there thus far appears to be no sensible way to get a Delphi RTL DLL that can be given the same dispensation.

The APIs in question can be called from a Metro app built with a developer certificate, but as soon as you run it through the checks for submission to the store, it will fail. Solutions to the problems are actively being sought and support for building WinRT apps will be in a future version of Delphi, according to Michael Swindell.

Other excitement in the world of Delphi involves the departure of Barry Kelly, the public human face of the Delphi compiler. The compiler has now been through three fine sets of hands: those of Anders Hejlsberg, who created it, Danny Thorpe and then Barry Kelly. I hope another suitably talented individual takes the job on real soon.

One potential storm cloud formed when a draft EULA for the XE3 products was leaked and found to contain a rather disturbing change. There was a clause that stated that license holder of the Professional version of the products were not permitted to distribute any client-server applications built with it – to do that required the Enterprise license. This caused some furore around the world’s digital corridors and fortunately the EULA changes were killed off before product release. This is confirmed by a post by John Ray Thomas.

A notable change has taken place with the RTM version of XE3. Anyone who spent a lot of time rolling their sleeves up and getting to grips with the minutiae of writing conditionalised code in the IDE and then using the FreePascal compiler inside Xcode to create working iOS FireMonkey applications might like to turn away now. iOS support is not in XE3. Indeed mobile support is not available from Delphi XE3 or C++Builder XE3.

With just a cursory glance this might seem to be a rather cynical and retrograde step. But the FreePascal usage was just a makeshift temporary placeholder, offered to give some iOS capability while work was continuing in the labs to conclude building ARM compilers for Delphi and C++Buillder. As it goes, those ARM compilers still aren’t ready yet for the XE3 release. We hear that the various architectural alterations made to FireMonkey 2 and also changes made to the Pascal language when targeting ARM mean that FreePascal is not able to compile the current version of the mobile FireMonkey stuff. So the FreePascal part of the puzzle has been jettisoned. However if you’ve been working on a project using these technologies, well, erm, keep using XE2 for that stuff I guess.

What seems to be the plan is that in the coming months the ARM compilers for Delphi and C++Builder will be ready, or near to it, and so mobile support for iOS and Android using Delphi or C++ will be available soon-ish. This looks to be made available in an add-on product. XE3 customers will have access to the Mobile Tool Chain beta. More details can be found in John Ray Thomas’s post.

Another deferment applies to the 64-bit C++Builder support, which is still absent in RAD Studio XE3. I can only imagine this is another item to appear in various preview forms over coming months, at least this must be the case if we are to take the planned timescales in this older post by John Ray Thomas as anything like realistic.

After a few potentially controversial stories referred to above, the final piece of news relating to Embo is a nice upbeat piece. Recently they introduced an Embarcadero MVP program. This was announced by Anders Ohlsson in late August, and I’m delighted to say that I am in the list of instated Embarcadero MVPs! :o)

As an aside I see that in the comments to that post the guys at DevJet have committed to making their products available free to MVPs. That’s magnificently munificent – an Express Edition of their nifty Documentation Insight product has been included in the last few versions of RAD Studio, so it would be great to see what functionality the full product offers!