Entwickler-Ecke :: Thema anzeigen

tommikko - Fr 26.05.06 23:12
Titel: Win32 oder .NET?

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

mkinzler - So 28.05.06 14:28

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 [http://www.mono-project-com] 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, ...)

Christian S. - So 28.05.06 14:30

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

AXMD - Mo 29.05.06 00:09

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

AXMD - Mo 29.05.06 10:12

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

0xCC - Mo 29.05.06 10:34

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

jasocul - Mo 29.05.06 10:37

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 user profile icon

mkinzler ja schon hingewiesen.
Die Probleme mit .NET unter Delphi hat user profile icon

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.

Holgerwa - Mo 29.05.06 18:54

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

AndyB - Mo 29.05.06 19:34

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?

Christian S. - Mo 29.05.06 19:52

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.

jasocul - Mo 29.05.06 20:46

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. :wink:
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.

Delete - Mo 29.05.06 21:22

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 (http://www.buecher.de/verteiler.asp?Publica_ID=KNO-15393113111423172358&zz=7684&artikelnummer=000001473774&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:
http://bilder.buecher.de/zusatz/13/13386/13386050_lese_1.pdf

Also bis dann
tschüss

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

Delete - Di 30.05.06 00:05

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.

Heiko - Mi 31.05.06 07:16

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 ;).

mkinzler - Mi 31.05.06 10:00

Heiko hat folgendes geschrieben:

Der .NET-Code wird ja meines Wissens nach gleich beim Programmstart kompiliert.

Nein, daß ist nicht ganz korrekt. Beim Einsatz eines JIT wird immer nurt ein Teil kompilliert.

Zitat:

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? ;).

Momentan verwendet das Framework noch Win32.

Zitat:

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 ;).

Die Exe enthält nicht den Quellcode, sondern den in eine "Virtuelle Machine" kompillierte Code (CLR), welcher zur Laufzeit interpretiert wird oder mit JIT blockweise übersetzt wird.

nullplan001 - Do 01.06.06 10:28

Hi all,
wenn ihr schon alle eure Meinung geigt, schreibe ich auch mal meine:
Warum benutze ich .NET? Weil ich 1. mit Lazarus nicht so ganz klar komme, aber 2. das WinAPI mich zur Verzweiflung bringt. Das .NET-Framework ist für mich nur die Basis von WinForms (Ich brauch's nicht für was anderes). Außerdem hat M$ ja versprochen, das Framework für andere Platformen herauszubringen, was mich von der lästigen Pflicht entbindet, den gleichen Code 10000mal in 5 verschiedenen Platformen kompilieren zu müssen, damit ich mein Programm auch ja für Win32, Linux/Unix, MacOS, usw verfügbar habe. Wenn ich die GPL richtig verstanden habe, ist das meine Pflicht für alle GPL-Programme. Naja, .NET-Programme unter die GPL zu stellen, mag ja auch relativ wagemutig sein. (.NET gibt es nur für Windows und Linux, GNU will aber alles für alle). Aber rechtlich machbar.
Wie mir auffiel, stellen die Menschen immer die falschen Fragen. Nicht "Warum?" muss es heißen, sondern "Warum nicht?". OK: Warum nicht Java? Gute Frage. Hauptsächlich wegen der Sprache. Bei .NET kann ich nehmen, was ich will, wenn ich den Compiler dazu habe. Bei Java muss ich mir aber erst mal Java anlernen. Och nö, wisst ihr, da hatte ich nicht so wirklich Bock drauf ;) . Jedenfalls ist der Sprung von Pascal nach Chrome nicht so weit, wie der von Pascal nach Java, trotz meiner C-Kenntnisse. Die ich hauptsächlich zur Übersetzung von C-Quellen nach Pascal nutze. Ich habe mich für Pascal entschieden, und dabei bleibt's.
Tschö,
nullplan
P.S.: OK, was Delphi/Delphi.NET angeht: Wie schon beschrieben nutze ich .NET nur wegen der WinForms. Da aber Delphi Formulare auch relativ einfach erstellen lässt, ist es wurscht, welches du benutzt. Zumindest von meiner warte aus.
P.P.S.: Könnte Linux eigentlich eine Win32-Exe (Konsole, der Einfachheit halber) ausführen? Das PE-Format ist ja eine Abwandlung des COFF. Und das kann Linux ausführen, wenn ich richtig liege.

Grendel - Do 01.06.06 11:32

nullplan001 hat folgendes geschrieben:

[...]was mich von der lästigen Pflicht entbindet, den gleichen Code 10000mal in 5 verschiedenen Platformen kompilieren zu müssen, damit ich mein Programm auch ja für Win32, Linux/Unix, MacOS, usw verfügbar habe. Wenn ich die GPL richtig verstanden habe, ist das meine Pflicht für alle GPL-Programme. Naja, .NET-Programme unter die GPL zu stellen, mag ja auch relativ wagemutig sein. (.NET gibt es nur für Windows und Linux, GNU will aber alles für alle).

Das ist schlicht falsch. Eine solche Forderung gibt es in der GPL nirgendwo.

Bis neulich ...

mkinzler - Do 01.06.06 11:46

Zitat:

Warum nicht Java? Gute Frage. Hauptsächlich wegen der Sprache. Bei .NET kann ich nehmen, was ich will, wenn ich den Compiler dazu habe. Bei Java muss ich mir aber erst mal Java anlernen.

Interessanter Weise war Java anfänglich so ähnlich wie .Net gedacht eine Plattform (VM) und sprachunabhängig. Als Beispiel hat man dann die Sprache Java implementiert diese aber nuzr als "Provisorium" gedacht, bis es andere Sprachen gibt. Die Anwender/SW-Entwickler sich aber mit dieser Sprache zufriedengegeben und keine anderen Sprachen portiert. Erst mit .Net wurde begonnen andere Sprachen auch an die Java-VM anzupassen wie z.B. Component Pascal [http://www.plas.fit.qut.edu.au/gpcp/]. Ein weiterer Pascalcompiler für die Java-Plattform ist MidletPascal [http://www.midletpascal.com].
Es gibt auch noch MiddleWare wie z.B. JaCIL [http://sourceforge.net/projects/jacil] oder IKVM.

Zitat:

Außerdem hat M$ ja versprochen, das Framework für andere Platformen herauszubringen

Haben sie doch schon. Nur MS versteht unter Plattformunabhängigkeit hat die Unabhängigkeit vom Prozessor und nicht vom OS also WinXP/x86 und WinCE/Arm. Außerdem haben sie ROTOR unter der shared-source veröffentlicht.

digi_c - Do 01.06.06 12:55

O.k. jetzt ich auch noch, dafür aber nur in Kurzform :D

Pro .NET

Einfache Zusammenarbeit/einheitliche Codebasis für unterschiedliche Abteilungen(Client/Server, Webentwicklung,..)
Abstraktion, potentielle Platformunabhängigkeit(MONO)

Con .NET

schirmt sehr von CPU/OS ab
User braucht Framework(in richtiger Version)
Java ist jetzt schon plattformunabhängig(jaja langsam,...)
VCL.NET umläuft das System(wurde schon gesagt)=Inkompatibilität

IMHO ist es so, dass ich .NET bevorzugen würde, wenn ich mit vielen unterschiedlichen Leuten schnell zusamenarbeiten muss und nur Geschäftsprozess und nicht sehr tief greifende Sachen coden muss. Um die Zukunft würde ich mir dabei weniger Sorgen machen denn OOP wird so schnell nicht weg gehen und mit .XMI lässt sich das Grundgerüßt auch schnell in eine andere OO Sprache übernehmen.

Ich nutze es aber nicht, da MS bewußt die Möglichkeit auslässt das plattformunabhängig zu machen es aber trotzdem nur interpretiert wird(langsam) und mich weiter von der CPU weg bringt. Für sowas würde ich dann doch eher Java bevorzugen denn das ist IMHO das Konzept in Rheinform(OS unabhängige Controls,...), der Aufwand ist hier natürlich beträchtlich.

Delete - Fr 02.06.06 21:35

Hi alle zusammen!!!

Hier sind noch zwei Vorteile des Frameworks:

1. Das Microsoft Event Pattern. Basierend auf Multicast-Events ist es eine weiterentwicklung des Observer Patterns.

2. ECO. Das Prinzip ist mir leider noch nicht so geläufig, des solltet ihr besser irgendwo nachlesen bevor ich hier etwas falsches erzähl. Auf jeden Fall ist das eines der Highlights in Delphi 2005, aber leider nur in der Enterprise Edition enthalten.

Ich hoffe dass konnte bei der Entscheidung zwischen Win32 und .NET helfen.

also bis dann

Martin

Robert_G - Sa 03.06.06 14:24

mkinzler hat folgendes geschrieben:

Zitat:

Auf jeden Fall ist das eines der Highlights in Delphi 2005, aber leider nur in der Enterprise Edition enthalten.

In BDS 2005 auch in der Pro (abgespeckt).

BDS 2006. ;)

btw: ECO ist an sich eine nette Idee, dich mich damals mit D8 auch wirklich eine Weile gefangennahm.
Es ist aber so Reflection-lastig, dass es einfach ziemlich lahm ist... :(

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!