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

[schöni]

Hallo,

[OT]
Bin seit langem mal wieder hier. Programmiere selber nur noch selten. Derzeit bin ich mit Web-Anwendungen beschäftigt. Delphi hat da paar interessante Komponenten, die ich gerne mal ausprobieren will. [/OT]

der Grund, warum ich das hier in der DP veröffentliche, ist der, das sowohl Anwendungen des hier zum Download angebotenen LK_GUI
Paketes, als auch die Anwendungen, die auf dem hier ebenfalls zum Download angebotenen auf LPTK (Light Pascal Toolkit) basierenden
Anwendungen auf allen drei im Titel genannten Plattformen lauffähig sind. Zur Sicherheit muss in der DOSBox 100% CPU Speed eingestellt werden. Eventuell muss der Stack der Anwendung auf das absolut notwendige begrenzt werden, damit es unter HXDOS keinen out of memory error gibt.

Gegebenenfalls muss der Parameter memsize in der .conf Datei der DOSBox passend erhöht werden. Ich habe für den Test memsize=53 (Megabyte) gesetzt.

Ich kann einfach nicht verstehen, warum zwar DOS einerseites als total veraltet gilt und deshalb offiziell nicht mehr unterstützt wird,
andererseits aber nach wie vor DOS Freaks existieren, die dieses System nutzen, aber dann möglichst nur auch Kommandozeilenebene oder
maximal mit Textmode GUI, auch TUI (T)extmode (U)ser (I)nterface genannt.

Heutige PC können mehr.

Ich habe mich damals bei Beginn der Entwicklung der fpGUI geärgert, das zwar Linux neben Windows unterstützt wird, aber DOS nicht, obwohl trotz das DOS soooo "veraltet" ist, dieses Betriebssystem nicht nur in Form einer DOSBox als Emulator in Windows,
sondern sogar mit FreeDOS und gleich auch noch OpenDOS wieder neu entwickelt wird. Warum unter diesen Umständen nicht auch grafische Bedienoberflächen für diese Plattform unterstützen?

Dies leistet nun das LPTK. Für DOS gibt es die X11 Bibliothek, die die X11 Umgebung unter DOS emuliert. So braucht man nur diese X11 Bibliotheken, die X11 auf DOS emulieren, gegen die Interface Units zu linken anstelle der gleichnamigen Linux Bibliotheken. Voila!

Die LK_Gui geht einen anderen Weg, nämlich über den Simple-Direct-Media-Layer, SDL. Es esxistiert außerdem das HXDOS Projekt von Japeth. Dieses verwendet das SDL. Dort existiert auch eine Dll mit einem Subset von Windows GDI Funktionen. Leider habe ich noch keine Doku darüber gefunden, um zu sehen, welche Funktionen das sind. Macht aber Sinn, nur ein Subset zu implementieren, denn wenn ich das gesamte Windows API/GDI zur Programmausführung brauche, kann ich das Programm auch gleich unter echtem Windows ausführen.

In C++ gibt es noch zahlreiche andere GUI Bibliotheken, die auch sowohl DOS als auch Windows untestützen, nur für Pascal gibt es da nicht so viel.

Ein interessantes C++ Projekt in dieser Richtung ist Microwindows:
http://www.microwindows.org/

Vor Jahren gab es mal das WDOSX Projekt. Es gab eine Unit AlpGraph, die ebenfalls sdl basierend verwendet werden konnte. Und es gab ein CLX basieredes TUI.

Warum hat der Autor damals auf Textmode bestanden? richtige GUI hätte nicht so viel mehr Entwicklungszeit erfordert. Warum wurde statt TUI nicht ein Windows GDI Wrapper entwickelt? Oder auch eine SDL basierte GUI, wie die LK_Gui. Mit einem Subset genau derjenigen GDI Funktionen, die vom CLX aufgerufen werden? Ein anderer Nachteil des WDOSX-DWPL Projektes war, das einige Delphi Original Units geändert werden mussten, was mir suspekt ist.

Wer weiß, ob Delphi nach den Änderungen noch optimal arbeitet? Außerdem war die Installation der Komponenten des DWPL Projektes schwierig bis unmöglich.


Diese GUIs hier kommen ohne Änderungen der Delphi Original Units aus, was auch im Sinne der GPL günstiger ist.

Habe mich bei DWPL damals gefragt, wo die Softwarefreiheit bleibt, da das DWPL bis Delphi 5 verfügbar war, einige Anpassungen gab es für Delphi 7. Der Autor sagte damals, bei Delphi 7 sei für optimale Installation der Kompos die Professional Version nötig, bei Delphi 6 reiche die Personal Version aus, was mich damals "gewurmt" hat. Weil D6 Personal nicht mehr verfügbar war, nur D7 Personal in der Ct Zeitschrift damals.

Hab später D6 Personal bekommen und muss sagen, auch mit D6 Personal klappt die Installation nicht besser. Auch dort sind nicht alle Quellcodes der VCL dabei.

Schwierig ist außerdem, das zwar die Komponentenpackages GPL sein mögen, jedoch eine propertiäre Version der Programmiersprache vorausgesetzt wird, statt sich mit der kostenlos verfügbaren Personal Version zu begnügen.

Die hier zum Download frei gegenenen GUI's umgehen all diese Probleme. Delphi-Original Units müssen nicht verändert werden, weshalb die Personal Versionen zum Übersetzen ausreichen dürften.

Dank SDL und für DOS verfügbarer XLib ist der verwendete DOS Extender auch gleichgültig. So können nun auch für DOS GUI Anwendungen erstellt werden. Das kann mit dem gewohnten Komfort der Delphi IDE geschehen, da der Code des LPTK zumindest in Object Pascal realisiert ist.

Die LK_GUI verwendet allerdings Objekte, so hier:

LK_GUI:

Delphi-Quellcode:

type
  MyWidget = Object(TAnchestor)
  end;

LPTK

Delphi-Quellcode:

type
  TMyWidget = class(TMyAnchestor)
  end;

Solange Delphi das Schlüsselwort Object wie im oberen Beispiel nach wie vor unterstützt, sollte es da keine Probleme geben, Freepascal unterstützt das noch, soweit mir bekannt ist.

Anderenfalls ist eine niedrigere Compilerversion erforderlich, die diesen Objekttyp noch unterstützt.


Außerdem hat Jason Burgon, der Entwickler der Graphic Vision für Turbo Pascal seinen Vertrieb eingestellt. Seine Webseite existiert noch, aber wer auf Order klickt, wird enttäuscht. Das Produkt ist auf diesem Weg nicht mehr verfügbar.

Jedoch kann jeder Herrn Jason Burgon per Mail kontaktieren und erhält bei Interesse das Paket kostenlos. Eine Donation als Dankeschön ist natürlich nach wie vor willkommen. Werde vielleicht mein IDE Projekt auf diese Ebene verlagern und mit diesem Paket ein IDE bauen, vielleicht auch noch ein Admin Tool, das bei zerstörtem Windows zur Datensicherung in Aktion treten kann und dies dann Herrn Burgon als Dankeschön zukommen lassen.

Er plant die Portierung des Paketes nach Freepascal, aber auch nur noch für die Windows Plattform.

Das Programme, die mit diesem Paket erstellt werden, mit der 64 Bit CPU nicht mehr funktionieren, dieses Argument lasse ich nicht gelten, da es erstens die DOSBox gibt, die auch 16 Bit Code nach wie vor ausführen kann und es außerdem FreeDOS und noch dazu OpenDOS gibt, die in der Lage sein sollten, 16 Bit Code auszuführen, da noch jede Menge alte PC Spiele existieren, die wohl die Motivation gegeben haben, DOS so lange noch weiter zu pflegen und mit FreeDOS und OpenDOS sogar wieder neu zu entwickeln.

Auf diesen Plattformen sollte dann eh auch 16 Bit Code laufen, in der DOSbox allemal.

Was das LPTK betrifft, möglicherweise wird dort die OpenSource DOSBox 0.7x eh benötigt oder reines Freedos oder Opendos. So dürfte es sich aber dann auch mit eventuellem 16 Bit Code aus Turbo Pascal verhalten, sobald eine 64 Bit CPU im Spiel ist. In diesem Fall geht dann halt nur noch die DOSBox oder eines der Freedos Distributionen.

Es gibt außerdem Microwindows, allerdings in C++ realisiert. Damit wurde eine echt ansprechende DOS GUI Oberfläche entwickelt. Zudem gibt es Geos für DOS und noch einige andere echt gute Oberflächen, die dann wie das bekannte Windows bedient werden.

Neben NanoX liefert Microwindows ein Subset von Windows GDI Funktionen, die auf DOS emuliert werden. Sind allerdings recht viele. Das LPTK und die LK_GUI sind in Pascal geschrieben und leisten die DOS Unterstützung bereits und laufen genau so auch unter Windows und X11 (KDE).

So muss ich den Windows GDI Wrapper nicht mehr realisieren.

Und mit LK_GUI oder dem LPTK kann nun auch Software für alle diese Plattformen entwickelt werden, nun auch in modernem Pascal.

Ich habe mich schon so manches Mal gefragt, warum unter DOS heute nur noch Kommandozeilenprogramme oder maximal TUI Programme entwickelt oder verteilt werden. Schon zu DOS Zeiten hat es wirklich gute Grafikbibliotheken gegeben, von denen aber viele nicht mehr im Netz zu finden sind, während die alten Textmode Programme nach wie vor zu finden sind.

Klar liefert Windows heute wasentlich mehr Möglichkeiten, als man sich zu DOS Zeiten erträumen konnte. Wenn aber dann DOS nach wie vor gepflegt und mit FreeDOS/OpenDOS sogar wieder entwickelt wird, dann hat auch die GUI Programmierung für diese Plattform wieder ihre Berechtigung.

Hir einige Links:

Japheth Hxdos-Seite:
http://www.japheth.de/HX.html

Ein Internet-Forum:
http://www.essential-freebies.de/boa...ic.php?t=14071

LPTK-Webseite:
http://lptk.sourceforge.net/

LK_Gui:
http://sourceforge.net/projects/lkgui/

Wollte meine Dateien hier hochladen. Die Lptk.zip ist 4,4 MByte groß und wird dennoch nicht angenommen, der Upload startet nicht, obwohl laut DP Auskunft im Popup Fenster bis 5 MByte erlaubt sind. Mit der LK_Gui versuche ich es deshalb gar nicht erst.

Aber ich kann ja die DOS Emulationsbibliotheken hier hochladen, dann könnt auch Ihr neben Windows und Linux auch DOS in der GUI Programmierung berücksichtigen. Wie das so manche C/C++ Bibliothek schon lange macht.



Ich habe mir das Paket privat herunter geladen, es ist also im Notfall auch bei mir erhältlich. Ebenso verhält es sich mit dem LK_Gui Paket.

In meinem privaten LPTK Paket befinden sich auch die zugehörigen .a und .dll Dateien der XLib Emulation für DOS. Das Original von der Webseite läßt sich so nur für echtes X11 und Windows übersetzen.

Hxdos erlaubt die Ausführung von Windows Programmen unter DOS, so lange, wie nur solche Windows API/GDI Funktionen von der App aufgerufen werden, die von Hxdos entweder per SDL oder durch die Hxdos-eigenen Windows-API-Dll's in Dos emuliert werden.

Hab mich auch geärgert über den Umstand, das alte Turbo Pascal GUI Programme mit Freepascal bis Version 1.9.2 auch mit Assemblercode noch übersetzbar waren und danach auch funktioniert hatten, bei späteren Freepascal Versionen klappte das nicht mehr, da wurde die Assembler Syntax massiv verändert. Mit den hier vorgestellten GUIs, die zudem moderner sind und im Fall LPTK sogar mit Object Pascal realisiert sind, ist dieses Problem nun endlich aus der Welt geschafft.

Ich veröffentliche das deshalb nicht nur hier, da die Libs mit Object Pascal und so auch mit Delphi verwendbar sind, sondern ich veröffentliche das auch in den mir bekannten DOS Foren.

[Daniel]

Delphi scheint mir dafür ein wenig geeignetes Werkzeug zu sein. Der Compiler erstellt 32bit-Windowsprogramme. Meinetwegen auch 64bit - aber eben Windows-Programme. Nun kann man diese ein wenig zurechtstutzen, damit daraus eine Konsolen-Anwendung wird - aber eben weiterhin eine echte Windows-Anwendung. Dieser Konsole nun wieder eine GUI aufzupfropfen halte ich für absurd, denn am Ende hat man eine Windows-Anwendung, die wie eine ... "andere" ... Anwendung aussieht.

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

.