DOSferatu hat geschrieben:Hm... Ich benutze aber teilweise Wraparounds beim Programmieren. Außerdem benutze ich gelegentlich auch mal die 16 oberen Bits der Exx Register zum Retten von Werten etc. Bisher hatte ich da zwar noch keine Probleme, aber das kann Zufall sein.
Heißt das nun, wenn ich HIMEM.SYS benutze UND die 16 oberen Bits der Register EBX, EBP, ESI und EDI irgendwie benutze oder zweckentfremde, daß ich dann Probleme kriege? Dachte immer, im 16Bit-Address-Mode wäre das kein Problem, da dort ja per Standard 16-Bit-Addressing eingestellt ist und man nur mit Prefix-Byte (67h - das man ja sowieso normalerweise nicht benutzt, weil im RealMode/V86-Mode keine 32-Bit Adressierung möglich) die 32bit Adressierung einschaltet.
Also im Klartext: Kann mir irgendein Mist passieren, wenn z.B:
- HIMEM.SYS vorher von mir benutzt wurde
- Ich dann irgendwann ESI auf 12345678h gesetzt habe
- Ich mov AX,ES:[SI] mache, um von Adresse ES:5678h ein Wort nach AX holen will?
(Also im Klartext: WIrd dann etwa versucht, von Adresse ES*16+12345678h zu laden?)
Wie gesagt: Bisher hatte ich dergleichen Probleme nicht, aber hoffentlich war das nicht nur ein Zufall. Ich benutze eben auch im RealMode die 32-Bit-Register (und die zusätzlichen Segmentregister FS und GS).
ich denke nicht, dass es da Probleme geben kann. Habe ich auch so schon gemacht und keine Probleme gehabt. Wenn Du explizit sagst: mov ax, es:[si] dann sollte der Assembler/Basm auch nur si verwenden.
Wenn ich TD richtig verstehe (ich verwende seit ein paar Tagen zum ersten Mal in meinem Leben einen Debugger), dann sagt er mir auch eindeutig, dass nur si, und nicht esi zur Adressbildung verwendet wurde.
Mit db $67 schaltest Du ja auch nicht die CPU (global) in den 32bit-Mode, sondern sagst: CPU verwende für nachfolgenden Befehl ausnahmsweise die 32bit-Variante (wenn ich das alles richtig verstanden habe). Und db $67 verwendest Du ja nur, wenn Du explizit 32-bit-Adressierung, also mov ax, es:[esi] haben willst, was Du in Deinem Beispiel weder tust noch tun willst.
Ich kann mir auch kein Problem vorstellen, dass dadurch entsteht, dass himem.sys (unter bestimmten Umständen) die Segmentbeschreiber für DS und ES auf Segmente >64k einstellt. Im Normalfall werden zur Adressbildung nur die 16bit-Register verwendet, was keine Probleme gibt. 16bit-Register ist 16bit-Register und damit <64k.
Das einzige wäre, wenn man unter Dos z.B. mit mov ax,es:[esi] auf den Speicher zugriffe und davon ausginge, es gäbe immer einen Wraparound, weil Segmente
stets 64k hätten. Das geht aber im Normalfall nicht: Bei mir hängt sich immer der PC auf, wenn esi einen Wert >=64k hat. ich gehe davon aus, dass die CPU eine Exception auslöst, unter Dos aber niemand da ist, um diese zu behandeln. Es wird also niemand ein solches Programm in Umlauf bringen können, weil es sich schon beim ersten Probelauf aufhängt.
Die einzige Konstellation, bei der sich mein PC nicht aufgehängt hat, war die von mir beschriebene Situation (gebrauchter himem.sys, 386er, kein v86). Dann gab es kein Aufhängen, sondern ich konnte die Speicherstelle unter Verwendung von esi mittels eines offsets >64k auslesen. Ich habe das als Bestätigung des Gerüchts gesehen, dass himem.sys in den 4G schaltet - und zu meiner Verwunderung diesen angeschaltet läßt.
Wie gesagt, ich denke das ganze ist nicht so wild und hat keine praktischen Auswirkungen:
- Dein Wraparound erfolgt durch die Verwendung des 16bit-Registers. Die oberen Bits (16-31) bleiben unangetastet.
- Dos Programme, die mov ax, es:[esi] o.ä. verwenden und dabei davon ausgehen, die oberen 16bit würden ignoriert, wird es nicht geben.
Meine weitere Vermutung, daß himem.sys "abgeschossen" wird, wenn die Segmentbeschreiber wieder auf 64k gesetzt werden, hat sich nicht bestätigt. Offensichtlich setzt die XMS-Funktion 11 vor jedem Aufruf wieder den 4G-Mode oder es wird anderweitig die Größe der Segmente geprüft.
Damit bleibt eigentlich nur zu sagen: Flat4G/unreal ist ein von MS anerkanntes Verfahren, das auch im Zusammenspiel mit himem.sys zu funktionieren scheint.
wobo