Hydra bridges the gap between the worlds of unmanaged Delphi code and the Microsoft .NET and Silverlight platforms by letting developers integrate the 2 platforms seamlessly within the same application – whether by reusing Delphi code in new .NET applications or extending exiting Delphi VCL apps with new parts created in .NET, Silverlight or FireMonkey.

Combining Delphi and .NET
These days, many Delphi developers consider migrating to the .NET platform, either to make use of its advanced development capabilities and better languages or to leverage new technologies such as the Windows Presentation Foundation or LINQ. At the same time, they are rightfully hesitant to leave the existing investment in their extensive Delphi code base behind.

Hydra – provided in one SKU for Delphi, .NET and Island – enables you to keep your investment in your existing native Delphi code base, while at the same time opening your applications to managed plugins. This allows new development to happen in .NET, for example using C#, Oxygene, Visual Basic.NET or any other language available for .NET.

At the same time, the existing code can be kept and maintained in Delphi, and both parts can contribute to what appears to the end user as a single, unified application.

This makes it possible to employ new and emerging .NET technologies within your existing Delphi-based application frame. For example, you might decide to implement fancy diagrams using the hardware-accelerated Windows Presentation Foundation (WPF) introduced in .NET 3.0 (as in the example shown on the left) or XE2's new FireMonkey. Or maybe you want to leverage technologies such as LINQ in your non-visual data processing code and show the results in your Delphi app.

Hydra is also helpful for migrating applications to .NET altogether, in a step-by-step fashion. Developers can start by modularizing their existing Win32 code base and extend it with .NET code or port selective modules over to .NET, where it makes most sense (for example those modules that still see most active development and would benefit most from using new, .NET-based development technologies).

Gradually, they can elect to port and replace the remaining modules (and even the host application) over time and at their own pace. They can keep working on the project in mixed-mode, or eventually migrate to a fully managed solution, once all parts are ported.

Combining Delphi and Island
Another interesting scenario, new in Hydra 5, is to extend a Delphi application with new code compiler using Elements' new Island platform in Elements 9.1 or later.

Using Island, Delphi developers can start extending their application with code written in Oxygene (which is similar to Delphi in style, but much more expressive and advanced) or C# and Swift, without giving up the benefit of being 100% unmanaged. Island code compiles CPU-natively to x64 or i386 assembly – just like Delphi – and does not require any runtime. But it still gives you all the breadth and language features of the more modern languages, along with our Elements RTL, and our Delphi compatibility class library (Delphi RTL).

Starting with a few Island plugins written in Oxygene is the perfect way to get your feet wet with Oxygene, and to be more productive coding than ever before.

Combining .NET and Island
Similarly, .NET developers will find it interesting to extend their existing .NET apps with native Island plugins — being able to use the exact same language they already use and love, whether it's C# or Oxygene.

Add some native code pieces to your application – for example an algorithm that has been fine-tuned to run in native code, or bits that access hardware and must run unmanaged – without having to learn a new language and/or steep down to C++.

Combining .NET and Java
New in Hydra 6, .NET hosts also support the embedding of Java plugins, with visual (using Swing widgets) and non-visual (to run Java-based logic behind the scene). Hydra takes care of hosting the Java Virtual Machine and everything else.

Combining VCL and FireMonkey
With Delphi XE2, Embarcadero introduced FireMonkey, a new framework for building rich 3D and vector-based graphical user interfaces using unmanaged Delphi code – comparable to what WPF offers on the .NET side. Unfortunately, the VCL and FireMonkey don't mix well, so once again developers are asked to leave their existing investment in VCL application code behind to adopt the new technology.

Hydra provides a solution for this problem by allowing developers to integrate FireMonkey UI seamlessly with their existing VCL applications, or conversely add existing VCL user interfaces into new FireMonkey apps. FireMonkey code can even be used with VCL code compiled in different versions of Delphi – so they can for example extend a Delphi 7 VCL application with new FireMonkey functionality, without porting the entire project to XE2.

And of course this works together with .NET and Silverlight plugins as well, letting you combine all of VCL, FireMonkey, WinForms, WPF and Silverlight in the same application, if necessary.

Inter-platform communication
Plugins and host created using different development platforms can communicate seamlessly using custom interfaces you can define, and Hydra's IDE integration in Delphi and Visual Studio lets you seamlessly port these interface definitions between the two platforms.

You can define your custom interfaces in Delphi code, and let Hydra's toolchain parse the code to generate the necessary interface definitions in C#, VB, Oxygene or any other .NET language. Or you can define your interfaces in .NET and let Hydra import them into your Delphi project.

Host and plugins can communicate using these interfaces without needing to be aware of the platform differences.

Hydra Host Platforms
Hydra applications consist of both plugins and hosts, both of which can be implemented using a variety of different development tools and UI frameworks that can be combined seamlessly. This page takes a look at the three different host platforms supported by Hydra; each type of host can use all the supported plugin platforms.

Delphi's Visual Component Library (VCL)
Probably the most common use case for Hydra today is a host application written in Delphi using the VCL and hosting plugins created either with the VCL as well, or using any of the other plugin platforms we support. Common reasons and scenarios for creating this type of applications include:

♦ The desire to build a dynamic application that can be expanded with new functionality simply by adding additional plugins that conform to the same well-defined API (with or without taking advantage of the different plugin platforms).

♦ The need to extend an existing Delphi VCL application with elements that are more easy or convenient to implement using other platforms, for example to leverage the rich UI capabilities of WPF, Silverlight or FireMonkey, or the technical benefits of .NET languages, when writing new code.

♦ The ability to start a piecemeal port of a legacy Delphi application to .NET by first modularizing it, and then porting individual plugins to .NET, optionally concluded by a port of the host application itself.

♦ The abilit to use more modern language features of Oxygene (or C#) to extend parts of a Delphi application, while still using native code, with Island.

»» VCL hosts can be created with Delphi 7 and later. Starting with Delphi XE2, hosts can support Win64 in addition to Win32.

.NET's Windows Forms
Just as with the VCL for Delphi, WinForms is, to date, the prevalent framework for creating applications using the standard Windows user interface controls on the .NET platform. Reasons for turning your WinForms application into a Hydra host include:

♦ Wanting to expand a WinForms app with user interface elements that are more easy or convenient to implement using WPF or FireMonkey, for example to add visually rich and stunning graphics for data visualization or other purposes.

♦ Needing to reuse legacy business logic or forms implemented in Delphi, without the need to port over to a .NET-based language.

♦ Providing a modular application that can be expanded dynamically with new functionality by adding additional plugins (whether purely based on WinForms or leveraging any of the other plugin platforms).

♦ Having concluded a piecemeal port of a legacy Delphi application to the .NET platform by concerting the host application.

♦ Including code or algorithms compiled to CPU-native code via C#, Oxygene of Swift for Island in a .NET application.

»» WinForms hosts can be created in Visual Studio using C#, Oxygene, Swift and Visual Basic .NET, as well as any other CLR-compliant language available for the .NET Framework.

Delphi's FireMonkey
FireMonkey is the newer framework in Delphi XE2 and later for creating rich vector-based user interfaces and 3D graphics, similar to .NET's Windows Presentation Foundation, using Win32 or Win64 Delphi code.

♦ Reuse existing business logic or forms that use the VCL in your new FireMonkey application, which Delphi does not support out of the box.*

♦ Create an extensible application that can load new functionality at runtime from plugins conforming to a common set of APIs defined by your app (whether they are all based on FireMonkey, or leverage other technologies as well).

♦ Extend a FireMonkey application with elements that are more easy or convenient to implement using the .NET, Silverlight or Island platforms, for example to leverage the technical benefits and advanced features of more modern languages such as Oxygene or C# over Delphi code.

»» FireMonkey hosts can be created using Delphi XE2 or later and are supported for both Win32 and Win64.

(Without Hydra, Delphi applications either use the VCL or FireMonkey, with no provision to mix the two technologies in the same project, let alone on the same form.)

Hydra Plugin Platforms
Hydra applications are made up of a host application that loads individual plugins, either installed as part of the host application or distributed separately. Host and plugins can (but do not have to) be written using different development platforms and UI technologies.

There are two distinct scenarios why you would want to leverage Hydra plugins in your application:

♦ Create an extendable application that can load various plugins at runtime. For example, an audio application might load additional filters from plugin dlls.
♦ Embed different technologies in what, to the end-user, will look like a monolithic application. For example, a VCL business application that uses WPF to graphically visualize data.

Island
New in Hydra 6, you can now leverage legacy Java code in your .NET applications by hosting the JVM and visual or non-visual Java plugins created with Hydra for Java (using Oracle's Java compiler, or Elements).

»» Java plugins can be created using any Java development tool including IntelliJ or Eclipse, as well as in Fire, Water or Visual Studio, using Elements.

Island
New since Hydra 5, Hydra lets you leverage the new native Island platform of our Elements compiler to write visual and non-visual plugins using the Win32 API and native Windows code, and embed them in your WinForms, VCL or FireMonkey host applications. This allows you to share the same languages between your .NET and unmanaged code, or to use more modern language features for unmanaged code in your Delphi apps.

For example, a C# developer might want to compile some algorithms to native i386 or x64 code, but not give up the comfort of writing said code in C#.

Or a Delphi developer might want to start exploring Oxygene as a more expressive and sophisticated language to write a new part of their application in, without having to rely on .NET.

»» Island plugins can be created in Visual Studio and Fire, using Oxygene, C#, Swift, or Java.

Silverlight
Since version 4, Hydra has enabled you to create visual plugins using Silverlight and embed them in your WinForms, VCL or FireMonkey host applications. This allows you to share code between your Silverlight-based web application or your Windows Phone app, and your desktop app.

For example, you might create a rich data entry form in Silverlight for your project's web front end and reuse the same form inside your desktop app, created using Delphi's VCL or FireMonkey, or using .NET's WinForms.

»» Silverlight plugins can be created in Visual Studio using C#, Oxygene for .NET Visual Basic .NET or Swift.

FireMonkey
Also as of that version, support for FireMonkey plugins and hosts created in Delphi XE2 or later has been available.

FireMonkey is a new framework from Embarcadero for creating vector-based user interfaces and 3D graphics (designed after .NET's Windows Presentation Foundation) using Win32 or Win64 Delphi code.

Out of the box, Delphi does not support mixing the traditional VCL and FireMonkey in the same application, but with Hydra, you can now embed visual plugins created with FireMonkey in your VCL application, alongside all our other plugin technologies. What's more, you can also embed FireMonkey plugins in your WinForms based .NET host applications, as well.

For example, you might want to create a visual representation of a 3D model using FireMonkey rich three-dimensional options, and embed it into a more traditional line-of-business application built using the VCL or WinForms.

»» FireMonkey plugins can be created using Delphi XE2 or later and are supported for both Win32 and Win64.

Windows presentation Foundation (WPF)
Similar to the new FireMonkey framework, Windows Presentation Foundation (“WPF” for short) is a modern, vector based UI framework for creating rich and stunning user interfaces leveraging modern graphics and 3D effects.

First introduced with .NET 3.0, WPF is slowly but steadily replacing WinForms as the standard UI model for .NET developers.

Hydra lets you embed WPF-based plugins into your VCL, WinForms and FireMonkey host applications. For example, you might want to create a visually rich chart view using one of the stunning charting components available for WPF, and embed it into an existing business application created with regular WinForms or VCL.

»» WPF plugins can be created in Visual Studio using C#, Oxygene for .NET, Visual Basic .NET or Swift, as well as any other CLR-compliant language available for the .NET Framework.

Visual Component Library (VCL)
The Visual Component Library (“VCL” for short) has been the standard way for developing great user interfaces for Windows with Delphi since its first release in 1995, so it goes without saying that Hydra fully supports the creation of plugins using the VCL, both to be embedded in VCL hosts (possibly alongside other plugin technologies, such as WPF or Silverlight), but also in host applications created using the new FireMonkey or .NET's WinForms.

For example, you might have some existing user interface created in Delphi that you want to reuse in a new WinForms-based application without rewriting the UI and the underlying code in a .NET language; or you might wrap VCL code in a plugin to be used transparently and interchangeably with plugins created using .NET or FireMonkey, within a VCL application.

»» VCL plugins can be created with Delphi 7 and later. Starting with Delphi XE2, plugins can support Win64 in addition to Win32.

Windows Forms
Although slowly being superseded by WPF, WinForms is still the default framework for building Windows user interfaces with the standard Windows widgets for .NET developers and provides a rich environment of first and third-party components for building application UI. Hydra lets you encapsulate WinForms UI in plugins and embed it in unmanaged Delphi VCL and FireMonkey host applications, as well as (usually alongside plugins created using the other technologies) in WinForms apps.

For example, you might want to extend an existing legacy Delphi application by writing new code with .NET and WinForms and use it alongside your existing codebase – possibly with the long-term goal to port the existing portion of your application over to .NET piecemeal.

»» WinForms plugins can be created in Visual Studio using C#, Oxygene for .NET and Visual Basic .NET, as well as any other CLR-compliant language available for the .NET Framework.

Non-Visual Plugins
In addition to all the visual plugin formats described above, Hydra also lets you create non-visual plugins that merely contain business-logic or other functionality that you might want to share between platforms. Non-visual plugins can expose their functionality using custom interfaces; they can be implemented using .NET or Delphi, and both kinds of plugins can be used in either type of host application.

For example, you might have existing business code implemented in Delphi that you want to reuse in a new .NET-based application, without porting it to Oxygene or C#. Or you might have found some great open source code written in C# that solves a problem you need to solve, and you want to use that code in your Delphi-based application. Or maybe you want to implement some core business logic code in Oxygene, and then share it between your Android, Windows Phone 7 and Delphi applications.

»» Managed non-visual plugins can be created in Visual Studio using C#, Oxygene for .NET, Swift and Visual Basic .NET, as well as any other CLR-compliant language available for the .NET Framework.

»» Unmanaged non-visual plugins can be created with Delphi 7 and later, and with C#, Oxygene and Swift in Elements 9.1 or later. Plugins can support Win64 (in addition to Win32) when created with Delphi XE2 or later or with Elements.

Plugin Platforms: 32-bit and 64-bit
Starting with Delphi XE2 (and later), Hydra supports the creation of unmanaged plugins (and hosts) for the 64-bit Windows platform, using both the VCL and FireMonkey. 64-bit plugins are also supported when using the Island platform with Elements.

Within a single process, Windows does not allow the mixing of 32-bit and 64-bit code, so the bitness of host application and plugins has to match - a Delphi Win32 host application can only host plugins compiled for 32-bit, and conversely, a Delphi Win64 application can only host plugins compiled for 64-bit. Since .NET plugins are (by default) CPU-independent, they can usually be hosted in either 32-bit or 64-bit hosts.

By default, .NET hosts can run under 32-bit and 64-bit, determined by the operating system platform and hardware they are being run on; depending on which bitness a .NET host runs under, it can only load Delphi or Island plugins that match its bitness. To ensure unmanaged plugins can be loaded, they can either be provided in two versions, for 32-bit and 64-bit, respectively, or the managed host application can be forced to a specific CPU type using the appropriate flags in the managed host project.