Delphi 8 und ActiveX Komponenten

[horst]

Zitat:

D8 "übersetzt" das ganze dann auf .NET Code

D.h. im Klartext:
Mein "altes" Win32 -Programm wird in D8 nach NET übersetzt und ist dann keine Win32-Anwendung mehr?
Danke für deine Hilfe ;)

[GetCool]

Zitat:

Zitat von horst

Zitat:

D8 "übersetzt" das ganze dann auf .NET Code

D.h. im Klartext:
Mein "altes" Win32 -Programm wird in D8 nach NET übersetzt und ist dann keine Win32-Anwendung mehr?
Danke für deine Hilfe ;)

Eigentlich schon, NUR ist es kein "wirkliches" .NET, da auch Komponenten von Borland (zwecks rückkompatibilität) benutzt werden und nicht nur die normalen .NET WinForm Komponenten. Für dich heißt das allerdings lediglich, dass die erstelle Exe mit ~1,4 MB Zusatzgepäck ankommt, da die Komponenten extra beigelegt werden müssen. Ansonsten hat man aber eine echte .NET-Anwendung.

[horst]

AHA !!!

[Bernd Ua]

Zitat:

Eigentlich schon, NUR ist es kein "wirkliches" .NET, da auch Komponenten von Borland ...

So, So - wirkliches .NET sind also nur WinForms-Komponenten, die untendrunter genauso auf Kernel32/RichEdit32.DLL
gehen wie VCL.NET auch.
Wirklicher .NET Datenzugriff ist dann wahrscheinlich auch nur ADO.NET mit dem Managed Provider für SQL Server,
der über PInvoke die klassische API des SQL Servers benutzt oder der MS OLE DB Provider für .NET, der unterdrunter
ActiveX/COM verwendet.

Bernd

[GetCool]

Nein, du weißt genau das ich das nicht so mein. Es war vielleicht ein bisschen schlecht formuliert, deswegen hab ich das "wirklich" ja auch in Anführungszeichen gesetzt. Mir ist schon klar das es echtes .NET ist. Trotzdem muss man VCL.NET ja eher als Übergangslösung sehen. Allein die ~1,4MB an zusätzlichem Speicherbedarf sind meiner Meinung nach inakzeptabel.

[Bernd Ua]

Zitat:

Nein, du weißt genau das ich das nicht so mein

Na ja - zumindest hat die MS Propaganda bei Dir gut gewirkt.
Ist ja schon witzig, dass Fremdcode der natives Zeugs aufruft Sicherheitsbeschränkungen unterliegt,
WinForms, was das auch tut aber nicht. Oder schau doch spasseshalber in die Bin-Verzeichnisse
von "echten" .NET Komponenten wie ComponentOne oder Crystal o.ä. und zähl mal die ActiveX, die dadrin liegen.

Zitat:

Trotzdem muss man VCL.NET ja eher als Übergangslösung sehen

Das sehe ich nicht ganz so eng - wenn ich mir die Halbwertszeit, der vergangenen
MS Technologien und Frameworks ansehe, kann es durchaus sein, dass die VCL.NET
länger hält, als das nach wie vor halbfertige WinForms. Mal schauen was sich
Ende des Jahres bei der nächsten .NET Version tut, wenn MS Templates ins .NET Framework
reindrückt. Bin gespannt ob MS der Versuchung widersteht, dass ins WinForms Framework
einfliessen zulassen und alten Code zu brechen...

Da ich zur Zeit beim besten Willen keine Platte mehr unter 40 GB bekomme, gehen mir die 1,4 MB
auch echt am A... vorbei.
Wenn du nur oft genug Deine .NET Anwendungen startest - überschreiten die Ausführungsprotokolle
den Betrag eh bald. Ganz zu schweigen von den SidebySide-DLLs in XP. Auf meinem neu installierten Rechner,
wo noch nix drauf ist ausser automatischen Updates und Fixes habe zB schon satte <8 MB im Verzeichnis WinSxS

Bernd

PS: Ähnliches zum Overhead der VCL habe ich schon mal gehört, das war 95 bei Delphi 1 :
VCL versus MFC Programme.

[GetCool]

Gut, lass wir das :mrgreen:
Kann deine Antwort durchaus nachvollziehen und du hast ja auch recht. Die Propagandamaschine schein wirklich gewirkt zu haben. :roll: