Si DOS es una tarea única, ¿cómo fue posible la multitarea en la versión anterior de Windows?

Leí que DOS es un sistema operativo de una sola tarea.

Pero si las versiones antiguas de Windows (¿también incluye Windows 95?) Eran solo envoltorios de DOS, ¿cómo podría Windows ejecutarse como un sistema operativo multitarea?

Windows 95

Windows 95 fue mucho más que "solo un contenedor" para MS-DOS . Citando a Raymond Chen:

MS-DOS sirvió para dos propósitos en Windows 95.

• Sirvió como el gestor de arranque.
• Actuó como la capa de controlador de dispositivo heredado de 16 bits.

Windows 95 en realidad enganchó / anuló casi todo MS-DOS, manteniéndolo como una capa de compatibilidad mientras realizaba todo el trabajo pesado. También implementó la multitarea preventiva para programas de 32 bits.

Previo a Windows 95

Windows 3.xy anteriores eran en su mayoría de 16 bits (con la excepción de Win32s, una capa de compatibilidad que une 16 y 32, pero ignoraremos eso aquí), eran más dependientes de DOS y usaban solo multitarea cooperativa, eso es aquel en el que no obligan a un programa en ejecución a desconectarse; esperan a que el programa en ejecución ceda el control (básicamente, dicen "Ya terminé" diciéndole al sistema operativo que ejecute el próximo programa que está esperando).

La multitarea fue cooperativa, al igual que en las versiones anteriores de MacOS (aunque a diferencia de Multitarea DOS 4.x, que lucía multitarea preventiva). Una tarea tenía que ceder al sistema operativo para programar una tarea diferente. Los rendimientos se incorporaron a ciertas llamadas API, en particular el procesamiento de mensajes. Mientras una tarea procesara los mensajes de manera oportuna, todo fue genial. Si una tarea dejaba de procesar mensajes y estaba ocupado ejecutando algún ciclo de procesamiento, la multitarea ya no existía.

Arquitectura de Windows 3.x

En cuanto a cómo los primeros programas de Windows cederían el control:

Windows 3.1 utiliza la multitarea cooperativa, lo que significa que cada aplicación que está en proceso de ejecución recibe instrucciones de verificar periódicamente una cola de mensajes para averiguar si alguna otra aplicación solicita el uso de la CPU y, de ser así, ceder el control a esa aplicación . Sin embargo, muchas aplicaciones de Windows 3.1 verificarían la cola de mensajes con poca frecuencia, o ninguna, y monopolizarían el control de la CPU durante el tiempo que requirieran. Un sistema multitarea preventivo como Windows 95 quitará el control de la CPU de una aplicación en ejecución y la distribuirá a aquellos que tengan una mayor prioridad en función de las necesidades del sistema.

fuente

Todo lo que vería DOS es esta aplicación única (Windows u otra) ejecutándose, que pasaría el control sin salir. En teoría, la multitarea preventiva posiblemente se puede implementar sobre DOS de todos modos con el uso de un reloj en tiempo real y las interrupciones de hardware para dar el control al planificador por la fuerza. Como comenta Tonny , esto fue hecho por algunos sistemas operativos que se ejecutan sobre DOS.

386 modo mejorado?

Nota: ha habido algunos comentarios sobre el modo mejorado 386 de Windows 3.x que es de 32 bits y que admite la multitarea preventiva.

Este es un caso interesante. Para resumir la publicación de blog vinculada , el modo mejorado 386 era básicamente un hipervisor de 32 bits, que ejecutaba máquinas virtuales. Dentro de una de esas máquinas virtuales se ejecutaba el modo estándar de Windows 3.x, que hace todo lo mencionado anteriormente.

MS-DOS también se ejecutaría dentro de esas máquinas virtuales, y aparentemente eran multitarea preventivas, por lo que parece que el hipervisor de modo mejorado 386 compartirá segmentos de tiempo de CPU entre las máquinas virtuales (una de las cuales ejecutó 3.xy normal y otras que ejecutaron MS -DOS), y cada VM hará lo suyo: 3.x cooperaría multitarea, mientras que MS-DOS tendría una única tarea.

MS-DOS

DOS en sí era una tarea única en papel, pero tenía soporte para programas TSR , que permanecería en segundo plano hasta que se activara por una interrupción de hardware. Lejos de ser una verdadera multitarea, pero tampoco de una sola tarea.

¿Toda esta charla de lo mordido? ¡Pregunté sobre la multitarea!

Bueno, estrictamente hablando, el bit-ness y la multitarea no dependen el uno del otro. Debería ser posible implementar cualquier modo multitarea en cualquier bit-ness. Sin embargo, el cambio de procesadores de 16 bits a procesadores de 32 bits también introdujo otra funcionalidad de hardware que podría haber hecho que la multitarea preventiva fuera más fácil de implementar.

Además, dado que los programas de 32 bits eran nuevos, era más fácil hacerlos funcionar cuando se los cambiaba por la fuerza, lo que podría haber roto algunos programas heredados de 16 bits.

Por supuesto, todo esto es especulación. Si realmente desea saber por qué MS no implementó la multitarea preventiva en Windows 3.x (a pesar del modo mejorado 386), tendrá que preguntarle a alguien que trabajó allí.

Además, quería corregir su suposición de que Windows 95 era solo un contenedor para DOS;)

Continuamente ejecutó un solo programa, el llamado windows. Ese reparte el tiempo de CPU (y otros recursos) entre diferentes programas.

Considere esta analogía:

Tiene una oficina que solo puede tener una persona a la vez (esa persona se llama señor o señora DOS). Esa persona trabaja en una cosa a la vez. Por ejemplo, llama a una sola persona y comienza a chatear las 24 horas del día, los 7 días de la semana con él.

Ahora reemplazas a esa persona con el Sr. secretario. (ventanas) Llamará a alguien y hablará todo el tiempo con él (sigue siendo una sola tarea). Luego, después de algún tiempo, la otra persona dirá "Ya he hablado lo suficiente por ahora. Ve a hablar con alguien más y llámame en un momento".

El señor secretario llamará a la otra persona. Chatea con ese hasta que esa persona diga lo mismo. Luego llamará a la siguiente persona hasta que esté al final de la lista de personas para hablar. En ese momento comenzará nuevamente en la parte superior.

• En términos técnicos, esto se llama multitarea cooperativa. Requiere que la otra persona diga que tuvo suficiente tiempo de CPU. Si uno no hace eso, todo se desmorona.
• Los sistemas modernos son mucho más inteligentes. Incluyendo la multitarea preventiva. Piense en la secretaria que pone una alarma y corta a la otra persona después de 5 minutos. "Eso es agradable Jane. Pero tengo que hablar con Joe ahora. Te llamaré en un momento. - Haz clic".

Si agrega múltiples procesadores se vuelve aún más complicado. :)

En un sistema operativo moderno, el sistema operativo controla todos los recursos de hardware y las aplicaciones en ejecución se guardan en cajas de arena. No se permite que una aplicación acceda a la memoria que el sistema operativo no ha asignado a esa aplicación, y no puede acceder directamente a los dispositivos de hardware en la computadora. Si se requiere acceso al hardware, la aplicación debe comunicarse a través de los controladores del dispositivo.

El sistema operativo puede aplicar este control, ya que obliga a la CPU a entrar en modo protegido .

DOS, por otro lado, nunca ingresa al modo protegido, sino que permanece en modo real *. En modo real, las aplicaciones en ejecución pueden realizar cualquier cosa que quieran, por ejemplo, acceder directamente al hardware. Pero una aplicación que se ejecuta en modo real también puede indicarle a la CPU que entre en modo protegido.

Y esta última parte permite que aplicaciones como Windows 95 inicien un entorno de subprocesos múltiples aunque básicamente se iniciaron desde DOS.

DOS (Sistema operativo de disco) era, afaik, no mucho más que un sistema de gestión de archivos. Proporcionó un sistema de archivos, mecanismos para navegar por el sistema de archivos, algunas herramientas y la posibilidad de iniciar aplicaciones. También permitió que algunas aplicaciones permanecieran residentes, por ejemplo, controladores de mouse y emuladores EMM. Pero no intentó controlar el hardware de la computadora como lo hace un SO moderno.

* Cuando se creó DOS por primera vez en los años 70, el modo protegido no existía en la CPU. No fue hasta el procesador 80286 a mediados de los 80 que el modo protegido se convirtió en parte de la CPU.

Antes de Windows 3.x, que era la primera versión para aplicaciones DOS multitareas, había programas como DesqView que podían hacer lo mismo. Si uno, por ejemplo, ejecuta tres sesiones de DOS a la vez, DesqView crearía cuatro máquinas virtuales. Las tres sesiones de DOS pensarían que "poseían" la máquina completa, excepto que ninguna de ellas realmente realizaría E / S de archivo. En cambio, la versión de DOS que se ejecuta en cada sesión se corregirá para que reenvíe cualquier solicitud de E / S de archivo a una sesión especial, que se dedicó a ese propósito. Dado que el hardware de modo de texto de la PC mostraría continuamente los contenidos de un área de memoria como caracteres; DesqView podría permitir que cada sesión tenga su propia pantalla virtual al asignar el rango 0xB8000-0xB9FFF de cada sesión a su propia área de RAM, y copiando periódicamente el área de la aplicación actual al búfer de pantalla física. El soporte gráfico fue mucho más difícil, porque 256 K de RAM en la placa de visualización se controlaron usando 64 K de espacio de direcciones, algunos registros de E / S y algún hardware "interesante" que requería que las cosas se leyeran y escribieran en ciertas secuencias específicas. En el modo de texto, cuando una aplicación escribió algo en el búfer de texto que se escribió, DesqView podría establecer un indicador que indique que debe copiarse en la pantalla en el siguiente tic del temporizador; solo la primera escritura en el búfer de texto en un momento determinado requeriría la intervención de DesqView; todos los demás se consolidarían al siguiente tic del temporizador. porque 256 K de RAM en el panel de visualización se controlaron usando 64 K de espacio de direcciones, algunos registros de E / S y un hardware "interesante" que requería que las cosas se leyeran y escribieran en ciertas secuencias específicas. En el modo de texto, cuando una aplicación escribió algo en el búfer de texto que se escribió, DesqView podría establecer un indicador que indicara que debe copiarse en la pantalla en el siguiente tic del temporizador; solo la primera escritura en el búfer de texto en un momento determinado requeriría la intervención de DesqView; todos los demás se consolidarían al siguiente tic del temporizador. porque 256 K de RAM en el panel de visualización se controlaron usando 64 K de espacio de direcciones, algunos registros de E / S y un hardware "interesante" que requería que las cosas se leyeran y escribieran en ciertas secuencias específicas. En el modo de texto, cuando una aplicación escribió algo en el búfer de texto que se escribió, DesqView podría establecer un indicador que indique que debe copiarse en la pantalla en el siguiente tic del temporizador; solo la primera escritura en el búfer de texto en un momento determinado requeriría la intervención de DesqView; todos los demás se consolidarían al siguiente tic del temporizador. DesqView podría establecer un indicador que indique que debe copiarse en la pantalla en el siguiente tic del temporizador; solo la primera escritura en el búfer de texto en un momento determinado requeriría la intervención de DesqView; todos los demás se consolidarían al siguiente tic del temporizador. DesqView podría establecer un indicador que indique que debe copiarse en la pantalla en el siguiente tic del temporizador; solo la primera escritura en el búfer de texto en un momento determinado requeriría la intervención de DesqView; todos los demás se consolidarían al siguiente tic del temporizador.

Por el contrario, el modo de virtualización de gráficos requeriría DeskView para atrapar cada escritura individual para mostrar la memoria o los registros de E / S. Dado que esto ralentizaría las escrituras de memoria en un factor de aproximadamente 100, y los programas gráficos tenían que escribir muchos más datos que los programas de texto, la virtualización en tiempo real de la mayoría del software gráfico no era práctica. En cambio, los gráficos se manejaron al tener cualquier aplicación que no fuera de primer plano que intentara hacer una pausa de gráficos hasta que se convirtiera en la aplicación de primer plano, y luego darle un control total sobre la pantalla. Cuando el control cambia a una aplicación diferente, DesqView intenta hacer una copia del estado de todos los registros gráficos y luego cambia. Al volver a la aplicación gráfica, DesqView restauraría el estado guardado.

En cierto modo, las aplicaciones de DOS no gráficas multitarea eran más fáciles que las aplicaciones de Windows multitarea porque había muy pocos recursos compartidos y las aplicaciones no tenían que interactuar entre sí. En Windows, por el contrario, es necesario lidiar con cosas como el portapapeles o la posibilidad de que las ventanas de un programa se muevan de tal manera que oscurezcan las de otro. Windows 95 fue la primera versión de Windows que pudo superar tales limitaciones al incluir cosas como un sistema de ventanas que podía acomodar que un área de la pantalla no estuviera disponible mientras el código intentaba atraerlo (con el efecto de que el dibujo quedaría oculto )

La multitarea no es más que una ilusión de ejecutar aplicaciones simultáneamente. Se percibe como una ejecución simultánea por su parte, pero de hecho los procesos A, B y C comparten el tiempo de CPU en este orden: A, B, C, A, B, C, A, B ... simplemente se encienden y fuera muy rápido. No hay dos procesos en ejecución al mismo tiempo.

Por lo tanto, es perfectamente posible realizar tareas múltiples de MS-DOS haciendo que pause un proceso, ejecute el siguiente por un período corto de tiempo, pause ese, salte al primero, y así sucesivamente.

La multitarea es solo una característica inteligente desarrollada cuando las CPU comenzaron a ser lo suficientemente rápidas para seguir girando a través de estos procesos y hacer que parezca simultáneo para el usuario final.

Para aquellos que recuerdan, los juegos todavía se ejecutaban en DOS4GW porque Windows era demasiado lento.

Aunque solo puede enfocarse en una tarea, lo que haría es un simple paso de pasar rápidamente de una a otra. De esta manera, parecía que era multitarea, pero en realidad solo se enfoca en 1, luego en otro, luego en otro, etc.

Una cosa que no vi mencionada aquí es algo interesante:

Windows 3.0 no era un sistema multitarea preventivo, era cooperativo como todas las versiones de MacOS hasta OS X: una aplicación tenía que regresar de una llamada antes de que cualquier otra aplicación pudiera realizar alguna acción.

Sin embargo, como me recordó un comentarista, las aplicaciones de DOS fueron multitarea. Esto se debe a que no se escribieron para tareas múltiples "cooperativas" (esto siempre debe integrarse en los sistemas que lo usan).

En ese momento había programas llamados TSR (Residente de terminación-permanencia) que tomaron el lugar de los controladores de dispositivos actuales. Estos controladores se ejecutarían de forma independiente, generalmente en su propio hilo al insertarse en uno de los controladores de eventos del sistema operativo. Windows generalmente no los conocía, corrían a un nivel inferior.

En realidad, no se trataba de aplicaciones de Windows, sino de cómo se realizaban todas las actividades de subprocesamiento antes de Windows 3.1, como controladores de impresora, controladores com, etc.

Aunque Windows 3.1 era multitarea, DOS no lo era, pero Windows 3.1 simplemente eliminó los dos y se hizo cargo cuando comenzó (en aquel entonces a menudo iniciaba Windows desde un indicador de DOS).

Buena pregunta. En MS-DOS, el núcleo era monolítico, lo que significa que solo manejaba una tarea a la vez, en comparación con el nuevo núcleo moderno que se implementó en Windows 9x y la versión actual. Puedes ver más aquí .