¿Cómo fue posible realizar múltiples tareas en versiones anteriores de Windows?
Teniendo en cuenta que DOS era un sistema operativo de una sola tarea y los vínculos que tenía con las primeras versiones de Windows, ¿cómo se las arreglaban las versiones anteriores de Windows para realizar tareas múltiples? La publicación de preguntas y respuestas de SuperUser de hoy analiza las respuestas a esta pregunta.
La sesión de Preguntas y Respuestas de hoy nos llega por cortesía de SuperUser, una subdivisión de Stack Exchange, un grupo de sitios web de preguntas y respuestas impulsado por la comunidad..
Captura de pantalla de Windows 95 cortesía de Wikipedia.
La pregunta
El lector SuperUser ¿LeNoob quiere saber cómo las versiones anteriores de Windows podían ejecutarse como sistemas multitarea ?:
Leí que DOS es un sistema operativo de una sola tarea. Pero si las versiones anteriores de Windows (¿también incluyen Windows 95?) Eran solo envoltorios para DOS, ¿cómo podrían ejecutarse como un sistema operativo multitarea??
¡Buena pregunta! ¿Cómo las versiones anteriores de Windows lograron ejecutarse como sistemas multitarea??
La respuesta
Los colaboradores de Superusuario Bob y Pete tienen la respuesta para nosotros. En primer lugar, Bob:
Windows 95 era mucho más que "solo un contenedor" para MS-DOS. Citando a Raymond Chen:
- MS-DOS sirvió dos propósitos en Windows 95: 1.) Sirvió como el cargador de arranque. & 2.) Actuó como la capa de controlador de dispositivo heredado de 16 bits.
Windows 95 en realidad enganchó / anuló casi todos los MS-DOS, manteniéndolo como una capa de compatibilidad mientras hacía todo el trabajo pesado. También implementó multitarea preventiva para programas de 32 bits.
Pre-Windows 95
Windows 3.xy las versiones anteriores eran en su mayoría de 16 bits (con la excepción de Win32s, un tipo de capa de compatibilidad que une a 16 y 32, pero ignoraremos eso aquí), eran más dependientes de DOS y solo usaban tareas múltiples cooperativas - esa es la que no obliga a un programa en ejecución a apagarse; esperan a que el programa en ejecución ceda el control (básicamente, dicen "Ya terminé" al decirle al sistema operativo que ejecute el siguiente programa que está esperando).
- La multitarea fue cooperativa, al igual que en las versiones anteriores de MacOS (aunque a diferencia de la multitarea DOS 4.x, que contaba con la multitarea preventiva). Una tarea tenía que ceder al sistema operativo para programar una tarea diferente. Los rendimientos se integraron en ciertas llamadas a la API, especialmente el procesamiento de mensajes. Mientras una tarea procesara los mensajes de manera oportuna, todo fue excelente. Si una tarea dejaba de procesar mensajes y estaba ocupada ejecutando algo de bucle de procesamiento, ya no era necesario realizar múltiples tareas.
Arquitectura de Windows 3.x
En cuanto a cómo los primeros programas de Windows darían el control:
- Windows 3.1 utiliza la multitarea cooperativa, lo que significa que a cada aplicación que se está ejecutando se le indica que revise periódicamente la cola de mensajes para saber si alguna otra aplicación está solicitando el uso de la CPU y, de ser así, ceder el control a esa aplicacion Sin embargo, muchas aplicaciones de Windows 3.1 verificarían la cola de mensajes con poca frecuencia, o no lo harían, y monopolizarían el control de la CPU durante todo el tiempo que necesitaran. Un sistema multitarea preventivo como Windows 95 quitará el control de la CPU de una aplicación en ejecución y lo distribuirá entre aquellos que tienen una prioridad más alta según las necesidades del sistema.
Fuente
Todo lo que DOS vería es la ejecución de esta aplicación única (Windows u otra), que pasaría el control sin salir. En teoría, la multitarea preventiva posiblemente se puede implementar en la parte superior del DOS de todos modos con el uso de un reloj de tiempo real y las interrupciones de hardware para dar el control al programador a la fuerza. Como comenta Tonny, esto fue hecho por algunos sistemas operativos que se ejecutan sobre DOS.
Modo mejorado 386?
Nota: ha habido algunos comentarios sobre el modo 386 mejorado de Windows 3.x que es de 32 bits y es compatible con la multitarea preventiva.
Este es un caso interesante. Para resumir la publicación del blog vinculado, el modo 386 mejorado era básicamente un hipervisor de 32 bits, que ejecutaba máquinas virtuales. Dentro de una de esas máquinas virtuales se ejecutó 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 tenían tareas múltiples de forma preventiva, 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 funcionó con 3.x y otros que ejecutaron MS-DOS), y cada VM hará lo suyo: 3.x sería cooperativamente multi-tarea, mientras que MS-DOS sería de una sola tarea.
MS-DOS
El DOS en sí era una tarea única en papel, pero tenía soporte para programas TSR que se mantendrían en segundo plano hasta que se desencadenara una interrupción de hardware. Lejos de la verdadera multitarea, pero tampoco de una sola tarea.
¿Toda esta charla de bit-ness? Le pregunté acerca de la multitarea!
Bueno, estrictamente hablando, el bit-ness y la multitarea no dependen unos de otros. Debería ser posible implementar cualquier modo multitarea en cualquier bit-ness. Sin embargo, el paso de los procesadores de 16 bits a los procesadores de 32 bits también introdujo otras funcionalidades de hardware que podrían haber facilitado la ejecución de tareas múltiples preventivas..
Además, dado que los programas de 32 bits eran nuevos, era más fácil hacer que funcionaran cuando se los desconectó por la fuerza, lo que podría haber roto algunos programas heredados de 16 bits..
Por supuesto, esto es toda especulación. Si realmente quiere 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.
Seguido por la respuesta de Pete:
En un sistema operativo moderno, el sistema operativo controla todos los recursos de hardware, y las aplicaciones en ejecución se mantienen en entornos limitados. 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 controladores de dispositivo.
El sistema operativo puede aplicar este control, ya que obliga a la CPU a entrar en modo protegido.
DOS, por otro lado, nunca entra en modo protegido, sino que permanece en modo real (*vea abajo). En el modo real, las aplicaciones en ejecución pueden realizar lo que quieran, es decir, acceder directamente al hardware. Pero una aplicación que se ejecuta en modo real también puede indicar 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 a pesar de que básicamente se lanzaron desde DOS.
DOS (Sistema operativo de disco) no era, por lo que sé, 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 permanezcan residentes, es decir, controladores de mouse y emuladores de EMM. Pero no intentó controlar el hardware en la computadora como lo hace un sistema operativo moderno.
*Cuando se creó DOS por primera vez en la década de 1970, el modo protegido no existía en la CPU. No fue hasta el procesador 80286 a mediados de la década de 1980 que el modo protegido se convirtió en parte de la CPU..
Asegúrese de navegar al hilo original y leer la discusión animada sobre este tema usando el siguiente enlace!
¿Tienes algo que agregar a la explicación? Apaga el sonido en los comentarios. ¿Quieres leer más respuestas de otros usuarios de Stack Exchange con experiencia en tecnología? Echa un vistazo a la discusión completa aquí.
