Application Panoramic

Ce que je comprends de la fonction Application (.exe) de Panoramic_Editor:
A l'exécutable produit seront intégrés, en plus du source compilé, un certain nombre de fichiers choisis pour la compilation.
Je fais l'expérience suivante, avec le source suivante dans un répertoire vide:

Code:

' Test
MEMO 1
FILE_LOAD 1, "Liste.txt"
END

J'enregistre en Test.bas et je compile avec la fonction Exécutable,
résultat: Test.exe 1995827 octets (mazette !)
Je crée dans le même répertoire un fichier texte: Liste.txt qui contient 3 lignes de texte.
Je compile le même source avec la fonction Application, et j'ajoute dans la fenêtre qui apparaît le fichieer Liste.txt (il ne me l'a pas proposé ?) puis je valide (Cliquer pour continuer).
Résultat: Test.exe 1995827 octets, donc idem, donc pas de fichier Liste intégré...
Evidemment si je supprime le fichier texte, à l'exécution il me dit ne pas le trouver.

Je n'y comprends plus rien, quelque chose que je fais mal ?
Et je n'ai trouvé aucune documentation sur cette fonction Application...

Moi non plus, JL35. Je n'ai rien trouvé, et je n'arrive pas non plus à m'en servir. Je suis en train de réfléchir à une demande précise à faire à Jack, dans ce domaine.

Heureka !

J'ai trouvé comment on s'en sert.

Lorsque tu crées une "application" dans le sens Panoramic, l'éditeur te propose une fenêtre avec un mémo qui est préchargé avec les noms des fichiers TXT, BMP et JPG qu'il trouve dans le dossier. Tu peux en enlever si tu veux, mais tous ceux qui restent dans le mémo seront intégrés dans l'exécutable qui sera généré.


Mais tu peux y ajouter d'autres fichiers, manuellement ! J'y ai ajouté KGF.dll et un fichier de données quelconque, et il le prend ! Si tu as toute une collection de fichiers non standard à ajouter, tu peux placer la liste dans un fichier texte (attention: pas en TXT, mais en INC ou DAT, par exemple !), puis par un copier/coller, tu insères le contenu de ce fichier dans le mémo, pour éviter de tout retaper à chaque fois.

Lorsque la liste est complète, tu valides en cliquant sur la barre-bouton en bas ("Cliqer pour continuer"). Et l'exécutable sera généré avec tous ces fichiers.

Maintenant, copie le nouvel EXE (l'application) dans un autre dossier. Et tu peux te servir alors de ces fichiers comme s'ils étaient présents dans le dossier ! Exemple:

Code:

memo 1
file_load 1,"test.txt"
file_save 1,"test.txt"
end

Si test.txt a été inclus dans la génération de l'application, tu trouveras un fichier test.txt dans le nouveau dossier (celui dans lequel tu as copié l'application générée), et ce fichier est la copie exacte du test.txt d'origine. Idem pour les autres fichiers (BMP et JPG), en passant par un PICTURE ou un IMAGE.

Maintenant, je voulais inclure KGF.dll. J'ai renommé KGF.dll en KGF.dxx, et lors de la création de l'application, j'ai ajouté KGF.dxx dans le mémo de la fenêtre des fichiers à inclure. Puis validation, et l'exécutable est généré. Je recopie l'EXE dans un autre dossier et je l'exécute, et je retrouve mon fichier KGF.dxx dans le même dossier. Ne reste plus qu'à le renomer en DLL et de m'en servir. Et le code Panoramic pour ceci:

Code:

' test_application.bas
file_copy "KGF.dxx","newKGF.dxx"
end

Il ne reste plus qu'à renommer newKGF.dxx en KGF.dll, et le tour est joué. Et certainement, cela marchera également si je garde l'extension dll au lieu de renommer en dxx, ce qui économise une opération à l'aller et au retour.

Avec la dernière version de Panoramic (V0.9.26i5), on a les fonctions de gestion d'un fichier ZIP. Donc, ty peux également inclure un fichier ZIP, l'extraire de l'exécutable par FILE_COPY, puis en extraire ce que tu veux par les commandes de Panoramic.

Voilà. Finalement, c'est simple et puissant !

Merci Klaus, tu me rassures, je commençais à me sentir devenir chèvre !
Jusqu'ici je n'avais fait que des exécutables tout simples (et tout de même très volumineux, vu la méthode employée), mais c'est vrai que le principe de l'Application est séduisant, d'intégrer toutes les ressources dans l'exécutable.
Même si je me demande bien comment ça peut être mis en oeuvre en interne, l'intégration, oui, mais l'utilisation ensuite ?

Eh bien, je passerai mon dimanche à penser à autre chose, d'autant plus que j'ai de la visite !

Bon dimanche à toi Klaus !

PS on s'est croisés et j'aperçois ton message, bon, je prends le temps de le lire mais je n'irai sans doute pas plus loin aujourdhui.

C'est bien toi le meilleur Klaus

Finalement ça veut donc dire qu'au moment de l'exécution il recrée les fichiers inclus dans le répertoire d'exécution, et il ne le fait qu'à la 1ère exécution... non, c'est pas ça, on peut les adresser, les renommer, les recopier, mais ils restent dans l'exécutable, c'est ce que j'ai compris.
Ce qui me troublait c'est qu'il ne me proposait pas le fichier .txt qui était pourtant dans le répertoire du source, je l'ajoutais à la main, mais sans résultat...

Bon, je regarderai ça plus en détail plus tard... et encore merci à toi.

Fausse joie ! Finalement, ça ne marche pas, et mon "succès" était dû à une erreur de manipulation ! Le fichier EXE généré ne contient pas la DLL que je voulais inclure.

Je continue mes recherches...

EDIT

Finalement, aucun fichier autre que TXT, BMP et JPG n'est intégré. Lors de la génération de l'application, les autres types de fichiers ne sont pas rejetés avec un message d'erreur, mais ils sont simplement ignorés. Et, évidemment, la taille de l'exécutable résultant n'augmente pas. Et à l'exécution, lorsqu'on essaie de copier un de ces fichiers non-standard (et qui n'ont pas été intégrés dans l'exécutable), Panoramic génère une erreur "Fichier existe déjà", au lieu d'un "Fichier inexistant" ou similaire. Très frustrant.

J'ai essayé de renommer KGF.dll en TXT, BMP ou JPG, mais ça ne marche pas non plus. Le fichier est vérifié, et Panoramic détecte que la structure n'est pas conforme à l'extension, et le rejette avec un message d'erreur !

Je vais poser la question à Jack !

@Jack:
Lors de la génération d'un exécutable sous forme d'application, on peut inclure tous les TXT, BMP et JPG qui se trouvent dans le même dossier que le source. Et dans l'exécutable généré, on peut ouvrir ces fichiers comme s'ils étaient dans le dossier actuel. Très bien.

Mais il n'y a aucun moyen d'inclure un autre type de fichier, sous forme de fichier de données binaires. Et on ne peut pas non plus renommer un tel fichier en TXT, BMP ou JPG, parce que le format est alors rejeté non conforme. Et si l'on spécifie un fichier CNF, DAT ou DLL, par exemple, il n'y a pas de message d'erreur lors de la génération, mais il est tout simplement ignoré et ne se retrouve pas dans l'exécutable. Et si l'on essaie de s'en servir à l'exécution, il y a un message d'erreur "Fichier existe déjà", alors que ça devrait être "Fichier inexistant".

J'hésite à placer ce message dans la rubrique des "bugs", mais je pense qu'il serait très utile d'ouvrir le mécanisme d'inclusion de fichiers externes à tous les fichiers qui seraient alors inclus comme ressource DATAFILE, comme je le fais à la génération de KGF.dll:

Code:

TOOLBAR_ICONS DATAFILE KGF.ilb
KGFUPDATE DATAFILE KGFupdate.txt

ou alors simplement copiés à la fin de l'exécutable (comme le source BAS)...

Ce qui est certain, c'est que cela permettrait une mise en place beaucoup plus facile des programmes. D'ailleurs, maintenant que Panoramic sait gérer les fichiers ZIP, on pourrait envisager d'ajouter ZIP à la liste des extensions autorisés si des raisons techniques t'empêchent d'ouvrir le mécanisme à tout type de fichier. On pourrait alors mettre tout ce qu'il faut, dans un ZIP, inclure ce fichier, et à l'exécution, faire l'extraction de ce ZIP.

Qu'est-ce que tu en penses ?

PS: Je me permets de rajouter mon grain de sel. Ce serait bien de pouvoir ajouter es répertoires de ressources.
on pourrait simplement préciser GFX (par exemple, il n'y a pas de raison d'avoir des noms identiques) qui correspondrait au répertoire contenant les images ou une partie des images à inclure, SND (c'est toujours un exemple) qui contiendrait les Wav et MP3, ou un répertoire RSC qui contiendrait les ressources (comme les DLL ou autre) ou un répertoire DATA, BDD selon les applications. Après encore faudrait-il savoir comment les utiliser...

La chose se complique.

Lorsqu'un ajoute un fichier texte dans une application, disons test.txt, le compilateur génère une "ressource" de type RCDATA, dont le nom est TEST.TXT (le nom du fichier sdans le chemin), et les données sont copiées juste derrière.

Je peux produire la même structure avec ResHacker interactif, mais je n'ai pas encore trouvé la bonne syntaxe pour faire cela en mode commande.

Je peux produire la même chose avec mes fonctions KGF.dll existantes. Bien. Je me suis donc fait un petit outil permettant d'injectier KGF.dll (et d'autres ressourcs) dans un fichier EXE de l'application. Ca marche.

MAIS, et il y a un MAIS:
aussi bien pour le fichier texte que pour KGF.dll, je n'ai pas trouvé le moyen d'extraire ces fchers et de les placer là où je veux. Panoramic génère une erreur si j'essaie de me servir d'un des fhciiers (Le fichier existe déjà). Le libellé de l'erreur est aberrant, et les fichiers sont bien disponibles. De plus, pour extraire KGF.dll, c'est inapplicable, car il faudrait disposer de KGF.dll pour ... etc.

Donc, une question à tous:
Quelle esl la bonne ligne de commande pour ResHacker pour ajouter une ressource ? Actuellement, je fais:

Code:

"<...chemin...>ResHacker.exe" -add application.exe, new_application.exe , KGF.dll , 1, 0

Une question à Jack:
Comment utilise-t-on une ressource tel qu'un fichier texte ?

J'aimerais bien comprendre comment ça marche !

Concernant ResHacker, j'ai trouvé une espèce de tuto ici:
http://www.autoitscript.com/forum/topic/47720-reshack-command-line-option/
avec notamment:
Examples: (File paths have been omitted for clarity)
--------
To add or update dialog name:maindlg lang:0 in MyProg.exe from UpdDlg.res
ResHacker.exe -addoverwrite MyProg.exe, MyProgNew.exe, UpdDlg.res, dialog,maindlg,0

To add or update bitmap name:128 in MyProg.exe from NewImage.bmp
ResHacker.exe -addoverwrite MyProg.exe, MyProgNew.exe, NewImage.bmp , bitmap,128,

To add or update all bitmaps in MyProg.exe from Images.res
ResHacker.exe -addoverwrite MyProg.exe, MyProgNew.exe, Images.res, bitmap,,

To add a ?user-defined? binary resource (README,1,0) to MyProg.exe from ReadMe.html
ResHacker.exe -addoverwrite MyProg.exe, MyProgNew.exe, ReadMe.html, readme,1,0

To add all items in Images.res to MyProg.exe (but fail if any item already exists)
ResHacker.exe -add MyProg.exe, MyProgNew.exe, Images.res ,,,

To add all items in Images.res to MyProg.exe (skipping any existing items)
ResHacker.exe -addskip MyProg.exe, MyProgNew.exe, Images.res ,,,

To modify all items in MyProg.exe with the items in Images.res (ignoring any items in Images.res which do not exist in MyProg.exe)
ResHacker.exe -modify MyProg.exe, MyProgNew.exe, Images.res , , ,

To extract all icons from MyProg.exe to MyProgIcons.rc (creating MyProgIcons.rc, Icon_1.ico, Icon_2.ico , Icon_3.ico etc...)
ResHacker.exe -extract MyProg.exe, MyProgIcons.rc, icongroup,,

To delete GIF name:128 from MyProg.exe
ResHacker.exe -delete MyProg.exe, MyProgNew.exe, gif,128,

mais c'est assez pointu... pour moi.

Merci, JL35. J'avais vu également ce bref résumé. C'est pourquoi j'ai construit ma ligne de commande comme indiquée dans mon post ci-dessus. Pourtant, elle se termine dans message, et sans modification dans le fichier ciblé. Je dois rater quelque chose...

Moi je viens de faire:

Code:

ResHacker.exe -addoverwrite Test.exe, Nouveau.exe, KGF.dll, dll,1,0

et mon exécutable Test.exe est passé de 1 995 830 octets à Nouveau.exe 5 354 550 octets (avec un KGF.dll de 3 358 720 octets) ce qui fait exactement le compte à l'octet près.
Quant à l'utilisation... c'est une autre paire de manches.

Bonne nuit Klaus, en attendant !  

PS les deux exécutables s'exécutent normalement l'un comme l'autre, mais très simplistes, ne faisant pas appel à KGF.dll.

Code:

' Test
MEMO 1
ITEM_ADD 1,"Programme test"
END

c'est pour dire...

Merci beaucoup, Jean-Claude ! Cela m'a mis sur la voie. Voici mon fichier BAT que j'utiliserai:

Code:

rem appeler par:
rem    KGF_add_ressource programme.exe KGF.dll KGF_dll
if exist %1_new del new_%1
ResHacker.exe -addoverwrite %1 , new_%1 , %2 , DATAFILE, %3 , 0
if not exist new_%1 goto fini
if exist %1 del %1
ren new_%1 %1
:fini

On trouvera une ressource de type DATAFILE de nom KGF_DLL et qui contient KGF.dll !

Klaus a écrit:

Merci beaucoup, Jean-Claude !

Remercier Jean Claude, c’est bien et il le mérite bien ; mais pour rendre à César son dû, tu veux bien adresser aussi un merci à JL35 : c’est lui qui t’a mis sur la voie.

Je sors !

Oups... désolé, JL35 ! C'est vrai, j'aurais dû être plus attentif. Je vous ai confondus, et je m'en excuse. A l'avenir, je promets d'être plus rigoureux !

Et Merci à Papydall pour le rappel à l'ordre, nécessaire !

Bon allez, merci à tous les deux, à toi papydall pour ta vigilance sans faille et à toi Klaus pour l'exploitation du résultat !

Finalement, il y a quelque chose qui me dérange, avec ResHacker. Je ne peux pas imposer un nom de ressource du type "KGF.dll". Le point est rejeté. Or, quand on crée une application avec un fichier TXT, la ressource porte bien le nom du fichier, y compris son extension avec le point.

J'ai donc fait une nouvelle version de KGF.dll avec une fonction qui fait ça, et un programme Panoramic pour résoudre mon problème:

Code:

' InsertResourceToExe.bas

label SelExe, SelRsc, insert

dim exe$, res$, res%, typ$, nam$

open_dialog 1

alpha  10 : top 10,10 : left 10,10  : caption 10,"Fichier EXE:"
edit  11 : top 11,10 : left 11,80  : width 11,300
button 12 : top 12,10 : left 12,380 : width 12,30 : caption 12,"..."
  on_click 12,SelExe

alpha  20 : top 20,40 : left 20,10  : caption 20,"Ressource:"
edit  21 : top 21,40 : left 21,80  : width 21,300
button 22 : top 22,40 : left 22,380 : width 22,30 : caption 22,"..."
  on_click 22,SelRsc

button 32 : top 32,80 : left 32,80  : caption 32,"Insérer"
  on_click 32,insert

dll_on "KGF.dll"

end

SelExe:
  filter 1,"Exécutables, DLLs|*.exe;*.dll"
  exe$ = file_name$(1)
  if exe$="_" then return
  text 11,exe$
  return
 
SelRsc:
  filter 1,"Ressource|*.*"
  res$ = file_name$(1)
  if res$="_" then return
  text 21,res$
  return

insert:
  exe$ = trim$(text$(11))
  if file_exists(exe$)=0
    message "Le fichier exécutable n'existe pas"
    return
  end_if
  res$ = trim$(text$(21))
  if file_exists(res$)=0
    message "Le fichier ressource n'existe pas"
    return
  end_if
  typ$ = "DATAFILE"
  nam$ = file_extract_name$(res$)
 
  res% = dll_call3("FindExistingResource",adr(exe$),adr(typ$),adr(nam$))
  if res%<>0
    if message_confirmation_yes_no("La ressource "+nam$+" existe déjà. Remplacer ?")<>1 then return
    res% = dll_call3("DeleteExistingResource",adr(exe$),adr(typ$),adr(nam$))
  end_if
 
  res% = dll_call4("AddNewResourceEX",adr(exe$),adr(res$),adr(typ$),adr(nam$))
  if res%<0
    message "Oups... erreur en mise à jour"
  else
    message "Le programme a été mis à jour"
  end_if
  return

Ensuite, on vérifie avec ResHacker, et on voit qu'une nouvelle ressource a été ajoutée: elle a le tyoe DATAFILE et le nom du fichier ajouté, y compris son extension. Bien sûr, le nom de la catégorie est libre et codée dans le source de ce programme. On peut mettre n'importe quoi. En mettant RCDATA, on tombe dans la même catégorie que les fichiers TXT, par exemple.

et après, tu vas faire une fonction pour que l'on puisse utiliser le fichier "joint" comme si c'était un fichier lu depuis le disque ?

Une idée tout bête sans doute mais je ne sais pas si c'est hors sujet: serait-ce compliquer d'avoir un lecteur en mémoire (RAMDRIVE) pour charger ces fichiers joints au fichier Exe et pouvoir travailler dessus en lecture ? Si ce n'était pas aberrant, ça permettrait aussi quand on créé des fichiers temporaires d'utiliser le lecteur même lecteur mémoire et de ne pas mettre à contribution le disque ni laisser de traces de l'activité.

Encore une fois, je ne sais pas non plus me servir de ces éléments accolés au fichier Exe et je suis peut être carrément à côté de la plaque ou il y a peut être des solutions beaucoups plus simples.

Ca existe déjà. Voici un extrait de la doc de KGF.dll:


Par ces fonctions, tu ajouter n'importe quoi à un fichier EXE généré par Panoramic, même un fichier ZIP. Et tu peux ensuite, par programme, l'extraire et le placer où tu veux. Tu peux ainsi réaliser des installations auto-extractibles ou auto_installables: au démarrage d'un programme, tu testes la présence d'un dossier ou d'un fichier significations, et s'il n'existe pas, tu l'extraies parmi les ressources.

Tout ça, ça marche depuis un moment. Ce que je voulais faire, c'est de pouvoir extraire KGF.dll. Et si KGF.dll n'est pas encore présente... d'où ma demande à Jack de faire une commande Panoramic d'extraction d'une ressource dans un fichier.

Le RAM-drive, c'est un problème indépendant des ressources. Un RAM-drive est toujours réalisé sous forme d'un driver système, tout comme un driver USB ou un driver d'imprimante. Donc, forcément une modification importante du système nécessitant les droits d'administrateur. Et en général un reboot au moment de l'installation. L'avantage est avant tout une très grande vitesse d'exécution, mais au prix d'une réduction de la mémoire centrale disponible. C'est très utile pour des fichiers de petite ou moyenne taille, mais accédés fréquemment et intensément. C'est très pénalisant pour des fichiers de grande taille. Par contre, cela a un intérêt pour sécuriser une application délicate - on copie tous les fichiers dans un RAM-drive, on lance l'application dans ce drive, et si tout se passe bien, on recopie le RAM-drive, sinon il suffit de l'effacer. Mais cela est possible également avec un répertoire de travail tout à fait banal.

Jicehel a écrit:

serait-ce compliquer d'avoir un lecteur en mémoire (RAMDRIVE) pour charger ces fichiers joints au fichier Exe et pouvoir travailler dessus en lecture ?

Non, il n’est pas aussi compliqué que ça d’avoir en mémoire un disque virtuel.
Si vous voulez simuler un disque dur pour bénéficier des temps d'accès de la RAM et  ne pas avoir à supprimer des fichiers temporaires, rendez-vous sur ce site, on vous explique tout.

Sinon,  jetez un oeil ici ou là

Merci, Papydall. Information complète et instructive.

@ Papydall, merci pour l'information, mais en l'occurence, avec l'explication de Klaus, j'ai la confirmation que c'est un peu hors sujet par rapport à la demande de Klaus.
Les ressources sont pratique pour des données que l'on ne modifie pas. Sinon, ça oblige a réenregistrer régulièrement le .exe avec tous les riques que cela comprend.
On peut mettre tous les fichiers d'origine dans le fichier exe et si l'on doit travailler dessus, mieux vaut l'extraire là où se trouve l'exe et faire un test dans le programme pour voir s'il existe. Si on n'a pas besoin de le garder, on peut toujours le supprimer en quittant le programme.
En fait c'est une petite gymnastique supplémentaire qu'il faut faire et qui un un peu inverse de l'esprit du forum dans lequel on partage tout, les sources et les ressources alors que là, on compile le fichier source et on agglutine tout dedans comme dans le fichier zip que l'on se transmet d'habitude.
Avec le système de drivers pour monter un RAMDRIVE, cele ne répond pas au besoin car chacun peut en faire ce qu'il veut, mais ce n'est pas gérable par le programmeur puisqu'indépendant du programme. La seule chose qui est faisable c'est de faire un fichier de paramètrage dans lequel l'utilisateur peut définir ces répertoires de travail (en choisissant si besoin un lecteur virtuel s'il en a créé un).