Aktuelles SDK

    Falls jemand übrigens mal unter Windows die DOSBox-Variante mit Swat ausprobieren will, hier ein paar Tipps, wie man Falks Tool stubproxy benutzt:

    In der DOSBox-Konfiguration muss man unter [serial] folgendes eintragen:

    Code
    serial1=nullmodem transparent:1 port:8079


    Dann ruft man die DOSBox auf und startet den seriellen Swat-Stub mit ss.bat. Schließlich kann man ein kleines Batchfile benutzen, um das Proxy-Tool und den Debugger zu starten:

    Code
    start c:\GEOS6\pcgeos\bin\stubproxy 127.0.0.1
timeout 2
C:\GEOS6\pcgeos\bin\swat32.exe


    Nun sollte sich Swat über die NT-Pipe mit stubproxy verbinden, das auf der anderen Seite per TCP/IP mit dem simulierten COM-Port der DOSBox "redet". Wichtig ist dazu, dass der "Communication Mode" per "GEOS Setup" auf "Local (NT Native)" gestellt ist. Wenn man vorher schon mal mit der Zwei-Fenster-Lösung debuggt hat, sollte das sowieso schon der Fall sein...

    Im Fenster von stubproxy sollte im Erfolgsfall "ConnectConnect successConnect -1" stehen.

    Das stubproxy-Tool ist noch experimentell und man sollte es am besten nach jeder Session von Hand beenden. Letzten Endes ist sowieso die Idee, swat direkt die Möglichkeit zu geben, per TCP/IP mit dem simulierten Port der DOSBox zu sprechen.

    ciao marcus

    Hallo Wilfried

    Ich hate heute gerade mein erstes Erfolgserlebnis. Mein GeoLadder konnte lauffähig unter dem neuen SDK mit Watcom kompiliert werden ;) Yipiie!

    Bin aber unter Linux und nicht Windows unterwegs. Soll jetzt nicht heissen, dass Du Windows aufgeben sollst.

    Gruss
    Andreas

    Hallo Marcus,

    deine Tipps zum Debuggen mit dem Target in der DOSBox würden mir sicher helfen, wenn ich wüsste, wie ich grundsätzlich anders als bisher vorgehen muss.
    Bisher hab ich (unter WindowsXP ohne DOSBox) in der gsdk-shell den Debugger mit swat-ec aufgerufen:

    @echo off
    rem IMPORTANT:
    rem THIS SCRIPT MUST BE CALLED FROM THE GSDK-SHELL !!!
    rem CHANGE THE ENVIRONMENT VARIABLES TO REFLECT YOUR OWN SETUP !!!

    rem Setup script environment variables.
    set TRGT_DIR=D:\Target\BBXEC

    rem Start the Error Checking target of Breadbox Ensemble.
    echo Starting Target Breadbox Ensamble (Error Checking Version) ...
    start "Target BBX EC" /normal /d "%TRGT_DIR%" %TRGT_DIR%\swat.exe /n:f /s loaderec.exe /log %1 %2 %3 %4

    rem Remove script environment variables.
    set TRGT_DIR=

    rem Start the SWAT.
    echo Starting SWAT ...
    start "Swat BBX" /normal swat

    Daraufhin öffnen sich das Swat-Fenster und auch (noch klein) ein Fenster für das Target ("starting vdd")
    Dann gebe ich im Swat-Fenster ein: send applicationname, danach c(ontinue). Das Targetfenster vergrößert sich etwas. Jetzt muss ich einmal in das Targetfenster klicken, damit das Target vollständig startet.

    Also was muss jetzt anders laufen?

    Wilfried

    Hallo Andreas,

    was ich auf GitHub sehe, vermag ich nicht einzuordnen geschweige denn zu nutzen. Ohne eine konkrete Anleitung für "Normal-User" (Zitat Jirka Kunze) bin ich tatsächlich zuemlich hilflos.

    Wilfried

    Zitat von Wilfried

    rem Start the Error Checking target of Breadbox Ensemble.
    echo Starting Target Breadbox Ensamble (Error Checking Version) ...
    start "Target BBX EC" /normal /d "%TRGT_DIR%" %TRGT_DIR%\swat.exe /n:f /s loaderec.exe /log %1 %2 %3 %4

    Das hier ist die Stelle, die sich am meisten ändert, da du jetzt nicht mehr den "Swat-Stub" direkt in Windows startest (also den Teil, der das GEOS-Target unter der Kontrolle von swat ausführt). Stattdessen würdest du an dieser Stelle die DOSBox mit dem Target drin öffnen, ins "ENSEMBLE"-Verzeichnis wechseln und dort den Stub starten. Das kannst du z.B. mit dem Batchfile "ss.bat" machen, das fast genau die Kommandozeile oben enthält. Der Trick ist eben, dass man das jetzt in der DOSBox tut und sich nicht mehr auf den DOS-Emulator von Windows verlässt.

    Eine Möglichkeit, um das mal auszuprobieren, wäre eine Variante deines Batchfiles, die anstelle der obigen Kommandos folgendes tut:

    • Zuerst stubproxy starten, damit das Program bereit steht, wenn die DOSBox sich verbinden möchte
    • Ein "pause" einbauen, so dass du erst mal von Hand die DOSBox aufrufen und in Ruhe den "Stub" starten kannst. Später kann man das auch durch einen direkten Aufruf der DOSBox mit einer Konfigurationsdatei machen, in der gleich per Autostart der Stub aufgerufen wird.


    Evtl. ist es nötig, auch die swat32-Version aus dem neuen SDK aufzurufen, da ich nicht ganz sicher bin, wie kompatibel die verschiedenen swat-Versionen untereinander sind.

    ciao marcus

    Hallo Marcus,

    es ist wohl besser (für mich;-)), wenn wir noch ein Stück vorher ansetzen, denn schon das Compilieren geht nicht. Mkmf scheitert schon an der ersten .goc-Datei, weil die zugehörige .cpp-Datei nicht gefunden wird.
    Kannst du mir dabei auch helfen?

    Wilfried

    Zitat von Wilfried


    es ist wohl besser (für mich;-)), wenn wir noch ein Stück vorher ansetzen, denn schon das Compilieren geht nicht. Mkmf scheitert schon an der ersten .goc-Datei, weil die zugehörige .cpp-Datei nicht gefunden wird.
    Kannst du mir dabei auch helfen?

    Kannst du mal ein paar Details zu deiner Konfiguration posten, also z.B. in welchem Verzeichnis dein SDK liegt, wo deine Sourcen liegen und was für Environment-Variablen du so gesetzt hast? Dann können wir ja mal probieren, das etwas genauer einzukreisen...

    ciao marcus

    Bisher hatte ja alles gut funktioniert. Erst nachdem ich meinen Ordner PCGEOS (auf D) gegen den aus pcgeos-sdk-win32-6.0.0.54 ausgetauscht hatte, ging es nicht mehr. Meine Quelldateien liegen in D:\Source\PCGEOS\Yourname\Appl

    Meine gsdk-shell.cmd:
    @echo off
    rem IMPORTANT:
    rem CHANGE THE ENVIRONMENT VARIABLES TO REFLECT YOUR OWN SETUP !!!

    rem Remove unneeded Windows environment variables.
    FOR /f "delims==" %%e IN ('set^|findstr /b /i /v "SystemRoot ProgramFiles"') DO (
    set %%e=
    )

    rem Setup script environment variables.
    set GSDK_DRV=D:

    rem Setup SDK environment variables.
    set GOC_COMPILER_DIR=%GSDK_DRV%\BCC
    set PERL_DIR=%GSDK_DRV%\PERL
    set ROOT_DIR=%GSDK_DRV%\PCGEOS
    set LOCAL_ROOT=%GSDK_DRV%\Source\PCGEOS\YourName\appl\d3
    rem Setup search path and temp environment variables.
    set PATH=%GSDK_DRV%;%GOC_COMPILER_DIR%\BIN;%PERL_DIR%\BIN;%ROOT_DIR%\BIN;%SYSTEMROOT%\SYSTEM32
    set TEMP=%GSDK_DRV%\Temp
    set TMP=%TEMP%

    rem Needed for Borland C++ Compiler before version 5.0 for long names.
    set CCOM=@DOSFRONT BCC
    set CPP=CPP32.EXE

    rem Change into local root.
    %GSDK_DRV%
    cd %LOCAL_ROOT%

    rem Remove script environment variables.
    set PERL_DIR=
    set GSDK_DRV=

    rem Start a new CMD to to stay open with this environment.
    start "GEOS-SDK Shell" cmd.exe /k "set PATHEXT=&&set COMSPEC="

    Mein BCC-Ordner liegt ebenfalls in D:.
    Das angehängte Bildschirmfoto zeigt den Verlauf nach Eingabe von mkmf. Alle nicht zum Projekt D3 gehörigen Dateien (einschl. dependencies.mk waren vorher gelöscht.

    Wilfried

    Zitat von Jirka Kunze

    Hallo Wilfried,
    ich vermute du meinst das SDK v. 6.0.0.54 von der bluewaysw Seite. Ich habe das gerade mal auf meinen 'Notfall Windows Rechner' und da funktioniert das mkmf wie gewohnt. BCC 5 ist auf diesem Rechner nicht installiert.
    Jirka

    Zitat von Jirka Kunze

    Hallo Wilfried,
    ich vermute du meinst das SDK v. 6.0.0.54 von der bluewaysw Seite. Ich habe das gerade mal auf meinen 'Notfall Windows Rechner' und da funktioniert das mkmf wie gewohnt. BCC 5 ist auf diesem Rechner nicht installiert.
    Jirka

    Schön das das soch schnell gegangen ist und Du somit das fgertige Compilat schon hast. Da das Geos SDK ja jetzt völlig frei verfügbar ist, frei cverteilt werden darf, an jeden der es haben will, wäre es echt shcön wenn Du hier mal aufzeigen würdest in welchem Ordner das SDK liegen muss, danit die Übersetzung so reibungslos funktioniert. Du hast ja demnach nun auch nicht Stunden Deiner wertvollen Freizeit da rein investiert und die Übersetzung hinbekommen, wir würden das auch gerne. Ich arbeite unter Windows.

    Und BCC55 ist ein ebenso frei verfügbarer Compiler, den sich jeder interessierte kostenlos runter laden darf wie GCC++ oder Watcom. Sollte demnach also erlaibt sein auch mit diesem Compiler zu übersetzen. Es genügt aber auch das Skript das mit Watcom zum Erfolg führt oder mit Gcc++

    Es funktioniert wie gewohnt hört sich nämlich für mich so an als ob der compiliervorgang ganz ganz simepl zu machen wäre, wenn man nur das SED im richigen Pfad stehen hat und mkmf danach vom richtigen Pfad aus aufruft.

    Wie aber lauten die richtigen Pfade:


    - Unter Windows und

    - Unter Linux (Da nutze ich Konoppix 7.4)

    Hallo Wilfried, ich versuch Dein Problem gerade hier nochmal nachzustellen, verwende hier aber BC5, da ich auf Windows 64bit arbeite und kein alternaive zum Testen habe. Leider sehe das Problem wie im Screen-Shot bei mir nicht, teste allerdings auch mit einem anderen Geode/App-Projekt. Kannst Du mir D3 ggf. mal als Source-Code per E-Mail schicken? Ansonsten wäre interessant man den Inhalt deine D3-Ordners vor dem Aufruf von mkmf zu sehen. Interessant ggf. auch der Inhalt des TMP-Files mal zu sehen, wenn es nach dem Fehler noch rumliegt. Viele Grüße, Falk

    2 Mal editiert, zuletzt von frehwagen (24. Februar 2019 um 15:32)

    Hallo Falk,

    das im Screenshot gezeigte Verhalten ist nicht abhängig vom zu compilierenden Objekt. Ich hab*s mit verschiedenen Original-Samples aus dem Ordner PCGEOS/Appl/SDK_C getestet: Überall das gleiche (Fehler-)Resultat.

    Nochmal zusammengefasst, wie ich vorgegangen bin:

    - Download pcgeos-sdk-win32-6.0.0.54
    - PCGEOS_Verzeichnis gegen mein bisheriges (auf D:) getauscht
    - Ein Sample in mein Source-Verzeichnis kopiert (hier: TicTac)
    - gsdk-shell.cmd mit angepasstem Pfad ins TicTac-Verzeichnis kopiert
    - gsdk-shell gestartet, mkmf eingegben

    Den Ergebnis-Screenshot hab ich ins TicTac-Verzeichnis kopiert (TicTac-Verzeichnis siehe Anlage).

    Mein bisheriges NT_SDK hat problemlos funktioniert (hast du ja in Syhra gesehen), alle zugehörigen Teile (PCGEOS, BCC, Perl, Source/PCGEOS/YourName/Appl) liegen auf D:. Eigentlich wollte ich nur sehen, ob man mit dem neueren SDK System-Bibliotheken (z.B. Ruler) übersetzen kann, ich würde da nämlich gern mal etwas ausprobieren, mit meinem bisherigen SDK ist das ja nicht möglich (wie in Syhra auch gesehen). Ach ja, nochmal als Ergänzung: Ich arbeite unter Windows XP (32 Bit).

    Gruß

    Wilfried

    Hi Wilfried, ich habe eine WinXP VM wiederbelebt und konnte dort in einem neuen Setup Dein Problem nachvollziehen :) Grund ist zunächst, das GOC.EXE sich nicht ausführen läßt (welches von makedpnd intern aufgerufen wird). Warum das so ist, muß ich jetzt noch herausfinden. Du kannst bis dahin gern die GOC.EXE aus Deinem alten Setup verwenden um das neue SDK weiter zu probeiren, die neue GOC.EXE fügt ausschließlich BC5-Support hinzu.

    Hallo Jirka,

    Zitat von Jirka Kunze

    Hallo Wilfried,
    ich vermute du meinst das SDK v. 6.0.0.54 von der bluewaysw Seite. Ich habe das gerade mal auf meinen 'Notfall Windows Rechner' und da funktioniert das mkmf wie gewohnt. BCC 5 ist auf diesem Rechner nicht installiert.
    Jirka


    hast du auch pmake laufen lassen?

    Wilfried

    Hallo Falk,

    mkmf und pmake laufen jetzt komplett durch :P .
    Die Umgebungsvariable CPP muss auf CPP32.EXE gesetzt sein (wie du ja schon vorher empfohlen hattest), nur CCP.EXE verursacht den Abbruch von mkmf, weil z.B. appui.i und eine Temp-Datei nicht gefunden werden. Das tritt immer dann auf, wenn eine asm-Datei dabei ist.

    Das Compilieren von System-Bibliotheken klappt noch nicht. Ich hab*s mit Ruler und GrObj versucht. Die auftretenden Fehlermeldungen (in mkmf) gleichen sich alle. Das mkmf-Resultat habe ich angehängt.

    Auf jeden Fall sind wir (du natürlich) einen guten Schritt weiter :) .

    Wilfried