Delphi 8 und das .NET

[Hansa]

Delphi 8 kann man vergessen, aber es ist nur eine Frage der Zeit, bis Besserung da ist. Die waren wahrscheinlich gezwungen schnellstmöglich etwas für .NET auf den Markt zu werfen. Ich lasse mich davon nicht verrückt machen.

.NET ist auf jeden Fall etwas ganz anderes und besser, als diese komische WinApi. Ich weiß, die ist sehr beliebt, da man damit Window etwas aushebeln kann, bzw. Sachen nutzt, die eigentlich für einen ganz anderen Zweck gedacht waren. Auch für Viren usw. Und genau das hat ihr jetzt definitiv das Genick gebrochen. 8) Spricht es sich herum, daß Viren mit der WinApi im Zusammenhang stehen, dann wird sich ein WinApi Programm wohl nicht mehr verkaufen lassen.

[mirage228]

Zitat von MathiasSimmack:

Es gibt doch Alternativen.

Zugegben C# hat was (auch gute IDEs), aber D8 war für mich halt eine Enttäuschung (ich hoffe nur D9 besser wird und dass Borland wirklich was gelernt hat).
Wie gesagt, ohne die richtige Delphi-IDE für .NET - macht mir .NET auch nur halb so viel Spaß.

mfG
mirage228

[MathiasSimmack]

Zitat von Hansa:

Spricht es sich herum, daß Viren mit der WinApi im Zusammenhang stehen, dann wird sich ein WinApi Programm wohl nicht mehr verkaufen lassen.

Soll das ein Beweis für die Intelligenz eines solchen ... na, ich sage mal: Kunden sein? Wohl eher das Gegenteil. Solange er ein API-basiertes OS mit all seinen Lücken benutzt, solange wird er auch potentielle Probleme haben. Ob er ein API-Programm nun benutzt oder nicht.

[Hansa]

Zitat von MathiasSimmack:

Soll das ein Beweis für die Intelligenz eines solchen ... na, ich sage mal: Kunden sein? ...

Erst mal : die Intelligenz eines Endanwenders sollte absolut keine Rolle spielen. Auch nicht die Erfahrung. Ein gewisses Maß davon sollte aber schon vorhanden sein. Wer nicht lesen kann, der kann wohl auch das ausgekügelste und einfachste Computerprogamm nicht bedienen. 8) Mit einem intelligenten Programm, das plausible Fehlermeldungen präsentiert, keine Klammeraffengriffe benötigt und auch sonst vom Bildschirm her sauber strukturiert ist, ermöglicht es auch einem ungeübten Anwender damit zurecht zu kommen. Insofern kann ein gewisses Maß an fehlender Intelligenz, wobei ich eher an der Erfahrung einiger zweifeln würde, sehr wohl vom Programm kompensiert werden.

Wenn ich nun sehe, was einige (sogar hier) über .NET wissen, so erscheint es mir fast unmöglich, einem Endanwender das zu verklickern, so daß er es versteht. Aber das ist auch gar nicht nötig. Er wird irgendwann etwas über .NET gehört haben oder in absehbarer Zeit hören. Ob er es versteht oder nicht ist völlig egal. Je nachdem, wo er die Information her hat, wird sie so aussehen, daß es ihm egal ist, oder er gezielt nach .NET fragt. Ist das eigene Programm dann ein .NET, so werden die Chancen spürbar steigen, wenn es nicht sogar ein K.O. Kriterium wird. Und dieses Szenario, a la "WinApi Pfui!" wird sich spätestens mit Longhorn durchsetzen.

Ich nähehre mich jetzt langsam dem eigentlichen Theme. Dafür muß ich Mathias' Posting noch etwas weiter zerlegen.

Zitat:

Solange er ein API-basiertes OS mit all seinen Lücken benutzt, solange wird er auch potentielle Probleme haben. Ob er ein API-Programm nun benutzt oder nicht.

So ganz Unrecht hast Du da nicht, aber es ist zu bedenken, daß wir uns mit dem .NET Framework in einer Art Zwischenstadium befinden. Vergleichbar etwa mit der Zeit von DOS und Win 3.1. Win32 ist das Betriebssystem und .NET ein Aufsatz dazu, so ähnlich wie Win 3.11 nur eine Benutzeroberfläche war. Ich weiß, der Vergleich hinkt, aber irgendwie paßt er schon. Damals hatten die Leute gefragt : "Ist das ein DOS oder ein Windows Programm ?". Bekannt waren nur die 2 Namen sonst nichts.

Wichtiger als D8 oder die WinApi ist nun die Frage, wie wirkt sich mittelfristig .NET auf die Programmierung aus ? Man hört viel von Emulationsmodus, Zwischenschicht usw.

Zum Verständnis hilft hier als Eselsbrücke ein DOS-Programm unter Win32. Man starte einmal den Editor in der MS-DOS Eingabeaufforderung. Also z.B. mit "edit Test.txt", gebe einen Text ein und versuche den zu drucken, wobei aber der Drucker aus ist. Was passiert ? Je nach Konstellation springt das Programm früher oder später vom Dos-Modus zurück nach Windows. Der Desktop ist da und ein Win-MessageDlg "Beim Drucken des Dokumentes bla ist ein Fehler aufgetreten. wiederholen abbrechen" erscheint. Wie das ? DOS ist zwar da, hat aber nicht die volle Kontrolle über den Rechner. Der Chef ist immer noch Windows. Unten in der Taskleiste ist die Eingabe-Aufforderung noch vorhanden, man kann also durch anklicken wieder in seinen Text zurückkehren.

Genauso ist es in Zukunft mit den WinApi-Programmen. Da heißt der Chef nur .NET. Alle WinApi-Aufrufe werden von dem argwöhnisch beobachtet. Das kostet einiges an Rechenzeit und wird sicherlich viel an Fehlermeldungen produzieren, die heute noch unbekannt sind. Und sonst noch einiges an Ungemach.

IMHO ist es deshalb falsch, zu sagen: "Was schert mich denn .NET ? Ich programmiere meine WinApi-Programme einfach weiter." D8 wurde nicht umsonst entwickelt. Die haben sich schon was dabei gedacht, wenn es auch noch nicht fertig, bzw. momentan noch Schrott ist. Damit geht es nämlich bei Borland weiter : die werden wohl kaum noch nennenswert in D7 oder WinApi investieren. Wichtige Neuerungen werden sich wohl nur noch in D8 aufwärts finden.

[Tubos]

Eine weitere Abstraktionsschicht?
Ist das nicht alles ziemlich langsam?
Heißt mehr Computerleistung, dass sich Programmierer nicht mehr um die Effizienz ihres Codes scheren?

[Hansa]

Ja, eine weitere Schicht, aber nur für die alten WinApi Programme. reine .NET Progs sind sauschnell und klitzeklein. Für Nanosekunden- und Bytejäger empfiehlt es sich eventuell, auf MHz umzusatteln.

[Phoenix]

Zitat von Insider2004:

Ist auch genauso resourcenhungrig und daher zum jetzigen Zeitpunkt völlig überflüssig. Wer performante Anwendungen machen muss wählt die Win-Api.

[ ] Du hast Verstanden worum es geht und schonmal selber .NET Anwendungen gebenchmarkt.
[X] Du solltest z.B. die letzte Ausgabe des Entwickler kaufen und lesen, wie performant .NET Anwendungen im Vergleich zu Api - Anwendungen wirklich sind.

[Phoenix]

Zitat von Tubos:

Eine weitere Abstraktionsschicht?
Ist das nicht alles ziemlich langsam?

Ja, und nein.
Die Abstraktionsschicht hat eben den Vorteil, das der Unterbau (derzeit WinAPI, unter Longhorn dann dessen Subsysteme, unter Linux eben die POSIX-Calls und das X-System) ausgetauscht werden kann, ohne das es die Anwendung auch nur Ansatzweise juckt.

Das bedeutet wiederum, das eine .NET Anwendung (nach einem einmaligen etwas langsameren Start) eben auch nativ 64 bit benutzen wird, wenn es der Prozessor erlaubt, ohne das man sich bei seinen Datentypen erstmal als Entwickler darum kümmern muss.

Die .NET Frameworl Klassen selber (zum Beispiel das WinForm) nutzen derzeit selber WinAPI um dargestellt zu werden - anders geht es ja derzeit nicht, deshalb sind .NET Anwendungen auch ca. gleich schnell wie API Anwendungen. Die paar MS sind kaum messbar. Unter Longhorn wird exakt das gleiche WinForm aber eben nicht mehr API sondern Avalon verwenden und wäre damit genauso performant wie Avalon es erlaubt.

Noch ein Beispiel: Anstelle der Indy TCP/IP Protokolle sollte man vielleicht in Zukunft eher die .NET Sockets verwenden. Ich meine.. es ist doch schön wenn dann irgendwann IPv6 global kommt und man keine einzige Zeile ändern muss, oder?

[Robert_G]

• .Net = langsam?
  .Net ist nach meiner Erfahrung nur langsamer wenn das sog. "marshaling" verwendet wird.
  Das ist ein Trick mit dem .Net Datentypen zu WinApi-Typen "übersetzt" werden (und auch andersherum ).
  Das läuft einem bei COM oder P/Invoke über den Weg.
  Außerdem bestraft einen die CLR für jeden P/I Call mit einem kompletten Stackwalk -> Es muss ja schließlich ALLES .Net compliant gefriemelt werden bevor eine Win32-DLL in/neben der CLR laufen darf.
  Das ist auch der Grund warum die VCL.Net so ar***langsam ist.
  
• .Net = ressourcenhungrig?
  Jedem, der erste Gehversuche mit .Net macht dürfte eins aufgefallen sein: Die Anwendungen verbrauchen verdammt viel RAM!
  Der Grund ist eigentlich total simpel:
  Solange dein System noch genügend freien RAM hat, sieht die Garbage Collection überhaupt keinen Sinn dahinter, unnötig CPU-Leistung zu vergeuden um aufzuräumen.
  
  Wer unbedingt aufräumen will kann zum Bleistift nach einer Schleife ...GC.Collect(); ... ausführen.
  
  Ein weiterer Grund für den hohen RAM-Verbrauch dürfte das ADO.Net DataSet sein.
  Da man sich mit einem DataSet eine Menge Arbeit ersparen kann, wird es oft eingesetzt.
  Da das DataSet aber _fast_ eine eigene Databank ist, braucht es natürlich wesentlich mehr Ressourcen als ein simpler Array oder eine Collection.

[Tubos]

Zitat:

[ ] Du hast Verstanden worum es geht und schonmal selber .NET Anwendungen gebenchmarkt.
[X] Du solltest z.B. die letzte Ausgabe des Entwickler kaufen und lesen, wie performant .NET Anwendungen im Vergleich zu Api - Anwendungen wirklich sind.

da hast du recht *duck*
aber es klingt halt ziemlich komisch das ganze

Danke!