fpGUI auch für Go32???

[creed steiger]

zwei kleine Fehler in deinem Beschreibungstext:

is a wigetset, based on fpGUI from Graeme Geldenhuy

es wäre widgetset und er heißt Graeme Geldenhuys

[pluto]

Wen Lazarus nicht auf HXDOS läuft,
dann würden andere Windows-Anwendungen auch nicht mit HXDOS laufen ?

Nun, Lazarus nutzt Intern auch nur den FPC. Dan kann man auch ohne Lazarus nutzen.
So mache ich das immer auf dem Banana PI. Ich Entwickel aber die Software mit Lazarus auf Linux Mind und kopiere sie dann rüber und kompiliere sie dort direkt mit FPC.

[Michl]

Läuft Lazarus mit dem fpgui widgetset. Imho nicht.

Man kann aber das Interface nutzen und mittels der Lazarus IDE eine fpgui-Anwendung erstellen. Das hat den Vorteil, dass man die Lazarus IDE mit ihren sehr hilfreichen Codetools etc. verwenden kann. Habe es längere Zeit nicht mehr probiert, dazumal ging es aber ohne Probleme. Siehe z.B.: http://wiki.freepascal.org/fpGUI#Compil ... m_Lazarus:

[fpGUIcoder]

Irgendwie blicke ich nicht durch.

Wie du schreibst ist HXDOS ein minimales Windows.
Somit müsste doch Lazarus darauf laufen, oder verstehe ich da etwas falsch ?

Eher eine Emulation der Windows API Funktionen und zwar nur einem Teil derselben. Deshalb wird Lazarus nicht darauf laufen, Lazarus basiert auf der Qt-library.

Und die ruft noch andere Windows API Funktionen auf, die von HXDOS nicht emuliert werden.

Wenn ich mir da aber den Quellcode innerhalb Lazarus, da spezeiell der im qtintf verwendeten Windows API Funktionen anschaue, könnte es machbart sein, Lazarus im DOS startfähig zu machen. Habe aber dazu noch keine exakte Analyse der in HXDOS voehandenen und auch implementierten Funktionen und derjenigen, die in qtintf aufgeführt sind, vorgenommen. Einige API Funktionen in HXDOS sind zwar vorhanden aber nur als Dummies. Einige davon könnte man vielleicht leicht nachbauen oder unter Verwendung bereits implementierter API Funktionen nachbauen. Dies habe ich zum Beispiel mit der GDI Funktion FillRect gemacht, die mit HXDOS gar nicht emuliert wird:

Code: Alles auswählen

 
function FillRect(dc: HDC; const Rect: TRect; Brush: HBRUSH): Longint;
begin
  //Rectangle(dc, Rect.Left, Rect.Top, Rect.Right, Rect.Bottom);
  //FillRect := Longint(FloodFill(dc, (Rect.Left + Rect.Right) div 2, (Rect.Top + Rect.Bottom) div 2, GetDCBrushColor(dc)));
  FillRect := Longint(FillRgn(dc, CreateRectRgn(Rect.Left, Rect.Top, Rect.Right, Rect.Bottom), Brush));
end;
 

Nach diesem Muster könnte man weitere fehlende Funktionen vielleicht noch nachbauen, indem an implementierte Funktionen geschickt kombiniert, wie FillRect hier an einem einfachen Beispeil zeigt.

Einen Veruch wäre es auf jeden Fall Wert. Ich habe schon aus qtintf zwei Inklude Daeien qtwinapih.inc und qtwinapii.inc gebaut und dazu eine Unit qtwinapi.pas geschrieben, die im Interface Teil die qtwinapih.inc und im Implementationsteil die qtwinapii.inc einbindet und dazu noch im Interfaceteil die Windows Typdefinitionen und Konstanten. Wenn ich damit alle Funktionen des WinAPI entweder von HXDOS emuliert bekomme oder die fehlenden durch geschickte Kombination vorhandener nachbilden kann, wie in FillRect gewschehen, dann könnte es klappen mit dem Lazaras Start in DOS. Wenigstens mit jenen Widgetsets die auf QT berugen. Beim GTK bin ich da nicht so sicher. FCL und LCL basieren meiner Kenntnis nach auf Qt.

Wenn Lazarus wirklich nur diejenigen Windows API Funktionen verwenden würde, die in QTintf zu sehen sind???? Allerdings gibt es ja noch die Unit Windows. Und die ShellAPI un d Active X, das alles emuliert hXDOS nicht. Damit könnte Lazarus dann mit HXDOS laufen, wenn alle von Qt verwendeten WinAPI Funktionen emulieren würde. Das heißt, wenn die Threadlogik am besten vollständig durch Qt-eigene Funktionen bereitgestellt wird. Wenn Lazarus läuft, läft parallel der GDB Debugger. Wenn ich übersetzen will, muss der Compilerthread mindestens temporär laufen. Wenn aber unter Windows da ein Thread läugt, der nur auf Halt steht, wenn ich den Quellcode editiere laufen mit Lazarus mindestens 3 Threads, der für Lazarus selber, der für den Compiler, wenn er auf Halt steht, so ich gerade nicht übersetze und der Debugger.

Ich fände es gut, wenn es unter DOS deshalb eine wenigstens rudimentäre Multitasking Unterstützung gäbe, THreads halt auch in DOS unterstützt, wobei es in DOS ausreicht, maximal 4 Threads zu unterstützen. Wenn dann Lazarus komplett auf Qt aufsetzt, und auch die Threds so funktionieren würden, könnte auch unter DOS der Debugger parallel mitlaufen. Das frickelige Freigeben von genug Speicher, damit der externe Prozess auch laufen kann, würde entfallen.

AUßerdem gibt es die Unit ptcGraph, die nur wegen der in DOS nicht funktionierenden Threads nicht für Go32 verwendet werden kann, laut Kommentaren in der ptcGraph Unit.

Das ist aber erst dran, wenn die fpGUI richtig getestet ist und wirklich alles funktioniert. Derzeit teste ich sukzessive alle mit der fpGUI mitgelieferten Demos.

[fpGUIcoder]

zwei kleine Fehler in deinem Beschreibungstext:

is a wigetset, based on fpGUI from Graeme Geldenhuy

es wäre widgetset und er heißt Graeme Geldenhuys

Danke für den Hinweis

[m.fuchs]

[...]Wie du schreibst ist HXDOS ein minimales Windows.
Somit müsste doch Lazarus darauf laufen, oder verstehe ich da etwas falsch ?

Eher eine Emulation der Windows API Funktionen und zwar nur einem Teil derselben. Deshalb wird Lazarus nicht darauf laufen, Lazarus basiert auf der Qt-library.

What? Wie kommst du da drauf?

[fpGUIcoder]

Wen Lazarus nicht auf HXDOS läuft,
dann würden andere Windows-Anwendungen auch nicht mit HXDOS laufen ?

Das hängt von denjenigen Windows API Funktionen ab, die einerseits von der Anwendung aufgerufen und andererseits von HXDOS auch implementiert werden, nicht nur als Dummies sondern wirklich implementiert.

Bei der FpGUI sind das schon mal fast alle. Muss die Radiobuttons explizit testen, das Ellipse definitiv in HXDOD nur Dummie ist, aber im Paket Anti Grain Gemetry im Ordner /src/render/software der fpGUI funktionsfähig implementiert ist. Alle API AUfrufe, die vom Anti Grain Geometry Paket verwendet werden, sind in HXDOS funktionsfähig implementiert. Dieses Paket sollte damit unter DOS laufen. Damit ließen sich dann noch fehlende Grafikfunktionen nachrüsten. Linie und Rechteck füllen und Pixel setzen ist definitiv in HXDOS als nachgebildete WIN API Funktion emuliert.

Was die obige Frage betrifft, auch wenn es mir gelingen sollte, alle in der Unit qtintf.pp aufgeführten Windows API Funktionen mit HXDOS zu implementieren, was ich mit Linklib <apilib> und hinter den Funktionen durch stdcall; external tun würde, dann ist noch nicht sicher, das dann mit DOS Lazarus Windows Anwendungen erstellt werden können, da ich einschätze, das die Qt library auch nur ein Subset an Windows API Funktionen verwendet und so viel wie möglich mit eigenem Code nachbildet. Dann aber fehlen für die Windows Programmierung wichtige Api Funktionen.

Allerdings sollte es möglich sein, die Windoes Units in den Compiliervorgang einzuschließen, um das Programm unter DOS für Windows zu übersetzen, nur Testen geht dann nicht. Getestet werden muss dann unter echtem Windows. DOS Programme sollten aber dann kein Problem sein.

[fpGUIcoder]

[...]Wie du schreibst ist HXDOS ein minimales Windows.
Somit müsste doch Lazarus darauf laufen, oder verstehe ich da etwas falsch ?

Eher eine Emulation der Windows API Funktionen und zwar nur einem Teil derselben. Deshalb wird Lazarus nicht darauf laufen, Lazarus basiert auf der Qt-library.

What? Wie kommst du da drauf?

Auf was?



.

[af0815]

BTW fpGUIcoder: Hast du schon mit Graeme Kontakt aufgenommen ?

[m.fuchs]

[...]Lazarus basiert auf der Qt-library.

What? Wie kommst du da drauf?

Auf was?

Dass Lazarus auf Qt basiert. Da betrifft ja nur die Qt-Version. Die Windowsvariante nutzt natürlich die WinAPI.

[marcov]

zwei kleine Fehler in deinem Beschreibungstext:

is a wigetset, based on fpGUI from Graeme Geldenhuy

es wäre widgetset und er heißt Graeme Geldenhuys

Und es war nicht Graeme Geldenhuys http://forum.lazarus.freepascal.org/ind ... #msg155409

[fpGUIcoder]

zwei kleine Fehler in deinem Beschreibungstext:

is a wigetset, based on fpGUI from Graeme Geldenhuy

es wäre widgetset und er heißt Graeme Geldenhuys

Und es war nicht Graeme Geldenhuys http://forum.lazarus.freepascal.org/ind ... #msg155409

Richtig, der hat die fpGUI entwickelt, das heist den Anfang von Sebastian Günther übernommen und weiter entwickelt. Aber nur für Windows, Linux und Mac (carbon). Aber nicht für DOS.

Ich habe nun im Internet HXDOS entdeckt und fpGUI Anwendungen damit zu starten versucht mit dpmild32 <prgname> in der DOSBox, der OpenSource Version DOSBox 0.72.

Ich habe nur einen Einzigen Missing Import gehabt, die Funktion SetArcDirection()

Wenn da mal nicht die Chance besteht, die fpGUI in DOS nutzbar zu machen.

Da bringen andere Windows Programme wesentlich mehr missing imports.

Später habe ich mich mir die Quellen von HXDOS beschafft und unter den Downloads befand sich nicht nur der Quellcode und die Dlls, sondern auch statische Bibliotheken gleichen Inhaltes. Mit denen will ich nun eine Go32 Version der fpGUI bauen. Warum? Weil dann das dpmild32 entfallen könnte, um das Programm zu starten, es ist dann schon für Go32 übersetzt. Und ich sollte mit ausschließlich denjenigen API Funktionen auskommen, die die fpGUI auch aufruft. Dateifunktionen hingegen gibt es in gleicher Form auch in Go32.

Parallel dazu werde ich natürlich auch an der fpGUI für Windows arbeiten und dort wegen des einen missing importes von SetArcDirection die Arc Funktion aus dem Anti Grain Geometry Package verwenden, damit SetArcDirection nicht mehr aufgerufen wird. Diese wird nur an 4 Stellen in der unit fpg_gdi verwendet, sonst nirgends. AUch die Entfernung der API Fuunktionen in der unit ActiveX, die von der Unit fpg_gdi.pas eingebunden wird, hat beim Übersetzen keine Fehler "Fehlende Funktion xxxx gebracht. So kann ich wohl davon ausgehen, das von der fpg_gdi und auch von fpg_OLEDragdrop ausschließlich die Interfaces benutzt werden. auch die UNit fpg_OLEDragDrop.pas verwendet die ActiveX Unit. Aber auch dort wohl nur die Interfaces.

Die Funktion Arc() und die Funktion Pie() die auch in der fpg_gdi aufgerufen wird, in Verbindung mit SetArcDirection(), sind in HXDOS Dummies, alle anderen aufgerufenen Funktionen sind echt implementiert. So sollte eine Neuimplementierung mit Hilfe von Funktionen des Anti Grain Geometry Packages, das zum Lieferumfang der fpGUI gehört und in /corelib/render/software zu finden ist, genügen. Das Anti Grain Geometry Package verwendet ausschließlich Windows API Funktionen die in HXDOS auch funktionsfähig implementiert sind, keine Dummies.

Um auf die Eingangsfrage zurück zu kommen, der aktuelle Entwickler der fpGUI ist Graeme Geldenhuys. Ich baue den Code jetzt nur so um, das er auch in Dos läuft. HXDOS und das zur fpGUI gehörende Anti Grain Geometry Package, eine Pascal Portierung von hier: http://www.antigrain.com sollten hier meine Freunde sein.

[fpGUIcoder]

Irgendwie blicke ich nicht durch.

Wie du schreibst HXDOS ein minimales Windows.
Somit müsste doch Lazarus darauf laufen, oder verstehe ich da etwas falsch ?

Läuft Lazarus mit dem fpgui widgetset. Imho nicht.

Werde mir in der nächsten Zeit mal das qtInterface und da besonders die qtwinapi vornehmen. Nur wenn dort wirklich alle WInAPI Funktionen zu finden sind, die von Qt verwendet werden und noch dazu Qt eine eigene Threadlogik, vom Windows API unabhängig, implementiert und HXDOS alle diese von Qt aufgerugenen Windows API Funktionen auch implementiert, nur dann besteht überhaupt eine Chance, Lazarus unter DOS lauffähig zu machen.

Wenn zwar von HXDOS alle von Qt aufgerufenen Windows API Funktionen imlementiert aber da auch Threadfunktionen dabei sind, wird es nicht funktionieren, da unter HXDOS die meisten Threadfunktionen nur Dummies sind.

Braucht allerdings ca. 80MByte RAM. Habe soeben mal Lazarus gestartet und mir im Taskmanager die RAM Auslastung aller Teile (StartLazarus.exe, Lazarus.exe, gdb.exe, LazarusPortable.exe angeschaut und die einzelnen RAM Anforderungen addiert.

Ob das sinnvoll ist, ist eine andere Frage, denn die fpGUI bringt ein, zwar noch experimentelle IDE namens Maximus mit, die allerdings noch ausgebaut werden muss, die braucht wesentlich weniger RAM. Und ein VFDDesigner ist auch dabei, bestehend aus Objektinspektor, Haupfenster mit Komponentenpalette und FormDesigner. Noch kein Texteditor. Aber dieser Designer erzeugt eine Pascal Datei mit Laufzeit Quelltext. Der ließe sin in die Maximus IDE einbauen, dann wäre der Texteditor vorhanden.


.