VCL.NET

[Hansa]

Hi,

folgendes bezieht sich im wesentlichen hierauf :

http://www.borland.com/products/whit..._to_dotnet.pdf

ACHTUNG : ist PDF !

es geht darum, was nun genau mit der VCL.NET ist. Verschiedendlich habe ich gelesen, dies sei immer noch ein WinApi-Programm, also die erzeugte EXE. Tatsächlich taucht das Wort "MESSAGE" usw. im Source von D8 öfters auf. Dies kann aber auch aus Kompitibiltätsgründen so sein.

Mich macht ziemlich stutzig, daß überhaupt eine VCL.NET existiert und Borland D8 eigentlich nur mit D7 ausliefert, damit gerade die WinApi Programme noch gepflegt werden können. Wozu dann die VCL.NET ?

Jetzt zu dem Artikel. Vorab sei gesagt, wer auf den Roadshows war, dem kommt das alles bekannt vor. Zitate :


Mist, geht nur als Anhang wegen Acrobat.

Also gut, in dem Zitat steht drin, es gäbe zwar Warnungen, aber man solle sich nicht verrückt machen es wäre schon eine native .NET Application. Tja das wars schon. 8) Im Text steht noch, welche Komponenten noch nicht portiert wurden. Wer D8 hat kann sich ja selber davon überzeugen. :mrgreen:

Und mit den Compiler-Direktiven die erwähnt wurden blicke ich auch nicht zu 100% durch. Was meinen die da ?

[Sanchez]

Die VCL.NET dient einzig und allein einer einfachen Portierungsmöglichkeit von Win32-Projekten in D8-Projekte.
Sie sollte nicht für neue Projekte verwendet werden, da sie ja nur eine Übergangslösung darstellt. Allerdings ist das einbinden der Win-API bei .NET über sogenannte P/Invokes (just like VCL.NET) IMHO durchaus üblich, da das .NET-Framework noch etwas lückenhaft ist (zumindest was meine Erfahrungen betrifft und die Beschränken sich größtenteils auf das CompactFramework).

[Hansa]

Es geht um bestehende Sachen. Unter Winforms ist noch nicht alles vorhanden. Das nützt also wohl nichts. Was ist mit der VCL.NET aus Sicht des Betriebssystems ? Das damit erzeugte Programm, ist das nun ein richtiges .NET Programm oder nur eins wie die mit D7 erzeugten WinApi-Programme ?

Wenn ich nun ein Mini-Programm als VCL.NET compiliere und das .NET deinstalliere, was passiert dann ? Läuft es dann noch ? *denkt* Falls ja, wäre es kein reines .NET Programm. Muß ich das jetzt tatsächlich so testen ? :shock: Hat das noch keiner bisher so gemacht ?

[Alexander]

Ich kann Sanchez nur zu stimmen, es betrifft nicht nur das CompactFramework. .NET kann die WinAPI32 noch nicht ablösen, da muss es schon ncoh ein wenig weiterentwickelt werden.
Aber eigentlich sollte es schon .NET bei einer VCL.NET Anwendung sein. Manche Teile sind halt noch nicht komplett nach .NET übersetzt worden.
Daher werden diese Anwendungen auch nur auf Windows-Systemen laufen...
(Zumal MONO auch ncoh nicht so weit ist, WindowForms zu unterstützen...)

[Hansa]

Linux ist zweitrangig. Das Programm muß laufen und ich muß wissen wann, wo und weshalb. Denjenigen, der es benutzen soll, interessiert der Kram hier nicht die Bohne.

Ich formuliere die Frage deshalb mal um : läuft ein mit VCL.NET compiliertes Programm nun in der Win32-Box unter .NET (so wie ein DOS-Prog in Win32) oder wie sonst ? Ob dem neueren D8-Programm jetzt WinApi-Emulation vorgegaukelt wird ist mir dabei egal.

[Sanchez]

Ein VCL.NET-Programm ruft, wie schon gesagt, häufig alte Win32-APIs über die P/Invokes auf. Dieser Vorgang kostet Zeit und ist kann (laut meinem Delphi.NET Sonderheft) mit dem alten Real-Mode verglichen werden.

Die VCL.NET ist deshalb auch nicht plattformunabhängig. Wenn also Microsoft irgendwann die Win32-API dichtmachen will, was aber vermutlich nicht so schnell passieren wird, hat der Umstieg auf die VCL.NET nicht viel gebracht. Wenn umsteigen, dann schon richtig.

Eine weitere Einschränkung ist, dass eine VCL.NET-Anwendung mehr Rechte benötigt um zu laufen.Das wird sich vor allem im Netzwerkbetrieb auswirken.

Allerdings kommt man zur Zeit, wie auch schon erwähnt nicht völlig ohne die Win32-API aus. Da muss man sich wohl einen mittelweg finden, oder mit dem Umstieg noch warten.

[Hansa]

Zitat:

Zitat von Sanchez

...Wenn umsteigen, dann schon richtig.

Eine weitere Einschränkung ist, dass eine VCL.NET-Anwendung mehr Rechte benötigt um zu laufen.Das wird sich vor allem im Netzwerkbetrieb auswirken.

Allerdings kommt man zur Zeit, wie auch schon erwähnt nicht völlig ohne die Win32-API aus. Da muss man sich wohl einen mittelweg finden, oder mit dem Umstieg noch warten.

Umsteigen ? Dazu wird man wohl gezwungen. :wall: Dann erkläre mir mal bitte noch, was das mit dem P/Invoke auf sich hat, bzw. wo das in dem Andreas Kosch Heft 8) drin steht. Ja, dann noch das mit den Rechten. Das ist auch noch etwas unübersichtlich (für mich zumindest). :gruebel:

[Sanchez]

Zitat:

Zitat von Hansa

Umsteigen ? Dazu wird man wohl gezwungen. :wall:

Aber doch nicht sofort. Ich habe mit .NET bisher nur wenig umfangreiche Dinge gemacht. Wenns gut genug sitzt (und .NET reif genug ist) überlege ich mir die größeren Brocken anzugehen.

im übrigen hab ich nen netten Artikel von Andreas Kosch gefunden:
http://derentwickler.de/itr/online_a...deid=56&id=600

[Hansa]

Zitat:

Zitat von Sanchez

Aber doch nicht sofort. Ich habe mit .NET bisher nur wenig umfangreiche Dinge gemacht.

Was heißt sofort ? :shock: Vor ziemlich genau einem halben Jahr erschien D8 in D. Ich habe mich mit ca. 100.000 Zeilen rumzuplagen.

Nene, ich gehe das schon gemächlich an, aber so langsam gewinne ich den Eindruck, daß sich kaum einer (zumindest hier in der Delphi-Praxis) um das Thema kümmert. Siehe die geringe Resonanz. Und das wird doch langsam Zeit. Ich meine jetzt die User, außer von Sanchez kam bisher nichts.

Na ja, hoffentlich kommt bald Longhorn. Ich vermute langsam zu ahnen, warum das so heißt. :mrgreen:

[Hansa]

EiEi :shock: Habe den Andreas Kosch Artikel kurz gelesen. Das wird heftig und alle können sich wohl warm anziehen. 99% werden wohl böse hinfallen. :mrgreen:

hier noch was :

http://www.delphipraxis.net/internal...ct.php?t=18988

Solange die Klarheit unklar ist, wird das wohl vorerst nichts. :lol: Also geht es wohl so weiter. Ohne Rücksicht auf Verluste. :mrgreen: