Delphi 8: Philosophie?

[Bernhard Geyer]

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

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

[Bernhard Geyer]

Zitat von Hansa:

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 ?

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.