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:
Um eine perfekte bzw. schöne Xdos-Installation zu haben, die
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:
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
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.
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.
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
WinFAQ: Startseite | WinFAQ: HTMLMenü | WinFAQ: Java Version
Der Tipp enthält einen Fehler oder Sie haben noch eine Ergänzung dafür? Schreiben Sie uns über die Feedback-Seite an: Feedback-Formular
URL: http://www.winfaq.de/faq_html/Content/tip1500/tip1826.htm
WinFAQ ® Version 9.01 Copyright © 1996/2016 by Frank Ullrich