GUI für Windows, Linux und sogar noch DOS!

[schöni]

Hallo Daniel,

Darüber kann man verschiedener Meinung sein, aber HXDOS erlaubt die Ausführung von Windows PE Dateien unter DOS. HXDOS brint mit OglTest und anderen App's Beispiele mit. Das Ogltest Programm ist eine Windows Exe mit OpenGL, die aber auch unter DOS läuft.

Ist doch egal, welches Format die Exe am Ende hat, Hauptsache die App läuft unter dem gegebenen Betriebssystem.

Deshalb gefällt mir die hier vorgestellte Lösung sehr gut weil:

- Delphi zur Programmerstellung benutzt werden kann

- daher nicht wegen DOS auf ältere Compiler zurück gegriffen werden muss, die nur eine völlig
andere Syntax erlauben, weshalb dann doppelt entwickelt werden müsste.

- Freepascal ebenfalls verwendet werden kann, da HXDOS auch Windows Exe'n akzeptiert

- und so die Exe 32 Bittig sein kann.

Ich teile daher Deine Auffassung nicht, weil es ja Anwendungsfälle zB. Admin Aufgaben oder wenn schon heute noch DOS auch Steuerungsaufgaben (Prozesssteuerung) geben kann, die eine wie auch immer geartete Visualisierung erfordern. Wenn dann schon für die Steuerung DOS statt ein Echtzeit-Multitasking-OS sein muss, kann die grafische Oberfläche so bereitgestellt werden.

Hab auch in mehreren DOS Foren gefragt "Wozu heute noch DOS?" Die Argumente reichten von der Weiterverwendung der alten DOS Spiele bis hin zur Steuerungsprogrammierung im Echtzeitbetrieb. Aber auch imletzteren Fall muss grafische Oberfläche nicht zwangsläufig negiert werden, es kann ja notwendige Prozessvisualisierungen geben, ich denke da auch an Brauereien (Füllstände von Kesseln überwachen u.a. Wenn ein Echtzeit-Multitaskingsystem da statt DOS verwendet wird, dann braucht es natürlich dort kein DOS mehr, aber das Steuerungsargument ist halt mit aufgeworfen worden.

Aber Ok, wir sind da halt verschiedener Auffassung. Die Zukunft, auch im OpenDOS und FreeDOS Bereich wird zeigen, welche Auffassung die realitätsnähere ist. Die DOBox'en sind, glaub ich, wegen vieler immer noch begehrter alter DOS Spiele entwickelt worden.

Mich aber hat halt, wie im Eröffnungsbeitrag gesagt, gewurmt, das DOS noch immer so präsent ist, aber keine grafischen Oberflächen mehr verfügbar. Nun, die gibt es doch noch, wenn auch mehr im C++ Bereich. Und Windows bis 98SE hatte auch noch einen DOS Unterbau. Das hat sich erst seit Windows NT/2000/XP geändert.

Zu DWPL hab ich mich oben schon geäußert. Ich hätte damals eine echte GUI bevorzugt. Hatte Herr Wache der Autor der DWPL für die "kommende Version" auch angekündigt, aber nie realisiert. Habe damals damit experimentiert. Jetzt gibt es stattdessen das LPTK oder auf SDL basierende GUIs.

Solange die unter HXDOS laufen klappt es, wenn nicht, dann

Könnte sein, das es Out Of Memory Fehler öfter gibt, weil HXDOS den geamten Stack der Anwendung als angeforderten Geamtspeicher reserviert und dann zu wenig für die Anwendung übrig bleibt. Da kann es also frickelig werden. Oder aber wegen der begrenzten Anzahl Windows API Funktionen. Wenn nämlich Funktionen aufgerufen werden, die nicht emuliert werden, war's das. Funktionen, die von der App nicht benutzt werden, können notfalls als Dummies implementiert werden, aber aufgerufene und in der App benötigte Funktionen nicht. Die müssen funktionell implementiert sein.

Dieser Problematik bin ich mir aber bewusst.

Und Graphic Vision von Jason Burgon gibt es auch noch. Vertrieb ist eingestellt aber auf Anfrage bibt Herr Burgon die Quellen und die übersetzten Units heraus. Auch damit kann ja dann eine GUI erstellt werden nur eben dann wirklich nicht mit Delphi. (:


So können wir da sicher noch stundenlang diskutieren. Aber das will ich jetzt gar nicht mehr und schon gar nicht mit verhärteten Fronten wie ich das schon in der Vergangenheit an anderer Stelle tat. Ich denke mal, die Anwendungsfälle sind einfach zu vielfältig, um da alle eine einheitliche Auffassung vertreten zu können. So wie das auch bei der Diskussion, welches denn nun das beste Betriebssystem sei, der Fall ist. Windows oder linux zum Beispiel. Oder ob nun propertiäre Software oder Open Source besser ist. Oder Delphi oder Lazarus,... Auch da gibt es heftige Diskussionen, an denen ich mich ja auch schon recht heftig beteiligt habe.

Alles hat seinen Zweck und der Programmierer muss diejenigen Werkzeuge verwenden, mit denen er seine Aufgabe oder sein im Hobbybereich gesetztes Ziel optimal erreicht. Auswahl an Werzeugen gibt es ja mehr als genug.




.

[Namenloser]

Gab es nicht auch von Microsoft mal so eine Middleware, um auf DOS grafische Programme anzuzeigen? Ich glaube die hieß... Windows?

[JamesTKirk]

Zitat von schöni:

- Freepascal ebenfalls verwendet werden kann, da HXDOS auch Windows Exe'n akzeptiert

Free Pascal unterstützt auch DOS direkt mit Hilfe des go32v2 DOS-Extenders und kann zudem seit etwa einem dreiviertel Jahr auch 16-Bit DOS Anwendungen erzeugen (wobei die Unterstützung hierfür noch in Entwicklung ist, aber immer besser wird).

Gruß,
Sven

[schöni]

@JamesTKirk:

LPTK (L)ight (P)ascal (T)oolkit kann mit Freepascal verwendet werden.
Besteht aus Objectpascal Klassen und lässt sich halt dank X11 Emulation für DOS auch für dieses Betriebssystem übersetzen. Und unter Go32 dann ausführen. Das gleich Programm kann aber mit dem LPTK auch für Windows oder Linux, mit echtem X11, übersetzt werden. Und das LPTK verwendet ObjectPascal Syntax und Klassen.

Besser als jede aus der DOS Welt portierte GUI Bibliothek.

16 Bit Code erzeugbar? zu aufwendig. Im verlinkten Text kann ich das außerdem nicht erkennen

Ist zudem einfacher FPC 1.9.2 runter zu laden, ist noch immer verfügbar, den Compilercode für die BASM Unterstützung zu extrahieren und in den aktuellen Compiler einzupflegen. Dazu noch objconv zur Konvertierung von Borland .obj files in Feepascal .o Files, möglicherweise kann das objconv-tool dies auch noch von 16- nach 32 Bit konvertieren. Jason Burgons Graphic Vision besitzt paar Fontfiles im .obj Format aber zu diesen im Gegensatz zum ausführbare Code keinen Quellcode dabei. Dort macht sich die .obj -> .o Konvertierung erforderlich, dazu noch von 16- auf 32 Bit. oder es finden sich gleichwertige Fontfiles in FPC oder anerweitig. Dieses Problem besteht allerdings bei weitem nicht bei allen Graiklibs für TP.


Das zusammengebracht und gut is. Dann lassen sich eine ganze Reihe guter Grafiklibs aus Turbo Pascal nach FPC portieren. Und diese Portierbarkeit sollte gewährleistet werden, wo sie noch nicht vorhanden ist. FPC 1.9.2 konnte das schon mal mit 16 Bit Assemblercode.

Inzwischen wurde allerdings das LPTK entwickelt.

Es sei denn die Entwickler haben Freude an der Entwicklung eines Compilers für 16 Bit Code.

Ich konnte auch nie verstehen, das es heute zwar für die Auflösung 320x200 so viele, aber für höhere Auflösungen ab 640x480 nur noch so wenige Grafiklibs gibt.

Aber wie auch immer, für GUI Programmierung gibt es das LPTK und seine Derivate nun mal und dazu noch die DOS Emulation der X11. Damit und mit zahlreichen anderen auf SDL basierenden GUI's und HXDOS sollte dieses Themaabgeschlossen sein, Nun kann auch in der DOS Welt grafisch oder in Textmode oder per Kommandozeile programmiert werden, je nach Präferenz des Programmierers. Auch ist die Graph Unit aus FPC von der Geschwindigkeit her für Fensterdarstellung gar nicht so schlecht, auch wenn sie für Spieleprogrammierung ruhig schneller sein könnte. Dank an die Programmierer

HXDOS sollte kompatibel mit DJGPP und so auch mit GO32 sein. So schließt sich der kreis. Nur schade, das mir da keine Softwarebibliothek für diesen Job gelungen ist. Nur bescheidene Anfänge und Versuche.

Ich selber bevorzuge Windows, wollte halt nur appellieren, das, wenn schon noch in DOS programmiert wird, dort auch bitte die GUI Bevorzugenden berücksichtigt werden. Das eine oder andere Tool lädt man sich ja vielleicht doch mal runter, für eine spezielle Situation. Warum dann noch Textmode, wo es doch echt gute GUI Bibliotheken auch für dieses betagte Betriebssystem gibt?

LPTK ist nur eine davon, es gibt noch viele andere, leider die meisten in C++ geschrieben.

So ist es auch auf diesem Sektor am Ende reine Geschmackssache, was zur Programmierung verwendet wird.

Und darüber bin ich wirklich froh. Warum, das sollte aus meinem Beitrag deutlich hervor gehen. Belassen wir es einfach dabei. Streit mit verhärteten Fronten ist überflüssig.

Ein Dank an die beteiligten Programmierer!

@Namenloser: Dieses Ding kenne ich, nutze es sogar selber. Aber LPTK kann halt, wenn für DOS übersetzt, einer einzelnen Anwendung eine GUI Oberfläche geben. Eben auch unter DOS Konsole.

Braucht dann weniger Ressourcen als unter Windows ausgführt.

Unter Linux mit Dosemu könnte dieses Programm dann, ohne den XServer zu benötigen, der ja doch ein paar Sekunden zum Starten braucht, rasend schnell starten und seine Aufgabe ausführen, wobei es sich im modernen grafischen Look präsentiert und schnell arbeitet.

.