1. stdcall / cdecl -- please clarify
Hello,
Regarding the problem with calling functions using cdecl in .dll files:
I am not a C programmer, so this is not completely clear to me. Will
the corruption/errors only occur when using the Translator? If I use
the interpreter with these .dll's, do I have no worries?
Can this problem be gotten around by using the Translator with Watcom
for my Euphoria programs, or is it the .dll that needs to be altered?
(I believe the latter, but I'm not positive.)
Would it be possible to make a simple "intermediate" C program or .dll
that is called with stdcall, which then in turn calls the desired .dll
using cdecl? In other words, my Euphoria program calls a function in a
.dll using stdcall. That fuction calls the 2nd .dll using cdecl.
Would this slow things down?
Andy Serpa
renegade at earthling.net
2. Re: stdcall / cdecl -- please clarify
- Posted by euman at bellsouth.net
Feb 12, 2002
----- Original Message -----
From: "Andy Serpa" <renegade at earthling.net>
>
> Hello,
>
> Regarding the problem with calling functions using cdecl in .dll files:
>
> I am not a C programmer, so this is not completely clear to me. Will
> the corruption/errors only occur when using the Translator? If I use
> the interpreter with these .dll's, do I have no worries?
>
> Can this problem be gotten around by using the Translator with Watcom
> for my Euphoria programs, or is it the .dll that needs to be altered?
> (I believe the latter, but I'm not positive.)
>
> Would it be possible to make a simple "intermediate" C program or .dll
> that is called with stdcall, which then in turn calls the desired .dll
> using cdecl? In other words, my Euphoria program calls a function in a
> .dll using stdcall. That fuction calls the 2nd .dll using cdecl.
> Would this slow things down?
>
>
> Andy Serpa
> renegade at earthling.net
This is an intersting subject and one Im struggling with aswell.
I tried to use a method presented by Matt Lewis on a cdecl .dll
and it doesnt work still if the .dll is designed for call_backs to
your program. Im guessing this might have something to do with
non-reintrant Euphoria. I just dont know.
I hope Robert clears this up in the future...
Euman
euman at bellsouth.net
3. Re: stdcall / cdecl -- please clarify
Andy Serpa writes:
> Regarding the problem with calling functions using cdecl in .dll files:
>
> I am not a C programmer, so this is not completely clear to me. Will
> the corruption/errors only occur when using the Translator? If I use
> the interpreter with these .dll's, do I have no worries?
> Can this problem be gotten around by using the Translator with Watcom
> for my Euphoria programs, or is it the .dll that needs to be altered?
> (I believe the latter, but I'm not positive.)
Euphoria was designed to call __stdcall routines, not __cdecl.
However, I noticed that the interpreter (compiled by Watcom), as well as
Translated code compiled by Watcom, can handle almost all
calls to __cdecl routines. This is due to the way that Watcom generates
code for handling the stack pointer. It's really just by luck that this works,
and I suspect it won't work if you try to pass or receive C doubles.
Most calls however use C integers and C pointers.
> Would it be possible to make a simple "intermediate" C program or .dll
> that is called with stdcall, which then in turn calls the desired .dll
> using cdecl? In other words, my Euphoria program calls a function in a
> .dll using stdcall. That fuction calls the 2nd .dll using cdecl.
Yes, that should work fine.
> Would this slow things down?
It will slow things down slightly.
The question is whether you will notice the slow down.
If you are calling WIN32 GUI routines, you won't notice it at all.
For it to be noticable, you'd have to be calling C routines
that do almost nothing before returning.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: stdcall / cdecl -- please clarify
C.K. Lester writes:
> Can somebody explain what a stdcall routine is vs. a cdecl routine?
In the beginning, Microsoft created
the __stdcall "standard call" calling convention for C subroutines.
Later, ANSI C and C++ decided to support the
passing of variable numbers of arguments to routines.
i.e. one call to foo() might pass 3 arguments, while another
call to foo() passes 6 arguments.
The problem was __stdcall couldn't handle variable numbers
of arguments, because in __stdcall, the subroutine is required
to pop the arguments off the stack at the end of a call, but with variable
numbers of args it can't always be sure how many arguments
were passed, so it doesn't know how many to pop.
Only the caller knows for sure how many arguments were passed,
so the caller must adjust the stack pointer register.
This led to the __cdecl calling convention, where the caller gets to
pop the arguments. Unfortunately, tons of code was already "out there"
that used __stdcall, in particular all those Windows apps that call the
WIN32 API.
So now Windows C programmers have to be aware
of two different calling conventions, and just to make it more
obscure, there are usually alternate names defined for these
calling conventions, such as EXPORT or WINAPI or CALLBACK
or whatever.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: stdcall / cdecl -- please clarify
- Posted by euman at bellsouth.net
Feb 13, 2002
Let me know if you recieve an attachment from me regarding
cdecl...
Euman
euman at bellsouth.net
6. Re: stdcall / cdecl -- please clarify
Andy Serpa writes:
> Hmmm... that means that even though the interpreter "luckily" can handle
> these things, it means we are on shaky ground for a number of powerful C
> libraries:
In the next release, there will be a solution to this.
Ideally, Euphoria would somehow figure out if a __cdecl call
is required, but if that's not feasible, the Euphoria programmer
will be given some means to specify which C routines need
__cdecl. Or, perhaps Matthew Lewis will come up with a clever solution.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
