Comportement bizarre de CopyMemoryRésolu

Question

Bonjours à tous.

Voici ma question:

j'ai voulu utiliser l'API COPYMEMORY pour transférer rapidement un tableau de Bytes dans un tableau de Longs. Bien sûr j'ai fait en sorte que la taille du tableau de Bytes soit 4 fois plus grande que celle du tableau de Longs. Par exemple j'ai un tableau de 32 Bytes que je veux transférer dans un tableau de 8 Longs (32 octets). 

Le transfert s'effectue. Mais je trouve la chose étrange. Alors je simplifie et tente de transférer ce tableau:

tByte(1) = 8   soit  00001000
tByte(2) = 4   soit  00000100   
tByte(3) = 1   soit  00000001
tByte(4) = 9   soit  00001001

vers ce Long lDest  avec l'API   COPYMEMORY lDest, tByte(1), 4

La copie s'effectue MAIS je retrouve dans le Long la valeur 151061512 ce qui correspond en binaire à

1001000000010000010000001000  soit octet par octet  9148 !! La valeur du tableau de Byte à l'envers.

POURQUOI DONC ?

Votre aide sera la bienvenue. D'avance merci.

mJuJu

cs_Galain · Accepted Answer

Salut 

comme dit DARKSIDIOUS Windows stocke les mots de 16 bits et les double-mots de 32 bits à l'envers

Soit la valeur 32 bits   04030201        soit en héxa &H4321

Windows la stocke ainsi à l'adresse mémoire ADR : 01   ' poids faibles en premier
                                                                    ADR +1 : 02
                                                                    ADR +2 : 03
                                                                    ADR +3 : 04  ' poids forts en dernier

par contre il n'y a aucune inversion de bits : c'est une inversion des octets

Autre chose : des bytes ce sont des bytes et des long ce sont des long : à ne pas mélanger car les longs peuvent être négatifs alors que les bytes non

GRENIER Alain

cs_DARKSIDIOUS · Answer

Salut,

Je m'y connais pas assez en système pour être catégorique, mais je dirais que cela ;vient du mode de stockage de windows en mémoire : avec les little-endian et high-endian, selon le mode utilisé, la réprésentation d'un WORD en mémoire est différente (inversion ou non des bits). Je laisse les experts confirmer ou infirmer mes propos !
______________________________________
DarK Sidious

cs_Galain · Answer

Si tu veux garder ce type de fonctionnement
Avant le copymemory inverse les bytes 2 à 2 (Byte1 avec Byte 4 et Byte2 avec Byte3)

dim temp as byte

temp = tByte(1)
tByte(1) =tByte(4)
tByte(4) = temp
temp = tByte(2)
tByte(2) = tByte(3)
tByte(2)= temp
COPYMEMORY lDest, tByte(1), 4

GRENIER Alain

cs_Galain · Answer

dim temp as byte

temp = tByte(1)
tByte(1) =tByte(4)
tByte(4) = temp
temp = tByte(2)
tByte(2) = tByte(3)
tByte(3)= temp       ' erreur dans le post précédent
COPYMEMORY lDest, tByte(1), 4

GRENIER Alain

cs_ghuysmans99 · Answer

@ [auteur/GALAIN/192155.aspx Galain] : Dans ce cas, c'est d'un bit que tu parles, pas d'un byte (octet)
_______________________________________________________________________
VB.NETis good ...VB6is better

cs_Galain · Answer

Salut ghuysmans99

DARKSIDIOUS avait marqué (inversion ou non des bits) alors que c'est une inversion des octets

VB.NET and VB6 are good : moi je prends les 2 

GRENIER Alain

cs_ghuysmans99 · Answer

Nan ... Exemple : 1011 (base 2) fait 11 (base 10).
Quand je dis 'bit', je veux parler des 1 et des 0, en binaire (base 2)
Un byte c'est un nombre de 0 à 255 inclus
_______________________________________________________________________
VB.NETis good ...VB6is better

Renfield · Answer

ce sont bel et bien les octets (bytes) qui sont inversés.

cs_ghuysmans99 · Answer

OOps ... C'est juste !
_______________________________________________________________________
VB.NETis good ...VB6is better

Comportement bizarre de CopyMemory

9 réponses

Votre réponse

Discussions similaires