October 27, 2006

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.





 

5 Comments

Mixed-Mode Delphi? Not For Me 

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. ;)
Comment by Brian Moelk [http://www.brainendeavor.com] on October 27, 17:20

Mixed-Mode Delphi? Not For Me 

 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.
Comment by Charlie on October 27, 17:57

Mixed-Mode Delphi? Not For Me 

 Brian - very well said. I too very much value 
Marco's opinion (I have all his books), but I 
disagree with him on this one.
Comment by Charlie on October 27, 18:02

I totally agree with Marco on this... :-) 

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. :-)
Comment by Marco Breveglieri [http://www.marco.breveglieri.name] on October 28, 03:47

Where the Compilers? 

 Hi Marco, where the compiler all versions 1-7?
Comment by Claudio Agra - Campina Grande-Pb [http://www.nohas.com.br] on August 24, 12:55


Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.