Re: VCL.NET revisited...

Atmapuri wrote:
If you recompile your application with VCL.NET what do you get?

The advantage is you get the .NET framework without sacrificing your
existing code. This assumes that VCL.NET is enough to recompile ones
application.

It should be stated, that VCL.NET not only applies to whole
applications, but portions of ones codebase as well.

Slow speed and more memory consumption.

This has been disputed, but there are other disadvantages in going .NET
for existing applications.

Why would you want to develope new applications with VCL.NET
or components?

I wouldn't, but some prefer it to WinForms.

1) requires access to unmanaged windows API.

Winforms does as well; the difference here is that it's trusted by default.

2.) Increased code size due to run time library

IMO, this is not a big deal at all.

3.) Is not written in C#.

It seems that many here don't buy this argument, but I agree with you
that it's significant. IMO, the big issue is not that it's not written
in C#.

The issue is that it's awkward to use from C#, so awkward that no one
would do so. Therefore, in using VCL.NET, one has effectively abandoned
one of .NET's core principles: language independence.

The more I think about it the more is VCL.NET looking like something
that was developed as an escape platform from unmanaged Delphi W32
with an assumption that once ALL Delphi programmers will see
how good .NET is will immediately abandon unmanaged code and
will need some way to port their application to the new platform.

I think that's pretty accurate. It's a migration strategy for their
existing customer base.

But, the unmanaged code is not going away. And as long as Delphi.W32
compiler is around, the existence of VCL.NET is pointless...

I think VCL.NET has value, I just don't think it's significant enough to
1) win new customers 2) keep existing customers. There will always be
exceptions, but on the whole, I don't believe it's an effective .NET
strategy.

Managed and unmanaged code seem to be two separate platforms
which will coexist far in the future each with their own pluses
and minuses.

I agree, but I think the ability to interop is critical. I'd love to
see a mixed mode Delphi compiler like MS has done with C++.

In that light porting VCL.NET to something like .NET 3.0 also
makes absolutely no sense.... If you want to use .NET use
Microsofts designer and Delphi.NET compiler. Why would you
need two designer frameworks?

I suspect they will need a WPF designer (and WCF, WF IDE support)
regardless of what they do with VCL.NET. But ultimately, I think
further investment in VCL.NET beyond what they have planned for
highlander is going to have a poor return rate.

But what does make sense, is to give Delphi.W32 compiler
at least a part of capabilities given to MS VC++ regarding writing
unmanaged code and making it accessible from .NET. That
is how CLR was written!

Agreed. Delphi Win32 should be able to leverage the .NET framework.
Also, in order for DevCo to remain competitive with C++Builder, they'll
need a .NET story, so I suspect they'll have to do a mixed-mode compiler
there anyway.

From the component writers point of view that would give
Delphi developers ability to write:

I think Peter Morris summed up the Delphi component vendors views
nicely. There are two choices: VCL.NET or WinForms.

Unless I've got an existing VCL component that's relatively easy to
support VCL.NET, I wouldn't support VCL.NET. As a component vendor,
looking at the relative size of the market, it's pretty obvious where
I'd go for .NET development.

1.) Really small, self contained dll's.
2.) Executing very fast and much faster than managed competition.
3.) Still using the same code from .NET and W32, but without
porting issues, performance drawbacks and memory clogging.

I don't think these are very important. All in all though, I agree with
your main point regarding VCL.NET.

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: First impression of Visual Studio from a Delphi user
    ... The C++/CLI compiler can generate native, ... Delphi doesn't support mixed mode, but Delphi for .Net and managed C++ ... Aside from using the .Net framework, ... If we're comparing to WinForms: ...
    (borland.public.delphi.non-technical)
  • Re: NET 2.0 And Delphi
    ... complicated than just adding references to the .NET framework into the ... D8 compiler and it works, but I really think that there should be some ... Do you really want to deploy a new Delphi ... I guess Borland has to change something in their .NET approach. ...
    (borland.public.delphi.non-technical)
  • Alternative Future of Delphi?
    ... relevant compiler or interpreter... ... No more intricate code generation required for a particular platform ... on the Delphi compiler side. ...
    (borland.public.delphi.non-technical)
  • Re: Which Delphi Version To Buy
    ... Given the fact that Delphi compiler is quick and small, do you see feasible having a runtime compiler/parser enabling what you describe above? ... For example the basic data types processing in Delphi is sensibly superior to .NET's one exactly because is closer to the iron. ... Well, for parallel programming I, for one, certainly feel the need of a VM simply because the actual CPU architecture is far from the way in which humans deal with the reality which is parallel. ... The vast majority of the games you have to deal with /different/ characters doing /different/ actions in parallel, responding each one to the stimuli which comes from the environment. ...
    (borland.public.delphi.non-technical)
  • Re: Version after Version
    ... merely because Delphi has no 64-bit compiler? ... >> targeted instructions and increasing the size of the cache to 32,000 ... >> That has nothing to do with the number of address lines on the CPU ...
    (alt.comp.lang.borland-delphi)