You are browsing the archive for Windows.

Managed is the New Native

May 15, 2012 in .NET, Elements, Java, Oxygene, Windows

It used to be that native development referred to compilers outputting code ready to execute on the target CPU. At the time, the pool of possible CPUs was small, and the alternatives where runtime interpretation. Since then a lot has changed. Modern CPUs have multiple modes of execution (protected mode, long mode, etc.) and optionals instruction sets (SSE4a, SSE5, etc.). A “native code” compiler must choose a minimum level to target, ignoring “higher” level functionality available on newer CPUs. This leaves programs unable to take advantage of the latest CPU innovations, and often running in a legacy compatibility mode on the very CPU it targets.

What is more native on the latest 64-bit processor: 32-bit x86 code or intermediate code just-in-time compiled to take advantage of the 64-bit architecture and latest SSE instruction set? Not so simple, is it?

Managed code platforms such as Java and .NET have a “native” advantage that no unmanaged (so called “native code”) compilers can match. Because managed platforms distribute their programs in an intermediate format (Intermediate Language [IL] Assemblies for .NET and Byte-code for Java) the Just-In-Time (JIT) compiler is able to compile the program to specifically target the CPU it is running on. This means the program can scale up or down as necessary on each CPU, even a CPU that wasn’t released when you wrote the code.

A misconception is that managed applications are slower than unmanaged applications, or that managed applications are interpreted at runtime. A managed application is JIT compiled into highly optimized machine code immediately on execution.

The alternative for non-managed compilers is to compile to multiple targets and then provide software emulation for CPU instruction sets on older CPUs. The result is a more bloated program that contains emulation code that is rarely used, or a program that is unable to take advantage of the latest CPU optimizations.

Now that managed is the new native, it leaves developers free to focus on what is really important: A Native User Experience.

Profile photo of marc

by marc

What, exactly, is “native” development?

April 19, 2012 in Android, Data Abstract, Elements, iOS, Mac, Metro, non-tech, Platforms, Windows, Windows Phone

Some developers, mostly those tied to unmanaged languages such as C++ or Delphi, define nativeness as compiling directly to the byte code expected by the physical CPU. That’s certainly one way to look at it, but we think it’s imprecise, and doesn’t take into account the full picture and the complexity of today’s software systems. Consider this for example: if you compile an application for x86, and then run it on a x64 CPU – is that really “native”? Arguably not.

CPU-native, unmanaged code, is becoming less and less relevant these days, and we believe true nativeness of code, of applications, and — most of all — of the developer experience defines itself by other criteria.

Here at RemObjects, we pride ourselves on providing truly native software development solutions for a variety of platforms. We consider two different and separate levels to determine what we consider “native” development: a native user experience, and a native developer experience.

A Native User Experience

What makes a native user experience? For a long time, there was only one platform for mainstream development: Windows. This has changed, and users are, by and large, choosing their work environment by preference. Even when avoiding to get into the “OS wars”, it cannot be disregarded that each platform out there today has its own distinct user paradigms, and that customers usually choose their computing platform carefully and want their applications to work and behave well on that particular system, adhering to their platform’s paradigms.

Windows users expect applications to behave “the Windows way”, and Mac users want them to work “the Mac way”. Similarly, iOS users want applications for their iPhones and iPads that fit in with that platform’s design philosophy, and Windows Phone (7) applications once again need to adhere to completely different UI paradigms than what Android users expect from their platform of choice.

Obviously, the degree to which applications need to fit in with their surrounding platform varies — most games, for example, usually sport more esoteric and platform-independent UIs (after all, they aim to take you out of your daily routing and immerse you in an entertainment experience), while business and productivity applications usually should adhere to the platform most strictly.

Nativeness also isn’t purely driven by using stock UI controls and themes exactly as prescribed. For example, many of the most famous and most well-respected iPhone applications add subtle textures or nuances to the OS provided controls. But they continue to feel “native”, because they stick to the basic UI paradigms, and the controls — while looking visually refined — look, feel and, most importantly, behave according to the user’s expectations.

This is generally achieved by using what is often referred to as the “native widget sets” of the platforms. Whether it’s a standard Win32 “Button” control or a native Mac NSButton, each widget set provides its own unique look and feel — from the spacing of text within the confines of the surrounding rectangle, over font sizes, styles and gradient strengths and directions, to the intricate details of how the control reacts and animates when it is clicked or touched. These subtle details are ingrained in the user’s mind; the user has subconscious expectations for how the control will feel when used, often down to the timing of animations. What may seem like unnecessary attention to detail becomes crucial to the user’s experience, and the user will feel an “Uncanny Valley” effect, if their expectations are not met.

But nativeness extends beyond just user controls. Most operating systems provide a lot of general infrastructure that users are used to seeing and working with — from the standardized Open/Close or Print dialogs on desktops to OS-provided Email or Tweet sheets on phones.

We believe that in order to create a truly native user experience with your application, your development tools need to let you work with the native widgets and infrastructure of the platform. No matter how much effort is put into “one size fits all” libraries, no cross-platform button will ever truly feel like a standard Windows button, like a standard Mac button, like a standard iOS button. In order to treat your customers to a truly native application, you need to choose a development tool chain that lets you work against the native platform.

Currently, such tool chains include .NET/WPF, Metro/WinRT, Delphi/VCL (for Windows), Objective-C/Xcode (for Mac and iOS), MonoMac and MonoTouch (for Mac and iOS, respectively), Java (for Android) or MonoDroid (also for Android).

It goes without saying that here at RemObjects we try to support developers with all of these tool chain choices. On the compiler side with Oxygene, we don’t have full coverage, but we can provide support for .NET and WinRT, all the Mono variations, as well as native Java/Android with our new Oxygene for Java. With our Data Abstract product suite, we have you covered on literally each and every one of the combinations listed above.

But: we believe that a native user experience, while key, is only half the story for successful app development.

A Native Developer Experience

Back in the day when Win32 was the gold standard of operating system APIs (and before), developer tools needed to provide strong abstraction layers for developers to work against — because the OS APIs themselves were so basic that working against them directly was akin to working in assembly language (or was, in fact, working in assembly).

When tools like the later Turbo Pascals, Visual Basic, or Delphi first came out, development against the core DOS or Win16/Win32 APIs was a chore, so developers welcomed abstraction layers that made coding easier, from basic class libraries to UI abstraction layers such as TurboVision, OWL, the VCL, or MFC.

But platforms have evolved, and with the likes of Microsoft’s .NET and WinRT, Apple’s Cocoa (and Cocoa Touch) or Android’s Java-based Dalvik, OS APIs have long reached a level that is developer friendly, a level that can and should be coded directly against.

Further abstractions on top of these APIs are a distraction, not a help to the developer, as they add an extra layer of unnecessary overhead to both the application and the development experience. And such abstractions have repeatedly shown to be failures, like when VCL.NET tried to reconstruct Delphi’s well-liked class library on top of the (already much more evolved and sophisticated, but orthogonal and thus incompatible) .NET Framework (then at early version 1.1).

Unnecessary abstractions of already good (or great) APIs serve no purpose to the developers using them. On the contrary, they separate developers from the platform, and from each other. For every article, sample or blog post provided by, say, Apple or the Cocoa community that shows how to use a feature of iOS, there has to be the equivalent “and here is how you do it in MonoTouch”, “and here is how you do it in FireMonkey”, “and here is how you do it in …”. The abstraction keeps developers from being able to (re)use the platform vendor’s documentation or samples. Worse, it fragments the developer community on the same platform, keeping programmers from interacting and sharing code — every Cocoa control written in MonoTouch is a Cocoa control that can’t be easily reused by a developer using the native Xcode/Objective-C toolchain (nor by a developer using FireMonkey, or Titanium, or any other abstraction layer).

Abstractions also keep developers from adopting new platform features quickly and easily. When the latest SDKs from the platform vendor come out, developers using the native tool chains usually can start working with the new technologies from day one (or even earlier). The very moment a new Android SDK hits, native Java developers can consume the new APIs. The very day a new iOS version becomes available, Cocoa developers can start getting their fingers dirty with the new goodness. All the while developers stuck behind a non-native abstraction layer need to wait for their tool vendor to abstract the new APIs for them.

Not to mention that non-native development tools will often lock you in and force you to stick with the abstraction layer.

The main selling point and attractiveness of a non-native tool chain usually is “familiarity”, the notion that the abstraction layer will let you get into a new platform without the steep learning curve of, well, learning a new platform.

But that is misleading and frequently turns out not to be the case. The main learning curve on a new platform is usually not the development language, or even the class framework — it is getting to know the platform itself and how to write great applications for that platform (looping us back to our first criterium: the native user experience).

Working with an abstraction layer turns out to actually have the opposite effect than intended, by making it harder to understand the platform vendor’s documentation (which is all tailored towards the platform-native tools, of course) and making it harder to re-use existing code samples found online.

To go back to the example of iOS: having to look at and understand documentation or samples written for Cocoa’s Objective-C APIs might seem difficult, if one is not yet familiar with the paradigms of Objective-C. But what’s actually more difficult is having to look at that same documentation or sample and then having to figure out how it translates to your — say — C#-based abstraction layer.

And no abstraction layer is ever perfect. Eventually, the underlying platform and its APIs will leak through and will have to be dealt with. Any efforts to avoid getting to know and understand the platform before developing on it is misguided and only delays the inevitable. Eventually the abstraction is missing a feature and the developer has to dig down to the base APIs and implement it themselves. Or a bug arrises that needs more debugging than the abstraction layer supports.

As with the native user experience, here at RemObjects Software we have made it our mission to support (and encourage) developers to use platform-native development tools; you’ll notice we’ll even encourage developers to go for the more native tool chain in cases where recommending a less native solution would mean an additional sale for us.

On the compiler front, Oxygene supports platform native development on classic Windows, Metro (Windows 8) and Android, and it is also a great choice for cross-platform servers based on Mono. The one notable omission is iOS and Mac, for which we recommend the excellent Xcode and Objective-C, even though Oxygene can support it via non-native development tool chains such as Mono and MonoTouch or Java.

With the Data Abstract suite, we support native development for all current major platforms: classic Windows (via .NET and Delphi), Windows Phone, Mac and iOS, as well as Android and other Java-based platforms (Data Abstract for Java is currently in beta).

Other Concerns, Such as Code Reuse

We realize of course that other factors play into the decision for the development tool chain. Considerations such as code reuse might rank higher on the list of priorities than a native development experience, and that is ok.

Our philosophy is that, all other things being equal, developers should aim for a toolchain that is native on both accounts: user experience and developer experience. If necessary, a compromise in developer experience can be made — it is after all a compromise that affects only the developer, if pursued correctly. No compromise, in our experience, should ever be made with regard to providing a truly native user experience.

In terms of code reuse between platforms, we at RemObjects Software aim to help, both on the language front (by providing the common Oxygene language as developer-native language for .NET, WinRT and Java/Android, at least) and on the back-end database front, by keeping Data Abstract wire compatible and letting you share a common server infrastructure for all your native client applications.

Read More

You can find out more about our cross-platform, platform-native products, Oxygene and Data Abstract, at and, respectively.

And you can find an overview matrix of how our products fit into the various native (as well as semi-native and non-native, if you must go there) development chains, at

Thank you for reading, and we are looking forward to your feedback and comments.

Windows 8? We got you covered!

April 17, 2012 in .NET, Delphi, Elements, JavaScript, Metro, Month of Metro, Visual Studio, Windows

I updated this slide from //Build/Windows 2011 to show where you can use RemObjects Software’s tools with the Windows 8 Platform and Tools.

Naturally, you can continue to use our tools for Delphi and .NET for desktop application development with Oxygene for .NET, Data Abstract and RemObjects SDK. If you are using Hydra, you can even combine Managed .NET and Unmanaged Delphi for the best of both worlds.  Then, with our latest JavaScript client libraries, we also have you covered in the browser.

The part that everyone is interested in is the new Metro style apps. These are the apps designed for touch on tablets and the desktop, and running in the Metro area of Windows 8. Most importantly, Metro style apps are the only ones available through the Windows Store. We got you covered for Metro, too. The latest betas of our .NET editions work with C#, VB and Oxygene for .NET to build XAML based Metro User Interfaces. Thanks to Windows 8’s new support for JavaScript based Metro apps, you can use our JavaScript client libraries for Data Abstract and RemObjects SDK to build Metro apps based on JavaScript and HTML/CSS too.

We are not in the unmanaged Metro space yet. Currently, the only tools that are supported there are Visual C and C++, which we don’t have libraries for. Hopefully in the future we will see that gap filled in one way or another.

One important thing to point out about the JavaScript client libraries is that they ship with all editions, including our Delphi editions. That means if you currently are building solutions with DA/Delphi or RO/Delphi, you can add JavaScript Metro client applications to your solution, all with the RemObjects licenses you have today. We will soon be offering DA/JavaScript as a free separate download too.

Currently, Metro support is only available in our beta builds (which are available to all users with current subscriptions). Rest assured that we will have final versions of our Metro support by the time Windows 8 ships.

Profile photo of marc

by marc

RemObjects SDK and Data Abstract in Visual Studio 11

March 9, 2012 in Data Abstract, Metro, Month of Metro, Windows

“Native” integration for RemObjects SDK and Data Abstract in Visual Studio 11 is coming along nicely.

The IDE integration has been made independent from the .NET product, and now gets offered up for the Delphi (Visual Studio 11 and only on Windows 8 or later) and Java (Visual Studio 2012 and 11) product installers as well; the former to support JavaScript Metro clients, the latter to support Oxygene for Java.

The re-theming is also happening, with menu and toolbar glyphs and project templates getting adjusted to the new colorless Visual Studio 11 theme, as shown in the screenshot below (click to view full size).

RemObjects SDK and Data Abstract in Visual Studio 11

As of now, the icons in Solution Explorer are driven by the file type icons registered for Windows Explorer, so it’s still unclear if we can theme those individually for Visual Studio 11 (without also forcing the flat look into VS2010 and Windows Explorer, which would not be good). Something we’re investigating.

Oh, and is that a Data Abstract template for Metro that you’re seeing there? Indeed it is. ;)

The RemObjects SDK template looks have also been updated; once again i’ve decided to keep a light touch of color.

RemObjects SDK Templates



The desktop is not the OS. It’s an app

March 9, 2012 in .NET, JavaScript, Metro, Month of Metro, Windows

When everyone was in a panic about the announcement that JavaScript was pushed to be the preferred development tool for Windows 8 Metro apps, I said that as long as there is a desktop, traditional Win32 (or Win64) development will be a first class citizen, and that the Metro interface was the old concept of just the traditional “sidebar” apps (which have been developed in JavaScript for a while now), elevated to a new, more prominent status.

Well, it would appear I was wrong.

I was reading Paul Thurrott’s Windows 8 Consumer Preview: A Call For Common Sense and one point of his really stood out to me: “The desktop is not the OS. It’s an app.

He goes on to say . . .

The desktop is not the OS. In fact, while this isn’t technically true, conceptually, the desktop is just an app. The Windows 8 OS is comprised of Windows Runtime (WinRT), the Start screen shell and its Metro-style environment.

and . . .

For those many, many businesses that will rollout Windows 8 alongside Windows 7, the existing desktop environment looks and works almost exactly like its predecessor, and has no compatibility or long-term testing issues. That’s the goal for the Windows 8 desktop. All the exciting and new stuff is in Metro.

This really changes things. It means that the Desktop and traditional Windows programming has more in common with Windows XP mode on Windows 7 (running inside a virtual machine). I am not saying, nor have I heard anyone say, that the “Desktop” is running in a virtual machine, but the point is that the Desktop and traditional Windows programming is now officially “legacy”. In Windows 9 (or beyond), the Desktop may actually run in a virtual machine, or at least a sandbox.

Microsoft is replacing the familiar Windows API’s with WinRT, and this changes everything. Despite your opinions on JavaScript or .NET programming, they are now the preferred tools for developing on the Windows platform.



Profile photo of marc

by marc

Introducing the “Month of Metro”

February 28, 2012 in Data Abstract, Elements, Metro, Month of Metro, non-tech, Visual Studio, Windows

As you’ve probably heard, the first real beta of Visual Studio 11 and a “Consumer Preview” of Windows 8 are coming out tomorrow. We are very excited about VS11 and Metro, and we want to hit the ground running once the beta is available to bring Metro support to our product line.

For that reason, we are starting what we’re calling the “Month of Metro”. For the month of March, we’ll be buckling down and working on Metro support all across our teams and across all our products (where applicable). We’re planning to make weekly beta drops of our progress available to customers via our regular beta channels, and (knock on wood) to ship Metro support in an interim release at the end of March or early April.

Of course, the current releases we shipped this week already do provide basic integration into Visual Studio 11 (based on the current Developer Preview from last year’s //build/ conference); this upcoming work is focused on going beyond the existing functionality, towards new VS11- and Metro-specific features.

So what products does this touch? More than you might think:

Data Abstract and RemObjects SDK for .NET, obviously, will gain full support for creating managed Metro client applications that can talk to your servers.

Data Abstract and RemObjects SDK for JavaScript will support creating JavaScript-based Metro applications, including templates and the whole IDE experience.

Oxygene for .NET (“Emarcadero Prism”) will of course support creating managed Metro applications, WinRT components and anything else needed to make it a full member of the WinRT tool chain.

In addition, Oxygene for Java and RemObjects SDK for Java, while not directly supporting WinRT or Metro, will also benefit from integration into Visual Studio 11, of course. The same is true for Hydra.

Stay tuned to this page over the coming month for frequent updates. You can find all posts relating to the “Month of Metro” by subscribing to the category.


Profile photo of marc

by marc

Choosing the Best Toolchain for each Platform

February 4, 2012 in .NET, Android, ASP.NET, Cocoa, Data Abstract, Delphi, Elements, iOS, Java, JavaScript, Mac, Metro, Mono, MonoTouch, non-tech, Oxygene, Platforms, RemObjects, Visual Studio, Windows, Windows Phone, Xcode

Four or five years ago, the software world was simple: if you were a commercial software developer, you were developing for Windows. But this has changed drastically with the advent of mobile platforms such as iOS and Android, the steadily increasing market share of Macs, and the establishment of new development paradigms such as rich web applications hosted in browsers.

Here at RemObjects, I field the majority of so called “sales related” emails (that is, emails that aren’t technical support requests handled by our excellent support team and the product developers) myself — and as this century gets older, I see more and more requests asking what tools and toolchains to pick for different platforms. “Can I develop for both Windows Phone 7 and Android with Oxygene and share code?” — “Which version of Data Abstract is best for targeting iOS?” — “Should I use Oxygene for .NET with MonoDroid or Oxygene for Java for my Android app?”.

There are a lot of great development tool chains for the different platforms out there — be they Xcode/Cocoa, Visual Studio/.NET, Delphi, JavaScript — and sometimes the decision does not seem easy, because here at RemObjects we provide editions of most of our products for various development platforms, and often more than one choice can be applied to a specific platform need.

To help make heads and tails of this, we created a small graphical overview chart on our website that gives insight into which language/framework/product combinations we support on any given platform and — more importantly IMHO — which combination we recommend.*

[*And that recommendation might not always be what you think — for example, I often get looked at weirdly when I recommend Xcode over our own Oxygene (plus Mono) for Mac development. But development tools, even versatile ones such as Oxygene, or Delphi, or Visual Studio, are not and should not be Jacks of all Trades, and thus no single tool, no matter how great (and we happen to think Oxygene is pretty great ;) can be the best choice for all scenarios. We acknowledge and honor that.]

You can find this overview matrix — which will be ever-expanding as time goes by and the development world around us changes — at; i’m also including a static screenshot of it, below.

May it help you to choose the best set of tools for your needs!

Profile photo of marc

by marc

Hydra 4 and Oxygene January 2012 Releases

February 1, 2012 in .NET, Android, ASP.NET, Cooper, Delphi, Elements, Hydra, Java, Oxygene, Visual Studio, Windows, Windows Phone

We’re hitting the ground running for 2012 and finished January with the first two product releases of the year.

Hydra 4

Hydra 4 is a major new release for our .NET/Delphi cross-platform product, and one we’re very excited about. Hydra has been at version 3 for a while now and seen mostly incremental changes, but with version 4 we’re adding three major new features/platforms to the mix:

  • Support for 64-bit Delphi Host Applications and Plugins
  • Support for FireMonkey Host Applications and Plugins
  • Support for hosting Silverlight-based Plugins

Compiling true 64-bit Windows applications has been on the wish-list for Delphi developers for a long time, and Delphi XE2 finally provided the elusive support, and Hydra has been updated to match. This makes it easier to build applications that use large amounts of memory, can interact with .NET plugins in 64-bit space, or simply run more natively on the 64-bit Windows systems that are standard these days.

FireMonkey is Embarcadero’s new framework for creating rich “HD” or 3D graphical user interfaces in Delphi, and it is destined to supersede the VCL sooner or later. Unfortunately, Embarcadero does not let applications mix FireMonkey (FMX) and VCL by default — but that is no reason to jump ship to FireMonkey and discard all your existing VCL code. Hydra adds FireMonkey to its list of platforms supported by plugins and lets you seamlessly mix new FireMonkey UI alongside existing VCL code or even among WinForms and WPF. And FireMonkey host support lets you create new FMX applications and integrate existing VCL (or WinForms and WPF) code and UI into them, as well.

Finally, there’s Silverlight, Microsoft’s platform for rich web controls and (more prominently, as of recent) Windows Phone 7. Silverlight is based on the same concepts as .NET but uses a smaller and a tad more limited runtime — in exchange it can run in Browsers on Windows and Mac, as well as on Microsoft’s new phone platform. With Hydra 4, Silverlight can now also run in your Delphi (or .NET) based host applications, alongside other plugins. This allows you to easily share code and visual elements between your web application and your desktop app, or between your phone and your desktop.

We think Hydra 4 will be an essential tool for the modern Delphi developer — whether to add .NET to your Delphi projects or to add FireMonkey.

Hydra 4 is a free update to all users with an active subscription and available for immediate download. If your subscription expired before January 27, you can renew now for $249 to get access to Hydra 4; the price for new users is $499, including on year of free updates (and we do have more exciting stuff planned for Hydra in 2012!). Of course Hydra 4 is also included in the Suite Subscriptions for both .NET and Delphi.

Oxygene — January 2012 Release

Last November, we shipped a major new release of Oxygene, introducing the brand new Oxygene for Java as second platform for everyone’s favorite modern Object Pascal.

After skipping the holidays, we’re back to our monthly release cycle, and the January 2012 release kicks the year off with a large range of fixes and enhancements for both .NET and Java/Android developers. Altogether, the change log contains over 170 improvements.

The new Oxygene build is a free update for all customers with an active subscription, including all users of Prism XE2 and RAD Studio XE2.

For those of you using Oxygene for both .NET and Java, the update (like all future updates) is a combined installer — it will automatically detect if you have both editions of Oxygene and update both.

Get Em While They’re Hot

Head over to our trials download page at now to give Hydra 4 or Oxygene a spin. Or if you’re already a customer, visit the downloads page on your customer portal to get the latest versions.

Oxygene and Hydra go great together by the way. If you’re a Delphi-only developer right now but thinking about adding .NET code to your application, Hydra makes that easy, and Oxygene lets you keep using the familiar Object Pascal language, even for your .NET work.

CodeRage 6 – Data Abstract: Cross-platform Database Applications

October 25, 2011 in Data Abstract, Delphi, Mac, Windows

Miss my CodeRage 6 session on Cross-platform Database Applications with Data Abstract and Delphi XE2? Not to fret, you can watch it here.

It shows how to use Data Abstract with Delphi XE 2 and FireMonkey live bindings to create a cross platform application and deploy to the Mac. Also outlines some of the benefits of Data Abstract, including DA SQL, business rule scripting, Relativity Server and the new Data Abstract Server Explorer.

I’ve used the YouTube annotations to let you jump to just the parts you want to see. Turn on annotations if you don’t see them.

Profile photo of marc

by marc

Prism & Oxygene: The “September 2011” Release and Beyond

October 3, 2011 in .NET, Build System, Cooper, Elements, Java, Metro, Oxygene, RemObjects, Visual Studio, Windows

This blog post is a bit of two things: an announcement of a new Prism update release, and a look at our development model for Oxygene for the next few months with a look at what’s to come next.

The Prism / Oxygene for .NET “September 2011” Release

As you all know, at the end of august we shipped version 5 of our Oxygene compiler for .NET in Embarcadero Prism XE2. This release marked a complete rewrite of the compiler (and much of the related IDE code), so in many ways, this was almost a “1.0” release. As such, we felt the need to prepare for being able to deliver quicker and more frequent updates rather than letting you all wait until April for the next update.

The first fruit of that is our new “September 2011” release which we promoted and RTMed last friday; the release is available from our Licensed Downloads section now and should be making its path thru Embarcadero and be available from their end as well within the week.

“September 2011” is not a feature release, meaning it contains only bug fixes and stability improvements – over 75 of them. You can see the full change log here. This means it should be 100% safe for any user of XE2 to update to, and in fact we strongly recommend that you do.

Getting Updates from RemObjects

Incidentally, a lot of people have asked us recently whether they can get support and updated builds of Prism directly from us. We’re happy to oblige, and we have put new infrastructure in place on our customer portal that allows you to register your Prism XE2 serial with us (if you didn’t buy Prism XE2 from our online shop in the first place; which you really should ;).

Just create an account with us (or log in with your existing account, if you already have one), put in your serial, and you’re all set.

Benefits of registering your serial with us include:
* Direct access to new builds from our Customer Portal, often before they are available from Embarcadero.
* Access to the beta program for Oxygene with (usually) weekly gamma or beta builds (more on that below).
* Support for Prism from our staff.

The (Short Term) Future Roadmap for Oxygene

So what’s next for Oxygene? As you know, development for “Cooper”, our flavor of Oxygene for Java, is in the works and scheduled to see the light of day, soon.

Let’s have a look at what we have planned, and also use that opportunity to get a behind-the-scenes glimpse at our development model (expanding on my previous post about git branching).

Right now, development of Oxygene is happening on two main branches, as shown in the diagram below. On the “stable” branch, we are continuing with bug fixes and (small) enhancements for Oxygene for .NET; on the “develop” branch, we are working on Cooper. Of course, all the fixes we do on “stable” get merged back into “develop” frequently, so the Cooper codebase is a true super-set of the Oxygene for .NET codebase right now.

We are planning to keep doing monthly non-feature release of Oxygene for .NET (i.e. Prism) based on the “stable” branch, at least for October and November – and possibly into 2012 as well (although we will be skipping December, because the end of December is an odd time to do a release, with the holidays, vacation times and all). We will have weekly “gamma” builds for those available to all registered users (see above). These gamma builds will give you early access to the fixes we’re making; they should be safe to install, but do not go thru the full QA cycle a “master” release would. (Gamma releases are particular useful for you if we fixed a bug that is biting you.)

At the same time, we’ll also keep doing weekly “beta” releases for our Cooper pre-order customers.

Shortly before the “November 2011” release, we are planning to merge the Cooper codebase up into “stable”, so the November release will unify both Oxygene for Java and Oxygene for .NET (for which we use the code name “Echoes”) in one place. Moving forward from November, every public release we build will support .NET and Java from the same bits.

The two-brached development approach will continue though, with bug fixes (now for Prism and Cooper) going on “stable” and new feature development happening on “develop”. If we keep releasing monthly interim releases, they will come from the “stable” branch. Come next spring, when it’s time to do our next feature release, “develop” will once again merge into “stable”.

Of course, feature development beyond the Cooper RTM in November is already going on in sub-branches off “develop” – illustrated by the “develop-x” branch in the diagram above. Once those are ready (and once Cooper has been promoted to “stable”) these will be merged up to “develop”, and come into an upcoming beta build; similarly, some work is being done off the “stable” branch – illustrated by “stable-y” in the diagram – and might or might not be promoted for inclusion into a monthly interim build. One such example which I mentioned in my post yesterday is the base Visual Studio 11 support, currently in “stable-feasture-vs11” (while WinRT support and more advanced Metro and VS11 integration and .NET 4.5 language features are happening in “develop-feature-winrt” and “develop-feature-net45”).

If things go well, experimental Visual Studio 11 support might go into the October 2011 release.


So to summarize:

  • We recommend you update to the new “September 2011 release”.
  • Make sure to register your Prism XE2 serial with us!
  • Lot’s more work ahead for the next half year ;)

Make sure to visit to learn more about Oxygene.