Delphi and the myth of .NET purity

Sunday, May 30, 2004 02:27 PM

Scott Hanselman writes in an MSDN article, titled "The Myth of .NET Purity, Reloaded":

Why spend 18 months converting your application, so you can arrive at the endpoint you're already at?

The article discusses the myth of ".NET Purity" - the idea that all .NET application must rely only on the .NET framework, without any COM interoperability or Win32 API calls. It's a myth because, as Hanselman reminds us, the framework itself relies heavily on both COM interop and Win32 API functions.

The .NET framework is indeed a platform, but it's not an operating system. Many people get the two concepts confused, and assume the .NET framework will eventually replace Windows. If that was the case, Hanselman notes, Microsoft would have marginalized their investment in the Windows platform. Instead, Microsoft is actively developing the operating system, while exposing many new capabilities as managed APIs. That's because Windows isn't going away, but there are significant advantages to managed code and to the Common Language Runtime. Managed code relieves developers of many of the difficult and error-prone tasks of memory management, lifetime management, and access to system services. The CLR provides a common base for interoperability, and the FCL provides a rich, language-independent and object-oriented API.

The article makes two very good points:

• There's nothing wrong in invoking COM objects or calling Win32 functions from a .NET application. In fact, the .NET framework itself does it all the time.
• Therefore, it makes very little sense to spend a lot of resources converting an application to pure managed code. A hybrid solution, using both managed and unmanaged code, can be far more efficient.

It occurred to me that the article makes a very strong case for Borland Delphi and VCL for .NET.

Delphi for .NET produces 100% managed IL code, and can be used to create any type of .NET application. A Win32 version of Delphi is also available, and produces 100% native code. Delphi for Win32's RAD capabilities are based on the VCL, a powerful and mature component library, comparable with .NET's WinForms. There are a lot of VCL-based applications out there, and lots of components, too.

The VCL was originally developed for Windows, and relies heavily on Win32 API function and messages. While there are many similarities between the .NET framework and the VCL (hardly surprising, as some of the designers of the VCL were also involved in the framework's design), the frameworks are too different to be made compatible. It would not be feasible, for example, to rewrite the VCL to sit on top of WinForms.

There is nothing, however, preventing a VCL application from using any of the other .NET classes. In fact, it's even possible to host WinForms controls on a VCL form. By building a VCL for .NET application, you lose nothing the .NET framework has to offer, and you can gain a lot. Also remember that if you still don't want to use the VCL, that's OK. Delphi fully supports the development of WinForms applications. For more information about VCL for .NET and its purpose, see Danny Thorpe's article at BDN.

Let's consider three groups of developers, and see what Delphi and the VCL can do for them:

1. Delphi developers targeting both Win32 and .NET

That's easy. VCL for .NET is highly compatible with VCL for Win32, and the Delphi language on .NET is highly compatible with the Win32 version. A lot of applications can be ported simply by recompiling, although most applications will require some minor modifications because of the move to a safe, managed environment (component, which live "closer to the metal", may obviously require additional work). Once these modifications are made, however, you can have code that is fully compatible with both Win32 and .NET. No other tool provides this ability.

2. Delphi developers targeting only .NET

Some Delphi developers about to start new projects in .NET are considering moving to C#, which is the most visible language in the .NET universe. Others are considering throwing away their old code and starting over with WinForms. Both are valid options, of course, but neither makes efficient use of available resources.

Learning a new language takes time. Although experienced developers can probably pick up C# in a few days, it takes time to be fully proficient in any language. Learning the little details, getting used to a language's way of thinking - these things take time, which could have been spent on producing code. Why throw away your skills?

Choosing between VCL for .NET and WinForms as the visual framework for a new application is a different matter. Delphi provides both options. WinForms has the obvious advantage of being designed with the .NET framework in mind. If the rest of your application is based on the FCL, WinForms development makes a lot of sense. .NET data binding, for example, is much easier with WinForms.

The VCL, however, has many advantages, even for new .NET projects, that are often overlooked. Here are a few examples:

• VCL graphics code can render much faster than WinForms code. That's because the VCL uses the GDI, while WinForms uses GDI+. GDI relies heavily on hardware acceleration, supported by any display adapter on Windows today. GDI+, on the other hand, does not use hardware acceleration, and is therefore slower. As a result, VCL for .NET applications can be much more responsive than WinForms applications.
• VCL for .NET provides direct access to Win32 functions and messages. While WinForms does a great job at abstracting some of the underlying Win32 messages, its implementation is still incomplete. For example, non-client area messages, such as WM_NCCALCSIZE and WM_NCPAINT are not available to WinForms controls.
• Delphi includes the full source code of the VCL. The source code is invaluable. Not only can you fix critical bugs without waiting for a service release, but you can use the source to learn how things work.

3. Non-Delphi developers (or potential Delphi developers)

Delphi is also extremely attractive for new developers: the ability to support both Win32 and .NET, and the choice between the mature and flexible VCL framework and the native WinForms architecture, are capabilities not supported by any other major .NET development tool.

In short, not only is Delphi an attractive option for .NET developers, but the VCL is also much more than a compatibility layer.

The only thing missing is the availability of the VCL for other .NET languages. Phil Gilmore suggests adding the VCL to C#Builder. This makes a lot of sense: Delphi for .NET and C#Builder already share an IDE, so integrating the VCL form designer doesn't seem impossible. C# developers will finally be able to choose between frameworks. It might even be possible to support other languages, although making the form designer support them might be difficult. Still, even today the VCL's form designer already supports both Delphi and C++ (on Win32 and Linux). Sounds interesting.