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:

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:

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:

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

[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. :shock:

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:

Zitat von Hansa

Im eigenen Source wirst du vielleicht 10 WinApi Aufrufe finden.

Und wie viele gibt es wohl in der VCL? :roll:

[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.

[nailor]

Zitat:

Zitat von Luckie

Zitat:

Zitat von Hansa

Im eigenen Source wirst du vielleicht 10 WinApi Aufrufe finden.

Und wie viele gibt es wohl in der VCL? :roll:

genug. aber es währe kein problem, dir die API unterm Ar** wegzuklauen, wenn dafür auch die VCL angepasst würde, wenn du rein VCL programmierst. Wenn du allerdings WinAPI programmierst, bekommst du dann echte Probleme. Von daher sollte es irgendwann mal die Zeit geben, wo das mit WinAPI nicht mehr so geschickt sein wird. Und ich nehme ebenso wie Hansa an, dass das der Fall sein wird, bevor der VCL das gleiche Schicksal wiederfahren wird.

... was nicht heißen soll, dass es bald sein wird, und nach der Umstellung immer noch ein großer Bedarf an Api-Programmierern bestehen wird, die so manchen Code porten.

[MathiasSimmack]

Zitat:

Zitat von 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.

Ja, aber was machen wir in der Zwischenzeit? ;)

[Luckie]

Zitat:

Zitat von MathiasSimmack

Ja, aber was machen wir in der Zwischenzeit? ;)

Däumchen drehen und das -Net Framework schlecht machen. ;)

[MathiasSimmack]

Däumchen drehen, okay. Aber .NET schlechtmachen? Nö. So übel ist das nämlich gar nicht.

[Treffnix]

Möchte jemand Tee? :mrgreen:

Also ich kann mich mit .NET auch noch nicht anfreunden. Über mehr als ein paar Testprogrämmchen ohne tieferen Sinn bin ich da noch nicht hinausgekommen...

[mirage228]

Zitat:

Zitat von Treffnix

Möchte jemand Tee? :mrgreen:

Oh ja, gerne. Einen "Eearl Gray Tea" bitte.

Zitat:

Zitat von Treffnix

Also ich kann mich mit .NET auch noch nicht anfreunden. Über mehr als ein paar Testprogrämmchen ohne tieferen Sinn bin ich da noch nicht hinausgekommen...

So geht es mir auch. Ich konnte mich mit D8 auch noch nicht anfreunden :-(

mfG
mirage228

[nailor]

ich finde es klasse. es hat sehr große ähnlichkeiten mit der VCL ohne deren hauptsächlichen nachteil - die großen exen die dabei rumkommen. über die runtime librarys die man braucht mal weggesehen.

[MathiasSimmack]

Zitat:

Zitat:

Zitat von Treffnix

Also ich kann mich mit .NET auch noch nicht anfreunden. Über mehr als ein paar Testprogrämmchen ohne tieferen Sinn bin ich da noch nicht hinausgekommen...

So geht es mir auch. Ich konnte mich mit D8 auch noch nicht anfreunden :-(

Es geht ja auch nicht um Delphi 8 sondern um .NET. Ob du dich mit Delphi 8 anfreunden kannst oder nicht (so richtig konnte ich es auch nicht, zugegeben), das ändert ja nichts an .NET.

[mirage228]

Zitat:

Zitat von MathiasSimmack

Zitat:

Zitat:

Zitat von Treffnix

Also ich kann mich mit .NET auch noch nicht anfreunden. Über mehr als ein paar Testprogrämmchen ohne tieferen Sinn bin ich da noch nicht hinausgekommen...

So geht es mir auch. Ich konnte mich mit D8 auch noch nicht anfreunden :-(

Es geht ja auch nicht um Delphi 8 sondern um .NET. Ob du dich mit Delphi 8 anfreunden kannst oder nicht (so richtig konnte ich es auch nicht, zugegeben), das ändert ja nichts an .NET.

Ja, du hast Recht. .NET an sicht ist ne super Idee, aber ohne ein vernünftiges Delphi macht mir .NET auch nur halb so viel Spaß :-(

mfG
mirage228

[MathiasSimmack]

Es gibt doch Alternativen. Abgesehen davon denke ich, dass Borland aus den vielen ... äh ... nicht so guten Meinungen über D8 doch was gelernt hat.

[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:

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:

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

[Hansa]

Zitat:

Zitat von MathiasSimmack

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

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

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!" :mrgreen: wird sich spätestens mit Longhorn durchsetzen.

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

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. :mrgreen: 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. :mrgreen: 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? :roll:

[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. :mrgreen:

[Phoenix]

Zitat:

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:

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 ...
  Delphi-Quellcode:

  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!

[nailor]

@Hansa: Zur Zeit sehen die Endanwender (und haben damit beinahe recht, da es für .NET bisher sozusagen nur den WinAPI-Unterbau gibt) sowas wie die VBRuntime Librarys. Nur dass es absolut kein Problem wäre, einen komplett neuen Unterbau zu schaffen, sodass das Programm auch unter anderen Systemen laufen würde (mono.net oder eben auch das, was mit Longhorn kommen wird). Und die "Langsamkeit" hängt ganz entscheidend mit dem zusammen, was Phoenix gesagt hat.

[sharkx]

Ich glaube nicht das Borland gezwungen war schnellstmöglich eine .NET IDE zu basteln. Zumal die C# Sprache mit dem Chefentwickler von Borland entwickelt wurde.

Ich Code selbst seit über einem Jahr intensiv in C# (jedoch mit der VS IDE) und habe eine Menge Vorteile gegenüber der alten Win32Api kennen gelernt.

Ab Longhorn wird die .NET Api die Win32Api definitiv ablösen.

Gruß
sharkx

[MathiasSimmack]

Zitat:

Zitat von sharkx

Ich glaube nicht das Borland gezwungen war schnellstmöglich eine .NET IDE zu basteln. Zumal die C# Sprache mit dem Chefentwickler von Borland entwickelt wurde.

Ja, aber nicht von und bei Borland. Oder?

[Phoenix]

Zitat:

Zitat von sharkx

Ich glaube nicht das Borland gezwungen war schnellstmöglich eine .NET IDE zu basteln.

DOch, Borland war da einfach etwas zu langsam. Der C# Builder kam dann ja heraus, und auf der gleichen IDE setzt ja jetzt auch D8 auf. Meines Erachtens sollte Borland dahin gehen Delphi und C# (und C++ ?) - also im Prinzip alle Sprachen - in einer IDE zu vereinen - so wie es das VS auch macht.

[sakura]

Zitat:

Zitat von sharkx

Ich glaube nicht das Borland gezwungen war schnellstmöglich eine .NET IDE zu basteln.

Doch, dass waren die schon. Borland musste zeigen, daß auch Delphi auf dem .NET Markt mitspielen will. Und es war damals besser Delphi 8 unfertig auf den Markt zu werfen als noch mehr Kunden zu verlieren die auf andere Sprachen wechseln.

Durch die schlechte Version von Delphi haben die bestimmt auch einige Kunden verloren, aber wahrscheinlich sehr viel weniger als wenn die nichts präsentiert hätten. Delphi.NET hat gegenüber anderen .NET Sprachen auch einige Alleinstellungsmerkmale (Beispiel Class Helpers).

@Hansa: Es ist anzunehmen, daß in Delphi 9 auch der Win32 Compiler komplett überarbeitet wurde. Hier mal ein Zitat zum Thema for A in B do, da es beide Welten betrifft ;)

http://homepages.borland.com/dthorpe/blog/delphi/2004_08_01_archive.php#109211211041479238

p.s. One last little tease: this for..in syntax is not limited to the .NET platform. It works just peachy in the Win32 Delphi compiler as well!

...:cat:...

[sakura]

Zitat:

Zitat von Phoenix

DOch, Borland war da einfach etwas zu langsam. Der C# Builder kam dann ja heraus, und auf der gleichen IDE setzt ja jetzt auch D8 auf.

Nicht ganz, Delphi 8 war BDS 2.0, C# war BDS 1.0. Es ist zwar dieselbe Basis, aber schon eine höhere Version (mit mehr Bugs :mrgreen:)

...:cat:...

[MaBuSE]

Zitat:

Zitat von sakura

(mit mehr Bugs :mrgreen:)

Wer wird denn schon so kleinlich sein :stupid: