Tag Archives: delphi

Hands on Cross-Platform Windows and Mac development with C++ Builder XE3

I have been writing about Embarcadero’s RAD Studio XE3, which includes Delphi and C++ Builder, and as part of the research I set this up for cross-platform development on a Mac.

My setup uses a Parallels Virtual Machine to run Windows 7, on which RAD Studio XE3 is installed. This is convenient for Mac development, since the IDE itself is Windows only. That said, if I were doing this in earnest I would use multiple displays or perhaps separate physical machines, since it is no fun debugging in a VM with the application running in another operating system behind it.

Is it straightforward to configure? Not too bad. You have to install Xcode on the Mac, and in addition, you have to install the Xcode command line tools, which you can do from Xcode itself, in Preferences – Downloads – Components, or as a separate download.

image

Then you need to find the Platform Assistant (paserver), an agent which runs on the Mac to support remote debugging. I was annoyed to find that this has a dependency on Java SE6, which to be fair it downloaded and installed automatically. Actually I find this amusing, after hearing from an Embarcadero VP how native code is all the rage and nobody uses managed code any more. Except Embarcadero for the paserver.

Once that is all up and running you are done on the Mac side. On Windows, you then need to sort out a remote profile, after having installed RAD Studio of course. The way to do this is first to start a new cross-platform project, which means using the FireMonkey framework. Then right-click TargetPlatforms in the project manager and add a platform. If you add OSX but no remote profile exists, you will be prompted to create one.

image

This is where something went slightly wrong. I created a profile and could connect OK. However, when I tried to build the project, I got an error: Unable to open include file ‘CoreFoundation/CoreFoundation.h’. You get this if for some reason the required library files have not been pulled over from the Mac. The fix is to edit the profile and click Update Local File Cache.

image

After that I was away. Set breakpoints if needed, build and debug.

image

Cross-platform is not new in RAD Studio; it was in XE2, and in some ways better, since you could target iOS as well as OSX. C++ Builder XE3 is actually a new generation though. In the 64-bit update 1, it is the first release to use Clang and LLVM, and from what I understand this represents the future for Embarcadero’s tools.

Updates are promised in 2013 for both Delphi and C++Builder – this roadmap is most of what we have to go on – which will add first iOS and later Android support, at what the company calls a “low cost”. Unlike the iOS support in XE2, the coming update will not use the Free Pascal compiler, but the new architecture based on LLVM. This also suggests that the add-on will replace some of the guts of Delphi when it arrives, so it will be significant and somewhat risky.

The cross-platform capabilities look good, though I am somewhat wary of FireMonkey which is less complete and mature than the Windows-only VCL. For example no Webbrowser component is supplied, which is a significant limitation, though I am sure there are ways of hacking this, perhaps through ChromiumEmbedded for which a Delphi FireMonkey exists.

It is worth a bit of effort, since Delphi and C++Builder are productive tools, and the output is true native code which still had advantages.

More information on RAD Studio XE3 is here.

Embarcadero launches C++ Builder XE3: first built on Clang

Embarcadero has released C++ Builder XE3, the first version built on the open source clang front end for the LLVM compiler. This has enabled the product to support many new features, including extensive C++ 11 support and a 64-bit compiler.

image

While it is a shame that the old Borland C/C++ Compiler is no more, it makes sense for Embarcadero to bring its VCL (Visual Component Library) and FireMonkey framework to Clang rather than continuing to work on its own compiler.

The other big change is cross-platform support. Through FireMonkey, C++ Builder XE3 supports Windows (including Windows 8) and Mac OS X, with iOS and Android promised for 2013.

Although Windows 8 is supported on the desktop, there is no official support for the Windows Runtime (Windows Store apps). Instead, Embarcadero has a curious application framework called Metropolis which fakes the Windows 8 style but with desktop applications, as if the Windows 8 world were not already sufficiently confusing.

The big question is how compatible VCL applications created for earlier versions of C++ Builder are with the XE3 release. With a new compiler and major changes to the VCL in order to support the new compiler, you might expect some issues.

“That’s what we’ve been spending all of our time on,” Embarcadero VP Michael Swindell told me. “This is fully compatible with all our previous C++ dialects. We’ve completely re-engineered the C++ front end but it’s engineered to be compatible with C++ Builder applications and Borland C++ applications.”

I would rather hear that from developers though, rather than from Embarcadero.

Although C++ Builder is a cross-platform compiler, it only runs on Windows. A common scenario is to run in Windows emulation on a Mac, using VMware Fusion or Parallels.

Similar changes are on the way for Delphi, which uses the same VCL and FireMonkey frameworks but with the Delphi language based on Object Pascal.

Note that the new Clang-based compiler is 64-bit only. You are meant to continue using the old Borland compiler for 32-bit, making it hard to maintain a single code base for both.

Embarcadero releases RAD Studio XE3

Embarcadero has released RAD Studio XE3, a major upgrade to its suite of tools for Windows, cross-platform and web development.

New in this version:

  • Windows 8 compatibility
  • Metropolis framework for desktop apps that have the look and feel of Windows 8 “Modern UI” (formerly Metro) apps. Live Tile support is included via a proxy Windows Runtime app.
  • Prism XE3 for .NET development, including support for the Windows Runtime in Windows 8, using a Delphi-like language.
  • Version 2 of the FireMonkey cross-platform framework, with improved touch support, a new grid control
  • Easier data binding in both FireMonkey and the Windows-only VCL (Visual Component Library) framework
  • New HTML5 Builder tool which replaces RadPHP. The new tool supports cross-platform mobile development by integrating PhoneGap, which lets you wrap HTML apps as native mobile apps.

Mac OSX support is included but iOS support has been removed, pending release of a forthcoming Mobile Studio product.

64-bit C++Builder is not in this release. 64-bit Delphi was introduced in the previous XE2 release.

Embarcadero has backed down from a proposed change to the license for the Professional edition which prohibited connection to remote databases. This restriction now only applies to the dbExpress database framework.

More when I have installed the actual release. The most eye-catching feature is Metropolis, though whether there is really a demand for a fake Modern UI framework is an open question. There are also concerns about deployment, which will not work on Windows RT (the ARM version) and may involve some hacks on x86, since it cannot go through the Windows Store.

image

Last year’s RAD Studio XE2 was an amazing release in terms of announced features, but plagued by quality issues which left some developers disappointed.

Delphi XE3 Professional downgraded to local databases only

There is a bit of a stir in the Embarcadero community following the leaking of a document which appears to be an email to partners concerning a major change in the EULA (End User Licence Agreement) for the Professional edition of Delphi, the RAD development tool for Windows (with lately some cross-platform capability).

This email is to let Embarcadero Technology partners know about some changes being made to the EULA changes in our XE3 release.

In particular, the use of data access technologies for client/server connectivity will no longer be allowed in the Professional edition.
This includes both Embarcadero and 3rd party solutions. Professional users may only, legally, access local databases with their applications.

Users who want to use client/server database access can purchase a Client/Server Add-On Pack for their Professional edition or purchase
an Enterprise, Ultimate or Architect edition product.

This restriction if for new licenses only.  Users upgrading to XE3 will be "grandfathered" in that they will be able to continue to use 3rd party data access technologies for client/server database access in version XE3. Additionally, Starter Edition has been restricted to use of MyBase (.CDS or .XML file formats) only for "database access."

While this has not been officially confirmed I believe the email, at least,is authentic. Embarcadero’s David Intersimone implicitly confirms it with comments in the lengthy discussion on the Embarcadero forums.

It sounds complex and, like many software licences, based essentially on trust rather than technical limitation.

In the past, Professional has been the edition of Delphi to get if you want to do real work but do not need fancy stuff like modeling tools, advanced database frameworks and so on.

A “Professional” edition with local database access only does not deserve the name. This kind of restriction is usually reserved for tools aimed at hobbyists or intended mainly for trial purposes.

The news has not gone down well. Some of the most vocal on the Embarcadero forums are partners whose add-ons will no longer be legal to use with the Professional edition.

As a loyal Delphi developer since 1995… and as an Embarcadero Technology Partner… I cannot simply sit by and say nothing. This EULA change is WRONG. There’s no moral ambiguity here! It doesn’t tow a line, fall into a "grey area" or wobble on the tightrope… it is simply wrong. It crosses every line: ethically, morally, and progressively. Not only that, but as an idea it is patently stupid! The condition is financially and logistically unenforcable, and the only thing it does is serve to deter new customers.

says Simon Stuart, creator of the Lua4Delphi library.

The core problem here? It is hard to make money on development tools, given the competition that is either free or provided by platform vendors (meaning Microsoft or Apple) who have every advantage in terms of finance and inside knowledge.

Delphi is a fantastic tool; but Embarcadero still struggles with quality issues. The answer is greater investment, but where does that come from? Upping the price is one strategy, though it is no sure-fire solution as the above debate demonstrates.

Update: It appears that Embarcadero has backed down. The “finalized” EULA states that the local database restriction only applies to dbExpress, a specific Embarcadero database framework:

Licensee may not use that portion of the Product identified as “dbExpress” in association with a database located on a different machine other than the machine on which the Works are installed.

Third-party compilers locked out of Windows Runtime development

Embarcadero’s chief scientist Allen Bauer has posted about the problems facing tool vendors who want want to support Microsoft’s Windows Runtime (WinRT) platform with their own compilers, which he calls “Windows 8’s ‘dirty little secret.’”

The issue is that in order to enforce security and isolation in WinRT apps, Microsoft prohibits certain API calls. Even if you find a way to use them, applications that use these calls will not be accepted into the Windows Store, which in effect means no public distribution.

We are very keen on supporting WinRT with native Delphi & C++ code. Right now, the issues surrounding the WinRT space center around the fact that many OS-supplied APIs which are required by anyone implementing their own language RTL are actually off-limits unless you’re the VC++ RTL DLL. You know, little things like RtlUnwind for exception processing and VirtualAlloc (et. al.) for memory management… Any calls to those APIs from your application will automatically disqualify your application from being an "official" WinRT application capable of delivering through the MS app store.

Right now the VC++ RTL DLL is given special dispensation since that is the library that makes the calls to those forbidden APIs and not directly from the user’s app. We’re currently rattling some cages at MS to find out how or if they’re going to allow third-party tools to target WinRT. Until we can get past that, targeting WinRT isn’t actually possible from a deliverable product sense. We are able to build WinRT applications with Delphi that work with a developer certificate, however they all fail the application qualification checks because of the aforementioned (an other) APIs.

Bauer adds that there are other restrictions that make it hard to create an alternative toolchain:

For instance, you cannot merely open any file, access the registry, and even use the loopback (127.0.0.1) adaptor. LoadLibrary cannot be used to load any arbitrary DLL; you must call LoadPackageLibrary and only on a DLL that is present in the digitally signed appx package. WinRT is a seriously locked down sandbox or "walled-garden" with some extremely high walls.

Embarcadero’s answer has been to create a framework that makes desktop apps look and behave somewhat like WinRT apps. I posted about these fake metro apps here. Even Live Tiles are supported. However, these apps cannot be distributed via the Store either, but only through a desktop setup. In addition, they lack the security of true WinRT, and access to the Contracts system for safe exchange of data.

The company does have a .NET tool in the works, called Prism, that will build WinRT apps.

Who is the villain here? Embarcadero’s concern is understandable, since it is locked out of creating a native code compiler for WinRT. On the other hand, to what extent can Microsoft relax the restrictions without blowing a hole in the WinRT security story. There are parallels with the complaints from Google and Mozilla that they cannot compete equally with IE10 in the Modern UI environment.

Thanks to .NET support, Microsoft does have a measure support for alternative languages; it is the Common Language Runtime after all. What would be better though would be to support LLVM, as Apple does on iOS, though this is not likely to be on Microsoft’s roadmap.

Thanks to Eric Grange for pointing me to this post.

DevExpress offering Metro-inspired Tile control for Delphi VCL, plans to drop support for Delphi 7

DevExpress has released an update to its VCL component suite, version 12.1, which includes a Metro-inspired tile control. That is, it looks like a Windows 8  Metro-style application, but in reality it runs as a desktop application. The VCL components support Embarcardero’s Delphi and C++ Builder, but not the FireMonkey library that runs cross-platform.

image

The new release also adds a “Server Mode” for  the ExpressQuantumGrid grid control, which retrieves only those rows needed to populate the current view.

DevExpress CTO Julian Bucknall has posted about the update. He says it is time to drop support for Delphi 7 (though this is supported in 12.1):

12.1 will be the last version to support Delphi and C++Builder 2010. I will sound a further note of caution: it’s likely that in 2013 we shall drop support for Delphi 7 and Delphi 2007 (what you might call the “ASCII IDEs”), so that we can concentrate on the latest run-times and environments.

Delphi 7 is significant because it was the last version to use its own dedicated IDE built with Delphi itself, and by today’s standards is delightfully small and fast.

Bucknall has reservations about Embarcadero’s move to Clang and LVVM for 64-bit C++ Builder and eventually for the other languages too:

I’m going to say we shall treat it with kid gloves. Re-engineering a compiler so fundamentally says “breaking changes” to me, especially given the necessary extensions that are present in the current C++Builder to interface with Delphi. So, fair warning: if the changes are too severe, we shall not support 64-bit C++Builder in 12.2. It took us long enough to support 64-bit Delphi across our entire product line, and this year we don’t have the resources. That doesn’t mean we won’t ever do this (after all, Embarcadero are saying that they’ll switch completely to Clang/LVVM at some point), just that we won’t this year.

Returning to the Tile Control: it will be fascinating to see if this sort of approach, mimicking Metro with a desktop app, becomes popular. Microsoft is promising some of the same with Office 15, though we have not seen much of this officially yet. The advantage is that you can make desktop apps just as touch-friendly as Metro apps. The disadvantage is that you do not get Windows Store support, Contracts, app isolation, or other benefits of the Windows Runtime which underlies the Metro side. Users may be confused.

I doubt Microsoft will mind though. It all helps to promote the Metro style which is the distinctive feature of Windows 8.

Embarcadero adopts open source Clang for future C++ versions

A couple of months ago Embarcadero’s John Ray Thomas published a roadmap for the company’s C++ tools. Coming soon: not only a long-awaited 64-bit compiler for Windows, but also native iOS and Android support. On top of that, there are plans for “the very best in C++11 and C99 language and library compliance in the industry.”

Sounds good; but this forthcoming upgrade is not quite what it seems. I spoke to technical evangelist David Intersimone about the changes. The company is adopting Clang, an open source project which creates a C/C++/Objective C front-end for the LLVM compiler. “We’re integrating all that into our IDE,” said Intersimone. “We’re also going to be using that same toolchain world with our Delphi compiler as well.”

“We have analysed what to do about C++. Our compilers both for Delphi and C++ have been around for a lot of years, and over time it just got harder and harder to add new capabilities to make programming simpler and also to add power and richness to the languages. In C++ in particular the language continues to be updated, with now C++ 11. So we made the decision to use Clang and LLVM on the C++ side, for the 64-bit compiler. We’re going to keep our existing compiler for 32-bit Windows for now, and then eventually replace that.

“For Delphi we’re still using our existing compiler to do some of the work, but we’ve been working on a next-generation compiler for Delphi and that is still in the works. For a while we’ll have two compilers, the existing architecture compilers, and then new compilers.”

Embarcadero has its own C++ extensions to support component development, and is working on adding them to Clang. “We’re leveraging and extending the Clang compiler with the property-method-event extensions that we added to our own C++ compiler.”

It is a sad moment in some ways, bearing in mind the long history of what was once the Borland C++ compiler. Equally, it is a sensible move. Intersimone said that the work of keeping up with the evolving C++ specification was disproportionate to the benefits. “It’s a monster language, with a lot of power and a lot of complexity. It made perfect sense to fit our extensions [to Clang] versus building a compiler from scratch and having to continue to track the language into the future.”

Embarcadero can focus instead on its IDE and tools, and on the frameworks for Windows and for cross-platform.

Look out for a more detailed interview with David Intersimone in a future article for Hardcopy.

Embarcadero updates Delphi XE2, full reinstall required

Embarcadero has released Delphi XE2 Update 4. The depressing news is that you have to uninstall RAD Studio completely before installing the update. The reward is a large number of bug fixes, listed here, as well as new features:

  • Printing support in FireMonkey OS X
  • Support for Free Pascal 2.6 in FireMonkey iOS
  • New FireMonkey types and methods
  • New VCL styles
  • 64-bit type library import, for using COM libraries in Delphi

Delphi XE2 was somewhat rough on first release, so upgrading is advisable. Maybe it is now sufficiently robust to attract those more cautious developers who do not like to use new products in their first incarnation.

Compile Object Pascal to JavaScript with Smart Mobile Studio

Here is an interesting project for Delphi developers: a compiler and IDE that takes your Object Pascal code and outputs HTML and JavaScript. 

image

Smart Mobile Studio, also known as OPJS (Object Pascal to JavaScript) is a project from Optimale Systemer AS, and supports not only the Object Pascal language. but also reusable components in true Delphi style. The goal is to bring Object Pascal programming to mobile platforms, using PhoneGap to wrap the generated code as a native application for iOS, Android or other platforms.

According to the developers, “The Smart object pascal dialect is more or less identical to Delphi 7”. That said, there are no pointers, and ASM blocks contain normal JavaScript instead of machine instructions. This enables use of JavaScript libraries such as JQuery from Smart Mobile code:

You can access native JS through an ASM section, create an instance of it to a variant, and then access its methods directly.

Smart Mobile Studio is currently in closed Alpha so not ready for most of us just yet. Note that there are other options for mobile development with Delphi, including Embarcadero’s official FireMonkey project which can be used with the Free Pascal iOS compiler. Embarcadero has promised its own compiler for IOS in a future version, as well as an Android option.

Cross-platform Windows and Mac lifts Delphi sales by 54%

Embarcadero has announced 54% growth in sales of Delphi and C++ Builder, its rapid application development tools, in 2011 vs 2010. These tools primarily target Windows, but in the 2011 XE2 edition also support Mac and iOS applications. XE2 also added a 64-bit compiler, making this the most significant Delphi release for years. The company says that the 2011 figures come on top of 15% year on year growth in the previous three years.

This is encouraging for Delphi developers, and well deserved in that Delphi still offers the most productive environment for native code development on Windows. The cross platform aspect is also interesting, though the FireMonkey framework which enables it is less mature than the old VCL, and there are many other options out there for cross-platform apps. FireMonkey does not yet support Android or other mobile platforms apart from Apple iOS.

2012 is also the year of Windows 8, raising the question of whether Delphi and C++ Builder will support the new Windows Runtime (WinRT) in future, and if it does, whether this will be FireMonkey only, or whether it could work with a XAML-defined user interface.