Windows 10 et LoadResource()

Bonjour

J'ai un petit programme exe, développé sous BCB6, nécessitant l'utilisation d'une dll. Pour ne pas avoir à distribuer cette dll en plus de l'exe, je l'ai mise dans les ressources de l'exe. A l'execution, lors de la création de la fenêtre principale, j'extraie cette dll [avec FindResource(), LoadResource() et LockResource()], et je re-crée ce fichier dll [avec CreateFile()] dans le même répertoire que celui où se trouve l'exe. L'execution peut se poursuivre en utilisant cette dll qui vient d'être créée.
Cette méthode fonctionne parfaitement sous Vista, W7 et W8, mais elle ne fonctionne pas sous W10 : La dll n'est pas créée.

Quelqu'un voit-il une piste pour résoudre ce problème ?
Merci.

Quelle est la fonction qui échoue et quelle est la valeur retournée par GetLastError() à ce moment-là? :roll:

---

Sinon, en dézoomant un peu, il y a quelques problèmes avec ton approche: Notamment que ce la nécessite que celui qui exécute le programme ait les droits d'écriture sur le répertoire le contenant (donc, pas question de le mettre dans Program Files, etc.)
Pourquoi ne pas passer plutôt par un vrai installeur ou, au pire, pourquoi ne pas utiliser le répertoire temporaire (obtenu avec SHGetKnownFolderPath() si possible, ou le vieux SHGetSpecialFolderPath() si nécessaire) pour y stocker ta DLL (avec le flag FILE_FLAG_DELETE_ON_CLOSE si possible)?

Merci pour la réponse.

L'utilisateur de cet exe sait qu'il doit le placer dans un de ses répertoires (Users/login/...), donc il n'y a pas de problème de droits d'écriture manquants.
Le but est de fournir quelque chose d'ultra simple et immédiat à lancer pour l'utilisateur : Pas de programme d'installation, pas de dll à copier en plus de l'exe : Il copie cet exe dans un de ses répertoires, double-clique sur le nom de ce fichier, et c'est parti... sauf sous Windows 10 !!!

Il n'y a pas de fonction qui échoue : Je peux le vérifier en mettant au préalable manuellement cette dll dans le répertoire de l'exe : Aucune des fonctions FindResource(), LoadResource() et LockResource() ne renvoie un pointeur NULL.
Si je mets un message qui doit s'afficher tout au début du Form Create, ce message ne s'affiche pas si je ne mets pas manuellement cette dll dans le répertoire de l'exe.
Tout se passe en fait comme si Windows 10 vérifiait les dépendances de l'exe avant de commencer la moindre exécution, alors que sous les OS précédents, au moins le Form Create se faisait, ce qui permettait de créer cette dll nécessaire à la suite de l'exécution.

Citation:

---

Tout se passe en fait comme si Windows 10 vérifiait les dépendances de l'exe avant de commencer la moindre exécution

---

1. Quand cela se fait, il y a un message d'erreur tout-à-fait explicite avant le lancement du programme.
2. Je ne vois pas pourquoi Windows 10 cesserait subitement de supporter les delay-loaded DLLs (et encore plus impossible si c'est LoadLibrary() qui est utilisé)

Citation:

---

Aucune des fonctions FindResource(), LoadResource() et LockResource() ne renvoie un pointeur NULL.

---

Et CreateFile() (ou ce que tu utilises pour écrire la DLL)?

Bonjour,

Sinon, peut être en désactivant l'anti virus ?

Citation:

---

Envoyé par Médinoc

Quand cela se fait, il y a un message d'erreur tout-à-fait explicite avant le lancement du programme.

---

Il y a bien un message d'erreur sous W10 (voir ci-dessous).

Pièce jointe 195168

Ce message n'apparaît bien sur pas sous les autres OS < W10.

Citation:

---

Envoyé par Médinoc

Et CreateFile() (ou ce que tu utilises pour écrire la DLL)?

---

Quand il n'y a pas de dll pré-existante dans le répertoire de l'exe, CreateFile() n'est pas exécuté, car il se trouve dans FormCreate, qui ne se fait pas (on a le message d'erreur ci-dessus à la place).
Si je mets cette dll manuellement avant de lancer l'exe, FormCreate se fait bien, et CreateFile() retourne bien un pointeur non NULL.

Citation:

---

Envoyé par LittleWhite

Sinon, peut être en désactivant l'anti virus ?

---

J'ai essayé, mais malheureusement, toujours le même comportement sous W10.

Vérifie alors dans les options de compilation du projet, que ton programme est bien configuré pour charger la DLL en "delay-loaded DLL". Particulièrement si tu as des variations 32/64 bits, etc.

Bonjour

Je viens d'essayer le "chargement dll retardé" dans les options du projet.
Cela se compile correctement, mais j'ai ensuite l'erreur ci-après venant du linker :

"Symbol from delayed load module module is a data reference
Vous ne pouvez pas différer le chargement d'un module (DLL) à partir duquel vous importez également des données."

J'ai bien peur que je doive me faire à l'idée qu'il me faudra distribuer cette dll en plus de l'exe pour les utilisateurs de Windows 10.
On ne peut que constater une fois de plus que Microsoft ne sait pas (ou ne prend pas la peine de) faire un minimum de compatibilité ascendante avec ses O.S.

Peut-être une solution viendra-t-elle par le canal de Windows Update...
Merci en tous cas pour vos conseils.

Alors là, si la DLL n'était pas en Delay-Loaded avant, je ne comprends pas comment ça marchait.

Mais si j'ai bien compris l'erreur d'édition de liens, tu peux contourner le problème si tu peux modifier ton code pour qu'il n'utilise plus directement des variables globales exportées par la DLL (tu peux à la place mettre des fonctions qui retournent un pointeur sur lesdites variables).

Citation:

---

On ne peut que constater une fois de plus que Microsoft ne sait pas (ou ne prend pas la peine de) faire un minimum de compatibilité ascendante avec ses O.S.

---

Et coco, M$ a le dos large, votre tambouille est clairement hors utilisation des guidelines M$.
C'est pas parce que faire une bidouille sur des OS datant de l'âge de la pierre taillée fonctionnait sur des OS relativement récents, avec une configuration de sécurité totalement laxiste, que cela correspond à une spécification qui doit engendrer une compatibilité ascendante jusqu'à la fin des temps.

Faites comme tout le monde, un MSI ou un ClickOnce ou une installation administrative, etc... qui ne pose pas ce type de problème.

Et tu ne peux pas juste lier statiquement ta bibliothèque? Comme ca, pas de fichier du tout.

Parce qu'une dll que tu recopies depuis l'intérieur du binaire, ca n'a aucun intérêt: duplication pendant l'exécution, pas de variabilité, pas de réutilisabilité par les autres programmes.

Une solution toute simple,créer un répertoire,mettre l'exe et la dll dedans.
Distribuer le répertoire,c'est fini.
Sinon rechercher la fonction utilisée dans la dll et la remplacer par une autre connue de Windows ou de
Borland,puisque que la dll semble être de Borland.

sinon,si la dll n'est pas créer faute de droits(aucune erreur générée!!),il faut tester:

Code:

---

1 2 3 4 5 6 7 8 9 10

;on opère sur le handle du fichier invoke GetFileInformationByHandle,hfile,addr file_information ;vérifie les attributs lea edx,file_information mov eax,[edx].BY_HANDLE_FILE_INFORMATION.dwFileAttributes and eax,FILE_ATTRIBUTE_VIRTUAL .if eax != 0 ;droit isuffisant pour utiliser le fichier .endif

---