RE: stdcall / cdecl -- please clarify
Andy Serpa wrote:
> 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?
You'll have this problem in Eu regardless. Every Eu call is stdcall.
> 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?
I've done something similar by wrapping a dll with another, hand coded c dll
that simply passes the calls through using cdecl. It should be fairly easy
to implement, assuming a little bit of c knowledge.
And then Euman wrote:
> 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.
So you implemented the asm I posted, and had the dll call the asm which
called your function? Can you tell me what happened? I haven't had a
chance to test any of that (just know that it works for stdcall). Maybe
I'll work up a little DLL and dissasemble it to get an idea for how cdecl
code looks. Looking at the code I posted before, I'm sure that there's more
messing with the stack early on. I think I can rework both pieces of asm to
call/be called by cdecl.
Matt Lewis
|
Not Categorized, Please Help
|
|
