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+

[alovesupreme]

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 !

[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]

Envoyé par Towl

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]

Envoyé par 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

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

[alovesupreme]

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