Unterschiede BBE 4 vs NDO2000/GPC?

    Moin,

    Hier eine Frage an die mit gutem Gedächtnis oder einer gut sortierten Sammlung 😉 Soweit ich mich erinnere war ja BBE damals in mancher Hinsicht ein Rückschritt im Vergleich zu NDO2000. Das betrifft natürlich vor allem das CUI, welches in BBE nicht dabei war. Auch enthielt NDO2000 eine neuere Version des FileFinders.

    Aber davon abgesehen, an was für Sachen erinnert ihr euch darüberhinaus noch? Was war in NDO2000 noch verbessert und fehlte später in BBE? Bin für jeden Hinweis dankbar.

    Bye,

    MeyerK

    Bye,
    MeyerK

    Gosh, Konstantin, you ask about things 20 years ago! I remember that Gene wrote a new E-mail peogram, called E-mail, the NDO e-mail programs was ditched. Gene also made updates to NDO GUI, free to download and install. I also recall that Frank at Breadbox complained about changes made to the code during GlobalPC/NDO era which contained bugs which affected the Terminal program among other things. Something also happened to the parallel port handling. This lead for Breadbox to take a step back codewise, to older version pre the changes. Hopefully, others can fill in?

    Hat eigentlich jemand einmal Gene Anderson bezüglich dem dem Quellcode von seinen Programmen kontaktiert?

    Irgendwie sollten wir von diesen ehemaligen Programmierern eine Liste führen mit dem Status, was mit ihren Programmen und Quellcode geschehen soll oder eben nicht...

    MeyerK Der hat leider noch keine Implementierung bezüglich ResEdit. Ich habe die DE / EN per globaler Konstante implementiert, was natürlich nicht ganz SDK-like ist...

    Sollte mal den Quellcode auf mein persönliches Github legen. So könnten die geübten Programmierer mir sicher entsprechende Hints geben...

    Ich habe bei den TrayApps (war es das?) die ganze Lokalisierungsgeschichte entfernt. Nach dem Einchecken des englischen Source-Codes war am nächsten Tag in der deutschen Version alles wie von Geisterhand übersetzt ;) Will sagen, die Übersetzungscrew hat sich drum gekümmert und ich habe echt keine Ahnung wie sie das macht, bin einfach nur dankbar. Will sagen, die Lokalisierung kann trotzdem gelingen, auch wenn Du sie einfach nur entfernst ;)

    Bye,
    MeyerK

    Ich habe da Texte in Chunks definiert. Das muss ich erst einmal so umbauen, dass diese dann auch per ResEdit übersetzt werden kann.

    Grundsätzlich muss ich mir hier erst einmal einen Plan erstellen, wie ich das auf Github am besten organisiert bekomme. Hätte gerne einen Projektordner mit Unterprojekten, um das organisatorisch vom anderen zu trennen. Wurde da schon etwas bezüglich 3rd-Party Apps im FreeGEOS entschieden? Dort wird man sich wohl sehr ähnliche Fragen machen müssen...

    Dann wäre noch zu klären, welche Dateien genau ins Github sollen, bzw. welche man explizit exkluden soll. Wenn hierzu jemand einen Vorschlag hat, wäre das sicher sehr hilfreich. Und hoffentlich nicht nur für mich.

    Also, seitens Github scheint es keine vernünftige Methode zu geben, Projekte in einem (Verzeichnis-)Baum zu strukturieren. Man kann lokal auf seinem Rechner Submodule verwenden, um andere Repos in einem Unterverzeichnis einzubinden. Sehe da jetzt aber keinen direkten Weg / Nutzen au Github selbst.

    Klar, ich kann in meinem Github-Account ein neues Repo anlegen. Für den (Geo)Ladder zum Beispiel "pcgeos-3rd-games-ladder"?.

    Habe da leider jeweils etwas Start-Motivations-Probleme, wenn es nicht von Anfang an klar ist :|

    Wir hatten auf dem Treffen mal gesagt, dass Zusatzanwendungen in ein Verzeichnis namens "ThirdParty" oder so kommen sollen. Bisher haben sich aber noch nicht so viele gefunden ;) Gene's Anwendung(en) sind zum Beispiel unter "dil" (designs in light) zu finden.

    Also, ich (!) finde, GeoLadder ist GeoGeschichte und gehört ins Repo. Da würde ich jetzt an Deiner Stelle einfach das pcgeos repo auf GitHub clonen und dann in Deinem geclonten Repo einen neuen Zweig anlegen, zum Beispiel "GeoLadder". Dann fügst Du in Deinem geclonten Repo einen Ordner namens ThirdParty/GeoLadder hinzu und packst da Deinen Source rein. Du könntest den Ladder auch unter Appl/Games packen und im Source deutlich kennzeichnen, dass das kein GeoWorks Code ist sondern alpenfrischer Bollhalder-Code aus der Schwitz. Dann kannst Du den Code bearbeiten und testen. Wenn du fertig bist, kann man besprechen ob der "GeoLadder" Teil von PC/GEOS Ensemble V6 1.0 sein soll (;-), ich meine: ja) und Du fügst fügst ihn dem FileTree und dem globalen Makefile hinzu. Anschließend machst du einen Pull-Request auf den Hauptzweig (also bei blueway) und fertig.

    Bye,
    MeyerK

    Hallo Konstantin

    Das hört sich nach einem guten Plan an :thumbup:Den werde ich aber im Moment noch etwas auf die (hoffentlich nicht allzu lange) Bank schieben. Habe gerade heute Morgen bei mir im Github ein Repo angelegt und den hoffentlich letzten Stand hochgeladen:

    GitHub - bolle732/pcgeos-3rdparty-games-ladder: This is a clone of the game Ladder originally written by Yahoo Software for various CP/M systems.
    This is a clone of the game Ladder originally written by Yahoo Software for various CP/M systems. - bolle732/pcgeos-3rdparty-games-ladder
    github.com

    Das wird mit dem aktuellen SDK problemlos übersetzt und es sind mir bis anhin keine Bugs aufgefallen.

    Dieses Repo kann sich jeder Interessierte in sein LOCAL_ROOT clonen. Bei mir sieht das folgendermassen aus:

    Code
    mkdir -p /home/bolle/pcgeos-local/Appl/GeoLadder
cd /home/bolle/pcgeos-local/Appl/GeoLadder
git clone https://github.com/bolle732/pcgeos-3rdparty-games-ladder.git .
source ~/.pcgeosrc
mkmf
pmake depend
pmake

    Der Befehl source ~/.pcgeosrc ist spezifisch bei mir, da ich alle Umgebungs-Variablen in eine dedizierte Datei ausgelagert habe. Einige Tools von Watcom gibt es auch unter Linux und das beisst sich bei anderen Projekten, welche die Linux-Variante brauchen...

    Meine ".gitignore" sieht folgendermassen aus:

    Code
    # PC/GEOS compile artifacts
Makefile
*.geo
*.mk
*.mk
*.nc
*.obj
*.rsc
*.sym

    Passt das so? Oder gibt es für einzelne Projekte noch weitere wichtige Dateien auszuschliessen?

    Ein paar generelle Fragen habe ich natürlich noch:

    • Wie handhabt Ihr die ".rev" Datei? Einfach auf immer und ewig hochzählen lassen? Wie macht man das, wenn man auf verschiedenen Rechnern daran arbeitet oder wenn Andere mitwirken?
    • Die Readme-Datei habe ich als Markdown mit der Endung ".md". Die Lizenz-Datei von Github per Erstellen vom Repository ist ohne Endung und nur reiner Text. Die kann man auch ohne Problem mit der Markdown-Endung führen.
    • Was für andere Dateien soll man noch verwenden? INSTALL, THANKS, TODO, VERSION etc.
    • Könnte man all die Fragen mit entsprechenden Antworten / Konventionen / Vorlagen hier in einem Wiki führen oder soll das auch auf Githab?

    Grundsätzlich möchte ich noch etwas sattelfester im Umgang mit Github werden. Freue mich von daher auf jeden Input ;)

    Gruss
    Andreas

    PS:
    Und danke für die Motivations-Blumen 8)

    Plan ist es, den Quellcode übersetzbar zu machen. Dann kann man ihn in das offizielle Repo überführen.

    Und Ideen für Erweiterungen sind auch noch da. Die kann ich dann in Branches meines Repo vorerst testen, ohne Branches im offiziellen Repo fahren zu müssen.

    Quote from bolle732

    Ich habe da Texte in Chunks definiert. Das muss ich erst einmal so umbauen, dass diese dann auch per ResEdit übersetzt werden kann.

    Texte in Chunks sollten sofort mit Resedit übersetzbar sein. Auch visMoniker, GTXI_text etx. Probleme machen wahrscheinlich Sonderzeichen unter 0x20, wenn sie im Text sind. Plain Text im Code ist nicht lokalisierbar.

    Quote from bolle732

    *.mk

    Die darfst du auf keinen Fall git-ignoren. Schau mal in die gitignore vom Repo.

    Quote from bolle732

    Was für andere Dateien soll man noch verwenden? INSTALL, THANKS, TODO, VERSION etc.

    Da würde ich sagen: Was du für richtig / nötig hältst.

    Quote from bolle732

    Wie handhabt Ihr die ".rev" Datei? Einfach auf immer und ewig hochzählen lassen? Wie macht man das, wenn man auf verschiedenen Rechnern daran arbeitet oder wenn Andere mitwirken?

    die rev wird nur hochgezählt, wenn du im local-root arbeitest. Da hast du ja immer alle Dateien synchron, wenn du auf anderen Rechnern arbeitest und andere Leute haben keinen Zugriff. Im root_dir (pmake in pcgeos\installed\apll\myapp aufrufen) wird sie nicht angefasst. Das ist nicht schön, aber unvermeidbar.

    LG
    Rainer

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

    Hallo Rainer

    Herzlichen Dank für Antworten.

    Quote

    Die darfst du auf keinen Fall git-ignoren. Schau mal in die gitignore vom Repo.

    Ja, die "local.mk" habe ich zum Beispiel auch im Repo drin. Auf die andere Seite wir die "dependecies.mk" doch bei jedem neu erzeugt. Sollte man in diesem Fall einfach nur die "dependencies.mk" in die ".gitignore" aufnehmen?

    Die ".gitignore" habe ich mir im Repo angesehen. Da ist halt auch von den Tools und allem sehr viel drin, was bei mir nicht benötigt wird...

    Andreas

    Und bei den Chunks ist eben nicht einfach Text...

    @ifdef I8N_DE
    @chunk byte ScreenMenu[] = {
     // Title
     TSPOS(0, 11),
     TSD_T_CHAR + 2, 'L', // Text "LL"
     TSP_T_MOVE, 21,
     TSD_T_CHAR + 2, 'd', // Text "dd"
     TSP_T_MOVE + 7,
     TSD_T_CHAR + 2, 'd', // Text "dd"
     TSPOS(1, 11),
     TSD_T_CHAR + 2, 'L', // Text "LL"

    Den Text habe ich kodiert und das macht es für ResEdit unmöglich zu übersetzen...

    Eigentlich muss ich den ganzen Aufbau überdenken. Mein Ziel dazumal war es, so kompkten code wie möglich zu generieren. Das ist dann beim Portieren ein Hinderniss.

    Aus mir nicht bekannten Grund muss die dependencies.mk und die MakeFile im Ordner Installed/Appl/MyApp (wo man pmake ruft) vorinstalliert sein. Der Buildprozess von Falk erzeugt sie NCIHT neu. Dito für Installed/Libary/... usw.

    Rainer

    PS. Versuchmal chunk char statt chunk byte.-

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

    Also, wenn ich in meinem "LOCAL_ROOT", das nicht innerhalb von "ROOT_DIR" liegt ein "pmake clean" mache und anschliessend die "dependencies.mk" lösche, wird diese bei mir nach einem "mkmf", "pmake depend" und "pmake" neu erstellt.

    Char anstatt Byte kan ich veruchen, wird aber trotzdem für das übersetzen schwierig. Die Texte sind ja verstückelt und durch über Steuerzeichen quasi zusammen gesetzt. Das ist für den Überstzer wohl zu viel... Und in Objekten sind auch noch je nach Sprache Längenangaben mit "ifDefs" für diese Texte vorhanden...

    Ich muss mir einmal eine Beispiel-App mit Überstzung basteln. Dann kann ich den Main-Branch in eine Next-Branch überführen und da versuchen das umzubauen. Eventuell ist es am Schluss fast einfacher, den Aufbau komplett neu zu machen und für weitere Änderungen zu öffnen.