Stack

Question

Bonsoir, 

Je me pose une kestion :
Si au debut d'une fonction, je fais : 

lea edx, [esp - 32]
mov esp, edx
call CreateRectRgn

On est d'accord, la pile est relevée de 16 apres l'appel a l'api. Ma kestion est la suivante : est ke je peux recuperer les parametres passés a la fonction si je fais un mov eax, [esp - 4]...Etc ?

Merci d'avance

++

BruNews · Answer

bien entendu qu'on peut lire ou affecter [esp-4] etc...

Par contre je ne vois pas bien ou tu vas avec ta suite d'instructions, risque pas d'y avoir grand chose d'interessant sous ESP au retour d'1 API.

ciao...
BruNews, MVP VC++

cs_AlexMAN · Answer

jdois passer des parametres a une fonction, je dois ensuite utiliser ces params pour une autre fonction, d'ou ma kestion.
Si tu vois un autre moyen, jsuis preneur.

Merci ++

BruNews · Answer

alors PUSH les 2 fois, ils seront prets pour le second 'call'.

ciao...
BruNews, MVP VC++

cs_AlexMAN · Answer

Enfin jmré ton avis, est ce ke je peux transcrire ca en ayant des params ke sur la pile, pas de variables globales...

if (message == WM_PAINT) {
RECT rectPB;
PAINTSTRUCT ps;
HRGN hrgn;
HDC	 hdc;
COLORREF hdef = GetSysColor(COLOR_WINDOW);
char buf[64], *c;

GetClientRect(hwnd, &rectPB);
hdc = BeginPaint(hwnd, &ps);
hrgn = CreateRectRgn(rectPB.left, rectPB.top, rectPB.right, rectPB.bottom);
SelectClipRgn(hdc, hrgn);
SetBkMode(hdc, TRANSPARENT);
rectPB.top = (int)SendMessage(hwnd, PBM_GETPOS, 0, 0);
c = bnstrcpy(buf, szstate);
c = bnultoa(rectPB.top, c);*c++ '%'; *c 0;
rectPB.top = 100 - rectPB.top;
FillRect(hdc, &rectPB, GetSysColorBrush(COLOR_HIGHLIGHT));
DrawText(hdc, buf, strlen(buf), &rectPB, DT_VCENTER | DT_CENTER | DT_SINGLELINE);
EndPaint(hwnd, &ps);
DeleteObject(hrgn);
ReleaseDC(hwnd, hdc);
return 0;
}
return CallWindowProc(oldproc, hwnd, message, wparam, lparam);

J'ai essayé plusieurs code, en PUSHant directement la pile pour passer les params, mais nan, ca marche po, ca ménerve pask ca doit pas etre si compliké ke ca, en plus pas de VS.net donc jpeux pas tester en inline...putain de dimanche..

Merci Brunews

++

BruNews · Answer

A part 'szstate' qui semble etre une chaine globale, pour sur que tout cela se fait sur pile dans l'event WM_PAINT, aucun besoin de variables globales.
Prepare la structure de ta pile sur papier avant pour bien voir combien de place tu auras besoin. Utiliser registres avant tout, ne jamais relire en memoire plus d'1 fois si la valeur ne change pas.
Tres bon exercice.

ciao...
BruNews, MVP VC++

BruNews · Answer

OHE j'avais pas fait gaffe, y a une couille dans le potage.
A BeginPaint() doit correspondre EndPaint() et NON ReleaseDC().

ciao...
BruNews, MVP VC++

cs_AlexMAN · Answer

ok chef, jV mi mettre ce soir, les cours passeront apres...
Merci pour le ReleaseDC() inutile.

cs_AlexMAN · Answer

Ca marche !! A moitié, mais ca a le merite ne pas planter... :

PBProc		PROC
mov 	edi, [esp + 4]	;hwnd
mov 	ecx, [esp + 8]	;message
cmp 	ecx, WM_PAINT
je 		onPaint
push 	[esp + 16]
push 	[esp + 12]
push 	ecx
push 	edi
push 	oldproc
call 	CallWindowProc
jmp 	fin
onPaint:
lea 	esi, [esp - 152]
mov 	esp, esi
push 	esi 
push 	edi
call 	GetClientRect
lea 	ecx, [esi + 16]
push 	ecx
push 	edi
call 	BeginPaint
mov 	[esi + 144], eax
push 	[esi + 12]
push 	[esi + 8]
push 	[esi + 4]
push 	[esi]
call 	CreateRectRgn
mov 	[esi + 148], eax
push 	eax
push 	[esi + 144]
call 	SelectClipRgn
push 	TRANSPARENT
push	[esi + 144]
call 	SetBkMode
xor		ecx, ecx
push 	ecx
push 	ecx
push 	PBM_GETPOS
push 	edi
call 	SendMessage
mov 	ecx, 100
sub 	ecx, eax
mov 	[esi + 4], eax
invoke 	dwtoa, eax, addr buf
invoke 	MessageBox, 0, addr buf, 0, 0
push 	COLOR_HIGHLIGHT
call 	GetSysColorBrush
push 	eax
push 	esi
push 	[esi + 144]
call 	FillRect
mov 	ecx, DT_SINGLELINE
or 		ecx, DT_CENTER
or 		ecx, DT_VCENTER
push 	ecx
push 	esi
push 	6
push 	offset sztest
push 	[esi + 144]
call 	DrawText
push	[esi + 148]
call	DeleteObject
lea 	ecx, [esi + 16]
push 	ecx
push 	edi
call 	EndPaint
add		esp, 152
xor 	eax, eax
fin:
ret 	16
PBProc endp

Voila, bonne nuit, merci 

++

BruNews · Answer

PBProc PROC
mov edi, [esp + 4] ;hwnd

JAMAIS !!! Autres que EAX, ECX et EDX il faut TOUJOURS sauvegarder les registres avant de s'en servir afin de les restituer en sortie. Tu testes cela sur un win2K ou un winbebe et devrait planter.

PBProc PROC
mov ecx, [esp + 8] ;message
mov edx, [esp + 4] ;hwnd
cmp ecx, WM_PAINT
......
allait aussi bien sans toucher a EDI.

ciao...
BruNews, MVP VC++

cs_AlexMAN · Answer

Mais j'ai un pb apres, paskil me faut reutiliser hwnd, donc sil est ds edx, apres le premier appel a une fonction, sa valeur sera changée, et si je reprend hwnd sur la pile, yora un agi stall nan ?

cs_patatalo · Answer

salut,

rien que le début du post m'a fait frémir...

il est strictement interdit d'utiliser des adresses memoires en dessous de esp.

mov eax,[esp-4] est invalide, la moindre interruption provoquera la destruction de la variable et a n'importe quel moment.

la premiere variable sure est [esp].
mov eax,[esp] est valide.

mov eax,[ebp-4] je veux bien si ebp a une valeur adequate.

@++

BruNews · Answer

patatalo> nous sommes en mode protege ici, aucune interruption ni quoi que ce soit n'agira sur ton ESP pendant le temps de traitement de ta procedure. On peut tres bien lire ou affecter dessous tant qu'on ne sort pas de la proc et en sachant parfaitement ce que l'on fait. Tout ceci ne s'entend que pour preparer des params (par exemple) pour un appel externe qui va suivre sous peu et donc pour un temps tres court.
Il est clair que comme dit plus haut, des qu'un appel API ou autre func intervient, tout ce qui est sous ESP est perdu et il faut une certaine pratique pour jouer a cela.

ciao...
BruNews, MVP VC++

ToutEnMasm · Answer

Salut,
Des méthodes de codages a faire frémir un microprocesseur par refus d'utiliser les variables locales.
                                    ToutEnMasm

cs_AlexMAN · Answer

ToutEnMasm > C'est lorsk je regarde tes codes ke je fremis. Excuse moi mais un code asm ki utilise des .IF .ELSEIF, invoke et tout ce ke sen suit, faire du C est vachement mieux. Je ne critique pas du tt des connaissance, je n'oserais pas, mais l'asm n'est pas un langage de haut niveau, alors pkoi utiliser toutes les macros de masm ki ne sont la ke pour denaturer l'asm ? Perso, jveux pas, jle repete, autant faire du C.

++

ToutEnMasm · Answer

Salut,
Bonne remarque,je vois que tu as mis le doigt sur les évolutions majeurs du langage assembleur.
J'avais un peu délaissé , comme tout le monde , le langage assembleur du 8086 , chose que tu essayes de reprendre.
(L'adressage des variables locales se fait par EBP et non esp)

Je m'y suis remis avec masm.
Quels sont les nouveautés apportés par masm qui rendent de nouveau l'assembleur attractif ?,en voici quelques unes :

Le compilateur se charge de traduire et d'optimiser les séquences de codes les plus répétitives et les plus génératrices d'erreurs comme la constitution de variables locales avec leur adressage.
Nul besoin de faire des calculs (avec erreur ..) , la technologie existante depuis le 286 ( enter et leave ) associé a un compilateur capable de mettre en place le bon adressage fait gagner un temps énorme en écriture et en debuggage.

Les .IF introduit par masm sont également optimisés rendent simplement l'écriture plus lisible.

Regretter l'utilisation de invoke ou dire que l'on aime bien passer des heures a debugger est la même chose.
   
                                    ToutEnMasm

cs_patatalo · Answer

re,

c'est vrai que la pile system en PM est isolée des tache de niveau 3. ( autant pour moi, je fremis dans la poêlle, grillé ;-)

cela dit, je suis complètement d'accord avec ToutEnMasm d'autant que la question a poser pourrait etre inversée:
si il est si facile d'imiter la prog C avec Masm pourquoi programmer en C ?

@++

BruNews · Answer

patatalo > Reponse trop facile: parce qu'en C il y a un compilo pour optimiser et qui produit maintenant un ASM tres performant. Ceci n'est pas le cas de MASM32 qui n'a que des macros pour effectuer la translation du sabir en code, aucune analyse des AGI Stall ni quoi que ce soit d'autre. Si on ne le fait pas soi meme, un prog C sur VS 2003 en Release sera plus performant a tout coup.

ciao...
BruNews, MVP VC++

cs_patatalo · Answer

re,

a ce moment là, est-ce trop facile aussi de dire que ça ne sert que dans le cas ou le programmeur possede VS2003 ?

quand on parle C, on parle portabilité. Quand à l'optimisation, je demande quand même a voir le code généré.

@++

BruNews · Answer

La portabilite est une vaste plaisanterie, si on devait toujours se ramener a ce + petit commun denominateur, il n'y aurait que des progs console.
Le C permet une rapide maintenance du prog, voila son utilite.
VS est le compilo standard dans l'industrie donc pas de prob.
En ce qui concerne la qualite du code produit sur VS on peut faire des mesures si tu veux mais tu peux deja m'en croire, il est difficile de le battre sans beaucoup s'appliquer.

ciao...
BruNews, MVP VC++

cs_patatalo · Answer

re,

les logiciels linux tels que vlc ou autre sont portables windows, linux et sur plein d'autres systemes. Effectivement, ce n'est pas dynamique, il faut recompiler. Si toi tu prefere reprogrammer a chaque changement de system d'exploitation, c'est ton avis, les sociétés ne peuvent se le permettre surtout avec l'expansion du nombre de systems d'exploitation.
c grace a ce genre de philosophie que Windows est si dur a detrôner de son monopole.

2eme point, un programme ne se limite pas non plus a son interface graphique.

@++

Stack

24 réponses

Votre réponse

Discussions similaires