32Bit RunCPM-CLI unter 16Bit DOS starten mit DPMILD32

JenGun Peter z80.eu  Martin Hepperle
In dem Thread zum RunCPM-compile unter DOS per DJGPP hattet ihr echt gute Ideen/Vorschlage, so dass wir damals die Version zum laufen brachten - nun koennte ich bei einer anderen Moeglichkeit auch Euer Wissen/Ideen brauchen:

Ich habe eine Moeglichkeit gefunden die 32Bit-CLI Windows-Version von RunCPM (compiled mit mingw32) auf 16Bit DOS zu starten.

Das geht ueber einen Loader (DPMILD32) von dem HX DOS Extender (aktuell v2.20)

So arbeitet dann die 32Bit Version von RunCPM auch mit dem unter DOS notwendigen NNANSI zusammen

Allerdings gibt es noch einen/einige Haken (waer ja sonst auch zu einfach/schoen) und zwar in den Datei-/File-Funktionen:

Was geht:

- laden von Programmen wie MBASIC oder Wordstar

- speichern und laden in MBASIC

- laden eines Dokuments in Wordstar

- PIP GLTEST.COM=FRAROUND.COM und starten der Kopue GLTEST.COM

Was get (leider) nicht:

- speichern in Wordstar (Disk-Full)

- DIR gibt nur "No File" aus (erkennt aber wenn man ein nicht vorhandes Laufwerk ansprechen will per BDOS-Error)

Info-Seite zur aelteren (non-Fork?) Version v2.17
dazu auch die passende Sourceforge-Seite

Zitat von JenGun

Könntest du ein ZIP-Archiv (oder Git) mit den erforderlichen Dateien (HX, RunCPM, WS) erstellen, damit man das direkt testen kann?
Die RunCPM-Version für DOS (DJGPP) funktioniert doch mit NNANSI, oder habe ich etwas übersehen?

Natuerlich stelle ich gerne ein Archiv bereit

Im angehaengtem RCPM32.ZIP sind die Verzeichnisse

- HX (um das zu "installieren" sollte \HX\BIN im PATH von DOS sein)

- RUNCPM (hier liegt die 32Bit Version als RCPM32.EXE und NNANSI.COM)

Im Verzeichnis \H\BIN ist zusaetzlich die MSVCRT.DLL von WinXPSP3 enthalten, da die zum Start vom 32Bit RunCPM angefordert wird, da der mingw32 die MSVCRT-Version ist (im Gegensatz zum neueren UCRT).

Unter dem RUNCPM-Verzeichnis liegt A: (\A\0) und dort ist auch MBASIC und B: (\B\0) beinhaltet
Wordstar CPM v4.0

Zu DJGPP/NNANSI:
Ja - die DJGPP-Version arbeitet mit NNANSI - dies tut aber fuer die ANSI-Funktionen die 32Bit-Version.

Da ist also mit NNANSI kein Problem.

ABER
Die DJGPP-Version benutzt eine aeltere/rudimentaerere Version der abstract.h mit weniger ausgefeilten File-Operationen als die ABSTRACTION.POSIX oder die ABTRACTION.VISUAL_STUDIO

Bei der 32Bi Version fuer Windows wird die ABTRACTION.VISUAL_STUDIO zum kompilieren "angezogen".

Da es fuer die DJGPP-Version eh eines DPMI-Hostes (CWSDPMI z.B.) braucht, hat es eigentlich nur Nachteile und schoen waere dann gleich die mit besserem Compiler (mingw32) und besseren/schnelleren File-Funktionen auch unter DOS 16Bit nutzen zu koennen (und spart auch verschiedene Compile-Wege).

Die hier von mir mitgelieferte MSVCRT.DLL (335KB) ist die Version 7.0.2600.5512

Das ist die letzte (die ich gefunden habe) die als Abhaengigkeit
nur die KERNEL32.DLL hat (die HX DOS ersetzt).

Alle spaeteren haben Abhaengigkeiten mit langen Dateinamen
Ausserdem laeuft die 32Bit Version damit ohne Probleme unter WinXP (auch mit ConEmu).

Zitat von JenGun

Der HX DOS-Extender hat ebenfalls einen DPMI-Host: HDPMI32.EXE ... durch die Win32-API-Emulation sind auch ein paar .DLL-Dateien (z.B. DKRNL32.DLL) notwendig:

Ja das mit den .DLLs ist mir bewusst (aus der DPMI32LD-Doku):

Zitat

5. Win32 API Emulation

During the load process some imported dlls will be "replaced"

by DPMI compatible versions. These are:

KERNEL32.DLL -> DKRNL32.DLL

ADVAPI32.DLL -> DADVAPI.DLL

USER32.DLL -> DUSER32.DLL

GDI32.DLL -> DGDI32.DLL

DDRAW.DLL -> DDDRAW.DLL

This feature allows dual-mode applications. Such apps run as normal Win32

apps in Win32 environments and will run as DPMI clients in non-Win32

environments.

Please note that some exports supplied by DKRNL32.DLL, such as

CreateProcess, LoadLibrary, FreeLibrary, GetProcAddress, GetModuleHandle

or GetModuleFileName are just thin wrappers around the loader's int 21h

API. This means that DKRNL32 can only work in conjunction with DPMILD32,

other PE loaders won't do the job.

Alles anzeigen

Es waere ja auch ein Weg vom DJGPP wegzukommen, der so aussieht als wuerde er nicht mehr weiterentwickelt.

Zitat von JenGun

Ist die Win32-Version von RunCPM mit dem HX DOS-Extender wirklich schneller oder "besser": Benchmark mit FRACTAL.BAS?

Ich glaube an der Rechnenleistung wie beim FRACTAL.BAS wird sich nichts tun.

Aber beim File-Zugriff sollte es beser werden.

Die alte abtract.h hat 2KB und die abstraction_vstuido.h hat 12KB

Interressant - was mir damals bei der DJGPP-Version auch aufgefallen ist als wir zu weige Dateien angezeigt bekommen haben - wenn man DOSLFN laedt, dann bekommt man bei DIR alle Dateien gelistet, die die 8.3er Konvention voll ausnutzen.

Also z.B. die MBAS529P.COM oder auch eine README12.TXT

Auch MBASIC zeigt mit FILES - wenn DOSLFN geladen ist - alle File an, wenn die volle 8.3 Zeichen haben.

Wenn DOSLFN geladen ist, kann Wordstar sogar dann speichern unter dem kurzen Namen (zeigt diesen aber nicht vorher beim Laden in der File-Auflistung).

Ein PIP README12.TXT=READ.ME geht und die README12.TXT erscheint in der Wordstar-Fileliste.

Anbei die alte abtract.h (letzte Version die ich fuer RunCPM v6.1 genutzt habe) und dabei auch zum Vergleich die abstraction_vstudio.h

ich habe auch schon versucht die Ausgabe wie bei der DJGPP Version mit fputc/putchar abzuaendern - wurde zwar compiliert brig aber nicht in der Ausgabe mehr (damals hatten wir es wegen der Interruptausgabe unter DOS und conio gemacht).

Zitat von JenGun

ob es dadurch unter DOS überhaupt einen spürbaren Geschwindigkeit-Unterschied zu den entsprechenden DJGPP-Funktionen gibt, müsste man gründlich testen ...

Ich sehe jedenfalls beim Start/Laden von MBASIC und Wordstar, dass diese bei der 32Bit Version per DPMILD32 fast instant geladen sind und es bei der DJGPP-Version doch eine merkbare Verzoegerung spuerbar ist

Nichtsdestotrotz habe ich mir DJGPP und desen RunCPM-Version nochmal angesehen und eine nonLUA-Version GL20240106 compiliert, die beim compilieren keine Fehlermeldungen geschmissen hat
Ich weiss schon garnicht mehr mit welchen Tricks ich LUA in der vorheringen GL20231231 drin hatte.
Mit einer 32Bit Version unter DOS koennte man auch dieses tricksen umgehen...wobei wer braucht wirklich LUA?

Zitat von JenGun

Bitte mal die angehängte abstract.h für DJGPP testen: dort werden die Funktionen aus abstraction_posix.h verwendet ...

VIELEN DANK fuer diese abstract.h, denn ich hatte nicht getestet, dass meine heutige Version auch nur die Dateien mit den vollen 8.3 Dateinamen anzeigt.

Mit Deiner abstract.h werden jetzt alle Dateien angezeigt und sind nutzbar - nur leider aendert sich nichts (bei mir hier) an der File-Ggeschwindigkeit.

Anbei die .EXE - die mit Deinem abtract.h compiliert wurde - als .ZIP

[EDIT] Ich hatte noch beim INFO-Command gesehen, dass in Deiner abstract.h das HostOS aud 0x02 was zur Anzeige POSIX anstatt DOS fuehrt.
Dies habe ich nun in 0x03 fuer DOS geaendert.
Zusaetzlich klappt nun wieder LUA, also haben wir eine Version die alle Dateien mit Deiner abstract.h anzeigt und bei der es LUA gibt
Die .EXE ist nun auch ordentlich groesser geworden...

Zitat von JenGun

guidol Bitte mal in abstraction_posix.h folgende Änderungen vornehmen und mit dem HX DOS-Extender testen:

Ich habe mal eingetragen und compiliert, aber es aendert sich nichts.

Aber ich denke da hast Du Dich fuer mingw in die falsche Datei "vertieft".

Meines Wissens wird mingw(32) von der main.c als WIN32 erkannt:

#ifdef _WIN32
#include "abstraction_vstudio.h"
#else
#include "abstraction_posix.h"
#endif

Weil auch das INFO-Command gibt aus: "running on Windows) - wohl wegen dem HostOS

Ich nutze ja:

mingw32-make mingw clean

mingw32-make -f Makefile.mingw

Die gleich Stelle in der abstraction.vstudio konnte ich per "find" nicht finden

Interessant an der Stelle:
Unter echten Windows geht LUAINFO und unter DPMILD32 kommt nur eine leere Ausgabe.
Dass LUA drin ist sieht man beim Bootscreen an der LUA scripting Version

Zitat von JenGun

Unter DJGPP gibt es auch strip: nach strip RCP61JG2.EXE hat die Datei "nur" noch 576512 Bytes ...

Info (auch fuer mich) von hier:

Zitat

Compile your code with -s to strip debugging information.