Tag Archives: embarcadero

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.

Windows 8 sideloading and Embarcadero’s Metropolis fake-WinRT framework

Embarcardero’s John Ray Thomas and Jason Vokes spoke to me about the company’s forthcoming RAD Studio XE3 development tool and in particular the new Metropolis framework which creates apps that have the appearance of a Windows 8 “Modern UI” (formerly known as Metro) but which are really desktop applications. Metropolis works with both the Delphi/C++ Builder VCL (Visual Component Library) and also with the newer FireMonkey user interface library.

“It’s a pretty large effort for us to get our compilers and runtime over to WinRT – which we intend to do”, said Thomas. In the meantime though, he argues that “Metro is just a style” and that developers will welcome the ability to “get their desktop apps over but participate in the Metro look and feel.”

End-users, explains Thomas, will not care about the WinRT or Win32 technology, but only notice that some apps have the new style and some do not. “We took the VCL and FireMonkey frameworks and used the styling engines that we introduced in XE2 to allow them to modify the forms to take on the look of those controls, as well as adding features like Windows 8 gesture support, improving the touch handling, and also taking on some of the standard templates like the grid and split views.”

Metropolis also support Live Tiles with update of dynamic content, and even enables apps to show up in the Windows 8 App Bar (which most desktop application do not support). This is done by means of a small WinRT app that is installed with the Metropolis application, and which communicates with it over a REST API – there being no built-in inter-process communication between desktop and WinRT apps. The WinRT app is a kind of proxy that lets the user launch or close the desktop Metropolis app. However access to Windows 8 contracts is not supported. “I think we’re hitting on the key elements that end users are going to expect when they’re working with WinRT applications,” says Thomas.

There is also the issue of how to deploy Metropolis apps. They will not be accepted by the Windows Store (other than perhaps as links to a vendor’s site as with other desktop apps), so how will software vendors get them onto a user’s machine? Getting the Win32 part installed is easy using standard Windows setup tools, but what about the WinRT component, if it is used? The procedure for installing a WinRT app without using the Store is called sideloading; and Microsoft intends that it only happens either for development and testing, or for enterprises deploying line of business applications.

“Sideloading requires a digital certificate and using a Powershell script that we provide to do the deployment,” says Thomas. “They can make that part of their standard desktop installer.”

Clever stuff; but will it work? I did some of my own testing. The most detailed technical article on WinRT app deployment is this one, which describes the  add-appxpackage PowerShell command which I presume Embarcadero is using. Using a Windows 8 Professional machine which does not have a developer licence installed, I was able to install my own WinRT app by trusting the certificate generated by Visual Studio as part of the Appx package, and after setting the key:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1

However, although the app installed it did not run.

image

The reason is this:

The computer does not have to be joined to a domain or have an activated sideloading product key before you install provisioned LOB apps. However, the apps will not run until the computer meets this sideloading requirement.

The key statement here concerns the activated sideloading product key. What is this? There is also a reference to it by Microsoft’s Antoine Leblond here:

To enable sideloading of a Metro style app onto a [non domain-joined] PC:

  • Set Group Policy for “Allow all trusted apps to install”. If you cannot use Group Policy, then you can set this through the following setting: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1
  • Verify that the app is signed by a CA that is trusted on the target machines
  • Activate a special product key by using a script on the target machine to enable sideloading. We’ll go into more detail about how the IT admin will acquire the product keys in an upcoming blog post. The product key only needs to be install and activated once on the PC.

The word script is linked to the reference for slmgr.vbs which is used for installing and activating Windows product keys, so although Microsoft has yet to reveal everything about these special product keys, it does sound like something which only makes sense in an enterprise context. A third-party vendor cannot mess with slmgr.vbs, which implies that sideloading will not always work.

Here is a developer who has run into exactly this problem. He wants to be able to deploy “a Win32 app that has a sideloaded WinRT component”. Microsoft’s Tim Heuer says:

I’m pretty sure you’re going to need enterprise SKUs

Maybe Embarcadero has found some setting that makes it work; but even if they have, what if Microsoft made some change to WinRT in the name of security that closes off these loopholes? Or stops the Metropolis REST communication from working?

“Our testing shows that there are switches that can enable that mode and you can set your PowerShell script to do these things,” says Thomas about the latter issue. “We’re going to be working around some of the limitations or additional constraints that Microsoft may put on their environment. We’re going to have to be active in understanding the changes, in talking to Microsoft about it, and updating it as necessary to make it continue to work in their sandboxed environment. It is their environment after all.”

Might there be security risks for the user in opening up holes to make Metropolis apps work? “I don’t think so,” says Thomas. “The WinRT side of it is really just four functions. The fact that they may allow the WinRT app to do this communication I don’t think opens up any kind of security hole.”

Despite Thomas’s reassurance, it seems to me risky to depend on a feature that runs counter to the way the operating system is intended to work.

That said, you can use Metropolis without the WinRT component, though you lose Live Tile support; and in fact such apps will run on older versions of Windows such as XP and Windows 7 as well; though you would have thought that they would make more sense for tablet users who are likely to be running Windows 8 anyway.

Update: this link suggests you could get around the sideloading problem by checking for a development license in a script and renewing if necessary. Make all your users have development licenses though? That does not sound good to me.

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.

Embarcadero previews Metropolis in RAD Studio XE3: fake Metro apps?

Embarcadero has released a video (embedded at the foot of this post) previewing RAD Studio XE3, the next version of the application development suite which includes Delphi and C++ Builder.

Two big new features are Metropolis applications and an new HTML5 Builder tool which looks like a next-generation PHP Builder.

Metropolis – a neat name until Microsoft back-pedalled on the Metro designation for Windows Runtime apps – appears to be a framework for apps that look like Windows Runtime apps but in reality are not. At least, that is my presumption for “VCL Metropolis applications”. The VCL (Visual Component Library) is a Delphi framework (usable also in C++ Builder) which is tied to Windows and GDI, the old-style Windows graphics API, along with many other Win32 APIs. GDI does not work in the Windows Runtime.

image

No matter, all we need is full-screen apps, touch input, and a don’t-call-it-Metro look and feel, and presto, Windows Runtime apps in all but name. They might even run on Windows 7.

image

A glimpse at the controls.

image

Except that there will be significant differences between Metropolis and Windows Runtime. No support for Contracts, for example, the Windows Runtime mechanism for inter-app communication; no delivery from the Windows Store; no support for Windows RT.

The big issue though is this: why would you want a desktop app to look like a Windows Runtime app? And will not users be mightily confused?

The video then goes on to talk about converting existing apps with a “Convert to Metropolis UI” menu option. It turns out though that you can also create FireMonkey Metropolis apps, and the Convert to Metropolis UI option is shown with a FireMonkey app, not a VCL app. Since the FireMonkey framework is designed for cross-platform and uses custom drawing for all its controls, potentially a FireMonkey app could be a real Windows Runtime app, though I get the impression it probably is not.

image

I do think Embarcadero needs absolute clarity here, which is notably lacking in this preview. There is no point in pretending that a Win32 app is a Windows Runtime app when it is not. I have asked for further information.

HTML5 Builder

There is also a quick look at HTML5 Builder.

image

This tool targets server-side development with PHP, as well as apps for web,iOS,Android, Blackberry and Windows Phone. My guess is that there is PhoneGap/Cordova under the covers. I also saw some jQuery in the demo.

image

Here is a look at the CSS3 colour picker.

image

Update: looks like Embarcadero found a way to fake Live Tiles as well:

Metropolis applications are really traditional "desktop" applications styled to look like the Metro UI.
The TLiveTemplate component spawns a new process in the WinRT space which is is an actual WinRT LiveTile application. The LiveTile communicates with the Metropolis "desktop" backend via HTTP/REST to start/stop the application or update the LiveTile.

The screenshots are drawn from this video, or you can watch it on the Embarcadero site here.

For more info from attendees of the RAD Studio XE3 world tour see also:

http://members.adug.org.au/2012/08/22/highlights-of-the-sydney-xe3-event/

https://forums.embarcadero.com/thread.jspa?threadID=75773

Embarcadero preparing Delphi, C++ Builder XE3 release

Embarcadero has announced a world tour to promote its forthcoming XE3 development suite.

image

But what is in it? No details yet, but a few clues:

  • Windows 8 “look and functionality” for VCL and FireMonkey apps
  • A new edition of the FireMonkey cross-platform framework, called FM2
  • A new tool called HTML5 Builder.

There are a few more clues in a leaked PDF document on what is new in Delphi and C++ Builder XE3. This refers to “full support of the Windows 8 Metro user interface” and describes new project wizards for “VCL Metro Desktop Application” and “FireMonkey Metro Desktop Application”.

Since “Desktop” normally means non-Metro in a Windows 8 context, this phrase is puzzling, making me wonder if the tool will build apps that look and feel like Windows Runtime apps, but really are not. That would be unsatisfactory, because features like Contracts and Live Tiles only work with real Windows Runtime apps. Or is Embarcadero is planning full Metro support and is distinguishing from mobile apps.

There are also changes in FireMonkey to add support for Actions, Anchors, and Layout managers. Sensor and gesture support will be important for Windows 8 apps.

Finally there will be a SQLite database driver in XE3.

All the above, save the tour announcement, is unofficial and may be wrong or subject to change. I doubt the Metro name will feature so prominently in the eventual release, for example. And Metropolis?

Update

Looking at the wording here seems to confirm suspicions that Delphi and C++ Builder are not getting true Windows Runtime support:

  • Create Delphi, C++Builder and Prism applications with Windows 8 styling and functionality
  • Create HTML5 web apps and mobile apps for Android, iOS and more with new HTML5 Builder
  • Build Windows 8 apps with WinRT using Prism XE3 in RAD Studio

Otherwise, why would Embarcadero state “WinRT” for Prism but not for Delphi and C++ Builder?

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.