Hydra is an application framework that allows developers to create modular applications that can mix managed (.NET) and unmanaged ("native" Delphi) code in the same project, creating a seamless user experience while combining the best technologies available from either platform.
Hydra 4 bridges the gap between the worlds of unmanaged Delphi code and the Microsoft .NET and Silverlight platforms by letting developers integrate the 2.5 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
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 4 – provided in one SKU for both Delphi and .NET – 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 languages 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).
Over time, 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.
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 4 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.
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 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 4; each type of host can use all the supported plugin platforms.
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.
»» VCL hosts can be created with Delphi 7 and later. Starting with Delphi XE2, hosts can support Win64 in addition to Win32.
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.
»» WinForms hosts 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.
FireMonkey is the new framework from Embarcadero 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 or Silverligght platforms, for example to leverage the technical benefits and advanced features of .NET languages such as Oxygene over unmanaged 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 provison to mix the two technologies in the same project, let alone on the same form._
But enough about Host Applications,; go on to read more about Plugins:
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:
New in version 4, Hydra now enables 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 and Visual Basic.NET.
Also new in version 4, we are introducing support for FireMonkey plugins and hosts created in Delphi XE2 or later.
FireMonkey is a new framework from Embarcadero for creating vector-based user interfaces and 3D graphics (designed after the .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 4, 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.
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 and Visual Basic.NET, as well as any other CLR-compliant language available for the .NET Framework.
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 creating 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; our 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.
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.
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 Adroid, Windows Phone 7 and Delphi applications.
»» Managed non-visual 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.
»» Unmanaged non-visual plugins can be created with Delphi 7 and later. Starting with Delphi XE2, plugins can support Win64 in addition to Win32.
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.
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 usuallhy 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 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.