Converstion de type "jbyte" (java native interface) vers un "char" en C
9 réponses
Chat
Bonjour,
j'ai une methode native en JAVA, qui appelle une fonction en C.
Jusque la pas de souci, ça se complique lorsque la fonction en C
travaille sur un jbyte et elle doit communiquer cette var. a une autre
fonction dont le prototype attends un char.
Syntaxiquement je veux faire un cast sur un
const jbyte *str
pour le changer en
char *com
est ce qu'il y a moyen de faire ça??? sans scrasher la jvm
Thanks.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Régis Troadec
Salut,
"Chat" a écrit dans le message de news: 402b69ab$0$28130$
Bonjour, j'ai une methode native en JAVA, qui appelle une fonction en C. Jusque la pas de souci, ça se complique lorsque la fonction en C travaille sur un jbyte et elle doit communiquer cette var. a une autre fonction dont le prototype attends un char. Syntaxiquement je veux faire un cast sur un const jbyte *str
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian suivant la plate-forme (spec JNI).
pour le changer en char *com
char c'est pareil, c'est du 8 bits (CHAR_BIT = 8 (ou plus) dans <limits.h>) signé.
est ce qu'il y a moyen de faire ça??? sans scrasher la jvm
oui.
Sinon,
typedef char jbyte;
Thanks.
Salut,
"Chat" <chat@nospam.com> a écrit dans le message de news:
402b69ab$0$28130$626a14ce@news.free.fr...
Bonjour,
j'ai une methode native en JAVA, qui appelle une fonction en C.
Jusque la pas de souci, ça se complique lorsque la fonction en C
travaille sur un jbyte et elle doit communiquer cette var. a une autre
fonction dont le prototype attends un char.
Syntaxiquement je veux faire un cast sur un
const jbyte *str
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian
suivant la plate-forme (spec JNI).
pour le changer en
char *com
char c'est pareil, c'est du 8 bits (CHAR_BIT = 8 (ou plus) dans <limits.h>)
signé.
est ce qu'il y a moyen de faire ça??? sans scrasher la jvm
"Chat" a écrit dans le message de news: 402b69ab$0$28130$
Bonjour, j'ai une methode native en JAVA, qui appelle une fonction en C. Jusque la pas de souci, ça se complique lorsque la fonction en C travaille sur un jbyte et elle doit communiquer cette var. a une autre fonction dont le prototype attends un char. Syntaxiquement je veux faire un cast sur un const jbyte *str
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian suivant la plate-forme (spec JNI).
pour le changer en char *com
char c'est pareil, c'est du 8 bits (CHAR_BIT = 8 (ou plus) dans <limits.h>) signé.
est ce qu'il y a moyen de faire ça??? sans scrasher la jvm
oui.
Sinon,
typedef char jbyte;
Thanks.
Horst Kraemer
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" wrote:
Salut,
"Chat" a écrit dans le message de news: 402b69ab$0$28130$
Bonjour, j'ai une methode native en JAVA, qui appelle une fonction en C. Jusque la pas de souci, ça se complique lorsque la fonction en C travaille sur un jbyte et elle doit communiquer cette var. a une autre fonction dont le prototype attends un char. Syntaxiquement je veux faire un cast sur un const jbyte *str
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8 bits représenté en big-endian?
pour le changer en char *com
char c'est pareil, c'est du 8 bits (CHAR_BIT = 8 (ou plus) dans <limits.h>) signé.
char n'est pas nécessairement signé. Il y a des compilateurs où char est non signé par défaut (p. ex. WATCOM).
-- Horst
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" <regt@wanadoo.fr>
wrote:
Salut,
"Chat" <chat@nospam.com> a écrit dans le message de news:
402b69ab$0$28130$626a14ce@news.free.fr...
Bonjour,
j'ai une methode native en JAVA, qui appelle une fonction en C.
Jusque la pas de souci, ça se complique lorsque la fonction en C
travaille sur un jbyte et elle doit communiquer cette var. a une autre
fonction dont le prototype attends un char.
Syntaxiquement je veux faire un cast sur un
const jbyte *str
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian
suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8
bits représenté en big-endian?
pour le changer en
char *com
char c'est pareil, c'est du 8 bits (CHAR_BIT = 8 (ou plus) dans <limits.h>)
signé.
char n'est pas nécessairement signé. Il y a des compilateurs où char
est non signé par défaut (p. ex. WATCOM).
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" wrote:
Salut,
"Chat" a écrit dans le message de news: 402b69ab$0$28130$
Bonjour, j'ai une methode native en JAVA, qui appelle une fonction en C. Jusque la pas de souci, ça se complique lorsque la fonction en C travaille sur un jbyte et elle doit communiquer cette var. a une autre fonction dont le prototype attends un char. Syntaxiquement je veux faire un cast sur un const jbyte *str
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8 bits représenté en big-endian?
pour le changer en char *com
char c'est pareil, c'est du 8 bits (CHAR_BIT = 8 (ou plus) dans <limits.h>) signé.
char n'est pas nécessairement signé. Il y a des compilateurs où char est non signé par défaut (p. ex. WATCOM).
-- Horst
Régis Troadec
Salut,
"Horst Kraemer" a écrit dans le message de news:
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" wrote:
Salut,
"Chat" a écrit dans le message de news: 402b69ab$0$28130$
Bonjour, j'ai une methode native en JAVA, qui appelle une fonction en C. Jusque la pas de souci, ça se complique lorsque la fonction en C travaille sur un jbyte et elle doit communiquer cette var. a une autre fonction dont le prototype attends un char. Syntaxiquement je veux faire un cast sur un const jbyte *str
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian
suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8 bits représenté en big-endian?
Ah oui, tiens c'est con ça, c'est pas du multibyte, j'y avais pas pensé, désolé.
pour le changer en char *com
char c'est pareil, c'est du 8 bits (CHAR_BIT = 8 (ou plus) dans <limits.h>)
signé.
char n'est pas nécessairement signé. Il y a des compilateurs où char est non signé par défaut (p. ex. WATCOM).
-- Horst
Salut,
"Horst Kraemer" <horst.kraemer@epost.de> a écrit dans le message de news:
1fmq205ncmcplah55kqccru5jv3eeoqan8@4ax.com...
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" <regt@wanadoo.fr>
wrote:
Salut,
"Chat" <chat@nospam.com> a écrit dans le message de news:
402b69ab$0$28130$626a14ce@news.free.fr...
Bonjour,
j'ai une methode native en JAVA, qui appelle une fonction en C.
Jusque la pas de souci, ça se complique lorsque la fonction en C
travaille sur un jbyte et elle doit communiquer cette var. a une autre
fonction dont le prototype attends un char.
Syntaxiquement je veux faire un cast sur un
const jbyte *str
Un jbyte c'est du 8 bits signé, représenté en little-endian ou
big-endian
suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8
bits représenté en big-endian?
Ah oui, tiens c'est con ça, c'est pas du multibyte, j'y avais pas pensé,
désolé.
pour le changer en
char *com
char c'est pareil, c'est du 8 bits (CHAR_BIT = 8 (ou plus) dans
<limits.h>)
signé.
char n'est pas nécessairement signé. Il y a des compilateurs où char
est non signé par défaut (p. ex. WATCOM).
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" wrote:
Salut,
"Chat" a écrit dans le message de news: 402b69ab$0$28130$
Bonjour, j'ai une methode native en JAVA, qui appelle une fonction en C. Jusque la pas de souci, ça se complique lorsque la fonction en C travaille sur un jbyte et elle doit communiquer cette var. a une autre fonction dont le prototype attends un char. Syntaxiquement je veux faire un cast sur un const jbyte *str
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian
suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8 bits représenté en big-endian?
Ah oui, tiens c'est con ça, c'est pas du multibyte, j'y avais pas pensé, désolé.
pour le changer en char *com
char c'est pareil, c'est du 8 bits (CHAR_BIT = 8 (ou plus) dans <limits.h>)
signé.
char n'est pas nécessairement signé. Il y a des compilateurs où char est non signé par défaut (p. ex. WATCOM).
-- Horst
Emmanuel Delahaye
In 'fr.comp.lang.c', "Régis Troadec" wrote:
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian suivant la plate-forme (spec JNI).
Pour un objet de 8 bits, ça fait une différence ?
typedef char jbyte;
Si on veut du signé, il faut être explicite :
typedef signed char jbyte;
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', "Régis Troadec" <regt@wanadoo.fr> wrote:
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian
suivant la plate-forme (spec JNI).
Pour un objet de 8 bits, ça fait une différence ?
typedef char jbyte;
Si on veut du signé, il faut être explicite :
typedef signed char jbyte;
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" wrote:
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8 bits représenté en big-endian?
Le sens des bits (poids faible ou bit de signe alias poids fort d'abord).
Ce qui n'empêche pas que cela n'importe que pour une sérialisation, qui n'est probablement pas le problème ici. ;-)
Antoine
Jean-Marc Bourguet
"Antoine Leca" writes:
En , Horst Kraemer va escriure:
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" wrote:
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8 bits représenté en big-endian?
Le sens des bits (poids faible ou bit de signe alias poids fort d'abord).
Ce qui n'empêche pas que cela n'importe que pour une sérialisation, qui n'est probablement pas le problème ici. ;-)
<HS>
Cela importe aussi pour certaines instructions en assembleur, par exemple une qui renverrait le bit de poid le plus faible mais a 1.
Il faut aussi faire remarquer qu'on peut utiliser un sens pour les bit et un autres pour les bytes. En fait, on peut utiliser encore un autre ordre pour des unites de longueur superieure et arriver pour des entiers representes sur 4 bytes a un ordre qui n'est ni grand boutien, ni petit boutien (les premieres versions du compilateur C pour 8086 etaient dans ce cas).
Dans le meme genre de complication, si j'ai bonne memoire, le 68000 etait aussi assez amusant: grand boutien pour les bytes, petit boutien pour les bits d'apres la documentation mais certaines intructions utilisaient une numerotation des bits grand boutienne.
</HS>
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
"Antoine Leca" <root@localhost.gov> writes:
En 1fmq205ncmcplah55kqccru5jv3eeoqan8@4ax.com,
Horst Kraemer va escriure:
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" <regt@wanadoo.fr>
wrote:
Un jbyte c'est du 8 bits signé, représenté en little-endian ou
big-endian suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8
bits représenté en big-endian?
Le sens des bits (poids faible ou bit de signe alias poids fort d'abord).
Ce qui n'empêche pas que cela n'importe que pour une sérialisation,
qui n'est probablement pas le problème ici. ;-)
<HS>
Cela importe aussi pour certaines instructions en assembleur, par
exemple une qui renverrait le bit de poid le plus faible mais a 1.
Il faut aussi faire remarquer qu'on peut utiliser un sens pour les bit
et un autres pour les bytes. En fait, on peut utiliser encore un
autre ordre pour des unites de longueur superieure et arriver pour des
entiers representes sur 4 bytes a un ordre qui n'est ni grand boutien,
ni petit boutien (les premieres versions du compilateur C pour 8086
etaient dans ce cas).
Dans le meme genre de complication, si j'ai bonne memoire, le 68000
etait aussi assez amusant: grand boutien pour les bytes, petit boutien
pour les bits d'apres la documentation mais certaines intructions
utilisaient une numerotation des bits grand boutienne.
</HS>
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" wrote:
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8 bits représenté en big-endian?
Le sens des bits (poids faible ou bit de signe alias poids fort d'abord).
Ce qui n'empêche pas que cela n'importe que pour une sérialisation, qui n'est probablement pas le problème ici. ;-)
<HS>
Cela importe aussi pour certaines instructions en assembleur, par exemple une qui renverrait le bit de poid le plus faible mais a 1.
Il faut aussi faire remarquer qu'on peut utiliser un sens pour les bit et un autres pour les bytes. En fait, on peut utiliser encore un autre ordre pour des unites de longueur superieure et arriver pour des entiers representes sur 4 bytes a un ordre qui n'est ni grand boutien, ni petit boutien (les premieres versions du compilateur C pour 8086 etaient dans ce cas).
Dans le meme genre de complication, si j'ai bonne memoire, le 68000 etait aussi assez amusant: grand boutien pour les bytes, petit boutien pour les bits d'apres la documentation mais certaines intructions utilisaient une numerotation des bits grand boutienne.
</HS>
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pierre Maurette
"Horst Kraemer" a écrit ...
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" wrote:
Salut,
"Chat" a écrit dans le message de news: 402b69ab$0$28130$
Bonjour, j'ai une methode native en JAVA, qui appelle une fonction en C. Jusque la pas de souci, ça se complique lorsque la fonction en C travaille sur un jbyte et elle doit communiquer cette var. a une autre fonction dont le prototype attends un char. Syntaxiquement je veux faire un cast sur un const jbyte *str
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian
suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8 bits représenté en big-endian?
pour le changer en char *com
char c'est pareil, c'est du 8 bits (CHAR_BIT = 8 (ou plus) dans <limits.h>)
signé.
char n'est pas nécessairement signé. Il y a des compilateurs où char est non signé par défaut (p. ex. WATCOM).
Oui, et même un caractère n'est sémantiquement pas un entier, signé ou non. N'est-il pas souhaitable de conserver systématiquement char pour les caractères, et de définir les types numériques : typedef unsigned char ubyte; typedef signed char sbyte; (si ce n'est déjà fait dans un windef.h ou autre) Ainsi : typedef sbyte jbyte; (le choix des noms ubyte et sbyte est peut-être discutable) Pierre
"Horst Kraemer" <horst.kraemer@epost.de> a écrit ...
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" <regt@wanadoo.fr>
wrote:
Salut,
"Chat" <chat@nospam.com> a écrit dans le message de news:
402b69ab$0$28130$626a14ce@news.free.fr...
Bonjour,
j'ai une methode native en JAVA, qui appelle une fonction en C.
Jusque la pas de souci, ça se complique lorsque la fonction en C
travaille sur un jbyte et elle doit communiquer cette var. a une autre
fonction dont le prototype attends un char.
Syntaxiquement je veux faire un cast sur un
const jbyte *str
Un jbyte c'est du 8 bits signé, représenté en little-endian ou
big-endian
suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8
bits représenté en big-endian?
pour le changer en
char *com
char c'est pareil, c'est du 8 bits (CHAR_BIT = 8 (ou plus) dans
<limits.h>)
signé.
char n'est pas nécessairement signé. Il y a des compilateurs où char
est non signé par défaut (p. ex. WATCOM).
Oui, et même un caractère n'est sémantiquement pas un entier, signé ou non.
N'est-il pas souhaitable de conserver systématiquement char pour les
caractères, et de définir les types numériques :
typedef unsigned char ubyte;
typedef signed char sbyte;
(si ce n'est déjà fait dans un windef.h ou autre)
Ainsi :
typedef sbyte jbyte;
(le choix des noms ubyte et sbyte est peut-être discutable)
Pierre
On Sat, 14 Feb 2004 00:01:26 +0100, "Régis Troadec" wrote:
Salut,
"Chat" a écrit dans le message de news: 402b69ab$0$28130$
Bonjour, j'ai une methode native en JAVA, qui appelle une fonction en C. Jusque la pas de souci, ça se complique lorsque la fonction en C travaille sur un jbyte et elle doit communiquer cette var. a une autre fonction dont le prototype attends un char. Syntaxiquement je veux faire un cast sur un const jbyte *str
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian
suivant la plate-forme (spec JNI).
Quelle est la différence entre 8 bit représenté en little-endian et 8 bits représenté en big-endian?
pour le changer en char *com
char c'est pareil, c'est du 8 bits (CHAR_BIT = 8 (ou plus) dans <limits.h>)
signé.
char n'est pas nécessairement signé. Il y a des compilateurs où char est non signé par défaut (p. ex. WATCOM).
Oui, et même un caractère n'est sémantiquement pas un entier, signé ou non. N'est-il pas souhaitable de conserver systématiquement char pour les caractères, et de définir les types numériques : typedef unsigned char ubyte; typedef signed char sbyte; (si ce n'est déjà fait dans un windef.h ou autre) Ainsi : typedef sbyte jbyte; (le choix des noms ubyte et sbyte est peut-être discutable) Pierre
Chat
merci pour les infos mais est ce que je peux trouver sur le net un tableau avec tous les types de conversions de données pour passer d'un type C vers un type nativ ( je veux dire jQuelque chose) et vice versa. Mon gros probleme, c que j'ai tous le tps des conversions dans le genre a faire. Aujourd'hui mon souci c de passer d'un unsigned char * vers du jchar comment ça marche c histoire???? merci
In 'fr.comp.lang.c', "Régis Troadec" wrote:
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian suivant la plate-forme (spec JNI).
Pour un objet de 8 bits, ça fait une différence ?
typedef char jbyte;
Si on veut du signé, il faut être explicite :
typedef signed char jbyte;
merci pour les infos mais est ce que je peux trouver sur le net un
tableau avec tous les types de conversions de données pour passer d'un
type C vers un type nativ ( je veux dire jQuelque chose) et vice versa.
Mon gros probleme, c que j'ai tous le tps des conversions dans le genre
a faire.
Aujourd'hui mon souci c de passer d'un unsigned char * vers du jchar
comment ça marche c histoire????
merci
In 'fr.comp.lang.c', "Régis Troadec" <regt@wanadoo.fr> wrote:
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian
suivant la plate-forme (spec JNI).
merci pour les infos mais est ce que je peux trouver sur le net un tableau avec tous les types de conversions de données pour passer d'un type C vers un type nativ ( je veux dire jQuelque chose) et vice versa. Mon gros probleme, c que j'ai tous le tps des conversions dans le genre a faire. Aujourd'hui mon souci c de passer d'un unsigned char * vers du jchar comment ça marche c histoire???? merci
In 'fr.comp.lang.c', "Régis Troadec" wrote:
Un jbyte c'est du 8 bits signé, représenté en little-endian ou big-endian suivant la plate-forme (spec JNI).
Pour un objet de 8 bits, ça fait une différence ?
typedef char jbyte;
Si on veut du signé, il faut être explicite :
typedef signed char jbyte;
Emmanuel Delahaye
In 'fr.comp.lang.c', "Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:
Oui, et même un caractère n'est sémantiquement pas un entier, signé ou non. N'est-il pas souhaitable de conserver systématiquement char pour les caractères, et de définir les types numériques : typedef unsigned char ubyte; typedef signed char sbyte; (si ce n'est déjà fait dans un windef.h ou autre)
typedef unsigned char uchar; typedef signed char schar; typedef unsigned short ushort; typedef unsigned int uint; typedef unsigned long ulong;
/* structures ========================================================== */ /* internal public data ================================================ */ /* internal public functions =========================================== */ /* entry points ======================================================== */ /* public data ========================================================= */
#ifdef __cplusplus } #endif
#endif /* H_ED_TYPES_20030502125527 */
/* Guards added by GUARD (c) ED 2000-2003 Feb 14 2003 Ver. 1.5 */
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', "Pierre Maurette"
<mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:
Oui, et même un caractère n'est sémantiquement pas un entier, signé ou non.
N'est-il pas souhaitable de conserver systématiquement char pour les
caractères, et de définir les types numériques :
typedef unsigned char ubyte;
typedef signed char sbyte;
(si ce n'est déjà fait dans un windef.h ou autre)
In 'fr.comp.lang.c', "Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:
Oui, et même un caractère n'est sémantiquement pas un entier, signé ou non. N'est-il pas souhaitable de conserver systématiquement char pour les caractères, et de définir les types numériques : typedef unsigned char ubyte; typedef signed char sbyte; (si ce n'est déjà fait dans un windef.h ou autre)
