Mixed-Mode Delphi? Not For Me

There has been some recent discussion about having Delphi support .NET mixed-mode, like Microsoft's C++/CLI does. I think the current Delphi .NET strategy is far better.

There has been an interesting discussion on the non-tech newsgroup that started with a request to support the so-called "mixed-mode" in the Delphi .NET compiler. Mixed-mode is a way to let you mix in the same executable (or compilation unit) managed and unmanaged code. The most relavant example of this appraoch is Microsoft's C++/CLI, introduced in some detail in this book chapter, that supercedes the earlier Managed C++.

From the C++ language perspective I think this is an interesting appraoch. Since the C++ language is really incompatible with the .NET model (or CLI, Common Language Infrastructure model) the only options are: (i) rewrite everything in C# (similar syntax, but very different language) (ii) extend the language providing new keywords and constructs. If you have a lot of code solution (ii) looks interesting. Of course, the existing C++ code will compiled to unmanaged code, while the new code you write can take full advantage of .NET.

Enter Delphi. In Delphi the native object model matches the .NET model almost exactly. This is why you can take existing Delphi Win32 code (unless you use low-level techniques, pointers, and the like) and recompile it for .NET, making it "native" and "managed". Like you were actually rewriting in C#. In Delphi you get (i) and (ii) at the same time, without having to change your class declarations or memory allocations, like C++/Cli requires you to do if you want to take advantage of .NET. This is why I find Delphi / Delphi .NET appraoch way better than the C++/CLI appraoch. Granted, the same could not be done with C++ as a language, and might be interesting for C++Builder or any future Borland C++ compiler willing to support .NET. But for Delphi, I think this wuold have been a mistake.

Mixing code. It is true that you might need to mix Win32 (native) code and .NET (managed) code. But do you really need to use a single executable? One area in which Delphi for .NET shines is in providing both a way to call Win32 code from .NET applications (P/Invoke) and a way to let your existing Win32 applications call .NET assembly libraries (Inverse P/Invoke, or Managed Exports). At the time it was released, Delphi was the only high-level language to provide this feature, don't know if C# now supports it as well

Some More Info on C++/CL

As a conclusion (I've decided to give my opinion first, this time) let me quote and comment a few relevant elements from the book chapter mentioned earlier, C++/CLI in Action by Nishant Sivakumar:

"C++/CLI improves over the now obsolete Managed C++ syntax": Microsoft has made obsolete language extensions introduced a few years ago. Think about the code investsments now lost...
"C++/CLI allows the reuse of a developer's native C++ code base, saving the agony of having to rewrite all his existing code...": in Delphi the picture is very different.
"In practice, you may find that you would have to change a small percentage of your code to successfully compile and build your applications." Even in C++/CLI compatibility is not perfect, like it is not moving from Delphi to Delphi .NET
"Imagine that you have a substantially large MFC application... Take VC++ 2005, recompile the MFC application for the CLR, change the UI layer to use the Windows Forms library". Now, in Delphi you don't have to change the UI layer. This is a huge advantage Delphi has!

Some Comments on the Newsgroup Posts

I've seen in that thread many newsgroup posts I disagree with, but also a few critical voices I agree with. Anyway,

John Kaster mentioned that "A mixed mode compiler has been discussed for more than 2 years internally." and that "There is no internal concensus. That's why it's being discussed ;)".
Kostya sais "[should have done mixed-mode] Instead of splitting product in .NET/Native so people have to make a choices instead of just hummin' along." I don't buy it: I have medium-sized app with single source I can compile both in Win32 and .NET. You don't have to choose, you can support both!
As Markus Humm mentions, Delphi supprots "unsafe code": I already achieved to get some checksum algorithm which uses pointers much running under .NET without any hassle just by declairing it {$UNSAFE ON}." This might not be the perfect solution, but it good enough in many cases.
I fully agree with TeamB'er Alisdair, summarized as: "Take another look at what you get from Delphi, and you will see that Delphi2006 already offers something significantly better in many ways".
Of relevance, Bjarne Stroustup in person corrected a poster quoting him on this topic, underlining he does not like Microsoft creating a new C++ standard, but this is at least better than having a new language with no standard at all.

That's it. Quite a long post. To summarize, I'm not saying mixed-mode won't be useful for some develoeprs. I claim the current strategy is far better.. You don't get MFC for .NET, you get VCL for .NET. And I really like having it.

Hi Marco, First, I'm an advocate for a mixed-mode compiler and plan on writing about why RSN. I have a lot of respect for you, your writings and opinions, but I disagree on this issue. ;) Here are some of my thoughts regarding your post: 1) I agree that the C++ object model is different from .NET's, and Delphi's is very similar. But from my point of view, the object model like C++ standardization (a point Alidair raised) is not the reason why a mixed-mode compiler is desireable. What's important is to look at what a mixed-mode compiler would offer Delphi developers, regardless of what C++/CLI offers C++ developers, or why they did it. IOW, the implication of those points, already presuppose that "pure" .NET support is best or the ideal goal. 2) The largest problem with Delphi for .NET's strategy is that one must port their entire codebase to .NET to leverage any part of .NET itself. However "effortless" this is, testing should be completely redone, as it's a new platform/runtime environment. In not doing so, one is placing great trust in Borland's ability to make .NET work exactly like Win32, and with similar performance characteristics. The other big problem is that it's actually not "effortless", there are many hiccups that prevent developers from embracing .NET in this way. One of the biggest is the use of third-party components. 3) Yes, Delphi has good interop already between .NET and Win32, but I believe more value will be provided if Delphi developers can mix code within the same executable, more importantly, mixing code within the same project or even unit. It's easier and integrated. Do we really need an integrated debugger? No, but it's much more productive and useful to have it work with our code editor. 4) The transition from Win32 to .NET is much more natural with a mixed-mode compiler. Developers can adopt .NET incrementally, if/when there is a reason to do so. Testing can be done incrementally. The problem with porting to .NET is that you have to do it all in one go. Also, VCL.NET offers Delphi developers nothing over VCL Win32; in fact it offers them less due to a subset of third party support and security issues. 5) It's more important to read what Nishant Sivakumar had to say about the *goals* and *benefits* of C++/CLI rather than the particular implementation details. Yes, it took MS two tries to build something that the C++ community is ok with, but Borland has had 3 with Delphi for .NET and they aren't doing anything substantially different to win the Delphi community over. ;) To focus on the C++/CLI details is a mistake, the goals and benefits of a mixed-mode compiler are the important things. 6) I don't think your paraphasing of Bjarne Stroustrup is accurate. IMO, it's best to read what he actually said. It's not long: "Sorry, but that misstate my position. I don't "endorse" C++/CLI. I just helped my friend Herb with a few technical details. I happen to applaud Microsofts effort to at least go for ECMA standardization instead of no standardization at all, but I don't like dialects and always encourage people to encapsulate the use of non-standard features (be it Microsoft's or others) as much as possible. See my FAQ." I'll have more to say in regards to a Delphi mixed-mode compiler soon. ;)

Hi Marco, The theory that a single code base would be used for both .net and win32 is a great one - I was very excited about it - until we tried to prepare our existing applications to make this work. The issue is that there is virtually no third party support for VCL.net. DevEx did convert their grids to support VCL .net (but not sure if they are maintaining them), but to my knowledge (and after exchanging emails with the CTO), they have no plans to convert any of their other controls (menus, task bars, schedules, etc.). DevEx is exactly like other component makers - why would they invest in making components specifically for the much smaller VCL.net market (especially when it requires a lot of investment), when they can them for the substantially larger C#, VB.Net and C++/CLI market? There is so much investement going into managed code libraries - DevCo should not try to compete with it (e.g., with VCL.net) - but rather make it extremely easy to leverage the investements by other companies. This would allow many Delphi developers to use the latest and most visually pleasing components to put the "prettiest face" on their existing win32 application (and pretty is what sells - show a potential client two applications with exact same functionality, one with really modern looking controls (e.g., DevEx's menus and grids) versus a stodgy VCL/VCL.net interface, the customer buys the good looking interface - I know from experience), without having to get rid of all the current win32 VCL hooks. There is also a strong business case for this in marketing applications: We use managed code for some of the highly visual aspects of the application, but utilize native for pure speed and flexibility advantages. Finally, having a mixed mode compiler does not preclude one base creating pure managed or pure native. It is the OPTION to mix the two that is attractive.

Thinking back about my past experiences of porting code from Win32 to .NET, I must agree with Marco. For a lot of Delphi developers, VCL.NET is only a Win32 VCL clone for .NET, or even a layer on top of WinForms (this is a curse!). Yes, in some sense, you can think of VCL.NET as a "managed mirror copy" of classic VCL, but it's more than that! I am currently mantaining an internal company package, filled with custom classes, components and controls, which can be fully compiled for Win32 and .NET. Going back to the main topic, I think a "mixed mode" Delphi would be useless, because 1) if you are going to target the .NET platform, you must know its architecture and "what you are doing"; there's no possibility to port pieces of code while you learn .NET, in my opinion, because it's not simply a matter of translating code for calling a different function to do the same thing: it's a totally different (and managed) platform; 2) in many situations, the code does not have to be changed, so what good is a mixed mode Win32/.NET compiler if the code can be just compiled for .NET as a whole? 3) many developers are asked for .NET applications, but other ones choose that platform because they want to leverage the CLR facilities, for example; what is the meaning of a "hybrid application" in this scenario? 4) developers can use the UNSAFE directive against the Delphi.NET compiler forcing it to "swallow" a lot of code that is difficult to port, obtaining a full .NET application, "unsafe" but .NET. Isn't this a good way to support a smoother transition from Win32 to .NET without requiring a mixed mode compiler? 5) there are too many high level ways for Win32 and .NET modules to interoperate for complaining about a missing mixed mode compiler, in my opinion: think about P/Invoke, VLI (Virtual Library Interfaces, available in Delphi only, as far as I know), COM/ActiveX wrappers and so on... I would prefer a million times encapsulating features and put them into these kind of "component boxes" instead of having a single module which behaves sometime managed, sometime unmanaged at the same time); Borland have also ported many components that wrap up a Win32 technology, like ADO, so there's no need for a mixed mode compiler for that, too: you build a full .NET application using .NET components which, at the end, talk to Win32 "flat" or COM based libraries; 6) someone complained about a small market for VCL.NET, because component makers invest on the C#/VB.NET and WinForms side, but notice that VCL.NET can make use of all .NET FCL classes, even WinForms components and thirdy part ones! (the opposite is not always true...) besides this, you can easily port lots and lots of existing Win32 VCL components and controls to VCL.NET, and these are often available for free, with source, since many years ago before .NET and WinForms came out! and they often require just some change to work, but in a totally different environment like .NET. To sum up my thoughts, I think a mixed mode compiler could be the perfect tool for a "make simple things difficult" department, especially after having seen how VCL.NET had been built: as similar as possibile to VCL Win32 in order to get existing source code ready for .NET at all and as integrated as possibile in the managed world (you can use a TMenuItem click event to add a dinamically created TButton to a Microsoft FCL.NET Hashtable object, for example). If tomorrow .NET were the only platform available, VCL.NET would be my best tool of choice. :-)

Marco Tech Blog