Conversion string 64-32 bits

Bonjour à tous,

Je me lance, merci de me dire si mon vocabulaire n'est pas correct...

Je travaille sur une application (32 et 64bits) qui utilise l'UDP pour communiquer avec un autre programme (32bits).Le problème est le suivant:

sur un tcpdump, la trame UDP concernant un string passé en data depuis l'appli en 64bits est codé de cette manière :

Code:

---

0000 0000 0000 0007 424f 4e4a 4f55 52ff BONJOUR

---

Ce qui est normal je suppose.

Il me faut adapter mes string encodés sur 8bytes afin d'obtenir une 4bytes:

Code:

---

0000 0007 424f 4e4a 4f55 52ff BONJOUR

---

Je précise que l'appli compilée en 32bits ne pose pas de problème (évidemment) et le problème ne concerne que les chaines (string). le ff de la trame exemple concerne un booléen. J'ai pensé à une directive de compilation qui me permettrait de transformer mes chaines ??? ou peut-être un transtypage ???. N'ayant pas trouver de résultat sur le net (je sais que je ne cherche pas toujours au bon endroit !), je me tourne une nouvelle fois vers vous.

Merci par avance.

Bonjour ! Je ne sais pas ce que c'est qu'UDP ni tcpdump mais j'ai l'impression que vous faites une confusion (à moins que ce ne soit moi qui n'ai rien compris, ce qui est possible) entre la plateforme (Win32 ou Win64) et le type des chaînes. Il me semble que ça n'a rien à voir. :roll:

Bonjour,

Merci d'avoir répondu. Oui il est fort possible que je me soit emmêlé les pinceaux, je m'en excuse. En fait mon soucis ne se trouvait pas là où je l'attendais, comme souvent. Tcpdump est un sniffeur qui me permet de voir les trames TCP ou UDP qui passent sur un port particulier (celui qui m’intéresse !). Je travaille sur deux versions de dev, une pour les systèmes 32bits (Linux) et une pour 64bits sous Lazarus. Chaque version est en relation avec un autre logiciel (qui n'est pas de moi celui-là) et qui lui est issus du C++ (pour 32bits). Les deux logiciels sont en relation par l'intermédiaire d'un protocole UDP. Hors, les trames UDP fourni par l'une et l'autre version ne sont pas identiques, de ce fait l'un fonctionne (la version 32bits) et l'autre pas. C'est la rasion pour laquelle j'ai mis les trames incriminées qui montre la présence d'un octet supplémentaire au début de ligne (0000 0000), les data étant composés de 6 caractères. J'ai donc cru tout bêtement à un problème d'encodage des chaînes de caractères... Mais que neni... en fait l'erreur, se trouvait dans une fonction Pack() incluant un Length() mal utilisé.

Donc merci de nouveau de m'avoir répondu et je met le post en résolu, à moins qu'un admin veuille le supprimer...

Amitiés et désolé de méli-mélo