Delphi-PRAXiS - Prism Was ist .NET?

Seite 2 von 3

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)

- - Prism Was ist .NET? (https://www.delphipraxis.net/3112-ist-net.html)

Naja Shadow, Du bist schon ein wenig ein Schwarzmaler :)

Ich selber finde .NET in Hinblick auf die 'Plattformunabhängigkeit' aber eher einen schwachen Witz. - Mit "Platform" meint Microsoft schliesslich nicht Dos / Win / Novell / Unices, sondern einfach Win98, WinMe, Win2k, WinXP und Windows Server 2003 - sprich alles in fester Microsoft - Hand.

Es gibt zwar im openSource-Bereich bereits versuche, daß zur Ausführung des Zwischencodes notwenidge .NET - Framework auch unter POSIX zur Verfügung zu stellen, die Versuche sind aber bisher noch nicht allzu weit gediehen.

Wenn jemand also unter Plattformunabhängigkeit von .NET meint, er könne ein und dieselbe Software unter Win und Linux verwenden, hat er sich also leider ganz gewaltig geschnitten. :(

Ich selber code also weiterhin in "normalem" Delphi mit der CLX. Damit bin ich dann hinterher wenigstens auch auf Linux lauffähig. Schade nur, daß Borland die VCL und nicht die CLX in einen .NET - Namespace portiert. Im anderen Falle hätten wir mit einer .NET - CLX tatsächlich einmal best of both worlds in unseren Händen. - So müssen wir uns nun unterscheiden: tatsächlich Plattform_un_abhängig mit Delphi und Kylix und der CLX oder eben .NET mit der VCL nur innerhalb der .NET - Sprachen.

Wobei ich da sagen muss.... C# ist schon schick... - Ist schliesslich ja auch von einem Ur-Delphianer entwickelt :))

Hmm, wenn ich das jetzt richtig verstanden hab wird der Zwischencode doch nur beim ersten Starten ausgeführt, danach liegt dann doch ein "echtes" x86 (oder sonstwas) - Programm vor, dass dann auch sich von wegen Prozessorlast und ähnlichem in Grenzen halten wird.

Nichtsdestotrotz hat Shadow irgendwo schon recht, da wird schon wieder mehr weggekapselt :roll:

Moin ShadowCaster,

was bringt Dich denn auf die Idee, man könne in .NET Programmen keine API Funktionen mehr benutzen?
Du solltest eigentlich jede Funktion einer beliebigen DLL importieren können, wie Du es jetzt schon mit den API Funktionen in Delphi machen musst (bzw. wie Borland es für viele Funktionen schon getan und mitgeliefert hat).

Das die Art und Weise wie man das tun kann neu ist liegt natürlich in der Natur der Sache, aber es ist machbar.
Für eine kleine Übung in C#, einen RegistryViewer, musste ich auch einige Funktionen importieren.

@Freak:

Bei plattformunabhängigen System, von mir jetzt mal Interpretersysteme genannt, gibt es einige Nachteile bei der Ausführung des Codes. Im Prinzip geht alles über den Interpreter. Wer die VM für den IE installiert hat, weiß wie groß sie ist. Wenn nach dem Compilieren der Java-code in X86-Code vorliegen würde, dann wär die VM in der Basisversion nicht über 4 MB groß. Leider ist es beim Ausführen eines vorcompilierten codes so, dass immer noch ein Programm zwischen Code und Kernel steht. Die Kommunikation zwischen vorkompilierten Code und Kernel sieht dann sehr vereinfacht so aus (man beachte dass ich die Javalibraries mal weggelassen habe, die Kommunikation mit den Libraries die auch interpretiert und erstmal entpackt werden müssen, kostet wohl zusätzlich noch 3 mal soviel Zeit wie folgendes Beispiel zeigt):

Plattformunabhängiger Code:

1. Interpreter öffnet code
2. Interpreter liest Befehl, um eine Datei zu laden (aus Programmcode gelesen)
3. Interpreter sendet den Befehl an den Kernel
4. Kernel lädt die Datei
5. Kernel liefert Speicheradresse an Interpreter
6. Interpreter stellt Adresse dem Programm zur Verfügung

Das ganze mal im direkten plattformabhängigen Code:
1. Kernel öffnet code
2. Kernel liest Befehl, eine Datei zu laden
3. Kernel lädt Datei
4. Kernel stellt Speicheradresse dem Programm zur Verfügung

Das ist nur ein Beispiel (auch wenns vom Aufbau nicht ganz stimmt, der Ansatz zeigt zumindest, wie das auf Kosten der Performance geht)

Ein weiteres Beispiel in dem Microsoft die Kontrolle hat könnte so aussehen:

1. Interpreter öffnet Code
2. Interpreter findet Code um einen Film zu laden, dessen Signatur nicht verifiziert ist
3. Interpreter verweigert weitere Ausführung des Programms
4. Programm wird mit Fehlermeldung beendet

Ob das jetzt Schwarzmalen ist oder nicht. so einfach wäre es dann für MS, die Kontrolle zu behalten.

@Christian Seehase:

Zitat:

was bringt Dich denn auf die Idee, man könne in .NET Programmen keine API Funktionen mehr benutzen?

dazu schrieb weiter oben Sakura folgendes:

Zitat:

Was ist .NET ? Es gibt dazu wohl schon eine Menge Infos. Letztenendes ist es die Ablösung für die Win32 API,...

Ich bin kein .NET Experte und insofern hab ich mal etwas an dem Posting orientiert. Ich bin nämlich IMAO nicht damit einverstanden, dass man mir einfach meine Win32 Api wegnimmt *heul* :mrgreen:

Achja, nochwas: Wieso sollte Microsoft eine PLattform zwischen Win98, NT4, ME, 2000 und XP erstellen, wenn laut Microsoft sowieso nurnoch auf der XP-Schiene bzw. 2000-Schiene gefahren werden soll. Der Aufwand würd sich aus der Sicht nicht lohnen da heute in Firmen fast ausschließlich nurnoch 2000 eingesetzt wird. XP setzt sich nicht so gescheit durch und NT4-Rechner gibt es auch immer weniger.

Moin ShadowCaster,

da das Ganze eigentlich dazu gedacht war plattformunabhängig zu funktionieren (nicht zwischen verschiedenen Windowsversionen ;-) ), war es unumgänglich sich vom direkten Win 32 API Zugriff zu lösen.
Solange MS Betriebssysteme mit Win 16/32/64 API liefert, wird die auch für eigene Programme zugänglich sein, und sei es, wie zumindest in C#, auf Umwegen.
Sollte es mal ein .NET Framework auf einem anderen Betriebssystem geben, so wird man wohl auch dort Möglichkeiten haben auf dort gewohnte Systemfunktionen zuzugreifen.
Ein Windows ohne die übliche API (und sei sie emuliert) kann ich mir allerdings in absehbarer Zeit nicht so recht vorstellen, denn das hiesse für alle Anwender dass sie ihre vorhandenen Software wegwerfen könnten, und das durchzusetzen, dürfte selbst für MS ein nicht so leicht zu bewältigender Brocken sein.
Immerhin laufen ja selbst echte DOS Programme in vielen Fällen noch, und das auch auf nicht DOS basierten Windows Versionen.

Zitat:

Naja. XP setzt sich (wie jedes andere Microsoft-OS inzwischen) seit dem SP 1 schon durch. Bei uns werden Win2k - Clients nur noch in Ausnahmesituationen neu installiert.

Bei NT schaut das anders aus. Es gibt u.A. auch größere Unternehmen, die aus Kostengründen noch NT4 einsetzen. - Bei der aktuellen Marktsituation bei uns und bei der Preispolitik von MS ist sogar davon auszugehen, daß das noch eine ganze Weile so weitergehen wird.

Was die Platformen inkl. 98 und ME angeht.. naja, vielleicht basiert das .NET Framework ja selber nur auf der Win32 - API. ;-)

Zitat:

Es wird ein Zwischencode erstellt, welcher vor dem ersten Aufruf auf einem Rechner kompiliert wird, und so an die lokale Umgebung bestmöglich angepasst wird. Anschliessend liegt das Kompilat im Cache zur sofortigen und schnellen Wiederverwendung vor.

@Shadow : bitte mal die fettgedruckten Stellen beachten. Ich seh das so dass da das Programm kompiliert und dann abgespeichert wird, später wird nur das Kompilat benutzt.

Ich teile ShadowCasters Bedenken vor allem bezüglich Performance.
Ein "Kompilat" im Cache ist spätestens nach dem nächsten Reboot futsch, oder soll es da einen persistenten Cache geben ? Dann wäre aber das Problem mit einer noch konsistenten Systemumgebung gewaltig.

Und die Vorstellung, mein .NET-Programm wird auf dem einen System anders "endgültig" kompiliert als auf dem anderen ("bestmögliche Anpassung an die Umgebung"), finde ich eine ziemlich beunruhigende Vorstellung. Wie soll man da noch Fehler "draußen" nachvollziehen ?

Roderich

Moin Roderich,

Zitat:

Zitat von Roderich

Dann wäre aber das Problem mit einer noch konsistenten Systemumgebung gewaltig.

Warum, wo ist da der Unterschied zu einer "normalen" EXE, wie sie direkt kompiliert auf den Rechner kopiert wird.

Zitat:

Zitat von Roderich

Und die Vorstellung, mein .NET-Programm wird auf dem einen System anders "endgültig" kompiliert als auf dem anderen ("bestmögliche Anpassung an die Umgebung"), finde ich eine ziemlich beunruhigende Vorstellung. Wie soll man da noch Fehler "draußen" nachvollziehen ?

Jain. Heute bist Du darauf angewiesen, dass die von Deinem Programm verwendeten DLLs ein einer entsprechenden Version vorliegen, so Du sie nicht mitlieferst. Letzteres kannst Du bei .NET aber auch.

Soweit ich informiert bin, geben die Programme im Zwischencode an, welche Voraussetzungen (Module) erforderlich sind, damit sie korrekt laufen, und das bis hin zur Version.
Das kannst Du mit bisherigen Mitteln nur erreichen, wenn Du jede benötigte DLL selber auf die korrekte Version prüfst.

Leider hast Du insofern wohl recht, als dass es sich um die Theorie handelt, die ja oft ein ganzes Stück von der Praxis entfernt ist.

Seite 2 von 3