La norme DPMI


La norme DPMI (en clair, DOS Protected Mode Interface) trouve ses origines dans des développements réalisés en interne par Microsoft pendant l'élaboration de Windows 3.0 : cet environnement exploite, en effet, le mode protégé des microprocesseurs Intel pour gérer efficacement la mémoire vive installée. Grâce au fonctionnement du microprocesseur en mode protégé, les applications Windows peuvent dépasser la limite de 1 Mo d'espace adressable (qui est imposée par le fonctionnement du microprocesseur en mode réel) et utiliser toute la mémoire physiquement disponible (voire même plus, grâce à la pagination sur disque). Lorsque ces développements furent connus hors de Microsoft, ce dernier décida d'"ouvrir" son programme en chargeant un comité de définir la norme DPMI.
Composé des principaux éditeurs de logiciels, ce comité comptait notamment parmi ses membres Microsoft, Intel, Lotus, IBM, Borland, Quarterdeck, Phar Lap et Rational Systeffls (les deux derniers étant surtout connus pour leurs DOS-Extended, gestionnaires de mémoire dédiés aux développeurs).

Comme toute spécification d'une interface de programmation (ou API pour Application Programming Interface), la norme DPMI se présente sous la forme d'un document qui définit l'ensemble des fonctions qu'un serveur DPMI doit mettre à la disposition des applications clientes, de même que la manière correcte dont ces dernières peuvent utiliser ces services. Afin de garantir la protection des diverses tâches entre elles, la norme DPMI indique également quelles sont les fonctions du DOS et du BIOS dont l'appel est autorisé à partir d'un programme qui s’exécute en mode protégé. Parmi les fonctions (ou services) fournies aux applications clientes, on peut citer le basculement dans le mode protégé du microprocesseur (les fonctions DPMI ne sont pas accessibles à pair du mode réel), la manipulation des tables de descripteurs locales (également désignées par les lettres LDT : Local Descriptor Tables), l'allocation de blocs de mémoire étendue (ou de mémoire conventionnelle), la gestion des pages de mémoire, le contrôle des interruptions ou encore la communication avec des programmes en mode réel (par exemple, des pilotes de périphériques ou des programmes résidents sous DOS).
La norme DPMI utilise les monismes de protection des microprocesseurs 80286, 386, 486 pour isoler efficacement les diverses tâches (ou machines virtuelles) entre elles. Le serveur DPMI s'exécute donc avec un niveau de privilège supérieur à celui des applications clientes (celles qui utilisent les fonctions fournies par le serveur). Les fonctions de protection des microprocesseurs Intel fournissent ainsi un contrôle automatique sur les actions effectuées par les applications clientes, ce qui, par exemple, permet au serveur d'intercepter toutes les tentatives d'accès direct à la mémoire physique et au matériel applications proviennent des applications clientes. Le serveur décide alors de la réponse appropriée pour chaque requête d'une application, ce qui permet notamment de donner aux applications clientes une vision "virtualisée" du matériel sous-jacent (les applications DOS, exécutées dans une fenêtre sous Windows 3.x en mode 386 étendu, donnent une idée assez exacte de ce que peut réaliser la virtualisation de la mémoire vidéo). Un serveur DPMI facilite donc la réalisation d'un système d'exploitation multitâche préemptif entre les diverses machines virtuelles ; le mécanisme de protection des microprocesseurs Intel garantit alors l'intégrité de chaque machine virtuelle vis-à-vis des autres tâches en cours d'exécution.
Il existe actuellement deux spécifications DPMI : la version 0.9, publiée en mai 1990, et la version 1.0, en novembre de la même année. La norme DPMI 1.0 ajoute vingt-deux fonctions aux quarante-neuf services fournis par la version 0.9 ; les nouvelles fonctions cherchent surtout à permettre un meilleur contrôle sur la gestion et le partage de la mémoire entre les diverses machines virtuelles. Par rapport aux normes EMS (Expanded Memory Specification) et XMS (eXtended Memory Spécification), les fonctions DPMI se placent plus bas, puisqu'elles travaillent généralement au niveau des tables internes du microprocesseur.
Cette approche provient du fait que, contrairement aux normes EMS et XMS, les spécifications DPMI n'ont pas été conçues pour être utilisées directement par les applications finales, mais plutôt par les systèmes d'exploitation et les DOS-Extenders. Normalement, les applications finales ne devraient pas appeler directement le serveur DPMI, mais passer par l'intermédiaire de l'API du DOS-Extender (ou du système d'exploitation), qui se chargerait alors de traduire les requêtes de l'application en une série d'appels aux services DPMI.
Un serveur DPMI fournit des fonctions semblables à celles définies par la norme VCPI (Virtual Control Program Interface), qui fut développée en 1987 par Phar Lap et Quarterdeck et adoptée par de nombreux éditeurs de logiciels (sauf Microsoft) entre 1989 et 1990 ; toutefois, la norme VCPI autorise les applications clientes à fonctionner au même niveau de privilège que celui du serveur VCPI, ce qui empêche ce dernier d'utiliser les mécanismes de protection des microprocesseurs Intel pour isoler de manière efficace les diverses tâches entre elles ou pour "virtualiser" l'accès aux ressources physiques.
Aujourd'hui, c'est donc la norme DPMI qui est "implémentée" par les principaux systèmes d'exploitation multitâches : Windows 3.x incorpore un serveur DPMI conforme à la spécification 0.9 de la norme, tandis que OS/2 2.0 "implémente" la version 1.0 de DPMI. Il faut noter que Windows 3.x emploie une seule machine virtuelle pour son propre noyau et pour toutes les applications Windows (voir figure ci-dessous) ; la protection entre les espaces mémoire de ces applications doit donc être assurée par Windows lui-même, ce qui entraîne une protection inférieure à celle obtenue lorsque c'est le serveur DPMI qui sépare les diverses machines virtuelles (ainsi s'expliquent les "plantages", si fréquents sous Windows 3.0 qu'ils ont conduit Windows, dans sa version 3.1, à vérifier beaucoup plus strictement les paramètres passés à ses fonctions internes), Toujours du fait que toutes les applications Windows partagent (avec le noyau de Windows) une seule machine virtuelle DPMI, le multitâche entre ces applications doit également être géré par Windows, ce qui explique sa non-préemptivité. En revanche, chaque tâche DOS lancée à partir de Windows (en mode 386 étendu) s'exécute dans sa propre machine virtuelle, ce qui permet au serveur DPMI d'imposer un multitâche préemptif entre ces tâches DOS et le reste de l'environnement Windows.
Supportée par les systèmes d'exploitation de Microsoft et d'IBM, la norme DPMI s'impose de plus en plus largement face aux anciennes spécifications VCPI. S'il existe encore plusieurs applications DOS qui utilisent la norme VCPI, le support de DPMI représente donc un "plus" indéniable pour un gestionnaire de mémoire, dans la mesure où il garantit la compatibilité avec les nouvelles versions des applications les plus gourmandes, A titre d'exemple, les derniers compilateurs C/C++ de Borland et Microsoft s'exécutent maintenant en mode protégé pour qu'on ait accès à davantage de mémoire ; le nouveau C/C++ 7.0 de Microsoft est même livré avec 386max comme serveur DPMI (version 0.9), afin de permettre l'utilisation du compilateur à partir du DOS seul (si le compilateur est exécuté sous une session Windows en mode 386 étendu, Windows fournit automatiquement le serveur DPMI requis), La présence d'un serveur DPMI sur un compatible PC-AT devient donc de plus en plus indispensable.