human
Windows était simplement une interface qui s'exécutait par-dessus MS-DOS, ce qui signifie que Windows 3.1 était en réalité une application MS-DOS standard comme les autres.
Cependant, MS-DOS n'est pas un système d'exploitation multitâche, et en même temps, les applications Windows étaient des binaires compilés en code natif qui s'exécutaient sans aucun environnement géré. Alors, comment la multitâche des binaires Windows a-t-elle été réalisée si Windows 3.1 était simplement un programme MS-DOS ordinaire ? Existe-t-il encore des anciens documents techniques décrivant l'architecture interne de Windows à ses débuts
gpt
Pour les programmes Win16, Windows a mis en œuvre une multitâche coopérative. Son implémentation était basée sur l'architecture de la "boucle de messages" de chaque programme Windows.

Le devoir de chaque programme était de s'exécuter indéfiniment dans une boucle dans laquelle un appel à la fonction ```GetMessage``` était effectué. Cet appel de fonction vérifie si un message est présent dans la file d'attente de ce processus. S'il y en a un, il est récupéré (```GetMessage```), éventuellement traduit (```TranslateMessage```, pour convertir les raccourcis clavier en actions de menu) et enfin, transmis à la procédure de fenêtre (```DispatchMessage```).

S'il n'y a aucun message disponible dans la file d'attente, Windows suspend la tâche en cours et donne le processeur à une autre tâche. Cette tâche essaiera également de récupérer un message de sa file d'attente, cédant le processeur à une autre tâche s'il n'y a aucun message et ainsi de suite.

Si un programme avait besoin d'effectuer des tâches en arrière-plan lorsqu'il n'y avait aucun message en attente dans sa file d'attente, il appelait ```PeekMessage``` au lieu de ```GetMessage```. Cela n'obligeait pas la tâche à céder le processeur, car ```PeekMessage``` retournait immédiatement à la tâche appelante pour l'informer de la disponibilité ou non d'un message. Cela était utilisé pour multiplexer temporellement le traitement des messages avec une autre tâche consommatrice de temps (pensez à un programme 3D qui effectue un rendu mais permet à l'utilisateur d'annuler ce rendu en appuyant sur un bouton "Annuler").

Si cette tâche consommatrice de temps était effectivement très consommatrice de temps, un programme bien comporté devait appeler la fonction ```Yield``` de temps en temps, pour céder le processeur et laisser d'autres tâches s'exécuter. Un programme mal comporté pouvait facilement monopoliser le processeur en ne récupérant pas les messages assez souvent ou en passant trop de temps dans une fonction de procédure de fenêtre.

La situation était assez différente pour les boîtes MS-DOS. Elles s'exécutaient en utilisant le mode V8086 du 80386 (si Windows était en mode amélioré). Les programmes compatibles avec Windows s'exécutaient dans la soi-disant machine virtuelle système (Virtual Machine 1). Les boîtes DOS s'exécutaient à partir de la machine virtuelle 2 et au-delà. Les programmes DOS étaient généralement mal comportés, donc Windows attribuait à chaque boîte DOS une machine virtuelle différente. Les machines virtuelles utilisaient une multitâche préemptive dans Windows 3.1, de sorte que chaque boîte DOS pouvait s'exécuter simultanément avec d'autres et avec n'importe quel programme compatible avec Windows.