Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Bonjour,
Je cherche à générer un exécutable pour mon application, mais j'aurai souhaité n'obtenir qu'un seul et unique fichier, facile à lancer et transmettre
Malheureusement, et malgré l'impression d'avoir quand même pas mal avancé, je suis arrivé à une impasse.
J'ai tenté pas mal de choses différentes dont voici un résumé :
J'ai commencé par inclure tout les graphiques utilisés dans mon fichier .pbr
J'ai ensuite décoché les librairies dynamique pour ne générer qu'un fichier .exe unique.
Arrivé là, effectivement, PB ne me génère plus qu'une seul fichier, mais il est loin d'être autonome, il dépend toujours des librairies PowerBuilder standard. (libjcc, PBVM, etc , ...) que je suis toujours obligé de fournir avec mon exe.
J'avais alors pensé les inclure dans le target. Mais elles n'existent "a priori" qu'en DLL compilées, et sont donc refusées lorsque je tente de les importer.
J'ai tenté une autre approche, les ajouter à mon fichier .pbr
Là, le résultat, est interressant, car vu la taille de l'exe généré, il est clair que les DLL sont bien incluses dedans lors de la compilation.
Mais elles sont toujours inexploitables, car le programme me signale quand même qu'elles sont manquantes lorsque je l'exécute.
Pour les rendre visibles, je cherche à regénérer les fichiers physiques des DLL au moment de la première exécution du programme.
Je pensais que puisque PB à bien inclu ces DLL dans l'exe, au même titre que mes images, il devait être possible de les référencer, de remplir un blob avec, de créer un fichier libjcc.dll avec ce blob , et de l'enregistrer dans Windows dans system32. Et ainsi de suite pour chacune des dll nécessaires.
Mais encore une fois, ca bloque, je ne sais pas comment lire le fichier dll qui est inclu dans mon exe. Si je fait un fileOpen, il cherche à ouvrir un fichier physique qui n'existe pas.
Alors peut être que ce que je cherche à faire est impossible, en tous cas, si vous avez des idées auxquelles je n'aurai pas pensé, celà m'interesse au plus haut point
(Je suis sous PB12.5)
Merci d'avance
Hors ligne
Bonjour, AMHA tu ne pourras pas faire autrement que de déployer les dll nécessaires au runtime...
Hors ligne
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 ?
Hors ligne
Oui, et les DLL tu ne les transmettras qu'une fois. Ensuite en cas de mise à jour, l'exe généré suffira. (sauf si tu changes de version/build de PB bien sur)
Hors ligne
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)
Hors ligne
Salut,
Avec PB 12.5 il existe également l'utiliaire <Powerbuilder Runtime Packager> qui génére un fichier msi comprenant toutes les dll du runtime nécessaire à l'exécution d'une application Powerbuilder.
Je sais que celà ne fait pas ce que tu désirais mais comme te l'as dis erasorz tu ne pourras pas faire autrement que de déployer le runtime.
Hors ligne
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.
Hors ligne
seki a écrit:
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.
ouais mais en général (pour une appli standard version pb "récente") tu as au moins :
* les impondérables "non-pb" : alt71, libjcc, libjutils, mscvp71, msvcr71
* les classiques pb : pbvm***, pbshr***, pbws32***, pbdwe***
* les drivers pb SGDR: pbo*** (p.ex)
* les drivers SGBR : oci, oraoci (p.ex)
sans compter les dll pour d'éventuelles fonctionnalités complémentaires (webservice, xml...)
après si le dll packager marche, tu peux réduire le nb de fichiers, mais est-ce bien raisonnable en matière de performances de mettre tous ses œufs dans le même panier (?)
EDIT : j'avais pas vu ton edit
seki a écrit:
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.
Hors ligne
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.
Hors ligne
seki a écrit:
Dans mon test, l'exe PB a besoin de
- pbvm115.dll
- pbshr115.dll
- libjcc.dll
- msvcr71.dll
Pas de DW dans ton appli ? (pas la peine de prendre PB alors... /troll)
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 (?)
Hors ligne
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 ?)
Hors ligne
seki a écrit:
Mettre toutes les dll où ? (il manque un mot ?)
je voulais dire toutes les dll dans une seule dll, mais je vois qu'il faut forcément un exe en fait...
Hors ligne