Zitat von
Robert_G:
Die
VCL.Net bringt niemanden etwas! Es werden per P/Invoke DLLs am Framework vorbeigeschliffen, da es Borland nicht geschafft hat, alle
Win32 Calls auszumerzen.
Microsoft hat es ja auch nicht geschafft.
Es werden ja genauso wie in der
VCL alle
Win32 spezifischen Dinge via P/Invoke an das
Win32 System weitergereicht.
Zitat von
Danny Thorpe, Delphi Compiler Architect and .NET Team Lead:
...
Wir erwogen zuerst, die
VCL auf das WinForms-Framework aufzusetzen. Nach ein wenig Forschung wurde klar, dass die gleichen Architekturunterschiede, die es schwierig machten,
VCL-Anwendungen nach WinForms zu portieren, es schwierig machen würden, eine
VCL-Schicht über WinForms zu erstellen - und trotzdem auf
VCL-Art zu funktionieren.
Was wir beim Evaluieren von WinForms feststellten war, dass WinForms direkt auf
Win32-
API-Aufrufe aufsetzt. WinForms-Fensterklassen rufen CreateWindow() auf, um
Win32-Fenster-Handles zu erzeugen, sie hooken die
Win32-WndProc, um Fensterbotschaften abzuhören und feuern entsprechende Events innerhalb der Klasse und so weiter und so fort.
Genau wie die
VCL.
...
-----
Veröffentlichung des
englischsprachigen Originals im BDN.
Übersetzung durch Martin Strohal auf delphi-source.de
Zitat von
Robert_G:
Deshalb ist es
IMHO unmöglich eine komplexe
VCL.Net App unter geringeren Berechtigungen als FullTrust laufen zu lassen.
VCL.Net ist Dummfang. Das klingt hart, aber es ist nunmal so. Das Ding hat nicht mehr Hintergrund als einen angeblich einfachen Migrationsweg vorzuheucheln.
VCL.NET ist KEIN Dummfang!!!
vcl.net ist nicht perfekt, aber ein bequemer Weg sein
VCL Wissen in die .Net Welt zu transportieren. Trotzdem empfehle ich jedem bei neuen Projekten keine
VCL sondern WinForms zu verwenden.
Den Delphi Entwicklern stand leider nicht genug Zeit zur Verfügung alles "ordentlich" zu portieren. Ich bin mal gespannt was Delphi 9 (erscheint Ende des Jahres) in diesem Punkt bringt.
Es kann ja nicht jeder die gleiche Meinung haben
