¿Por qué hay tres configuraciones diferentes en la sección [Rutas] de MSDOS.SYS?

Aug 17 2020

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 WinDiry WinBootDirapuntan al directorio de instalación de Windows, que normalmente es C:\WINDOWS, y HostWinBootDrvapuntan 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

9 user3840170 Aug 17 2020 at 14:22

HostWinBootDrves 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( nnnsiendo 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, HostWinBootDrvapunta 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 WinDiry WinBootDir, lo que hacen es relativamente fácil de descubrir. Algunos experimentos revelan lo siguiente:

WinDirapunta al directorio en el que está instalado Windows. La presencia de WinDirin MSDOS.SYSes 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 WinDirestá configurado, el kernel en modo real hará lo siguiente:

  • Coloque dos entradas en la PATHvariable de entorno: el directorio al que apunta WinDiry su subdirectorio COMMAND;
  • Cree un subdirectorio TEMPen este directorio y apunte las variables de entorno TEMPy TMPhacia él;
  • Borrar una bandera, devuelta por el 0x2fservicio de interrupción 0x1611en el bit 5 del registro BL, que COMMAND.COMverifica para decidir si se inicia WIN.COMdespués del procesamiento AUTOEXEC.BAT;
  • Inicie el administrador de configuración del dispositivo antes de procesar CONFIG.SYS(esto se puede suprimir con la SystemReg=0configuració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 como HIMEM.SYSy IFSHLP.SYS(que puede ser suprimida por el establecimiento DOS=NOAUTOen CONFIG.SYS);
  • Almacene el directorio en sí mismo en la winbootdirvariable 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 WinBootDirlugar y, por supuesto, es ese directorio el que terminará en la winbootdirvariable de entorno.

Sin embargo, hay algunas arrugas aquí, por ejemplo con respecto a WIN.COM. Cuando el AUTOEXEC.BATarchivo está ausente, vacío o se omite (como, por ejemplo, en modo seguro), COMMAND.COMno se carga y el kernel en modo real se ejecutará directamente WIN.COMdesde WinBootDir. Sin embargo, si AUTOEXEC.BATestá presente, COMMAND.COMse 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 WinDiry WinBootDirajustes 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.SYSdesde WinBootDirubicado 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.COMrareza 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 SETMDIRutilidad, que se distribuye como parte de Windows 95. Esto implica que el arranque en red probablemente fue un caso de uso previsto por Microsoft.

2 wendy.krieger Sep 22 2020 at 19:34

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.