probléme avec fork()

salut les amis
j'ai un probléme à comprendre le fonctionnement de la fonction fork

Code:

---

1 2 3 4 5 6 7 8 9

pid = fork ();   if (pid > 0) { /* Processus père */ } else if (pid == 0) { /* Processus fils */ } else { /* Traitement d'erreur */ }

---

je veux savoir dans quel cas le pid sera égal à 0 ou différent de 0 ? c'est aleatoire ?
la valeure retourné par fork a un rapport avec le PID (du getpid ou getppid )?

et puisque il y aura la creation de 2 prossesus en meme temps par frok un avec un pid <> de 0 (père) et l'autre avec 0 (fils) ... on va executer le if et le else en meme temps :roll:... c'est faux ça ?

Citation:

---

Envoyé par yous18

je veux savoir dans quel cas le pid sera égal à 0 ou différent de 0 ? c'est aleatoire ?

---

Ben non 8O tu viens de le dire.. dans un cas c'est le pere, dans l'autre le fils...

Citation:

---

Envoyé par yous18

la valeure retourné par fork a un rapport avec le PID (du getpid ou getppid )?

---

Ben oui, c'est la meme chose "Process Identifier"

Citation:

---

Envoyé par yous18

et puisque il y aura la creation de 2 prossesus en meme temps par frok un avec un pid <> de 0 (père) et l'autre avec 0 (fils) ... on va executer le if et le else en meme temps :roll:... c'est faux ça ?

---

OUI c'est faux... :D

Il n'y aura pas creation de 2 processus, mais d'un seul, le fils...
Le pere existe deja.

Le fork duplique le pere (et execute le meme code jusqu'au fork).

Donc non on ne fera pas le if et le else en meme temps :on duplique le code, dans une instance, le pere, on passera d'un cote. Dans le fils de l'autre...

Citation:

---

Envoyé par souviron34

OUI c'est faux... :D

Il n'y aura pas creation de 2 processus, mais d'un seul, le fils...
Le pere existe deja.

Le fork duplique le pere (et execute le meme code jusqu'au fork).

Donc non on ne fera pas le if et le else en meme temps :on duplique le code, dans une instance, le pere, on passera d'un cote. Dans le fils de l'autre...

---

la j'ai pas bien compris :cry: tu peux encors m'expliquer ?
le choix sera aléatoire entre fils et père ... c'est ça ?

le processus fils prends le pid 0 alors que le pere garde son pid

dans ton code tu as un "if (pid == 0)" donc le fils entrera dans cette partie de code
d'un autre cote le processus pere n'a pas son pid == 0 donc il entrera dans le else

j'espere ne pas avoir dit d'anerie

Citation:

---

Envoyé par yous18

la j'ai pas bien compris :cry: tu peux encors m'expliquer ?
le choix sera aléatoire entre fils et père ... c'est ça ?

---

Qu'est ce que tu ne comprends pas dans "C'est faux" ??

J'ai dit "non le choix n'est pas aléatoire, tu as donné toi-même la réponse".

Citation:

---

Envoyé par m0ul3sh0t

le processus fils prends le pid 0 alors que le pere garde son pid

dans ton code tu as un "if (pid == 0)" donc le fils entrera dans cette partie de code
d'un autre cote le processus pere n'a pas son pid == 0 donc il entrera dans le else

j'espere ne pas avoir dit d'anerie

---

Du tout, c'est bien ça.. :D

Citation:

---

Envoyé par yous18

la j'ai pas bien compris :cry: tu peux encors m'expliquer ?
le choix sera aléatoire entre fils et père ... c'est ça ?

---

La seule chose qu'il faut impérativement se mettre en tête, c'est que dès que tu exécutes "fork()" tu obtiens instantanément un duplicata de ton processus en cours. Donc avant le fork tu as un procesus, au moment où l'instruction se termine tu en as 2 identiques qui continuent tous deux à exécuter la suite du code
exemple

Code:

---

1 2 3 4 5 6 7 8

#include <sys/types.h> #include <unistd.h>   int main() { fork(); printf("Hello (pid=%d)\n", getpid())); }

---

=> Tu compiles, tu exécutes, tu obtiens 2 fois "Hello" mais chaque affichage provient d'un processus différent (le pid n'est pas le même)

Donc la seule façon de distinguer qui est le père de qui est dans le retour du fork()
Exemple

Code:

---

1 2 3 4 5 6 7 8 9 10

#include <sys/types.h> #include <unistd.h>   int main() { int pid;   pid=fork(); printf("Mon père: %d - Moi: %d - pid: %d\n", getppid(), getpid(), pid); }

---

Tu devrais obtenir un truc de ce style
Mon père: <valeurA> - Moi: <valeur B> - pid <valeur C>
Mon père: <valeur B> - Moi: <valeur C> - pid 0
C'est donc grace à la valeur de pid que t'arrives à savoir dans quel processus tu es et que tu peux affecter tel ou tel code à tel ou tel processus.

merci le amis j'ai compri ... aprés la création si il y a un if pour le fils et un else pour le père ils seront tous les deux exécuter ...

quand j'ai compilé le dernier code de Sve@r j'ai eu une erreure de compilation sous Dev C++

Code:

---

1 2 3

[Linker error] undefined reference to `fork' [Linker error] undefined reference to `getppid' ld returned 1 exit status

---

alors quoi faire ?

ah je crois que seulement sur linux que fork peut s'executer et pas sur windows :roll:

Citation:

---

Envoyé par souviron34

Le fork duplique le pere (et execute le meme code jusqu'au fork).

---

Tu me mets le doute là. Tu ne voulais pas dire exécute le même code à partir du fork ?

yous18 : En effet, fork() est une fonction POSIX uniquement.

valefor : Si j'ai bien compris, certaines implémentations de fork() ré-exécutent tout ce qui s'est passé avant (ne me demande pas comment ça fait pour des fonctions qui ont eu des effets de bord).
Mais normalement, fork() duplique le processus et son état complet, ne changeant que quelques petites choses comme l'id du processus et évidemment la valeur de retour de fork()...

yous18 : Dans le code que tu as posté, le test du if sera fait pour les deux processus, mais comme le pid n'aura pas la même valeur, le if n'ira pas dans la même branche. Pour le père, le test sera vrai, tandis que pour le fils, le test sera faux et c'est le else if qui sera exécuté.

Citation:

---

Envoyé par Médinoc

valefor : Si j'ai bien compris, certaines implémentations de fork() ré-exécutent tout ce qui s'est passé avant (ne me demande pas comment ça fait pour des fonctions qui ont eu des effets de bord).

---

Intéressant. Pour tester le truc j'ai essayer de créer un code ayant des effets de bord pour voir ce que ça donne...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include <sys/types.h> #include <unistd.h> #include <stdio.h>   int main() { char nom[1024]; FILE *fp;   sprintf(nom, "/tmp/essai%d", getpid());   fp=fopen(nom, "a"); fprintf(fp, "essai %d\n", getpid()); fclose(fp);   fork(); printf("Fini (%d)\n", getpid()); }

---

J'espérais que si le fork redéroule tout ce qui s'est passé avant, j'aurais alors soit 2 fichiers dans "/tmp", soit un fichier avec 2 lignes. Rien de tout ça...
[edit]
... jusqu'à ce que j'ai l'idée de mettre le fclose après le fork(). Niveau prog je ne sais pas comment est sensé se comporter ce code où un process ouvre un fichier qui est fermé ensuite par lui et par son fils mais au résultat j'ai eu 2 lignes dans le fichier...

Citation:

---

Envoyé par Médinoc

Mais normalement, fork() duplique le processus et son état complet, ne changeant que quelques petites choses comme l'id du processus et évidemment la valeur de retour de fork()...

---

En fait, sous Linux, fork() ne duplique même pas la mémoire sauf si un des processus la modifie (optimisation à donf)

Pour la mémoire, oui ça optimise, le Copy On Write, c'est utile.

Il faut bien compenser pour l'impossibilité d'avoir confirmation immédiate qu'une application arbitraire s'est bien lancée (on peut savoir qu'elle a foiré, mais pas qu'elle marche, à moins de se dire "si elle n'a pas foiré dans cinq secondes, c'est qu'elle marche")... :roll:

fork() est très bien pour diviser une application et faire comme des "threads indépendants". Par contre, pour lancer une application étrangère, le CreateProcess() de Windows est bien plus pratique.

Citation:

---

Envoyé par Sve@r

Intéressant. Pour tester le truc j'ai essayer de créer un code ayant des effets de bord pour voir ce que ça donne...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include <sys/types.h> #include <unistd.h> #include <stdio.h>   int main() { char nom[1024]; FILE *fp;   sprintf(nom, "/tmp/essai%d", getpid());   fp=fopen(nom, "a"); fprintf(fp, "essai %d\n", getpid()); fclose(fp);   fork(); printf("Fini (%d)\n", getpid()); }

---

J'espérais que si le fork redéroule tout ce qui s'est passé avant, j'aurais alors soit 2 fichiers dans "/tmp", soit un fichier avec 2 lignes. Rien de tout ça...
[edit]
... jusqu'à ce que j'ai l'idée de mettre le fclose après le fork(). Niveau prog je ne sais pas comment est sensé se comporter ce code où un process ouvre un fichier qui est fermé ensuite par lui et par son fils mais au résultat j'ai eu 2 lignes dans le fichier...


En fait, sous Linux, fork() ne duplique même pas la mémoire sauf si un des processus la modifie (optimisation à donf)

---

J'ai déjà eu affaire a ce genre de code et le comportement est très aléatoir et plusieurs scénarios sont possible. De tte facon le fichier est une ressource partagée donc l'accès doit etre protégé par un mutex ou une semaphore. et du coup celui qui a ouvert le premier ecrit et ferme, le deuxième ne pourras rentrer dans le fichier que si la semaphore est liberée.

Citation:

---

Envoyé par Médinoc

valefor : Si j'ai bien compris, certaines implémentations de fork() ré-exécutent tout ce qui s'est passé avant (ne me demande pas comment ça fait pour des fonctions qui ont eu des effets de bord).
Mais normalement, fork() duplique le processus et son état complet, ne changeant que quelques petites choses comme l'id du processus et évidemment la valeur de retour de fork()...

---

ben oui.. Et c'est valable pour TOUTE implémentation de fork, c'est précisé dans la doc.

T'as pas remarqué, quand on fait un client/serveur : le code contenu jusqu'à l'attente est rééxécuté par le clone quand il démarre.... (tu peux faire des inits, des lectures de fichiers de configs, etc.. etc..) ?

(puisqu'on arrive au "if (pid == 0 ) else ...")

Euh...
Mais s'il y avait un affichage dans le code avant le fork(), l'affichage sera refait ?
Ou une modification de fichier (un comptage, par exemple) ?

Je n'ai jamais constaté cela...

Citation:

---

Envoyé par Médinoc

Euh...
Mais s'il y avait un affichage dans le code avant le fork(), l'affichage sera refait ?
Ou une modification de fichier (un comptage, par exemple) ?

Je n'ai jamais constaté cela...

---

testes ;)

Mais comme en général quand on fait des clients/serveurs on met pas de print, on le voit pas, mais si tu te mets en debug, avec des print, tu verras bien....

Je n'ai plus rien d'unixoïde sous la main, hélas. Mais on avait des cours sous HP-UX et FreeBSD à l'ISTY, avec des codes simples:

Code:

---

1 2 3 4 5 6 7 8

int main(void) { int pid; printf("Avant\n"); pid = fork(); printf("Apres: %d\n", pid); return 0; }

---

Et dans aucun de mes souvenirs (qui je dois l'admettre, ont trois ans), le "Avant" n'était affiché deux fois...

ben comment expliquerais-tu le code du PO (post #1), dans ce cas ??

Je ne vois pas ce qu'il y a de particulier à expliquer dans cet extrait de code (il n'y a rien de visible avant le fork()).

Comme explications sur fork() dans le code lui-même, je dirais ceci:
Lors du fork(), (et en supposant que le fork() n'échoue pas), le processus est dupliqué, y compris son état et sa mémoire (enfin, dupliqué ou mis en Copy-On-Write), donc y compris l'état de ses variables et le fait que son compteur programme soit quelque part dans le code de fork() (bien que où exactement dans la fonction peut être changé par le système d'exploitation, pour différencier la valeur de retour. C'est un détail, mais le fait est que le processus fils commence "déjà dans fork()".
Ensuite, fork() retourne pour chacun des deux processus, avec de chaque côté la valeur de retour appropriée (0 pour le fils, pid du fils pour le père).

PS: Peux-tu poster un lien vers la doc en question ? Je ne trouve rien via Wikipedia ou l'Open Group...

Citation:

---

Envoyé par Médinoc

valefor : Si j'ai bien compris, certaines implémentations de fork() ré-exécutent tout ce qui s'est passé avant

---

Heu... lesquelles?

D'après souviron34, toutes.

D'après moi, aucune (c'est de lui que je tenais les "certaines"), sauf peut-être celle de cygwin, et encore je suis loin d'en être sur.

Et comment une telle chose pourrait-elle être implémentée?

Remarque, le re-jeu serait très pratique pour le débogage. Mais parle t-on de systèmes déterministes?

Note : Le re-jeu est une méthode de débogage en programmation logique (CLP).

C'est à lui qu'il faut le demander, pas à moi.

Ça me parait aussi logique qu'à toi, tu sais...

tres simple de verifier...

Lit un petit fichier juste avant et stocke-le dans un tableau de chaines allouees dynamiquement...

Si c'est la "copie", les adresses des chaines devraient etre les memes, si je vous suis...

Si il refait le code, les adresses seront differentes :D

(a mon avis, si c'etait la copie, ca marcherait pas, car pas de memoire partagee , or on a 2 processus differents... )

Je n'ai pas de système unixoïde sous la main, mais je suis persuadé que c'est de la copie, et si, ça marcherait:
Deux processus peuvent référencer exactement la même adresse virtuelle, et pourtant "voir" deux zones mémoire différentes.

Citation:

---

Envoyé par souviron34

tres simple de verifier...

Lit un petit fichier juste avant et stocke-le dans un tableau de chaines allouees dynamiquement...

Si c'est la "copie", les adresses des chaines devraient etre les memes, si je vous suis...

---

Bien sûr que les adresses sont les mêmes! On ne va quand même pas perde notre temps à faire des expériences absurdes dont on connait le résultat par avance pour te faire plaisir.

Citation:

---

Envoyé par souviron34

Si il refait le code, les adresses seront differentes :D

---

Pas forcément. Au contraire, je parierai que l'allocation dynamique est déterministe.

Citation:

---

Envoyé par souviron34

(a mon avis, si c'etait la copie, ca marcherait pas, car pas de memoire partagee , or on a 2 processus differents... )

---

Tu ne comprends toujours pas ce que fait fork().

J'ai fait des tests, et je n'arrive pas à avoir des pointeurs différents.

Par exemple avec ce code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

#include <stdio.h> #include <sys/types.h> #include <unistd.h> #include <stdlib.h> #include <sys/stat.h> #include <fcntl.h>   int main(int argc, char **argv) { char *texte[10] = {0}; int i = 0;   for(i = 0; i < 10; i++) { texte[i] = (char *)malloc(1 + i); }   if(fork() < 0) { exit(1); }   for(i = 0; i < 10; i++) { printf("%d : texte[%d] = %p\n", getpid(), i, texte[i]); }   return 0; }

---

Rajoute un affichage de texte juste avant le fork(), s'il te plait, juste pour faire joli et nous dire si le texte est affiché deux fois (il faut s'attendre à tout, mais je parierais que non)...

Au début j'avais essayé ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#include <stdio.h> #include <sys/types.h> #include <unistd.h> #include <stdlib.h>   int main(int argc, char **argv) { void * foo = 0;   printf("%d : foo = %p\n", getpid(), foo);   foo = malloc(42);   if(fork() < 0) { exit(1); }   printf("%d : foo = %p\n", getpid(), foo);   return 0; }

---

et cela donne :

Code:

---

1 2 3

1737 : foo = (nil) 1738 : foo = 0x804a008 1737 : foo = 0x804a008

---

Je me paluche le man de fork en attendant.

Par contre,

Citation:

---

Deux processus peuvent référencer exactement la même adresse virtuelle, et pourtant "voir" deux zones mémoire différentes.

---

si tu as un exemple, ça m'éclairerait.

Citation:

---

Envoyé par valefor

J'ai fait des tests,

---

Pourquoi?

Si je te dis que printf("%d",2+2) affiche 42, tu fais le test aussi?

Citation:

---

Envoyé par valefor

et je n'arrive pas à avoir des pointeurs différents.

---

Tu veux dire :

• chaque exécution du programme affiche deux fois la même chose, ou
• toutes les exécutions du programme affichent exactement la même chose (= le test ne teste rien du tout)

?

Le système d'exploitation est fait pour que par défaut, chaque programme se croie seul sur le système.
C'est une des raisons pour lesquelles l'adressage est virtuel : Un programme peut voir quelque chose à l'adresse virtuelle X, mais la "vraie" adresse en mémoire, ou dans le fichier de pagination, est seulement connue du système d'exploitation.

Ainsi, les variables globales d'un programme pourraient avoir une adresse virtuelle fixe (par exemple, un int se trouvant toujours à l'adresse virtuelle 0x00000004). Si tu fais tourner deux programmes, chacun verra sa variable à l'adresse virtuelle 0x00000004, mais les vraies adresses seront différentes (par exemple, l'un peut être voir les adresses réelles 1000 à 1999, tandis que l'autre verra les adresses réelles 2000 à 2999).

Et en plus, avec les histoires de pagination, mise de la mémoire sur le disque et autre, ces adresses réelles peuvent changer au cours du temps. Mais du point de vue du processus, l'adresse virtuelle ne change pas.

Aussi, la "mémoire partagée" est une fonction spéciale du système d'exploitation, qui donne à deux processus l'accès à la même adresse réelle (qui, en fait, peut être représentée par deux adresses virtuelles différentes).

Citation:

---

Envoyé par valefor

et cela donne :

Code:

---

1 2 3

1737 : foo = (nil) 1738 : foo = 0x804a008 1737 : foo = 0x804a008

---

---

Citation:

---

Envoyé par corrector

Tu veux dire :

• chaque exécution du programme affiche deux fois la même chose, ou
• toutes les exécutions du programme affichent exactement la même chose (= le test ne teste rien du tout)

?

---

Visiblement, c'est ni l'un ni l'autre, c'est ce que je disais (:P) :

le pid change dans son print, ce qui veut dire que chaque programme est reexecute....

Citation:

---

le pid change dans son print, ce qui veut dire que chaque programme est reexecute....

---

Là, 'faut expliquer ton raisonnement...

ok , desole j'avais lu trop vite.. :oops:

Citation:

---

Envoyé par souviron34

Visiblement, c'est ni l'un ni l'autre, c'est ce que je disais (:P) :

---

Non, visiblement tu regardes mal. Il n'y a qu'une seule exécution du programme.

C'est bien ce que je pensais, le test ne teste rien, parce qu'il n'y a même pas de base de référence pour comparer.

Un exemple qui devrait bien tester:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

#define SIZE 20   int main() { srand(time)   int pidAvant = getpid(); int val[SIZE] for(i=0 ; i<SIZE ; i++) val[i] = rand();   puts("fork in 2 seconds"); sleep(2); /*pour forcer srand(time) à régler une autre "graine"*/ fork(); printf("Avant=%d Après=%d", pidAvant, getpid());   for(i=0 ; i<SIZE ; i++) printf("process%d[ %d ] : %d", getpid(), i, val[i]); }

---

Avec un code de ce genre, si le code est ré-exécuté, on aura des valeurs aléatoires différentes.

Et à mon avis, tout comme celui de corrector, elles devraient être identiques.

Edit: Je rentre chez moi et j'ai 1h30 de transports. À plus!

Citation:

---

Envoyé par Médinoc

Rajoute un affichage de texte juste avant le fork(), s'il te plait, juste pour faire joli et nous dire si le texte est affiché deux fois (il faut s'attendre à tout, mais je parierais que non)...

---

Fait plutôt une lecture sur stdin, et imprime la valeur lue après le fork...

(et entre une valeur différente les deux fois :marteau:)

Citation:

---

Envoyé par Médinoc

Un exemple qui devrait bien tester:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

#define SIZE 20   int main() { srand(time)   int pidAvant = getpid(); int val[SIZE] for(i=0 ; i<SIZE ; i++) val[i] = rand();   puts("fork in 2 seconds"); sleep(2); /*pour forcer srand(time) à régler une autre "graine"*/ fork(); printf("Avant=%d Après=%d", pidAvant, getpid());   for(i=0 ; i<SIZE ; i++) printf("process%d[ %d ] : %d", getpid(), i, val[i]); }

---

Avec un code de ce genre, si le code est ré-exécuté, on aura des valeurs aléatoires différentes.

---

Rhaa j'ai plus d'unixoide à disposition pour tester ça. Mais je pense qu'on aura les mêmes valeurs dans le père et dans le fils. Parce que tant qu'un test ne travaille que sur la mémoire ben on ne prouve rien vu que chaque processus reçoit une copie de la mémoire au moment du fork. Or quand le fork est lancé, le tableau a déjà été rempli.

En fait, plus je réfléchis et plus je me dis que du point de vue des programmeurs systèmes, il serait plus facile de faire commencer le fils au moment du fork que de lui faire rejouer tout le code exécuté avant tout en lui demandant de ne pas changer les valeurs trouvées lors de la première exécution.

D'ailleurs, si je tape

Code:

---

1 2 3 4

sleep(300); printf("Depart\n"); fork(); printf("Fin\n");

---

Est ce que le fils va vraiment rejouer tout le code et attendre lui-aussi connement 5mn avant d'afficher "hello" ???

Bon, j'ai fait le test sur mon vieux Ubuntu 5.04:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

#include <stdio.h> #include <unistd.h> #include <time.h> #include <math.h>   #define SIZE 10   int main() { int pidAvant = getpid(); int val[SIZE]; size_t i;   srand((int)time(NULL));   for(i=0 ; i<SIZE ; i++) val[i] = rand();   puts("fork in 2 seconds"); sleep(2); /*pour forcer srand(time) à régler une autre "graine"*/ fork(); printf("Avant=%d Après=%d\n", pidAvant, getpid());   for(i=0 ; i<SIZE ; i++) printf("process%d[ %d ] : %d\n", getpid(), i, val[i]); return 0; }

---

Et la sortie:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

link@ubuntu:~/TestsCpp$ gcc -o testfork TestFork.c link@ubuntu:~/TestsCpp$ ./testfork fork in 2 seconds Avant=8102 AprÚs=8103 process8103[ 0 ] : 688197052 process8103[ 1 ] : 1049773403 process8103[ 2 ] : 413948371 process8103[ 3 ] : 1623950930 process8103[ 4 ] : 755136942 process8103[ 5 ] : 762038674 process8103[ 6 ] : 539295439 process8103[ 7 ] : 1471486800 process8103[ 8 ] : 1637510112 process8103[ 9 ] : 923374679 Avant=8102 AprÚs=8102 process8102[ 0 ] : 688197052 process8102[ 1 ] : 1049773403 process8102[ 2 ] : 413948371 process8102[ 3 ] : 1623950930 process8102[ 4 ] : 755136942 process8102[ 5 ] : 762038674 process8102[ 6 ] : 539295439 process8102[ 7 ] : 1471486800 process8102[ 8 ] : 1637510112 process8102[ 9 ] : 923374679 link@ubuntu:~/TestsCpp$

---

Cela montre que non seulement les valeurs sont identiques, mais le "pid avant fork()" est identique également.
Cela suffit-il à prouver que fork() ne ré-exécute pas ce que le programme a déjà accompli ?
(de plus, réexécuter le programme serait plus compliqué que la simple duplication de son état...)

Quant à ce que j'avais dit sur cygwin, on peut aussi spéculer que son implémentation de fork(), au lieu de ré-exécuter, crée un processus séparé et recopie "manuellement" l'état du processus précédent, à coup de VirtualAllocEx(), ReadProcessMemory(), WriteProcessMemory()...