Développement de DLL (traduction automatique)

Article
09/24/2014

Dernière modification : vendredi 13 mars 2009

S’applique à : Excel 2010 | Office 2010 | VBA | Visual Studio

Dans cet article
Avantages de l'utilisation des DLL
Ressources pour la création de DLL
Exportation de fonctions et commandes

Important

Cet article a été traduit automatiquement, voir l’avertissement. Vous pouvez consulter la version en anglais de cet article ici.

Une bibliothèque est un corps de code compilé qui fournit des fonctionnalité et des données à une application exécutable. Les bibliothèques peuvent être liées de manière statique ou bien dynamique, et par convention ont des extensions de nom de fichier .lib et .dll respectivement. Les bibliothèques statiques (comme la bibliothèque d’exécution C) sont liées à l’application au moment de la compilation et de ce fait font partie de l’exécutable résultant. L’application charge une DLL si nécessaire, généralement lorsque l’application démarre. Une DLL peut charger et se lier dynamiquement à une autre DLL.

Avantages de l'utilisation des DLL

Les principaux avantages des DLL sont comme suit :

Toutes les applications peuvent partager une seule copie sur disque.
Fichiers exécutables des applications sont conservés plus petits.
Ils permettent aux projets de développement volumineux être ventilées. Les développeurs d'application et la DLL est nécessaire uniquement conviennent d'une interface entre leurs pièces respectives. Cette interface est exportée par la DLL.
Les développeurs DLL peuvent mettre à jour les DLL — peut-être à les rendre plus efficace ou pour résoudre un bogue — sans avoir à mettre à jour toutes les applications qui l'utilisent, sous réserve que l'interface de la DLL exportée ne change pas.

Vous pouvez utiliser la DLL pour ajouter des commandes et les fonctions de feuille de calcul dans Microsoft Excel.

Ressources pour la création de DLL

Pour créer une DLL, vous devez les éléments suivants :

Un éditeur de code source.
Un compilateur pour activer le code source en code objet qui est compatible avec votre matériel.
Un éditeur de liens pour ajouter du code à partir de bibliothèques statiques, cas d'emploi et pour créer le fichier exécutable de la DLL.

Les environnements modernes de développement intégré (IDE), tels que Microsoft Visual Studio, fournissent toutes ces choses. Ils fournissent également beaucoup plus : smart éditeurs, outils pour déboguer votre code, outils de gestion de plusieurs projets, nouveaux Assistants de projet et de nombreux autres outils importants.

Vous pouvez créer des DLL en plusieurs langues, par exemple, C/C++, Pascal et Visual Basic. Étant donné que le code source API disponibles dans Excel est c et C++, seulement ces deux langages sont considérés comme dans cette documentation.

Exportation de fonctions et commandes

Lorsque vous compilez un projet DLL, le compilateur et l'éditeur de liens ont besoin de savoir quelles sont les fonctions à exporter afin qu'ils peuvent les rendre disponibles pour l'application. Cette section décrit les méthodes pour ce faire.

Lorsque les compilateurs compiler le code source, en règle générale, ils modifient les noms des fonctions à partir de leur apparence dans le code source. Ils généralement y parvenir en ajoutant au début et/ou à la fin du nom, dans le cadre d'un processus de décoration de nom. Vous devez vous assurer que la fonction est exportée avec un nom reconnaissable pour la chargement de la DLL d'application. Cela peut signifier indiquant l'éditeur de liens pour associer le nom décoré avec un nom plus simple d'exportation. Le nom d'exportation peut être le nom tel qu'il apparaissait à l'origine dans le code source, ou toute autre chose.

La façon dont le nom est décoré varie selon la langue et la façon dont le compilateur reçoit l'instruction pour libérer de la fonction, en d'autres termes, convention d'appel. La convention d'appel inter-processus standard pour Windows utilisé par les DLL est appelée à la convention WinAPI . Il est défini dans les fichiers d'en-tête Windows en tant que WINAPI, qui est défini à son tour à l'aide de la __stdcall déclarateur de Win32.

Une fonction d'exportation de DLL à utiliser avec Excel (si elle est une fonction de feuille de calcul, la fonction équivalente feuille macro ou la commande de défini par l'utilisateur) doit toujours utiliser la WINAPI / __stdcall convention d'appel. Il est nécessaire d'inclure le spécificateur de WINAPI explicitement dans la définition de la fonction, comme la valeur par défaut dans les compilateurs Win32 consiste à utiliser la convention d'appel __cdecl, également définie en tant que WINAPIV, si aucun n'est spécifié.

Vous pouvez indiquer à l'éditeur de liens est une fonction à exporter et le nom, qu'il doit être connue par l'extérieur de plusieurs manières :

Placez la fonction dans un fichier DEF après le mot clé EXPORTS et réglez votre projet DLL pour faire référence à ce fichier lors de la liaison.
Utilisez le déclarateur de __declspec(dllexport) dans la définition de la fonction.
Utilisez une directive de préprocesseur #pragma pour envoyer un message à l'éditeur de liens.

Bien que votre projet peut utiliser tous les trois méthodes et votre compilateur et l'éditeur de liens les prennent en charge, vous ne devez pas tenter d'exporter une fonction dans plus d'une des manières suivantes. Par exemple, supposons qu'une DLL contient deux modules de code source, un c et C++, qui contiennent les deux fonctions à exporter un, my_C_export et my_Cpp_export respectivement. Par souci de simplicité, supposons que chaque fonction prend un seul argument numérique double précision et renvoie le même type de données. Les possibilités d'exportation de chaque fonction à l'aide de chacune de ces méthodes sont décrites dans les sections suivantes.

À l'aide d'un fichier DEF

double WINAPI my_C_export(double x)
{
/* Modify x and return it. */
    return x * 2.0;
}

double WINAPI my_Cpp_export(double x)
{
// Modify x and return it.
    return x * 2.0;
}

Le fichier DEF doit contenir ces lignes.

EXPORTS
    my_C_export = _my_C_export@8
    my_Cpp_export

La syntaxe générale d'une ligne qui suit une instruction EXPORTS est la suivante.

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

Notez que la fonction c a été décorée, mais le fichier DEF explicitement force l'éditeur de liens pour exposer la fonction en utilisant le nom de code source d'origine (dans cet exemple). L'éditeur de liens exporte implicitement la fonction C++ en utilisant le nom de code d'origine, afin qu'il n'est pas nécessaire d'inclure le nom décoré dans le fichier DEF.

Pour les appels de fonction API Windows 32 bits, la convention pour la décoration des fonctions compilées c est la suivante : function_name devient _function_name@n , où n est le nombre d'octets exprimés en valeurs décimales pris en charge par tous les arguments, avec le nombre d'octets pour chaque arrondi au multiple plus proche de quatre.

Notes

Tous les pointeurs sont les quatre octets dans Win32. Le type de retour n'a aucun impact sur la décoration de nom.

Il est possible de forcer le compilateur C++ pour exposer les noms non décorés de fonctions C++ en plaçant la fonction et les prototypes de fonction, dans un bloc d'extern "C" {…}, comme illustré dans cet exemple. (La {} accolades sont omises ici parce que la déclaration fait référence uniquement pour le bloc de code de fonction qui la suit immédiatement).

extern "C"
double WINAPI my_undecorated_Cpp_export(double x)
{
// Modify x and return it.
    return x * 2.0;
}

Lorsque vous placez les prototypes de fonction c dans les fichiers d'en-tête pouvant être inclus dans les fichiers source c ou C++, vous devez inclure la directive de préprocesseur suivante.

#ifdef __cplusplus
extern "C" {
#endif

double WINAPI my_C_export(double x);
double WINAPI my_Cdecorated_Cpp_export(double x);

#ifdef __cplusplus
}
#endif

En utilisant le déclarateur __declspec (dllexport)

Le mot clé __declspec(dllexport) peut être utilisé dans la déclaration de la fonction comme suit.

__declspec(dllexport) double WINAPI my_C_export(double x)
{
/* Modify x and return it. */
    return x * 2.0;
}

Le mot clé __declspec(dllexport) doit être ajouté à l'extrême gauche de la déclaration. Les avantages de cette approche sont que la fonction n'a pas besoin de figurer dans un fichier DEF, et que l'état d'exportation est droite avec la définition.

Si vous souhaitez éviter une fonction C++ soient communiquée à la décoration des noms, vous devez déclarer la fonction comme suit.

extern "C"
__declspec(dllexport) double WINAPI my_undecorated_Cpp_export(double x)
{
// Modify x and return it.
    return x * 2.0;
}

L'éditeur de liens rendra la fonction disponible en tant que my_undecorated_Cpp_export, autrement dit, le nom tel qu'il apparaît dans le code source avec aucune décoration.

À l'aide d'une Directive d'éditeur de liens de préprocesseur # pragma

Les versions récentes de Microsoft Visual Studio prend en charge deux macros prédéfinies qui, lorsqu'elle est utilisée en conjonction avec une directive de #pragma, permettent de demander à l'éditeur de liens pour exporter la fonction directement dans le code de fonction. Les macros sont __FUNCTION__ et __FUNCDNAME__ (Notez le trait de soulignement double à chaque extrémité) qui sont développés respectivement aux noms des fonctions non décorés et décorés.

Par exemple, lorsque vous utilisez Microsoft Visual Studio, ces lignes peuvent être incorporés comme suit dans un fichier d'en-tête commun.

#if _MSC_VER > 1200 // Later than Visual Studio 6.0
#define EXPORT comment(linker, "/EXPORT:"__FUNCTION__"="__FUNCDNAME__)
#else // Cannot use this way of exporting functions.
#define EXPORT
#endif // else need to use DEF file or __declspec(dllexport)

Si cet en-tête est inclus dans les fichiers source, les deux exemples de fonctions peuvent ensuite être exportés comme suit.

Code c :

double WINAPI my_C_export(double x)
{
#pragma EXPORT
/* Modify x and return it. */
    return x * 2.0;
}

Code C++ :

double WINAPI my_Cpp_export(double x)
{
#pragma EXPORT
// Modify x and return it.
    return x * 2.0;
}

Notez que la directive doit être placée dans le corps de la fonction et qu'elle est développée uniquement lorsque aucune option du compilateur options /EP ou /P est définie. Cette technique élimine le besoin d'un fichier de définition, déclaration d'or__declspec(dllexport) et conserve la spécification de son état d'exportation avec le code de fonction.

Notes

Avertissement traduction automatique : cet article a été traduit par un ordinateur, sans intervention humaine. Microsoft propose cette traduction automatique pour offrir aux personnes ne maîtrisant pas l’anglais l’accès au contenu relatif aux produits, services et technologies Microsoft. Comme cet article a été traduit automatiquement, il risque de contenir des erreurs de grammaire, de syntaxe ou de terminologie.