Delphi 8 und das .NET

[daniel8520]

Hallo Leute,

ich hab mich jetzt mal etwas intensiver mit der "neuen" .NET-Technologie beschäftigt.
Die erste Frage die ich mir jetzt stellen musste (in Bezug auf Delphi) war, laufen alle meine Delphi Anwendungen, die ich mit Delphi 8 programmieren würde (auch wenn's nur ein simples Form, ohne andere Objects, ist) nur auf Rechnern, auf denen das .NET-Framework installiert ist, oder ist das abhängig davon, welche (Standard-)Units ich verwende!?
Ich mein, wenn dies der Fall wäre, wäre Delphi 7 ja die vorraussichtlich letzte (von Borland) angebotene WIN32 Programmierplattform!

[Sanchez]

Hallo,

Zitat von daniel8520:

Die erste Frage die ich mir jetzt stellen musste (in Bezug auf Delphi) war, laufen alle meine Delphi Anwendungen, die ich mit Delphi 8 programmieren würde (auch wenn's nur ein simples Form, ohne andere Objects, ist) nur auf Rechnern, auf denen das .NET-Framework installiert ist, oder ist das abhängig davon, welche (Standard-)Units ich verwende!?

Damit .NET-Programme laufen, und mit D8 erstellte Programme basieren auf dem .NET-Framework, benötigen natürlich auch das .NET-Framework, um zu laufen.

Zitat von daniel8520:

Ich mein, wenn dies der Fall wäre, wäre Delphi 7 ja die vorraussichtlich letzte (von Borland) angebotene WIN32 Programmierplattform!

Ich glaube irgendwo gelesen zu haben, dass man mit Delphi 9 auch Win32-Programme erstellen können soll. Is aber ohne Gewähr.

grüße, daniel

[daniel8520]

Aber warum dann plötzlich in Delphi 9 doch wieder WinApi? Das ergibt doch irgendwo keinen Sinn? Ich mein spätestens mit der nächsten Windows Version (sprich Longhorn) wird es doch wohl zum größten Teil mit der WinApi vorbei sein!
OK, sie werden höchst wahrscheinlich noch unter einem Emulator laufen, aber ich glaube, dass man damit den vollen Zugriff auf den Rechner, so wie es heute ist, bekommen wird. Denn: Aus meiner Sicht ist doch ein Grund der .NET-Technolgie die ganzen Viren. Microsoft will damit, meiner Meinung nach nur verhindern, das bösartige Programme schaden anrichten. Aber das wäre ja mit einem WIN32-Emulator, welcher Vollzugriff hat, wieder völlig sinnlos!
Meine zweite Frage wäre jetzt gewesen, ob es sich lohnt, jetzt "schon" auf .NET umzusteigen. Aber wenn ich jetzt höhre/sehe, dass man doch noch weiter mit der WinApi arbeiten kann, ist doch das Umsteigen --Im Moment-- noch nicht unbedingt nötig, oder!?

[Phoenix]

Delphi 8 war ein 'Schnellschuss' von Borland. Auf Basis der neuen IDE ist es ohne weiteres Möglich, einen weiteren Compiler einzubauen, demnach wird D9 definitiv auch wieder Win32 - Anwendungen erzeugen können.

Theoretisch sogar dann, wenn Objekte aus dem .NET Framework verwendet werden (will heissen: Erst zu .NET Framwork -Anwendungen kompilieren und die intermediate Language dann weiter in reguläre ausführbare .exe - Dateien weiterübersetzen), soweit geht der Compiler dann aber wohl doch nicht.

Will heissen: D7 Projekte werden sich dann in D9 genauso übersetzen lassen wie D8 Projekte. Ein Austausch der beiden wird aber je nachdem nur recht schwierig / Umständlich vorzunehmen sein bzw. dann unter den bereits bekannten EInschränkungen was z.B. Performance von VCL.NET Anwendungen angeht.

[Phoenix]

Zitat von daniel8520:

Meine zweite Frage wäre jetzt gewesen, ob es sich lohnt, jetzt "schon" auf .NET umzusteigen. Aber wenn ich jetzt höhre/sehe, dass man doch noch weiter mit der WinApi arbeiten kann, ist doch das Umsteigen --Im Moment-- noch nicht unbedingt nötig, oder!?

Ja, Definitiv. Allerdings nicht zwingend mit Delphi.

Und zwar eigentlich aus nur einem Grund: Ohne eine einzige Codeänderungen lassen sich z.B. ASP.NET Anwendungen inzwischen auch auf Linux einsetzen. - Und zwar mit der auf Windows-Rechnern kompilierten DLL.

Das ganze wird spätestens in zwei, ich tippe eher auf noch ein Jahr auch mit Windows-Forms Anwendungen der Fall sein. Zudem ist das .NET Framework sehr mächtig, und nimmt einem genau wie die VCL eine Menge Arbeit ab.

Will im Fazit heissen: Wenn die Anwendungen Web-Enabled sein sollen und / oder es auch nur den leisesten Ansatz von Sinn machen könnte, die Anwendung irgendwann später auch auf Longhorn ohne Sicherheitswarnungen bzw. auch auf Linux einsetzen zu können, dann ist .NET die richtige Wahl für neue Projekte.

[Hansa]

Mittlerweile, sieht es so aus, bzw. sehe ich das so 8) : in D9 wird nicht nur die Auswahl geboten eine VCL.NET oder eine Winforms Anwendung zu schreiben, sondern auch eine WinApi-Application.

In letzterem Fall wird wohl dcc32 von D7 benutzt werden, eventuell etwas modifiziert, oder sie machen es anders. Im Prinzip wird aber nur D7 in die D9-IDE integriert.

Desweiteren wird es mehr und einfachere Werkzeuge geben, ein Winapi-Programm nach .NET zu portieren.

All das ändert nichts an der Tatsache, daß man die WinApi mittelfristig vergessen kann. Spätestens in 2 Jahren werden die Fragen von Endanwendern kommen : "Ist das jetzt ein WinApi Programm oder ein .NET ?" Das wars dann.

[Luckie]

Und ihn vier Jahren sind dann die Entwickler gesucht, die noch WinAPI können, um die Programme zu warten. Ich habe mir extra das Jar schon mal freigehalten im Terminkalender. Die WinAPI wird es noch eine gute Weile geben.

[Hansa]

Klar wirds die noch lange geben. Ich nehme momentan auch keinerlei Rücksicht auf .Net, nur insofern, daß ich versuche die WinApi-Teile im Programm möglichst gering zu halten. Im eigenen Source wirst du vielleicht 10 WinApi Aufrufe finden.

In absehbarer Zeit wird aber immer öfter und schneller der Bedarf nach neuen Lösungen steigen. Da wird bald nicht mehr in altes investiert werden. Und etwas neues auf WinApi aufzubauen wäre Unfug. Davon abgesehen ist ein Jahr recht wenig für eine größere Sache, um sich da reinzudenken.

[Luckie]

Zitat von Hansa:

Im eigenen Source wirst du vielleicht 10 WinApi Aufrufe finden.

Und wie viele gibt es wohl in der VCL?

[Insider2004]

1.
Delphi 9 wird Win32 und .Net unterstützen (umschaltbar, wie bei Borland Pascal 7.0: DOS <-> Win 16)

2.
Für Net Programme muss das .Net-Framework von MS installiert sein. Vom Prinzip her ist Net mit Java vergleichbar. Ist auch genauso resourcenhungrig und daher zum jetzigen Zeitpunkt völlig überflüssig. Wer performante Anwendungen machen muss wählt die Win-Api.