Salut,

puis-je demander pourquoi tu cherches à faire ça exactement ?

si c'est pour une facilité de transfert de fichiers ne serait il pas plus simple de passer par la case "création d'une archive auto extractible" avec un programme genre winrar, winzip / 7zip ?

Tu peux peut-être tenter ta chance avec le dll packager de rewolf, qui permet d'embarquer dans un exécutable les dll nécessaires à celui-ci. Les fonctions de chargement de dll et autres api système sont ensuite bricolées pour aller chercher les dll dans les ressources de l'exe.

Maintenant, je n'ai jamais testé dllpackager sur un exe pb, et sachant comment c'est structuré (avec le bytecode PB collé à la fin de l'exe après les ressources comme un overlay) j'ai des doutes sur le fait que l'exe fonctionne encore après (les fonctions de manipulation standard de ressources de windows "cassent" parfois les exe PB).

EDIT comme je le soupçonnait, un exe pb traité avec dllpackager est cassé (il perd la portion PB). Je suis en train de regarder si on peut "réparer" l'exe après coup.

Dernière modification par seki (19-10-2012 12:57:59)

Yanis a écrit:

tu ne pourras pas faire autrement que de déployer le runtime.

Pas forcément. J'ai plusieurs vieilles applis ici fabriquées avec d'anciens PB (6, 7, 9) et pour lesquelles je n'ai pas de runtime installé. Souvent il suffit de mettre pbvmxxx.dll à côté et ça fonctionne très bien.

Dans mon test, l'exe PB a besoin de
- pbvm115.dll
- pbshr115.dll
- libjcc.dll
- msvcr71.dll

Cette liste a été établie en examinant l'exe avec Dependency Walker, un outil que je recommande pour essayer de s'y retrouver dans le dll "hell". Ici j'ai utilisé la fonction de "profilage" qui permet de suivre ce que fait l'appli pendant son exécution et qui permet de voir les dll chargée plus tard pendant l'exécution. Je me suis limité aux dll non-système mais en incluant le runtime C (msvcr).

Le problème avec PB c'est qu'un exe PB contient son bytecode à la fin du fichier, après les sections connues de windows (les ressources sont dans une de ces section : .rsrc) dans un "espace supplémentaire" (overlay, qui a la même structure qu'un pbl ou pbd) et que les fonctions système permettant de manipuler cassent quasi systématiquement cette partie quand elle doivent mettre à jour une ressource. On peut étudier cela avec Stud_PE un autre excellent outil permettant de visualiser la structure d'un exécutable windows.

J'avais découvert ce problème en manipulant les ressources VersionInfo qui permettent d'afficher des information custom quand on regarde les propriétés d'un exe dans l'explorateur de fichiers. Et je me suis fait un tool permettant de sauver la partie PB, modifier les ressources, remettre la partie PB et la corriger  si il y a un décalage.

Seulement avec dllpackager, il y a des données "en trop" après les dll qui ont été embarquées dans une ressource. Je suppose un espace supplémentaire nécessaire au fonctionnement du chargement des dll embarquées. Et ça perturbe mon outil, ou alors ce n'est pas possible de modifier un exe PB dans ce sens.

erasorz a écrit:

Pas de DW dans ton appli ? (pas la peine de prendre PB alors...  /troll)

Nan , c'est le programme de test (proof of concept) de mon objet Mailslot (pas de DW pour ça). Je m'en suis servi pour débugger une communication entre PB et une appli java, ça marche très bien, très simplement et ça supporte même une communication entre 2 ou plus postes réseau (peut fonctionner en broadcast). Si vous voulez causer de manière asynchrone entre 2 process même avec des langages différents et / ou 2 machines dans un réseau windows, je recommande cette solution.

erasorz a écrit:

Et un compromis à 2 fichiers en utilisant le DLL packager : mettre uniquement toutes les DLL et laisser l'EXE pb à côté, ça doit pouvoir marcher (?)

Mettre toutes les dll où ? (il manque un mot ?)