flat assembler
Message board for the users of flat assembler.

Index > Windows > "dll calling convention"

Author
Thread Post new topic Reply to topic
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
DustWolf
Hello,

I have created a simple string processing DLL in FASM and am trying to use it in a very high-level language (namely Visual Basic 6), however it complains about my choice of "dll calling convention". According to google, this means that my DLL is using some other calling convention than "__stdcall".

I don't recall defining a calling convention in any part of my code...

Code:
proc Find               textBuffer,queryBuffer,resultBuffer    


How do I convince that programming language that I am using the right convention?
Post 29 Sep 2006, 20:52
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost
When you have a DLLEXPORT it doesn't declare its convention, you declare that in the HLL Smile

basic "proc" with a "ret" in it is stdcall anyways.

_________________
redghost.ca
Post 29 Sep 2006, 22:40
View user's profile Send private message AIM Address MSN Messenger Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
RedGhost wrote:
basic "proc" with a "ret" in it is stdcall anyways.


wrong, you still have to preserve right registers,

Code:
;stdcall-calling convention is the default, other one that
;fasm macros support is cdecl-calling convention
proc StdCallProc uses esi edi ebx, params
;do something and return result in eax
;of course you can leave esi, edi or ebx out of 'uses *' if you dont use of them...
ret
endp    

_________________
When We Ride On Our Enemies
support reverse smileys |:
Post 30 Sep 2006, 13:55
View user's profile Send private message MSN Messenger Reply with quote
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
DustWolf
okasvi wrote:
you still have to preserve right registers,

Code:
proc StdCallProc uses esi edi ebx, params    


That works great for me, thanks! Smile
Post 30 Sep 2006, 16:01
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost
okasvi wrote:
RedGhost wrote:
basic "proc" with a "ret" in it is stdcall anyways.


wrong, you still have to preserve right registers,

Code:
;stdcall-calling convention is the default, other one that
;fasm macros support is cdecl-calling convention
proc StdCallProc uses esi edi ebx, params
;do something and return result in eax
;of course you can leave esi, edi or ebx out of 'uses *' if you dont use of them...
ret
endp    


Considering it is a proc for my own use, I normally don't bother Wink

Also, the register preserving is Windows specific and not specific to the stdcall convention. Which is platform independant.

_________________
redghost.ca
Post 30 Sep 2006, 18:12
View user's profile Send private message AIM Address MSN Messenger Reply with quote
UCM



Joined: 25 Feb 2005
Posts: 285
Location: Canada
UCM
Actually, register preserving *is* part of stdcall.
Post 30 Sep 2006, 21:09
View user's profile Send private message Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost
UCM wrote:
Actually, register preserving *is* part of stdcall.


Quote:

The stdcall[3] calling convention is the de facto standard calling convention for the Microsoft Windows NT application programming interface. Function parameters are passed right-to-left. Registers EAX, ECX, and EDX are preserved for use within the function. Return values are stored in the EAX register. Unlike cdecl, the called function cleans the stack, instead of the calling function. Because of this fact, stdcall functions cannot support variable-length argument lists.


All I see is that there is no promise that ecx, ecx, or edx will be preserved across the call, when infact esi, edi and ebx go unmentioned.

_________________
redghost.ca
Post 01 Oct 2006, 09:12
View user's profile Send private message AIM Address MSN Messenger Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
RedGhost wrote:
UCM wrote:
Actually, register preserving *is* part of stdcall.


Quote:

The stdcall[3] calling convention is the de facto standard calling convention for the Microsoft Windows NT application programming interface. Function parameters are passed right-to-left. Registers EAX, ECX, and EDX are preserved for use within the function. Return values are stored in the EAX register. Unlike cdecl, the called function cleans the stack, instead of the calling function. Because of this fact, stdcall functions cannot support variable-length argument lists.


All I see is that there is no promise that ecx, ecx, or edx will be preserved across the call, when infact esi, edi and ebx go unmentioned.

You shouldnt rely on wikipedia that much...

Quote:
Registers EAX, ECX, and EDX are preserved for use within the function. Return values are stored in the EAX register.
clearly means that function CAN(most likely WILL) trash ECX and EDX, and that EAX is used for return value... In other words, EBP, EBX, ESI, and EDI stay untouched, and those facts are part of STDCALL...

oh and I suggest reading http://www.agner.org/optimize/calling_conventions.pdf
especially part "6. Register Usage", it has an table that shows ebx, esi, edi, and ebp are 'callee-saves' registers in win32/linux/bsd/mac stdcall...

_________________
When We Ride On Our Enemies
support reverse smileys |:
Post 01 Oct 2006, 20:38
View user's profile Send private message MSN Messenger Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost
okasvi wrote:
RedGhost wrote:
UCM wrote:
Actually, register preserving *is* part of stdcall.


Quote:

The stdcall[3] calling convention is the de facto standard calling convention for the Microsoft Windows NT application programming interface. Function parameters are passed right-to-left. Registers EAX, ECX, and EDX are preserved for use within the function. Return values are stored in the EAX register. Unlike cdecl, the called function cleans the stack, instead of the calling function. Because of this fact, stdcall functions cannot support variable-length argument lists.


All I see is that there is no promise that ecx, ecx, or edx will be preserved across the call, when infact esi, edi and ebx go unmentioned.

You shouldnt rely on wikipedia that much...

Quote:
Registers EAX, ECX, and EDX are preserved for use within the function. Return values are stored in the EAX register.
clearly means that function CAN(most likely WILL) trash ECX and EDX, and that EAX is used for return value... In other words, EBP, EBX, ESI, and EDI stay untouched, and those facts are part of STDCALL...

oh and I suggest reading http://www.agner.org/optimize/calling_conventions.pdf
especially part "6. Register Usage", it has an table that shows ebx, esi, edi, and ebp are 'callee-saves' registers in win32/linux/bsd/mac stdcall...


ecx, edx and eax getting trashed is exactly what I said above..... "there is no promise they will get preserved..." and I've done enough reversing in my time to know that from HLL generation push ebx or push esi followed by a pop before return is something you rarely see (: Infact most winapi don't even do this.

_________________
redghost.ca
Post 01 Oct 2006, 20:52
View user's profile Send private message AIM Address MSN Messenger Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
umm, who said ecx, edx, and eax would get preserved? I thought we were having debate if ebp, ebx, esi, edi are preserved or not... I'd like to see an win32api func which trashes ebp, ebx, esi or edi....
Post 01 Oct 2006, 21:12
View user's profile Send private message MSN Messenger Reply with quote
Maverick



Joined: 07 Aug 2006
Posts: 251
Location: Citizen of the Universe
Maverick
RedGhost wrote:
..I've done enough reversing in my time to know that from HLL generation push ebx or push esi followed by a pop before return is something you rarely see (: Infact most winapi don't even do this.

If they don't is just because they do not modify those registers. There's no need to save/restore something you don't modify, research before making assumptions.

Or show some compiler generated code that trashes EBX or ESI, as you said above.

_________________
Greets,
Fabio
Post 02 Oct 2006, 05:28
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.