P/Invoke

Cet article est une ébauche concernant l’informatique et un logiciel.

Vous pouvez partager vos connaissances en l’améliorant (comment ? ) selon les recommandations des projets correspondants.

Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.

Cet article ne cite pas suffisamment ses sources (septembre 2015).

Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».

En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?

Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.

L'article doit être débarrassé d'une partie de son jargon (septembre 2020).

Sa qualité peut être largement améliorée en utilisant un vocabulaire plus directement compréhensible.

Discutez des points à améliorer en page de discussion.

P/Invoke (aussi appelé Platform Invocation Services) de Microsoft est une spécification de l'implémentation de CLI, qui permet au managed code d'appeler du code natif dans les DLL. Le code natif est référencé via les meta-données qui décrivent les fonctions exportées d'une DLL.

Utilisation

[modifier | modifier le code ]

Quand P/Invoke est utilisé, le CLR gère le chargement des DLL et la conversion des types en types CTS. Pour réaliser cela, le CLR effectue les étapes suivantes :

Localiser l'emplacement de la DLL qui contient la fonction recherchée
Charger la DLL en mémoire
Trouver l'adresse en mémoire de la fonction et ajouter ses arguments dans la Pile d'appel
Convertir les types de données de .NET en un autre type

P/Invoke est utile pour accéder à des DLL qui ne sont pas basées sur Microsoft .NET, notamment celles basées sur C ou C++.

Le ramasse-miettes ne fonctionne pas à l'intérieur de la Platform Invocation Service. De même, la vérification de la validité des types ne fonctionne plus. Par conséquent, le programmeur doit être rigoureux dans sa programmation, sinon il y aura des erreurs de segmentation ou, (plus insidieusement...) des Fuites de mémoire.

Si le programmeur se montre peu rigoureux sur la conversion de type, un mauvais alignement de données peut provoquer de gros problèmes.

Exemples

[modifier | modifier le code ]

Le premier exemple montre comment obtenir la version d'une DLL particulière.

Le prototype de la fonction DllGetVersion dans l'API Windows :

HRESULT DllGetVersion
(
 DLLVERSIONINFO* pdvi
)

Code C# pour appeler la fonction DllGetVersion :

[DllImport("shell32.dll")]
static extern int DllGetVersion(ref DLLVERSIONINFO pdvi);

Le second exemple montre comment extraire une icône d'un fichier :

Le prototype de la fonction ExtractIcon :

HICON ExtractIcon
( 
 HINSTANCE hInst,
 LPCTSTR lpszExeFileName,
 UINT nIconIndex
);

Code C# pour appeler la fonction ExtractIcon :

[DllImport("shell32.dll")]
static extern IntPtr ExtractIcon(
 IntPtr hInst, 
 [MarshalAs(UnmanagedType.LPStr)] string lpszExeFileName, 
 uint nIconIndex);

L'exemple suivant plus complexe montre comment partager un évènement entre deux processus sur une plate-forme Windows

Le prototype de la fonction CreateEvent :

HANDLE CreateEvent(
 LPSECURITY_ATTRIBUTES lpEventAttributes,
 BOOL bManualReset,
 BOOL bInitialState,
 LPCTSTR lpName
);

Code C# pour créer l'objet évènement :

[DllImport("kernel32.dll", SetLastError=true)]
static extern IntPtr CreateEvent(
 IntPtr lpEventAttributes, 
 bool bManualReset,
 bool bInitialState, 
 [MarshalAs(UnmanagedType.LPStr)] string lpName);

Historique

[modifier | modifier le code ]

Le prédécesseur de Platform Invocation Service

[modifier | modifier le code ]

Microsoft avait réalisé sa propre Java Virtual Machine; l'interface entre le code Java et les DLL était réalisée par la bibliothèque J/Direct (voir (en) J/Direct). Cette bibliothèque n'est plus maintenue actuellement par Microsoft.