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

113

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?

Arkonix
la source
8
C'est ce qu'on appelle le multitâche préemptif - support.microsoft.com/kb/117567
joeqwerty
20
Vous allez devoir définir "vieux" beaucoup mieux que cela. DOS + Windows 9x et DOS + Windows 3.x en "Mode amélioré 386" étaient assez différents à cet égard de DOS + Windows 3.x / 2.x en "Mode standard" et en "Mode réel". Et comme le dit joeqwerty, il y a eu plusieurs tâches simultanées et préventives. Des livres entiers ont été écrits à ce sujet, alors une question spécifique est préférable.
JdeBP
5
@ joeqwerty L'OMI la plus impressionnante est que Microsoft conserve en ligne la documentation sur les logiciels les plus anciens. Il y a même des articles sur des sujets avancés sur les anciennes versions de MS-DOS ... Vraiment gentil de le garder en vie.
NothingsImpossible
6
DOS ne vous donne pas le multitâche. Vous pouvez toujours écrire des programmes multitâches complets sans l'aide de DOS, comme le faisait Windows à ses débuts. Windows 95 n'est certainement pas simplement un "wrapper" pour DOS.
Boann
3
@NigelNquande J'ai en fait trouvé que MS maîtrisait assez bien les anciens documents. La plupart de leurs articles de la base de connaissances mis à la retraite sont en ligne (par exemple, une base de données aléatoire de 3.1 Ko Windows ou des documents sur l' printutilitaire pour Windows 2.1-3.0 ou une ansi.sys de MS-DOS 5.0), même après la fin de leur période de 12 mois indiquée. période de grâce Ce n'est tout simplement pas aussi facile à parcourir que la documentation produit active, vous devez en quelque sorte être spécifique dans vos recherches.
Jason C

Réponses:

160

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;)

Bob
la source
4
Très belle rédaction. 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 a raccordé les interrupteurs de minuterie pour appliquer son propre planificateur, comme vous l'avez suggéré dans votre deuxième au dernier paragraphe. Il y avait d'autres OS sur DOS qui faisaient la même chose. Je m'en souviens clairement grâce à AMX (système d'exploitation temps réel pour applications industrielles) et à XINU (objectif pédagogique de petite taille Unix / Posix comme système d'exploitation) qui fonctionnaient tous deux sous DOS. (AMX pouvait aussi exécuter directement du métal nu depuis EPROM. Il était beaucoup plus facile de tester / déboguer sous DOS. Vous évitait de ré-graver des EPROMS pour chaque test.)
Tonny
@Tonny Merci d'avoir confirmé que ce schéma est possible (et utilisé en pratique). À première vue, la raison pour laquelle Windows 1-3 n'a pas utilisé le multitâche préemptif n'est pas telle qu'elle était incapable de le faire (MS-DOS 4 l'avait, bien qu'inéditée), mais cela aurait plutôt rompu la compatibilité ascendante avec DOS programmes.
Bob
3
Mmmmhhh Considérant Windows 1-3: Le fait qu'il s'agisse d'une base de code commune pour les processeurs 8086 et supérieurs aurait pu être plus lié à cela. Une gestion correcte de ring0-3 n’était possible qu’à partir de 80286 et plus, c’est ce que Win9x utilisait pour implémenter le multitâche. 4DOS et d’autres ont déjà fourni un multitâche limité sur DOS (80286 étaient nécessaires si je me souviens bien). Vous pouvez même exécuter Win3 lui-même en tant que processus séparé dans 4DOS.
Tonny
1
Xinu n'a pas vraiment fonctionné sous DOS. Il s'agissait au départ d'un système d'exploitation LSI-11. L'affirmation qu'il n'y avait pas de multitâche préalable dans DOS + Windows 3.x est fausse. En mode amélioré 386, il y avait, gracieuseté du VMM. Et le non-sens sur 4DOS vous donne une réponse fréquente: 4DOS n'est pas un système d'exploitation . Les affirmations selon lesquelles le multitâche est multitâche sont totalement fausses.
JdeBP
2
Le PDP-8 prenait en charge le traitement multitâche préventif, et ce n’était qu’un ordinateur 12 bits.
david25272
26

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é. :)

Hennes
la source
1
Ne voulez-vous pas parler de multitâche coopératif / non préemptif dans votre premier point? En outre, il est intéressant de noter que Windows 95 a introduit le multitâche préemptif pour les programmes 32 bits. Ce n’était pas vraiment un wrapper pour DOS, c’était un système d’exploitation qui utilisait DOS comme chargeur de démarrage mais en remplaçait la majeure partie (en gardant suffisamment pour la prise en charge du programme 16 bits / DOS).
Bob
monsieur ou manque, pourquoi pas 'Dr.' DOS?
gtrak
1
"Il a exécuté en permanence un seul programme ... Celui-ci répartissait le temps processeur (et d'autres ressources) entre différents programmes." cela ne peut-il être dit à 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 lors de l'utilisation de 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
13

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.

Pete
la source
2
Rappelez-vous qu’à l’époque, les processeurs n’avaient pas de mode protégé.
Jwenting
1
@jwenting - bon point, j'ai ajouté une note à ce sujet
Pete
6

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 ).

supercat
la source
Merci de me rappeler de DesqView. Je l'utilisais tout le temps, mais je l'avais complètement oublié.
Emmet
3

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.

Dan Horvat
la source
1
et pour la plupart, c'est toujours comme ça que les choses fonctionnent dans les systèmes d'exploitation à ce jour. C'est pourquoi vous pouvez exécuter 10 choses "en même temps" sur un processeur à 4 cœurs, par exemple.
Jwenting
2
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-tâches multi-utilisateurs sur un 286 (tel que Coherent de The Mark Williams Company , un excellent système d’exploitation introduit sur PC en 1983). Les versions MS-DOS et Windows (non NT) jusqu'à «Millenium» (y compris) étaient vraiment atroces selon tous les critères objectifs, même les normes techniques de l'époque, mais une fois que MS-DOS avait été établi comme norme pour les PC par IBM, Le marketing de Microsoft et son dynamisme (sans parler des abus criminels de son pouvoir de monopole) ont efficacement exclu la concurrence pendant très longtemps.
Emmet
2
"Le multitâche n'est qu'une fonctionnalité astucieuse développée lorsque les processeurs ont commencé à être assez rapides ..." Vous voulez dire que l' ordinateur de guidage Apollo était une conception multitâche ?
un CVn
1
Quand je disais «CPU», je parlais de ceux fabriqués en série, et quand je parlais de «multitâche», je parlais du multitâche des applications PC. Et, enfin, par "utilisateur final", je voulais dire le petit derrière le PC, pas l'astronaute. Encore bravo pour le commentaire intéressant.
Dan Horvat
0

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.

Thot
la source
Vous y confondez le multitâche avec l' informatique multiprocesseur . Basculer très rapidement entre plusieurs tâches est une tâche multitâche, dans le monde de l'informatique. La définition habituelle ne demande l' exécution parallèle. Diverses «anciennes versions de Windows» effectuaient le multitâche différemment, en fonction de la version de Windows, du mode dans lequel il était exécuté et du fait qu’il s’agissait même de DOS ou non. (Windows NT 3.1 est plus ancien que DOS + Windows 95 et peut utiliser SMP.) Comme je l'ai indiqué dans un autre commentaire, des livres entiers ont été écrits à ce sujet. Ce n'est pas vraiment le meilleur résumé en 2 phrases.
JdeBP
@JdeBP ... Je connais la différence entre le multitâche et le multiprocesseur, car je continue à utiliser principalement des processeurs simple cœur! Les ordinateurs fonctionnent en série. Le véritable parallèle ne sera visible qu'en informatique quantique.
Thoth
0

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).

Bill K
la source
Windows 3.0 prenait en charge le multitâche préemptif des applications DOS lorsqu'il était exécuté sur un processeur 386 ou supérieur. Seules les applications Windows étaient multitâches en coopération.
Jules
Oh, c'est exact. À l'époque, je codais des applications Windows et je ne pensais pas vraiment à DOS. Elle traitait les applications DOS différemment - merci de l'avoir signalé.
Bill K
-8

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 .

javathunderman
la source
11
-1 vous suggérez qu'un système d'exploitation monothithique ne peut pas effectuer plusieurs tâches à la fois, ce qui est totalement faux. linux est un noyau FAMILIALEMENT monothithique (il y a eu un débat célèbre entre linus torvalds et andrew tanenbaum), mais linux peut évidemment être multi-tâche. voici un lien pour vous montrer Linux est monolithique stackoverflow.com/questions/1806585/...
barlop
4
Monolithique ne veut pas dire ce que vous pensez.
Thorbjørn Ravn Andersen