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
Arnaud Debaene
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.

Arnaud
Avatar
Cyrille Szymanski
On 2004-04-21, AMcD® wrote:
Cyrille Szymanski wrote:

AAAAAAh

printf() pour fficher un caractère ????



Bah quoi ? Tu veux putchar() ?




Tant qu'à faire :

const char * hal = "HAL";
int i=0;
while( hal[i]!=0 && putchar(hal[i++]+1)!=EOF );

voire si on veut faire un peu d'obfuscation :

char *p = "HAL";
while( *p && putchar(*p+++1)!=EOF );

ou tout simplement en C99 :

for(char*q="HAL";*q&&putchar(*q+++1)!=EOF;);

En voilà une belle signature, attends, je teste...

--
cns -- for(char*q="HAL";*q&&putchar(*q+++1)!=EOF;);
Avatar
AMcD®
Cyrille Szymanski wrote:

Tant qu'à faire :

const char * hal = "HAL";
int i=0;
while( hal[i]!=0 && putchar(hal[i++]+1)!=EOF );



Quelle horreur le EOF !

ou tout simplement en C99 :

for(char*q="HAL";*q&&putchar(*q+++1)!=EOF;);



MDR. À montrer dans toutes les écoles...

En voilà une belle signature, attends, je teste...



Rajoute un chtit Rot13 dessus, ça fera plus staïle.

--
AMcD®

http://arnold.mcdonald.free.fr/
Avatar
Vincent Burel
"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 ! ? :-)

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...

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... est-ce à dire que toute implentation ++ de
l'API Windows est fragile !? :-)

VB
Avatar
Aurélien REGAT-BARREL
"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
non optimisée :

; HAL1
push ebp
mov ebp, esp
sub esp, 8
mov DWORD PTR _i$[ebp], 0
$L613:
mov eax, DWORD PTR ?hal@@3PBDB ; hal
add eax, DWORD PTR _i$[ebp]
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]
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
$L610:
mov esp, ebp
pop ebp
ret 0

Ta version optimisée diffère seulement entre les ;-----------------:
;---------------
mov DWORD PTR tv72[ebp], eax
mov ecx, DWORD PTR tv72[ebp]
;---------------


Quit à optimiser, autant le faire jusqu'au bout :

#include <windows.h>

#pragma comment(linker,"/merge:.rdata=.data")
#pragma comment(linker,"/merge:.text=.data")
#pragma comment(linker,"/entry:main")
#pragma comment(linker,"/nodefaultlib")

const char * hal = "HAL";
int main()
{
DWORD msg = *((DWORD *)hal) + 0x00010101;
DWORD nb;
WriteFile(
GetStdHandle( STD_OUTPUT_HANDLE ),
&msg,
3,
&nb,
0 );

return 0;
}


Exe d'1 Ko...
Avatar
Vincent Burel
"Aurélien REGAT-BARREL" wrote in message
news:40879266$0$17596$

"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
non optimisée :




laisse moi faire plutot ! :-)

char p[4]="HAL";
long * lp=(long*)p;
*lp=*lp+0x00010101;

VB
Avatar
Aurélien REGAT-BARREL
> laisse moi faire plutot ! :-)

char p[4]="HAL";
long * lp=(long*)p;
*lp=*lp+0x00010101;



char p[4]="HAL";
*(long*)p += 0x00010101;

:-p

Mais tu triches. On part d'une string constante globale => section des
données initialisée => pas touche à la string !
Avatar
AMcD®
Aurélien REGAT-BARREL wrote:

Mais tu triches. On part d'une string constante globale => section des
données initialisée => pas touche à la string !



Tatata ! On optimise, donc on gaspille pas de place pour rien ;o). Elle me
plaît bien cette version moi.

--
AMcD®

http://arnold.mcdonald.free.fr/
Avatar
Aurélien REGAT-BARREL
> Tatata ! On optimise, donc on gaspille pas de place pour rien ;o). Elle me
plaît bien cette version moi.



Ca dépend ce qu'on veut optimiser : il faut bien du code pour initialiser le
tableau...et le code, c'est de l'espace mémoire + du temps CPU.
Avatar
Ambassadeur Kosh
>> Tatata ! On optimise, donc on gaspille pas de place pour rien ;o). Elle




me
plaît bien cette version moi.





trop gourmand encore. il y'a des indirections, et on ne beneficie pas de la
mise en registre pour p

char p[4]="HAL";
long * lp=(long*)p;
*lp=*lp+0x00010101;



__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 ;
}

le Sleep débloque du temps pour les autres taches. c'est important si on
veux etre temps reel.
il y a un buffer >>= 8 ; en trop. donc une version goto s'impose.
4 5 6 7 8