Re: 64-bit Windows for AMD 64 is here...

From: Rudy Velthuis (TeamB) (rvelthuis_at_gmx.de)
Date: 03/13/04 

Date: Sat, 13 Mar 2004 10:55:45 +0100

At 09:16:49, 13.03.2004, Eric Grange wrote:

> > Yes, and it is a lot more powerful and consistent than the "new"
> > WinForms.
>
> All that was demonstrated is that VCL.net is less capable than VCL
> classic, but as for being "a lot more powerful", it obviously isn't,

You are thinking about speed. It may come as a suprise to you, but
usually people don't fill listviews with thousands of entries, etc. With
powerful I mean the features. Of course the VCL for NET is partly slower
than its Win32 equivalent.

But if we are on .NET anyway, the VCL is a lot richer, and consistent
than the rather poor WinForms. This may change in future versions of
.NET, but currently WinForms is lagging behind.

> As you often say, it's a different platform, what took 3-4 distinct
> components in the VCL can be handled by one in WinForms,

Heheh, I have the exact opposite impression, in WinForms you are
constantly writing and instantiating classes like EventArgs, instead of
simply passing parameters directly. This is more or less the same as the
old Win32 API structures in an OO coating.

But I'm sure you can give me an example where one WinForms class does
what requires 3 or 4 VCL components.

 just have to
> ask nicely. The only "strong point" is that VCL.net is still Win32 at
> its core, i.e. based on GDI, which means higher speed. But that's all.

No, its strong points are its ease of use, its richness, and its
consistency.
 
> Everyone has been very clear that the .Net Framework SDK help won't
> (can't) be changed. So all that will remain non Delphi friendly

Just like the Win32 SDK help was even more unfriendly. Where is the
difference?

> If you want to use the framework, you'll end up with examples and
> definitions for other languages.

And how was that in Win32?
 
> I never used "implements", don't plan to.

Good, I simply gave it as an example of the features missing. Someone
writing an OPF using interfaces will probably miss it dearly.
 
> You wish to strengthen the point I've made that you've got to convince

I mentioned that one of the strong points of Delphi is is compatibility
with Delphi/Win32. The MS .NET languages don't offer that.
 
> Btw, where are those examples that demonstrate that D8FDN can be more
> efficient than D7 that you promised me in your many replies about both
> having their strength?

I never ever promised that. I never said that D8fN is more efficient than
Win32. I have no idea how you could read that into everything I said.

But you seemto be doing two different things:

- comapre .NET with Win32
- compare MS.NET languaghes with Delphi for NET

Now which is it you are comparing? Of course code that is not restricted
and managed can do a lot more tricks and be faster.

But compared to other .NET languages, Delphi is more powerful (and I
don't mean speed), and so is the VCL.

Your main concern seems to be speed. Sorry, but if you need raw speed,
you need contact with the bare metal, and that is currently not what .NET
provides.

> > I am not saying Delphi is equal. But it has the added advantage of not
> > having to jump through hoops to be able to use DLLs written in the
> > native language of the OS.
>
> ???
> You seem lost in a possible future.

No. If I want to use Win32 APIs, I must translate all the types and
functions to Delphi. There is no need for that in .NET. I can use C# or
Mamaged C++ written assemblies directly, without any translation.

> In the present and for the next
> couple of years, .Net is and will remain a runtime library

I think you misunderstood what I was saying.

> Also, I don't see the point about complaining about hoops... unless you
> want to talk about performance?

The hoops being us having to translate all Win32 APIs to Delphi, instead
of simply using them as they are, as we can do in .NET. 

-- 
Rudy Velthuis (TeamB)
"One of the symptoms of an approaching nervous breakdown is the belief
that one's work is terribly important."
    - Bertrand Russell (1872-1970)

Relevant Pages

  • Re: 64-bit Windows for AMD 64 is here...
    ... Of course the VCL for NET is ... classes (or structs in Win32) around. ... although not as extreme as the Win32 API. ... Delphi is also very strong on native compilation. ...
    (borland.public.delphi.non-technical)
  • Re: How can you drop Winforms support?
    ... Being able to use that shiny VCL Office 2007 Ribbon Bar from ... The support for WinForms in Delphi ... Get 3rd paty developers on board with a partner VCL.NET program with the idea of a coordinated release of the VCL.NET IDE and VCL.NET 3rd party ports to get an initial influx of the biggest 3rd party names. ...
    (borland.public.delphi.non-technical)
  • Re: My rant about the "throw out delphi and re-write it in C#" crowd.
    ... nothing out there that I've seen for WinForms that hasn't already been ... done to death by 3rd party vendors for VCL? ... thought we were talking about being able to port Delphi applications to ... Drop it on a Windows Form. ...
    (borland.public.delphi.non-technical)
  • Re: The New Roadmap
    ... WinForms is not my first choice for .Net UI apps. ... for the VCL since Delphi 1. ... VCL in both places where it makes sense. ... Why would you ever *need* to write a .NET GUI app? ...
    (borland.public.delphi.non-technical)
  • Re: Captain Jakes Top Ten List of what Id like to see in thenextversionofDelphi
    ... MFC and WinForms do not. ... For the Delphi developer, there is less of an argument. ... How many VCL Win32 customers have been asking their vendors to support ... Delphi developers, moving their existing Win32 application to .NET ...
    (borland.public.delphi.non-technical)