dlls + exe => exe (unique)

[Memnon]

Bonsoir a tous!
j'ai une question
Est il possible de rassembler en un bloc une application ??
je m'explique pour firefox par exemple, il y a firefox.exe + les dll + pleins d'autres trucs et je voudrais savoir s'il est possible de "compresser le tout" dans une unique application ou executable (je ne parle pas de .zip ou .rar ni d'autoexecutable) mais de rassembler le tout en un unique executable qui lancerait le programme normalement.
Je vous remercie
-----

[Papy Octet]

Bonjour Memnom,
Ta question est pour le moins saugrenue. En effet, lorsque les auteurs de logiciels écrivent leurs programmes, c'est avec l'idée de pouvoir continuer à le développer le plus facilement possible.
Pour ce faire, ils morcèlent leurs paquets de lignes de code (des centaines de milliers !) en plusieurs blocs qui auront des extentions particulières qui aideront à reconnaître les types de "paquets".
Chaque "paquet" sera un ensemble d'outils spécifiques à une action ou un groupe d'actions. La mise à niveau d'un tel groupe d'action sera aisée puisqu'il y a relativement peu de lignes de code à modifier.
Si un programme était écrit en un seul "paquet", je te laisse imaginer les problèmes pour retrouver une partie du code et la modifier.

Cette manière de programmer permet également de créer des programmes qui peuvent tournenr sur différentes configurations matérielles simplement en allant chercher le/les "paquets" indispensables et en omettant d'installer les autres. c'est autant de pace gagnée sur le disque dur de l'utilisateur.

Pour répondre à ta question : sauf si tu as le code source, c'est-à-dire le listing complet qu'a écrit le créateur du programme, il t'est impossible de recréer un programme contenant tous les fichiers annexes nécessaires à son bon fonctionnement.

Si un langage comme le C, mais bien d'autres également, ont développé des méthodes de codages dites "orientée objet", c'est justement pour faciliter le travail de codage mais aussi celui de la maintenance et de la mise à niveau des logiciels. Il est plus aisé de s'y retrouver dans dix "petits" programmes que dans un seul énorme.

A+

[invite54165721]

Bonjour,

J'imagine que la question avait un but pratique par exemple pour une sauvegarde de programme. Comment s'assurer qu'on a pas oublié une dll dans un coin perdu!

[Papy Octet]

Bonne question, je vous remercie de l'avoir posée.

Mais aussi comment savoir quels sont les fichiers inscrits sur le disque dur lors de l'installation d'un programme et comment savoir quelles dll ont été modifiées ?

Là, c'est la boite à malices !

[A voir en vidéo sur Futura]

[Memnon]

Bonjour a tous!
Merci pour tes explications Papy Octet.
Wii c'est d'ordre pratique, c'est pour avoir tout dans un seul endroit. Donc, si j'ai bien compris, il est impossible de tout rassembler sauf si j'ai les codes sources...j'avais penser à une double compilation... la premiere faite par les programmeurs, avec des fichiers morcelés puis une autre au dessus pour rassembler tout ça.

[Towl]

Pour répondre à ta question : sauf si tu as le code source, c'est-à-dire le listing complet qu'a écrit le créateur du programme, il t'est impossible de recréer un programme contenant tous les fichiers annexes nécessaires à son bon fonctionnement.

Si c'est possible, et heureusement. Sinon comment ferait le système d'exploitation pour tout charger en mémoire et mapper les bonnes adresses des DLL ?

Après ce n'est clairement pas une opération triviale. La maniere de le faire que je vois (sans réfléchir à la propreté) :
- parcourir la table d'import de l'executable pour rechercher les DLLS.
- faire un bete copier / coller des dll dans des nouvelles sections de l'executable (1 section = 1DLL)
- développer un code qui hook le chargement de DLL, et qui au lieu de demander à windows de charger la DLL XXX s'occupe de la récupérer dans la bonne section, la mappe en mémoire et la patch à chaud pour corriger les adresses.

Ca pourrait être un petit projet bien fun, je vais garder ca dans un coin de ma tête

Sinon l'un des gros interet des DLL, c'est de ne pas avoir le meme code chargé 36000x en mémoire : chaque DLL est chargée une seule fois en mémoire. Si un composant veut par exemple afficher une page html en utilisant le moteur de rendu de IE, il ne va pas charger IE.dll (ou quelque soit son nom) si celui-ci est déjà en mémoire (ce qui est souvent le cas )

[Memnon]

et c'est quoi le code?? Il est en quoi??java, C, C++...?

[Towl]

Euh, je comprend pas ta question la.
Le code de quoi ?

[Memnon]

développer un code qui hook le chargement de DLL, et qui au lieu de demander à windows de charger la DLL XXX s'occupe de la récupérer dans la bonne section, la mappe en mémoire et la patch à chaud pour corriger les adresses.

ce code la

[Towl]

java, C, C++...?

Aucun de ceux la en assembleur, avec possibilité d'écrire quelques bout de code en C

[Memnon]

ah...
en effet la je ne sais vraiment pas faire...
On fait comment??

[Towl]

Hum... honnêtement ? pas facile.

Faut avoir de bonnes connaissances du C coté programmation systeme, bien connaitre le fonctionnement de l'OS (chargement de dlls, format de l'executable), avoir une de bonnes notions de l'assembleur x86...

Et puis faut beaucoup lire les articles liés à ce sujets, lire les codes correspondant (ne pas avoir peur de lire les blogs chinois, on comprends rien à ce qu'ils disent, mais leur code est tres propre et compréhensible)..

Bref, ca se fait pas comme ca du jour au lendemain

[Memnon]

Hum... honnêtement ? pas facile.

Faut avoir de bonnes connaissances du C coté programmation systeme, bien connaitre le fonctionnement de l'OS (chargement de dlls, format de l'executable), avoir une de bonnes notions de l'assembleur x86...

Et puis faut beaucoup lire les articles liés à ce sujets, lire les codes correspondant (ne pas avoir peur de lire les blogs chinois, on comprends rien à ce qu'ils disent, mais leur code est tres propre et compréhensible)..

Bref, ca se fait pas comme ca du jour au lendemain

J'ai quelques connaissances en C mais le reste... bon je pense que c'est hors de portée pour moi pour le moment

Merci de m'avoir répondu

[invite54165721]

Bonsoir,

Par curiosité, quand on lance un exe comment trouve t il l'emplacement des dll sur le disque (on a pu défragmenter donc changé les emplacements) ? est ce qu'll recherche d'après les noms de dll existant sur le disque?

[Towl]

Un petit exemple / analyse valant mieux qu'un long discours

En partant du principe que tu as un executable standard (comprendre sans aucune protection ni autre), celui-ci dispose d'une section .rdata contenant une table d'import et une table d'export.
Dans la table d'import, tu as la liste des fonctions externe dont il va avoir besoin, ainsi que le nom de la DLL.
Par ex (voir img), on voit que Putty.exe va importer
- RegCloseKey
- RegCreateKeyA
- RegSetValueExA
- RegOpenKeyA
- RegQueryValueExA
- RegDeleteKeyA
- RegEnumKeyA
Ces fonctions sont incluses dans ADVAPI32.dll

Et la, tu t'aperçois d'une limitation du systeme : la dll est référencée par son nom, pas de n° de version ou autre (d'ou certains problèmes de DLL trop récente / vieille qui pourrissent un systeme en remplacant celles d'origine).

ensuite, la recherche des DLL s'effecture d'abord dans le repertoire de l'executable, ensuite dans %systemroot%\system32, et enfin dans %path% (pas tout a fait sur de l'ordre / inclusion des deux derniers). Donc aucun soucis la dessus en cas de défragmentation

[Memnon]

oula! Ca a l'air compliqué tout ca

[Memnon]

Bonjour a tous!
Il n'existe pas un logiciel qui est capable de faire ca??

[Towl]

Pas a ma connaissance. Et ca serait dangereux de toute facon. La dll kernel32.dll (dont quasiment toute appli dépend) est différente sur un Windows XP SP3, SP2, francais, anglais... donc tu ne pourrais utiliser ton programme que sur un PC avec exactement la même conf. Donc pas d'interet

[Memnon]

ok!
donc ca voudrait dire qu'on pourrait faire ca uniquement en utilisant un logiciel de virtualisation comme thinstall (logiciel a 4500€ )

Mais pourtant si on rassemble tout en un seul .exe, qu'on utilise la dll kernel32.dll d'un ordi ou d'un autre, je ne vois pas ce qui change parce que le programme est capable de s'adapter non? Je ne vois pas vraiment ce que tu veux dire...

[Towl]

Pour le programme, en théorie, cela ne change rien. Par contre, windows peut faire appel à des fonctions très spécifique de cette DLL.
Par exemple, Vista à introduit l'UAC (la jolie popup pour augmenter ses privilege). Il y a fort à parier qu'une nouvelle fonction est apparue dans kernel32.dll (ou user32.dll)

Or si le logiciel est fournit en tout en un avec les dll de XP, Lors de l'install du logiciel sur Vista, peut etre que celui ci va charger la dll de XP en plus de celle de vista en mémoire. Et peut etre que l'appel à la dll user32.dll futur va etre redirigé sur celle d'XP, ou pas.
Enfin la logique voudrait que seul ton programme utilise ta dll. Mais peut etre qu'un antivirus, qui ne fait pas confiance au systeme pour certaines fonction, va tomber sur ta version de la dll, la trouver saine et se mettre à l'utiliser comme s'il s'agissait de Vista et non d'XP..
Le truc bien avec les dlls de meme nom, c'est que c'est une bonne source d'aléa

[Memnon]

D'apres ce que j'ai compris, cela sous entend que j'ai mis les dll kernell32.dll ou user.dll dans mon "package"...
mais si je ne mets que des dll propre au *.exe, dans ce cas la, mon logiciel *.exe va chercher ses dll a leur place dans le "package" mais aussi utiliser les dll propre a windows comme par exemple kernell32.dll
Je pense que tu n'avais pas compris ça comme ça...

[Towl]

Comment faire pour savoir s'il s'agit d'une dll propre à Windows ? Est ce que les dll d'Internet Explorer en font parties ? Est ce que les dll de Windows Media en font parties ? Après c'est vrai qu'on les connait, mais ca veut dire que avant de packager ton programme, tu dois te farcir la liste à la "mimine" et exclure celles ci. Bonjour la portabilité
Et apres comment savoir que la dll que tu prends n'est pas aussi utilisée par un autre programme et risque d'amener des conflits ? Puisque si tu fais ton packaging, c'est que tu ne connais pas les ressources nécessaire à ce programme.

Bref, oui c'est possible de créer un tel logiciel, mais l'utilisation peut dans certains cas aux limites s'avérer catastrophique pour le système.
Sans parler de la consommation de mémoire que cela entraine : si n programmes packagés utilisent la dll X, alors X sera chargé n fois en mémoire, au lieu de 1 seule fois.