Aktuelles SDK

Anfänger

Dienstag, 22. Januar 2019, 19:47

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:

	Quellcode
1	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:

	Quellcode
1 2 3	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

Zum Seitenanfang

bolle732

Fortgeschrittener

Beiträge: 280

22

Mittwoch, 6. Februar 2019, 16:12

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

Zum Seitenanfang

Wilfried

Fortgeschrittener

Beiträge: 266

23

Mittwoch, 6. Februar 2019, 19:04

Hallo Andreas,

gratuliere!

Du meinst aber wahrscheinlich nicht die Version pcgeos-sdk-win32-6.0.0.54 oder?

Wilfried

Zum Seitenanfang

bolle732

Fortgeschrittener

Beiträge: 280

24

Donnerstag, 7. Februar 2019, 10:10

Hallo Wilfried

Habe persönlich Windows aufgegeben. Darum habe ich das SDK auf Github verwendet. Dieses sollte aber auch unter Windows funktionieren.

Gruss
Andreas

Zum Seitenanfang

Wilfried

Fortgeschrittener

Beiträge: 266

25

Donnerstag, 7. Februar 2019, 11:34

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

Zum Seitenanfang

Wilfried

Fortgeschrittener

Beiträge: 266

26

Donnerstag, 7. Februar 2019, 11:41

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

Zum Seitenanfang

mgroeber

Anfänger

Beiträge: 33

27

Samstag, 9. Februar 2019, 09:36

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

Zum Seitenanfang

Wilfried

Fortgeschrittener

Beiträge: 266

28

Samstag, 9. Februar 2019, 10:58

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

Zum Seitenanfang

mgroeber

Anfänger

Beiträge: 33

29

Samstag, 9. Februar 2019, 11:22

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

Zum Seitenanfang

Wilfried

Fortgeschrittener

Beiträge: 266

30

Samstag, 9. Februar 2019, 16:22

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