Si DOS est monotâche, comment le multitâche était-il possible dans l'ancienne version de Windows ?

Windows 95

Windows 95 était bien plus qu'une "simple enveloppe" pour MS-DOS. . Citation de Raymond Chen :

MS-DOS a servi deux objectifs dans Windows 95.

• Il servait de boot loader.
• Il a fait office de couche de pilotes de périphériques 16 bits.

Windows 95 a en fait repris/supprimé à peu près tout MS-DOS, le conservant comme couche de compatibilité tout en faisant lui-même le gros du travail. Il a également mis en œuvre 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 des systèmes 16 bits (à l'exception de Win32s, une sorte de couche de compatibilité qui fait le lien entre le 16 et le 32, mais nous l'ignorerons ici), étaient plus dépendants du DOS et n'utilisaient que le multitâche coopératif - c'est-à-dire celui où ils ne forcent pas un programme en cours d'exécution à changer de place ; ils attendent que le programme en cours d'exécution cède le contrôle (en gros, ils disent "j'ai fini" en indiquant au système d'exploitation d'exécuter le programme suivant qui attend).

Le multitâche était coopératif, comme dans les anciennes versions de MacOS (à la différence de DOS 4.x, qui proposait un multitâche préemptif). Une tâche devait céder sa place au système d'exploitation afin de pouvoir planifier une autre tâche. Les cessions étaient intégrées à 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 cessait de traiter les messages et était occupée à exécuter une boucle de traitement, le multitâche n'existait plus.

Architecture Windows 3.x

Quant à la façon dont les premiers programmes Windows céderaient le contrôle :

Windows 3.1 utilise le multitâche coopératif, ce qui signifie que chaque application en cours d'exécution a pour instruction de vérifier périodiquement une file d'attente de messages pour savoir si une autre application demande l'utilisation de l'unité centrale et, le cas échéant, de lui céder le contrôle. Cependant, de nombreuses applications Windows 3.1 ne vérifient la file d'attente des messages que rarement, voire pas du tout, et monopolisent le contrôle de l'UC aussi longtemps qu'elles le souhaitent. Un système multitâche préemptif comme Windows 95 retire le contrôle de l'unité centrale à une application en cours d'exécution et le distribue à celles qui ont une priorité plus élevée en fonction des besoins du système.

Quelle

Tout ce que le DOS verrait, c'est cette seule application (Windows ou autre) en cours d'exécution, qui passerait le contrôle sans se terminer. En théorie, le multitâche préemptif peut être implémenté au-dessus de DOS en utilisant une horloge en temps réel et des interruptions matérielles pour donner de force le contrôle au planificateur. Comme Commentaires de Tonny En fait, cela a été fait par certains systèmes d'exploitation fonctionnant au-dessus de DOS.

Mode amélioré 386 ?

Note : il y a eu des commentaires sur Mode amélioré 386 de Windows 3.x étant 32-bit, et supportant le multitâche préemptif.

C'est un cas intéressant. Pour résumer l'affaire article de blog Le mode amélioré du 386 était essentiellement un hyperviseur 32 bits, qui exécutait des machines virtuelles. Dans l'une de ces machines virtuelles tournait le mode standard de Windows 3.x, qui fait toutes les choses listées ci-dessus.

MS-DOS s'exécutait également dans ces machines virtuelles, et apparemment, elles étaient préemptivement multitâches. Il semble donc que l'hyperviseur en mode amélioré 386 partage les tranches de temps du processeur entre les machines virtuelles (l'une d'entre elles exécutant la version normale 3.x et les autres MS-DOS), et que chaque VM fasse son propre travail - 3.x serait multitâches en coopération, tandis que MS-DOS serait monotâche.

MS-DOS

DOS lui-même était mono-tâche sur le papier, mais il avait le support pour TSR qui resteraient en arrière-plan jusqu'à ce qu'ils soient déclenchés par une interruption matérielle. Loin du véritable multitâche, mais pas complètement monotâche non plus.

Toute cette discussion sur le "bit-ness" ? J'ai posé une question sur le multitâche !

Eh bien, à proprement parler, le bit-ness et le multitâche ne dépendent pas l'un de l'autre. 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 rendre le multitâche préemptif plus facile à mettre en œuvre.

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

Bien sûr, ce ne sont que des spéculations. Si vous voulez vraiment savoir pourquoi MS n'a pas implémenté le multitâche préemptif dans Windows 3.x (en dépit du mode amélioré 386), vous devrez demander à quelqu'un qui y a travaillé.

De plus, je voulais corriger votre hypothèse selon laquelle Windows 95 n'était qu'une enveloppe pour DOS ;)

Il exécutait en permanence un seul programme, celui appelé Windows. Celui-ci répartissait le temps d'utilisation du processeur (et d'autres ressources) entre différents programmes.

Considérez cette analogie :

Vous avez un bureau qui ne peut accueillir qu'une seule personne à la fois (cette personne est appelée monsieur ou madame DOS). Cette personne travaille sur une seule chose à la fois. Par exemple, elle 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. le secrétaire. (Windows). Il va téléphoner à quelqu'un et lui parler tout le temps (toujours une seule tâche). Puis, après un certain temps, l'autre personne dira "J'ai assez parlé pour l'instant. Allez parler à quelqu'un d'autre et rappelez-moi dans un moment".

M. le secrétaire va appeler l'autre personne. Discutez avec cette personne jusqu'à ce qu'elle vous dise la même chose. Puis il appellera la personne suivante jusqu'à ce qu'il soit à la fin de la liste des personnes avec lesquelles il doit parler. À ce moment-là, il recommencera au début.

• En termes techniques, on appelle cela le multitâche coopératif. Il faut que l'autre personne dise qu'elle a eu assez de temps CPU. Si l'un des deux ne le fait pas, tout s'écroule.
• Les systèmes modernes sont beaucoup plus intelligents. Y compris le multitâche préventif. Pensez à la secrétaire qui règle un réveil et coupe l'autre personne au bout de 5 minutes. "C'est bien, Jane. Mais je dois parler à Joe maintenant. Je te rappelle dans un instant. - Clic."

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 bacs à sable. 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 elle ne peut pas accéder directement aux périphériques matériels de l'ordinateur. Si un accès au matériel est nécessaire, l'application doit communiquer par le biais de pilotes de périphériques.

Le système d'exploitation peut appliquer ce contrôle, car il oblige l'unité centrale à entrer dans le système d'exploitation. mode protégé .

DOS, en revanche, ne passe jamais en mode protégé, mais reste en mode mode réel *. En mode réel, l'application en cours d'exécution peut effectuer tout ce qu'elle veut, par exemple accéder directement au matériel. Mais une application s'exécutant en mode réel peut également demander au CPU de passer en mode protégé.

Cette dernière partie permet à des applications telles que Windows 95 de démarrer un environnement multithread, même si elles ont été lancées à partir de DOS.

DOS (Disk Operating System) n'était, afaik, pas beaucoup 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. Il permettait également à certaines applications de rester résidentes, par exemple les pilotes de souris et les émulateurs EMM. Mais il ne tentait pas de contrôler le matériel de l'ordinateur comme le fait un système d'exploitation moderne.

* Lorsque le DOS a été créé dans les années 70, le mode protégé n'existait pas dans l'unité centrale. Ce n'est qu'avec le processeur 80286, au milieu des années 80, que le mode protégé est devenu partie intégrante de l'unité centrale.

Avant Windows 3.x, qui a été la première version à multitâches des applications DOS, il existait des programmes tels que DesqView qui pouvaient faire de même. Si l'on exécutait, par exemple, trois sessions DOS en même temps, DesqView créait quatre machines virtuelles. Les trois sessions DOS penseraient chacune qu'elles "possèdent" la machine entière, sauf qu'aucune d'entre elles n'effectuerait réellement d'entrées/sorties de fichiers. Au lieu de cela, la version de DOS exécutée dans chaque session serait corrigée de manière à transmettre toute demande d'entrée/sortie de fichier à une session spéciale, dédiée à cet effet. Puisque le matériel en mode texte du PC affichait continuellement le contenu d'une zone de mémoire sous forme de caractères, DesqView pouvait permettre à chaque session d'avoir son propre écran virtuel en mappant la plage 0xB8000-0xB9FFF de chaque session à sa propre zone de RAM, et en copiant périodiquement la zone de l'application en cours dans le tampon d'écran physique. La prise en charge graphique était beaucoup plus difficile, car 256 Ko de RAM sur la carte d'affichage étaient contrôlés à l'aide de 64 Ko d'espace d'adressage, de quelques registres d'E/S et d'un matériel "intéressant" qui exigeait que les choses soient lues et écrites dans certaines séquences spécifiques. En mode texte, lorsqu'une application écrivait quelque chose dans le Tampon de texte, DesqView pouvait mettre un drapeau indiquant qu'il devait être copié sur l'écran au prochain tic-tac de minuterie ; seule la première écriture dans le Tampon de texte dans un tic-tac de temps donné nécessitait l'intervention de DesqView ; toutes les autres étaient consolidées au prochain tic-tac de minuterie.

En revanche, la virtualisation du mode graphique nécessiterait que DeskView piège chaque écriture individuelle dans la mémoire de l'écran ou dans les registres d'E/S. Étant donné que cela ralentirait les écritures en mémoire par un facteur d'environ 100, et que les programmes graphiques devaient écrire beaucoup plus de données que les programmes texte, la virtualisation en temps réel de la plupart des logiciels graphiques n'était pas pratique. Au lieu de cela, les graphiques étaient gérés en faisant en sorte que toute application qui n'était pas au premier plan et qui essayait de faire des graphiques fasse une pause jusqu'à ce qu'elle devienne l'application au premier plan, puis en lui donnant le contrôle total de l'écran. Lorsque le contrôle passait à une autre application, DesqView essayait de faire une copie de l'état de tous les registres graphiques, puis changeait. Lors du retour à l'application graphique, DesqView restaurait l'état sauvegardé.

D'une certaine manière, il était plus facile de faire fonctionner en multitâche des applications DOS non graphiques que des applications Windows, 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, par contre, il faut gérer des choses comme 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 a été la première version de Windows à pouvoir surmonter de telles limitations en incluant des éléments tels qu'un système de fenêtrage permettant de rendre une zone de l'écran indisponible alors qu'un code tente d'y dessiner (avec pour effet que le dessin est masqué).

Le multitâche n'est rien d'autre que l'illusion de faire fonctionner des applications simultanément. Il est perçu comme une exécution simultanée de votre côté, mais en fait les processus A, B et C se partagent le temps CPU dans cet ordre : A, B, C, A, B, C, A, B... ils s'activent et se désactivent simplement très rapidement. Aucun processus n'est réellement en cours d'exécution au même moment.

Il est donc parfaitement possible de rendre MS-DOS multitâche en mettant en pause un processus, en exécutant le suivant pendant une courte période, en mettant ce dernier en pause, en revenant au premier, et ainsi de suite.

Le multitâche n'est qu'une fonctionnalité intelligente développée lorsque les processeurs ont commencé à être suffisamment rapides pour faire tourner ces processus et donner l'impression qu'ils sont simultanés pour l'utilisateur final.

Pour ceux qui s'en souviennent, les jeux étaient encore exécutés sur DOS4GW parce que Windows était trop lent.