Aufbau einer 32-Bit-DOS Umgebung (Xdos)

 

---

von: Oliver Riedl

 

Hier wird die Möglichkeit beschrieben, allein mit den Dateien bigmem.drv, ifsmgr.vxd, ios.vxd, rmm.pdr, vmm32.vxd und win.com ein 32-Bit-DOS zu starten, nachdem man eineDOS-Shell (wie command.com oder 4dos.com) in krnl386.exe umbenannt/kopiert hat. Wenn man Xdos startet, gelangt man in ein "32-Bit-DOS", in dem man:

1. Zugriff auf lange Dateinamen,
2. den Vorteil des gegenüber Smartdrv weitaus schnelleren VCACHE,
3. die meisten Windows-Console-Anwendungen und
4. den Vorteil eines blitzschnellen Wechsels (mit "exit" bzw. "win") zwischen Pure-Dos und "32-Bit-DOS" hat.

Um eine perfekte bzw. schöne Xdos-Installation zu haben, die

• mit einem vorhandenen Windows problemlos im gleichen Laufwerk "lebt"
• mit einem einzigen Befehl gestartet werden kann
• ohne automatisches Ausschalten des Rechners zu DOS führt
• nach dem Herunterfahren zu DOS einen Start von Windows erlaubt
• ohne Fehlermeldungen arbeitet,

sind Massnahmen erforderlich, die ein erhebliches Grundwissen voraussetzen und von Microsoft so nicht vorgesehen sind.

 

Xdos ist unsicher und nur für "Bastler". Es kann abstürzen und aus noch unbekannten Gründen einfach den Rechner neu booten und zu Datenverlust führen. Ohne ein funktionierendes Backup sollte man diese Experimente nicht machen. Auf der anderen Seite haben Sie unter Xdos Zugriff auf lange Dateinamen.

 

Zur Vereinfachung werden folgende Bezeichnungen verwendet:

 

DOS	realmode dos 7.x
Windows	normales Windows 9x mit GUI
Xdos	das "32-Bit-Dos" (um das es hier geht)
SYSTEM_X	Umschreibung für einen Vorgang, der an dieser Stelle nicht weiter wichtig oder uns unbekannt ist
(!!)	"buchstäblich übernehmen"
xdos.bat	Batchdatei, mit der Xdos gestartet wird
4start.bat	Batchdatei, deren relative Notwendigkeit weiter unten deutlich wird
------------------	Symbol für Anfang und Ende einer Text-Datei
Shell	command.com oder 4dos.com oder ...

 

Anmerkung zur Shell:

 

Ich empfehle einerseits aus Gründen, die unten deutlicher werden und andererseits wegen der ohnehin gegenüber command.com geradezu phantastischen Möglichkeiten, die Verwendung der 4dos.com.

 

Folgende Quellen sind wichtig bzw. interessant:

• Freier Download von 4dos.com: http://jpsoft.com
• Freier Download von Ralph Browns Interrupt-List: http://www.pobox.com/~ralf
• Download SETREG.COM von Oliver Riedl: <Download>

Ich nehme hier die zwei bedenklichsten Punkte vorweg, erwähne einige Interna, gehe auf den speziellen Vorteil von 4dos.com unter Xdos ein und beschreibe die konkreten Schritte weiter unten.

 

Was tun, wenn beim Herunterfahren von Xdos (mit EXIT) nicht wieder DOS kommt, sondern entgegen dem möglichen Wunsch in DOS zu bleiben, Windows zu starten oder wieder Xdos zu starten, der Rechner ausgeht?

 

Mir ist vorerst nur die Möglichkeit bekannt, mit einem HEX-Editor (notfalls mit edit.com) herumzuhacken (siehe unten). Möglicherweise gibt es aber auch einen Registry-Eintrag, der das automatische Ausschalten verhindern kann. Der ist uns aber noch nicht bekannt.

 

Beim Start von Xdos sowie beim Start vom Windows sucht das System_X die Datei SYSTEM.DAT in dem Verzeichnis, das in der Datei MSDOS.SYS unter [PATHS] als winbootdir angegeben ist. (Ich dachte immer, die besondere (weil kleingeschriebene und mit dem normalen SET-Befehl nicht zu modifizierende) Umgebungsvariable winbootdir würde von System_X gelesen.)

 

Mit einem selbstgebastelten, erweiterten Set-Befehl kann man die %winbootdir% ändern, löschen usw. Das ist dem System egal, da es den Pfad zur Registryerkennt. Auch das Löschen der Pfadangabe zum Windows-Verzeichnis in der Umgebungsvariable PATHS ändert daran nichts. Ich kenne zwei Möglichkeiten, das System beim Start von Xdos daran zu hindern, die Windows-Registry zu lesen.

 

Die erste führt zu (harmlosen) Fehlermeldungen, ist aber auch mit der Unmöglichkeit verbunden, eine (vielleicht später einmal mit einem echten Inhalt versehene) Xdos-Registry einlesen zu lassen. Man benennt in der xdos.bat vor dem eigentlichen Start von Xdos das Windows-Verzeichnis um.

 

Die zweite Möglichkeit setzt voraus, dass man entweder mein beigelegtes Programm SETREG.COM (für das ich keine Verantwortung übernehmen kann) benutzt oder selbst in der Lage ist, ein solches Programm zu erstellen. Es ruft eine amtliche, aber von Microsoft (laut Interrupt-List von Ralph Brown) verschwiegene DOS-Funktion auf, mit der man den Pfad zur Registry setzen, modifizieren oder löschen kann.

 

Nach dem (erfolgreichen) Start von Xdos wird - aus mir unbekannten Gründen - nicht wie beim Start einer gewöhnlichen Sub-Shell die DOS-Umgebung (comspec, path, prompt, temp, tmp usw.) übernommen. Sie ist vollkommen weg und man befindet sich (bei Verwendung von command.com) vor dem leeren Prompt C>. Benutzt man 4dos.com, muss man nicht per Hand die 4start.bat aufrufen, die eine Umgebung einrichtet, denn 4dos.com ruft beim Start automatisch (falls vorhanden) 4start.bat auf.

 

Schritt 1: Sicherstellen, dass beim Einschalten des Rechners nicht Windows geladen wird.

In der MSDOS.SYS unter dem Abschnitt [options] bootgui=0 eintragen.

 

Schritt 2: Kopieren der benötigten Dateien.

Hier wird als Beispiel

• das Verzeichnis C:\XDIR zum Root-Verzeichnis von Xdos gewählt,
• davon ausgegangen, dass Windows im Verzeichnis C:\WINDOWS liegt und
• weiterhin auch, dass die Umgebungsvariable COMSPEC auf eine gültige Shell zeigt.

md c:\xdir

md c:\xdir\system

md c:\xdir\system\vmm32

md c:\xdir\system\iosubsys

(!!) copy c:\windows\win.com c:\xdir\dos.com

copy c:\windows\system\vmm32.vxd c:\xdir\system

(!!) copy %comspec% c:\xdir\system\krnl386.exe

copy c:\windows\system\vmm32\ios.vxd c:\xdir\system\vmm32

copy c:\windows\system\vmm32\ifsmgr.vxd c:\xdir\system\vmm32

copy c:\windows\system\iosubsys\bigmem.drv c:\xdir\system\iosubsys

copy c:\windows\system\iosubsys\rmm.pdr c:\xdir\system\iosubsys

 

Anmerkung zum ersten (!!): Der Name dos.com dient dazu, dass man nicht aus Versehen Windows bzw. Xdos startet, wenn man eigentlich Xdos bzw. Windows starten will.

 

Anmerkung zu vmm32.vxd: Ich glaube, man darf nicht die vmm32.vxd von der Windows-Installations-CD nehmen, da sie ohne Treiber ist.

 

Schritt 3: Erstellen einer c:\xdir\system.ini

Für den Anfang genügt eine >>system.ini<<, die einzig und allein

------------------

[386Enh]

------------------

enthält. Für mögliche weitere Einträge siehe unten.

 

Schritt 4: Notwendige Schönheitsoperationen für den Start

Würde man jetzt (im Verzeichnis c:\xdos) "dos" eingeben, würde er wie in der Einleitung erwähnt in C:\WINDOWS\SYSTEM.DAT lesen (und schreiben?). Man sollte sich eine Batch-Datei (xdos.bat) anfertigen und

in einem Verzeichnis des Pfades (PATHS) ablegen. (Das Verzeichnis xdir muss nicht im Pfad liegen).

 

Möglichkeit 1: xdos.bat ohne Verwendung von SETREG.COM (Xdos startet, es werden aber Fehlermeldungen ausgeben)

------------------

@echo off

ren c:\windows _windows

c:\xdir\dos

------------------

 

Möglichkeit 2: xdos.bat mit SETREG.COM und Xdos-Registy

 

Man erstellt sich eine vorerst leere Registry, indem man erst eine TXT-Datei (zum Beispiel c:\xdir\xdos.reg) mit dem einzigen Inhalt

------------------

REGEDIT4

------------------

erstellt und dann den folgenden Befehl aufruft.

 

(!!) regedit /l:c:\xdir\SYSTEM.DAT /r:c:\xdir\user.dat /c c:\xdir\xdos.reg

 

Die Batchdatei könnte dann so aussehen:

------------------

@echo off

setreg C:\XDIR\SYSTEM.DAT

c:\xdir\dos

------------------

 

Anmerkung zu den Batches: Ich habe mir noch eine Abfrage eingebaut, die sicherstellt, dass sich das System in DOS (und nicht in Xdos oder Windows befindet).

 

Schritt 5: Notwendige Schönheitsoperationen für den Betrieb.

Nach meinen bisherigen Erfahrungen liest (schreibt?) Xdos nicht mehr NACH dem Start in der Registry. Da man damit rechnen muss, dass ein System abstürzt oder dass man nicht in der Lage ist, das automatische Abschalten des Rechners zu umgehen, sollten die Veränderung (Umsetzen der Pfadangabe zur Registry bzw. Umbennenen des Windows-Verzeichnis) jetzt gleich in der 4start.bat rückgängig gemacht werden.

 

Möglichkeit 1: Ohne Verwendung von SETREG.COM (siehe Schritt 4)

 

Man muss bei Verwendung von command.com als krnl386.exe per Hand die 4start.bat aufrufen, die wie folgt aussehen könnte. (Benutzt man 4dos.com als krnl386.exe genügt das blosse Vorhandensein der 4start.bat im Verzeichnis c:\xdir\system)

------------------

@echo off

set comspec=(indivudell anpassen)

prompt (indivudell anpassen)

path (indivudell anpassen)

set temp=(indivudell anpassen)

set tmp=(indivudell anpassen)

rem Da jetzt lange Dateinamen verarbeitet werden

rem schreibe ich windows gross

ren c:\_windows WINDOWS

------------------

 

Möglichkeit 2: Verwendung von SETREG.COM (siehe Schritt 4)

------------------

@echo off

set comspec=(indivudell anpassen)

prompt (indivudell anpassen)

path (indivudell anpassen).

set temp=(indivudell anpassen)

set tmp=(indivudell anpassen)

rem Jetzt braucht's keine Pfadangabe zu SETREG.COM

setreg C:\WINDOWS\SYSTEM.DAT

------------------

 

Wie man das automatische Ausschalten des Rechners verhindert.

 

(!!) 1. Wenn man Assembler-Kenntnisse hat:

Man sucht in der dos.com den ERSTEN Aufruf der Funktion "APM 1.0+ Installation-Check" (ax = 5300h, int 15h) und ändert dann mit einem HEX-Editor das erste Byte vom Befehl "int 15h" (CD 15) zum Befehl "cmp al, 15h" (3C 15). Danach sollte dos.com davon ausgehen, dass kein APM vorhanden ist und mit der normalen Meldung: "Sie können den Rechner jetzt ..." enden.

 

(!!) 2. Wenn man keine Assembler-Kenntnisse hat:

Besteht das Problem darin, dass nicht nur für jede Windows-Version, sondern vermutlich auch für jede Sprachversion der hexadezimale Offset, an dem der Befehl steht, eine andere Adresse hat. Ich kann hier nur eine Angabe für das deutsche Windows98SE machen, in dem die dos.com die Länge 25.399 Byte und die Creation-Time "05.05.1999 22:22" hat.

 

BEI JEDER ANDEREN VERSION FÄHRT DER FOLGENDE HACK ZU VOLLKOMMEN UNVORHERSEHBAREN ERGEBNISSEN BIS HIN ZUM VÖLLIGEN DATENVERLUST.

 

Mit "edit /589 c:\xdir\dos.com" die dos.com öffnen, das letzte Zeichen in Zeile 8 von "Í" auf "<" ändern und speichern.

 

Zur Kontrolle, dass man alles richtig gemacht hat, muss die Ausgabe des Befehls

 

fc/b c:\xdir\dos.com c:\windows\win.com

 

genau Verglichen werden... "00001267: 3C CD" sein.

 

Weitere Möglichkeiten für system.ini's

 

Diese system.ini verhindert das Erstellen einer SWAP

------------------

[386Enh]

Paging=off

------------------

 

Diese system.ini sorgt für eine SWAP, man kann die gleiche SWAP wie Windows verwenden

------------------

[386Enh]

ConservativeSwpafileUsage=1

PagingFile=(individuell anpassen)

MinPagingFileSize=(Zahlenwert in Kilobyte individuell anpassen)

MaxPagingFileSize=(Zahlenwert in Kilobyte individuell anpassen)

 

[vcache]

MinFileCache=(Zahlenwert in Kilobyte individuell anpassen)

MaxFileCache=(Zahlenwert in Kilobyte individuell anpassen)

------------------

 

Wichtiger Geheimtip für das folgende.

Man kann im DOS-Editor mit "Strg+2" (NICHT die 2 auf dem Ziffernblock, sondern die normale 2) das Zeichen <NUL> (also das Zeichen mit dem Ascii-Code 0) eingeben.

 

Wen es nervt, dass Xdos die Dateien ios.log und wnbootng.sts erstellt, der kann mit einem Hexeditor oder edit.com in ios.vxd den Eintrag "IOS.LOG" in <NUL>OS.LOG und in vmm32.vxd den Eintrag "WNBOOTNG.STS" in <NUL>NBOOTNG.STS ändern.

 

Wen es stört, dass die "Handvoll" Dateien von Xdos gleich drei Unterverzeichnisse (system, system/vmm32 und system/iosubsys) brauchen, der kann mit einem Hexeditor oder edit.com in dos.com den Eintrag "system\vmm32.vxd" in "vmm32.vxd<NUL>32.vxd" in ios.vxd den Eintrag "IOSUBSYS\*.vxd" in "IOSUB\..\*.vxd" und in vmm32.vxd den Eintrag "VMM32\*.VXD" in "VM\..\*.VXD" ändern und danach alle Dateien im Verzeichnis C:\Xdos halten.

 

 

DOS-CDROM-Treiber ohne mscdex.exe mit den Windows-CDROM-Treiber

 

Hier wird beschrieben, wie man unter "Xdos" die Windows-CDROM-Treiber einbindet. Man benötigt neben den in meiner Anleitung zur "Installation von xdos" aufgeführten Dateien/Treibern einerseits die folgenden Treiber

 

C:\WINDOWS\SYSTEM\BIOS.VXD

C:\WINDOWS\SYSTEM\PCI.VXD

C:\WINDOWS\SYSTEM\IOSUBSYS\CDFS.VXD

C:\WINDOWS\SYSTEM\IOSUBSYS\CDTSD.VXD

C:\WINDOWS\SYSTEM\IOSUBSYS\CDVSD.VXD

C:\WINDOWS\SYSTEM\IOSUBSYS\ESDI_506.PDR

C:\WINDOWS\SYSTEM\IOSUBSYS\VOLTRACK.VXD

 

und andererseits die Registry-Einträge aus

 

HKEY_LOCAL_MACHINE\ENUM\BIOS

HKEY_LOCAL_MACHINE\ENUM\MF

HKEY_LOCAL_MACHINE\ENUM\PCI

HKEY_LOCAL_MACHINE\ENUM\Root

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VCDFSD

 

Einige irrelevante Unterpunkte dieser Registry-Einträge können (und müssen zur Vermeidung von Fehlermeldungen) gelöscht werden.

 

Nach der Einbindung verlängert sich die Startzeit bei meinem Rechner (850MHz) von ca. 3 auf ca. 6 Sekunden.

 

 

Einige Tips, um ein auf CD gebranntes Windows-9x mit und ohne eingehängte Festplatte(n) von CD zu booten

 

Ich beschreibe hier die Möglichkeit, nahezu die gesamte (vermutlich immer notwendige RamDisk) als Cache und TEMP-Verzeichnis zu Verfügung zu haben.

 

Startet man von einer Boot-CD, die mit "Harddisk-Emulation" erstellt wurde, dann beansprucht die Boot-CD die Laufwerksnummer 128 (erste Festplatte) und macht dadurch (zumindest bei Vorhandensein von 2 Festplatten) jede Art von Zugriff auf die erste Festplatte unmöglich.

 

Man kann einer Boot-CD, die mit "Floppy-Emulation" erstellt wurde, durch folgenden Trick sogar dann den Laufwerksbuchstaben C: zuordnen, wenn das Festplattenlaufwerk C: vorhanden und gültig ist.

 

subst z: c:\

xmsdsk 16 y: /y

subst c: y:\

xmsdsk /y /u

 

Zeile 1 ermöglicht den Zugriff auf C: mit Z:,

Zeile 2 lädt temporär eine kleine Ramdisk auf Y:,

Zeile 3 lässt den Laufwerksbuchstaben C: auf Y: zeigen,

Zeile 4 entlädt die temporäre Ramdisk und macht C: damit für MSCDEX frei.

 

Nach diesem Eingriff ist Y: ungültig, aber NICHT frei. Ein Zugriff auf Y: führt zum Hänger. Es empfiehlt sich daher, vor dem Ende der autoexec.bat (mit subst) Y: auf ein gültiges Laufwerk zeigen zu lassen.

 

Durch die Möglichkeit, dem CDROM-Laufwerk den Buchstaben C: zuzuordnen, sind kaum Veränderungen nötig, um ein auf der Festplatte C: vorhandenes Windows-9x auf CD zu brennen und von dort zu starten. Die Registry (SYSTEM.DAT + user.dat) muss vor dem Starten von Windows auf eine RamDisk kopiert werden und in der MSDOS.SYS muss unter dem Abschnitt [PATHS] der Eintrag "winbootdir=" auf das RamDisk-Verzeichnis zeigen. Bei Verwendung des Browsers Mozilla muss (unter windows-98) nur in die Datei C:\WINDOWS\Anwendungsdaten\Mozilla\Firefox\profiles.ini ein Verzeichnis auf der RamDisk angegeben werden. Andere Anwendungen, die Daten schreiben müssen oder wollen, müssen in ähnlicher Weise auf die RamDisk umgelenkt werden.

 

Verbesserungsvorschläge zu diesen Tipp nehmen wir gern entgegen

---