1. 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
2. RE: stdcall / cdecl -- please clarify
> Euphoria was designed to call __stdcall routines, not __cdecl.
Can somebody explain what a stdcall routine is vs. a cdecl routine? I
noticed some of this stuff when looking at the GLUT includes we have in
our
library. I want to understand what I'm getting into before I get into
it.
Thanks,
ck
3. RE: stdcall / cdecl -- please clarify
Matthew Lewis wrote:
>
>
> 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.
>
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: the Regex library that I noted a while back, and also the
SQL-Lite (I can't remember the exact name) library. I would love to be
using those, but this issue makes me wary -- plus I want to be able to
translate to C for distribution, which definitely doesn't work.
> > 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.
>
My knowledge of C is next to nothing. But I think maybe some bright
person around here could possibly make a "universal" dll wrapper where
you could pass the name of the "final" dll, the name of the function &
the arguments to the euMiddleMan (There. Now the project even has a
name.), which would in turn call that function using cdecl, get any
return values, and then return those back to the Euphoria program. This
could even support a variable number of arguments. Anybody want to
tackle it?
I could do it myself, but I'd have to learn C first, so it would take a
while.
OR -- maybe Euphoria itself could support this in the future? It seems
we are missing out on a lot of fast & powerful existing code over a
relatively minor issue...
> 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.
>
If I could get this working on the regex and sql C libs I noted above,
I'd be happy for the time being...
Andy Serpa
renegade at earthling.net
4. RE: stdcall / cdecl -- please clarify
> -----Original Message-----
> From: Andy Serpa [mailto:renegade at earthling.net]
> My knowledge of C is next to nothing. But I think maybe some bright
> person around here could possibly make a "universal" dll
> wrapper where
> you could pass the name of the "final" dll, the name of the
> function &
> the arguments to the euMiddleMan (There. Now the project even has a
> name.), which would in turn call that function using cdecl, get any
> return values, and then return those back to the Euphoria
> program. This
> could even support a variable number of arguments. Anybody want to
> tackle it?
>
> I could do it myself, but I'd have to learn C first, so it
> would take a
> while.
>
> OR -- maybe Euphoria itself could support this in the future?
> It seems
> we are missing out on a lot of fast & powerful existing code over a
> relatively minor issue...
I've been working with Euman to convert my fptr.e to handle cdecl (at least
for callbacks). I think I know how to call cdecl routines as well using Eu
and a little bit of asm.
Matt Lewis
5. RE: stdcall / cdecl -- please clarify
While trying to figure this out, I ran across this:
BCX -- Basic to C translator
http://bcx.basicguru.com/
It looks pretty cool, and will allow me to make wrapper dll's in a snap
(it seems -- haven't done it yet), and I *still* don't have to learn any
C. I love it.
Apparently, my "universal" idea won't work though, because there isn't a
way to dynamically declare which .dll you're going to be calling.
I'm going to try to make a wrapper dll for the SQLite & Regex libraries
(which crash now if you use the translator). If I mirror the function
names exactly, all it should entail is changing the name of the dll in
the Euphoria wrapper functions. I'll let you know how it goes...
6. RE: stdcall / cdecl -- please clarify
Robert Craig wrote:
>
> 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.
How long is "__cdecl" going to be a viable interface? :)
And what's with the underscores?!?! sheesh good golly!!!
7. RE: stdcall / cdecl -- please clarify
Robert Craig wrote:
> 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.
>
>
Cool. Glad to hear it. Having the programmer (me) simply specify the
calling convention is good enough, but auto-detecting would be nice too
(maybe it could detect *other* calling conventions too -- fastcall, etc.
and generate an error if it ain't going to work)...
