Was kommt nach Alpha? - Beta!

  • stefank schreibt: "Mir fehlt es hier an der Basis: ich kenne nicht die Verästelungen der einzelnen GEOS-Varianten bzw. was Ihr für Pläne habt: was ist das Split-Setup-Konzept?"

    Und das ist eine gute Frage. Denn eigentlich war es nie unser Ziel, "Verästelungen und GEOS-Varianten" zu produzieren, sondern nur ein offzielles PC/GEOS Ensemble.

    2018 hat frehwagen den PC/GEOS Quellcode auf GitHub als Open Source bereitgestellt, nachdem schon sehr viel Arbeit in die Portierung auf den Watcom Compiler geflossen war. In den folgenden Jahren haben wir alle intensiv daran gearbeitet, das System zu modernisieren. Es wurden uralte Bugs gefixed, die App-Auswahl festgelegt und alle Apps und Spiele bereinigt und modernisiert, neue kleine Features hinzugefügt, der Übersetzungsprozess wiederhergestellt, alle Übersetzungen eingepflegt und überprüft, Hilfen neu geschrieben, übersetzt, die Basebox (eine DosBox-staging Variante) für GEOS optimiert, um zukünftig GEOS auf möglichst vielen Platformen optimal ausführen zu können und sogar eine komplett neue Font-Engine geschrieben, mit der man nun TTF Fonts nutzen kann - Wahnsinn!

    Allein, was es bis heute, 8 Jahre nach der Freigabe als open-source, nach wie vor nicht gibt, ist ein sauberes, offizielles Release. Ein Paket, das man herunterladen und jemandem in die Hand drücken und sagen kann, "hier, das ist es, kannst ja mal gucken". Oder das man sich auf seinem modernen Rechner herunterlädt, installiert und zum Arbeiten nutzt. Und das man gegebenenfalls einfach updatet, falls es eine neue Version gibt. Das war aber immer das Ziel für die initiale Version 6.

    Dass die Sehnsucht nach einem solchen offiziellen Paket in der Community groß ist, kann man nach den vielen Jahren des Stillstandes (in denen man immer noch irgendwo auf ein neues GEOS von Breadbox gewartet hat) und all der Arbeit von uns verbliebenen Supportern natürlich verstehen.

    Einer der Gründe warum wir noch kein solches Release haben, ist, dass frehwagen als Maintainer eine sehr konkrete und professionelle Vorstellung davon hat, was so ein Release können muss: Das System sollte möglichst ohne platformspezifische Skripte oder Installer installierbar sein. Die Basebox war immer mit als Teil des Systems zu denken. GEOS sollte updatefähig werden, ohne dass man seine Dokumente, Apps und Einstellungen verliert. Das sind keine kleinen Anforderungen und wir hatten für manche Herausforderung einfach lange keine Antwort.

    Anfang des Jahres ist mir irgendwie klar geworden, dass es nicht mehr Top-Priorität hat, weiterhin kleine Bugs zu fixen oder Features hinzuzufügen. Ich wollte, dass wir endlich wieder etwas installieren und zum "Arbeiten" nutzen können. Also hab ich frehwagen vorgeschlagen, dass wir uns jetzt auf dieses Thema fokussieren.

    mgroeber hatte schon mal ein paar Veränderungen vorgeschlagen, um GEOS leichter updatefähig zu machen, das sogenannte split-setup, welches in ähnlicher Form beim GlobalPC zum Einsatz kam. Dieses hatte alledings noch einige ungelöste bzw. mit Falks Anforderungen unvereinbare Herausforderungen, um die wir uns in der Folge gekümmert haben.

    Ohne zu sehr ins technische Detail zu gehen, kann ich sagen, dass das Ergebnis konzeptionell jetzt verblüffend modern ist: Der Kern von GEOS und die mitgelieferten Anwendungen laufen zukünftig in einem unveränderlichen Image (ähnlich wie bei immutable Linux-Distros wie Fedora Silverblue) und sämtliche eigenen Anwendungen und Dokumente liegen in einer Schicht darüber. Bei einem Update wird ein neues Image heruntergeladen und GEOS auf dieses Image umgestellt. Die eingebauten Anwendungen und Libraries sind dann automatisch alle wieder aktuell. Alle eigenen Dateien, Programme und INI-Einstellungen bleiben erhalten. Das ist zumindest das Konzept ;)

    Das Ganze ist ein ziemlicher Rundumschlag und erfordert viele kleine Änderungen an vielen Stellen im System. Wir sind damit vielleicht zu 75 Prozent durch und werden hoffentlich in den nächsten Tagen oder Wochen "eine Alpha-Version" dieses Releases anbieten können (das ist dann ein vollständiges Paket aus GEOS und Basebox, nicht nur ein GEOS Zweig!). Dieses Bundle wird aufgrund der vielen Änderungen wieder viele Tests benötigen und am Ende sicher auch noch hässliche Bugs haben - aber wenn nicht der Himmel einstürzt oder wir noch grundsätzliche konzeptionelle Schwächen entdecken, wird es zum diesjährigen Treffen endlich ein Beta-Release von "PC/GEOS Ensemble 6" geben.

    Bye,
    MeyerK

    Edited 2 times, last by MeyerK (May 7, 2026 at 3:34 PM).

  • Ich bin gespannt.

    Wie ich das lese, wird es aber immer "Hostbasiert" bleiben.

    Ich hätte da einen Wunsch wegen der Aktualisierung der Fenster.

    Beispielhaft hier...

    In dem hier geposteten Video (weiter hinten) zeige ich wie in eine Datei drucke und aus dieser ein PDF erstelle (am Host). Das vom Hostrechner kopiere ich zurück nach Geos.

    Leider habe ich keinen Weg gefunden, dass ich diese Datei in der aktuellen Sitzung sehen kann. Das Dateifenster wird nicht aktualisiert.

    Nach einem Neustart ist die kopierte Datei vohanden...

    Ich habe nicht probiert, was mit Geos bezogenen download passiert, die ich vom Hostsystem nach Geos schiebe z.B. in die Dokumente aber ich denke, dass wird auch so sein, weil von Diskette, bei laufender Sitzung von aussen einkopierte Dokumente, auch erstmal nicht zu sehen sind.

    Oder habe ich was übersehen? Auch gut möglich.

    Viel Erfolg,

    Raik

  • Hallo,

    also die Vision für Version 6 war immer hostbasiert (denn den Host wegzulassen ist einfacher, als ihn hinterher anzuflanschen.) Aber Version 6.1 soll sich verstärkt auf reines DOS, Protected Mode Entwicklung und alternative Nutzungsszenarien konzentrieren.

    Bye,
    MeyerK

  • Eine bessere Synchronisation der Dateien zwischen Host und GEOS ist auch sowas, was durch die Basesbox möglich wird. Allerdings weiß ich, dass Rainer auch relativ hemmungslos zwischen laufender DosBox und GEOS hin- und herkopiert - es gibt doch da Tastenkombinationen um die DosBox zum Neu-Einlesen von Verzeichnissen zu zwingen ....?

    Bye,
    MeyerK

  • Vorher mit (sorry aus den Gedächtnis getippt, weil noch unterwegs, könnte auch was Anderes mit F4 sein. )

    STRG +F4 die baseox zum neu einlesen bringen.

    Dann in Geos F5

    So etwas Ähnliches liegt mir auch an, nur F5 in Geos reicht nicht.

    Ansonsten bin ich gespannt wie ein Flitzebogen nach Konstantins Ankündigungen. ^^

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

  • Hallo Zusammen,
    das ist eine Erweiterung die für die Basebox kommen soll:

    "STRG +F4 die baseox zum neu einlesen bringen. Dann in Geos F5" kann entfallen.

    Bis dahin ist das der erforderliche Weg.

    Viele Grüße,
    Falk \\ blueway.Softworks

  • Als Basis von GEOS haben wir nun DOS Emulatoren, und alle ganz verschieden. DosBox, DosBox-X, FastDosBox, DosEmu, BaseBox usw. usf. Wie die Probleme von Raik zeigen (und meine eigenen Versuche unter Linux oder RISC OS), muss man erst einmal die DosBox-Conf's studieren und die haben mit den guten, alten DOS Versionen nichts zu tun, wie mir scheint. (Wobei Raik natürlich Ahnung hat, ich nicht. Ich fange an mit c:\keyb gr und muss dann erkennen, dass man mit ganz anderen Parametern in irgend einer dosbox.conf herummachen muss, um eine deutsche Sprachumgebung hinzubekommen, von allem anderen zu schweigen.)

    On top of that kommt dann die GEOS-Entwicklung. Hm, naja, das erinnert mich fatal an RISC OS. Wir werden alle nicht jünger (ich sogar älter, im Juli möglicherweise 68), und wenn nichts Jüngeres nachkommt, wird das ein Rennen gegen die Zeit. Sprich: der Letzte klebt "Release Version 1.0!" auf's virtuelle Packerl.

  • Ich habe gerade noch mal nachgeschaut:

    blueway.Softworks
    Man muss einen Account machen, dann kann man auch ein paar Sachen unter "Downloads" sehen.
    Dann gibt es dies unter github:

    bluewaysw - Overview
    bluewaysw has 11 repositories available. Follow their code on GitHub.
    github.com

    DIY:

    GitHub - bluewaysw/pcgeos: #FreeGEOS source codes. The offical home of the PC/GEOS operating system technology. For personal computing fans. For all developers and assembly lovers. For YOU!
    #FreeGEOS source codes. The offical home of the PC/GEOS operating system technology. For personal computing fans. For all developers and assembly lovers. For…
    github.com

    und hier kann man die "blueway softworks CI-latest" herunterladen (wobei CI für Community Idition steht?)

    Release CI-latest · bluewaysw/pcgeos
    This release holds the latest successful built artifacts from the master branch.
    github.com

    Die Blueway Softworks GEOS sind die (bayerisch "Erlkönig") FreeGEOS Aspiranten? Oder FrehGEOS? Mr. Spock: IDIC

  • das ist eine Erweiterung die für die Basebox kommen soll:

    ganz trivial ist das aber nicht. Ich habe das selbst auch schon probiert und folgende (potentielle) Probleme ausgemacht:

    - die unterschiedlichen Plattformen (z.B. Windows, Linux) verwenden recht unterschiedlich Mechanismen Änderungen im zu überwachenden Dateisystmzweigen zu "alerten"

    - Polling hatte sehr negative Einflüsse auf die Performance

    Die Basebox war immer mit als Teil des Systems zu denken

    ...muß dann aber auch konsequent gepflegt werden. Aktuell häng sie >3800 Commits hinter DosBox-Staging hinterher, was vmtl. manuelles Rückportieren von Code/Mergen erfordert. Die CI/CD-Skripte sind für veraltete OS gedacht und teilw. (macOS) auch nicht lauffähig, weil die zu Grunde liegenden Runner EoL sind.

    das sogenannte split-setup

    stammt ursprünglich aus der Netzwerkinstallation, die bewust größere Veränderungen durch den Nutzer unterbunden hat. Geos-Nutzer fummeln jedoch mit Begeisterung an ihrem Systemen herum, um es ihrem ganz persönlichen Geschmack anzupassen: die Struckturierung der Applikationen im GeoManager steht da sicher ganz oben auf der Liste. Das kann man bestimmt durch Ablage der Apps im SYSTEM-Bereich und Verlinkung in (User)WORLD lösen, aber auch dann muß ich saber zwischen Erst- und Update-Installation unterscheiden. In menen Experimenten hat sich auch gezeigt, dass nicht aller Einstellungen in NET.INI und GEOS.INI gleichermßenanwendbar sind - Skepsis....

    Gruß Thomas

  • Hallo Thomas,

    Das Polling keine Option beim File-System-Update ist, ist klar, deswegen ist die Integration des GEOS-API jetzt auch voll asynchron. Das es kein Leichtes Thema ist, ist auch klar, aber auch die bisherigen Anpassung waren auch eher nicht trivial aus Sicht der Integration. Versucht auf SDL zu bleiben hat natürlich die Systeme abstrahiert.

    Die Integration des GEOS-Änderungen von BASEBOX in die DOSBox-Staging sind bisher minimal (extra so nochmal gemacht), auch aus der Erfarhrung heraus, dass es sonst aussichtslos ist, zu Updaten. Ein Rebase sollte gut machbar sein. Ich hab eher Not neue Updates der DosBOX-Staging zu identifitieren, weil ein neues Release der DOSbox-STaging gibt es eher nicht?

    Das Split-Setup kommt auch von den Mobil-Geräten die das System im ROM gehalten haben. GPC hat es auch aufgegriffen.

    Das Thema App-Layout wurde im neuen Split-Setup adressiert., sollte nicht das Problem werden. Lösung über Links GEOS-seitigen Init/Migration-Ablauf. Es ist eben möglich ein Update zu machen und das App-Layout bleibt erhalten.

    Ja, ungünstige INI-Definition können dennoch problemtisch sein, das können wir ja ggf. fixen, es betrifft ja die System-Einstellung die Im FreeGEOS von uns auch modelliert werden.

    Viele Grüße,

    Falk \\ blueway.Soffworks

  • Dumme Frage aus dem OFF: Wenn F5 die Standard-Taste zum Neuaufbau von Fenstern ist, warum dann nicht im GeoManager F5 benutzen um erst die Dateien neu einzulesen und dann erst das Fenster neu darzustellen? Dann muss ich niemand Strg-F4 als weiter Kombination merken. :/
    Also Konzeptionell: Datei nicht da obwohl ich sie vom Host gerade eingespielt habe? -> F5 -> Ah, da ist sie ja!

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

  • Mmm, [FN]+F5 (F5 mach den Bildschirm am Laptop dunkler) baut bei mir das DosBox-X Fenster neu auf aber ohne die Dateiliste zu aktualisieren und STRG+F4 wechselt eine Verzeichnisebene nach oben ...

    DosBox ohne X aktualisiert die Dateiliste mi r [FN]+F5 und STRG+F4 wechselt nicht eine Verzeichnisebene nach oben...

    Alles probiert mit den portablen Boxen unter Win11...

    RISC OS folgt heute Abend.

    Aber seltsam schon, das unterschiedliche Verhalten. Ensemble ist das selbe also müssen die Boxen (oder die DOS Versionen) die Tastatureingaben anders handhaben. Sichtbare Unterschiede in der config gibt es nicht.

  • Dumme Frage aus dem OFF: Wenn F5 die Standard-Taste zum Neuaufbau von Fenstern ist, warum dann nicht im GeoManager F5 benutzen um erst die Dateien neu einzulesen und dann erst das Fenster neu darzustellen? Dann muss ich niemand Strg-F4 als weiter Kombination merken. :/
    Also Konzeptionell: Datei nicht da obwohl ich sie vom Host gerade eingespielt habe? -> F5 -> Ah, da ist sie ja!

    GPC-Installer v3.0.9D feat: add MOUNT -s flag for lazy hostdrive refresh

    Add RefreshMode enum (Manual/Lazy) and MOUNT -s flag to automatically invalidate directory cache on FindFirst, matching the existing floppy refresh behavior. Includes localdrive unit tests validating that Manual mode caches while Lazy mode picks up external host file changes.

    Im Grunde ist Ctrl+F4 nur nötig um den Directory-Cache zu löschen. Für -t floppy Mounts wird der jetzt schon nicht genutzt, um Diskettenwechsel zu behandeln. Auf modernen Rechnern scheint das auch keinen Performance-Impact zu haben, wenn man's deaktiviert. Ohne Hostintegration plopt eine neue Datei zwar nicht von selbst im File/GeoManger auf, aber beim Verzeiichniswechsel oder F5 wird sie sichtbar. Vieleicht ist das ja schon Änderung genug. Probierts einfachmal aus...

    Gruß Thomas

  • Hallo Thomas,

    gibt es denkbare Nachteile, wenn man -s macht, wann gibt es die? Auch: Braucht die basebox das als Option oder könnte da einfach das Defaultverhalten sein? Dann würden wir die Kompatibilität mit anderen Dosboxen nicht brechen und ein wenig Konfigurationkomplexität sparen. Ähnliche Frage hätte ich bei der Time-Symc-Option.

    Viele Grüße,

    Falk \\ blueway.Softworks

  • Ich habe einfach mal "-t floppy" und "-s" ausprobiert. In der BaseBox funktionieren beide Parameter.

    In meiner DOSBox staging 0.7x funktioniert "-t floppy", was so auch unter anderen / älteren DOSBox-Versionen gehen sollte. Der Umgang mit kopierten / verschobenen Dateien funktioniert wie vorhergesagt einfach per F5, oder durch den Wechsel des Verzeichnisses. Sehr komfortabel.

    Risiken und Nebenwirkungen müssen sich noch herausstellen...

  • Negative Auswirkungen auf Datenkonsistanz sind nicht zu erwarten, da nur der Direktory-Cache praktisch für mit -s gemountete Drives vor jedem Dir gelöscht wird - Floppy Mounts ist das Default. Auf die Schnelle habe ich keine spürbaren Effekte beim Betrieb von Geos bemerkt - ich habe aber auch kein R-Basic getestet und wüsste jetzt spontan auch keine App, viele Dirs triggert. Vielleicht wirkt sich der fehlende Cache auch nur Host-Lw mit hoher Latenz WebDav-Mounts(?) negativ aus. Das gilt es zu testen…

    Generell denke ich, sollten alle Geos-spezifischen Anpassungen ein Opt-In sein, wenn wir sie upstream bringen wollen. Codeblöcke für zusätzliche DOSBox.conf Parameter sind ja zusammenhängend an einer Stelle und eigentlich unproblematisch. Die Anpassung des Mount Befehls war hier bewusst, um z.b. im Splitsetup zwischen System und User-Tree auf getrennten Lw evtl. Performanceprobleme umschiffen zu können.

    Einstellungen bzgl. bedingter Compilierung halte für viel problematischer. Meson und Cmake Configs sind IMHO schwieriger zu warten - und solange DB-Staging beides nutzt doppelte Arbeit. Ich würde sogar soweit gehen, BaseBox im (CI/CD-)Code nicht so zu nennen, weil die dadurch entstehenden Brüche einfach nur lästig sind.

  • Zwischen wir führen -s ein und ggf. landet es in einem offiziellen DB Staging Release kann halt lang sein und mit allen andere DOS-Boxen ist es nicht kompatibel. Aus der Sicht sehe ich für solche Kernaspekte konfigurierbarkeit kritisch, inbesondere wenn es keinen Nutzernutzen hat.

    Interne Naming sollte man unverändert lassen. Änderungen im Code selbst sollten so wenig wie möglich sein, auch da ist wenig Config, wenig Impact. Für den Time-Sync gar es ja schon einen Compile-Schalter, warum hast Du den nicht benutzt? Interessant wäre zu verstehen, was ist anders in Deiner Implementation verglichen zum Original?

    Viele Grüße,

    Falk \\ blueway.Softworks

  • Wenn ich mich richtig erinnere, war der Compilerschalter nicht als Build Flag implementiert nur im Code zu setzen. Der Code, den er aktivierte, hat eine Zeitdifferenz durch kleine Offsets versucht auszugleichen (kontinuierlich). Das hilft nichts nach einem Host-Wakeup… außer man hat viel Geduld. Mehr Code/Rechenaufwand ist es auch.