Question Si DOS est mono-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 à tâche unique.

Mais si les anciennes versions de Windows (y compris Windows 95?) N'étaient que des enveloppes de DOS, comment Windows pourrait-il fonctionner en tant qu'OS multitâche?


114
2018-03-08 14:28


origine


C'est ce qu'on appelle le multitâche préemptif - support.microsoft.com/kb/117567 - joeqwerty
Il va falloir définir "vieux" beaucoup mieux que cela. DOS + Windows 9x et DOS + Windows 3.x dans "386 Enhanced Mode" étaient assez différents à cet égard avec DOS + Windows 3.x / 2.x en "Mode Standard" et "Mode réel". Et comme le fait allusion joeqwerty, il y avait aussi bien du multitâche que du préventif. Des livres entiers ont été écrits à ce sujet, donc une question spécifique est préférable. - JdeBP
@joeqwerty La plus impressionnante des IMO est que Microsoft conserve la documentation en ligne sur les logiciels si anciens. Il y a même des articles sur des sujets avancés sur les anciennes versions de MS-DOS ... Vraiment sympa de les garder en vie. - NothingsImpossible
DOS ne vous donne pas le multitâche. Vous pouvez toujours écrire des programmes entièrement multitâches sans l'aide de DOS, ce que fait Windows au début. Windows 95 n'est certainement pas simplement un "wrapper" pour DOS. - Boann
@NigelNquande En fait, j'ai trouvé que MS était assez efficace pour conserver les anciens documents. La plupart de leurs articles retirés de la base de connaissances sont en ligne (par exemple, au hasard Windows 3.1 KB, ou docs sur le print utilitaire pour Windows 2.1-3.0 ou ansi.sys de MS-DOS 5.0), même après leur période de grâce de fin de vie de 12 mois indiquée. Il n'est tout simplement pas aussi facile de naviguer que la documentation de produit active, vous devez en quelque sorte être spécifique dans vos recherches. - Jason C


Réponses:


Windows 95

Windows 95 était bien plus que "juste un wrapper" pour MS-DOS. Citant Raymond Chen:

MS-DOS a servi à deux fins dans Windows 95.

  • Il a servi de chargeur de démarrage.
  • Il a agi en tant que couche de pilote de périphérique hérité 16 bits.

Windows 95 en fait accroché / surchargé à peu près tous de MS-DOS, en le gardant comme couche de compatibilité tout en se chargeant de tout. Il a également implémenté le multitâche préemptif pour les programmes 32 bits.


Pré-Windows 95

Windows 3.x et les versions plus anciennes étaient principalement 16 bits (à l'exception de Win32s, une couche de compatibilité un peu différente des ponts 16 et 32, mais nous l'ignorerons ici), plus dépendants de DOS et n'utilisant que le multitâche coopératif. celui où ils ne forcent pas un programme en cours d'exécution à sortir; ils attendent que le programme en cours prenne le contrôle (en gros, disons "J'ai terminé" en disant au système d'exploitation d'exécuter le programme en attente).

Le multitâche était coopératif, comme dans les anciennes versions de MacOS (contrairement à Multitasking DOS 4.x, qui comportait le multitâche préemptif). Une tâche devait céder à l'OS 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 était parfait. Si une tâche cessait de traiter les messages et exécutait une boucle de traitement, le multitâche n'existait plus.

Windows 3.x architecture

En ce qui concerne le début des programmes Windows:

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, si tel est le cas, de contrôler cette application. . Cependant, de nombreuses applications Windows 3.1 ne vérifient que rarement, voire pas du tout, la file d'attente des messages et monopolisent le contrôle de l'unité centrale autant de fois qu'elles le souhaitent. Un système multitâche préemptif comme Windows 95 éloigne le contrôle du processeur d'une application en cours d'exécution et le distribue à ceux qui ont une priorité plus élevée 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 passerait le contrôle sans quitter. En théorie, le multitâche préemptif peut être implémenté au-dessus de DOS avec l'utilisation d'une horloge en temps réel et d'interruptions matérielles pour donner le contrôle du planificateur. Comme Commentaires de Tonny, en fait, cela a été fait par certains systèmes d'exploitation s'exécutant au-dessus de DOS.

386 mode amélioré?

Note: 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 le lien article de blogLe mode 386 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 était exécuté.

MS-DOS serait également exécuté à l'intérieur de ces machines virtuelles, et apparemment elles étaient multitâches préventives. Il semble donc que l'hyperviseur en mode 386 partagé partagerait les tranches de temps CPU entre les machines virtuelles (l'une fonctionnant normalement avec -DOS), et chaque VM fera sa propre chose - 3.x multitâches en coopération, tandis que MS-DOS serait à tâche unique.


MS-DOS

Le DOS lui-même était à tâche unique sur papier, mais il était compatible avec TSR programmes, 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 unique.


Tout ce discours de bêtise? J'ai posé des questions 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 un 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 l'implémentation du multitâche préemptif.

De plus, comme les programmes 32 bits étaient nouveaux, il était plus facile de les faire fonctionner lorsqu'ils étaient déconnectés de force - ce qui pourrait avoir brisé certains programmes 16 bits traditionnels.

Bien sûr, c'est toute la spéculation. Si vous voulez vraiment savoir pourquoi MS n'a pas implémenté le multitâche préemptif sous Windows 3.x (nonobstant le mode 386 amélioré), vous devrez demander à quelqu'un qui y travaille.

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


161
2018-03-08 15:22



Très belle écriture. Si je me souviens bien (la classe de conception du système d'exploitation était pour moi il y a de nombreuses années), Windows 9x connectait les interruptions du temporisateur pour appliquer son propre planificateur, comme vous l'avez suggéré dans votre paragraphe précédent. Il y avait d'autres systèmes d'exploitation au-dessus de DOS qui faisaient la même chose. Je m'en souviens très bien de AMX (OS en temps réel pour applications industrielles) et XINU (Unix / Posix comme OS, à but éducatif) qui fonctionnaient tous deux sur DOS. (AMX pouvait également exécuter le bare-metal directement depuis EPROM. Il était beaucoup plus facile de tester / déboguer sous DOS. Vous évitiez ainsi de re-graver des EPROMS pour chaque test.) - Tonny
@Tonny Merci d'avoir confirmé que ce schéma est possible (et utilisé dans la pratique). En supposant que la raison pour laquelle Windows 1-3 n’a pas utilisé le multitâche préemptif n’est pas tant qu’ils n’ont pas pu le faire (MS-DOS 4 l’avait, bien qu’inédit), il aurait plutôt une compatibilité avec DOS. programmes. - Bob
Mmmmhhh Considérant Windows 1-3: Le fait qu'il soit commun à la base de code pour les processeurs 8086 et plus pourrait avoir plus à voir avec cela. La gestion correcte de ring0-3 n'était possible qu'avec 80286 et plus, et c'était ce que Win9x utilisait pour mettre en œuvre le multitâche. 4DOS et d'autres ont déjà fourni un multitâche limité sous DOS (80286 était nécessaire si je me souviens bien). Vous pouvez même exécuter Win3 en tant que processus distinct dans 4DOS. - Tonny
Xinu a vraiment fait ne pas courir sur DOS. Après tout, il s'agissait d'un système d'exploitation LSI-11. La déclaration selon laquelle il n'y a pas eu de multitâche préemptif sous DOS + Windows 3.x est fausse. En 386 Enhanced Mode, il y avait, gracieuseté du VMM. Et le non-sens de 4DOS vous apporte une réponse fréquente: 4DOS n'est pas un système d'exploitation. Les déclarations qu'il a fournies en multitâche sont entièrement fausses. - JdeBP
Le PDP-8 supportait le multitâche préemptif, et il ne s'agissait que d'un ordinateur 12 bits. - david25272


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

Considérez 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 lui 24/7.

Maintenant, remplacez cette personne par M. le secrétaire. (les fenêtres). Il va téléphoner à quelqu'un et parler tout le temps avec lui (toujours une seule tâche). Puis, après un certain temps, l'autre personne dira "J'ai assez parlé pour le moment. Va parler à quelqu'un d'autre et rappelle-moi un peu".

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

  • En termes techniques, cela s'appelle le multitâche coopératif. Cela demande à l'autre personne de dire qu'il / elle a eu suffisamment de temps CPU. Si on ne le fait pas, alors tout s'écroule.
  • Les systèmes modernes sont beaucoup plus intelligents. Y compris le multitâche préemptif. Pensez à la secrétaire en mettant un réveil et en coupant l'autre personne après 5 minutes. "C'est gentil Jane. Mais je dois parler à Joe maintenant. Je vous rappellerai un peu. - Cliquez."

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


26
2018-03-08 14:36



Ne voulez-vous pas dire multitâche coopératif / non préemptif dans votre premier point? Fait intéressant, Windows 95 a introduit le multitâche préemptif pour les programmes 32 bits. Ce n'était pas vraiment un wrapper pour DOS, car il s'agissait d'un système d'exploitation qui utilisait DOS comme chargeur de démarrage, mais en a remplacé les principales parties (en conservant une quantité suffisante pour prendre en charge les programmes 16 bits / DOS). - Bob
monsieur ou mademoiselle, pourquoi pas 'Dr.' DOS? - gtrak
"Il exécutait en permanence un seul programme ... Celui-là répartissait le temps CPU (et les autres ressources) entre les différents programmes." Ne peut-on pas dire à propos d'un système d'exploitation? Bien que la question implique que MS-DOS ne pourrait pas. Je suis fermement opposé aux analogies / métaphores lorsque l'on se débarrasse des détails techniques de la technologie. Ok, alors maintenant nous savons comment fonctionne un bureau hypothétique? Cela n'explique pas vraiment la réponse à la question. - Celeritas


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 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 oblige le processeur à entrer mode protégé.

DOS, par contre, 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 effectuer tout ce qu'elles veulent, par ex. accéder directement au matériel. Mais une application fonctionnant en mode réel peut également demander au processeur de passer en mode protégé.

Et cette dernière partie permet aux applications comme 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 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. Cela a également permis à certaines applications de rester résidentes, par ex. pilotes de souris et é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 pas avant le processeur 80286 au milieu des années 80 que le mode protégé est devenu partie intégrante du processeur.


13
2018-03-08 17:11



Rappelez-vous qu'à ce moment-là, les CPU n'avaient pas de mode protégé. - jwenting
@jwenting - bon point, j'ai ajouté une note à ce sujet - Pete


Avant Windows 3.x, qui était la première version pour les applications DOS multitâches, il y avait des programmes tels que DesqView qui pouvaient faire de même. Si on était par exemple exécutant trois sessions DOS à la fois, alors DesqView créerait quatre machines virtuelles. Les trois sessions DOS penseraient chacune qu'elles "possédaient" l'intégralité de la machine, sauf qu'aucune d'entre elles n'effectuait réellement des E / S de fichiers. Au lieu de cela, la version de DOS exécutée dans chaque session serait corrigée afin de transférer toutes les demandes d'E / S de fichiers à une session spéciale dédiée à cette fin. Étant donné que le matériel en mode texte du PC afficherait en continu le contenu d'une zone de mémoire en tant que caractères; DesqView pouvait laisser chaque session avoir son propre écran virtuel en mappant la plage de chaque session 0xB8000-0xB9FFF à 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 graphique étaient contrôlés en utilisant 64 Ko d'espace d'adressage, certains registres d'E / S et certains matériels "intéressants" nécessitant une lecture et une écriture dans certaines séquences spécifiques. En mode texte, lorsqu'une application écrivait quelque chose dans le tampon de texte, DesqView pouvait définir un indicateur indiquant qu'il devait être copié à l'écran lors du prochain tick du temporisateur; Seule la première écriture dans le tampon de texte à un moment donné nécessiterait l'intervention de DesqView; tous les autres seraient consolidés à la prochaine minuterie.

En revanche, la virtualisation du mode graphique nécessiterait que DeskView bloque chaque écriture individuelle pour afficher les registres de mémoire ou d'E / S. Étant donné que cela ralentirait les écritures mémoire d'environ 100 fois 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 ont été gérés en ayant toute application non-premier plan qui a essayé de faire des graphiques de pause jusqu'à ce qu'il devienne l'application de premier plan, puis lui donnant un contrôle total sur 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 de basculer. Lors du retour à l'application graphique, DesqView restaurera l'état enregistré.

D'une certaine manière, les applications DOS non graphiques multi-tâches étaient plus faciles que les applications Windows multitâches car il y avait très peu de ressources partagées et les applications n'avaient pas besoin d'interagir les unes avec les autres. Dans Windows, en revanche, il est nécessaire de traiter des choses comme le presse-papiers ou la possibilité que les fenêtres d'un programme se déplacent de manière à masquer les autres. Windows 95 a été la première version de Windows qui pourrait surmonter ces limitations en incluant des choses comme un système de fenêtrage qui pourrait accueillir d'avoir une zone de l'écran devient indisponible alors que le code cherchait à attirer (avec l'effet que le dessin sera masquée ).


6
2018-03-09 00:33



Merci de m'avoir rappelé DesqView. Je l'utilisais tout le temps, mais je l'avais complètement oublié. - Emmet


Le multitâche n'est rien d'autre qu'une illusion de lancer des applications simultanément. Elle est perçue comme une exécution simultanée sur votre fin, mais en fait les processus A, B et C sont le partage du temps CPU dans cet ordre: A, B, C, A, B, C, A, B ... ils passent juste sur et éteint très rapidement. Deux processus ne fonctionnent pas en même temps.

Donc, il est parfaitement possible de faire du multitâche MS-DOS en lui faisant suspendre un processus, d'exécuter le suivant pendant une courte période, de suspendre celui-ci, de revenir au premier, etc.

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

Pour ceux qui se souviennent, les jeux étaient toujours exécutés sous DOS4GW car Windows était trop lent.


3
2018-03-10 21:34



et pour la plupart, c'est toujours comme ça que fonctionnent les systèmes d'exploitation à ce jour. C'est pourquoi vous pouvez lancer 10 choses "en même temps" sur un processeur à 4 cœurs par exemple. - jwenting
Ce n'est pas vraiment que "les processeurs ont commencé à être assez rapides". Il était possible d’exécuter des systèmes d’exploitation multi-utilisateurs multitâches sur un 286 (comme le Cohérent, un bon OS introduit sur PC en 1983). Les versions MS-DOS et Windows (et non NT) jusqu'à "(y compris)" Millenium "étaient vraiment atroces selon toute norme objective, même les normes techniques de l'époque, mais une fois MS-DOS établi comme standard pour les PC par IBM, Le marketing et le dynamisme de Microsoft (sans parler de l'abus criminel de leur pouvoir de monopole) ont exclu la meilleure concurrence pendant très longtemps. - Emmet
"Le multitâche est juste une fonctionnalité intelligente développée lorsque les processeurs ont commencé à être assez rapides ..." Vous voulez dire comme la façon dont le Apollo Guidance Computer était un concept multitâche? - Michael Kjörling
Quand j'ai dit "CPU", je parlais des produits en série, et lorsque j'ai dit "multitâche", je voulais dire le multitâche des applications PC. Et enfin, par «utilisateur final», je voulais dire l'enfant derrière le PC, pas l'astronaute. Encore bravo pour le commentaire intéressant. - Dan Horvat


Même si elle ne peut se concentrer que sur une tâche, elle consiste simplement à passer rapidement de l'une à l'autre. De cette façon, il est apparu que c'était du multitâche, mais en vérité, il ne s'agissait que de se concentrer sur 1, puis sur un autre, puis sur un autre, etc.


0
2018-03-08 19:33



Vous vous confondez multitâche avec informatique multiprocesseur Là. Le basculement entre plusieurs tâches très rapidement est multi-tâches, dans le monde informatique. La définition habituelle ne demande exécution parallèle. Diverses "anciennes versions de Windows" faisaient du multitâche différemment, en fonction de la version de Windows, du mode d'exécution et de la base même de DOS. (Windows NT 3.1 est plus ancien que DOS + Windows 95 et pourrait faire SMP). Comme je l’ai souligné dans un autre commentaire, des livres entiers ont été écrits sur ce sujet. Ce n'est vraiment pas le meilleur résumé en deux phrases. - JdeBP
@JdeBP ... Je connais la différence entre le multitâche et le multiprocesseur, car j'utilise principalement des processeurs à cœur unique! Les ordinateurs fonctionnent en série. Le vrai parallèle ne sera visible qu'en informatique quantique. - Thoth


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

Windows 3.0 n'était pas un système multitâche préemptif, il était coopératif comme toutes les versions de MacOS jusqu'à OS X - une application devait revenir d'un appel avant que toute autre application puisse prendre des mesures.

Comme me l’a rappelé un commentateur, les applications DOS étaient multitâches. Cela est dû au fait qu’ils n’ont pas été écrits dans des tâches multiples «coopératives» (cela doit toujours être intégré aux systèmes qui l’utilisent).

À l'époque, il y avait des programmes appelés TSR (Terminate-Stay Resident) qui ont remplacé les pilotes de périphériques actuels. Ces pilotes s'exécuteraient 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.

Il ne s’agissait pas vraiment d’applications Windows, mais de la manière dont toutes les activités de threading se déroulaient avant Windows 3.1, telles que les pilotes d’imprimante, les pilotes de communication, etc.

Bien que Windows 3.1 soit multitâche, le DOS ne l'était pas, mais Windows 3.1 a simplement repoussé les dos et a pris le relais au démarrage (à l'époque, vous lanciez souvent Windows à partir d'une invite DOS).


0
2018-03-10 20:39



Windows 3.0 prend en charge le multitâche préemptif des applications DOS lorsqu'il est exécuté sur un processeur 386 ou supérieur. Seules les applications Windows étaient multitâches en coopération. - Jules
Oh, c'est correct - je codais des applications Windows à l'époque et je ne pensais pas vraiment à DOS. Les applications DOS ont été traitées différemment - merci de le signaler. - Bill K