Delete argv[0]
tgx874sah
Messages postés
1
Date d'inscription
dimanche 29 décembre 2002
Statut
Membre
Dernière intervention
7 septembre 2004
-
7 sept. 2004 à 01:44
MetalDwarf Messages postés 241 Date d'inscription mardi 29 octobre 2002 Statut Membre Dernière intervention 23 janvier 2006 - 10 sept. 2004 à 23:00
MetalDwarf Messages postés 241 Date d'inscription mardi 29 octobre 2002 Statut Membre Dernière intervention 23 janvier 2006 - 10 sept. 2004 à 23:00
5 réponses
cs_eRoZion
Messages postés
241
Date d'inscription
vendredi 23 mai 2003
Statut
Membre
Dernière intervention
8 octobre 2007
1
7 sept. 2004 à 02:45
7 sept. 2004 à 02:45
Donc si j'ai bien compris ton programme est en mode console.
Deux cas de figures :
- Ton application est une application ms-dos, auquel cas tu peux le faire sans problème puisque chaque executable est copié en mémoire puis le fichier libéré juste avant execution.
- Ton application est une application 32 bits, alors là il me semble que l'on peut modifié l'header de l'executable après compilation pour que le fichier soit également libéré après la copie en mémoire, mais là il te faudra plus d'infos parce que je ne m'en souviens plus.
nb: au sujet de argv[0], pour le remplacer en win32 il te faudra employé GetModuleFileName()
eRoZion
Deux cas de figures :
- Ton application est une application ms-dos, auquel cas tu peux le faire sans problème puisque chaque executable est copié en mémoire puis le fichier libéré juste avant execution.
- Ton application est une application 32 bits, alors là il me semble que l'on peut modifié l'header de l'executable après compilation pour que le fichier soit également libéré après la copie en mémoire, mais là il te faudra plus d'infos parce que je ne m'en souviens plus.
nb: au sujet de argv[0], pour le remplacer en win32 il te faudra employé GetModuleFileName()
eRoZion
magic_Nono
Messages postés
1878
Date d'inscription
jeudi 16 octobre 2003
Statut
Membre
Dernière intervention
16 mars 2011
7 sept. 2004 à 10:50
7 sept. 2004 à 10:50
si ça marche po ou que tu es sous X,
créé un processus indépendant (ayant pour père le système)
dis lui d'attendre la fermeture du prg (tu peux régler ça par un msg)
ou un cht ds une variable quelconque
et supprime l'appelant
ceci dit, je trouve que c'est un peu du sucide et ne vois pas vraiement l'intéret, surtout que c'est pas forcément tjs possible
(éventuellement, tu peux faire sauter la protection de lecture seule mais si le prg est lancé depuis un périph protégé physiquement en écriture [cd, diskette protégée, clef protégée...], c'est mission impossible)
++
Magic Nono: l'informagicien! 8-)
créé un processus indépendant (ayant pour père le système)
dis lui d'attendre la fermeture du prg (tu peux régler ça par un msg)
ou un cht ds une variable quelconque
et supprime l'appelant
ceci dit, je trouve que c'est un peu du sucide et ne vois pas vraiement l'intéret, surtout que c'est pas forcément tjs possible
(éventuellement, tu peux faire sauter la protection de lecture seule mais si le prg est lancé depuis un périph protégé physiquement en écriture [cd, diskette protégée, clef protégée...], c'est mission impossible)
++
Magic Nono: l'informagicien! 8-)
MetalDwarf
Messages postés
241
Date d'inscription
mardi 29 octobre 2002
Statut
Membre
Dernière intervention
23 janvier 2006
9 sept. 2004 à 21:29
9 sept. 2004 à 21:29
he he c est impossible car malloc()/free() ou new/delete n agissent que sur la zone de la memoire qui s appelle le tas (heap), et argv n est pas dans le tas quel que soit l OS.
Abandonne cette idee, sinon plantages (mais je pense plutot que la memoire est protegee).
Abandonne cette idee, sinon plantages (mais je pense plutot que la memoire est protegee).
magic_Nono
Messages postés
1878
Date d'inscription
jeudi 16 octobre 2003
Statut
Membre
Dernière intervention
16 mars 2011
10 sept. 2004 à 09:07
10 sept. 2004 à 09:07
le chemin & nom de l'appelant étant bien évidement transmis au 2e processus...
je vois po ce qu'il y a d'impossible la dedans
Magic Nono: l'informagicien! 8-)
je vois po ce qu'il y a d'impossible la dedans
Magic Nono: l'informagicien! 8-)
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
MetalDwarf
Messages postés
241
Date d'inscription
mardi 29 octobre 2002
Statut
Membre
Dernière intervention
23 janvier 2006
10 sept. 2004 à 23:00
10 sept. 2004 à 23:00
En faitr ca tient au decoupage de la memoire en zones sur l architecture x86. Chaque processus est mappe dans son propre espace d adressage (sur tous les OS ulti-taches). Il y a une zone de donnees, une zone pour la pile, une zone pour le tas...et le reste des zones (comme les zones des bibliotheques partagees. Les fonctions malloc() et free() (de meme que les operateurs new et delete) permettent de reserver et de liberer de la memoire sur le tas, et UNIQUEMENT sur le tas (un free(&n) avec n en variable locale (donc allouee sur la pile) ne marchera pas par exemple). Et le tableau argv (de meme que env) ne se trouve pas dans le tas, donc la fonction free() ne peut pas intervenir dessus (pas plus que delete qui fait un appel a la meme routine que free en interne, meme si je ne suis pas sur qu un espace alloue avec malloc() puisse etre libere avec delete).
Il s agit de points un peu delicat et une connaissance de l architecture x86 et des OS en general est necessaire pour comprendre ceci, mais pour s en convaincre il suffit de regarder l adresse memoire de argv et celle d un espace alloue sur le tas. Elles sont totalement differentes!
Par contre pour la fonction windows GetModuleFileName() je ne sais pas comment elle fonctionne donc je ne me prononce pas... :)
Il s agit de points un peu delicat et une connaissance de l architecture x86 et des OS en general est necessaire pour comprendre ceci, mais pour s en convaincre il suffit de regarder l adresse memoire de argv et celle d un espace alloue sur le tas. Elles sont totalement differentes!
Par contre pour la fonction windows GetModuleFileName() je ne sais pas comment elle fonctionne donc je ne me prononce pas... :)
