Reverse Engineering der NLT II

[Obi-Wahn]

Als ich während Corona als Info-Lehrer in einer Schule Homeschooling implementiert haben wir Jitsi (Browserbasiert) genutzt.

Features:
* Datenschutzkonform (verschlüsselte Server in Deutschland),
* keine Anmeldung/Registrierung,
* Termin ausmachen, Link wird von mir generiert und verschickt,
* Piep-einfach, funktioniert und vermeidet unnötige Arbeit.

Die Schulleitung wollte gern MS-Teams benutzen, war jedoch in technischen Dingen sehr unbedarft und kontrollsüchtig.
Die wurden ab einem gewissen Zeitpunkt komplett ignoriert und nach einem Jahr hab ich gekündigt.
Jetzt haben sie 60 Linux-Laptops. CHECK!

Da hatten wir in Niedersachsen auch Glück. Die Schulen haben von IServ BigBlueButton-Server zur Verfügung bekommen. Lief insgesamt recht gut. Auch wenn ich zugeben muss, dass Zoom am problemlosten war. Die Datenschutzproblematik und vor allem die Abhängigkeit von Dritten wird leider von vielen Leuten ignoriert und heruntergeredet....

[HenneNWH]

Das sehe ich auch so. Zoom kann ich auch anbieten, das setzt einen Client bei jedem voraus.
Bei euch geh ich davon aus, dass ihr das hinbekommt.
Bei den Corona-gestressten, technisch unbedarften 160 Haushalten der Schule im ländlichen Raum hätte das nicht funktionieren können.

BBB hab ich noch nie benutzt und finde das an sich eine gute Lösung für geschlossene Bereiche (Uni, Unternehmen),
erfordert allerdings, dass sich jemand darum kümmert.
Bei dem Jitsi-Server, welchen die Schule benutzt hat, war der Freifunk München der Hoster. Hat super geklappt.

[Obi-Wahn]

Wäre es eigentlich möglich die Wechsel zwischen Anfänger- und Fortgeschrittenmodus und der verschiedenen Speicherversionen in das grüne Menü als Punkt aufzunehmen? Die Tasten 6 und 7 sind doch etwas schwer zu merken.

[NewProggie]

@Obi-Wahn & NewProggie: Obi hat's auf den Punkt gebracht. BrightEyes stellt "nur" moderne Binaries für die alten Datenfiles um die Schicksalsklinge/Gen auf mehr (Linux) oder weniger (Windows) modernen Systemen nutzbar zu machen. CI ist somit ohne DSAGEN.DAT möglich, wenn es nur ums kompilieren geht.

Richtig. Ich dachte aber tatsächlich daran, eine DSAGEN.DAT mit ins ZIP zu packen, so dass man eine standalone-Lösung herunterladen kann. Das wird aber vermutlich aus Copyright-Gründen immer noch nicht möglich sein. Kann das jemand bestätigen?

Prinzipiell halte ich CI für eine gute Sache, wenn sie von fähigen Leuten langfristig betreut und instand gehalten wird.
@NewProggie: Haste Bock?

Das kann ich gerne im BrightEyes Repository aufsetzen. Magst du mir vielleicht für das Repository Push-Rechte geben, dann müsste ich keinen Umweg über meinen Fork machen? Alternativ kann ich auch nochmal forken und einen PR aufmachen.

Wenn eurerseits Interesse besteht: Ich halte es für einen guten Zeitpunkt ein datenschutzkonformes, zwangloses Online-Treffen zu organisieren (ca. 1h).
ich würde mich freuen über die Teilnahme von: siebenstreich, Obi-Wahn und NewProggie.
Jeder andere ist gern willkommen. Es gelten die Forenregeln und gesunder Menschenverstand.

Da bin ich auch gerne dabei.

[HenneNWH]

@Obi-Wahn & NewProggie: Obi hat's auf den Punkt gebracht. BrightEyes stellt "nur" moderne Binaries für die alten Datenfiles um die Schicksalsklinge/Gen auf mehr (Linux) oder weniger (Windows) modernen Systemen nutzbar zu machen. CI ist somit ohne DSAGEN.DAT möglich, wenn es nur ums kompilieren geht.

Richtig. Ich dachte aber tatsächlich daran, eine DSAGEN.DAT mit ins ZIP zu packen, so dass man eine standalone-Lösung herunterladen kann. Das wird aber vermutlich aus Copyright-Gründen immer noch nicht möglich sein. Kann das jemand bestätigen?

Ich hab Dr. Stefan Blanck (Lizenzinhaber der NLT) vor vielen Jahren kontaktiert und gefragt, ob ich dieses Projekt umsetzen kann.
Er hat mir sinngemäß geschrieben, dass meine Nutzer eine legale Kopie des Spiels besitzen müssen.
Somit würdest du dich potentiell strafbar machen, wenn du die DSAGEN.DAT verteilst.

Gute Vorbilder in dieser Sache sind ScummVM und Exult.
Im Exult FAQ unter 1.3 und 2.1 und What is ScummVM ist das so definiert. Zu Recht.

Prinzipiell halte ich CI für eine gute Sache, wenn sie von fähigen Leuten langfristig betreut und instand gehalten wird.
@NewProggie: Haste Bock?

Das kann ich gerne im BrightEyes Repository aufsetzen. Magst du mir vielleicht für das Repository Push-Rechte geben, dann müsste ich keinen Umweg über meinen Fork machen? Alternativ kann ich auch nochmal forken und einen PR aufmachen.

DEV-INFO:
Ich hab soeben den Git-Hook 'pre-commit' für BrightEyes angepasst.
Der liegt unter 'src/tools/pre-commit' und sollte für Entwickler die pushen nach ./git/hooks kopiert werden.

Was hältst du denn davon: Du bereitest das für das Treffen auf deinem Fork vor und zeigst uns das mal.
Dann denk ich drüber nach und entscheide dann ob es wirklich langfristig für BrightEyes etwas bringt.

Dem CI-Gedanken (Continous Integration) hab ich aus meiner Sicht mit dem Hook genüge getan.
Der CD-Gedanke (Continous Delivery) ist tatsächlich noch stark ausbaufähig.

Bei ScummVM halte ich das für absolut sinnvoll, siehe ScummVM Releases .
Ob es für unseren kleinen Kreis zu überdimensioniert ist, kann ich noch nicht beurteilen.

Welches System nutzt du denn?: Hab bisher mit Jenkins Erfahrungen gemacht.

Wenn eurerseits Interesse besteht: Ich halte es für einen guten Zeitpunkt ein datenschutzkonformes, zwangloses Online-Treffen zu organisieren (ca. 1h).
ich würde mich freuen über die Teilnahme von: siebenstreich, Obi-Wahn und NewProggie.
Jeder andere ist gern willkommen. Es gelten die Forenregeln und gesunder Menschenverstand.

Da bin ich auch gerne dabei.

[Obi-Wahn]

Kannst du grob umschreiben was du gerade machst, Henne? Ich sehe, dass du schon sehr aktiv am Aufräumen beim Code von Schick bist.

[HenneNWH]

Um es einfach zu sagen: Ich entferne aus dem Schick-Code die Abhängigkeiten zur DOSBox.

Damals habe ich tief in der Trickkiste gewühlt, damit der Code in beiden Welten (DOSBox und DOS) korrekt funktioniert,
z.B. aus der virtuellen DOSBox-Umgebung ausbrechen, eigenen Code ausführen und wieder in die DOSBox rein, wenn es sich um Standartcode handelt (CLib: open(), close(), ...) oder Funktionalitäten welche von der virtuellen DOSBox-Hardware abhängen.
Dafür wurden "Callbacks" verwendet.

Schick soll irgendwann, wie NGEN, als native Desktop-Anwendung laufen, weshalb ich vorerst davon ausgehe,
das auf unterstützten Betriebssystemen eine funktionierende C-Bibliothek vorhanden ist.
Außerdem muss ich jetzt umdenken und ausschließlich für reale (aber veraltete) Hardware entwickeln.


Die Funktion creat() "Erzeugen einer neuen Datei" ist ein Beispiel dafür.
Diese ist auf den gängigen Betriebssystemen seit Äonen vorhanden,
schien unter Windows jedoch dafür verantwortlich gewesen zu sein,
dass die Dateilänge der CHR-Dateien unterschiedlich war.
In dem Fall kann gesagt werden: "Windows hat nachweislich meine Dateien kaputt gemacht."
Mit einem open() mit passenden Parametern konnte ich das Verhalten von creat() nachbilden und es scheint zu funktionieren.

Jetzt entferne ich gerade diese Verbindung zu C-Bibliothek ohne die DOS-Version zu beschädigen.
Mit dem bisher benutzen Testverfahren ist das ohne Weiteres möglich.
Wenn ich anfange die hartcodierten Variablen in richtige Variablen umzubenennen, funktioniert dieses jedoch nicht mehr.
Am Beispiel von NGEN habe ich schon ein Hilfsprogramm erstellt, welches zwei BCC EXE-Dateien vergleichbar macht.
Damit geht es dann hoffentlich.
Darüber zerbrech ich mir jetzt nicht den Kopf und lösche munter vor mich hin, bis es nicht mehr weitergeht.

[Obi-Wahn]

Danke, jetzt verstehe ich das (teilweise) besser!

[HenneNWH]

Kleine Zwischenmeldung:
Die Header-Dateien von Schick wurden etwas umstrukturiert und entrümpelt.
Es ist mir auch gelungen 7 / 113 Dateien mit dem GCC zu übersetzen.
Weiterhin hab ich mein BCC-EXE-Vergleichsprogramm an Schick probiert und es funktioniert.
Natürlich gibt es noch einiges zu tun...

[Obi-Wahn]

Danke für das weitere Update! Ich bin gespannt, wann der Schick-Teil den ersten Test-Build-Status erreicht haben wird. 

Übrigens hat das BrightEyes-Repository mit 1016 Commits bzw. Änderungen/Freischaltungen gerade die tausender Marke überschritten! Glückwunsch, Henne! 

[HenneNWH]

Danke, danke!

Hab heute noch ein Schmalkerl geschafft:
Die englische Version von GEN (V3.00 en) konnte vor einiger Zeit binäräquivalent nachgebaut werden.
Seit heute ist der Quellcode von GEN (V1.05 de) auch binäräquivalent zu der GEN.EXE der CD-Version.  
Beim Überarbeiten des Audio-CD Codes von Schick ist mir aufgefallen, dass ich dort "wieder einmal" etwas richtig gemacht habe.

Wann es für moderne Betriebssysteme eine überarbeitete Version von der Schicksalsklinge geben wird ist noch unklar.
Vorher gibt es noch viel zu löschen!

[NewProggie]

Dann packe ich direkt noch einen drauf 

Ich hab gerade einen Pull Request eröffnet mit CI Support für Windows, macOS, Ubuntu Linux und DOS. Interessant für die Nutzer ist vielleicht, dass man sich bei jeder Codeänderung jetzt die aktuellste EXE herunterladen und ausprobieren kann.

Für die Entwickler unter uns wird im Wesentlichen alles aus dem pre-commit gemacht. Da scheint aber aktuell noch ein bisschen was zu fehlen, weil die Originaldateien (aus dem bnt.sh Skript) nicht erzeugt werden. Für den Test auf Binäräquivalenz würde ich das build.sh Skript noch gerne abändern, so dass am Ende eine XML erzeugt wird, die GitHub versteht (JUnit-Format) und dann hübsch für jeden Commit auch die Testergebnisse anzeigen kann.

[Obi-Wahn]

Wow, super! Bin gespannt, wann der CI Support verfügbar ist.

Anbei vielleicht einer der letzten handgemachten Builds.


  BrightEyes_2025_07_19.zip (Größe: 1,39 MB / Downloads: 0)

[HenneNWH]

Sehr gut, NewProggie!

Habe mir vorhin noch Notizen zum bnt.sh-Skript gemacht.
Das Ding war erstmal nur für mich gedacht und es ist noch nicht ganz fertig und auch noch nicht dort wo es hingehört.
Möglicherweise bin ich der Einzige der mehrere verschiedene Original EXE-Dateien hat.
Bei anderen DEVs oder im CI kann das Script u.U. gar nicht wie bei mir funktionieren.

Da denke ich nochmal ausgiebig drüber nach. Passt morgen Abend?

[NewProggie]

Sehr gut, NewProggie!

Habe mir vorhin noch Notizen zum bnt.sh-Skript gemacht.
Das Ding war erstmal nur für mich gedacht und es ist noch nicht ganz fertig und auch noch nicht dort wo es hingehört.
Möglicherweise bin ich der Einzige der mehrere verschiedene Original EXE-Dateien hat.
Bei anderen DEVs oder im CI kann das Script u.U. gar nicht wie bei mir funktionieren.

Da denke ich nochmal ausgiebig drüber nach. Passt morgen Abend?

Sollte passen. Ehrlicherweise würde ich die ganzen Shell-Skripte und das alte Makefile gerne mal aufräumen und für die CI fit machen. Gerade die Tests auf Äquivalenz ließen sich super mit CMake automatisieren und das würde auch direkt maschinenlesbare Ergebnisse produzieren können.

[NewProggie]

Wow, super!    Bin gespannt, wann der CI Support verfügbar ist.

Anbei vielleicht einer der letzten handgemachten Builds.  

Das lässt sich in meinem Fork aktuell schon testen: https://github.com/NewProggie/BrightEyes/actions

Hier links auf das eigene Betriebssystem klicken:


und dann unten das ZIP herunterladen:

[Obi-Wahn]

Wow, super!    Bin gespannt, wann der CI Support verfügbar ist.

Anbei vielleicht einer der letzten handgemachten Builds.  

Das lässt sich in meinem Fork aktuell schon testen: https://github.com/NewProggie/BrightEyes/actions

Ui, das wird ja immer besser! Der Windows-Build sträubt sich leider noch.

Es ist echt beeindruckend, was GitHub kann und auch frei zur Verfügung stellt.

[HenneNWH]

Sollte passen. Ehrlicherweise würde ich die ganzen Shell-Skripte und das alte Makefile gerne mal aufräumen und für die CI fit machen. Gerade die Tests auf Äquivalenz ließen sich super mit CMake automatisieren und das würde auch direkt maschinenlesbare Ergebnisse produzieren können.

Nope, die brauche ich.
Zum Testen für die DOS-EXEn reicht doch auch pro Datei eine Prüfsumme.
Das erspart Copyright-Fragen, unnötige Arbeit und liefert die benötigte Antwort.

[NewProggie]

Sollte passen. Ehrlicherweise würde ich die ganzen Shell-Skripte und das alte Makefile gerne mal aufräumen und für die CI fit machen. Gerade die Tests auf Äquivalenz ließen sich super mit CMake automatisieren und das würde auch direkt maschinenlesbare Ergebnisse produzieren können.

Nope, die brauche ich.
Zum Testen für die DOS-EXEn reicht doch auch pro Datei eine Prüfsumme.
Das erspart Copyright-Fragen, unnötige Arbeit und liefert die benötigte Antwort.

Mit Aufräumen meinte ich auch nicht löschen, sondern refaktorisieren ;-)

[NewProggie]

Ui, das wird ja immer besser! Der Windows-Build sträubt sich leider noch.

Es ist echt beeindruckend, was GitHub kann und auch frei zur Verfügung stellt.

Kannst du sagen, was genau schief läuft bei Windows?