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
sexé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.