Re: VCL.NET revisited...

Hi!

1) requires access to unmanaged windows API.
So does WinForms (.NET is still a layer on top of the windows API)

Not the same at all. .NET framework does not require 5MB
of runtime distrubtion add-on as does VCL.NET.
And it is not certified by Microsoft.

2.) Increased code size due to run time library
Ever noticed the size of the .NET Framework directory?

Distributed with OS..

3.) Is not written in C#.
Ehum, is that a disadvantage?

It can be if you are selling components.
C# is standard for .NET.

solution which is migrated from Win16 to Win32, .NET and in the future
also to CF.NET, Win64, Vista, etc. With some manual steps (easy if you

Converting of VCL to anything except 64 bit and Unicode which is not
a conversion but upgrade does notmake sense. CLX port was a very special
case which is no longer alive and has nothing in common with the
support for .NET

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!
This can already be done.

You know it does not even come close. You cant take
highperforming pointer, asm unmanaged dll call app and
have it execute at peak performance within .NET with
pure .NET component interface.

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

1.) Really small, self contained dll's.

Back to DLL Hell deployment?

Delphi apps were/are mostly single exe only and any
dll hell can be solved in other ways than with .NET.
You can duplicate dlls on your disk without the .NET
framework.

2.) Executing very fast and much faster than managed competition.
Which would defeat the use of the safe, managed .NET environment in
itself.

Who is asking for it? Internet developers. Of course, I have no problem
with that. I am only saying that there is a need for TWO completely
independent frameworks. One is .NET which has its advantages
and the other is W32.

You are still pushing both in the same pot. Maybe its time for another
DevCo spinoff: Unmanaged Delphi W32.

3.) Still using the same code from .NET and W32, but without
porting issues, performance drawbacks and memory clogging.

You can already use Win32 DLLs in .NET. I have a feeling, however, you do
not have a full picture of what .NET offers.

Oh, yeah. If somebody does not agree, he must be inferior <g>

Regards!
Atmapuri


.

Relevant Pages

  • Re: System.Runtime.InteropServices.COMException: Error
    ... after i registered the dll on sever, ... > Is there any other setting I need to do on Win2K3 to make the old dll work> on .Net framework? ... > Exception Details: System.Runtime.InteropServices.COMException: COM object> with CLSID is either not valid or not> registered. ...
    (microsoft.public.dotnet.general)
  • Re: .tmp is not a valid win32 resource file
    ... Please suggest some ways to resolve ... I replaced the dll as suggested in the mentioned post. ... dll present in the framework folder and the system 32 folder are ... I got the problem when i reinstalled the .Net framework 1.1. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Redirecting Assembly Binding
    ... the fusion.dll which is component of .NET framework ... the strongnamed DLL is an evidence to prove its unique ... So the bindingredirect element is used in this scenario to instruct the CLR ... Because .NET will probe multiple places for an assembly binding. ...
    (microsoft.public.dotnet.framework)
  • Re: consuming managed C# DLL from unmanaged VB6
    ... I created a DLL using managed C# and this DLL needs to be consumed by ... .NET framework installed. ...
    (microsoft.public.dotnet.languages.csharp)
  • problem with .net framework 2.0 and 1.1
    ... I have an application that runs a DLL written in Delphi .net. ... My Dll runs well only on .net framework 1.1 and NOT 2.0. ... on framework 1.1 and some on 2.0 - so I cant specify on the exe.config ...
    (microsoft.public.dotnet.framework)