Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Environnement Microsoft acces memoire directe sous windows avec C++

acces memoire directe sous windows avec C++

79 réponses
Avatar
heinquoi
Bjr,

Ayant un probleme avec une fonction de CALLBACK et pour ne pas la citer
WndProc, j'ai chercher à acceder directement à la memoire, sans y parvenir
( sous dos nous avons la fameuse peekb ) mais sous win32 je n'y parvient
pas.
_comment acceder directement a la memoire virtuelle alloué au processus de
mon prog ?
_Et/ou acceder directement à la memoire virtuelle general ? ( genre dump)

et eventuellement, si un puriste avait trouvé la solution pour faire du vrai
C++ avec <Windows.h> et notament placer WndProc dans une classe. En tirer
son adresse sur un pointeur type WNDPROC, la ce serais vraiment NOEL pour
moi. ( j'ai le sentiment que les fonctions appartenant à un classe ne sont
pas constitué de la meme facon que les fonctions C: pointeur "this" peut
etre ?)

Ce probleme est récurant lorsque l'on se lance dans la programmation
windows.
DirectX par exemple ou APIWindows ne sont pas adapté au C++ a cause notament
de ces callback.
Votre avis ?
Cordialement
Heinquoi
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
4 5 6 7 8
Avatar
Aurélien REGAT-BARREL
> __int32 buffer = 'H' << 8*2 | 'A' << 8*1 | 'L' << 8*0 ;
for(int i=0;i<3;i++)
{
char c = (bufer | 0xFF) ;
Sleep(1) ;
putchar(--c) ;
buffer >>= 8 ;
}



i++

Mon dieu quelle horreur!
Avatar
adebaene
"Vincent Burel" wrote in message news:<c67obb$htg$...
"Arnaud Debaene" wrote in message
news:4086dc24$0$20145$
> Vincent Burel wrote:
>
> >
> > d'accord c'est clair... mais je ne vois pas l'utilité du côté
> > "dynamique" de la chose.
> > une seule wndproc de sousclassement suffit, d'utilisez le champ
> > GWL_USERDATA de la windows pour y stocker l'instance de l'objet
> > associé.
> Si tu utilises GWL_USERDATA, ce champ n'est plus disponible pour autre
> chose. Hors, quand tu écrits une librairie, il n'y a aucun moyen
d'empêcher
> un utilisateur de la lib de vouloir uiliser GWL_USERDATA pour ces propores
> besoins. C'est donc une solution plus fragile.

Ca sous entend que l'utilisateur n'est pas vous, et donc que vous avez des
clients ! n'est-ce pas un peu présomptueux de votre part ! ? :-)



Le gars qui s'amuse à coder un truc de cette importance pour nue appli
spécifique sans en faire une bibliothèque réutilisable n'est pas très
malin...


Trêve de plaisanterie, d'après ce que j'avais compris, c'était pour
interfacé de l'objet C++... Hors, a priori, l'objet ayant son objet, il n'a
aucune raison que l'utilisateur de l'objet ++ utilise ce champ... puisqu'il
a un objet...


Va dire çà à tous les utilisateurs des MFC ou bien des OWL ;-)

Ceci dit, vous avez raison, rien n'empêche l'utilisateur d'utiliser le champ
USERDATA... mais rien n'empêche non plus l'utilisateur de re-sous-classer
une fenêtre ou une classe...


Tout à fait, sauf que le gars qui sous-classe proprement une fenêtre,
il appelle la version de bae (càd le thunk) pour les messages qu'il ne
traite pas lui-même.

Arnaud
Avatar
AMcD®
Aurélien REGAT-BARREL wrote:

Mon dieu quelle horreur!



Meuh non !

long buffer = 0x48414C00;
__asm
{
mov ebx,buffer
zbub:
rol ebx,08h
inc ebx
push ebx
call putchar
cmp bl,4Dh
jne zbub
}

--
AMcD®

http://arnold.mcdonald.free.fr/
Avatar
Cyrille Szymanski
On 2004-04-22, AMcD® wrote:
Aurélien REGAT-BARREL wrote:

Mon dieu quelle horreur!



Meuh non !

long buffer = 0x48414C00;
__asm
{
mov ebx,buffer
zbub:
rol ebx,08h



pourquoi pas shl ?

inc ebx
push ebx
call putchar



Tu testes pas la valeur de retour de putchar ;-)

cmp bl,4Dh
jne zbub
}




--
cns
Avatar
Cyrille Szymanski
On 2004-04-22, Aurélien REGAT-BARREL wrote:

"AMcD®" a écrit dans le message de
news:4086b2e2$0$26994$

Puisque ça trolle, optimise un peu :o) :

const char * hal = "HAL";
int i = 0;
while ( hal[i]!= '' ) printf( "%c", hal[i++] + 1 );



Je laisse mon compilo le faire. Il s'en sort bien : listing pour la version



Tu trouves qu'il s'en sort bien ? Bof bof...
Regarde un peu le code qu'il te sort, c'est dégeu !



; HAL1
push ebp
mov ebp, esp
sub esp, 8
mov DWORD PTR _i$[ebp], 0



Là il met "int i" sur la pile. A quoi bon vu qu'on a assez de registres pour
le garder en immédiate...


$L613:
mov eax, DWORD PTR ?hal@@3PBDB ; hal
add eax, DWORD PTR _i$[ebp]



Ben oui, il calcule effectivement "hal+i", à chaque fois !

movsx ecx, BYTE PTR [eax]
test ecx, ecx
je SHORT $L610



mov edx, DWORD PTR ?hal@@3PBDB ; hal
add edx, DWORD PTR _i$[ebp]
movsx eax, BYTE PTR [edx]



Bon il recalcule le truc encore une fois...

add eax, 1




;---------------
mov BYTE PTR _c$615[ebp], al
movsx ecx, BYTE PTR _c$615[ebp]
;---------------
push ecx
push OFFSET FLAT:$SG616
call _printf
add esp, 8
mov edx, DWORD PTR _i$[ebp]
add edx, 1
mov DWORD PTR _i$[ebp], edx
jmp SHORT $L613



Wahou

$L610:
mov esp, ebp
pop ebp
ret 0



C'est quoi ton compilateur déjà ?

--
cns
Avatar
AMcD®
Cyrille Szymanski wrote:

long buffer = 0x48414C00;
__asm
{
mov ebx,buffer
zbub:
rol ebx,08h



pourquoi pas shl ?



Ben paske ça sort sinon...

--
AMcD®

http://arnold.mcdonald.free.fr/
Avatar
Aurélien REGAT-BARREL
> Tu trouves qu'il s'en sort bien ? Bof bof...
Regarde un peu le code qu'il te sort, c'est dégeu !



Je voulais souligner le gain quasi nul qu'apporte une optimisation du code C
vis à vis d'un code plus lisible, le code objet final étant quasiment
identique.

C'est quoi ton compilateur déjà ?



VS .Net 2003.
C'est la version Initiation, donc avec un bridage sur les optimisations.
Ce soir je testerais la différence avec ce que MS founit généreusement
depuis quelques jours (VC++ Toolkit 2003).

--
Aurélien REGAT-BARREL
Avatar
AMcD®
Cyrille Szymanski wrote:

Tu testes pas la valeur de retour de putchar ;-)



C'est mieux là ?

long buffer = 0x48414C00;

__asm
{
mov ebx,buffer
add ebx,01010100h
zbub:
rol ebx,08h
push ebx
call putchar
cmp eax,4Dh
jne zbub
}

--
AMcD®

http://arnold.mcdonald.free.fr/
Avatar
Cyrille Szymanski
On 2004-04-22, AMcD® wrote:
Cyrille Szymanski wrote:

Tu testes pas la valeur de retour de putchar ;-)



C'est mieux là ?



Je pense que la version avec ebx est meilleure :
là si putchar renvoie une erreur, eax sera jamais égal à 4Dh.

db hal 0x48, 0x41, 0x4C, 0x00

mov ebx, dword ptr hal ; on a ebx = 0x004C4148 pas vrai ?
add ebx, 0x00010101
push ebx ; je pense qu'en développant c'est plus rapide
call putchar
shr ebx, 0x08
push ebx
call putchar
shr ebx, 0x08
push ebx
call putchar
Avatar
Vincent Burel
"Arnaud Debaene" wrote in message
news:
"Vincent Burel" wrote in message


news:<c67obb$htg$...
> "Arnaud Debaene" wrote in message
> news:4086dc24$0$20145$
> > Vincent Burel wrote:
> >
> > >
> > > d'accord c'est clair... mais je ne vois pas l'utilité du côté
> > > "dynamique" de la chose.
> > > une seule wndproc de sousclassement suffit, d'utilisez le champ
> > > GWL_USERDATA de la windows pour y stocker l'instance de l'objet
> > > associé.
> > Si tu utilises GWL_USERDATA, ce champ n'est plus disponible pour autre
> > chose. Hors, quand tu écrits une librairie, il n'y a aucun moyen
> d'empêcher
> > un utilisateur de la lib de vouloir uiliser GWL_USERDATA pour ces


propores
> > besoins. C'est donc une solution plus fragile.
>
> Ca sous entend que l'utilisateur n'est pas vous, et donc que vous avez


des
> clients ! n'est-ce pas un peu présomptueux de votre part ! ? :-)

Le gars qui s'amuse à coder un truc de cette importance pour nue appli
spécifique sans en faire une bibliothèque réutilisable n'est pas très
malin...



oui, cependant, je ne vois pas en quoi une contrainte (et il y en a
toujours) : à savoir celle qui interdirait de se servir du champ USERDATA
d'un fenêtre HWND (ce qui ne pose aucun probleme sur une implémentation OO ,
étant donnée que ce USERDATA est justement là pour une implémentation OO et
qu'à partir du moment où on a mis l'engin sous forme d'objet, on peut
ajouter tous les champs qu'on veut... ) bref ce n'est pas parce qu'il y a
des contraintes, que la librairie n'est pas re-utilisable... par des tiers
en plus ! :-)

> Trêve de plaisanterie, d'après ce que j'avais compris, c'était pour
> interfacé de l'objet C++... Hors, a priori, l'objet ayant son objet, il


n'a
> aucune raison que l'utilisateur de l'objet ++ utilise ce champ...


puisqu'il
> a un objet...
Va dire çà à tous les utilisateurs des MFC ou bien des OWL ;-)



Des utilisateurs MFC / OWL qui connaissent l'existence de GWL_USERDATA ! :-)
pas possible !? :-)


> Ceci dit, vous avez raison, rien n'empêche l'utilisateur d'utiliser le


champ
> USERDATA... mais rien n'empêche non plus l'utilisateur de


re-sous-classer
> une fenêtre ou une classe...
Tout à fait, sauf que le gars qui sous-classe proprement une fenêtre,
il appelle la version de bae (càd le thunk) pour les messages qu'il ne
traite pas lui-même.



Et le gars qui utilise proprement votre lib OO d'interfacage Windows
n'utilisera pas le champ USERDATA... c'est tout :-)

VB
4 5 6 7 8