¿Por qué hay tres configuraciones diferentes en la sección [Rutas] de MSDOS.SYS?
En Windows 9x, el archivo de configuración MSDOS.SYS contiene una [Paths]
sección cuyo contenido suele verse así:
[Paths]
WinDir=C:\WINDOWS
WinBootDir=C:\WINDOWS
HostWinBootDrv=C
Ambos WinDir
y WinBootDir
apuntan al directorio de instalación de Windows, que normalmente es C:\WINDOWS
, y HostWinBootDrv
apuntan a la letra de unidad que lo contiene. Tener distintos escenarios sugiere que potencialmente estos podrían ser diferentes. ¿Hay situaciones en las que este sea el caso? ¿Por qué hay tres configuraciones diferentes? ¿Cuál es su propósito de todos modos?
Respuestas
HostWinBootDrv
es el más fácil de explicar: tiene que ver con la compresión de disco, es decir, DoubleSpace / DriveSpace. Lo que hace DriveSpace es crear un archivo con un nombre como DRVSPACE.nnn
( nnn
siendo un número de tres dígitos) que contiene el contenido comprimido del disco. Al sistema de archivos comprimido se le asigna la letra de unidad de la partición que contiene el archivo, y a esta última (llamada unidad de host en este contexto) se le asigna otra letra de unidad, o algunas veces se oculta por completo. Si la partición desde la que se inicia Windows está comprimida, HostWinBootDrv
apunta a la unidad de host de esa partición, que de forma predeterminada es H
, mientras que las otras configuraciones apuntan al sistema de archivos comprimido.
En cuanto a WinDir
y WinBootDir
, lo que hacen es relativamente fácil de descubrir. Algunos experimentos revelan lo siguiente:
WinDir
apunta al directorio en el que está instalado Windows. La presencia de WinDir
in MSDOS.SYS
es lo que indicaba IO.SYS
(antes de Windows Me) que había una instalación de Windows presente que debería estar preparada para iniciarse (en lugar de simplemente arrancar en un símbolo del sistema, como en un disquete de arranque de emergencia). Si WinDir
está configurado, el kernel en modo real hará lo siguiente:
- Coloque dos entradas en la
PATH
variable de entorno: el directorio al que apuntaWinDir
y su subdirectorioCOMMAND
; - Cree un subdirectorio
TEMP
en este directorio y apunte las variables de entornoTEMP
yTMP
hacia él; - Borrar una bandera, devuelta por el
0x2f
servicio de interrupción0x1611
en el bit 5 del registro BL, queCOMMAND.COM
verifica para decidir si se iniciaWIN.COM
después del procesamientoAUTOEXEC.BAT
; - Inicie el administrador de configuración del dispositivo antes de procesar
CONFIG.SYS
(esto se puede suprimir con laSystemReg=0
configuración en la[Options]
sección) - Buscar ciertos archivos críticos en este directorio, incluyendo
SYSTEM.DAT
(el Registro),COMMAND.COM
(que volverá a caer en el directorio raíz si ausentes) y controladores en modo real comoHIMEM.SYS
yIFSHLP.SYS
(que puede ser suprimida por el establecimientoDOS=NOAUTO
enCONFIG.SYS
); - Almacene el directorio en sí mismo en la
winbootdir
variable de entorno (¡todo en minúsculas!).
Los dos últimos de estos son los que se pueden anular mediante la configuración WinBootDir
: si esa configuración también está presente, esos archivos se buscarán en su WinBootDir
lugar y, por supuesto, es ese directorio el que terminará en la winbootdir
variable de entorno.
Sin embargo, hay algunas arrugas aquí, por ejemplo con respecto a WIN.COM
. Cuando el AUTOEXEC.BAT
archivo está ausente, vacío o se omite (como, por ejemplo, en modo seguro), COMMAND.COM
no se carga y el kernel en modo real se ejecutará directamente WIN.COM
desde WinBootDir
. Sin embargo, si AUTOEXEC.BAT
está presente, COMMAND.COM
se lanzará para procesarlo, luego de lo cual a su vez ejecutará el comando WIN
, lanzándolo WIN.COM
… buscándolo en PATH
, que por defecto apunta a WinDir
.
Bueno, muy bien, pero ¿por qué son WinDir
y WinBootDir
ajustes separados en absoluto? Todavía no está del todo claro para mí, pero por lo poco que puedo reunir, probablemente estaba destinado a admitir el arranque de Windows a través de una LAN. En tal configuración, DOS primero se carga desde un sistema de archivos normal (o incluso la propia imagen de disco descargado a través de la red), cargar los controladores esenciales como HIMEM.SYS
desde WinBootDir
ubicado en el mismo sistema de archivos, a continuación, cargar los controladores de red de DOS, asignar un recurso compartido (que contiene WinDir
) a su letra de unidad y luego continúe arrancando desde allí. Si ese es el escenario previsto, incluso la WIN.COM
rareza comienza a tener sentido ahora: podría haber una copia 'principal' de Windows iniciada cuando se inicia normalmente desde WinDir
, y otra copia mínima de 'emergencia' iniciada en Modo seguro desde WinBootDir
, cuando falla el inicio de la red.
En cualquier caso, los requisitos de este escenario podrían requerir fácilmente que esas dos configuraciones tengan valores diferentes. Aquí hay un breve fragmento de un documento que describe tal configuración:
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:)
También hay un documento y una serie de artículos de Micho Durdevich ( parte 1 , 2 , 3 , 4 , 5 y 6 ) que describen cómo lograr el arranque en red con Windows 9x.
Son algo escasos en los detalles de cómo funcionó todo esto, pero ambas fuentes mencionan una SETMDIR
utilidad, que se distribuye como parte de Windows 95. Esto implica que el arranque en red probablemente fue un caso de uso previsto por Microsoft.
Winbootdir apunta al directorio en el que se encuentran los archivos de inicio de DOS. Puede ser diferente a Windir.
Windir apunta al directorio en el que se encuentra el registro del usuario. En una red, esto puede ser diferente al lugar donde está instalado Windows.
Winbootdir se usa si no hay config.sys / autoexec.bat, para cargar los controladores como himem.sys, ifs $ hlp.sys y co. Podría estar en una imagen de arranque enviada a través de la red, por ejemplo.
Windir como en 3.0, necesita contener win.com, pero win.com es responsable de iniciar Windows (ejecutando win32.vxd o algo así).
== Editar ==
http://reboot.pro/topic/22047-dual-boot-msdos-710-and-630/
Esta publicación describe la creación de una configuración mínima de DOS, usando el DOS de Win98se, y un MS-DOS 6.22 ligeramente modificado.
Ejemplos de lo que sucede cuando se cambian winbootdir y windir. El comando setmdir cambia windir después de que se inicia el sistema, no lo estamos usando aquí.
http://reboot.pro/topic/18130-ms-dos-7-help-file/
Este tema contiene los comentarios de trabajo para crear un archivo de ayuda qbasic para DOS 5 a 7 (es decir, como reemplazo de lo que está en el CDROM).
https://www.betaarchive.com/forum/viewtopic.php?f=72&t=34798&p=401645#p401645
Aquí es donde estamos documentando la ejecución de múltiples versiones de Windows 9x como opciones en config.sys. Hasta ahora hemos superado la mayoría de los problemas al iniciar Win95 desde DOS98SE.
https://www.betaarchive.com/forum/viewtopic.php?f=60&t=41489
Este es un progreso en la ejecución de Windows 95 y ME desde DOS98SE. Tiene un enlace a los archivos de DOS utilizados en los experimentos.
Todos estos experimentos se basan en sesiones de VPC que hacen lo que se describe. Por ejemplo, después de que Offer publicó la construcción de c: \ MSDOS7, ejecuté el experimento con varios NT5x sobre las diferentes instalaciones de Win98 y ME, en inglés y en alemán. Es de donde tuve la idea de usar c: \ msdos7.