Sie sind nicht angemeldet.

Neues SDK: Mein erstes eigenes Programm: Erfahrungsbericht

Lieber Besucher, herzlich willkommen bei: GEOS-InfoBase-Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

jpolzfuss

Profi

  • »jpolzfuss« ist der Autor dieses Themas

Beiträge: 835

  • Nachricht senden

1

Freitag, 20. November 2020, 12:35

Neues SDK: Mein erstes eigenes Programm: Erfahrungsbericht

Hallo!

Ich habe es jetzt geschafft, dass eines meiner Uraltprogramme nun auch dann läuft, wenn es mit dem neuen SDK kompiliert wird. ;) :D

Codeänderungen/Anmerkungen:
  • Erstellt hatte ich das Programm mit dem alten DOS-SDK für den Zoomer. Daher hießen die Dateien EDDIE.GOC, EDDIE.GP und LOCAL.MK. Das verursacht arge Probleme mit dem neuen SDK -> Umbenannt in Eddie.goc, Eddie.gp und local.mk (Ordner heißt "Eddie"). --> Das neue SDK erzeugt trotzdem noch ein heilloses Durcheinander von Schreibweisen. Die erzeugten GEO- und SYM-Dateien werden z.B. komplett klein geschrieben, während die anderen erzeugten Dateinamen (EC, EOBJ, OBJ, ...) alle mit einem großen E anfangen.
  • Dem alten SDK war es egal, wie die Groß-/Kleinschreibung der Ressourcen war. Beim neuen SDK muss das exakt im GOC-File so heißen wie im GP. --> Korrigiert
  • Das Programm arbeitet "natürlich" mit Zufallszahlen und daher mit Floats, die im neuen SDK noch Probleme bereiten. -> Durch einen eigenen "Pseudozufallscode" ersetzt. ;)
  • Das Programm nutzte einen Trick, um auf dem Zoomer im GeoManager zweizeilige Dateinamen zu erzeugen (\r statt eines Leerzeichens im Namen). Das bereitete jetzt Probleme (Punkte statt \r im Fenstertitel, ...), was aber vermutlich nicht am SDK, sondern an der ISUI als "specific UI" liegt). --> Name gekürzt.
  • Der DosBox MB6 bereitet Probleme, wenn man ihn als Target benutzt, da das Geos permanent ausgebremst wird. --> Eine "normale DosBox 0.74" parallel installiert und anstelle des MB6 in den Suchpfad gesetzt.
  • Im neuen SDK waren mehrere "Platform-Files" entweder viel zu kurz, oder gar nicht erst vorhanden. --> Pull-Request in Git erstellt, Änderungen sollten jetzt im neuen SDK enthalten sein.
  • Ich weiß nicht, ob mein Programm "schon immer" nicht korrekt lief, oder ob sich der Watcom etwas "zickiger" verhält. Früher habe ich z.B. einfach ein "word x = ...; byte y = x;" gemacht. Das verursachte nun Probleme mit dem HEAP! --> überall einen "explicit cast" eingebaut und Sicherheitsvorkehrungen à la "word x = ...; byte y = (byte) (x % 256);" getroffen. Und wo ich schon dabei war, habe ich den Code gleich drastisch verschlankt. ;)
  • Ich hatte in der local.mk ein "NO_EC = 1". Früher hat es gereicht, das in "NO_EC = 0" zu ändern, um die EC-Variante zu erzeugen. Das klappt jetzt nicht mehr. --> Zeile muss auskommentiert werden, wenn man die EC-Variante erzeugen will.
  • Swat findet manchmal die SYM-Dateien nicht, obwohl der vorgeschlagene Pfad stimmt?! --> Pfad kann man händisch eingeben und normal weiterarbeiten. --> Ich muss hier mal vernünftige "Steps to reproduce" herausfinden und einen Fehler auf Github erstellen.
  • Der "pmake depend"-Schritt beim "mkmf" liefert immer noch Fehlermeldungen bzgl. angeblich fehlender Header-Dateien. --> Ist nur nerbig, funktioniert aber trotzdem alles. --> Fehler auf Github erstellt. ;)


Gruß
Jörg
»jpolzfuss« hat folgende Datei angehängt:
  • Eddie.zip (12,21 kB - 447 mal heruntergeladen - zuletzt: Heute, 15:08)
There are two rules in life:
1. Never give out all of the information.

Rainer

Profi

Beiträge: 856

  • Nachricht senden

2

Freitag, 20. November 2020, 20:28

Coole Sache! Viel Arbeit für Falk ;-)
Mit der Forderung, dass man überall eine "explizit cast" benötigt, könnte ich nicht leben.
Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

jpolzfuss

Profi

  • »jpolzfuss« ist der Autor dieses Themas

Beiträge: 835

  • Nachricht senden

3

Samstag, 21. November 2020, 13:26

Nach den ganzen Umbauten kann ich leider nicht mehr sagen, ob ein „expliziter Cast“ wirklich erforderlich ist. Denn ein Teil der „Casterei“ ist nun weggefallen - so viele Variablen waren das nicht, um selbst auf einem Zoomer diese Casts zu rechtfertigen.

Die ganzen Heap-Probleme traten auf jeden Fall laut swat dann auf, wenn der Double-Wert oder Word-Wert deutlich größer als 10.000 war und dann nach Byte konvertiert wurde. Kann sein, dass das „modulo 256“ in diesem Fall reichen würde... Vielleicht schreibe ich nächste Woche einfach mal einen „Heap-Violator“, um das zu testen...
There are two rules in life:
1. Never give out all of the information.

frehwagen

Schüler

Beiträge: 89

  • Nachricht senden

4

Samstag, 21. November 2020, 17:05

Kann es sein, dass der SWAT nicht mit 6 byte doubles umgehen kann bei Stack-Dump? Dass der Compiler was übersetzte was dann nicht funktioniert in der beschriebenen Art und Weise glaube ich eher nicht.

Jirka Kunze

Schüler

Beiträge: 64

  • Nachricht senden

5

Mittwoch, 25. November 2020, 20:51

Hallo Jörg,

der Problematik mit dem double werde ich mich annehmen.

Da das NewSDK als Host OS sowohl Windows als auch Linux unterstützen soll ist jetzt auch etwas mehr Disziplin bei den Includes notwendig bspw. muss es jetzt "#include <Ansi/string.h>" anstatt "#include <ansi\string.h>" lauten.

JIrka

Ähnliche Themen

Thema bewerten