Dans cet article, je suppose que vous êtes familier avec le mode protégé des microprocesseurs 80x86 et que vous avez des connaissances sur V86, GDT, LDT, IDT. Si vous avez des lacunes, vous pouvez les combler en lisant la documentation INTEL sur le site.

http://developer.intel.com/design/pentium/manuals

2 Comment fonctionne Windows 9x

Windows 9x est un système d’exploitation multitâche fonctionnant dans le niveau de privilège le plus élevé, dit ring-0. Tous les programmes d’application fonctionnent au niveau de privilège le plus faible, appelé ring-3. Comme de tels programmes sont volontairement limités dans leurs possibilités et ne peuvent pas faire ce qu’ils veulent du système, ils ne peuvent utiliser certaines instructions privilégiées du processeur, ils ne peuvent accéder directement aux ports d’entrée et de sortie, etc.

Vous êtes sûrement familier avec les trois plus importants composants du système d’exploitation : gdi32, kernel32 et user32. Vous pouvez penser que des composants de cette importance tournent dans le ring-0. Il n’en est rien, ils fonctionnent dans le ring-3, comme toutes les autres applications. Ils n’ont pas plus de privilèges que la calculatrice ou le jeu du démineur.

La puissance réelle du système est sous le contrôle du gestionnaire de machine virtuelle (VMM) et des pilotes de périphériques virtuels (VxD).

Tout cela ne serait pas ainsi si DOS n’avait pas rendu le problème aussi compliqué. Durant la période Windows 3.x le marché des DOS avait encore beaucoup de succès. Windows 3.x devait être capable de fonctionner cote à cote du DOS sous peine d’échec commercial. Ce dilemme n’est pas aisé à résoudre. Les programmes DOS et Windows sont fondamentalement différents l’un de l’autre. Les programmes DOS sont mauvais dans le sens ou ils ont un accès total sur le système : clavier, processeurs, mémoire, disques, etc. Ils ne savent pas coopérer avec d’autres programmes alors que les programmes Windows (au même moment) comptent sur un multitâche coopératif. Chaque programme Windows doit rendre la main aux autres programmes par GetMessage ou PeekMessage.

La solution est de faire tourner chaque programme DOS dans une machine virtuelle 8086 ,tandis que les autres programmes Windows fonctionnent dans une autre machine virtuelle appelée machine virtuelle système. Windows est responsable de la répartition du temps processeur entre les machines virtuelles. Ainsi sous Windows 3.x, les programmes Windows utilisent le multitâche coopératif alors que les machines virtuelles utilisent le multitâche préemptif.

3 Qu’est ce qu'une machine virtuelle ?

C’est une fiction crée exclusivement pour le software. Une machine virtuelle réagit comme une machine réelle aux programmes. Ainsi un programme ignore qu’il tourne dans une machine virtuelle et ne s’en souci pas. Comme Une machine virtuelle se comporte comme une machine réelle, elle peut être traitée comme telle.
L’interface entre la machine réelle et le software est basé sur une sorte d’API. Cette API inhabituelle est faite d’interruptions, d’appels BIOS et d’accès aux ports. Si Windows peut d’une manière ou d’une autre émuler exactement cette API, les programmes fonctionneront dans la machine réelle comme ils sont capables de le faire dans la machine réelle.

C’est ici que le VMM et les VxD entrent en scène. Pour coordonner et superviser les machines virtuelles (VM), Windows à besoin d’un gestionnaire dédié à cette tache. C’est le Virtual Machine Manager (VMM).

4 Le Virtual Machine Manager

4.1 Généralités

VMM est un programme 32-bit en mode protégé. Sa première responsabilité est de bâtir et maintenir l’ossature qui supporte les machines virtuelles (VM). Il doit ainsi, créer, faire fonctionner et terminer les VM.

Le VMM est stocké dans VMM32.VXD situé dans le dossier système. C’est un VxD spécial qui peut être considéré comme le superviseur des autres VxD.

4.2 Séquence de démarrage de Windows 9x

io.sys est chargé en mémoire.
config.sys et autoexec.bat sont traités.
win.com est appelé
win.com lance VMM32.VXD qui est en réalité un simple fichier EXE DOS.
VMM32.VXD charge le VMM en mémoire étendu en utilisant le driver XMS, généralement himem.sys.
VMM s’auto-initialise et initialise aussi les autres VxD.
VMM bascule la machine en mode protégé et crée la machine virtuelle système.
L’interpréteur de commande virtuel (VSD), qui est chargé en premier, démarre Windows dans la VM système en lançant krnl386.exe.
krnl386.exe charge les autres fichiers, et en arrive à l’interface de Windows 9x.

4.3 Récapitulatif

Comme vous pouvez le voir, VMM est le premier VxD chargé en mémoire. Il crée la machine virtuelle système et initialise les autres VxD. Il alloue également un numéro de service à ces VxD.

Le fonctionnement du VMM et des VxD est différent de celui des programmes réels. Ils dorment la plupart du temps. Tant que les programmes des applications sont actifs, ces VxD sont inactifs. Ils sont réveillés dans certaines occasions, quand des interruptions, fautes, événements réclament leur attention. Le VMM n’est pas ré-entrant. Cela signifie que les VxD doivent synchroniser leurs accès aux services du VMM. Il y a certaines situations dans lesquelles il n’est pas sur d’appeler un service du VMM, par exemple quand une interruption hardware est en train d’être traitée. Pendant le temps de ce traitement, le VMM ne peut tolérer la ré-entrance. Le développeur de VxD devra être extrêmement prudent sur ce qu’il est en train de faire. Rappelez-vous ceci, il n’y aucun garde-fou pour vous protéger contre les erreurs de code. Vous faites absolument ce que vous voulez dans le ring-0.

5 Les Virtual Device Drivers

5.1 Généralités

VxD est l’abréviation de Virtual Device Driver, c’est à dire pilote de périphérique virtuel. Le x représente la place du périphérique, qui peut être un clavier, une souris ou autre dispositif. Les VxD sont les clés de la virtualisation du hardware. Souvenez-vous que les programmes DOS pensent être les seuls à interférer avec le système. Quand ils fonctionnent dans des machines virtuelles, Windows doit fournir l’interface avec le matériel réel. Les VxD sont ces interfaces.

Les VxD virtualisent généralement la plupart des composants hardware. Quand par exemple, un programme DOS pense accéder au clavier, c’est en réalité au pilote virtuel de clavier qu’il accède. Un VxD prend généralement le contrôle du matériel et organise le partage de ce matériel entre les machines virtuelles. Toutefois il n’y a pas de règle qui impose à un VxD d’être lié à un composant hardware. Il est vrai que les VxD sont conçus pour cela, mais nous pouvons aussi considérer les VxD comme des DLL agissant dans le ring-0.

Par exemple, si vous voulez des caractéristiques qui ne peuvent être obtenues que dans le ring-0, vous pouvez écrire un VxD qui effectue ce travail. Dans ce sens, vous pouvez considérer un VxD comme une extension de programme, étant donné qu’il ne virtualise pas de hardware. Avant de plonger dans le sujet et d’écrire votre propre VxD, laissez moi rajouter quelques éléments concernant ce sujet.

Les VxD sont spécifiques à Windows 9x. Ils ne fonctionnent pas sous Windows NT. Aussi si vos programmes sont dépendants de VxD, ils ne seront pas portables sur la plate-forme Windows NT.

Les VxD sont les plus puissantes entités du système. Comme ils peuvent faire ce qu’ils veulent, ils sont de fait extrêmement dangereux. Un VxD fou peut faire un crash du système. Il n’y a pas de protection contre ce VxD dévoyé. La plupart du temps il y a des tas de manière pour obtenir le but désiré sans recourir aux VxD. Réfléchissez deux fois plutôt qu’une avant de choisir la solution VxD. S’il y a moyen d’effectuer cette tache autrement en restant en ring-3, utilisez cette méthode.

Il y a deux types de VxD sous Windows 9x : Les VxD statiques et les VxD dynamiques.

5.2 Les VxD statiques

Les VxD statiques sont ceux qui sont chargés durant le démarrage du système d’exploitation. Ce type de VxD date de l’époque de Windows3.x.

5.3 Les VxD dynamiques

Les VxD dynamiques sont disponibles sous Windows 9x seulement. Ces VxD peuvent être chargés ou déchargés à la demande. La plupart d’entre eux sont des VxD contrôlant des périphériques Plug and Play et sont chargés par le Configuration Manager et l’Input Output Supervisor. Vous pouvez aussi charger ou décharger un VxD dynamique depuis votre application win32.

6 Communication entre les VxD

6.1 Généralités

Les VxD, VMM inclus, communiquent entre eux via trois mécanismes : les messages de contrôle, les API de service, les Callbacks.

6.2 Les messages de contrôle

Le VMM envoie des messages de contrôle à TOUS les VxD chargés du système quand certains événements spécifiques surviennent. Dans un sens, les messages de contrôle sont comme les messages d’applications Windows en ring-3. Chaque VxD a une fonction, appelée procédure de contrôle de périphérique, qui reçoit et distribue les messages de contrôle. Il y a une cinquantaine de messages de contrôle système. S’il n’y a pas plus de messages de contrôle, c’est qu’il a la plupart du temps plusieurs VxD chargés en même temps, et que comme chacun d’eux doit traiter ce message, cela pourrait conduire à ralentir, voir figer le système. Pour ce faire, vous ne devriez trouver que des messages réellement importants relatifs aux VM, comme par exemple la création ou la destruction de VM. En plus des messages de contrôle système, un VxD peut définir ses propres messages de contrôle pour communiquer avec d’autres VxD capables de les comprendre.

6.3 Les API de services

Un VxD, VMM y compris, exporte fréquemment une série de fonctions publiques pouvant être appelées par d’autre VxD. De telles fonctions sont appelées services VxD.

Le mécanisme d’appel de ces services VxD sont sensiblement différents des mécanismes d’appel des applications en ring-3. Chaque VxD qui exporte des services VxD doit se voir attribuer un identificateur unique (ID) sous la forme d’un nombre 16-bit. Vous pouvez obtenir certains de ces ID auprès de Microsoft.

Par exemple :

UNDEFINED_DEVICE_ID     EQU 00000H
VMM_DEVICE_ID           EQU 00001H
DEBUG_DEVICE_ID         EQU 00002H
VPICD_DEVICE_ID         EQU 00003H
VDMAD_DEVICE_ID         EQU 00004H
VTD_DEVICE_ID           EQU 00005H

Vous pouvez ainsi voir que L’ID du VMM est 1, l’ID de VPICD est 3 et ainsi de suite. Le VMM utilise cet ID unique pour trouver le VxD qui exporte les services requis du VxD. Vous devez également sélectionner le service désiré, via un index dans la table de services. Quand un VxD exporte des services, il range l’adresse du service dans une table. Le VMM utilise l’index de la table de services qui lui est fourni, pour localiser l’adresse du service.

Par exemple, si vous désirer appeler GetVersion qui est le premier service, vous devez spécifier 0 (l’index démarre à zéro). Le mécanisme réel d’appel d’un service de VxD est basé sur l’interruption 20h. Votre code commence par int 20h suivi par une valeur dword composée de l’ID du VxD et de l’index du service index. A titre d’exemple si vous appelez le service 1 d’un VxD dont l’ID est 000Dh, le code devrait être le suivant :

int 20h
dd 000D0001h

Le mot de poids fort du dword suivant l’instruction int 20h contient l’ID. Le mot de poids faible est l’index commençant par zéro dans la table des services. Quand int 20h est déclenchée, VMM obtient le contrôle et examine le dword qui suit immédiatement l’instruction d’interruption, il en extrait l’ID et l’utilise pour localiser le VxD, il en extrait ensuite l’index pour obtenir l’adresse du service dans ce VxD. Vous pouvez constater que cette opération est consommatrice de temps. Le VMM doit gaspiller du temps pour localiser le VxD, puis pour déterminer l’adresse du service. Aussi le VMM triche un peu. Après un appel réussi à int 20h, le VMM remplace int 20h et le dword qui le suit par un appel direct au service. L’instruction int 20h suivie du dword sera transformée en :

call dword ptr [VxD_Service_Address]

Cette combine fonctionne parce que la taille de int 20h + dword est de 6 octets, soit exactement la même taille que l’instruction dword ptr.

Cet appel est efficace mais la méthode a des avantages et des inconvénients. D’un coté la charge du VMM et du chargeur de VxD est réduite, car il est inutile de prédéterminer tous les appels lors du chargement et les appels jamais exécutés restent donc non modifiés. D’un autre coté, cela rend le VxD impossible à décharger car le VMM prépare l’appel avec l’adresse véritable du service du VxD.

Il n’y a pas de mécanisme pour faire marche arrière avec cette tricherie.

Le corollaire de ceci est que les VxD dynamiques ne sont pas adaptés en tant que fournisseur de services.

6.4 les callbacks

Les fonctions de rappel ou Callbacks sont des fonctions de VxD conçues pour être appelées par d’autres VxD. Ne confondez pas les Callbacks et les services VxD. Les Callbacks ne sont pas publiques contrairement aux services. Ce sont des fonctions privées qui donnent leur adresse aux autres VxD dans certaines circonstances particulières.

Par exemple quand un VxD traite une interruption hardware, comme le VMM n’est pas ré-entrant, le VxD ne peut utiliser aucun service, ce qui provoquerait une faute de page. Le VxD peut donner l’adresse d’une de ses propres fonctions au VMM et ce VMM appellera la fonction quand celle ci pourra effectuer son travail sans créer de faute de page. Le VxD ne réalise donc son travail que quand sa fonction de rappel est appelée.

L’idée des callbacks n’est pas exclusive aux VxD. De nombreuses API Windows font de même. Le meilleur exemple est certainement la procédure de fenêtre. Vous spécifiez l’adresse de la procédure de fenêtre dans la structure WNDCLASS ou WNDCLASSEX et vous passez cette structure à Windows avec un appel à RegisterClass ou à RegisterClassEx. Windows appelle votre procédure quand il y a des messages destinés à la fenêtre.

Un autre exemple est la procédure de Hook. Votre application donne l’adresse de cette procédure à Windows ce qui permet d’intercepter certains événements d’une application.

6.5 Synthèse

Ces trois techniques sont faites pour les communications entre VxD. Il existe aussi des interfaces pour V86, le mode protégé et les applications win32.

Page: 1 2 3 4 5 6 7 8 9

Précédent Suivant

Qu’est ce qu’un VxD ?

1 Introduction