Si DOS utilise une seule tâche, comment le multitâche était-il possible dans l'ancienne version de Windows?

J'ai lu que DOS est un système d'exploitation mono-tâche.

Mais si les anciennes versions de Windows (y compris Windows 95?) N'étaient que des wrappers de DOS, comment Windows pouvait-il fonctionner en tant que système d'exploitation multitâche?

Windows 95

Windows 95 était bien plus qu'un simple "wrapper" pour MS-DOS . Citant Raymond Chen:

MS-DOS servait à deux fins dans Windows 95.

• Il a servi de chargeur de démarrage.
• Il s'agissait de la couche de pilote de périphérique héritée 16 bits.

Windows 95 a en fait accroché / remplacé presque tout MS-DOS, en le gardant comme couche de compatibilité tout en faisant le gros du travail. Il a également implémenté le multitâche préemptif pour les programmes 32 bits.

Pré-Windows 95

Windows 3.x et les versions antérieures étaient pour la plupart en 16 bits (à l'exception de Win32s, une couche de compatibilité qui relie 16 et 32, mais nous l'ignorerons ici), dépendaient davantage de DOS et utilisaient uniquement le multitâche coopératif - c'est-à-dire celui où ils ne forcent pas un programme en cours à se déconnecter; ils attendent que le programme en cours donne le contrôle (en gros, dites "J'ai terminé" en disant au système d'exploitation de lancer le prochain programme en attente).

Le multitâche était coopératif, comme dans les anciennes versions de MacOS (bien que contrairement à Multitasking DOS 4.x, qui comportait le multitâche préventif). Une tâche devait céder la place au système d'exploitation pour pouvoir planifier une tâche différente. Les rendements ont été intégrés à certains appels API, notamment le traitement des messages. Tant qu'une tâche traitait les messages en temps voulu, tout allait bien. Si une tâche arrêtait de traiter des messages et était occupée à exécuter une boucle de traitement, le multitâche n'existait plus.

Architecture Windows 3.x

En ce qui concerne la façon dont les premiers programmes Windows permettraient de contrôler:

Windows 3.1 utilise le multitâche coopératif, ce qui signifie que chaque application en cours d'exécution doit vérifier périodiquement une file de messages pour déterminer si une autre application demande l'utilisation de la CPU et, le cas échéant, la contrôler. . Cependant, de nombreuses applications Windows 3.1 vérifiaient la file de messages de manière peu fréquente, voire pas du tout, et monopolisaient le contrôle du processeur pendant le temps requis. Un système multitâche préemptif, tel que Windows 95, détournera le contrôle du processeur d'une application en cours d'exécution et le distribuera à celles dont la priorité est supérieure, en fonction des besoins du système.

la source

Tout ce que DOS verrait, c’est cette application unique (Windows ou autre) en cours d’exécution, qui transmettrait le contrôle sans quitter. En théorie, le multitâche préemptif peut de toute façon être implémenté sous DOS avec l'utilisation d'une horloge en temps réel et d'interruptions matérielles pour forcer le contrôle du planificateur. Comme le commente Tonny , certains systèmes d’exploitation fonctionnant sous DOS ont fait cela.

386 mode amélioré?

Remarque: certains commentaires ont été formulés sur le mode amélioré 386 de Windows 3.x, 32 bits, prenant en charge le multitâche préemptif.

C'est un cas intéressant. Pour résumer l' article de blog lié , le mode amélioré 386 était essentiellement un hyperviseur 32 bits, qui exécutait des machines virtuelles. À l’intérieur de l’une de ces machines virtuelles, le mode standard Windows 3.x était exécuté.

MS-DOS s’exécutait également à l’intérieur de ces machines virtuelles et, apparemment, elles étaient multitâches préventives. Il semble donc que l’hyperviseur de mode étendu 386 partage les tranches de temps de l’UC entre les machines virtuelles (l’une d’elles exécutant la version 3.x normale et d’autres fonctionnant sous MS). -DOS), et chaque machine virtuelle fera sa propre chose - 3.x serait multitâche coopérativement, alors que MS-DOS aurait une tâche unique.

MS-DOS

Le DOS lui-même ne comportait qu'une tâche sur papier, mais il prenait en charge les programmes TSR , qui resteraient en arrière-plan jusqu'à ce qu'ils soient déclenchés par une interruption matérielle. Loin du vrai multitâche, mais pas entièrement à tâche unique non plus.

Toutes ces discussions sur les bêtises? J'ai posé des questions sur le multitâche!

Eh bien, à proprement parler, le bit-ness et le multitâche ne sont pas dépendants les uns des autres. Il devrait être possible d'implémenter n'importe quel mode multitâche dans n'importe quel bit-ness. Cependant, le passage des processeurs 16 bits aux processeurs 32 bits a également introduit d'autres fonctionnalités matérielles qui auraient pu faciliter la mise en œuvre du multitâche préemptif.

De plus, les programmes 32 bits étant nouveaux, il était plus facile de les faire fonctionner lorsqu'ils étaient déconnectés de force - ce qui aurait pu casser certains programmes 16 bits hérités.

Bien sûr, tout cela n’est que spéculation. Si vous voulez vraiment savoir pourquoi MS n'a pas implémenté le multitâche préemptif dans Windows 3.x (nonobstant le mode 386 amélioré), vous devrez demander à quelqu'un qui a travaillé là-bas.

En outre, je voulais corriger votre hypothèse selon laquelle Windows 95 était tout simplement un wrapper pour DOS;)

Il a continuellement exécuté un seul programme, celui appelé Windows. Celui-ci répartit le temps processeur (et d'autres ressources) entre différents programmes.

Considérons cette analogie:

Vous avez un bureau qui ne peut avoir qu'une seule personne à la fois (cette personne s'appelle monsieur ou madame DOS). Cette personne travaille sur une chose à la fois. Par exemple, il téléphone à une seule personne et commence à discuter avec elle 24 heures sur 24, 7 jours sur 7.

Maintenant, vous remplacez cette personne par M. secrétaire. (les fenêtres). Il va téléphoner à quelqu'un et parler tout le temps avec lui (encore une tâche). Ensuite, après un certain temps, l'autre personne dira "J'ai suffisamment parlé pour l'instant. Parlez à quelqu'un d'autre et rappelez-moi un peu plus tard".

M. secrétaire va appeler l'autre personne. Discutez avec lui jusqu'à ce que cette personne dise la même chose. Ensuite, il appellera la personne suivante jusqu'à la fin de la liste des personnes avec lesquelles parler. À ce moment-là, cela recommencera au sommet.

• En termes techniques, cela s'appelle le multitâche coopératif. Il faut que l’autre personne dise qu’elle dispose de suffisamment de temps processeur. Si on ne fait pas ça, tout tombe en morceaux.
• Les systèmes modernes sont beaucoup plus intelligents. Y compris le multitâche préemptif. Pensez à la secrétaire qui règle un réveil et coupe l’autre personne au bout de 5 minutes. "C'est gentil Jane. Mais je dois parler à Joe maintenant. Je te rappellerai dans un moment. - Clique."

Si vous ajoutez plusieurs processeurs, cela devient encore plus compliqué. :)

Dans un système d'exploitation moderne, le système d'exploitation contrôle toutes les ressources matérielles et les applications en cours d'exécution sont conservées dans des sandbox. Une application n'est pas autorisée à accéder à la mémoire que le système d'exploitation n'a pas allouée à cette application et ne peut pas accéder directement aux périphériques matériels de l'ordinateur. Si un accès matériel est requis, l'application doit communiquer via des pilotes de périphérique.

Le système d'exploitation peut appliquer ce contrôle car il oblige la CPU à entrer en mode protégé .

Par contre, DOS n'entre jamais en mode protégé, mais reste en mode réel *. En mode réel, les applications en cours d'exécution peuvent exécuter toutes les tâches de leur choix, par exemple, accéder directement au matériel. Mais une application exécutée en mode réel peut également indiquer au processeur de passer en mode protégé.

Et cette dernière partie permet aux applications telles que Windows 95 de démarrer un environnement multithread même s’ils ont été lancés à partir de DOS.

Le DOS (système d’exploitation sur disque) n’était, à mon avis, guère plus qu'un système de gestion de fichiers. Il fournissait un système de fichiers, des mécanismes de navigation dans le système de fichiers, quelques outils et la possibilité de lancer des applications. Cela permettait également à certaines applications de rester résidentes, par exemple les pilotes de souris et les émulateurs EMM. Mais il n'a pas tenté de contrôler le matériel de l'ordinateur comme le fait un système d'exploitation moderne.

* Lorsque DOS a été créé pour la première fois dans les années 70, le mode protégé n'existait pas dans la CPU. Ce n'est qu'au moment du processeur 80286, au milieu des années 80, que le mode protégé est devenu partie intégrante du processeur.

Avant Windows 3.x, qui était la première version d'applications multitâches DOS, il existait des programmes tels que DesqView qui pouvaient faire de même. Si, par exemple, on exécutait trois sessions DOS en même temps, DesqView créerait quatre machines virtuelles. Les trois sessions DOS pensaient chacune qu'elles "possédaient" la totalité de la machine, sauf qu'aucune d'elles n'exécuterait réellement des E / S sur fichier. Au lieu de cela, la version de DOS exécutée dans chaque session serait corrigée de manière à transférer toute demande d’E / S sur fichier vers une session spéciale, dédiée à cet usage. Étant donné que le matériel en mode texte du PC affiche en permanence le contenu d’une zone de la mémoire sous forme de caractères; DesqView pourrait laisser chaque session disposer de son propre écran virtuel en mappant la plage 0xB8000-0xB9FFF de chaque session sur sa propre zone de RAM, et copier périodiquement la zone de l'application actuelle dans la mémoire tampon d'écran physique. La prise en charge graphique était beaucoup plus difficile, car 256 Ko de RAM sur le tableau d’affichage étaient contrôlés à l’aide de 64 Ko d’espace adresse, de certains registres d’E / S et de matériel "intéressant" qui nécessitait la lecture et l’écriture de séquences spécifiques. En mode texte, lorsqu'une application écrivait quelque chose dans la mémoire tampon de texte, DesqView pouvait définir un indicateur indiquant qu'elle devait être copiée sur l'affichage lors du prochain tick d'horloge; seule la première écriture dans le tampon de texte dans un intervalle de temps donné nécessiterait l'intervention de DesqView; tous les autres seraient regroupés au prochain tick de la minuterie. Parce que 256K de RAM sur la carte d’affichage étaient contrôlés à l’aide de 64K d’espace adresse, de quelques registres d’E / S et de matériel "intéressant" nécessitant la lecture et l’écriture de séquences spécifiques. En mode texte, lorsqu'une application écrivait quelque chose dans la mémoire tampon de texte, DesqView pouvait définir un indicateur indiquant qu'elle devait être copiée sur l'affichage lors du prochain tick d'horloge; seule la première écriture dans le tampon de texte dans un intervalle de temps donné nécessiterait l'intervention de DesqView; tous les autres seraient regroupés au prochain tick de la minuterie. Parce que 256K de RAM sur la carte d’affichage étaient contrôlés à l’aide de 64K d’espace adresse, de quelques registres d’E / S et de matériel "intéressant" nécessitant la lecture et l’écriture de séquences spécifiques. En mode texte, lorsqu'une application écrivait quelque chose dans la mémoire tampon de texte, DesqView pouvait définir un indicateur indiquant qu'elle devait être copiée sur l'affichage lors du prochain tick d'horloge; seule la première écriture dans le tampon de texte dans un intervalle de temps donné nécessiterait l'intervention de DesqView; tous les autres seraient regroupés au prochain tick de la minuterie. DesqView pourrait définir un drapeau indiquant qu'il devrait être copié sur l'affichage lors du prochain tick d'horloge; seule la première écriture dans le tampon de texte dans un intervalle de temps donné nécessiterait l'intervention de DesqView; tous les autres seraient regroupés au prochain tick de la minuterie. DesqView pourrait définir un drapeau indiquant qu'il devrait être copié sur l'affichage lors du prochain tick d'horloge; seule la première écriture dans le tampon de texte dans un intervalle de temps donné nécessiterait l'intervention de DesqView; tous les autres seraient regroupés au prochain tick de la minuterie.

En revanche, la virtualisation du mode graphique nécessiterait que DeskView capture toutes les écritures individuelles pour afficher la mémoire ou les registres d'E / S. Étant donné que cela ralentirait la mémoire d'un facteur 100 environ et que les programmes graphiques devaient écrire beaucoup plus de données que les programmes de texte, la virtualisation en temps réel de la plupart des logiciels graphiques n'était pas pratique. Au lieu de cela, les graphiques ont été gérés en utilisant une application autre que le premier plan qui essayait de faire une pause graphique jusqu'à ce qu'elle devienne l'application au premier plan, puis en lui donnant un contrôle total sur l'écran. Lorsque le contrôle passait à une autre application, DesqView essayait de copier l'état de tous les registres graphiques, puis basculait. En revenant à l'application graphique, DesqView restaurerait l'état enregistré.

D'une certaine manière, les applications DOS multi-tâches non graphiques étaient plus faciles que les applications Windows multi-tâches car il y avait très peu de ressources partagées et les applications n'avaient pas à interagir les unes avec les autres. Dans Windows, en revanche, il est nécessaire de gérer des problèmes tels que le Presse-papiers ou la possibilité que les fenêtres d’un programme se déplacent de manière à masquer celles d’un autre. Windows 95 était la première version de Windows capable de surmonter ces limitations en incluant, par exemple, un système de fenêtrage capable de rendre indisponible une partie de l'écran pendant que le code essayait de l'attirer (avec pour effet de masquer le dessin ).

Le multitâche n'est rien de plus qu'une illusion d'exécuter des applications simultanément. Il est perçu comme une exécution simultanée de votre côté, mais en réalité, les processus A, B et C partagent le temps CPU dans cet ordre: A, B, C, A, B, C, A, B ... très vite. Aucun processus ne s'exécute en même temps.

Ainsi, il est parfaitement possible de créer plusieurs tâches MS-DOS en mettant en pause un processus, en exécutant le processus suivant pendant une courte période, en mettant en pause celui-ci, en revenant au premier, etc.

Le multitâche est simplement une fonctionnalité intelligente développée lorsque les processeurs ont commencé à être assez rapides pour continuer à suivre ces processus et à les rendre simultanés pour l'utilisateur final.

Pour ceux qui s'en souviennent, les jeux fonctionnaient toujours sous DOS4GW car Windows était trop lent.

Même s'il ne peut se concentrer que sur une tâche, il s'agirait simplement de passer rapidement de l'une à l'autre. De cette façon, il est apparu qu’il s’agissait de tâches multiples, mais en réalité, il se concentrait uniquement sur 1, puis sur un autre, puis sur un autre, etc.

Une chose que je n'ai pas vue mentionnée ici est plutôt intéressante:

Windows 3.0 n'était pas un système multitâche préemptif, il coopérait comme toutes les versions de MacOS jusqu'à ce que OS X - Une application doive revenir d'un appel avant qu'une autre application puisse entreprendre une action.

Comme un commentateur me l'a rappelé cependant, les applications DOS étaient multi-tâches. En effet, ils ne sont pas écrits en multi-tâches "Coopérative" (ceci doit toujours être intégré aux systèmes qui l'utilisent).

À l'époque, il existait des programmes appelés TSR (Terminate-Stay Resident) qui remplaçaient les pilotes de périphériques actuels. Ces pilotes s'exécutent indépendamment - généralement sur leur propre thread en s'insérant dans l'un des gestionnaires d'événements du système d'exploitation. Windows ne les connaissait généralement pas, ils fonctionnaient à un niveau inférieur.

Ce ne sont pas vraiment des applications Windows, mais bien comment toutes les activités de threading ont eu lieu avant Windows 3.1, telles que les pilotes d’imprimante, les pilotes de communication, etc.

Bien que Windows 3.1 soit multi-tâches, le DOS ne l’était pas, mais Windows 3.1 ne faisait qu’aplanir les tâches et en prenait le relais à son démarrage (à l’époque, vous lanciez souvent Windows à partir d’une invite DOS).

Bonne question. Sous MS-DOS, le noyau était monolithique, ce qui signifie qu'il ne gérait qu'une tâche à la fois, contrairement au nouveau noyau moderne implémenté dans Windows 9x et la version actuelle. Vous pouvez consulter plus ici .