Les bibliothèques dynamiques (DLL)

La décoration de nom est l'action effectuée par certains compilateurs qui consiste à ajouter des symboles additionnels au nom des fonctions et/ou des variables. Ces symboles représentent souvent des informations qui sont indispensables pour le langage et/ou le compilateur. De manière générale, chaque compilateur a sa propre manière de décorer les noms. Ainsi, pour nous fixer les idées, nous supposons que nous travaillons avec Visual C++, le compilateur de référence en matière de développement Windows, mais les conclusions que nous tirerons seront applicables que vous travailliez avec ou non.

Visual C++ ajoute toujours un underscore (_) devant le nom d'une fonction cdecl. Cela signifie que si votre fonction s'appelle myfunc dans le fichier source, elle sera renommée en _myfunc dans le fichier objet. Sans commandes spéciales, c'est cependant le nom original qui sera utilisé dans le fichier final (c'est-à-dire l'exe ou la dll). Ainsi, dans le fichier test.dll de l'exemple II-B, le nom de la fonction exportée sera toujours TestDll (et non _TestDLL comme dans l'obj). Voici un programme test pour s'en convaincre :

#include <stdio.h>
#include <windows.h>

typedef int TESTDLLFUNC(void);

int main()
{
    HMODULE hTest = LoadLibrary("test.dll");
    
    if (hTest == NULL)
        fprintf(stderr, "Le fichier test.dll n'a pa pu etre charge.\n");
    else
    {
        TESTDLLFUNC * lpTestDll = (TESTDLLFUNC *)GetProcAddress(hTest, "TestDLL");

        if (lpTestDll == NULL)
            fprintf(stderr, "L'adresse de la fonction TestDLL n'a pas pu etre lue.\n");
        else
            lpTestDll();
        
        FreeLibrary(hTest);
    }

    return 0;
}

Encore plus loin, lorsqu'une fonction f (toujours supposée être cdecl) est exportée par une DLL, lors de l'édition des liens, deux « fonctions » sont placées dans la bibliothèque d'importation de la DLL : _f et _f préfixé de __imp_ soit __imp__f. Dans la DLL, il n'y a cependant bel et bien qu'une et une seule fonction, f, qu'il ne faut surtout pas confondre avec le symbole de même nom dans la bibliothèque d'importation. Pour preuve, on peut contrôler le nom de la fonction à l'intérieur de la DLL, mais on ne peut pas en faire autant pour les symboles de la bibliothèque d'importation.

Le préfixe __imp_ indique qu'il s'agit juste d'un « lien » (ou un « renvoi ») vers une fonction dont le code est situé dans la DLL associée. Et que fait au juste la « fonction » _f ? Et bien, elle ne fait rien de plus que donner la main à __imp__f ! Mais alors lorsqu'on fait référence à f dans le code source, cela génère-t-il en code machine une référence à _f ou à __imp__f ? Cela dépend de la manière dont vous avez déclaré f !

En effet, supposons que le prototype de f soit int f(void). Lorsqu'on déclare f avec :

int f(void);

Le compilateur, qui ne saura jamais deviner qu'il s'agit d'une fonction se trouvant dans une quelconque DLL, va se contenter de générer à chaque référence à f dans le code source une référence à _f dans le code machine.

Lorsqu'on déclare f avec :

__declspec(dllimport) int f(void);

Le compilateur saura qu'il s'agit d'une fonction se trouvant dans une DLL et génèrera dans ce cas, à chaque référence à f dans le code source, une référence à __imp__f dans le code machine. C'est pourquoi, lorsque vous vous liez à une bibliothèque d'importation, déclarez toujours les fonctions à importer avec __declspec(dllimport).

Visual C++ décore le nom d'une fonction stdcall en le préfixant d'un underscore et en ajoutant un suffixe constitué du caractère @ et de la quantité totale de mémoire requise par les paramètres de la fonction. Par exemple, si le prototype de votre fonction est int __stdcall myfunc(int, int), dans les fichiers objet, le nom de la fonction sera _myfunc@8. Si la fonction est exportée, alors on aura dans la bibliothèque d'importation les fonctions __myfunc@8 et __imp__myfunc@8. La fonction dans la DLL sera par défaut nommée _myfunc@8 (c'est-à-dire que c'est le nom décoré qui est utilisé).

Un fichier de définition de module (*.def) est un fichier texte permettant de lister entre autres les fonctions exportées par un module, en offrant plus d'options d'exportation qu'en utilisant __declspec(dllexport).

Voici un exemple de fichier def (qu'il faudra donc ajouter au projet) qui ordonne l'exportation de deux fonctions func1 et func2 :

EXPORTS
    func1
    func2

Exportées ainsi, les deux fonctions se trouveront nommées telles quelles (c'est-à-dire sans aucune décoration de nom !) dans la DLL. Dans la bibliothèque d'importation associée à la DLL, on aura par contre toujours les noms décorés (qui ne sont que des relais vers les véritables fonctions dans la DLL) selon les principes vus dans II-D.

On peut même spécifier les noms qu'on veut obtenir dans la DLL comme le montre l'exemple suivant :

EXPORTS
    DllFunc1=func1
    DllFunc2=func2

Dans ce cas les fonctions func1 et func2 seront nommées, dans la DLL, DllFunc1 et DllFunc2. Cette syntaxe permet également de créer ce qu'on appelle un relais (en anglais : forwarder), c'est-à-dire une fonction qui ne fait rien de plus que de donner directement la main à une autre. Par exemple, avec :

EXPORTS
    KernelBeep=kernel32.Beep

On obtiendra dans notre DLL une fonction nommée KernelBeep qui n'est juste qu'un relais menant à la fonction Beep se trouvant dans kernel32.dll.

La syntaxe complète d'une entrée de la section EXPORTS est la suivante :

entryname[=internalname] [@ordinal [NONAME]] [PRIVATE] [DATA]

• entryname est le nom de l'entrée qu'on veut créer dans la DLL.
• internalname est le nom de la fonction ou de la variable à exporter sous le nom entryname. Par défaut, internalname = entryname.
• ordinal est un numéro qu'on veut associer à l'entrée. L'ordinal peut être utilisé dans l'argument lpProcName de GetProcAdress (par exemple : GetProcAddress(hMod, « 1 »)).
• Le flag NONAME qui n'est disponible que lorsqu'un ordinal est spécifié indique qu'on ne veut pas avoir le nom de la fonction dans la DLL, juste l'ordinal. Cela permet de minimiser la taille des fichiers.
• Le flag PRIVATE indique qu'on ne veut pas avoir d'entrée pour la fonction ou la variable dans le .lib.
• Et enfin, le flag DATA indique qu'on est en train d'exporter une variable et non une fonction.

Dans les paragraphes suivants, nous allons mettre en évidence l'importance des DLL dans le système Windows (en plus du fait qu'elles sont utilisées pour exposer les API bien entendu…).

Savez-vous quelle est la différence entre un fichier EXE et un fichier DLL ? Un bit ! Pas même un octet, mais un bit. La seule chose qui permet de distinguer un fichier EXE d'un fichier DLL est un bit dans l'en-tête du fichier qui indique si le fichier est un EXE ou une DLL. En clair, ces fichiers ont exactement le même format.

Un fait qui en découle est bien sûr qu'on peut donc aussi exporter des fonctions depuis un EXE. Un autre, ce qui nous intéressera ici, est qu'il possible de mettre des ressources dans une DLL. Le fichier shell32.dll par exemple contient les icônes utilisées par l'explorateur Windows. Il y a aussi comdlg32.dll qui contient les modèles des boîtes de dialogue communes de Windows et bien d'autres exemples encore.

En conclusion, si vous développez des applications qui utilisent totalement ou en partie les mêmes ressources (icônes, bitmaps, boîtes de dialogue, etc.), alors vous tirerez beaucoup avantage en créant une ou plusieurs DLL de ressources.

Un hook est un programme notifié par Windows de chaque nouveau message dans un thread donné ou dans le système tout entier avant que le message n'atteigne son véritable destinataire.

Il existe plusieurs de types de hooks. Par exemple, un hook clavier est un hook qui n'est notifié que des messages provenant du clavier. Selon le type du hook, il peut examiner, modifier et/ou supprimer le message.

On peut aussi classer les hooks selon leur étendue. Ainsi, un hook global est un hook qui surveille le système tout entier et un hook local est un hook qui ne surveille qu'un processus voire juste un thread. Dans tous les cas, un hook a besoin d'un installeur (généralement un EXE) pour s'installer. L'installation se fait juste en appelant la fonction SetWindowsHookEx. Lorsqu'on n'a plus besoin du hook, il faut le désinstaller. Cela se fait en appelant la fonction UnhookWindowsHookEx.

HHOOK SetWindowsHookEx(int idHook, HOOKPROC lpfn, HINSTANCE hMod, DWORD dwThreadId);

idHook indique évidemment le type de hook qu'on veut installer. Ce sont des commandes commençant généralement par WH_. Par exemple, on a WH_KEYBOARD pour un hook clavier de haut niveau et WH_KEYBOARD_LL pour un hook clavier de bas niveau. Ce ne sont pas ce qui nous intéresse.

lpfn indique la procédure principale (la « Hook Proc ») qu'on veut associer au hook (c'est-à-dire la procédure qui « hooker »).

hMod indique le handle du module contenant la fonction pointée par lpfn. Mettre NULL si la fonction se trouve dans le module EXE lui-même.

dwThreadId indique, si hMod vaut NULL, l'ID du thread qu'on veut surveiller. Si hMod est différent de NULL, ce paramètre doit être mis à 0 et tous les threads du système seront surveillés.

La valeur retournée est le handle du hook et NULL en cas d'erreur. La fonction UnhookWindowsHookEx ne requiert que ce handle en argument.

La procédure principale (HookProc) d'un hook global doit être définie dans une DLL externe tandis que celle d'un hook local à un processus peut être définie dans l'EXE (l'installeur) lui-même. Dans ce tutoriel, nous allons prendre pour exemple un hook global. Une raison pourrait être que si la HookProc d'un hook global était implémentée dans l'installeur lui-même, les threads qui n'appartiennent pas au processus installeur ne pourront pas l'appeler, car ils appartiennent à un espace d'adressage différent de celui où la fonction existe (qui n'est autre que l'espace d'adressage de l'installeur). Il faut donc effectivement que la HookProc soit définie dans une DLL afin que tous les processus puissent s'y lier et accéder à la fonction.

LRESULT CALLBACK HookProc(int code, WPARAM wParam, LPARAM lParam);

Le rôle de chaque paramètre dépend du type de hook.

Après qu'un hook s'est correctement installé, il est placé dans ce qu'on appelle la chaîne de hooks. Le dernier hook installé est celui qui recevra en premier les notifications. Lorsqu'un hook reçoit un message, il peut, après avoir terminé tous ses traitements, passer le message au prochain hook de la chaîne (ou alors à son destinataire s'il n'y a plus de hook dans chaîne) en appelant la fonction CallNextHookEx et retournant ce que la fonction retourne, passer directement le message au destinataire en retournant 0 ou encore arrêter la progression du message (c'est-à-dire le supprimer) en retournant une valeur différente de 0. Rappelons cependant que les hooks n'ont pas tous les mêmes droits sur les messages qu'ils reçoivent et que vous n'avez donc pas parfois beaucoup de choix quant à la valeur que votre HookProc doit retourner.

Les hooks les plus utilisés sont :

• les Keyboard Hooks (WH_KEYBOARD et WH_KEYBOARD_LL), notifiés de tous les messages provenant du clavier. Ils sont réputés maléfiques, car ils sont principalement utilisés dans la fabrication de logiciels d'espionnage appelés keyloggers (enregistreurs de frappe). Ces hooks peuvent examiner et supprimer un message ;
  
  
• les Mouse Hooks (WH_MOUSE et WH_MOUSE_LL), notifiés de tous les messages provenant de la souris. Ils sont utilisés la plupart du temps pour créer des extensions de l'environnement graphique ou dans des applications maniaques du contrôle. Ces hooks peuvent examiner et supprimer un message ;
  
  
• les Get Message Hooks (WH_GETMESSAGE), notifiés des messages lus par GetMessage ou PeekMessage avant que ces fonctions ne retournent. Ils ne peuvent donc être notifiés que des messages issus d'une queue de messages (messages clavier, souris, WM_PAINT, WM_TIMER, WM_QUIT et messages postés à l'aide de PostMessage par exemple). Ces hooks peuvent examiner et modifier un message ;
  
  
• les Call Window Proc Hooks (WH_CALLWNDPROC), notifiés des messages qui sont sur le point d'être directement passés à une procédure de fenêtre, que le message ait été envoyé par Windows lui-même ou par une application (via SendMessage par exemple). Ce type de message regroupe la majorité des messages Windows. Ces hooks ne peuvent qu'examiner un message.
  
  

Utilisés en même temps, un Get Message Hook et un Call Window Proc Hook permettent donc de hooker tous les messages transitant dans le système tout entier. C'est ainsi que fonctionnent basiquement les logiciels de surveillance comme Spy++, un programme livré avec Visual Studio.

Créons donc, pour avoir du concret, un hook tout simple, un Call Window Proc Hook. Pour un tel hook, les paramètres de la HookProc ont les significations suivantes :

• code vaut HT_ACTION lorsqu'il y a un message à traiter. Lorsque code est inférieur à 0, il faut immédiatement retourner la valeur retournée par CallNextHookEx ;
• wParam vaut VRAI si le message vient du thread courant (c'est-à-dire le thread qui a installé le hook) et FAUX dans les autres cas ;
• lParam contient l'adresse d'une structure CWPSTRUCT contenant les informations sur le message (hwnd, message, wParam et lParam).

Voici donc, à titre d'exemple, le code d'un hook global qui surveille les messages WM_CREATE et WM_DESTROY - hook.dll - et celui de son gestionnaire (lanceur/stoppeur) : hookman.exe.

#include <stdio.h>
#include <windows.h>

struct {
    char FileName[MAX_PATH];
    FILE * fOut;
} MyApp; /* Représente le processus lié à la DLL. */

LRESULT CALLBACK CallWndProc(int code, WPARAM wParam, LPARAM lParam);

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    BOOL ret = TRUE;

    switch(fdwReason)
    {
    case DLL_PROCESS_ATTACH:
        strcpy(MyApp.FileName, "<unknown>");
        GetModuleFileName(NULL, MyApp.FileName, sizeof(MyApp.FileName));
        MyApp.fOut = fopen("c:\\hooklog.txt", "a");
        if (MyApp.fOut == NULL)
            ret = FALSE;
        break;

    case DLL_PROCESS_DETACH:
        if (MyApp.fOut != NULL)
            fclose(MyApp.fOut);
        break;
    }

    return ret;
}

LRESULT CALLBACK CallWndProc(int code, WPARAM wParam, LPARAM lParam)
{
    if (code == HC_ACTION)
    {
        PCWPSTRUCT lpcwps = (PCWPSTRUCT)lParam;

        switch(lpcwps->message)
        {
        case WM_CREATE:
            /* On va s'intéresser qu'aux fenêtres qui n'ont pas de parent. */
            if (GetParent(lpcwps->hwnd) == NULL)
            {
                char lpBuffer[256];

                fprintf(MyApp.fOut, "[WM_CREATE]\n");
                fprintf(MyApp.fOut, "App=%s\n", MyApp.FileName);

                *lpBuffer = '\0';
                GetClassName(lpcwps->hwnd, lpBuffer, sizeof(lpBuffer));
                fprintf(MyApp.fOut, "Class=%s\n", lpBuffer);

                *lpBuffer = '\0';
                GetWindowText(lpcwps->hwnd, lpBuffer, sizeof(lpBuffer));
                fprintf(MyApp.fOut, "Name=%s\n", lpBuffer);

                fprintf(MyApp.fOut, "Handle=%#010x\n\n", (unsigned)lpcwps->hwnd);
            }
            break;

        case WM_DESTROY:
            if (GetParent(lpcwps->hwnd) == NULL)
            {
                fprintf(MyApp.fOut, "[WM_DESTROY]\n");
                fprintf(MyApp.fOut, "Handle=%#010x\n\n", (unsigned)lpcwps->hwnd);
            }
            break;
        }
    }

    return CallNextHookEx(NULL, code, wParam, lParam);
}

#include <stdio.h>
#include <windows.h>

int main()
{
    HMODULE hmodHook = LoadLibrary("hook.dll");
    HHOOK hHook = SetWindowsHookEx(WH_CALLWNDPROC, (HOOKPROC)GetProcAddress(hmodHook, "CallWndProc"), hmodHook, 0);
    if (hHook)
    {
        printf("Appuyez sur ENTREE pour terminer.\n");
        getchar();
        UnhookWindowsHookEx(hHook);
    }
    FreeLibrary(hmodHook);
    return 0;
}

Lors de son chargement, user32.dll charge également dans le processus des DLL additionnelles appelées AppInit_DLL. Ce sont des DLL tout à fait normales à part qu'elles sont inscrites dans la valeur AppInit_DLL de la clé :

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows

Si on veut inscrire plusieurs DLL, il faut les séparer par un point-virgule.

Les AppInit_DLL sont le plus souvent utilisées pour créer des classes de fenêtre globales. En effet, en enregistrant une classe pendant l'initialisation d'une AppInit_DLL, on est sûr de pouvoir utiliser cette classe depuis n'importe quelle application graphique (car toutes les applications graphiques se lient avec au moins user32.dll, en plus de kernel32.dll qui est obligatoire pour toutes les applications bien sûr). Il y a cependant une petite différence entre les classes globales et les classes locales, c'est tout simplement que les premières doivent posséder le style CS_GLOBALCLASS.

Depuis Windows 7, les valeurs suivantes ont également été ajoutées dans la même clé :

• LoadAppInit_DLL (DWORD) qui indique à user32.dll si les AppInit_DLL doivent être chargées ou non (1 pour oui et 0 pour non) ;
• RequireSignedAppInit_DLL (DWORD) qui indique si seules les DLL numériquement signées peuvent être chargées en tant qu'AppInit_DLL ou si toutes les DLL peuvent l'être.

Cela évidemment pour des raisons de sécurité. Les valeurs par défaut pour ces entrées sont respectivement 1 et 0 pour des raisons de compatibilité avec les versions antérieures.

Pour ajouter une signature numérique à vos fichiers, utilisez les outils fournis par Microsoft.

Les langages à objets ou orientés objets tels que VB, C++, Java, etc. permettent généralement de développer plus rapidement des applications que les langages procéduraux tels que le Pascal ou le C. Cela est notamment dû à leur support de ce qu'on appelle classes (qui sont des versions plus perfectionnées de ce qu'on appelle structures en C) qui facilitent énormément la réutilisabilité des codes sources. Malheureusement, la compilation des codes écrits dans ces langages nécessite des techniques relativement complexes et à priori spécifiques au langage. Cela signifie que si vous créez une DLL de classes C++, il vous sera pratiquement impossible de l'utiliser dans un langage autre que le C++ lui-même. Microsoft a donc développé une spécification appelée COM (Component Object Model) permettant à une bibliothèque écrite dans un langage donné d'être utilisable depuis d'autres langages pour peu que la DLL soit bien conforme à la spécification COM et que le langage avec lequel on veut l'utiliser supporte cette spécification. COM permet donc la réutilisabilité du code jusqu'au niveau binaire. Un EXE ou une DLL hébergeant des composants COM est appelé un serveur COM.

Pratiquement tous les langages disponibles sous Windows (C, C++, VB, Delphi, Java, C#, etc.) supportent COM. COM en soi est cependant indépendant de tout langage de tout système d'exploitation bien qu'il est rare d'en entendre parler en dehors de Windows. Chaque fois que Microsoft doit sortir une API orientée objet (certaines API seraient trop difficiles à utiliser si elles étaient procédurales), l'API sera le plus souvent basé sur COM.

Voici la section sur MSDN pour en savoir plus sur COM : Component Object Model (COM).

Un assembly est un ensemble de composants (généralement des DLL) constituant une version donnée d'une bibliothèque. Cela permet d'avoir multiples versions d'une même bibliothèque sur un même système. Avec de « simples » bibliothèques, on ne peut avoir qu'une seule version par système ce qui réduit la capacité du système à héberger différentes applications.

Les applications utilisent un fichier MANIFEST pour indiquer les versions des différentes bibliothèques avec lesquelles elles désirent se lier. Les assemblies aussi utilisent des fichiers MANIFEST pour se décrire. Nous avons déjà eu l'occasion de les utiliser dans les tutoriels antérieurs. Lorsque les bibliothèques requises par une application sont toutes décrites par un MANIFEST, alors l'application n'a aucun risque d'utiliser une mauvaise version d'une de ces bibliothèques. On dit alors qu'elle est isolée. La technologie qui permet cette gestion élégante et ultra sécurisée des bibliothèques sous Windows est appelée la technologie Side-by-side (SxS), introduite pour la première fois avec Windows XP. Un side-by-side assembly est un assembly qui ne peut être utilisée qu'avec la technologie side-by-side, c'est-à-dire à l'aide d'un fichier MANIFEST. Les versions de la CRT depuis Visual Studio .NET en sont des exemples.

Voici la section sur MSDN pour en savoir plus sur la technologie SxS : Isolated Applications and Side-by-side Assemblies.