Démineur en Mode Graphique - Quoi choisir ? - Page 2

heu c pas la DLL std quand mm
ou alors bonne taille d'exe

Pollux: tutafe ! sinon, ils auraient besoin des DLL cyg-X.... de cygwin/X

tiens d'ailleurs c'est possible de linker plusieurs binaires ensemble de manière relativement fiable ? (dll+dll -> dll, ou dll+exe -> exe)

Ben tu peux mettre une dll en ressource oui, mais il faut que ton app soit au courant qu'lle est en ressource, sinon je crois aps qu'il y ait d'autre moyen ^^

oui je parlais de faire un truc totalement transparent ^^ pk ça serait pas possible ? (genre si il faut appeler une fonction spéciale pour charger une DLL, ça doit être possible de l'overrider, non ?)

Hmm nan de ce côté là je pense pas qu'il y ait de problème (Pas difficile (enfin façon de parler ^^) de surcharger LoadLibrary & co), mais le truc c'est au chargement de l'application, je vois mal quel moyen tu as de te démerder ^^

comment ça ? si elle appelle bien LoadLibrary et que tu arrives à remplacer LoadLibrary, tu devrais pouvoir te débrouiller non ? (enfin, sous réserve que tu aies aussi accès aux structures de données censées être remplies par LoadLibrary, ce qui doit être le cas)

Je suis vraiment pas sûr hein...
Je sais pas exactement comment windows charge les applications faut que je regarde plus en détail, mais du fait du linking dynamique je doute que ça appelle LoadLibrary au démarrage (ce qui impliquerait linking automatique de kernel32.dll (je ne sais pas si il est toujours chargé quoi qu'il arrive), puis éxécution de code dans le processus avant qu'il soit réellement créé, et ensuite je vois pas comment fonctionnerai le linking ^^)
(Sinon l'accès aux structures internes c pas important du tout pour une surcharge hein ^^)

GoldenCrystal :
Je suis vraiment pas sûr hein... Je sais pas exactement comment windows charge les applications faut que je regarde plus en détail, mais du fait du linking dynamique je doute que ça appelle LoadLibrary au démarrage (ce qui impliquerait linking automatique de kernel32.dll (je ne sais pas si il est toujours chargé quoi qu'il arrive), puis éxécution de code dans le processus avant qu'il soit réellement créé, et ensuite je vois pas comment fonctionnerai le linking ^^)

Pk il faudrait exécuter du code dans le processus avant la création ?

(Sinon l'accès aux structures internes c pas important du tout pour une surcharge hein ^^)

Gni ? Je veux dire, avoir accès à suffisamment de choses pour pouvoir émuler LoadLibrary ^^

-

LoadLibrary() n'est pas appelé au démarrage, je crois bien que les libraries load-time sont chargées autrement lors de la création du processus.
Par contre, le DllMain() de chaque Dll est appelé lors du chargement, sauf pour le cas particulier de Kernel32.dll (la seule librarie qu'on puisse appeler sans risque dans le DllMain() : Elle est forcément chargée).

Ce qu'il faudrait voir, c'est sans doute la librairie statique d'importation qui est liée au chargement load-time d'une librairie: En tripatouillant la lib statique d'importation, on doit pouvoir faire certains trucs...

Mais c'est vrai qu'il faudrait aussi surcharger LoadLibrary() pour les librairies chargées en run-time, mais je crois bien que ce n'est possible qu'en C: J'avais essayé une fois de surcharger EndDialog(), et j'avais une erreur C++

Pollux
: Pk il faudrait exécuter du code dans le processus avant la création ?

Ben c'est simple, LoadLibrary comme au moins 90% des fonctions windows fonctionne dans le processus, donc si tu l'appelles c'est forcément dans le processus qui veut charger une dll ^^

Gni ? Je veux dire, avoir accès à suffisamment de choses pour pouvoir émuler LoadLibrary ^^

Ben tu as suffisemment de choses pour l'émuler
Dans un cas simple tu te contentes d'extraire la Dll dans un fichier temporaire (que tu supprimera plus tard bien entendu) et tu apelles le LoadLibrary initial ça suffit :]
Sinon tu peux vouloir refaire le linking toi même et tout c'est certainement bien lourd et ça devient aussi beaucoup moins transparent Mais le vrai problème c'est comment allouer la mémoire...

Link
: LoadLibrary() n'est pas appelé au démarrage, je crois bien que les libraries load-time sont chargées autrement lors de la création du processus.

Merci, c'est justement ce sur quoi j'avais des doûtes ^^

Ce qu'il faudrait voir, c'est sans doute la librairie statique d'importation qui est liée au chargement load-time d'une librairie: En tripatouillant la lib statique d'importation, on doit pouvoir faire certains trucs...

Hmm oui tu peux faire certains trucs effectivement, mais il te faut au moins une Dll externe pour gérer les imports correctement après ça

Mais c'est vrai qu'il faudrait aussi surcharger LoadLibrary() pour les librairies chargées en run-time, mais je crois bien que ce n'est possible qu'en C: J'avais essayé une fois de surcharger EndDialog(), et j'avais une erreur C++

Non ça c'est indépendant du langage Tu peux le faire en C ou C++ sans problème, mais une fonction système ne se surcharge pas comme tu as du essayer de le faire Le truc c'est de patcher (oué tout de suite ça devient moins simple hein ^^) la procédure en mémoire (donc une fois le programme chargé...) pour que les appels soient redirrigés vers ta procédure a toi (Tu peux évidemment écrire la fonction de rempalcement en n'importe quel langage, mais le patch c'est en assembleur ^^)

Orion_ :
c'est marrant de voir comment a partir d'une question toute simple au depart, on degenere sur 2 pages dés qu'on commence a parler de truc linux genre Qt et GTK
perso moi, devoir installer je sais pas combien de Mo de dll Gtk ou Qt juste pour Une application ça me refroidis.

TiEmu

Orion_ :
c'est marrant de voir comment a partir d'une question toute simple au depart, on degenere sur 2 pages dés qu'on commence a parler de truc linux genre Qt et GTK
perso moi, devoir installer je sais pas combien de Mo de dll Gtk ou Qt juste pour Une application ça me refroidis.

Pke tu n'as jamais fait de grosse application

Orion et la programmation, une longue aventure

-

Une DLL de 7mega, c pas enorme je trouve

GTK/Qt tiennent vraiment dans une DLL de 7 Mo ? o_O

La version de base de QT (donc sans les widget exotiques) fait 7 meg ouais

tu inclus le rendu HTML dans les widgets exotiques j'imagine ?

-

non, les derives de TextEdit sont dedans
exotique = opengl, xml etc.

Orion_ :
donc aller chercher un package a droite a gauche pour faire fonctionner un prog, oui c'est relou, on est pas sous linux la, on est sous windows

attention, tu vas déchaîner des hordes de linuxiens qui vont te raconter qu'avec un gestionnaire de packages au contraire c'est totalement transparent et tout et tout et donc en fait c'est justement parce que windows est techniquement inférieur© que t'as ces pbs etc... et donc qu'en fait c'est de la faute de windows

Dis ça à mon installation d'une version plus récente de GCC... J'ai du renoncer et il a fallu qu'on m'apprenne le paramètre --force pour pouvoir revenir à la version précédente... Sinon, je n'avais plus aucun GCC qui marchait!

Ahlàlà pourquoi utiliser GCC sous linux quand on a Microsoft Visual C++ sous Windows ? (#troll#)

Parce qu'il fallait que notre projet de compilation marche sous linux...
C'est là que j'ai appris, hélas APRES avoir rendu le projet et avoir été salement noté, que:
1) GCC ne signale pas les déclarations implicites par défaut sur toutes les plateformes, et les fonctions ne sont pas toujours dans le même header (refus de compiler sous linux car je passais directement une structure à strncpy, au lieu de structure.chaine)
2) Les noms de fonctions ne sont pas décorés sous linux (ça marchait bien avec dev-c++ sous windows, téléchargé pour l'occasion, et impossible de linker sous nux... )

Résultat, 9/20...

Link :
2) Les noms de fonctions ne sont pas décorés sous linux (ça marchait bien avec dev-c++ sous windows, téléchargé pour l'occasion, et impossible de linker sous nux... )

??

1) Faut quand même être bon pour faire une erreur comme ça. T'as bien mis un -Wall dans les flags ?
2) Faux, c'est dans la norme... Tu linkes quoi, les fichiers objets de Windows ?

nEUrOO > effectivement, mais à la fin du mois, avec de la chance, on aura Qt4

nEUrOO:
Sous DOS comme sous Windows, les fonctions C normales, comme printf, sont précédées d'un underscore lors de la compilation: printf("coucou\n"); devient "pushl str1 - call _printf - addl $4, %esp"
C'est un peu plus compliqué en fait sous windows, selon la convention d'appel:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_core_argument_passing_and_naming_conventions.asp
(regarde __cdecl, __stdcall et __fastcall pour plus d'infos sur les décorations de chaque type)

ex-miles:
1) Ben non, moi, un habitué des environnements de développement, je ne l'avais pas mis (on n'en a besoin ni sous visual, ni sous dev-c++)... donc, je n'ai pas su que strncpy n'était pas déclaré, donc le compilo ne m'a pas signalé qu'il n'était pas normal de lui passer une structure...
2) Je passais à GCC un fichier assembleur.s faisant entre autre un "call _malloc".
->Sous windows, ça linkait parfaitement.
->Sous linux, compiler n'importe quoi d'autre marchait et était linké correctement, compiler le .s me mettait "symboles introuvables: _free, _malloc, etc."
Après avoir vainement tenté d'installer un gcc plus récent parce que celui de dev-c++ était plus récent que celui de mon linux, je me suis dit que s'il ne trouvait plus les noms standard, c'est qu'ils n'étaient pas décorés sous nux, ou pas décorés pareil...

ex-Miles: ouais, faut pas rever je pense, mais bon, j'hate de voir QT4 GPL pour Windows... ca va vraiment changer plein de trucs !

Link > c'est que ça a sans doute dû changer, effectivement Faut aussi voir que GCC sous Windows utilise une couche en plus, MinGW ou Cygwin, c'est peut-être eux qui sont responsables de ce pb, je ne sais pas...

nEUrOO > A priori, il arrive avant la fin du mois : http://www.trolltech.com/newsroom/announcements/00000207.html

Dev-c++ utilise MinGW. Mais les décorations des fonctions sous Windows sont standardisées par MS et respectées aussi bien par visual que par dev-c++.

C'est sous linux en tout cas que les décorations avec underscore ne sont sans doute pas utilisées...