Tag.
Bin ganz neu hier, also erst mal ein herzliches Hallo an alle.
Ich hätte da eine Frage bzgl. Ausstattung des PCs für DOS und Windows.
Hauptaugenmerk des PCs liegt auf Spieletauglichkeit unter reiner DOS
Umgebung. Aber da ich ( per HD im Wechselrahmen ) auch gelegentlich
Windows 98SE auf diesem PC starte ,würde ich gerne wissen ob es:
1) DOS ( MS-DOS 6.22 & 7.10 ) stören würde, wenn ich in diesem Rechner
384 MB einbaue? Mir ist klar dass DOS diesen Speicher nicht nutzt, aber
würde er sich störend bemerkbar machen?
2) Wenn unter DOS 6.22 eine Partition mit FAT32 Filesystem dranhängt,
ist die für DOS dann komplett unsichtbar oder nur nicht lesbar?
Hintergrund ist, dass ich für einen weiteren Retro Rechner langsam nun
wirklich keinen Platz mehr habe. Danke.
384MB RAM für DOS zuviel?
Re: 384MB RAM für DOS zuviel?
Hallo,
zu 1: Nein, eigentlich sollte es DOS nicht stören. Bei DOS 6.2 war glaube ich bei 64MB sowieso Schluß, mehr hat HIMEM nicht erkannt. Allenfalls könnten irgendwelche älteren Programme "in Ohnmacht" fallen, falls sie unter DOS 7 soviel XMS-Speicher sehen.
zu 2: Unter DOS 6 sind FAT32-Partitionen nicht sichtbar, weil die eine andere Partitionskennung (0x0b oder 0x0c) haben als FAT16-Partitionen (0x06) und folglich von DOS 6 nicht als DOS-Partition erkannt werden.
Gruß, Thomas
zu 1: Nein, eigentlich sollte es DOS nicht stören. Bei DOS 6.2 war glaube ich bei 64MB sowieso Schluß, mehr hat HIMEM nicht erkannt. Allenfalls könnten irgendwelche älteren Programme "in Ohnmacht" fallen, falls sie unter DOS 7 soviel XMS-Speicher sehen.
zu 2: Unter DOS 6 sind FAT32-Partitionen nicht sichtbar, weil die eine andere Partitionskennung (0x0b oder 0x0c) haben als FAT16-Partitionen (0x06) und folglich von DOS 6 nicht als DOS-Partition erkannt werden.
Gruß, Thomas
Re: 384MB RAM für DOS zuviel?
Danke für deine Antwort 
Dann werde ich meinen Rechner
jetzt mal langsam der Endausbaustufe zuführen...
Dann werde ich meinen Rechnerjetzt mal langsam der Endausbaustufe zuführen...
Re: 384MB RAM für DOS zuviel?
Das mit den knapp 64 MB betrifft HIMEM.SYS vor Version 3.0.
Ab HIMEM.SYS 3.0 können bis zu knapp 4 GB Speicher angewählt werden - dazu müssen die erweiterten Funktionen, die ab v3.0 verfügbar sind (für 32bit Register) verwendet werden - jedoch erlaubt auch HIMEM 3.0 weiterhin die 16bit-Zugriffe wie vorher.
Probleme ergeben sich dann eher, wenn Programme den freien Speicher abfragen wollen und manche davon mit Werten >=64MB nicht klarkommen.
Anmerkung (falls das jemanden interessiert) : Diese knapp 64MB ergeben sich übrigens daher, daß HIMEM.SYS den XMS in 1kB (bzw Kibibyte, wie die Kinder heute sagen) Blöcken belegen - und weil 16Bit eben Werte bis 65535 ausdrücken können, ergeben sich diese 65535 x 1kB = knapp 64MB.
Ab HIMEM.SYS 3.0 können bis zu knapp 4 GB Speicher angewählt werden - dazu müssen die erweiterten Funktionen, die ab v3.0 verfügbar sind (für 32bit Register) verwendet werden - jedoch erlaubt auch HIMEM 3.0 weiterhin die 16bit-Zugriffe wie vorher.
Probleme ergeben sich dann eher, wenn Programme den freien Speicher abfragen wollen und manche davon mit Werten >=64MB nicht klarkommen.
Anmerkung (falls das jemanden interessiert) : Diese knapp 64MB ergeben sich übrigens daher, daß HIMEM.SYS den XMS in 1kB (bzw Kibibyte, wie die Kinder heute sagen) Blöcken belegen - und weil 16Bit eben Werte bis 65535 ausdrücken können, ergeben sich diese 65535 x 1kB = knapp 64MB.
Re: 384MB RAM für DOS zuviel?
Also ich sag' seit 1988 und für immer & ewig kb für 1024 byte...DOSferatu hat geschrieben:Das mit den knapp 64 MB betrifft HIMEM.SYS vor Version 3.0.
Ab HIMEM.SYS 3.0 können bis zu knapp 4 GB Speicher angewählt werden - dazu müssen die erweiterten Funktionen, die ab v3.0 verfügbar sind (für 32bit Register) verwendet werden - jedoch erlaubt auch HIMEM 3.0 weiterhin die 16bit-Zugriffe wie vorher.
Probleme ergeben sich dann eher, wenn Programme den freien Speicher abfragen wollen und manche davon mit Werten >=64MB nicht klarkommen.
Anmerkung (falls das jemanden interessiert) : Diese knapp 64MB ergeben sich übrigens daher, daß HIMEM.SYS den XMS in 1kB (bzw Kibibyte, wie die Kinder heute sagen) Blöcken belegen - und weil 16Bit eben Werte bis 65535 ausdrücken können, ergeben sich diese 65535 x 1kB = knapp 64MB.
zum xms: Ich habe nur Unterlagen zu 2.0 und richte mich auch nur danach. Wenn ich XMS-Speicher allokiere, frage ich über Funktion 08h die Größe des größten zusammenhängenden Speicherblock ab. Dieser wird in kb in AX zurückgeliefert. Da ich bisher (und auch zukünftig) nicht mehr als 4 MB benötigte, habe ich mich nie um XMS 3.0 gekümmert.
Ich dachte bisher immer, dass XMS 3.0 abwärtskompatibel zu 2.0 ist. Und deswegen sollte XMS 3.0 doch für XMS-Bedarfe >= 64MB eine _eigene_ Funktion haben und nicht einfach die Größe des XMS in EAX zurück liefern!
Wenn aber eine eigene Funktion für XMS-Bedarfe >= 64 vorhanden ist, wie kann es dann Inkompatibilitäten mit alten Programmen geben?
Nachtrag: Ich habe eben nach xms 3.0 gegoogelt. Danach ist die Funktion 08h noch identisch zu XMS 2.0. Der XMM sollte doch so schlau sein, wenn er mehr als 64 MB findet, für die XMS 2.0 - FUnktion 08h doch dann den MAximalwert von 65535 zurück zu liefern???
Nachtrag 2:
Nach den XMS 3.0 Spezifikationen handelt es sich bei den erweiterten Funktionen um zusätzliche Funktionen, die eben 32-bit-Werte liefern. Inkompatibilitäten können - wie Dosferatu ja geschrieben hat - eigentlich nur durch unsaubere Anwendungsprogramme entstehen. Bleibt ein Programm allein bei den XMS 2.0 Spezifikationen, so sollte es deswegen keine Probleme geben, egal wie groß der XMS tatsächlich ist.
Re: 384MB RAM für DOS zuviel?
Ja, die erweiterten Funktionen für HIMEM.SYS 3.0 (also die für 4 GB Speicher und mit 32bit Registern) sind nicht dieselben wie bei 2.0! Es sind ZUSÄTZLICHE Funktionen, die es bei 2.0 noch nicht gab und demzufolge nicht benutzt werden. Diese zusätzlichen Funktionen sind leicht zu finden: Man addiert zu den normalen Funktionsnummern einfach $80 (also 128), d.h. setzt das oberste Bit der Funktionsnummer auf 1.
Das bedeutet: HIMEM.SYS 3.0 ist SELBSTVERSTÄNDLICH abwärtskompatibel, denn die normalen Funktionen verhalten sich identisch zu denen von HIMEM.SYS 2.0 und die anderen Funktionsnummern ruft man ja nicht auf.
Entschuldigung, falls meine vorigen Anmerkungen anders verstanden wurden.
Ich habe mir übrigens mal eine Pascal-Unit geschrieben, die diese ganzen XMS-Funktionen benutzt. Erkennnt selbst die HIMEM.SYS-Version und verwendet dementsprechend die Funktionen - kann also, bei Vorhandensein von genügend Speicher und HIMEM 3.0 auch bis zu (knapp) 4 GB belegen. (Die Subroutinen sind in ASM, lediglich die Prozedur-/Funktionsköpfe sind Pascal, um von Pascal-Programmen aufrufbar zu sein.) Ich habe dafür auch - ähnlich wie in einer Unit für den Heap - eine dynamische Speicherverwaltung geschrieben...
An sich finde ich diesen ganzen XMS-Kram schon manchmal recht nützlich.
Das bedeutet: HIMEM.SYS 3.0 ist SELBSTVERSTÄNDLICH abwärtskompatibel, denn die normalen Funktionen verhalten sich identisch zu denen von HIMEM.SYS 2.0 und die anderen Funktionsnummern ruft man ja nicht auf.
Entschuldigung, falls meine vorigen Anmerkungen anders verstanden wurden.
Ich habe mir übrigens mal eine Pascal-Unit geschrieben, die diese ganzen XMS-Funktionen benutzt. Erkennnt selbst die HIMEM.SYS-Version und verwendet dementsprechend die Funktionen - kann also, bei Vorhandensein von genügend Speicher und HIMEM 3.0 auch bis zu (knapp) 4 GB belegen. (Die Subroutinen sind in ASM, lediglich die Prozedur-/Funktionsköpfe sind Pascal, um von Pascal-Programmen aufrufbar zu sein.) Ich habe dafür auch - ähnlich wie in einer Unit für den Heap - eine dynamische Speicherverwaltung geschrieben...
An sich finde ich diesen ganzen XMS-Kram schon manchmal recht nützlich.
Re: 384MB RAM für DOS zuviel?
BTW. Mem von Dose 6.22 liefert, wenn mehr als 64 Mega/mebi/miregal byte vorhanden sind, als XMS Speicher 64Mb+ den belegten XMS Speicher zurück.
siehe auch: http://www.dosforum.de/viewtopic.php?p=1699#p1699
siehe auch: http://www.dosforum.de/viewtopic.php?p=1699#p1699
Re: 384MB RAM für DOS zuviel?
@DosFeratu:
Danke für die Infos. Deine Anmerkungen waren objektiv natürllich komplett richtig. Nur ich habe sie etwas panisch falsch verstanden, und es erst während meiner Nachträge und dem LEsen der XMS 3.0 Spezifkationen gemerkt...
Meine XMS-Unit ist übrigens viel spartanischer. Eine dynamische Speicherverwaltung gibt es nicht. Ich allokiere einmal am Anfang den nötigen XMS und verteile ihn dann intern...
@Dosenware:
Sehr interessant. Die Angabe 64MB + verbrauchter XMS (bei mehr als 64 MB vorhandenen XMS) deutet eigentlich daraufhin, dass der himem.sys den XMS für Applikationen, die nur nach XMS 2.0 allokieren, optimal verteilt.
Danke für die Infos. Deine Anmerkungen waren objektiv natürllich komplett richtig. Nur ich habe sie etwas panisch falsch verstanden, und es erst während meiner Nachträge und dem LEsen der XMS 3.0 Spezifkationen gemerkt...
Meine XMS-Unit ist übrigens viel spartanischer. Eine dynamische Speicherverwaltung gibt es nicht. Ich allokiere einmal am Anfang den nötigen XMS und verteile ihn dann intern...
@Dosenware:
Sehr interessant. Die Angabe 64MB + verbrauchter XMS (bei mehr als 64 MB vorhandenen XMS) deutet eigentlich daraufhin, dass der himem.sys den XMS für Applikationen, die nur nach XMS 2.0 allokieren, optimal verteilt.