Pourquoi existe-t-il trois paramètres différents dans la section [Chemins] de MSDOS.SYS?
Sous Windows 9x, le fichier de configuration MSDOS.SYS contient une [Paths]section dont le contenu ressemble généralement à ceci:
[Paths]
WinDir=C:\WINDOWS
WinBootDir=C:\WINDOWS
HostWinBootDrv=C
Les deux WinDiret WinBootDirpointent vers le répertoire d'installation de Windows, qui est généralement C:\WINDOWS, et HostWinBootDrvpointe vers la lettre de lecteur qui le contient. Le fait d'avoir des paramètres distincts suggère que ceux-ci pourraient être différents. Y a-t-il des situations où c'est le cas? Pourquoi y a-t-il trois paramètres différents? Quel est leur but de toute façon?
Réponses
HostWinBootDrvest le plus simple à expliquer: il s'agit de la compression de disque, c'est-à-dire DoubleSpace / DriveSpace. Ce que fait DriveSpace est de créer un fichier avec un nom comme DRVSPACE.nnn(avec nnnun nombre à trois chiffres) qui contient le contenu compressé du disque. Le système de fichiers compressé se voit attribuer la lettre de lecteur de la partition contenant le fichier, et ce dernier (appelé lecteur hôte dans ce contexte) se voit attribuer une autre lettre de lecteur, ou parfois complètement masquée. Si la partition à partir de laquelle Windows démarre est compressée, HostWinBootDrvpointe vers le lecteur hôte de cette partition, ce qui est par défaut H, tandis que les autres paramètres pointent vers le système de fichiers compressé.
Quant à WinDiret WinBootDir, ce qu'ils font est relativement facile à découvrir. Certaines expérimentations révèlent ce qui suit:
WinDirpointe vers le répertoire dans lequel Windows est installé. La présence de WinDirin MSDOS.SYSest ce qui indiquait IO.SYS(avant Windows Me) qu'il y avait une installation de Windows présente qu'elle devrait être prête à démarrer (par opposition à un simple démarrage à partir d'une invite de commande, comme sur une disquette de démarrage d'urgence). Si WinDirest défini, le noyau en mode réel fera ce qui suit:
- Mettez deux entrées dans la
PATHvariable d'environnement: le répertoire pointé parWinDiret son sous-répertoireCOMMAND; - Créez un sous-répertoire
TEMPsous ce répertoire et pointez les variables d'environnementTEMPetTMPvers lui; - Effacer un drapeau, renvoyé par le
0x2fservice d' interruption0x1611dans le bit 5 du registre BL, quiCOMMAND.COMvérifie s'il faut lancerWIN.COMaprès le traitementAUTOEXEC.BAT; - Démarrez le gestionnaire de configuration de périphérique avant le traitement
CONFIG.SYS(cela peut être supprimé par leSystemReg=0paramètre dans la[Options]section) - Recherchez certains fichiers critiques dans ce répertoire, y compris
SYSTEM.DAT(le registre),COMMAND.COM(qui reviendra au répertoire racine s'il est absent) et des pilotes en mode réel commeHIMEM.SYSetIFSHLP.SYS(qui peuvent être supprimés en définissantDOS=NOAUTOdansCONFIG.SYS); - Stockez le répertoire lui-même dans la
winbootdirvariable d'environnement (tout en minuscules!).
Les deux derniers d'entre eux sont ce qui peut être remplacé par le paramètre WinBootDir: si ce paramètre est également présent, ces fichiers seront recherchés à la WinBootDirplace, et bien sûr, c'est ce répertoire qui se terminera dans la winbootdirvariable d'environnement.
Il y a cependant quelques rides ici, par exemple en ce qui concerne WIN.COM. Lorsque le AUTOEXEC.BATfichier est absent, vide ou ignoré (comme par exemple en mode sans échec), il COMMAND.COMn'est pas chargé et le noyau en mode réel s'exécutera directement à WIN.COMpartir de WinBootDir. Cependant, si AUTOEXEC.BATest présent, COMMAND.COMsera lancé pour le traiter, après quoi il exécutera à son tour la commande WIN, en le lançant WIN.COM… en le recherchant dans PATH, qui par défaut pointe vers WinDir.
Eh bien, très bien, mais pourquoi WinDiret WinBootDirréglages séparés du tout? Ce n'est toujours pas tout à fait clair pour moi, mais d'après le peu que je peux recueillir, il était probablement destiné à prendre en charge le démarrage de Windows sur un réseau local. Dans une telle configuration, DOS serait d' abord chargé à partir d' un système de fichiers normal (ou même lui - même à partir d' une image disque téléchargée sur le réseau), charger les pilotes essentiels comme HIMEM.SYSde WinBootDirsitués sur le même système de fichiers, puis chargez les pilotes de réseau DOS, mapper un partage (contenant WinDir) à sa lettre de lecteur, puis continuez à démarrer à partir de là. Si tel est le scénario prévu, alors même la WIN.COMbizarrerie commence à avoir un sens maintenant: il pourrait y avoir une copie Windows `` principale '' démarrée lors du démarrage normal à partir de WinDir, et une autre copie `` d'urgence '' minimale démarrée en mode sans échec à partir de WinBootDir, lorsque le démarrage du réseau échoue.
Dans tous les cas, les exigences de ce scénario pourraient facilement exiger que ces deux paramètres aient des valeurs différentes. Voici un court fragment d' un document décrivant une telle configuration:
D-2. MSDOS.SYS Sample File for DM9102 : ======================================= [Paths] WinDir=g:\client1 WinBootDir=d:\winboot <== According to RAMDRIVE.SYS assign HostWinBootDrv=c Virtual Drive (D: or E:)
Il existe également un article et une série d'articles de Micho Durdevich ( partie 1 , 2 , 3 , 4 , 5 et 6 ) qui décrivent comment réaliser un démarrage réseau avec Windows 9x.
Ils sont quelque peu peu détaillés sur la façon dont tout cela a fonctionné, mais ces deux sources mentionnent un SETMDIRutilitaire, qui est distribué dans le cadre de Windows 95. Cela implique que le démarrage réseau était probablement un cas d'utilisation prévu par Microsoft.
Winbootdir pointe vers le répertoire dans lequel se trouvent les fichiers de démarrage DOS. Il peut être différent de Windir.
Windir pointe vers le répertoire dans lequel se trouve le registre de l'utilisateur. Sur un réseau, cela peut être différent de celui où Windows est installé.
Winbootdir est utilisé s'il n'y a pas de config.sys / autoexec.bat, pour charger les pilotes comme himem.sys, ifs $ hlp.sys, et co. Il peut s'agir d'une image de démarrage envoyée via le réseau, par exemple.
Windir comme dans 3.0, doit contenir win.com, mais win.com est alors responsable du démarrage de Windows (en exécutant win32.vxd ou quelque chose.)
== Modifier ==
http://reboot.pro/topic/22047-dual-boot-msdos-710-and-630/
Cet article décrit la création d'une installation DOS minimale, à l'aide du DOS de Win98se et d'un MS-DOS 6.22 légèrement modifié.
Des exemples de ce qui se passe lorsque winbootdir et windir sont modifiés. La commande setmdir change windir après le démarrage du système, nous ne l'utilisons pas ici.
http://reboot.pro/topic/18130-ms-dos-7-help-file/
Cette rubrique contient les commentaires de travail pour créer un fichier d'aide qbasic pour DOS 5 à 7 (c'est-à-dire en remplacement de ce qui se trouve sur le CD-ROM).
https://www.betaarchive.com/forum/viewtopic.php?f=72&t=34798&p=401645#p401645
C'est là que nous documentons l'exécution de plusieurs versions de Windows 9x en tant qu'options dans le fichier config.sys. Jusqu'à présent, nous avons surmonté la plupart des problèmes liés au lancement de Win95 à partir de DOS98SE.
https://www.betaarchive.com/forum/viewtopic.php?f=60&t=41489
Il s'agit de la progression de l'exécution de Windows 95 et ME à partir de DOS98SE. Il a un lien vers les fichiers DOS utilisés dans les expériences.
Toutes ces expériences sont basées sur des sessions VPC qui font ce qui est décrit. Par exemple, après que Offer ait publié la construction de c: \ MSDOS7, j'ai exécuté l'expérience avec plusieurs NT5x au-dessus de différentes installations Win98 et ME, en anglais et en allemand. C'est là que j'ai eu l'idée d'utiliser c: \ msdos7.