Éviter le masquage des informations

Parfois, les programmes masquent délibérément ou par inadvertance des informations du moteur de marshaling RPC. Voici quelques exemples :

• Envoi d’une structure de données sous la forme d’un bloc d’octets non différents
• Tirer parti des performances en utilisant un effet secondaire d’une méthode pour canaliser des données supplémentaires sur le réseau
• Tentative de déguisement d’un handle en le passant en tant que DWORD ou ULONG

Ces techniques sont presque garanties pour introduire des problèmes de compatibilité avant même que vous portiez votre application vers Windows 64 bits.

Au lieu d’envoyer un contexte serveur en tant que DWORD dans un appel de procédure distante standard, utilisez un handle de contexte pour fournir un handle opaque à un contexte serveur qui est détenu pour le compte d’un client. Les contextes sont identifiés par des GUID définis par l’exécution rpc lorsqu’un serveur crée un handle de contexte pour un client. Aucun pointeur n’est utilisé sur le fil et l’opération est entièrement transparente sur les limites 32 ou 64 bits. Pour plus d’informations sur l’utilisation de handles de contexte, consultez Handles de contexte.

Les interfaces DCOM ne peuvent pas utiliser de handles de contexte, car COM fournit sa propre gestion de contexte. Au lieu de créer un handle de contexte, vous pouvez passer un pointeur d’interface à l’objet COM. Vous pouvez ensuite appeler les méthodes directement via le pointeur d’interface ou placer le pointeur à l’intérieur d’autres appels. Pour libérer l’objet serveur, le client appelle la méthode Release de l’interface via le pointeur d’interface.

Là encore, il peut arriver que vous ne pouvez pas modifier la conception d’origine du code que vous portez. S’il n’existe aucun moyen d’éviter d’envoyer un pointeur sur le réseau en tant que DWORD, vous devrez implémenter une forme de mappage côté serveur entre les valeurs DWORD et les pointeurs. Pour ce faire, vous pouvez remplacer les pointeurs dans l’application côté client par des types de précision de pointeur, tels que ULONG_PTR ou DWORD_PTR. Utilisez ensuite l’attribut MIDL [call_as] pour placer les pointeurs sur le câble en tant que valeurs DWORD . Le wrapper côté client doit uniquement passer les arguments. Le wrapper côté serveur gère le mappage entre les deux types. De la même façon, vous pouvez utiliser l’attribut [transmit_as] ou l’attribut [represent_as] pour convertir vos données dans un format à compatibilité descendante pour la représentation par câble.

Si la compatibilité descendante n’est pas un problème ou si le handle n’est pas utilisé pour les appels distants et que vous êtes sûr que les appels distants entre les processus 32 et 64 bits ne se produisent jamais, vous pouvez redéfinir un argument en tant que ULONG64. Si nécessaire, vous pouvez modifier l’application 32 bits pour passer un DWORD à l’utilisateur. Vous pouvez également créer des stubs distincts à partir de fichiers IDL distincts pour chaque plateforme à l’aide d’un DWORD sur Windows 32 bits et d’un ULONG64 sur windows 64 bits.