Thunk functions : appel de CreateFile dans une appli 16 bits

Bonjour !

Dans une appli 16 bits (écrite en BPW, pour ceux qui connaissent), j'essaye d'exécuter la fonction CreateFile du kernel32 à l'aide des thunk functions du kernel16 (LoadLibraryEx32W, FreeLibrary32W, GetProcAddress32W, GetVDMPointer32W et CallProc32W).

Sur une machine Win NT 4.0 ou Win 2000 Pro, j'aboutis à une access violation dans NTDLL.DLL.
J'ai vérifié tous mes paramètres, converti les adresses 16:16 en adresses linéaires... rien à faire.

C'est la première fois que j'ai un problème avec les thunk functions.

Quelqu'un a-t-il déjà été confronté au problème ?

J'ai trouvé !!! :idea:

Sans que je puisse donner la moindre explication à la chose, tout fonctionne si je traduis l'adresse 16:16 du nom de fichier en adresse linéaire directement dans mon programme 16 bits (à l'aide de la fonction GetVDMPointer32W du kernel 16 bits) au lieu de la laisser traduire par la fonction CallProc32W.

Si quelqu'un peut m'expliquer pourquoi, je suis bien entendu preneur !

J'aurai séché là-dessus près d'un mois 1/2... :fou:

Maintenant que tu as trouvé ça semble logique.
De même que depuis le 16 bits il faut convertir le pointeur de fonction pour pouvoir l'appeler, cette fonction (exécutée en 32 bits) se voit passer un pointeur 16 bits...boum. Donc il faut aussi convertir l'adresse des paramètres passés, au même titre que l'on traduit l'adresse des fonctions appelées. Enfin, je pense.
Félicitations.

Merci !

En fait, la fonction CallProc32W fait elle aussi partie du kernel 16 bits.

J'ai pourtant déjà appelé pas mal de fonctions 32 bits en laissant CallProc32W convertir l'adresse 16:16 (FindFirstFile, GetCurrentDirectory, GetOpenFileName et encore bien d'autres) sans avoir jamais eu de problème, d'où ma perplexité.
Je n'utilisais GetVDMPointer32W que pour des adresses à l'intérieur de structures passées comme paramètres à CallProc32W.

Enfin, ça reste du "bricolage". Le "thunking" comporte hélas des zones d'ombres et de flou : j'ai plusieurs sources documentaires qui se contredisent parfois sur le même sujet. Et MSDN n'est pas toujours exempt d'erreur...