Delphi 8: Philosophie?

[Insider2004]

Kann jemand mir die Philosophie erklären, die hinter Delphi8.net steht. Soviel ich bisher mitbekommen habe ist das verdammt langsam und resourenhungrig. Das net-Zeug ist doch sowas wie Java. Oder? Wo liegen da überhaupt die Vorteile (ausser das MS wieder verdient). Warum gibt man das ausgereifte und schnelle Win-API auf?

[sui]

Glaub weil die NET plattformübergreifend ist.

[scp]

Zitat:

Zitat von sui

Glaub weil die NET plattformübergreifend ist.

"plattformübergreifend", hihi. Heisst wohl soviel wie 98/Me/NT4/2000/XP.
Naja, mal sehen wies mit Mono weitergeht.

[sui]

Meite damit, das Net-Proggs sowohl unter Windows als auch
unter Linux laufen.

Ich weiss es nicht genau, habs nur gelesen.

Was ist denn mit der LonghornSide-Bar? Läuft die auch unter Linux?

[scp]

Im Moment läuft nichts von .NET in Linux - es sei denn man nutzt Mono.
Man kann dort aber nicht einmal die WinForms verwenden, von der Avalon(Longhorn)-Technologie ganz zu schweigen.

[ak1]

Die bösen Buben von Microsoft wollen euch armen Programmierern das Geld aus der Tasche ziehen :-).

Mal im Ernst:

.NET ist wurde entwicklelt um die Erstellung von Softwaresystemen zu vereinfachen und zu verbessern, außerdem soll es eine Alternative zu Java darstellen. Die WinApi ist ja schön und gut aber es muss weitergehn. .NET ist insofern plattformunabhängig, dass alle .NET-Anwendungen unabhängig vom Betriebssystem laufen können (es wird keine Wi-Api benötigt), es muss halt nur das .NET-Framework auf dem Client und/oder Server installiert sein, und da hakt es eben, weil es derzeit nur auf Windowsmaschinen läuft. Mono ist ein Projekt, welches das .NET-Framework auf Linux und Unix zum laufen bringen soll (ist derzeit als Version 1.0 draußen).

[Phoenix]

Es gibt neben MONO auch noch das ROTOR Projekt.

Dieses wird mit dem Know-How von Microsoft direkt versorgt. Unter ROTOR ist es derzeit sogar schon möglich, WinForms basierte Applikationen unter Linux laufen zu lassen. Das allerdings noch recht instabil. Ist halt noch pre-Alpha.

.NET ist in sofern genial, wenn man schon einmal mit einem etwas komplexeren Framework gearbeitet hat. Und ich nehme die VCL da jetzt gezielt aus.

Ein Framework muss für mich die Unterstützung liefern, ohne Probleme eine n-Tier Applikation mal so in ein paar Minuten zu erstellen. Native Delphi (also mit VCL) tue ich mich da vor allem in der Datenbankschicht ohne BDE etwas schwer. Das .NET Framework hat hier zwar in der Business-Schicht noch einige defizite, aber die hat Borland zum Beispiel mit ECO schon ausgeräumt, und es gibt noch weitere Lösungen hierfür.

[Bernhard Geyer]

Zitat:

Zitat von Phoenix

Es gibt neben MONO auch noch das ROTOR Projekt.

Rotor hat aber Lizenztechnische Probleme

[woki]

Hi,

ohne in diesem Thread die Bedetung von .Net auch nur ankratzen zu können, schnell vier Punkte:

1. Eine dreichsichtige Anwendung kann man in ca 5 min (sagen wir mal eine Datenbank gibt es schon) auch unter Verwendung von VCL und COM+, und ohne .Net und auch ohne BDE aufsetzen (from scratch), und die Enterprise Core Objects gibt notfalls es da auch.

Ich formuliere hier mal etwas prägnant, will damit niemand auf die Füße treten:
2. DAS WINAPI ist nicht ausgereift sondern ausgelutscht: Es ist eine konzeoptionslose, unstrúkturierte, redundante Ansammlung von abertausenden von Funktionen, die selbst die MS-Entwickler offensichtlich nicht mehr duchschauen, (warum programmieren sie sonst diegleiche Funktion immer wieder).

3. Das WINAPI ist nicht schnell sondern .Net kann durch seine Fähigkeit prozessorspezifisch optimierten Maschinencode und sehr kleine executables zu erezeugen, die Geschwindigkeit von Anwendungsprogrammen auf aktuellen Prozessoren erheblich steigern. Das der Entwickler eventuell eine leistungsfähige Maschine braucht, kann da ja kein Hinderungsgrund sein.

4. Das Ziel von Microsoft mit .Net ist es nicht (und war es noch nie), dem Entwcickler, sondern dem Endkunden das Geld aus der Tasche zu ziehen.

Grüsse
Woki

[ak1]

Dem Kunden das Geld aus der Tasche ziehen zu wollen ist natürlich ne fiese Sauerei. Ich werden nach meinem bezahlten Urlaub mal meinen Chef dazu überreden, dass wir unsere Software ab sofort an unsere Kunden verschenken. Aber vorher will ich noch ne Gehaltserhöhung. ;-)

[Bernhard Geyer]

Zitat:

Zitat von woki

Eine dreichsichtige Anwendung kann man in ca 5 min (sagen wir mal eine Datenbank gibt es schon) auch unter Verwendung von VCL und COM+, und ohne .Net und auch ohne BDE aufsetzen (from scratch), und die Enterprise Core Objects gibt notfalls es da auch.

Aber in manchen Bereichen (z.B. SOAP bzw. Remoting) ist die .NET-Lösung eleganter und mit weniger Code zu erreichen.

Zitat:

Zitat von woki

Ich formuliere hier mal etwas prägnant, will damit niemand auf die Füße treten:
2. DAS WINAPI ist nicht ausgereift sondern ausgelutscht: Es ist eine konzeoptionslose, unstrúkturierte, redundante Ansammlung von abertausenden von Funktionen, die selbst die MS-Entwickler offensichtlich nicht mehr duchschauen, (warum programmieren sie sonst diegleiche Funktion immer wieder).

Kann ich nur voll zustimmen. Und das passiert den MS-Entwicklern auch in der Klassenbibliothek MFC/ATL auch zu genüge. Und dann noch teilweise mit entegengesetzter Logik.

Zitat:

Zitat von woki

4. Das Ziel von Microsoft mit .Net ist es nicht (und war es noch nie), dem Entwcickler, sondern dem Endkunden das Geld aus der Tasche zu ziehen.

Ich denke aber auch das M$ gezwungen war eine modernere Klassenbibliothek zu entwickeln, da mit MFC/ATL man schon an vielen Ecken und Enden an Grenzen dieser Frameworks gelangt ist. Ich kann mich noch mit "Schrecken" an die Zeit erinnern als ich MFC programmieren mußte. Wie umständliche vieles gegenüber der VCL realisiert wurde.
Aber dafür ist sie ja auch ein paar Jahre älter.

[Hansa]

Ich sehe das ganze so (obwohl auch ich noch nicht alles durchschaue) :

die WinAPi ist mittlerweile eine Sackgasse. Wobei die Betonung auf mittlerweile liegt. Im Laufe der Zeit kam immer mehr dazu, versionsabhängig usw. Dafür die Unmenge an Service-Packs usw.

Wie heißt es so schön ? "Viele Köche verderben den Brei". Und in der Programmierung handelt es sich sogar um eine weltweite Küche. Jeder kann da einen Teil des Gesamtmenüs so kochen, wie er will. Vor allem aber darf er sämtliche Zutaten verwenden, die er kennt.

Das ist für mich das wichtigste. Leider gibt es nämlich auch welche, die das ganze schöne, offene Gebilde ohne Ankündigung mit etwas Gift versetzen. EXE ist eben EXE. Da helfen nur Virenscanner u.Ä. Die haben aber den Nachteil, daß sie im Prinzip zu spät reagieren und nicht automatisch aktuell sind.

Im Prinzip müßte man das ganze Betriebssystem neu programmieren, um solchen Sachen von vorneherein Einhalt zu gebieten. Und das ist nun das Dilemma von M$. Wegen der großen Verbreitung geht das nicht ! Liebend gerne würden die jedem Windows Benutzer ein neues Betriebssystem verkaufen. :mrgreen: Aber sogar verschenken ginge nicht, denn wer weiß wo noch irgendwo ein Uralt-Rechner mit einem wichtigen Programm läuft.

Die Treiber für zigtausende Uralt-Hardwareteile neu programmieren ? Geht wohl auch nicht. Also muß man mit den vorhandenen Gegebenheiten vorlieb nehmen.

Die logische Folgerung ist dann, die Programmwelt zweizuteilen. .NET Programme und der Rest so wie bisher. Vorerst ist das natürlich nichts halbes und nichts ganzes. Aber das kann es (irgendwann) noch werden. In der Praxis bedeutet das, daß für neue .NET Programme ein Zusatz gebraucht wird : das .NET Framework. Mit D8 geschriebene Programme z.B. laufen nämlich nur mit installiertem .NET-Framework.

Im Prinzip laufen die eigentlich gar nicht, zumindest nicht von alleine. Die Zeiten lauffähiger EXEs so wie gewohnt ist dann vorbei. Heißen die dann überhaupt noch EXE ? :gruebel: Denn : erst durch einen JIT (Just in time) Compiler werden sie zu einem lauffähigen Programm. Es scheint die einzige Möglichkeit zu sein, einen Virus zu 100 % auszuschalten. Denn es wird erst ein Programm ausgeführt, wenn es der JIT-Compiler zuläßt. Werden genau an diesem Punkt geeignete Vorsichtsmaßnahmen getroffen, so kann (theoretisch) eigentlich nichts mehr passieren.

Folgende Nachteile bringt das mit sich : wie gesagt wird das Programm nochmals compiliert. Delphi-"Compilierung" alleine reicht nicht mehr ! Außerdem die Sicherheitsüberprüfungen des Codes. Deshalb die "Lahmheit". Ich würde aber sagen, daß man das in Kauf nehmen kann. Ich glaube, das passiert nur beim erstmaligen starten.

Wegen der ausgeuferten WinApi und deren Sicherheitslöcher muß für Ersatz gesorgt werden. Die muß weg und was besseres neu programmiert werden. Das sind die WinForms. Sehen für mich schon wesentlich besser aus, als die WinApi. Da wurde auch vieles reingepackt, was es vorher nicht gab. Einige Fremdkomponenten sind nicht mehr nötig. Für jetzige Winapi Programme hat das ganze auch noch den Effekt, daß sie später mit Longhorn so laufen, wie unter Win die Dos-Programme. Also nur in einer Emulation. Und ein .NET Programm läuft natürlich nicht ohne installiertes .NET.

Fazit aus meiner Sicht : von außen sichtbare wichtige Veränderungen wird es kaum geben, hinter den Kulisssen um so mehr. Ich werde deshalb auf WinApi-Zugriffe, wenn es irgendwie geht verzichten. Auf gar keinen Fall werde ich bewußt, so wie einige hier, ein nonVCL Programm machen. Niemals. :mrgreen:

Was jetzt noch an Fragen offen bleibt, ist vor allem die VCL.NET. Jemand hat behauptet, die würde immer noch WinApi Aufrufe benutzen. Insofern wäre es unmöglich damit ein reines .NET Programm hinzukriegen. So ganz glaube ich das aber nicht.

[Phoenix]

Es ist aber so. Sogar der Delphi 8 Compiler meckert, wenn man die VCL verwendet, das diese Anwendung dann nicht Plattformunabhängig sein wird.

Und das greift schon bei Windows CE: Eine VCL.net Anwendung wird nicht auf einem Pocket PC laufen, eine Windows Forms Anwendung hingegen schon.

[Bernhard Geyer]

Zitat:

Zitat von Phoenix

Und das greift schon bei Windows CE: Eine VCL.net Anwendung wird nicht auf einem Pocket PC laufen, eine Windows Forms Anwendung hingegen schon.

Nicht ganz. Eine Windows Forms Anwendung wird nur auf dem Pocket PC laufen, wenn nur die Funktionen des Compact Frameworks verwendet werden. Und bei Handys mit Windows CE läuft (wenns mal eines gibt) nur ein Compact-Compact Framework.
Auch muss man seine Anwendung entsprechend den kleineren Displays teilweise neu programmieren.

[Phoenix]

Äh. Ja. Das schon. Aber ein WinForm gibt es nunmal im Compact Framework, eine VCL Form eben nicht. ;-)

[Bernhard Geyer]

Darauf sollte man immer hinweisen. Es ist zwar auf CE die gleiche Klassenbibliothek und konzepte verfügbar. Aber .NET-Programme laufen ohne vorkehrungen (und Programmanpassungen) (trotz entsprechender Namensgebung von M$) nicht so einfach auf PocketPC.

Ich hatte schon öfters den Fall, das ein Kunde gefragt hatte: "Das Programm läuft doch auch auf den PocketPC, oder? Ist doch auch Windows." Und bis man denen immer erklärt das das nicht so einfach ist und auch das Word auf PocketPC eigentlich 'ne komplette Neuentwicklung gegenüber den Word auf dem "richtigen" PC's

[Hansa]

Zitat:

Zitat von Phoenix

Es ist aber so. Sogar der Delphi 8 Compiler meckert, wenn man die VCL verwendet, das diese Anwendung dann nicht Plattformunabhängig sein wird...

Was aber heißt jetzt plattformunabhängig ? Ist .NET als Plattform in diesem Kontext anzusehen ?

Kannst Du diese Fehlermeldung mal genau posten oder Screenshot ?
Oder muß ich jetzt doch tatsächlich mein D8 neu überspielen. Das wurde Opfer einer Win-Neuinstallation. :twisted:

[Bernhard Geyer]

Zitat:

Zitat von Hansa

Zitat:

Zitat von Phoenix

Es ist aber so. Sogar der Delphi 8 Compiler meckert, wenn man die VCL verwendet, das diese Anwendung dann nicht Plattformunabhängig sein wird...

Was aber heißt jetzt plattformunabhängig ? Ist .NET als Plattform in diesem Kontext anzusehen ?

Die VCL macht ausgiebig gebrauch von der Win32-Schnittstelle, wie sie auf x86-Systemen (Win95-2003) definiert ist. D.h. man kann eine Anwendung nicht unter PocketPC laufen lassen, als auch nicht als native-Anwendung unter Linux (Dafür gibt/gab es ja CLX). Diese Fehlermledung ist jedoch nicht unter D8 eingeführt worden, sondern sie gibt es seit D6 (um darauf hinzuweisen, das der Code in der Art und weise nicht mit Kylix unter Linux kompiliert werden kann.

[Hansa]

PocketPC ist doch ein ganz anderes Thema. Es gibt wohl kaum ein PC-Programm, welches ungeändert darauf läuft. Wie soll denn das auch gehen, bei so einem Mini-Bildschirm ? :shock:

Es geht mir um einen ganz normalen Windows-PC mit .NET.

[Phoenix]

Plattformunabhängig sehe ich dem Zusammenhang sogar die Verwendung von Software auf 64bit - Prozessoren.

Und da die .NET - Anwendungen bei erster Ausführung Maschinenoptimiert fertigkompiliert werden, sind meine Anwendungen mit .NET eben auch dort optmimal ausführbar.

Versuch mal, eine native Delphi-32bit - Applikation ohne kompilierung in entweder einem Cross-Compile-Environment oder direkt auf der Zielarchitektur kompiliert zu erstellen. Das problem fällt bei .NET wenigstens schonmal weg.

[Tubos]

Zitat:

erst durch einen JIT (Just in time) Compiler werden sie zu einem lauffähigen Programm. Es scheint die einzige Möglichkeit zu sein, einen Virus zu 100 % auszuschalten

Das glaube ich nicht, da unter Longhorn (und sicher auch noch einige Zeit danach) noch immer Win32-Programme unterstützt werden, wenn ich das richtig mitgekriegt habe...
aber wenn das mal nicht mehr so ist, ist es sicher eine gute Lösung!

[dizzy]

Win32 Anwendungen laufen in Longhorn dann aber in einer Sandbox, ähnlich wie Java-Applets mit eingeschränkten Rechten, wenn ich das richtig verstanden habe. Somit wird potentiell schädlichem Code verwehrt bleibe gewisse Dinge zu tun. In wie weit das saubere Programme "kaputt-sichert", oder Schädlinge tatsächlich einengt vermag ich aber nicht zu beurteilen.

[Hansa]

Ich habe jetzt D8 inkl. Framework neu installiert. Von der angesprochenen Warnung ist nichts zu sehen. 8) VCL.NET Projekt neu angelegt unter D8.

[Robert_G]

Zitat:

Zitat von Hansa

Ich habe jetzt D8 inkl. Framework neu installiert. Von der angesprochenen Warnung ist nichts zu sehen. 8) VCL.NET Projekt neu angelegt unter D8.

Mit den Warnungen meinte er Delphi32. ;)

Zitat:

Zitat von Woki

4. Das Ziel von Microsoft mit .Net ist es nicht (und war es noch nie), dem Entwcickler, sondern dem Endkunden das Geld aus der Tasche zu ziehen.

mhhh... :gruebel:
IMVHO ist das FrameWork ein kostenloses AddOn zu den aktuellen Winversionen, damit man schon jetzt Anwendungen entwickeln kann, die auf Longhorn laufen problemlos können, theoretisch zumindest ( erstens kommt es anders und zweitens als man denkt :roll: ).

BTW: Ich dachte für die Vorstellung von Herrn Gates als ewigen Anti-Christ sind wir mittlerweile zu erwachsen. ;)

Zitat:

Delphi 8: Philosophie?

Ganz einfach:

• Die C#Express 2005 Beta saugen
• große Augen machen :shock:
  BTW: Das wird die "Billig-Version" von C# (ein Feuervögelchen flüsterte etwas von ca. 100€ :!: ).
  Sie ist als IDE & im Funktionsumfang soviel genialer als D8 das sich Borland warm anziehen muss. (Der XSD Designer und das Refractoring sind einfach :thuimb: )

[Phoenix]

Zitat:

Zitat von Robert_G

Sie ist als IDE & im Funktionsumfang soviel genialer als D8 das sich Borland warm anziehen muss. (Der XSD Designer und das Refractoring sind einfach :thuimb: )

Fehlt nur noch ein "Visual Delphi Express 2005" und ich wechsle zu MS.
Aber da MS es einfach nicht auf die Reihe bekommt eine einfache Sprache zu entwickeln... :wink:

[ak1]

@Robert:

Zitat:

Visual C# 2005 Express Edition includes many of the same productivity features found in Visual Studio, all streamlined to fit the needs of the non-professional Windows developer.

Heisst das nun, dass es nicht für professionelle Projekte geeignet oder erlaubt ist?

[Phoenix]

Das heisst, das (noch) nicht professionelle Entwickler (in anderen Worten Hobby-Coder) damit auch zurechtkommen sollen.

Ziel der Aktion ist es, mehr Entwickler für die Windows-Plattform zu gewinnen.

[MathiasSimmack]

Ich fürchte, wenn Borland nicht aufpasst und aus einigen Fehlern der Vergangenheit lernt, dann wird es ein Delphi 10 vermutlich nicht geben. Oder es kommt tatsächlich zum von dir gewünschten Visual Delphi Express, @Phoenix. ;)

Zitat:

Aber da MS es einfach nicht auf die Reihe bekommt eine einfache Sprache zu entwickeln

Sag nicht so was. C# ist sehr einfach, und ich glaube es mehrfach gelesen zu haben, dass der Entwickler dieser Sprache einer der Entwickler (wenn nicht gar der Entwickler) von Delphi war.

[DaFox]

Hi Mathias,

Zitat:

Zitat von MathiasSimmack

C# ist sehr einfach, und ich glaube es mehrfach gelesen zu haben, dass der Entwickler dieser Sprache einer der Entwickler (wenn nicht gar der Entwickler) von Delphi war.

Richtig, du redest von Anders Heijlsberg. Er war der Delphi Chefentwickler bei Borland, bevor er von Microsoft abgeworben wurde.

Gruß,
Markus

[ak1]

C# und Teile des .NET-Frameworks sind zu sehr großen Teilen von von Java und J2EE "abgekupfert". Ein gewisser "Anders Heijsberg" von Borland war/ist einer der Chefentwickler des Visual Studio.NET, was ich der IDE auch schon von Anfang an angesehen habe.
Zu Borland kann ich nur sagen, dass sie es wohl schwer haben werden in anbetracht von Eclipse (kostenlos und garnicht mal schlecht (besonders Version 3.0)) und dem JBuilder sowie Visual Studio und C#-Builder, Delphi 8.

Schauen wir mal.

[Phoenix]

Ja, aber dennoch ein {..} - Code schlechter zu lesen und verstehen als ein gut strukturierter Delphi-Code. Wie war das nochmal?

Zitat:

C is almost a real language. Even the name sounds like it's gone through
an optimizing compiler. Get rid of all of those stupid brackets and we'll talk.

Das gleiche gilt für C# ;-)

[Hansa]

Zitat:

Zitat von Robert_G

..Mit den Warnungen meinte er Delphi32. ;)..

Was ist jetzt ? Wer bringt Licht ins Dunkel, was mit der VCL.NET jetzt genau los ist ?

[woki]

Zitat:

Zitat von Robert_G

Zitat:

Zitat von Woki

4. Das Ziel von Microsoft mit .Net ist es nicht (und war es noch nie), dem Entwcickler, sondern dem Endkunden das Geld aus der Tasche zu ziehen.

mhhh... :gruebel:
IMVHO ist das FrameWork ein kostenloses AddOn zu den aktuellen Winversionen, damit man schon jetzt Anwendungen entwickeln kann, die auf Longhorn laufen problemlos können, theoretisch zumindest ( erstens kommt es anders und zweitens als man denkt :roll: ).

BTW: Ich dachte für die Vorstellung von Herrn Gates als ewigen Anti-Christ sind wir mittlerweile zu erwachsen. ;)

Das war auch lediglich ein nicht wertend gemeinter Hinweis auf das Geschäftsmodell von Microsoft. Microsoft verdient nicht an Entwiclungsumgebungen sondern zahlt da mächtig drauf, oder Zitat von einer Konferenz:

Microsoft macht an jeder Version von VS soviel Verlust wie Borland Umsatz. Ohne sich jetzt um genaue Zahlen streiten zu wollen, kann die Überlebensstrategie von Borland auch nicht sein, nur mit Compilern gegen MS überleben zu wollen, und ist es ja auch nicht. Aber Borland tut schon, was möglich ist, um es Entwciklern einfacher zu machen, sich nicht auf Gedeih und Verderb an MS hzu Ketten. Und während MS es jetzt endlich mal geschafft hat, nachdem sie den Chefentwickler von Delphi (Anders H...) quasi gekidnapt haben, mit C# eine State of the Art Entwicklngsumgebung zu haben, ist Borland bei der Unterstützung des Entwiclungsprozesses schon wieder ein ganzes Stück weiter (Application Lifecycle Management), was Microsoft auch erkannt und akzeptiert hat, (siehe Eröffnungskeynote zur Microsoft TechEd). Borland tut aber was immer möglich und für borland bezahlbar ist, um Entwicklern die Chance zu geben, sich so wenig wie möglich an eine Plattform zu ketten. Dies macht Borland zu einem Player im Markt, von dem ich hoffe, dass er noch lange gegen die Riesen MS und IBM (Eclipse) überlebt, denn er ist der einzige große, der Entwcilungstools macht, um gute Entwciklungstools zu machen, und nicht nur um die eigenen Plattform zu supporten.

Grüsse
Woki

[maestro]

Zitat:

Zitat von Hansa

Was ist jetzt ? Wer bringt Licht ins Dunkel, was mit der VCL.NET jetzt genau los ist ?

Lies doch einfach selbst: http://www.delphi-source.de/grundlag...lfordotnet.php
Im Internet gibt es genügend Quellen dazu.