Hallo,
wir besitzen in unserem Betrieb Delphi2005. Ich beginne gerade ein neues Projekt und bin ziemlich ratlos mit welcher Delphi-Variante ich nun dieses Projekt entwickeln soll.
Soll ich weiterhin bei dem alt-vertrauten Delphi2005 für Win32 bleiben (dort habe ich alles, was ich unter Delphi7 auch hatte, ich muss nichts neues dazulernen)?
Oder soll ich auf Delphi.NET umsatteln? Hier ist einiges anders, andere Komponenten mit anderen Namen/Eigenschaften usw. Angeblich soll es aber doch die Zukunft sein, da Windows Vista auch auf .NET aufbauen wird. Allerdings finde ich, insbesondere, wenn ich WinForms verwende, nur noch grundlegende Komponenten wieder und längst nicht mehr die reiche Auswahl, die ich in Win32 hatte. Oder soll ich dann VCL.NET verwenden, hier sind wieder einige Komponenten mehr zu finden.

Werden Programme, die jetzt mit Delphi Win32 entwickelt werden, auch in zukünftigen Windows-Versionen (VISTA) laufen? Könnte ich demnach ohne Bedenken bei Win32 bleiben (was mir am liebsten wäre)?

Eine Menge Fragen. Ich bin ziemlich ratlos und stehe hier vor der Qual der Wahl.
Ich wäre Euch dankbar wenn dazu Tipps/Ratschläge habt.
Vielen Dank im voraus.
Herzliche Grüße
Tommikko

Das Thema würde mich auch mal brennend interessieren

Mit .Net machst du dich mehr oder weniger abhängig von Windows, soviel ich weiß. Da bin ich grundsätzlich dagegen (Signatur ). Zudem macht er mit Win32 richtige Programme (.exe).

Xion

Hallo Xion deine Aussage ist relativ interessant. Man könnte daraus schließen das ein Win32-Programm weniger mit Windows zu tun hat als ein .Net Programm. Andersherum wird eher ein Schuh draus.
WinForms ist zwar auch nur ein OO-Wrapper um die Win32-Api, dafür gibt es aber auch eine alternative Implemetierungen z.B. von Novell namens Mono oder von GNU für verschiedene Betriebssysteme, also CrossPlattform im allgemeinen Sinn .Net ist laut MS auch cross-Plattform, sie meinen da aber verschiedene Windows-Plattformen (WinXp, WinCE, ...) für verschiedene Prozessoren ( x86, Arm, ...)

Hallo!

Ich möchte Dir dringend davon abraten, unter Delphi mit .NET zu programmieren. Delphi wird auch in den nächsten Monaten kein .NET 2.0 unterstützen und das hieße für Dich, dass Du mit einem Trabbi (.NET 1.1) arbeitest, obwohl es schon längst die neue E-Klasse (2.0) gibt.

Die etwas spärlich vorhandenen Komponenten hast Du schon bemerkt, aber es gibt auch viele andere Features, die in .NET 2.0 entweder neu hinzugekommen oder verbessert wurden. So sparen Dir Generics zum Beispiel enorm viel Code und damit Arbeit beim Schreiben und der Wartung.

VCL .NET ist ein schwieriges Thema. Du solltest wissen, dass die nur deshalb so viele Komponenten bietet, weil sie sehr viel PInvoke verwendet, also das Framework "umgeht" und direkt aufs Betriebssystem zugreift. Mit anderen Worten: Die VCL .NET enthält auch einiges an Win32 (lapidar gesagt). Wenn Du keine .NET-Funktionen nutzen willst, kannst Du dann genauso gut die VCL Win32 nutzen.

Fazit: .NET mit Delphi würde ich persönlich sein lassen.

Ach ja, und Du glaubst nicht wirklcih, dass MS mit Vista ein Betriebssystem rausbringt, auf dem ein Großteil der vorhandenen Programme nicht mehr laufen, oder?

@Xion: Ich halte mich mit Kommentaren mal zurück. Nur soviel: Wenn man keine Ahnung hat, ...

Grüße
Christian

Vielen Dank! Mir helfen die Hinweise schon mal weiter. Ich werde wohl bei Delphi Win32 bleiben. Ich bin aber für weitere Hinweise sehr dankbar.
Auf einer Road-Show zu Delphi2005 von Better-Office stellte der Referent es als ein absolut notwendiges Muss dar, auf .NET umzusteigen. Dem scheint aber wohl doch nicht so zu sein, oder?

tommikko hat folgendes geschrieben:

Vielen Dank! Mir helfen die Hinweise schon mal weiter. Ich werde wohl bei Delphi Win32 bleiben. Ich bin aber für weitere Hinweise sehr dankbar. Auf einer Road-Show zu Delphi2005 von Better-Office stellte der Referent es als ein absolut notwendiges Muss dar, auf .NET umzusteigen. Dem scheint aber wohl doch nicht so zu sein, oder?

Du wirst damit rechnen müssen, dass in ein paar Jahren (nagel mich nicht darauf fest) Win32 nicht mehr oder nur noch in Teilen unterstützt werden wird. Momentan ist das noch kein wirkliches Thema, langfristig wirst du dich wohl oder übel mit .NET auseinandersetzen müssen.

AXMD

Und wenn Du Dich jetzt schon nebenbei mit .NET beschäftigst wird dir der Umstieg in ein paar Jahren leichter fallen, bzw. wirst Du keine Einarbeitung mehr benötigen.

Neidhard von Reuental hat folgendes geschrieben:

Und wenn Du Dich jetzt schon nebenbei mit .NET beschäftigst wird dir der Umstieg in ein paar Jahren leichter fallen, bzw. wirst Du keine Einarbeitung mehr benötigen.

Ich hab mich in den letzten Tagen/Wochen ein bisschen mit C# und .NET ansich beschäftigt und muss sagen, dass es nach etwas Einarbeitung wirklich nicht so wild ist. Ich hab mich monatelang dagegen gesträubt, mich damit zu beschäftigen, ohne mir das ganze richtig angesehen zu haben. Wenn man den Dreh mal raushat, ist es um einiges einfacher und vor allem übersichtlicher als Win32 - ganz zu schweigen von den ganzen netten Sprachfeatures . Soll keine Werbung sein, aber ich kann dir wirklich nur empfehlen, mal ein bisschen reinzulesen (Artikel gibt's ja in der MSDN genug) und das ein oder andere kleine Programm zu schreiben - wenn es dir absolut nicht zusagt, kannst du es dir ja immer noch überlegen

AXMD

AXMD hat folgendes geschrieben:

Du wirst damit rechnen müssen, dass in ein paar Jahren (nagel mich nicht darauf fest) Win32 nicht mehr oder nur noch in Teilen unterstützt werden wird.

du kannst dir aber sicher sein, dass diese noch auf windows laufen werden, sollte tatsächlich irgendwann was bahnbrechend neues wie "singularity" kommen, darf man damit rechnen dass ein win32 emulator darauf laufen wird, ähnlich wie es heutzutage mit DOS-programmen unter XP der fall ist.
Und selbst wenn nicht, WINE ist im sourcecode verfügbar und wird sicher portiert werden.

Da Vista voraussichtlich erst 2007 marktreif ist, und vermutlich auch einen Lebenszyklus von mindestens 3 Jahren haben wird, ist dies aber sowieso uninteressant.... bis 2010 gibts sicher wieder was "besseres" als .net

Wenn man sich auf Dauer für Anwendungen unter Windows entscheidet, wird es wohl keinen Weg um .NET herum geben. Für andere Systeme werden entsprechende Unterstützungen angeboten, aber darauf hat mkinzler ja schon hingewiesen.
Die Probleme mit .NET unter Delphi hat Christian S schon erläutert. Die selben Gründe haben mich dazu bewogen, Delphi nicht dafür zu verwenden.
MS wird sicher noch einige Zeit Win32 unterstützen, aber wer weiß, wie lange. Ein paar Jahre hat man sicher noch Zeit umzulernen. Wer allerdings jetzt schon anfängt, hat dann natürlich einen Vorteil.
Das Framework ist sicher sehr umfangreich, aber wäre es das nicht, würde sicher etwas fehlen. Das Gemecker wäre dann genauso groß. Noch hat man Zeit sich einzuarbeiten. In ein paar Jahren kann es schon zu spät sein.
MS ist halt Marktführer und wird bestimmen, wohin es geht (machen wir uns doch nichts vor). Da MS .NET als Zukunft ausgerufen hat, müsste schon einiges passieren, bevor sich das ändert.

jasocul hat folgendes geschrieben:

Wenn man sich auf Dauer für Anwendungen unter Windows entscheidet...

Wie dauerhaft ist schon das IT-Business, bzw wie wankelmütig MS...
Wenn du wirklich was dauerhaftes willst, lern C/C++ ...
Dafür wirds wahrscheinlich noch in 100 Jahren einen Compiler für JEDES BETRIEBSSYSTEM geben.

Hallo,

ich hatte bisher noch nichts mit .NET zu tun, stelle mir aber die Frage, wie sicher diese Sache ist?
.NET ist wohl noch ziemlich neu (zumindest verglichen mit Win32) und wer weiß was Microsoft sich vielleicht in 2 Jahren ausdenkt. Vielleicht gibts dann .IRGENDWAS und .NET stirbt.
Bisher habe ich nur gehört, daß Win32 noch mehrere Jahre unterstützt werden wird... von der Zukunft von .NET habe ich noch nichts gehört, außer daß es jeder haben will weil es ... neu ist?
Wie gesagt, bisher keine .NET Erfahrung, es geht mir auch nicht darum, ob Win32 besser oder schlechter ist als .NET.
Aber wer weiß was die Zukunft bringt. Sollte man auf jeden neuen Zug aufspringen?

Holger

Kurz gesagt ist .NET die konsequente Weiterentwicklung von OOP.
Wer OOP für die richtige Programmier-Methode hält, kommt imho nicht an .NET vorbei.
Aber das ist wirklich nur als meine ganz persönliche Meinung zu betrachten. Es gibt bestimmt genug Leute, die da völlig anderer Meinung sind.

jasocul hat folgendes geschrieben:

Kurz gesagt ist .NET die konsequente Weiterentwicklung von OOP.

Hä? Nur weil .NET komplett auf OOP basiert, ist es noch lange keine "konsequente Weiterentwicklung von OOP". Was war dann Java für dich?

[ironie]
.NET wurde entwickelt, weil die CPUs mittlerweilse so schnell sind, dass die Programme einfach zu schnell mit ihrer Arbeit fertig sind. Um das zu unterbinden, wurde mit .NET nun eine Schicht auf breiter Masse zwischen Anwendung und CPU geklemmt, die das ganze wieder verlangsamt. So können die Prozessorhersteller wieder Geld mit noch schnelleren CPUs machen.
[/ironie]

Christian S. hat folgendes geschrieben:

VCL .NET ist ein schwieriges Thema. Du solltest wissen, dass die nur deshalb so viele Komponenten bietet, weil sie sehr viel PInvoke verwendet

Ach, und was macht WinForms? Schon mal den WinForms-Code mit Reflector angeschaut?

AndyB hat folgendes geschrieben:

Christian S. hat folgendes geschrieben: VCL .NET ist ein schwieriges Thema. Du solltest wissen, dass die nur deshalb so viele Komponenten bietet, weil sie sehr viel PInvoke verwendet Ach, und was macht WinForms? Schon mal den WinForms-Code mit Reflector angeschaut?

Die Diskussion hatten wir IIRC schon einmal. Der Punkt ist, dass es keinen Sinn macht, eine Abstraktionsebene (.NET) zu benutzen und gleichzeitig dran vorbei zu arbeiten (PInvoke). Selbstverständlich muss das Framework auch auf Windows zugreifen, wie sollte es sonst arbeiten? .NET ist kein eigenes Betriebssystem, sondern eine Zwischenschicht, welche das Betriebssystem quasi "verdeckt". Die Anwendung muss nicht wissen, auf welchem Betriebssystem sie läuft, solange sie nur die .NET-Funktionen nutzt. Tue ich das, kann ich das Betriebssystem unter .NET austauschen und mit einem entsprechend angepassten Framework laufen meine Anwendungen immer noch.

Da ist IMHO ein Vergleich mit Java durchaus angebracht: Solange ich nur die Funktionen nutze, welche mir die VM zur Verfügung stellt, kann ich sie auf jedem OS, für das es eine VM gibt, ausführen. Dabei nutzt die Java-VM für Windows sicherlich auch Windows-Funktionen. Täte ich das aber in meinen Programmen, könnte ich sie nicht auf Linux laufen lassen.

AndyB hat folgendes geschrieben:

jasocul hat folgendes geschrieben: Kurz gesagt ist .NET die konsequente Weiterentwicklung von OOP. Hä? Nur weil .NET komplett auf OOP basiert, ist es noch lange keine "konsequente Weiterentwicklung von OOP". Was war dann Java für dich?

Java war noch nie etwas für mich. Sorry. Aber nett, dass du bei Java in der Vergangheitsform schreibst.
Und du hast selbst geschrieben, dass .NET komplett auf OOP basiert. Was ist das anderes, als OOP konsequent weiter zu führen? Als Zwischenschicht zum OS, brauche ich mich beim Programmieren gar nicht mehr umstellen und irgendwelche API-Calls kapseln.

Hallo, erstmal

Ich weiß nicht wieso noch keiner einen der wichtigsten Vorteile des Delphi.NET genannt hat:
Alle .NET Compiler übersetzten Code in eine einheitliche Sprache(MSIL-Code) und dieser Code wird erst später vom JIT (Just in Runtime) ausgeführt. => eine wesentlich leichtere Kummunikation der Assemblies... verschiedenster Programmiersprachen

Ich habe mir das Buch Borland Delphi 2005 mit .NET Framework (www.buecher.de/verte...mp;site=artikel.asp) gekauft und ich programmiere eigentlich hauptsächlich jetzt in Delphi.NET. Hier eine sehr umfangreiche Leseprobe über die Änderungen in Delphi.NET:
bilder.buecher.de/zu.../13386050_lese_1.pdf

Also bis dann
tschüss

P.S.: Falls ich irgendwelchen Mist erzählt habe dann korrigiert mich bitte!

jetzt werd ich auch mal meinen senf mit zugeben, hab das seit dem umstieg von 16B auf 32B nicht mehr gemacht.

aber nach meiner meinung bietet eine zusätzliche abstraktionsschicht, welche nur auf windows läuft, keinen vorteil... wenn, dann müsste dies auch auf anderen prozessoren und betriebssystemen laufen.. ist aber in aller regel bei M$ nicht der fall, da sie sich sonst das wasser abgraben würden.

da .NET sowieso nur auf M$ läuft und daher auch die M$-API nützt, gäb es ausser verlusst an performance, nur einen zusätzlichen vorteil, den des interpreters. dieser kann beim ausführen des progies den speicher überwachen und eine dump-collection machen (aus der JVE bereits seit langen bekannt). damit lassen sich speicherlecks vermeiden... was nicht zu unterschätzen ist.

ansonsten sehe ich .NET nicht für nützlich... was sich im endeffekt durchsetzen wird, steht in den sternen. ich erinnere mich noch deutlich, als billy gates verkündete dass Basic strategisch ist und von allen anwendungen unterstützt wird... tja, von basic reden wir wohl nicht mehr ganz so laut...

nun denn, dies war das wort zum dienstag und noch einen schönen abend.

Der .NET-Code wird ja meines Wissens nach gleich beim Programmstart kompiliert. Wäre es da nicht für das .NET-Framework am einfachsten, wenn er es dann als Win32 (bzw. Win64 oder wie das heißt *g*) zu kompilieren und dann zu starten? Dadurch würde die .NET-Ebene umgangen werden, wo mit auf jeden Fall kein Performance-Nachteil gegenüber Win32-Anwendungen entstehen würde (außer beim Start). Oder ist das .NET-Framework eine Ebene in der gleichen Ebene wie Win32 (also das die beiden nebeneinander liegen), denn dann würde .NET auch ohne Compilierung in .NET gleich sein? .

Und ich sehe vor allem einen Vorteil in .NET. Da es die "EXE" nur den Quellcode enthält, ist es gut für Emulatoren, da die sich dass dann selber zusammenkompilieren können und nicht wirklich emulieren müssen .