Sie sind nicht angemeldet.

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.

21

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

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

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

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

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

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

27

Samstag, 9. Februar 2019, 09:36

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

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

29

Samstag, 9. Februar 2019, 11:22


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

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

31

Samstag, 9. Februar 2019, 16:57

Anhang vergessen:-(
»Wilfried« hat folgende Datei angehängt:
  • mkmf.jpg (72,05 kB - 540 mal heruntergeladen - zuletzt: Heute, 02:00)

32

Samstag, 23. Februar 2019, 15:58

Also Marcus, wenn dir dazu auch nichts einfällt, dann lass ich mal die Finger davon:-(.

Wilfried

33

Sonntag, 24. Februar 2019, 12:24

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

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)

34

Sonntag, 24. Februar 2019, 14:13

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

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »frehwagen« (24. Februar 2019, 15:32)


35

Sonntag, 24. Februar 2019, 18:10

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
»Wilfried« hat folgende Datei angehängt:
  • TicTac.zip (37,01 kB - 503 mal heruntergeladen - zuletzt: Heute, 04:08)

36

Montag, 25. Februar 2019, 19:33

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.

37

Dienstag, 26. Februar 2019, 10:17

Hallo Falk,

mkmf läuft jetzt durch, pmake allerdings noch nicht (siehe Anhang).
»Wilfried« hat folgende Datei angehängt:
  • pmake.jpg (146,47 kB - 496 mal heruntergeladen - zuletzt: Gestern, 16:10)

38

Freitag, 1. März 2019, 10:47

Hallo Jirka,
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

39

Samstag, 2. März 2019, 20:11

Hallo Wilfried,
ich habe eine neue SDK-Version 6.0.0.56 hochgeladen. Sie ist hier verfügbar:

http://blog.bluewaysw.de/packages-for-download

Diese Update enthält sowohl eine für WinXP nutzbar GOC.EXE als auch die vermisste BORLAND.OBJ. Dies zusammen sollte nun endlich Dein Projekt durchcompilieren.

Viele Grüße, Falk

40

Sonntag, 3. März 2019, 12:10

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
»Wilfried« hat folgende Datei angehängt:
  • rulermkmf.jpg (107,31 kB - 475 mal heruntergeladen - zuletzt: Gestern, 09:24)

Ähnliche Themen

Thema bewerten