Compte tenu du fait que DOS était un système d’exploitation monotâche et des liens qu’il entretenait avec les premières versions de Windows, comment les versions antérieures de Windows ont-elles réussi à accomplir plusieurs tâches? Le post de questions-réponses des superutilisateurs d’aujourd’hui examine les réponses à cette question.
La question
Le lecteur SuperUser LeNoob veut savoir comment les anciennes versions de Windows ont pu fonctionner en tant que systèmes multitâches?:
J’ai lu que DOS est un système d’exploitation monotâche. Mais si les anciennes versions de Windows (y compris Windows 95?) N’étaient que des wrappers pour DOS, comment pourraient-elles fonctionner comme un système d’exploitation multitâche?
Bonne question! Comment les anciennes versions de Windows ont-elles réussi à fonctionner en tant que systèmes multitâches?
La réponse
Les contributeurs SuperUser Bob et Pete ont la réponse pour nous. Tout d’abord, Bob:
Windows 95 était bien plus qu’un «simple wrapper» pour MS-DOS. Citant Raymond Chen:
- MS-DOS a servi deux objectifs dans Windows 95: 1.) Il a servi de chargeur de démarrage. & 2.) Il a agi comme la couche de pilote de périphérique hérité 16 bits.
Windows 95 a en fait accroché / remplacé presque tout MS-DOS, le gardant comme couche de compatibilité tout en faisant tout le gros du travail. Il a également mis en œuvre le multitâche préventif pour les programmes 32 bits.
Pré-Windows 95
Windows 3.x et les versions antérieures étaient pour la plupart 16 bits (à l’exception de Win32s, une sorte de couche de compatibilité qui relie 16 et 32, mais nous l’ignorerons ici), étaient plus dépendants de DOS et utilisaient uniquement le multitâche coopératif – c’est celui où ils ne forcent pas un programme en cours à se déconnecter; ils attendent que le programme en cours d’exécution cède le contrôle (en gros, dites «j’ai terminé» en disant au système d’exploitation d’exécuter le programme suivant en attente).
- Le multitâche était coopératif, tout comme dans les anciennes versions de MacOS (bien que contrairement au multitâche DOS 4.x, qui arborait un multitâche préventif). Une tâche devait céder la place au système d’exploitation pour planifier une tâche différente. Les rendements ont été intégrés à certains appels d’API, notamment le traitement des messages. Tant qu’une tâche traitait les messages en temps opportun, tout allait bien. Si une tâche arrêtait de traiter les messages et était occupée à exécuter une boucle de traitement, le multitâche n’était plus.
Quant à savoir à quel point les premiers programmes Windows donneraient le contrôle:
- Windows 3.1 utilise le multitâche coopératif – ce qui signifie que chaque application en cours d’exécution est chargée de vérifier périodiquement une file d’attente de messages pour savoir si une autre application demande l’utilisation du processeur et, le cas échéant, de céder le contrôle à cette application. Cependant, de nombreuses applications Windows 3.1 ne vérifieraient la file d’attente des messages que rarement, voire pas du tout, et monopoliseraient le contrôle du processeur autant de temps que nécessaire. Un système multi-tâches préventif comme Windows 95 enlèvera le contrôle du processeur à une application en cours d’exécution et le distribuera à ceux qui ont une priorité plus élevée en fonction des besoins du système.
Tout ce que DOS verrait, c’est cette seule application (Windows ou autre) en cours d’exécution, qui passerait le contrôle sans quitter. En théorie, le multi-tâches préventif peut éventuellement être implémenté sur DOS de toute façon avec l’utilisation d’une horloge en temps réel et des interruptions matérielles pour donner de force le contrôle au planificateur. Comme Commentaires de Tonny, cela a été fait par certains systèmes d’exploitation fonctionnant sous DOS.
386 Mode amélioré?
Remarque: il y a eu quelques commentaires sur 386 mode amélioré de Windows 3.x étant 32 bits et prenant en charge le multitâche préemptif.
C’est un cas intéressant. Pour résumer les liens article de blog, 386 mode amélioré é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 fonctionnait, qui effectue toutes les tâches énumérées ci-dessus.
MS-DOS fonctionnerait également à l’intérieur de ces machines virtuelles, et apparemment elles étaient multi-tâches de manière préventive – il semble donc que l’hyperviseur en mode amélioré 386 partagera les tranches de temps CPU entre les machines virtuelles (dont l’une exécutait normalement 3.x et autres qui exécutaient MS-DOS), et chaque machine virtuelle fera son propre travail – 3.x serait multitâche en coopération, tandis que MS-DOS serait à une seule tâche.
MS-DOS
DOS lui-même était mono-tâche sur papier, mais il prenait en charge TSR programmes qui resteraient en arrière-plan jusqu’à ce qu’ils soient déclenchés par une interruption matérielle. Loin d’être un véritable multitâche, mais pas non plus entièrement mono-tâche.
Tout ce discours de 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 multi-tâches 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 multi-tâches préventif.
De plus, comme les programmes 32 bits étaient nouveaux, il était plus facile de les faire fonctionner lorsqu’ils étaient désactivés de force – ce qui aurait pu briser 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 (malgré le mode 386 amélioré), vous devrez demander à quelqu’un qui y a travaillé.
Aussi, je voulais corriger votre hypothèse selon laquelle Windows 95 n’était qu’un wrapper pour DOS.
Suivi de la réponse de Pete:
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 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 force le CPU à entrer mode protégé.
DOS, en revanche, n’entre jamais en mode protégé, mais reste en mode réel (*voir ci-dessous). En mode réel, les applications en cours d’exécution peuvent effectuer tout ce qu’elles veulent, c’est-à-dire accéder directement au matériel. Mais une application exécutée en mode réel peut également indiquer au CPU de passer en mode protégé.
Et cette dernière partie permet à des applications comme Windows 95 de démarrer un environnement multi-thread même si elles ont été essentiellement lancées depuis DOS.
DOS (Disk Operating System) n’était, pour autant que je sache, rien de 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, à savoir 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 1970, le mode protégé n’existait pas dans le CPU. Il a fallu attendre le processeur 80286 au milieu des années 1980 pour que le mode protégé fasse partie du processeur.
Assurez-vous de parcourir le fil d’origine et de lire la discussion animée sur ce sujet en utilisant le lien ci-dessous!
Avez-vous quelque chose à ajouter à l’explication? Sonnez dans les commentaires. Vous voulez lire plus de réponses d’autres utilisateurs de Stack Exchange férus de technologie? Consultez le fil de discussion complet ici.
