J'ai un probleme avec les fonctions SetThreadContext et GetThreadContext
sous Windows XP cela fonctionne
mais sous Windows 2000 sur certains postes (apparemment du Pentium M 1.6
GHz)
Les registres Dr0, Dr1, Dr2, Dr3, Dr6, Dr7 ne sont pas restitués
correctement.
CONTEXT context;
Vous oubliez allégrement que votre processus peut être swappé, que son working-set peut évoluer réduisant la taille de la pile physiquement alloué, que toute page physique qui passe d'un process à un autre doit être misa à 0 (toute la page) dû au cahier des charges de l'armée américaine que WindowsNT respect depuis sa création.
Oui, Patrick à raison de dire que l'OS peut mettre à 0 les pages au-delà du sommet de la pile, et Non Vincent, l'OS fait bien des choses que le programme utilisateur ne voit pas ;-). -- Paul Bacelar MVP VC++
"Vincent Burel" wrote in message news:43d7b071$0$20138$
"Cyrille Szymanski" wrote in message news:
int main(int argc, char **argv) { RemplirPile(); LirePile();
return 0; }
* Sauf que bien sûr cela n'a aucune garantie de renvoyer le résultat attendu.
si tu fais rien entre les deux appels, j'ose espérer que si ! :-)
VB
Vous oubliez allégrement que votre processus peut être swappé, que son
working-set peut évoluer réduisant la taille de la pile physiquement alloué,
que toute page physique qui passe d'un process à un autre doit être misa à 0
(toute la page) dû au cahier des charges de l'armée américaine que WindowsNT
respect depuis sa création.
Oui, Patrick à raison de dire que l'OS peut mettre à 0 les pages au-delà du
sommet de la pile, et Non Vincent, l'OS fait bien des choses que le
programme utilisateur ne voit pas ;-).
--
Paul Bacelar
MVP VC++
"Vincent Burel" <vincent.burel@nospam.wanadoo.fr> wrote in message
news:43d7b071$0$20138$8fcfb975@news.wanadoo.fr...
"Cyrille Szymanski" <cns@cns2.invalid> wrote in message
news:Xns9756B6557263Ccns2cnsinvalid@212.27.42.133...
int main(int argc, char **argv) {
RemplirPile();
LirePile();
return 0;
}
* Sauf que bien sûr cela n'a aucune garantie de renvoyer le résultat
attendu.
si tu fais rien entre les deux appels, j'ose espérer que si ! :-)
Vous oubliez allégrement que votre processus peut être swappé, que son working-set peut évoluer réduisant la taille de la pile physiquement alloué, que toute page physique qui passe d'un process à un autre doit être misa à 0 (toute la page) dû au cahier des charges de l'armée américaine que WindowsNT respect depuis sa création.
Oui, Patrick à raison de dire que l'OS peut mettre à 0 les pages au-delà du sommet de la pile, et Non Vincent, l'OS fait bien des choses que le programme utilisateur ne voit pas ;-). -- Paul Bacelar MVP VC++
"Vincent Burel" wrote in message news:43d7b071$0$20138$
"Cyrille Szymanski" wrote in message news:
int main(int argc, char **argv) { RemplirPile(); LirePile();
return 0; }
* Sauf que bien sûr cela n'a aucune garantie de renvoyer le résultat attendu.
si tu fais rien entre les deux appels, j'ose espérer que si ! :-)
VB
Paul Bacelar
Vous oubliez allégrement que votre processus peut être swappé, que son working-set peut évoluer réduisant la taille de la pile physiquement alloué, que toute page physique qui passe d'un process à un autre doit être misa à 0 (toute la page) dû au cahier des charges de l'armée américaine que WindowsNT respect depuis sa création.
Oui, Patrick à raison de dire que l'OS peut mettre à 0 les pages au-delà du sommet de la pile, et Non Vincent, l'OS fait bien des choses que le programme utilisateur ne voit pas ;-).
-- Paul Bacelar
"Vincent Burel" wrote in message news:43d7b071$0$20138$
"Cyrille Szymanski" wrote in message news:
int main(int argc, char **argv) { RemplirPile(); LirePile();
return 0; }
* Sauf que bien sûr cela n'a aucune garantie de renvoyer le résultat attendu.
si tu fais rien entre les deux appels, j'ose espérer que si ! :-)
VB
Vous oubliez allégrement que votre processus peut être swappé, que son
working-set peut évoluer réduisant la taille de la pile physiquement alloué,
que toute page physique qui passe d'un process à un autre doit être misa à 0
(toute la page) dû au cahier des charges de l'armée américaine que WindowsNT
respect depuis sa création.
Oui, Patrick à raison de dire que l'OS peut mettre à 0 les pages au-delà du
sommet de la pile, et Non Vincent, l'OS fait bien des choses que le
programme utilisateur ne voit pas ;-).
--
Paul Bacelar
"Vincent Burel" <vincent.burel@nospam.wanadoo.fr> wrote in message
news:43d7b071$0$20138$8fcfb975@news.wanadoo.fr...
"Cyrille Szymanski" <cns@cns2.invalid> wrote in message
news:Xns9756B6557263Ccns2cnsinvalid@212.27.42.133...
int main(int argc, char **argv) {
RemplirPile();
LirePile();
return 0;
}
* Sauf que bien sûr cela n'a aucune garantie de renvoyer le résultat
attendu.
si tu fais rien entre les deux appels, j'ose espérer que si ! :-)
Vous oubliez allégrement que votre processus peut être swappé, que son working-set peut évoluer réduisant la taille de la pile physiquement alloué, que toute page physique qui passe d'un process à un autre doit être misa à 0 (toute la page) dû au cahier des charges de l'armée américaine que WindowsNT respect depuis sa création.
Oui, Patrick à raison de dire que l'OS peut mettre à 0 les pages au-delà du sommet de la pile, et Non Vincent, l'OS fait bien des choses que le programme utilisateur ne voit pas ;-).
-- Paul Bacelar
"Vincent Burel" wrote in message news:43d7b071$0$20138$
"Cyrille Szymanski" wrote in message news:
int main(int argc, char **argv) { RemplirPile(); LirePile();
return 0; }
* Sauf que bien sûr cela n'a aucune garantie de renvoyer le résultat attendu.
si tu fais rien entre les deux appels, j'ose espérer que si ! :-)
VB
Paul Bacelar
"Vincent Burel" wrote in message news:43d7a364$0$18314$
"Remi THOMAS" wrote in message news:43d79c24$0$21351$
"Olivier" écrivit > Bonjour, > > J'ai un probleme avec les fonctions SetThreadContext et > GetThreadContext > sous Windows XP cela fonctionne > mais sous Windows 2000 sur certains postes (apparemment du Pentium M > 1.6 > GHz) >
Le plus souvent c'est parceque la structure CONTEXT n'est pas crée au bon endroit. Tu fais un new ou c'est sur la pile. Sur la pile il y a de forte chance que la structure ait disparue quand tu
y
accèdes. La différence de comportement entre XP et 2000 c'est que sous XP miraculeusement ton espace mémoire n'est pas écrasé après sa libération. Sous 2000 oui.
la pile n'est jamais écrasé (le systeme n'a pas que ca à faire), elle est
Tu te trompes bien lourdement.
simplement utilisé... sous forme d'une pile. Les conséquences de cette utilisation vont faire que les locales utilisées par une fonction seront plus ou moins longtemps valide (en terme de contenu, car une pile est toujours valide en terme d'adresse).
un erreur typique permet d'éclairer le propos :
long * FonctionQuiFaitUneBetise(void) { long n=0x12345678; return &n; }
ici on marque la pile d'un long dont on connais le contenu (0x12345678) et on renvoie un pointeur dessus. ce pointeur (toujours valide) vous permet de vérifier le contenu de la pile à cette endroit, contenu qui sera modifié si vous appelez une fonction qui se sert des 4 prochains octet de la pile entre temps.
long * FonctionQuiFaitUneBetisePlusFine(void) { char sz[1024]=""; long n=0x12345678; return &n; }
suivant les déclarations des locales la valeur en pile peut rester valide plus longtemps. Ici on peut espérer que notre long sera déclaré dans la pile après les 1024 char de notre string. (on ne peut qu'espérer car c'est généralement le compilo 'c/c++' qui controle l'ordre de déclaration des locales... )
VB
-- Paul Bacelar MVP VC++
"Vincent Burel" <vincent.burel@nospam.wanadoo.fr> wrote in message
news:43d7a364$0$18314$8fcfb975@news.wanadoo.fr...
"Remi THOMAS" <remi@xtware.com> wrote in message
news:43d79c24$0$21351$626a54ce@news.free.fr...
"Olivier" écrivit
> Bonjour,
>
> J'ai un probleme avec les fonctions SetThreadContext et
> GetThreadContext
> sous Windows XP cela fonctionne
> mais sous Windows 2000 sur certains postes (apparemment du Pentium M
> 1.6
> GHz)
>
Le plus souvent c'est parceque la structure CONTEXT n'est pas crée au bon
endroit.
Tu fais un new ou c'est sur la pile.
Sur la pile il y a de forte chance que la structure ait disparue quand tu
y
accèdes.
La différence de comportement entre XP et 2000 c'est que sous XP
miraculeusement ton espace mémoire n'est pas écrasé après sa libération.
Sous 2000 oui.
la pile n'est jamais écrasé (le systeme n'a pas que ca à faire), elle est
Tu te trompes bien lourdement.
simplement utilisé... sous forme d'une pile. Les conséquences de cette
utilisation vont faire que les locales utilisées par une fonction seront
plus ou moins longtemps valide (en terme de contenu, car une pile est
toujours valide en terme d'adresse).
un erreur typique permet d'éclairer le propos :
long * FonctionQuiFaitUneBetise(void)
{
long n=0x12345678;
return &n;
}
ici on marque la pile d'un long dont on connais le contenu (0x12345678) et
on renvoie un pointeur dessus.
ce pointeur (toujours valide) vous permet de vérifier le contenu de la
pile
à cette endroit, contenu qui sera modifié si vous appelez une fonction qui
se sert des 4 prochains octet de la pile entre temps.
long * FonctionQuiFaitUneBetisePlusFine(void)
{
char sz[1024]="";
long n=0x12345678;
return &n;
}
suivant les déclarations des locales la valeur en pile peut rester valide
plus longtemps. Ici on peut espérer que notre long sera déclaré dans la
pile
après les 1024 char de notre string. (on ne peut qu'espérer car c'est
généralement le compilo 'c/c++' qui controle l'ordre de déclaration des
locales... )
"Vincent Burel" wrote in message news:43d7a364$0$18314$
"Remi THOMAS" wrote in message news:43d79c24$0$21351$
"Olivier" écrivit > Bonjour, > > J'ai un probleme avec les fonctions SetThreadContext et > GetThreadContext > sous Windows XP cela fonctionne > mais sous Windows 2000 sur certains postes (apparemment du Pentium M > 1.6 > GHz) >
Le plus souvent c'est parceque la structure CONTEXT n'est pas crée au bon endroit. Tu fais un new ou c'est sur la pile. Sur la pile il y a de forte chance que la structure ait disparue quand tu
y
accèdes. La différence de comportement entre XP et 2000 c'est que sous XP miraculeusement ton espace mémoire n'est pas écrasé après sa libération. Sous 2000 oui.
la pile n'est jamais écrasé (le systeme n'a pas que ca à faire), elle est
Tu te trompes bien lourdement.
simplement utilisé... sous forme d'une pile. Les conséquences de cette utilisation vont faire que les locales utilisées par une fonction seront plus ou moins longtemps valide (en terme de contenu, car une pile est toujours valide en terme d'adresse).
un erreur typique permet d'éclairer le propos :
long * FonctionQuiFaitUneBetise(void) { long n=0x12345678; return &n; }
ici on marque la pile d'un long dont on connais le contenu (0x12345678) et on renvoie un pointeur dessus. ce pointeur (toujours valide) vous permet de vérifier le contenu de la pile à cette endroit, contenu qui sera modifié si vous appelez une fonction qui se sert des 4 prochains octet de la pile entre temps.
long * FonctionQuiFaitUneBetisePlusFine(void) { char sz[1024]=""; long n=0x12345678; return &n; }
suivant les déclarations des locales la valeur en pile peut rester valide plus longtemps. Ici on peut espérer que notre long sera déclaré dans la pile après les 1024 char de notre string. (on ne peut qu'espérer car c'est généralement le compilo 'c/c++' qui controle l'ordre de déclaration des locales... )
VB
-- Paul Bacelar MVP VC++
Paul Bacelar
"Vincent Burel" wrote in message news:43d7a364$0$18314$
"Remi THOMAS" wrote in message news:43d79c24$0$21351$
"Olivier" écrivit > Bonjour, > > J'ai un probleme avec les fonctions SetThreadContext et > GetThreadContext > sous Windows XP cela fonctionne > mais sous Windows 2000 sur certains postes (apparemment du Pentium M > 1.6 > GHz) >
Le plus souvent c'est parceque la structure CONTEXT n'est pas crée au bon endroit. Tu fais un new ou c'est sur la pile. Sur la pile il y a de forte chance que la structure ait disparue quand tu
y
accèdes. La différence de comportement entre XP et 2000 c'est que sous XP miraculeusement ton espace mémoire n'est pas écrasé après sa libération. Sous 2000 oui.
la pile n'est jamais écrasé (le systeme n'a pas que ca à faire), elle est
Tu te trompes bien lourdement.
simplement utilisé... sous forme d'une pile. Les conséquences de cette utilisation vont faire que les locales utilisées par une fonction seront plus ou moins longtemps valide (en terme de contenu, car une pile est toujours valide en terme d'adresse).
un erreur typique permet d'éclairer le propos :
long * FonctionQuiFaitUneBetise(void) { long n=0x12345678; return &n; }
ici on marque la pile d'un long dont on connais le contenu (0x12345678) et on renvoie un pointeur dessus. ce pointeur (toujours valide) vous permet de vérifier le contenu de la pile à cette endroit, contenu qui sera modifié si vous appelez une fonction qui se sert des 4 prochains octet de la pile entre temps.
long * FonctionQuiFaitUneBetisePlusFine(void) { char sz[1024]=""; long n=0x12345678; return &n; }
suivant les déclarations des locales la valeur en pile peut rester valide plus longtemps. Ici on peut espérer que notre long sera déclaré dans la pile après les 1024 char de notre string. (on ne peut qu'espérer car c'est généralement le compilo 'c/c++' qui controle l'ordre de déclaration des locales... )
VB
-- Paul Bacelar
"Vincent Burel" <vincent.burel@nospam.wanadoo.fr> wrote in message
news:43d7a364$0$18314$8fcfb975@news.wanadoo.fr...
"Remi THOMAS" <remi@xtware.com> wrote in message
news:43d79c24$0$21351$626a54ce@news.free.fr...
"Olivier" écrivit
> Bonjour,
>
> J'ai un probleme avec les fonctions SetThreadContext et
> GetThreadContext
> sous Windows XP cela fonctionne
> mais sous Windows 2000 sur certains postes (apparemment du Pentium M
> 1.6
> GHz)
>
Le plus souvent c'est parceque la structure CONTEXT n'est pas crée au bon
endroit.
Tu fais un new ou c'est sur la pile.
Sur la pile il y a de forte chance que la structure ait disparue quand tu
y
accèdes.
La différence de comportement entre XP et 2000 c'est que sous XP
miraculeusement ton espace mémoire n'est pas écrasé après sa libération.
Sous 2000 oui.
la pile n'est jamais écrasé (le systeme n'a pas que ca à faire), elle est
Tu te trompes bien lourdement.
simplement utilisé... sous forme d'une pile. Les conséquences de cette
utilisation vont faire que les locales utilisées par une fonction seront
plus ou moins longtemps valide (en terme de contenu, car une pile est
toujours valide en terme d'adresse).
un erreur typique permet d'éclairer le propos :
long * FonctionQuiFaitUneBetise(void)
{
long n=0x12345678;
return &n;
}
ici on marque la pile d'un long dont on connais le contenu (0x12345678) et
on renvoie un pointeur dessus.
ce pointeur (toujours valide) vous permet de vérifier le contenu de la
pile
à cette endroit, contenu qui sera modifié si vous appelez une fonction qui
se sert des 4 prochains octet de la pile entre temps.
long * FonctionQuiFaitUneBetisePlusFine(void)
{
char sz[1024]="";
long n=0x12345678;
return &n;
}
suivant les déclarations des locales la valeur en pile peut rester valide
plus longtemps. Ici on peut espérer que notre long sera déclaré dans la
pile
après les 1024 char de notre string. (on ne peut qu'espérer car c'est
généralement le compilo 'c/c++' qui controle l'ordre de déclaration des
locales... )
"Vincent Burel" wrote in message news:43d7a364$0$18314$
"Remi THOMAS" wrote in message news:43d79c24$0$21351$
"Olivier" écrivit > Bonjour, > > J'ai un probleme avec les fonctions SetThreadContext et > GetThreadContext > sous Windows XP cela fonctionne > mais sous Windows 2000 sur certains postes (apparemment du Pentium M > 1.6 > GHz) >
Le plus souvent c'est parceque la structure CONTEXT n'est pas crée au bon endroit. Tu fais un new ou c'est sur la pile. Sur la pile il y a de forte chance que la structure ait disparue quand tu
y
accèdes. La différence de comportement entre XP et 2000 c'est que sous XP miraculeusement ton espace mémoire n'est pas écrasé après sa libération. Sous 2000 oui.
la pile n'est jamais écrasé (le systeme n'a pas que ca à faire), elle est
Tu te trompes bien lourdement.
simplement utilisé... sous forme d'une pile. Les conséquences de cette utilisation vont faire que les locales utilisées par une fonction seront plus ou moins longtemps valide (en terme de contenu, car une pile est toujours valide en terme d'adresse).
un erreur typique permet d'éclairer le propos :
long * FonctionQuiFaitUneBetise(void) { long n=0x12345678; return &n; }
ici on marque la pile d'un long dont on connais le contenu (0x12345678) et on renvoie un pointeur dessus. ce pointeur (toujours valide) vous permet de vérifier le contenu de la pile à cette endroit, contenu qui sera modifié si vous appelez une fonction qui se sert des 4 prochains octet de la pile entre temps.
long * FonctionQuiFaitUneBetisePlusFine(void) { char sz[1024]=""; long n=0x12345678; return &n; }
suivant les déclarations des locales la valeur en pile peut rester valide plus longtemps. Ici on peut espérer que notre long sera déclaré dans la pile après les 1024 char de notre string. (on ne peut qu'espérer car c'est généralement le compilo 'c/c++' qui controle l'ordre de déclaration des locales... )
VB
-- Paul Bacelar
Vincent Burel
"Paul Bacelar" wrote in message news:
Vous oubliez allégrement que votre processus peut être swappé, que son working-set peut évoluer réduisant la taille de la pile physiquement
alloué,
que toute page physique qui passe d'un process à un autre doit être misa à
0
(toute la page) dû au cahier des charges de l'armée américaine que
WindowsNT
respect depuis sa création.
Oui, Patrick à raison de dire que l'OS peut mettre à 0 les pages au-delà
du
sommet de la pile, et Non Vincent, l'OS fait bien des choses que le programme utilisateur ne voit pas ;-).
Au lieu de faire dans la condescendance, vous devriez faire l'expérience : Dans un thread quelconque, écrivez qqchose en pile (une phrase dans une chaine par exemple) à l'aide d'une fonction, et bouclez sur une autre fonction qui ne fera que lire cette pile... Ensuite rappelez nous quand le contenu à changé :-)
VB
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> wrote in message
news:erpjLqfIGHA.3904@TK2MSFTNGP10.phx.gbl...
Vous oubliez allégrement que votre processus peut être swappé, que son
working-set peut évoluer réduisant la taille de la pile physiquement
alloué,
que toute page physique qui passe d'un process à un autre doit être misa à
0
(toute la page) dû au cahier des charges de l'armée américaine que
WindowsNT
respect depuis sa création.
Oui, Patrick à raison de dire que l'OS peut mettre à 0 les pages au-delà
du
sommet de la pile, et Non Vincent, l'OS fait bien des choses que le
programme utilisateur ne voit pas ;-).
Au lieu de faire dans la condescendance, vous devriez faire l'expérience :
Dans un thread quelconque, écrivez qqchose en pile (une phrase dans une
chaine par exemple) à l'aide d'une fonction, et bouclez sur une autre
fonction qui ne fera que lire cette pile... Ensuite rappelez nous quand le
contenu à changé :-)
Vous oubliez allégrement que votre processus peut être swappé, que son working-set peut évoluer réduisant la taille de la pile physiquement
alloué,
que toute page physique qui passe d'un process à un autre doit être misa à
0
(toute la page) dû au cahier des charges de l'armée américaine que
WindowsNT
respect depuis sa création.
Oui, Patrick à raison de dire que l'OS peut mettre à 0 les pages au-delà
du
sommet de la pile, et Non Vincent, l'OS fait bien des choses que le programme utilisateur ne voit pas ;-).
Au lieu de faire dans la condescendance, vous devriez faire l'expérience : Dans un thread quelconque, écrivez qqchose en pile (une phrase dans une chaine par exemple) à l'aide d'une fonction, et bouclez sur une autre fonction qui ne fera que lire cette pile... Ensuite rappelez nous quand le contenu à changé :-)
VB
Vincent Burel
"Vincent Burel" wrote in message news:43d87a0d$0$6645$
"Paul Bacelar" wrote in message news: > Vous oubliez allégrement que votre processus peut être swappé, que son > working-set peut évoluer réduisant la taille de la pile physiquement alloué, > que toute page physique qui passe d'un process à un autre doit être misa
à
0 > (toute la page) dû au cahier des charges de l'armée américaine que WindowsNT > respect depuis sa création. > > Oui, Patrick à raison de dire que l'OS peut mettre à 0 les pages au-delà du > sommet de la pile, et Non Vincent, l'OS fait bien des choses que le > programme utilisateur ne voit pas ;-).
Au lieu de faire dans la condescendance, vous devriez faire l'expérience : Dans un thread quelconque, écrivez qqchose en pile (une phrase dans une chaine par exemple) à l'aide d'une fonction, et bouclez sur une autre fonction qui ne fera que lire cette pile... Ensuite rappelez nous quand le contenu à changé :-)
Comme j'ai peur que vous n'ayez pas les capacités de faire le petit programme de démonstration dont je vous parle, je me permets un exemple de code (ci-dessous) où la fonction "TestSiQQcToucheAMaPile" sort quand quelqu'un, ou quelque chose, ou l'armée américaine, ou un vent solaire, ou même un rayon télépathique, modifie le contenu de notre pile... Vous verrez d'ailleurs qu'aucune interruption ou task swapping ne modifie notre pile (car ce genre de chose n'est pas gérer par la pile d'un thread user, mais sans doute je ne vous apprend rien)...
static char machaine[]="Ma pile n'est jamais modifiée, sauf si je fais en sorte qu'elle le soit ";
void TestSiQQcToucheAMaPile(void) { long vi; char * lp; lp=WriteInStack(); while (1) { vi=0; while (machaine[vi]!=0) { if (lp[vi] != machaine[vi]) return; vi++; } } }
"Vincent Burel" <vincent.burel@nospam.wanadoo.fr> wrote in message
news:43d87a0d$0$6645$8fcfb975@news.wanadoo.fr...
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> wrote in message
news:erpjLqfIGHA.3904@TK2MSFTNGP10.phx.gbl...
> Vous oubliez allégrement que votre processus peut être swappé, que son
> working-set peut évoluer réduisant la taille de la pile physiquement
alloué,
> que toute page physique qui passe d'un process à un autre doit être misa
à
0
> (toute la page) dû au cahier des charges de l'armée américaine que
WindowsNT
> respect depuis sa création.
>
> Oui, Patrick à raison de dire que l'OS peut mettre à 0 les pages au-delà
du
> sommet de la pile, et Non Vincent, l'OS fait bien des choses que le
> programme utilisateur ne voit pas ;-).
Au lieu de faire dans la condescendance, vous devriez faire l'expérience :
Dans un thread quelconque, écrivez qqchose en pile (une phrase dans une
chaine par exemple) à l'aide d'une fonction, et bouclez sur une autre
fonction qui ne fera que lire cette pile... Ensuite rappelez nous quand le
contenu à changé :-)
Comme j'ai peur que vous n'ayez pas les capacités de faire le petit
programme de démonstration dont je vous parle, je me permets un exemple de
code (ci-dessous) où la fonction "TestSiQQcToucheAMaPile" sort quand
quelqu'un, ou quelque chose, ou l'armée américaine, ou un vent solaire, ou
même un rayon télépathique, modifie le contenu de notre pile... Vous verrez
d'ailleurs qu'aucune interruption ou task swapping ne modifie notre pile
(car ce genre de chose n'est pas gérer par la pile d'un thread user, mais
sans doute je ne vous apprend rien)...
static char machaine[]="Ma pile n'est jamais modifiée, sauf si je fais en
sorte qu'elle le soit ";
"Vincent Burel" wrote in message news:43d87a0d$0$6645$
"Paul Bacelar" wrote in message news: > Vous oubliez allégrement que votre processus peut être swappé, que son > working-set peut évoluer réduisant la taille de la pile physiquement alloué, > que toute page physique qui passe d'un process à un autre doit être misa
à
0 > (toute la page) dû au cahier des charges de l'armée américaine que WindowsNT > respect depuis sa création. > > Oui, Patrick à raison de dire que l'OS peut mettre à 0 les pages au-delà du > sommet de la pile, et Non Vincent, l'OS fait bien des choses que le > programme utilisateur ne voit pas ;-).
Au lieu de faire dans la condescendance, vous devriez faire l'expérience : Dans un thread quelconque, écrivez qqchose en pile (une phrase dans une chaine par exemple) à l'aide d'une fonction, et bouclez sur une autre fonction qui ne fera que lire cette pile... Ensuite rappelez nous quand le contenu à changé :-)
Comme j'ai peur que vous n'ayez pas les capacités de faire le petit programme de démonstration dont je vous parle, je me permets un exemple de code (ci-dessous) où la fonction "TestSiQQcToucheAMaPile" sort quand quelqu'un, ou quelque chose, ou l'armée américaine, ou un vent solaire, ou même un rayon télépathique, modifie le contenu de notre pile... Vous verrez d'ailleurs qu'aucune interruption ou task swapping ne modifie notre pile (car ce genre de chose n'est pas gérer par la pile d'un thread user, mais sans doute je ne vous apprend rien)...
static char machaine[]="Ma pile n'est jamais modifiée, sauf si je fais en sorte qu'elle le soit ";
void TestSiQQcToucheAMaPile(void) { long vi; char * lp; lp=WriteInStack(); while (1) { vi=0; while (machaine[vi]!=0) { if (lp[vi] != machaine[vi]) return; vi++; } } }
Bertrand Lenoir-Welter
Vincent Burel :
Comme j'ai peur que vous n'ayez pas les capacités de faire le petit programme de démonstration dont je vous parle, je me permets un exemple de code (ci-dessous) où la fonction "TestSiQQcToucheAMaPile" sort quand quelqu'un, ou quelque chose, ou l'armée américaine, ou un vent solaire, ou même un rayon télépathique, modifie le contenu de notre pile...
En fait, ça dépend si y'a des armes de destruction massive dans la pile.
Vincent Burel :
Comme j'ai peur que vous n'ayez pas les capacités de faire le petit
programme de démonstration dont je vous parle, je me permets un exemple de
code (ci-dessous) où la fonction "TestSiQQcToucheAMaPile" sort quand
quelqu'un, ou quelque chose, ou l'armée américaine, ou un vent solaire, ou
même un rayon télépathique, modifie le contenu de notre pile...
En fait, ça dépend si y'a des armes de destruction massive dans la pile.
Comme j'ai peur que vous n'ayez pas les capacités de faire le petit programme de démonstration dont je vous parle, je me permets un exemple de code (ci-dessous) où la fonction "TestSiQQcToucheAMaPile" sort quand quelqu'un, ou quelque chose, ou l'armée américaine, ou un vent solaire, ou même un rayon télépathique, modifie le contenu de notre pile...
En fait, ça dépend si y'a des armes de destruction massive dans la pile.
Paul Bacelar
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in message news:43d8e8cd$0$20184$
Vincent Burel :
Comme j'ai peur que vous n'ayez pas les capacités de faire le petit programme de démonstration dont je vous parle, je me permets un exemple de code (ci-dessous) où la fonction "TestSiQQcToucheAMaPile" sort quand quelqu'un, ou quelque chose, ou l'armée américaine, ou un vent solaire, ou même un rayon télépathique, modifie le contenu de notre pile...
En fait, ça dépend si y'a des armes de destruction massive dans la pile.
Et les deux clowns, pensez à lire les recommandations C2 de l'armée américaine que WinNT/200/XP/2003 respectent depuis WinNT3.x.
-- Paul Bacelar Microsoft MVP VC++
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in
message news:43d8e8cd$0$20184$8fcfb975@news.wanadoo.fr...
Vincent Burel :
Comme j'ai peur que vous n'ayez pas les capacités de faire le petit
programme de démonstration dont je vous parle, je me permets un exemple
de
code (ci-dessous) où la fonction "TestSiQQcToucheAMaPile" sort quand
quelqu'un, ou quelque chose, ou l'armée américaine, ou un vent solaire,
ou
même un rayon télépathique, modifie le contenu de notre pile...
En fait, ça dépend si y'a des armes de destruction massive dans la pile.
Et les deux clowns, pensez à lire les recommandations C2 de l'armée
américaine que WinNT/200/XP/2003 respectent depuis WinNT3.x.
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in message news:43d8e8cd$0$20184$
Vincent Burel :
Comme j'ai peur que vous n'ayez pas les capacités de faire le petit programme de démonstration dont je vous parle, je me permets un exemple de code (ci-dessous) où la fonction "TestSiQQcToucheAMaPile" sort quand quelqu'un, ou quelque chose, ou l'armée américaine, ou un vent solaire, ou même un rayon télépathique, modifie le contenu de notre pile...
En fait, ça dépend si y'a des armes de destruction massive dans la pile.
Et les deux clowns, pensez à lire les recommandations C2 de l'armée américaine que WinNT/200/XP/2003 respectent depuis WinNT3.x.
-- Paul Bacelar Microsoft MVP VC++
Paul Bacelar
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in message news:43d8e8cd$0$20184$
Vincent Burel :
Comme j'ai peur que vous n'ayez pas les capacités de faire le petit programme de démonstration dont je vous parle, je me permets un exemple de code (ci-dessous) où la fonction "TestSiQQcToucheAMaPile" sort quand quelqu'un, ou quelque chose, ou l'armée américaine, ou un vent solaire, ou même un rayon télépathique, modifie le contenu de notre pile...
En fait, ça dépend si y'a des armes de destruction massive dans la pile.
Et les deux clowns, pensez à lire les recommandations C2 de l'armée américaine que WinNT/200/XP/2003 respectent depuis WinNT3.x.
-- Paul Bacelar MVP VC++
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in
message news:43d8e8cd$0$20184$8fcfb975@news.wanadoo.fr...
Vincent Burel :
Comme j'ai peur que vous n'ayez pas les capacités de faire le petit
programme de démonstration dont je vous parle, je me permets un exemple
de
code (ci-dessous) où la fonction "TestSiQQcToucheAMaPile" sort quand
quelqu'un, ou quelque chose, ou l'armée américaine, ou un vent solaire,
ou
même un rayon télépathique, modifie le contenu de notre pile...
En fait, ça dépend si y'a des armes de destruction massive dans la pile.
Et les deux clowns, pensez à lire les recommandations C2 de l'armée
américaine que WinNT/200/XP/2003 respectent depuis WinNT3.x.
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in message news:43d8e8cd$0$20184$
Vincent Burel :
Comme j'ai peur que vous n'ayez pas les capacités de faire le petit programme de démonstration dont je vous parle, je me permets un exemple de code (ci-dessous) où la fonction "TestSiQQcToucheAMaPile" sort quand quelqu'un, ou quelque chose, ou l'armée américaine, ou un vent solaire, ou même un rayon télépathique, modifie le contenu de notre pile...
En fait, ça dépend si y'a des armes de destruction massive dans la pile.
Et les deux clowns, pensez à lire les recommandations C2 de l'armée américaine que WinNT/200/XP/2003 respectent depuis WinNT3.x.
-- Paul Bacelar MVP VC++
Arnold McDonald \(AMcD\)
Paul Bacelar wrote:
Et les deux clowns, pensez à lire les recommandations C2 de l'armée américaine que WinNT/200/XP/2003 respectent depuis WinNT3.x.
Malgré ton titre ronflant de MVP, je doute que tu puisses te croire habilité à insulter VB ou BLW qui sont parmi les intervenants les plus compétents ici. Surtout quand on lit le niveau de tes réponses. Si, si, relis-toi, tu verras les âneries que t'écris parfois en ces lieux.
PS : on en a rien à foutre que tu soies MVP. À quelques rares exceptions près, dont quelques-uns traînent parfois ici (Debaene, Astor, etc.), la grande majorité sont des guignols qui ne savent même pas ce qu'est un bit ! Je parle des MVP français bien sûr, pas des cadors américains. Alors, inutile de mentionner ton titre à tout va, on s'en cogne.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Paul Bacelar wrote:
Et les deux clowns, pensez à lire les recommandations C2 de l'armée
américaine que WinNT/200/XP/2003 respectent depuis WinNT3.x.
Malgré ton titre ronflant de MVP, je doute que tu puisses te croire habilité
à insulter VB ou BLW qui sont parmi les intervenants les plus compétents
ici. Surtout quand on lit le niveau de tes réponses. Si, si, relis-toi, tu
verras les âneries que t'écris parfois en ces lieux.
PS : on en a rien à foutre que tu soies MVP. À quelques rares exceptions
près, dont quelques-uns traînent parfois ici (Debaene, Astor, etc.), la
grande majorité sont des guignols qui ne savent même pas ce qu'est un bit !
Je parle des MVP français bien sûr, pas des cadors américains. Alors,
inutile de mentionner ton titre à tout va, on s'en cogne.
Et les deux clowns, pensez à lire les recommandations C2 de l'armée américaine que WinNT/200/XP/2003 respectent depuis WinNT3.x.
Malgré ton titre ronflant de MVP, je doute que tu puisses te croire habilité à insulter VB ou BLW qui sont parmi les intervenants les plus compétents ici. Surtout quand on lit le niveau de tes réponses. Si, si, relis-toi, tu verras les âneries que t'écris parfois en ces lieux.
PS : on en a rien à foutre que tu soies MVP. À quelques rares exceptions près, dont quelques-uns traînent parfois ici (Debaene, Astor, etc.), la grande majorité sont des guignols qui ne savent même pas ce qu'est un bit ! Je parle des MVP français bien sûr, pas des cadors américains. Alors, inutile de mentionner ton titre à tout va, on s'en cogne.
