Neuer User: DOSferatu

Stellt Euch der DOS-Forum Community vor!
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Neuer User: DOSferatu

Beitrag von freecrac »

wobo hat geschrieben:Nachtrag:
Hier habe ich den Artikel wiedergefunden:
http://www.df.lth.se/~john_e/gems/gem0022.html
Dort steht: "To access the memory you must set a segment register to 0 and read or write to the absolute 32-bit address to the memory block."

Das stimmt aber gar nicht und mir ist es auch völlig unklar warum das immer wieder behauptet wird, denn es genügt von der gewünschten absoluten 32Bit-Zleladresse die jeweilige Adresse im verwendeten Segmentregister abzuziehen.

Code: Alles auswählen

mov  edi, 100000h     ; absolute Zieladresse des 2.Megabyte
xor  eax, eax
mov  ax, DATEN        ; relative Segmentadresse unseres Datensegments
mov  ds, ax
shl  eax, 4           ; aktuelle Segmentadresse in 32Bit-Adresse umwandeln
sub  edi, eax         ;  ...und von unserer Zieladresse abziehen
mov  esi, OFFSET WERT
mov  eax, [esi]       ; Wert aus dem Datensegment lesen (über DS:ESI)
mov  [edi], eax       ; Wert in Zieladresse schreiben (über DS:EDI)

; ---Datensegment---
WERT DD 12345678h
Nachträglich eingefügt:
Ganz am Ende der Seite wird dann noch der Frage nachgegangen wie sinnvoll es ist den Unrealmode im Vergleich zum PMode zu verwenden.
Völlig unberücksichtig bleibt hierbei aber die Möglichkeit ebenfalls im RMode/Unrealmode den 32 Bit-Mode zu verwenden und das alle Zugriffe auf Segmentregister im PMode weit aus langsamer sind als im RMode/Unrealmode.
Der Einwand man müsse im Realmode/Unrealmode für 32-Bit-Befehle dafür immer 32Bit-Prefixe verwenden (flat real mode became less attractive since it is still 16-bit) ist definitiv falsch.
Mit der Äusserung: "Flat memory will provide you with a 32 bit full addressing range along with 32-bit protected mode" wird dem Leser auch unterschlagen,
das auch mit dem 16Bit-PM es ebenfalls möglich ist den gesamten 32Bit-Adressraum (wie auch im 16-Bit Unrealmode) zu adressieren (bei der Verwendung eines 80386+).

Die angebliche Instabilität des Unrealmodes kann ich selber auch nicht nachvollziehen.

Auch wird hier die Tatsache das man 16Bit-BIOS-Aufrufe für den RMode/Unrealmode im PMode gar nicht machen kann und die Dokumentation von 32Bit-Bios-Funktionen so gut wie gar nicht vorhanden ist,
oder das solche 32 Bit-Funktionen einfach nicht im Bios existieren gar nicht erst erwähnt.
Logisch das man dann einen erheblichen Mehraufwand betreiben muss um z.B. benötigte Daten von/zu einem Datenträger zu laden/schreiben, wenn man keine entsprechenden Bios-Funktionen dafür benutzen kann.

Dirk
Zuletzt geändert von freecrac am Sa 11. Dez 2010, 10:30, insgesamt 9-mal geändert.
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Neuer User: DOSferatu

Beitrag von wobo »

freecrac hat geschrieben:
wobo hat geschrieben:Nachtrag:
Hier habe ich den Artikel wiedergefunden:
http://www.df.lth.se/~john_e/gems/gem0022.html
Dort steht: "To access the memory you must set a segment register to 0 and read or write to the absolute 32-bit address to the memory block."

Das stimmt aber gar nicht und mir ist es auch völlig unklar warum das immer wieder behauptet wird, denn es genügt von der gewünschten absoluten 32Bit-Zleladresse die jeweilige Adresse im verwendeten Segmentregister abzuziehen.

Code: Alles auswählen

mov  edi, 100000h     ; absolute Zieladresse des 2.Megabyte
xor  eax, eax
mov  ax, DATEN        ; relative Segmentadresse unseres Datensegments
mov  ds, ax
shl  eax, 4           ; aktuelle Segmentadresse in 32Bit-Adresse umwandeln
sub  edi, eax         ;  ...und von unserer Zieladresse abziehen
mov  esi, OFFSET WERT
mov  eax, [esi]       ; Wert aus dem Datensegment lesen (über DS:ESI)
mov  [edi], eax       ; Wert in Zieladresse schreiben (über DS:EDI)

; ---Datensegment---
WERT DD 12345678h
Dirk
Das stimmt natürlich. Das entsprechende Segmentregister muß nicht zwingend auf Null gesetzt werden. Ich schalte die VGA meines 386sx auch gerne in einen 128k - Mode, so dass sich das Videoram in $A0000 - $Bffff befindet, welches ich linear - ohne Banking - z.B. für 320x400/256 adressieren kann (Das Banking nutze ich dann für Pageflipping). Dabei setze ich das Segment - Register für die Zugriffe auf das Videoram auch auf $A000.

Theoretisch könnte man also über Unreal 4GB + 1MB - 16byte an Speicher adressieren, ähnlich der HMA unter XMS/DOS.

Der Artikel ist halt von 1998, da war man froh, wenn das überhaupt klappte. 1998 hieß der Unreal auch noch einfach Flatmode. Auch nur über diesen Begriff habe ich den Artikel noch gefunden...

Wie fügst Du eigentlich Deine Listings immer so elegant ein? Wenn ich Pascal-Code in meine Kommentare einfüge, wird immer die Formatierung ignoriert... ...ups, jetzt beim Zitieren sehe ich die Anweisungen _code_ und _/code_ in eckigen Klammern...

wobo
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Neuer User: DOSferatu

Beitrag von freecrac »

wobo hat geschrieben:Der Artikel ist halt von 1998, da war man froh, wenn das überhaupt klappte.
Also hatte der Schreiber dieser Seite(John Eckerdal?) vermutlich schon über 10 Jahre lang Zeit gehabt derartige Fehl-Informationen zu beseitigen und richtig zu stellen.
Wie fügst Du eigentlich Deine Listings immer so elegant ein? Wenn ich Pascal-Code in meine Kommentare einfüge, wird immer die Formatierung ignoriert... ...ups, jetzt beim Zitieren sehe ich die Anweisungen _code_ und _/code_ in eckigen Klammern...

wobo
Leider muss ich damit immer noch z.B. die Kommentare einrücken um diese alle untereinander in eine Spalte zu bekommen.
Vorvormatierter Text mit HTML-Tag <pre> ... </pre> funktioniert doch etwas anders.

Dirk
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Neuer User: DOSferatu

Beitrag von wobo »

freecrac hat geschrieben: Nachträglich eingefügt:
Ganz am Ende der Seite wird dann noch der Frage nachgegangen wie sinnvoll es ist den Unrealmode im Vergleich zum PMode zu verwenden.
Völlig unberücksichtig bleibt hierbei aber die Möglichkeit ebenfalls im RMode/Unrealmode den 32 Bit-Mode zu verwenden und das alle Zugriffe auf Segmentregister im PMode weit aus langsamer sind als im RMode/Unrealmode.
Der Einwand man müsse im Realmode/Unrealmode für 32-Bit-Befehle dafür immer 32Bit-Prefixe verwenden (flat real mode became less attractive since it is still 16-bit) ist definitiv falsch.
Mit der Äusserung: "Flat memory will provide you with a 32 bit full addressing range along with 32-bit protected mode" wird dem Leser auch unterschlagen,
das auch mit dem 16Bit-PM es ebenfalls möglich ist den gesamten 32Bit-Adressraum (wie auch im 16-Bit Unrealmode) zu adressieren (bei der Verwendung eines 80386+).

Die angebliche Instabilität des Unrealmodes kann ich selber auch nicht nachvollziehen.

Auch wird hier die Tatsache das man 16Bit-BIOS-Aufrufe für den RMode/Unrealmode im PMode gar nicht machen kann und die Dokumentation von 32Bit-Bios-Funktionen so gut wie gar nicht vorhanden ist,
oder das solche 32 Bit-Funktionen einfach nicht im Bios existieren gar nicht erst erwähnt.
Logisch das man dann einen erheblichen Mehraufwand betreiben muss um z.B. benötigte Daten von/zu einem Datenträger zu laden/schreiben, wenn man keine entsprechenden Bios-Funktionen dafür benutzen kann.

Dirk
Aber auch in einem 32bit-Real-Mode wird man die 16bit-BIOS-Aufrufe nicht nutzen können? Der Aufwand dann für eine 32bit-RM-Anwendung wäre dann genauso hoch wie für eine 32bit-PM-Anwendung (wenn man keinen fertigen PM-Extender verwendet)?
Kennst Du eine Anwendung, die im 32bit-Real-Mode läuft?


Die Instabilität von Unreal kann ich ebenfalls nicht bestätigen. Bei mir lag es immer an eigenen Programmierfehlern, wenn etwas insoweit nicht klappte.

wobo
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Neuer User: DOSferatu

Beitrag von DOSferatu »

Ja, ich wollte damit nicht sagen, daß ich den Flat/4G-Mode nicht verwenden will oder sowas... Ich hab es bisher einfach noch nicht gemacht und all mein Zeugs ist auf den Real-Address-Mode (16Bit halt) ausgelegt. Ich verwende zwar auch die 32-Bit-Register (mit Präfix-Bytes halt) und die beiden zusätzlichen Segmentregister (FS, GS - auch mit Präfix-Bytes), aber ansonsten ist bei mir alles 16-Bit, vor allem eben sämtliche Adressierung. Ich weiß, das limitiert mich auf 1 MB Speicher (bzw 1 MB plus 65520 Bytes, wenn A20 Gate offen) und Zugriff auf höheren Speicher hab ich nur mit XMS (über die HIMEM.SYS Routinen). Aber bisher hat mir das halt immer ausgereicht.

Ich bin mir durchaus dessen bewußt, daß ich nur ein kleiner Privatcoder und Lamer bin, der nicht mit den wirklichen Programmiergrößen mithalten kann. Bei mir liegt es eben daran, daß ich nur Dinge benutze, wenn ich verstanden habe, wie sie funktionieren (was auch der Grund ist, warum ich keine fremden Bibliotheken einfach bei mir einbaue/verwende).

Außerdem benutze ich nur maximal 386er-Befehle, obwohl ich auch einige 486er-Befehle einsetzen und dadurch an manchen Stellen ein, zwei Zyklen rausholen könnte - aber dann würde mein Zeugs nicht mehr auf 386ern lauffähig sein und das würde mich stören (obwohl ich selbst nie einen 386er besessen habe).
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Neuer User: DOSferatu

Beitrag von wobo »

DOSferatu hat geschrieben:Ja, ich wollte damit nicht sagen, daß ich den Flat/4G-Mode nicht verwenden will oder sowas... Ich hab es bisher einfach noch nicht gemacht und all mein Zeugs ist auf den Real-Address-Mode (16Bit halt) ausgelegt.
[...]
Aber bisher hat mir das halt immer ausgereicht.

Ich bin mir durchaus dessen bewußt, daß ich nur ein kleiner Privatcoder und Lamer bin, der nicht mit den wirklichen Programmiergrößen mithalten kann. Bei mir liegt es eben daran, daß ich nur Dinge benutze, wenn ich verstanden habe, wie sie funktionieren (was auch der Grund ist, warum ich keine fremden Bibliotheken einfach bei mir einbaue/verwende).
:-) Naja, ich benutze ja auch den XMS über Himem.sys, dann immer nämlich, wenn es ausreichend schnell ist - eben weil es kompatibel ist. Z.B. benutze ich Standard xms für meinen Game-Editor. Nur für die Game-Engine ist das einfach zu langsam. Grund ist: Meine gesamte Landschaft ist im xms bereits fertig aufgebaut (und _das_ ist LAME!). Von dort mit himem.sys die Grafiken auszulesen haut jede Framerate in den Eimer.

Himem.sys zum Zugriff auf das XMS läßt sich im Übrigen nicht mit 4G kunterbunt vermischen. Ich vermute, dass Himem.sys nach jedem Aufruf der Kopierfunktion alle Segmentregister (auch FS und GS) wieder auf 64k-Größe stellt. Die Verwendung von 4G wäre dann tatsächlich ein Probem, wenn zugleich ein TSR vorliegt, das selbst auf den XMS über einen XMS-Treiber zugreift. (Ein gleichzeitiger Zugriff auf UMB oder HMA ist m.W. kein Problem.)

Ich halte 4G wirklich nicht für ein Allerheilmittel. Richtig ist es sicherlich, EMS oder XMS über einen XMS-Treiber zu benutzen, solange es geht. 4G ist für mich halt die Möglichkeit, auf sehr beschränkten Rechnern schnellen Zugriff auf mehrere MB zu bekommen. Ohne dass ich neu denken muß (es ist halt Real Mode nur mit größeren Offsets). Ohne dass ich von Turbo Pascal, Dos, Norton Commander etc. lassen muß.


Und ein Game wie XPYDERZ in 600kb Ram zu pressen, finde ich "krank" ;-)! 4G könntest Du ja jetzt ruhig benutzen, wo Du ihn endlich verstanden hast. Dann müssten freecrac und ich auch nicht mehr so viel bei jedem Deiner Projekte rumdiskutieren. ;-) ...

PS: Ich versuche auch, nur Sachen zu benutzen, die ich - soweit mir möglich - verstanden habe. Bei mir führt das leider zur produktiven Stagnation...

Grüße,
wobo
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Neuer User: DOSferatu

Beitrag von DOSferatu »

wobo hat geschrieben:Naja, ich benutze ja auch den XMS über Himem.sys, dann immer nämlich, wenn es ausreichend schnell ist - eben weil es kompatibel ist. Z.B. benutze ich Standard xms für meinen Game-Editor. Nur für die Game-Engine ist das einfach zu langsam. Grund ist: Meine gesamte Landschaft ist im xms bereits fertig aufgebaut (und _das_ ist LAME!). Von dort mit himem.sys die Grafiken auszulesen haut jede Framerate in den Eimer.
Ja, wenn ich z.B. die Musik (WAV) über PC-Speaker ausgebe, hol ich die ausm XMS. (Ist ja nur so ein Dummy-Feature.)
wobo hat geschrieben:Himem.sys zum Zugriff auf das XMS läßt sich im Übrigen nicht mit 4G kunterbunt vermischen. Ich vermute, dass Himem.sys nach jedem Aufruf der Kopierfunktion alle Segmentregister (auch FS und GS) wieder auf 64k-Größe stellt.
Das liegt daran, daß HIMEM.SYS dieselben Mechanismen benutzt wie der Flag/4G Mode - und daß HIMEM.SYS aber davon ausgeht, vom RealMode aus aufgerufen worden zu sein.
wobo hat geschrieben:Und ein Game wie XPYDERZ in 600kb Ram zu pressen, finde ich "krank"!
Ich dagegen finde es völlig OK. Wenn der Speicher reicht, muß ich keinen weiteren verschwenden. Und eigentlich könnte ich bei vernünftiger Programmierung (d.h. wenn ich das "Stückwerk", zu dem sich Xpyderz in den Jahren entwickelt hat, mal "aufräumen" würde) bestimmt 10 bis 30 kB sparen oder so.
wobo hat geschrieben:4G könntest Du ja jetzt ruhig benutzen, wo Du ihn endlich verstanden hast.
Ich will ihn nicht benutzen. Schon alleine, weil ich immer EMM386 geladen habe und so. (Wenn ich den Rechner nämlich "blank" boote (damit Flat/4G überhaupt geht - weil vom V86 Mode aus kann man den ja nicht mehr...), kann ich ja nix mehr "hochladen" - dann hab ich weniger Heap - also: Nix da!)
wobo hat geschrieben:Dann müssten freecrac und ich auch nicht mehr so viel bei jedem Deiner Projekte rumdiskutieren.
Wieso "rumdiskutieren"? So lange irgendwas funktioniert, ist es völlig egal, wie es gemacht wurde.
wobo hat geschrieben:PS: Ich versuche auch, nur Sachen zu benutzen, die ich - soweit mir möglich - verstanden habe. Bei mir führt das leider zur produktiven Stagnation...
Tut's bei mir auch. Aber ich bin ja kein geldgeiler Großkonzern, der damit Geld verdienen muß. (Du weißt schon: Die Leute, die, wenn Weihnachten oder sowas ran ist, Spiele, Tools oder Betriebssysteme unfertig und verbuggt auf den Markt werfen, um den Feiertagsverkauf mitzunehmen und dann mindestens ein halbes Jahr lang Patches rausbringen müssen, damit das Zeug überhaupt nutzbar ist.)
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Neuer User: DOSferatu

Beitrag von freecrac »

wobo hat geschrieben:Aber auch in einem 32bit-Real-Mode wird man die 16bit-BIOS-Aufrufe nicht nutzen können? Der Aufwand dann für eine 32bit-RM-Anwendung wäre dann genauso hoch wie für eine 32bit-PM-Anwendung (wenn man keinen fertigen PM-Extender verwendet)?
Ja das ist natürlich richtig.

In diesem Zusammenhang wurde ja der Frage nachgegangen welche Vor- und Nachteile sich durch die Benutzung des PModes im Vergleich zum Unrealmode ergeben.
Bei meiner Kritik ging es um den falschen Eindruck den man gewinnt, das man im Realmode/Unrealmode immer nur den 16Bit-Mode betreiben könne und damit für 32Bit-Befehle auch immer 32Bit-Prefixe verwenden müsse.
Hier wird ein positiver Aspekt, das man solche 32-Bit-Prefixe im PMode in Kombination mit dem 32Bit-Mode bei 32Bit-Befehlen weglassen könne erwähnt und auch richtig zugeordnet,
aber die Tatsache blieb unerwähnt, das man diesen positiven Effekt ebenso auch im Realmode/Unrealmode in Kombination mit dem 32Bit-Mode nutzen kann.
Hiermit wird somit fälschlich suggeriert, das es ein alleiniger Vorteil des PModes wäre den 32 Bit Mode und die damit sich ergebenen Vorteile zu verwenden.
Kennst Du eine Anwendung, die im 32bit-Real-Mode läuft?
Nein solche Anwendungen kenne ich persöhnlich auch noch nicht.
Die Instabilität von Unreal kann ich ebenfalls nicht bestätigen. Bei mir lag es immer an eigenen Programmierfehlern, wenn etwas insoweit nicht klappte.

wobo
Ich habe bei einer Disskussion rund um den Unrealmode gelesen das es Steckkarten für den PC geben soll, die über ihr BIOS selber in den PM und dann wohl auch zurück in den RM schalten können. Damit lässt sich der Unrealmodes abschalten.
Welche Steckkarten so etwas machen das wurde leider nicht genau spezifiziert.

Dirk
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Neuer User: DOSferatu

Beitrag von freecrac »

DOSferatu hat geschrieben:Ja, ich wollte damit nicht sagen, daß ich den Flat/4G-Mode nicht verwenden will oder sowas... Ich hab es bisher einfach noch nicht gemacht und all mein Zeugs ist auf den Real-Address-Mode (16Bit halt) ausgelegt. Ich verwende zwar auch die 32-Bit-Register (mit Präfix-Bytes halt) und die beiden zusätzlichen Segmentregister (FS, GS - auch mit Präfix-Bytes), aber ansonsten ist bei mir alles 16-Bit, vor allem eben sämtliche Adressierung. Ich weiß, das limitiert mich auf 1 MB Speicher (bzw 1 MB plus 65520 Bytes, wenn A20 Gate offen) und Zugriff auf höheren Speicher hab ich nur mit XMS (über die HIMEM.SYS Routinen). Aber bisher hat mir das halt immer ausgereicht.

Ich bin mir durchaus dessen bewußt, daß ich nur ein kleiner Privatcoder und Lamer bin, der nicht mit den wirklichen Programmiergrößen mithalten kann. Bei mir liegt es eben daran, daß ich nur Dinge benutze, wenn ich verstanden habe, wie sie funktionieren (was auch der Grund ist, warum ich keine fremden Bibliotheken einfach bei mir einbaue/verwende).

Außerdem benutze ich nur maximal 386er-Befehle, obwohl ich auch einige 486er-Befehle einsetzen und dadurch an manchen Stellen ein, zwei Zyklen rausholen könnte - aber dann würde mein Zeugs nicht mehr auf 386ern lauffähig sein und das würde mich stören (obwohl ich selbst nie einen 386er besessen habe).
Nein, du bist doch kein Lamer, hier muss ich dir widersprechen. Und wenn dir der Speicher genügt dann ist das völlig in Ordnung. Selbst auf dem C64 mit der dorttigen Speichermenge lässt sich schon sehr viel anstellen.
Mit fremden Bibliotheken mag ich auch nicht gerne arbeiten. Allerdings habe ich die Messlatte für eine CPU schon etwas höher gelegt und denke das eine CPU mit MMX heute schon fast überall in der x86-Welt anzutreffen ist.
Ich persöhnlich möchte diese von mir aufgestellten minimalen Anforderungen an eine CPU eigentlich nicht mehr wirklich gerne unterschreiten.

Dirk
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Neuer User: DOSferatu

Beitrag von freecrac »

wobo hat geschrieben:Himem.sys zum Zugriff auf das XMS läßt sich im Übrigen nicht mit 4G kunterbunt vermischen. Ich vermute, dass Himem.sys nach jedem Aufruf der Kopierfunktion alle Segmentregister (auch FS und GS) wieder auf 64k-Größe stellt. Die Verwendung von 4G wäre dann tatsächlich ein Probem, wenn zugleich ein TSR vorliegt, das selbst auf den XMS über einen XMS-Treiber zugreift. (Ein gleichzeitiger Zugriff auf UMB oder HMA ist m.W. kein Problem.)
Das widerspricht aber meinen Erfahrungen.
Denn ich habe neben einer RAM-Disk(SRDXMS.SYS von Marko Kohtala) die auf angeforderten XMS-Speicher von Himem.sys basiert schon erfolgreich von dort aus eine Anwendung die in den Unralmode schaltet
mehrmals hintereinander starten und beenden können, wobei die Anwendung zur Laufzeit selber Daten von der Ramdisk einläd und auch Daten darauf abspeichert, ganz ohne das dadurch der Unrealmode ausgeschaltet wurde.
http://sourceforge.net/projects/srdisk/
Ich halte 4G wirklich nicht für ein Allerheilmittel. Richtig ist es sicherlich, EMS oder XMS über einen XMS-Treiber zu benutzen, solange es geht. 4G ist für mich halt die Möglichkeit, auf sehr beschränkten Rechnern schnellen Zugriff auf mehrere MB zu bekommen. Ohne dass ich neu denken muß (es ist halt Real Mode nur mit größeren Offsets). Ohne dass ich von Turbo Pascal, Dos, Norton Commander etc. lassen muß.
Emm386.exe und auch Windows/Linux mag ich desewegen nicht, weil es mich zu sehr einschränkt und ich damit u.A nicht selber mehr in den PM schalten kann.
Könnte mir Windows/Linux diese Möglichkeit einräumen dann würde ich vermutlich auch etwas mehr für diese OS programmieren.
Sicherheitsprobleme sind mir zwar nicht völlig unbekannt, aber wenn die Abwehr davor mein Recht so sehr einschränkt das ich meine Hardware deswegen nicht mehr so benutzen kann wie es mir gefällt,
dann lege ich mir bestimmt nicht freiwillig die Fesseln dazu an, um die Probleme auf mir fremden Rechnern damit zu vermeiden.
Ich zwinge keinen Menschen dazu einen Computer mit sicherheitsrelevanten Daten zu füttern und wer das freiwillig tut, der hat auch selber Schuld,
denn ich persöhlich habe keine Daten zu beschützen und ich betrachte das Füttern eines Computers mit sicherheitsrelevanten Daten generell als fahrlässsig,
da es immer nur eine Frage der Zeit ist bis jegliche Barrieren zum Schutz sicherheitsrelevanten Daten auf einem PC überwunden werden können.
Und ein Game wie XPYDERZ in 600kb Ram zu pressen, finde ich "krank" ;-)! 4G könntest Du ja jetzt ruhig benutzen, wo Du ihn endlich verstanden hast. Dann müssten freecrac und ich auch nicht mehr so viel bei jedem Deiner Projekte rumdiskutieren. ;-) ...
So lange der Speicher noch reicht macht mir das keine Sorgen. Auch diskutiere ich gerne über den Unrealmode.
PS: Ich versuche auch, nur Sachen zu benutzen, die ich - soweit mir möglich - verstanden habe. Bei mir führt das leider zur produktiven Stagnation...

Grüße,
wobo
Nur nicht den Kopf hängen lassen. Alles kann man eben nicht lernen. Aber das was wir uns aus eigener Kraft beibringen können ist eben die beste Möglichkeit unseren Fähigkeiten entspechend das zu nutzen was wir haben.
Damit haben wir unsere Verantwortung mit unseren Fähigkeiten vernünftig umzugehen erfüllt.

Dirk
Zuletzt geändert von freecrac am So 12. Dez 2010, 13:23, insgesamt 2-mal geändert.
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Neuer User: DOSferatu

Beitrag von freecrac »

DOSferatu hat geschrieben:Ja, wenn ich z.B. die Musik (WAV) über PC-Speaker ausgebe, hol ich die ausm XMS. (Ist ja nur so ein Dummy-Feature.)
Ich würde mich freuen wenn du das mal genauer aufzeigen könntest wie man das anstellt, denn mit Audio habe ich mich noch immer nicht beschäftigt und auch noch nicht damit wie ein WAV-File aufgebaut ist.
wobo hat geschrieben:Himem.sys zum Zugriff auf das XMS läßt sich im Übrigen nicht mit 4G kunterbunt vermischen. Ich vermute, dass Himem.sys nach jedem Aufruf der Kopierfunktion alle Segmentregister (auch FS und GS) wieder auf 64k-Größe stellt.
Das liegt daran, daß HIMEM.SYS dieselben Mechanismen benutzt wie der Flag/4G Mode - und daß HIMEM.SYS aber davon ausgeht, vom RealMode aus aufgerufen worden zu sein.
Ich selber habe solche Probleme noch nicht feststellen können.

PS: Mich stört es keineswegs über alles( bei Bedarf auch über den Unrealmode) mit dir zu diskutieren. Ganz im Gegenteil, ich betrachte es als eine Bereicherung.

Dirk
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Neuer User: DOSferatu

Beitrag von wobo »

freecrac hat geschrieben:
wobo hat geschrieben:Himem.sys zum Zugriff auf das XMS läßt sich im Übrigen nicht mit 4G kunterbunt vermischen. Ich vermute, dass Himem.sys nach jedem Aufruf der Kopierfunktion alle Segmentregister (auch FS und GS) wieder auf 64k-Größe stellt.
Das widerspricht aber meinen Erfahrungen.
Denn ich habe neben einer RAM-Disk(SRDXMS.SYS von Marko Kohtala) die auf angeforderten XMS-Speicher von Himem.sys basiert schon erfolgreich von dort aus eine Anwendung die in den Unralmode schaltet
mehrmals hintereinander starten und beenden können, wobei die Anwendung zur Laufzeit selber Daten von der Ramdisk einläd und auch Daten darauf abspeichert, ganz ohne das dadurch der Unrealmode ausgeschaltet wurde.
Wobo schreibt gemutmaßten Mist. Freecrac hat Recht!

Ich dachte all' die Jahre, die Behauptung, himem.sys schalte in den 4G, sei ein Gerücht. Schließlich wollte MS ja Windows verkaufen, da werden die sich doch nicht selbst so ein Ei legen. Als dann diese Behauptung (4G) immer öfter kam, habe ich einfach gedacht: himem.sys schaltet in den 4G, kopiert die Daten ins LowMem und schaltet dann wieder alle Register auf 64k - und das bei jedem Aufruf der XMS-Kopierfunktion Nr. 11.

Das wäre für mich die einzige Erklärung dafür gewesen, wenn man als Betriebssystemhersteller den verteufelten 4G-Mode dennoch benutzt, aber nicht will, dass er populär wird. Im Übrigen war dies für mich die einzige Erkärung, warum XMS so langsam ist, obwohl er doch 4G benutzt.

Dem ist aber wohl nicht so (gilt nur, wenn emm386 nicht geladen ist):

Offensichtlich schaltet himem.sys - sobald die Kopierfunktion Nr. 11 aufgerufen wird (das bloße Treiberinitialisieren oder Aufrufe anderer XMS-Funktionen genügen noch nicht) - die beiden Segmentregister DS und ES auf 4G und setzt diese nicht zurück.

Ich konnte, sobald ich mit irgendeinem Programm die XMS-Kopierfunktion aufgerufen habe, ohne Systemabsturz Befehle wie

mov ebx, 00010008h
mov ax, es:[ebx]
mov bx, ds:[ebx]

ausführen - ohne dass ich selbst den 4G eingeschaltet habe. Habe ich die Segmentregister FS oder GS benutzt, kam es zum Systemabsturz. Ebenso auch, wenn vorher (d.h. seit dem letzten Booten) die Kopierfunktion des XMS nicht aufgerufen wurde. Dann kam es bei jedem Segmentregister zum Absturz.

Ich habe wirklich vor jedem Versuch neu gebootet. Dabei konnte ich immer dann über DS und ES mit Offsets>64k auf Speicherstellen zugreifen, wenn
- himem.sys geladen war,
- emm386.exe (o.ä.) nicht geladen war,
- und wenigstens irgendwann zuvor einmal die xms-Kopierfunktion (Nr.11) aufgerufen war.

Testkonfiguration: intel386sx16, 6 MB, MS-Dos 6.20, XMS 3.0, TASM 2.0, TP 7.0
(Ich hatte auch immer die IDE von TP verlassen, bevor ich einen Probelauf gestartet habe. Nicht dass die mir die Segment-register verändert...)

Wieso hatte ich dann jahrzehntelang Probleme in der Kombination 4G mit himem.sys? Wahrscheinlich hatte nicht ich die Probleme, sondern himem.sys. Mein 4G ging nämlich immer, nur der Zugriff auf XMS über himem.sys klappte dann nicht mehr jedesmal. Grund (wahrscheinlich): Meine Enable4G-Routine hat nur GS in den 4G geschaltet, und alle anderen Segm.Register (DS, ES, FS) auf 64k - und das um möglichst kompatibel zu sein! Schießlich empfiehlt das Zurücksetzen der Segm.Reg. auf 64k meiner Erinnerung nach auch die Intel-Doku ganz offiziell für die Rückkehr vom PMode in den Realmode.
Das hat natürlich dem himem.sys nicht gefallen, wenn der erste Aufruf seiner XMS-Kopierfunktion zufällig vor meiner Enable4G-Routine erfolgt war. Der setzt wahrscheinlich ein internes Flag, wenn er einmal DS und ES auf 4G gestellt hat, und vertraut dann darauf, dass bis zum nächsten Booten niemand mehr an "seinen" DS und ES - Registern rumfummelt. Knallkopf!

Derart fahrlässiges und regelwidriges Verhalten hätte ich keinem Betriebssystemhersteller zugetraut. Entweder stellt man die Regel auf, dass unter DOS alle Segmente 64k haben und hält sich daran (und macht höchstens ganz heimlich davon Gebrauch und schaltet danach sofort wieder zurück, so dass es fast keiner merkt). Oder man stellt die Regel auf: wenn himem.sys verwendet ist, sind DS und ES (ggf. unter bestimmten Bedingungen) auf 4G gestellt.

Ach, was reg' ich mich denn auf.... ...bringt ja alles nix.

freecrac hat geschrieben:
wobo hat geschrieben:PS: Ich versuche auch, nur Sachen zu benutzen, die ich - soweit mir möglich - verstanden habe. Bei mir führt das leider zur produktiven Stagnation...
Nur nicht den Kopf hängen lassen. Alles kann man eben nicht lernen. Aber das was wir uns aus eigener Kraft beibringen können, ist eben die beste Möglichkeit, unseren Fähigkeiten entspechend, das zu nutzen, was wir haben.
Damit haben wir unsere Verantwortung, mit unseren Fähigkeiten vernünftig umzugehen, erfüllt.

Dirk
Muß ich mir jetzt Sorgen machen? Ich meine, ich schreibe, was bei mir alles nicht klappt und Du sagst, das passt schon, solange ich dabei nur meine Fähigkeiten ausschöpfe.. ;-))

Aber gute Weisheit. Auf jeden Fall etwas zum Nachdenken (PS: habe noch ein paar Kommas in Dein Zitat einfügen dürfen - und beim Editieren auch noch in meinem Geschreibsel...).

Grüße
wobo
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Neuer User: DOSferatu

Beitrag von freecrac »

wobo hat geschrieben:
freecrac hat geschrieben:
wobo hat geschrieben:Himem.sys zum Zugriff auf das XMS läßt sich im Übrigen nicht mit 4G kunterbunt vermischen. Ich vermute, dass Himem.sys nach jedem Aufruf der Kopierfunktion alle Segmentregister (auch FS und GS) wieder auf 64k-Größe stellt.
Das widerspricht aber meinen Erfahrungen.
Denn ich habe neben einer RAM-Disk(SRDXMS.SYS von Marko Kohtala) die auf angeforderten XMS-Speicher von Himem.sys basiert schon erfolgreich von dort aus eine Anwendung die in den Unralmode schaltet
mehrmals hintereinander starten und beenden können, wobei die Anwendung zur Laufzeit selber Daten von der Ramdisk einläd und auch Daten darauf abspeichert, ganz ohne das dadurch der Unrealmode ausgeschaltet wurde.
Wobo schreibt gemutmaßten Mist. Freecrac hat Recht!

Ich dachte all' die Jahre, die Behauptung, himem.sys schalte in den 4G, sei ein Gerücht. Schließlich wollte MS ja Windows verkaufen, da werden die sich doch nicht selbst so ein Ei legen. Als dann diese Behauptung (4G) immer öfter kam, habe ich einfach gedacht: himem.sys schaltet in den 4G, kopiert die Daten ins LowMem und schaltet dann wieder alle Register auf 64k - und das bei jedem Aufruf der XMS-Kopierfunktion Nr. 11.

Das wäre für mich die einzige Erklärung dafür gewesen, wenn man als Betriebssystemhersteller den verteufelten 4G-Mode dennoch benutzt, aber nicht will, dass er populär wird. Im Übrigen war dies für mich die einzige Erkärung, warum XMS so langsam ist, obwohl er doch 4G benutzt.

Dem ist aber wohl nicht so (gilt nur, wenn emm386 nicht geladen ist):

Offensichtlich schaltet himem.sys - sobald die Kopierfunktion Nr. 11 aufgerufen wird (das bloße Treiberinitialisieren oder Aufrufe anderer XMS-Funktionen genügen noch nicht) - die beiden Segmentregister DS und ES auf 4G und setzt diese nicht zurück.

Ich konnte, sobald ich mit irgendeinem Programm die XMS-Kopierfunktion aufgerufen habe, ohne Systemabsturz Befehle wie

mov ebx, 00010008h
mov ax, es:[ebx]
mov bx, ds:[ebx]
Welche physikalische Adresse ergibt sich genau aus DS:10008h?

......

Noch bis zum 80286 gab es ein wrap around.
Ab 80386+ im RM addressierbar:
Segment (* 2²) FFFF0h
+ Offset.........0FFFFh
---------------------------
physik adr.....10FFEFh

Somit kann man die Adressen von 100000h bis 10FFEFh ebenfalls auch im RM benutzen (wenn physikalisch vorhanden).
ausführen - ohne dass ich selbst den 4G eingeschaltet habe. Habe ich die Segmentregister FS oder GS benutzt, kam es zum Systemabsturz. Ebenso auch, wenn vorher (d.h. seit dem letzten Booten) die Kopierfunktion des XMS nicht aufgerufen wurde. Dann kam es bei jedem Segmentregister zum Absturz.

Ich habe wirklich vor jedem Versuch neu gebootet. Dabei konnte ich immer dann über DS und ES mit Offsets>64k auf Speicherstellen zugreifen, wenn
- himem.sys geladen war,
- emm386.exe (o.ä.) nicht geladen war,
- und wenigstens irgendwann zuvor einmal die xms-Kopierfunktion (Nr.11) aufgerufen war.

Testkonfiguration: intel386sx16, 6 MB, MS-Dos 6.20, XMS 3.0, TASM 2.0, TP 7.0
(Ich hatte auch immer die IDE von TP verlassen, bevor ich einen Probelauf gestartet habe. Nicht dass die mir die Segment-register verändert...)

Wieso hatte ich dann jahrzehntelang Probleme in der Kombination 4G mit himem.sys? Wahrscheinlich hatte nicht ich die Probleme, sondern himem.sys. Mein 4G ging nämlich immer, nur der Zugriff auf XMS über himem.sys klappte dann nicht mehr jedesmal. Grund (wahrscheinlich): Meine Enable4G-Routine hat nur GS in den 4G geschaltet, und alle anderen Segm.Register (DS, ES, FS) auf 64k - und das um möglichst kompatibel zu sein! Schießlich empfiehlt das Zurücksetzen der Segm.Reg. auf 64k meiner Erinnerung nach auch die Intel-Doku ganz offiziell für die Rückkehr vom PMode in den Realmode.
Das hat natürlich dem himem.sys nicht gefallen, wenn der erste Aufruf seiner XMS-Kopierfunktion zufällig vor meiner Enable4G-Routine erfolgt war. Der setzt wahrscheinlich ein internes Flag, wenn er einmal DS und ES auf 4G gestellt hat, und vertraut dann darauf, dass bis zum nächsten Booten niemand mehr an "seinen" DS und ES - Registern rumfummelt. Knallkopf!
Möglicherweise verhalten sich die verschiedenen Versionen auch anders?
Himem.sys:
MS-DOS ab 5.0 bis 6.xx = 64 MB
MS-DOS 7.0 (Windows 95) = 256 MB
MS-DOS 7.1 (Windows 98) = 4 GB
Derart fahrlässiges und regelwidriges Verhalten hätte ich keinem Betriebssystemhersteller zugetraut. Entweder stellt man die Regel auf, dass unter DOS alle Segmente 64k haben und hält sich daran (und macht höchstens ganz heimlich davon Gebrauch und schaltet danach sofort wieder zurück, so dass es fast keiner merkt). Oder man stellt die Regel auf: wenn himem.sys verwendet ist, sind DS und ES (ggf. unter bestimmten Bedingungen) auf 4G gestellt.

Ach, was reg' ich mich denn auf.... ...bringt ja alles nix.

freecrac hat geschrieben:
wobo hat geschrieben:PS: Ich versuche auch, nur Sachen zu benutzen, die ich - soweit mir möglich - verstanden habe. Bei mir führt das leider zur produktiven Stagnation...
Nur nicht den Kopf hängen lassen. Alles kann man eben nicht lernen. Aber das was wir uns aus eigener Kraft beibringen können, ist eben die beste Möglichkeit, unseren Fähigkeiten entspechend, das zu nutzen, was wir haben.
Damit haben wir unsere Verantwortung, mit unseren Fähigkeiten vernünftig umzugehen, erfüllt.

Dirk
Muß ich mir jetzt Sorgen machen? Ich meine, ich schreibe, was bei mir alles nicht klappt und Du sagst, das passt schon, solange ich dabei nur meine Fähigkeiten ausschöpfe.. ;-))
Ich dachte eher, mit ein bischen Hilfe kommt man auch weiter. Und das man manchmal auch eine Pause einlegen sollte wenn man in einer Lernphase steckt. Ein bischen Abstand gewinnen.
Aber gute Weisheit. Auf jeden Fall etwas zum Nachdenken (PS: habe noch ein paar Kommas in Dein Zitat einfügen dürfen - und beim Editieren auch noch in meinem Geschreibsel...).

Grüße
wobo
Danke.

Dirk
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Neuer User: DOSferatu

Beitrag von wobo »

freecrac hat geschrieben:
wobo hat geschrieben:
[...DS und ES auf 4G allein durch Aufruf der XMS-Kopierfunktion Nr. 11 von himem.sys bei 386+ und nicht v86-Mode...]

Ich konnte, sobald ich mit irgendeinem Programm die XMS-Kopierfunktion aufgerufen habe, ohne Systemabsturz Befehle wie

mov ebx, 00010008h
mov ax, es:[ebx]
mov bx, ds:[ebx]
Welche physikalische Adresse ergibt sich genau aus DS:10008h?
Kommt darauf an, was in DS steht. Grundsätzlich also [DS]*16+10008h, oder?
......
Noch bis zum 80286 gab es ein wrap around.
Ab 80386+ im RM addressierbar:
Segment (* 2²) FFFF0h
+ Offset.........0FFFFh
---------------------------
physik adr.....10FFEFh

Somit kann man die Adressen von 100000h bis 10FFEFh ebenfalls auch im RM benutzen (wenn physikalisch vorhanden).
Du meinst die HMA - wenn A20 enabled ist? Muß es nicht Segment (*2 hoch 4) heißen?


Möglicherweise verhalten sich die verschiedenen Versionen auch anders?
Himem.sys:
MS-DOS ab 5.0 bis 6.xx = 64 MB
MS-DOS 7.0 (Windows 95) = 256 MB
MS-DOS 7.1 (Windows 98) = 4 GB
Könnte sein. Konnte derzeit alles nur unter MS-Dos 6.20 (XMS 3.0) testen. Ich weiss aber, dass himem.sys (XMS-Version 2.0) unter MS-Dos 5.0 diesselben Probleme hatte. War (auf 386+) himem.sys geladen, aber kein emm386 und habe ich die Register DS, ES (und FS) auf 64k gestellt, so hatte ich oft Systemabstürze, wenn ich danach per XMS-Funktion Speicher kopieren wollte. Im Nachhinein kann ich mir das eben nur wie beschrieben erklären, nämlich, dass himem.sys davon ausging, DS und ES zeigten noch auf 4G-Segmente.

Für mich bedeutet dies zwangsläufig, dass unter Dos der Programmierer nicht davon ausgehen darf, dass die Segmentregister immer auf 64k-Segmente zeigen. Eben weil MS gerade unter bestimmten Umständen Segmentgrößen von (wohl 4G) vorauszusetzen scheint. Meine Zurückhaltung beim Flat/4G ist hiermit beendet.

Aber gute Weisheit. Auf jeden Fall etwas zum Nachdenken (PS: habe noch ein paar Kommas in Dein Zitat einfügen dürfen - und beim Editieren auch noch in meinem Geschreibsel...).
Kommasetzung von mir war übrigens nicht vollkommen fehlerfrei... ... Aber wenn MS sich nicht mal festlegen kann, wie groß Datensegmente unter Dos sein dürfen und sogar sein müssen, dann ist das auch nicht mehr so wild ;-)

Grüße
Wobo
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Neuer User: DOSferatu

Beitrag von freecrac »

wobo hat geschrieben:
freecrac hat geschrieben:
wobo hat geschrieben:
[...DS und ES auf 4G allein durch Aufruf der XMS-Kopierfunktion Nr. 11 von himem.sys bei 386+ und nicht v86-Mode...]

Ich konnte, sobald ich mit irgendeinem Programm die XMS-Kopierfunktion aufgerufen habe, ohne Systemabsturz Befehle wie

mov ebx, 00010008h
mov ax, es:[ebx]
mov bx, ds:[ebx]
Welche physikalische Adresse ergibt sich genau aus DS:10008h?
Kommt darauf an, was in DS steht.
Jo.
Grundsätzlich also [DS]*16+10008h, oder?
Ja richtig. Doch wenn DS = 0 ist, dann fehlt in deinem Offset eine Null um damit die Adresse 1MB+8 Byte zu bilden.
......
Noch bis zum 80286 gab es ein wrap around.
Ab 80386+ im RM addressierbar:
Segment (* 2²) FFFF0h
+ Offset.........0FFFFh
---------------------------
physik adr.....10FFEFh

Somit kann man die Adressen von 100000h bis 10FFEFh ebenfalls auch im RM benutzen (wenn physikalisch vorhanden).
Du meinst die HMA - wenn A20 enabled ist?
Ja genau, damit kann die physikalische Adresse von 10FFEFh bei einem 80386+ im RM mit SEG=0FFFFh + Offset=0FFFFh gebildet werden. 1 MB + 65520 Bytes
Ohne A20 enabled kommt es zum wrap-around so das dann die Adresse 0FFEFh angesprochen wird.
Muß es nicht Segment (*2 hoch 4) heißen?
Uff, ich glaube ja.

Möglicherweise verhalten sich die verschiedenen Versionen auch anders?
Himem.sys:
MS-DOS ab 5.0 bis 6.xx = 64 MB
MS-DOS 7.0 (Windows 95) = 256 MB
MS-DOS 7.1 (Windows 98) = 4 GB
Könnte sein. Konnte derzeit alles nur unter MS-Dos 6.20 (XMS 3.0) testen. Ich weiss aber, dass himem.sys (XMS-Version 2.0) unter MS-Dos 5.0 diesselben Probleme hatte. War (auf 386+) himem.sys geladen, aber kein emm386 und habe ich die Register DS, ES (und FS) auf 64k gestellt, so hatte ich oft Systemabstürze, wenn ich danach per XMS-Funktion Speicher kopieren wollte. Im Nachhinein kann ich mir das eben nur wie beschrieben erklären, nämlich, dass himem.sys davon ausging, DS und ES zeigten noch auf 4G-Segmente.

Für mich bedeutet dies zwangsläufig, dass unter Dos der Programmierer nicht davon ausgehen darf, dass die Segmentregister immer auf 64k-Segmente zeigen. Eben weil MS gerade unter bestimmten Umständen Segmentgrößen von (wohl 4G) vorauszusetzen scheint. Meine Zurückhaltung beim Flat/4G ist hiermit beendet.
Zum Testen ob DS und ES erweitert sind solltest du aber eine Adresse oberhalb von 10FFEFh verwenden.

Dirk
Antworten