J'ai une question qui me traKsse avec MASM:
quand je declare un tampon comme cela:

buffer db 100 dup(0)

et dans le code, j'essaye d'ecrire dedans, avec une fonction comme strcpy ou instruction du type

mov byte ptr [buffer],ah

ou bien n'importe quelle fonction ou instruction qui ecrit dans une variable, eh bien j'obtiens un sympatique message de Windows 2000 me disant que "Access violation".
Es-ce normal? Seul windows2000 (et eventuellement NT) est-il sujet a cette limitation?
Ou bien tout simplement C moi ki sait pas faire?

Voila si quelqu'un peut m'aider j'en serais heureux

Je ne vois pas d'erreur dans ton code, en fait, je pense que tu as déclaré ton buffer dans le segment de code. Sous windows tu n'as pas le droit d'écrire dans un segment de code. Déclare plutôt ton buffer dans un autre segment, genre .data
Si c'est pas ça je vois pas de raisons pour qu'il y ait une violation d'acces

Bien sur!
Oui c'est bien dans mon genre de chercher des raisons compliquées alors que la solution est juste devant moi, tellement simple que je n'y ai meme pas fait attention!

Merci beaucoup, en effet, en declarant le truc dans .data ça marche bcp mieux!

Mais a propos, il n'y a AUCUN moyen sous Windows donc, de faire un programme qui ecrit dans son propre code? C'est nul, ça! J'avais deja pensé a faire un programme genre IA qui se change tout seul, mais sa va etre + compliqué que prévu apparemment...

Je t'en prie content de t'avoir aidé.

Effectivement c'est pas évident de faire du self-modifying code sous windows. C'est pas impossible, tu peux changer les permissions d'acces d'une zone mémoire avec la fonction VirtualProtect, mais personnellement j'ai jamais essayé.

Aucun probleme pour ecrire sur ton code comme sur celui d'un autre processus.
Va voir dans MDN:
OpenProcess(...), WriteProcessMemory(...).
BruNews, ciao...


-------------------------------
Réponse au message :
-------------------------------

> Bien sur!
> Oui c'est bien dans mon genre de chercher des raisons compliquées alors que la solution est juste devant moi, tellement simple que je n'y ai meme pas fait attention!
>
> Merci beaucoup, en effet, en declarant le truc dans .data ça marche bcp mieux!
>
> Mais a propos, il n'y a AUCUN moyen sous Windows donc, de faire un programme qui ecrit dans son propre code? C'est nul, ça! J'avais deja pensé a faire un programme genre IA qui se change tout seul, mais sa va etre + compliqué que prévu apparemment...

OK merci tt le monde

Mais ya un truc d'ordre general que je voudrais savoir:
quand je place une variable apres .data, et que j'utilise un debugger et que je regarde à l'adresse de cette variable, je me trouve face à un bloc de 4096 octets initialisés à 0, ou je peux librement ecrire;

Cette memoire est-elle la celebre memoire du "data segment"? (non, j'ai pas fait assez de theorie)
et si oui, c'est bizarre, on m'avait dit que dans le "flat memory mode", les donnees et le code etaient dans le meme segment. Or je ne peux pas ecrire sur mon code directement.

Et enfin, es-ce qu'on peut (facilement) augmenter cet espace?

Voili voilou, renseignez-moi merci!

La raison de pourquoi tu a un bloque de 4096 octet initialiser a zero, c'est parsque la mémoire et couper en bloque de 4 Ko
. La raison de c'est bloque c'est pour la pagination (c'est ce qui permet a un programme d'avoir un morceau de donner au millieu de la mémoire et la suite à la fin de la mémoire (par exemples), il que le programme voit les donnée comme si elle était continue)

"flat memory mode" tu a un segment qui donner le code et un qui donnée les donnée, mais tout deux peuvent pointer la même zone de mémoire. Tu a un segment dans CS et un dans DS. Ils peuvent être identique (sauf que celui de CS est un segment de code et celui de DS un segment de donnée, car en mode protégée ils sont distinc).

Pour augmenter l'espace des donnée tu fait un
buffer db 4097

au plus proprement
buffer db <La taille dont tu a besoin>

A+ (j'espére avoit été assez clair)