RunCPM compile via DJGPP auf DOS/Win9x klappt nicht :(

    ähem, Dir ist aber schon klar, daß zumindest die von Dir abgebildeten Fehlermeldungen nix mit make zu tun haben ... ?

    Zitat von Tux

    ähem, Dir ist aber schon klar, daß zumindest die von Dir abgebildeten Fehlermeldungen nix mit make zu tun haben ... ?

    klar! dass sind undefinierte Variablen vom Sourcecode, die zum ersten mal angesprochen werden ohne vorher im Sourcecode benutzt zu werden :( (denk ich mal)....

    aber mit dem neuesten make mak43b.zip gibt es anstatt dieser Meldungen gleich ein

    rmvfromfree: memory fouled
    sigabrt

    aehnlich wie unter
    https://usenetarchives.com/vie…s.msdos.djgpp&g=22843&p=0

    djGPP??

    Das braucht man um eine originale, unmodifizierte Quake Source Distri zu kompilieren.


    Dir ist klar, dass der DJGPP nur auf einem echten DOS Rechner mit DPMI richtig funktioniert?

    Unter DOS-Emu, Virtual DOS und DOS-Box läuft das Teil nicht sauber.


    Muss es denn der DJGPP sein?

    Zitat von guidol

    klar! dass sind undefinierte Variablen vom Sourcecode, die zum ersten mal angesprochen werden ohne vorher im Sourcecode benutzt zu werden :( (denk ich mal)....

    Nein. :neinnein:

    Das sind undefinierte Variablen, weil der Sourcecode fehlerhaft ist. :fp:

    Schlampigkeit des RunCPM-Schöpfers.

    Vergleiche "abstract.h" mit "abstraction_posix.h" (in Bezug auf die Fehlermeldungen).


    <Läster-Modus>

    Wer lesen kann, ist klar im Vorteil.

    </Läster-Modus>


    Sobald Du die Fehlermeldungen abgestellt hast, läuft das Kompilieren problemlos durch.

    Ich habe einfach die fehlenden Definitionen aus abstraction_posix.h nach abstract.h hineinkopiert.


    Ich habe es unter FreeDOS, mit einer (ur)alten Installation von DJGPP 2.03 (weil ich die gerade zur Hand hatte), auf Anhieb geschafft

    (und FreeDOS war sogar "nur" virtualisiert, unter PCem).

    Da Du Dich ja so sehr für make interessierst: es war make 3.79.1.


    Ich bin mir aber ziemlich sicher, daß es unter neueren Versionen auch klappt. :razz:

    Lustig finde ich die Aussage im GIThub:


    " RunCPM is an application which can execute vintage CP/M 8 bits programs on many modern platforms, like Windows, Mac OS X, Linux, FreeBSD, MS-DOS, Arduino DUE and variants, like the Teensy or ESP32 "



    Anscheinend ist MS-DOS eine "moderne" Plattform ...

    Dann habe ich doch richtig gelesen - dachte ich, weil es um undeklarierte/undefinierte Variablen ging.

    Abstellen konnte ich die auf Anhieb nicht, weil
    - ich mich eigentlich garnicht mit C-Programmierung auskenne (eher BASIC und PHP oder Shell)
    - mein DOS-Fenster immer bei den Fehlermeldungen durchscrollt und ich nicht alle Fehler sah
    (und die Umleitung per >error.txt nicht klappte)

    Die abstract.h ist laut ihm wohl bei den Updates zu kurz gekommen - hatte ich schon eine .posix Dtaei, bei der was fehlte. Das habe ich dann mit ihm zusammen hinbekommen und man konnte auch mit aelteren Linux-Versionen wieder sauber kompilieren.


    Ich kann mit die Unterschiede zu den Dateien selbst mal ansehen, allerdings weissich dann nicht ob ich so erfolgreich die Unterschiede finde.

    Deshalb wuerde ich Dich bitten, Deine neue abstract.h hier einzustellen oder mir zukommen zu lassen.
    Ich wuerde dann auch dafuer sorgen, dass es sauber zu ihmins Github kommt, damit alle wieder sauber eine DOS-Version erstellen/kompilieren koennen.

    Auch der "schlampige" (wohl eher nachlaessige) RunCPM-Schoepfer ist neugierig was er vergessen hat.
    Ich persoenlich sehe es ihm in soweit nach, da die Software auf vielen Plattformen laeuft (auch Microcontroller), so dass man auch mal vergessen kann fuer jede Plattform die Dateien anzupassen.

    Vielen Dank fuer Deine Muehen!


    Ich habe es versucht zu loesen (auch mit djdev203.zip und mak3791b.zip) aber ich bin wohl zu wenig C-Entwickler ;(

    Die hauptsaechliche Fehlermeldung geht immer noch um signdedness und "HostnameToFCB".

    Bitte stelle Deine Abtract.h ein - dann kann auch ich versuchen es zu verstehen - ueber ein compare im Editor.

    Zitat von Tux

    bitteschön.

    Die Datei muß natürlich umbenannt werden in abstract.h, die Endung *.h scheint hier nicht erlaubt zu sein.

    Vielen herzlichen Dank :)

    Ich glaube, da war ich grundsaetzlich in der richtigen Rchtung unterwegs - denn nachdem ich Deine abstract.h genutzt habe, hatte ich auch einige Warnings die ich vorher schon hatte (nachdem ich an der abstract.h "gebastelt" hatte).


    Da bin ich auf die Idee gekommen - weil Du und der RunCPM-Schoepfer davon geschrieben habt, dass ihr alte Installtionen von DGJPP genutzt habt bzw. bei dem RunCPM-Schoepfer es schon lange her ist - mal einige aeltere DGJPP-Binaerpakete zu nehmen.


    Bei make konnte ich auf bis zu mak421b.zip "rauf", aber beim GCC musste ich bis auf den gcc2952b.zip runter.
    Denn das von Dir genannte Binaerpakete fuer make ging auf das Jahr 2002 zurueck.


    Nach einigen Versuchen hatte ich dann meine Kombination der Pakete, mit denen sich
    - auch nach Neuinstallation von DJGPP - die RunCPM.exe verifizierbar wieder erstellen lassen konnte :)

    Ich haenge mein Vorgehen mal als "Code" an und ein Bild des gestarteten RunCPM.

    BTW: bei mir hat dieser RunCPM das "Problem" dass er per "DIR" nicht alle Dateien aus dem Pfad anzeigt, aber diese aufrufen kann - wie z.B. die MBASIC.COM



    Tux
    Ich bin jetzt mal einen anderen Weg gegangen und habe RunCPM v4.8 - in der 32Bit compilierten version via TDM-GCC-32) auf dem 16Bit DOS (Win98SE, FreeDOS 1.3 und DOS-Part von Windows Millenium) so zum laufen gebracht, wie die teilweise (siehe oben im Thread) funkionierende v4.4 die mit DJGPP compiliert war.


    D.h. wenn man DIR aufruft, kommt nicht die komplete Anzeige der Files, aber aufrufen kann man die Programme.


    Unter purem DOS habe ich zum starten den HX DOS DPMI32 Extender v2.17 genommen.

    (Der will von WinXPSP3 die msvcrt.dll und die crtdll.dll - natuerlich 32bit)


    oder in der Win98SE DOS-Eingabeaufforderung kann man die 32bit Version von RunCPM starten, wenn man in Windows 98SE die Extension KernelEx Core installiert und dies in den Eigenschaften vom Programm (rechte Maustaste) die KernelEx Kernel-Erweiterungen zuweist.


    Die Information habe ich auch bei meiner Fehlermeldung auf GitHub bei RunCPM nachgetragen


    Ach ja - damit die 32bit Version von RunCPM ueberhaupt einige Files bei DIR anzeigt braucht es noch den

    DOS Long Filename Support von DOSLFN


    Wer Ideen hat, warum das selbe 32bit RunCPM-binary unter Win10 oder WinXPSP3 die Files alle per DIR anzeigt und dann unter Win98SE oder DOS mit Extender nicht mehr darf sich gerne melden :)


    Einmal editiert, zuletzt von guidol ()

    ... so etwas habe ich in der Regel, wenn die Terminaleinstellungen zum Zeilenende nicht passen.

    Kann es sein, dass da CR/LF unterschiedlich in den unterschiedlichen Windows Konsolen unterschiedlich verstanden werden?

    Schreibt er die Zeilen eventuell übereinander, weil nur ein LF an Ende ist?

    ich glaube man kann die Windows-Konsolen mit einem IOCTL Aufruf auf "roh" oder "gekocht" einstellen - vielleicht sind da die Defaults unterschiedlich.


    [Das ist ja eine alte Crux: Macintosh(CR)/Unix(LF)/DOS(CR,LF) -- alle hatten da ihre eigenen Vorstellungen, wobei ich da mal für DOS sprechen muss, da CR+LF eigentlich am logischsten ist: CR fährt den Schreibwagen (Cursor) zurück nach links und LF dreht die Walze (Cursor), eine Zeile weiter. Bei Unix kann man da immerhin im Binärmodus mit separaten "\r\n" auch etwas ähnliches erreichen (z.B. zum Überschreiben einer Zeile für fortlaufende xx% Displays etc.]

    Ich kann mich erinnern, dass ich mal of einem DeskJet 500 eine Mac Textdatei gedruckt habe. Der hat sich exakt an den Input gehalten und nur CR gemacht. Das war ne riesen Sauerei auf der EINEN Zeile, die sich eigentlich über mehrere Seiten hätte erstrecken sollen.

    Vorteil: seit dem weiß ich, welches System was als Zeilenumbruch verwendet. :fp:

    Das Genie beherrscht das Chaos

    Fun-Fakt (Fleissaufgabe meinerseits und meiner Internetleitung und Festplatte) fuer heute:


    Ein per Visual Studio 2019 kompiliertes RunCPM v4.8 32bit laest sich in Win98SE auch starten per KerneEx (4.5.2016) ABER erzeugt trotz anderem Source-/Quell-Code die selbe falsche DIRrectory-Ausgabe wie die Version von DJGPP 16bit oder TDM-GCC 32Bit.


    Martin Hepperle Ich wuesste fuer die DOS-Eingabeaufforderung keine Alternative oder wie man da Terminal-Einstellungen bezueglich der Ausgabe macht (ausser Font, Schiftgroesse und Farben).


    Ab der Eingabeaufforderung von WinXP klappt die Ausgabe (ok, die ist gleich 32bit), aber drunter (Win98, DOS, FreeDOS, 4DOS) klappt es nicht - strange :(


    BTW: das 32Bit RunCPM das per Visual Studio 2019 kompiliert wurde laesst sich nicht per HX DOS Extender starten :(

    PS: was TDM-GCC in einem 75MB Download hinbekommt hinterlaesst beim Visual Studio gleich einen 6GB Fussabdruck auf der Platte.
    Nebenbei ist das kompilierte Binary mit 1.7MB 16x groesser als das 110Kb binary aus dem TDM-GCC-32 :(


    Beim gcc von Linux kommen auch nur 110-120Kb raus :)

    Ich denke, viele (alle?) der verfügbaren UNIX/LINUX basierten Compiler machen in ihren I/O libraries keine Übersetzung der Zeilenenden.


    Es kann gut sein, dass die neueren Windows Versionen ab XP so intelligent sind, dass sie das im Default-Modus selbst tun, wenn Text ausgegeben wird. Von WIndows 98 zu 2000 hat man ja die NT Consolenfunktionen übernommen und damit die Console gründlich umgekrempelt.


    Du kannst auch in der Dokumentation zur jeweiligen C-Compiler Library nachsehen, ob es beim "fopen()" (falls das verwendet wird, um die Console zu öffnen) ein einfaches "w" verwendet wird. Falls es da keine Option "wt" oder ähnliche (für "Text" Modus) gibt, müsste man in die Ausgabeschicht eine Übersetzung einbauen.

    Eigentlich sollte das ein Compiler, der behauptet, Programme für Windows/DOS erzeugen zu können aber mitbringen.


    Wenn Du die Ausgabe des CP/M Emulators in eine Datei umleiten kannst, vielleicht mal die HEX Codes der Zeilenenden ansehen.


    In der Console-Applikation von WIndows selbst kann man das wohl nicht umstellen. Eventuell mal ANSI.SYS laden, vielleicht macht der das nebenbei auch.


    [Die sauberste Art ist, im C-Programm eine Variable "LineTerminator" zu definieren und diese dann mit "\n", \r" oder "\r\n" zu besetzen, je nach System. Diese dann an jede Ausgabe anhängen.

    Modernere Systeme wie z.B. Java haben dazu vordefinierte Konstanten, auch für Pfadtrennzeichen etc., die je nach System automatisch gesetzt werden.]

    Habe auch nochmal ein kleines Testprogramm geschrieben, das Du ggf. auf den unterschiedlichen Systemen laufen lassen kannst. Theoretisch sollte die Ausgabe identisch sein.


    Für neuere Windows Versionen gibt es auch "Ersatz-Konsolen", wie z.B. https://conemu.github.io/, Ob es so was für Win16 gibt, weiß ich leider nicht.



    Ausgabe unter windos 7:

    Martin Hepperle

    Ich glaube da nicht an ein CR/LF Problem.

    Ich habe mal eine RunCPM mit Debug-Output ins File compiliert.


    Und wenn man unter Win10 und unter Win98SE die selben DIR-Befehle startet, wird da schon viel weniger Output erzeugt.

    Laut Autor sollte es an den Funktionen "FindFirst" und "FindNext" bei der Filesuche sein,

    aber mit dem gleichen Binary (nur eben unter Win98SE mit 32bit Extender) wird es wohl nicht gleich verarbeitet :(

    Der Emulator laeuft ja eigentlich mit dem selben Binary unter WinXP oder Win10.


    Aber ich glaube fuer mich hat es sich jetzt fuer DOS/Win98SE erledigt, da seit der neuen

    RunCPM v4.9 noch (also alles) an DOS Support gestrichen wurde.


    Unter pure DOS mit HX Extender laeuft weder die TDM-GCC noch die Visual Studio kompilierte Version.


    Unter Win98SE GUI Eingabeaufforderung laeuft noch die Visual Studio Version mit KernelEx,

    allerdings immer noch mit dem Fehler bei der DIR-Ausgabe.


    Somit streiche ich - fuer mich - die Idee eines schnellen DOS-PC boot in RunCPM :(

    guidol - bin durch eine Google-Suche nach DJGPP und MS-DOS auf diesen Thread gestossen (manchmal sind die Wege des Herrn unergründlich)... mir ist aufgefallen dass hier aus dem "deleted" Zweig die GNU C 2.95.2 genommen wurde, dabei gibt es ja bspw. aus dem "current" Zweig auch eine GNU C 3.46 (gcc346b.zip). Gibt es einen bestimmten Grund, die viel ältere Version zu nutzen ?

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    heute Nacht kam mir eine "bloede" Idee in den Sinn ;)
    Warum nicht anstatt dem DJGPP den TDM-GCC fuer 16Bit nehmen?


    Im Kopf war es soo einfach. Einfach den Compile-Flag von -m32 (oder -m64) auf -m16 umstellen.


    Leider macht mir der Compiler/Source einen Strich durch die Rechnng, weil der Assembler wohl werte groesser 65535 speichern wollte und somit einen int16 ueberstieg(?)


    Leider wird die .s Datei nach dem erfolglosen Compile gleich geloescht, so kann ich nicht mal versuchen zu erkennen was da so hohe Werte reinschreiben will.

    Eigentlich dachte ich, im SOurce seien alle int Werte jeweils sauber definiert (uint8, uint16 und uint32)

    aber es wird wohl irgendwo ein int ohne Angabe genutzt (denk ich) der dann bei weniger als 32bit Umgebung nur 16bit ist und muesste vom Wert der reinpassen sollte 32bit sein :(


    Nun ja - war ein Versuch....


    Ausgabe beim compile:


    Tux  Martin Hepperle  Peter z80.eu

    Heute habe ich mir nochmal den DJGPP vorgenommen - diesmal unter Win7 auf einem Netbook ;)

    Damit habe ich es heute geschafft eine unter DOS (16Bit) lauffaehige Version zu erstellen, die diesmal das vollstaendige DIRectory anzeigt.

    (OK - die braucht CWSDPMI.EXE als Extender)


    Genutzt habe ich


    gcc1020b kennt wohl die Commandline-Option -mconsole nicht mehr.
    Alle ANSI-Ausgaben laufen ins leere trotz ANSI.SYS in der CONFIG.SYS


    Fuer den compile war also wichtig die Linker-Option -mconsole raus zu nehmen und auch die Option

    -Wno-pointer-sign im gcc compile reinzunehmen.


    Der gcc346 wohl noch die Option -mconsole - aber auch da erkennt die Console die ANSI-Ausgaben nicht (z.B bei Wordstar).


    PS: In Win7 habe ich in der Console "nur" eine englische Tastatur - aber im deutschen MS-DOS 6.22 klappt die deutsche Tastatur.....


    Anbei eine compilierte Test-version von RunCPM v4.4 und v5.7


    Empfohlen von https://www.delorie.com/djgpp/zip-picker.cgi auf
    FTP Site: http://www.delorie.com/pub/djgpp/current/


    Zitat von Peter z80.eu

    Das sieht so aus, als ob die Bildschirmausgabe nicht via DOS-Interrupts geschieht, sondern via BIOS-Interrupts.

    Hmm - im Source gibt eine "Funktion" _puts fuer "put string" - die muesste ich mir mal ansehen.

    Fuer DOS-interrupt Ausgabe habe ich au folgender Seite:

    https://nullprogram.com/blog/2014/12/09/

    im Bereich "Hello World in DOS"

    was an Source gefunden, der evtl. passen koennte.

    Muss ich Morgen mal ansehen...

    Oder hast Du noch einen Source/Link Tipp?

    Prinzipiell ist ...

    Code
    static void print(char *string)
{    asm volatile ("mov   $0x09, %%ah\n"
                   "int   $0x21\n"
                  : /* no output */
                  : "d"(string)
                  : "ah");
}

    ... gar nicht so falsch, was eine Zeichenkettenausgabe via DOS-Interrupt angeht. Diese Assembler-Inline-Notation kenne ich aber nicht (sondern eher die von Borland). Allerdings bauen viele Libraries Ihre Ausgabe alleine auf eine Zeichenausgabe eines Zeichens auf, eine Zeichenkette wird dann wie gewohnt so lange Zeichen für Zeichen ausgegeben, bis die '\0' kommt (und nicht so mit '$' am Ende).


    Ein Zeichen wird normalerweise mit AH=02h und INT 21h ausgegeben, d.h. darauf könnte man alles aufbauen.


    Siehe auch http://www.ctyme.com/intr/rb-2554.htm für die einzelne Zeichenausgabe-Funktion ...

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.