DOS-Forum

So wie versprochen etwas zur Speicherverwaltung unter DOS.

Womit man oft zu tun hat ist XMS , EMS , DOS Extendern und vielleicht manchmal VCPI und DPMI.

Alle Speichermanager dienen dazu an mehr Speicher als die 640 kB zu kommen.

Zuerst zu HIMEM.SYS:

HIMEM.SYS aktiviert das A20-Gate und bietet die XMS Funktionalitaet.
Das funktioniert grob so, dass man Speicherbereiche von ueber 1 MB sich unter die 640 kB kopieren lassen kann und andersherum. Dabei schaltet HIMEM.SYS jedesmal in den Protected Mode um den Speicher ueber 1 MB adressieren zu koennen, kopiert den Bereich und schaltet in den Real Mode zurueck.

EMM386:
So nun wirds etwas komplizierter. EMM386 schaltet in den Protected Mode und legt DOS in einen Virtual 8086 Prozess. Weiterhin implementiert es den LIM EMS Standard, mit einem 64 kB Speicherfenster bei meist $E000:0000. Das heisst in dem V86 Prozess von DOS wird ein Fenster von 64 kB aus dem Speicher jenseits der 1 MB eingeblendet. Da EMM386 im Protected Mode die Kontrolle ueber Speicher und IO Zugriffe hat, sind die physikalischen Adressen und die Adressen im V86 Modus nicht zwangslaeufig gleich. Dann macht es freien RAM zwischen 640 kB und 1 MB als Upper Memory Blocks - UMBs nutzbar. DOS selbst ist in die HMA geladen. Damit ist es moeglich TSR Programme 'hochzuladen'.

QEMM386:
QEMM386 treibt die Speicherverwaltung noch eine Stufe weiter als EMM386 von Microsoft. Da der Speichermanager als oberste Instanz im Protected Mode die volle Kontrolle ueber Zugriffsrechte und Speicherzuweisung hat, kann er noch mehr. Das erste was als sinnvoll erscheint - er kann den verfuegbaren Speicher wahlweise als XMS oder EMS anbieten, je nach Bedarf des Programms.
Nun ist es so, dass die UMBs doch sehr begrenzt sind und man oft nicht alles hochladen kann, was man gern moechte. Die DOS Programme selbst interessiert jedoch oft nur, wieviel freien Speicher sie unter der 640 kB Grenze haben und wieviel EMS / XMS sie bekommen koennen. Daher wuerde es sich anbieten mehr Speicher zwischen den 640 kB und 1 MB zu bekommen um dort nach Moeglichkeit alle TSR hinzuladen.
Wie man an dem EMS PageFrame schon sieht, ermoeglicht es der 386er Speicher beliebig in den V86 DOS Prozess zu mappen. QEMM hooked alle Bios ROM Aufrufe und kann damit zweierlei Dinge:
1. Die BIOS ROMS werden aus den 1 MB des V86 Prozesses ausgemappt und durch RAM ersetzt. Wenn eine BIOS Funktion aufgerufen wird mit einem Interrupt, mappt QEMM das BIOS ROM wieder unter die 1 MB.
In diesem Fall hat man entsprechend der Groesse des BIOS mehr UMBs.
Das ROM ist in diesem Fall nicht zwangslaeufig an der physikalischen Adresse eingemappt.
oder
2. Der EMS PageFrame wird ueber das BIOS ROM gemappt. In diesem Fall hat man 64 kB mehr UMBs. Wenn das ROM eingemapped ist, ist es an der physikalisch korrekten Adresse.

Diese Technik funktioniert nicht, wenn BIOS Funktionen direkt aufgerufen werden. Das ist aber 'schlechte' Programmierung und tritt normal nicht auf.
Als Workaround kann das Optimize Programm sowas erkennen und das Mapping in 4kB (siehe Protected Mode) thunken. Das heisst man kann diese Mapping Funktionalitaet in 4 kB Bloecken einstellen.

Weiterhin bietet ein 386er Speichermanager die Basisfunktionalitaet auch IO Zugriffe abzufangen, was von einigen Emulatoren fuer Soundkarten genutzt wird. (siehe zB GUS MegaEM)

Als Referenz kann man sich dazu die QEMM Technical Notes durchlesen.

DOS Extender:
Fuer ein Programm stellt sich nun die Frage, wie kommt man an den Speicher jenseits der 640kB. XMS und EMS ist zwar nett aber kompliziert zu handhaben, da man immer 64 kB Stuecke hat und trotzdem keinen grossen zusammenhaengenden Speicher. Da hilft es nur direkt den Protected Mode zu nehmen und linearen freien Speicher zu nutzen. Meistens irgendwo ueber der 1 MB Grenze. Was so einfach klingt ist aber nicht so trivial. Denn um mit der Hardware zu kommunizieren braucht man DOS Funktionen (zB Dateien lesen) und das versteht keinen Protected Mode. Daher gibt es fuer die Protected Mode Programme einen sogenannten DOS Extender, der die Speicherverwaltung und die Schnittstelle zu DOS gewaehrleistet.
Als bekannteste Vertreter sind Watcoms DOS4GW, PMODE/W und DOS4G zu nennen.
Das ganze laeuft so ab, dass der Extender linearen Adressraum reserviert, in den Protected Mode schaltet (oder sich mit EMM386 einigt ueber VCPI / DPMI) dort das Programm hinlaed und ausfuehrt. Alle DOS Funktionsaufrufe werden abgefangen und der DOS Extender uebernimmt deren Abarbeitung. Dabei verursacht er einen Ruecksturz in den Real Mode oder V86 Mode, ruft die DOS Funktion aus, nimmt die Daten entgegen, schaltet wieder in den Protected Mode und uebergibt die Daten an das Programm.
Das heisst letztendlich, dass der DOS Extender zwar dem Programm Speicher gibt, jedoch DOS und BIOS Funktionsaufrufe durch den Moduswechsel langsam werden.

Nette Zusammenfassung. Eine Anmerkung zu DOS Extendern.

Eigentlich unterscheidet man zwischen DPMI-Servern und -Extendern. DOS4/GW is z.B. ein Extender, der im Gegensatz zu dem DPMI-Server nicht nur die DPMI-API zur Verfügung stellt.

Deine Liste ist meiner Meinung nach nicht mehr ganz aktuell. Ich denke, dass folgende Server aktuell am meisten verwendet werden (für neue Programme):

HX-DOS (gleichzeitig Emulator für Windows-Kommandozeilenprog., http://www.japheth.de/)
CWSDPMI (DJGPP)
DOS/32A (Watcom C)


Ich persönlich verwende nur mehr den HX-Server, er ist in Entwicklung und hat nette features. Die meisten Programme rennen super mit ihm.

Ich wollte mich auch nicht diekt auf DPMI Server besiehen, da diese im weitesten Sinne wie EMM386 eine Funktionalitaet zur Verfuegung stellen, die von DOS Extendern genutzt werden kann. Bei QEMM wird zB auch QDPMI mitgeliefert.
DPMI ist zwar das modernste (da auch Paging Funktionen eingeschlossen sind) wird aber 'ungern' von den DOS Extendern verwendet.

Um Aktualitaet ging es mir auch nicht, da DOS4GW wahrscheinlich das bekannteste ist, da es von sehr vielen Spielen und auch anderen Programmen verwendet wird.
Sicherlich kann man heute gut auswaehlen, was DPMI Server betrifft, jedoch reicht fuer ein DOS Extender Plain DOS aus. Das heisst ein DPMI Server benoetigt man nur fuer die Programme, die NUR DPMI koennen.
Letztendlich braucht man DPMI Funktionalitaet fuer DOS-Spiele (fast) nie.

Das einzige was ich bisher verwendet, was DPMI benoetigt ist zB DASM (Crossassembler).

elianda hat geschrieben: Das einzige was ich bisher verwendet, was DPMI benoetigt ist zB DASM (Crossassembler).

Mitlerweile gibt es bis auf 4DOS kein Programm mehr bei mir, das nicht DPMI verwendet. Ich habe im Moment allerdings keine Zeit mehr zum Spiele spielen....

Folgende Frage möchte ich an die Experten stellen:

ich habe ein TSR geschrieben, das einen Speicherblock von DOS anfordert, diesen in eine Reale Adresse umrechnet und an einen Controller als gemeinsamer Speicherbereich gibt um darüber zu kommunizieren.

Dies funktioniert nur, solange das Programm und der Speicherblock unterhalb von 640k liegen. Wird das TSR mit Loadhigh geladen, so versagt es seinen Dienst. Auch wenn nur der angeforderte Speicherblock im UMB liegt klappt es nicht mehr. Der Controller erwartet, daß der Speicherbereich immer an der angegebenen realen Adresse liegt und nicht verschoben wird.

Was könnte der Grund für das Problem sein, der V86 Modus von EMM386?

Hmm, schwer zu sagen.

Schaue mal ob du wirklich die physikalische Adresse mit EMM386 bekommst oder nur die im Virtual 8086 Segment.

Ansonsten Include einen Speicherbereich bei EMM386, der dann freigelassen wird als reserviert fuer I/O Karten. Dann nimm fuer deinen Controlle den Speicherbereich.

Ansonsten sollte EMM386 eigentlich nicht den Speicher wild verschieben.
Vielleicht findest du irgendwo eine Doku oder auch Funktion um herauszufinden wie der Bezug physikalisch zu V8086 Adresse ist nach dem laden von QEMM. Hast Du schonmal in Ralf Browns Interruptliste geschaut ob vielleicht EMM386 eine FUnktion zum konvertieren zu physikalischen Adressen bietet?

Hmm mehr faellt mir gerade nicht ein.

Ich habe folgendes bei Microsoft gefunden:

EMM386.EXE is a device driver for 80386 and higher systems with XMS memory. EMM386.EXE uses XMS memory to create and manage EMS memory and/or XMS upper memory blocks (UMBs). EMS is available to programs through the EMS 4.0 interface; UMBs are available through the XMS interface. When providing UMBs, EMM386.EXE answers only requests to allocate or deallocate UMBs; all other XMS memory is managed by HIMEM.SYS.

Wenn ich dies richtig verstehe, werden von emm386.exe EMS und umb's im XMS, also oberhalb von 1MB angelegt. Dann könnte ich daraus nicht einfach die physikalische Adresse errechnen.

Einen Speicherbereich wie vorgeschlagen auszuschließen, könnte funktionieren, aber dies ist nicht sehr benutzerfreundlich. Der Treiber soll ja von anderen Usern auf möglichst allen PC's verwendet werden können.

Hmm, wir nutzen hier Messkarten, die das genau ueber Exclude machen.
(Include war ein Fehler, natuerlich muss man den Speicher fuer EMM386 Excluden)

I will das doch mal probieren. Dies ist wohl bei emm386.exe die Option "x=mmmm-nnnn".

Welchen Speicherbereich schließt man denn sinnvollerweise aus, ich brauche 24k? Man muß ja aufpassen, daß man einen anderweitig unbenutzten Bereich verwendet.

Fordert man diesen ausgeschlossenen Speicher dann irgendwie mit ah=48/int21 an oder addressiert man ihn direkt?

Schaue einfach vorher, welcher Speicherbereich fuer UMBs verwendet wird. Den kannst Du excluden, da dort keine andere Hardware ist. Adressieren sollte direkt gehen, da EMM386 den Speicher nicht komplett umkrempelt - in Bezug auf physikalisch vs. V8086 Adressen.