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.
Damit der Topf nicht explodiert, lässt man es ab und zu mal zischen.