1. cdecl support
For Matt Lewis and/or Euman: Did you guys come up with a relatively
clean solution for defining cdecl callbacks?
For Robert Craig: How long before a 2.4 alpha with cdecl support?
For anybody with source: Anybody willing to build me a PD interpreter
with cdecl support? I'm getting frustrated without it.
Thanks,
-- Brian
2. Re: cdecl support
- Posted by euman at bellsouth.net
Feb 25, 2002
Hi Brian
I gave up about a week ago trying to get it to work properly.
I tried Matts routines, Mic has some routines in his GLU project
and some of my own routines that never seemed to work right.
I can get handles to the Euphoria routine but when a .dll requires
that these routines (Eu routines) be cdecl also, I threw up my hands.
I too would like a work around cause I wanted to use cabinet.dll
to extract files from compressed MS-Cab's.
Euman
euman at bellsouth.net
Q: Are we monetarily insane?
A: YES
----- Original Message -----
From: "Brian Broker" <bkb at cnw.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, February 25, 2002 3:16 PM
Subject: cdecl support
>
> For Matt Lewis and/or Euman: Did you guys come up with a relatively
> clean solution for defining cdecl callbacks?
>
> For Robert Craig: How long before a 2.4 alpha with cdecl support?
>
> For anybody with source: Anybody willing to build me a PD interpreter
> with cdecl support? I'm getting frustrated without it.
>
> Thanks,
> -- Brian
>
>
>
>
3. Re: cdecl support
- Posted by euman at bellsouth.net
Feb 25, 2002
I was trying to follow the CAB file SDK.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q310618
I wanted wrappers written in Euphoria bypassing everything but the cabinet.dll
file
Euman
euman at bellsouth.net
Q: Are we monetarily insane?
A: YES
----- Original Message -----
From: "Brian Broker" <bkb at cnw.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, February 25, 2002 4:10 PM
Subject: RE: cdecl support
>
> I looked at Mic's routines but they left me confused and it looked like
> a bit of a hack job.
>
> For working with cab files, you might want to look into the Setup API:
>
> >From SDK:
> You can extract files from a cabinet in two ways. The first and simplest
> way is to take advantage of the automatic cabinet processing built into
> the setup functions.
>
> <snipped details>
>
> The second way to extract files from a cabinet is by using
> SetupIterateCabinet. This function iterates through each file in a
> cabinet, sending a notification to a callback routine for each file
> found. The callback routine then returns a value that indicates whether
> the file should be extracted or skipped.
>
> I haven't used them myself but I don't think they require cdecl calls
> (being Windows CALLBACKs and all...)
>
> -- Brian
>
> Euman wrote:
> > Hi Brian
> >
> > I gave up about a week ago trying to get it to work properly.
> > I tried Matts routines, Mic has some routines in his GLU project
> > and some of my own routines that never seemed to work right.
> >
> > I can get handles to the Euphoria routine but when a .dll requires
> > that these routines (Eu routines) be cdecl also, I threw up my hands.
> >
> > I too would like a work around cause I wanted to use cabinet.dll
> > to extract files from compressed MS-Cab's.
> >
> > Euman
> > euman at bellsouth.net
> >
> > Q: Are we monetarily insane?
> > A: YES
> > ----- Original Message -----
> > From: "Brian Broker" <bkb at cnw.com>
> > To: "EUforum" <EUforum at topica.com>
> > Sent: Monday, February 25, 2002 3:16 PM
> > Subject: cdecl support
> >
> >
> > > For Matt Lewis and/or Euman: Did you guys come up with a relatively
> > > clean solution for defining cdecl callbacks?
> > >
> > > For Robert Craig: How long before a 2.4 alpha with cdecl support?
> > >
> > > For anybody with source: Anybody willing to build me a PD interpreter
> > > with cdecl support? I'm getting frustrated without it.
> > >
> > > Thanks,
> > > -- Brian
> > >
> > >
>
>
>
4. Re: cdecl support
Brian Broker writes:
> For Robert Craig: How long before a 2.4 alpha with cdecl support?
I don't know. It depends on how long it takes to accumulate
enough bug fixes and new features to justify the (considerable)
overhead of doing a release. It could be 3 months to a year I suppose.
> For anybody with source: Anybody willing to build
> me a PD interpreter with cdecl support? I'm getting
> frustrated without it.
A quick hack could be easily done by someone with the source
to create a second form of c_proc() and c_func() that would
use a cdecl call. I don't have time to do quick hacks for one person
or a few people. I'd like to find the best long-term solution.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: cdecl support
I suppose some enterprising person could write a "conversion" DLL. One that
accepts Euphoria
parameters, passes them onto the _cdecl routine and returns the _cdecl results
to Euphoria?
I have no idea if this is possible or how hard it might be; just a thought.
6. Re: cdecl support
Andy Serpa writes:
> How would the long-term solution be different from
> this "quick hack" -- isn't that all we need?
I'd like to do some research before I implement
a solution to _cdecl. For instance, I'd be happier
if Euphoria could detect the need for cdecl, rather
than having the programmer worry about it.
Adding "quick hack" solutions to a programming
language is easy. Removing those quick hacks once
people start to use them is extremely difficult.
I don't want Euphoria to accumulate a lot of quick hacks
that are later made obsolete when a better solution
is implemented.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: cdecl support
- Posted by euman at bellsouth.net
Feb 26, 2002
"Matthew Lewis" <matthewwalkerlewis at YAHOO.COM>
wrote:
> I finally had some time to look at the problem in detail. I've got cdecl
> callbacks to Euphoria working (ie, you can call Eu routines using cdecl),
> and I think I figured out how to call a cdecl routine (had an epiphany right
> before bed last night). Here's how to make a cdecl callback:
>
> -- Start code
> include machine.e
> include misc.e
> include dll.e
>
> constant
> func_asm = {
>
> #55, -- 0: push ebp
> #89,#E5, -- 1: mov ebp, esp
> #51, -- 3: push ecx
> #B9,#00,#00,#00,#00, -- 4: mov ecx, argnum (5)
> #89,#E6, -- 9: mov esi, esp
> #83,#C6,#0C, -- B: add esi, 12
> #BF,#00,#00,#00,#00, -- E: mov edi, myargs (15)
> #F3,#A5, -- 13: rep movsd; next we call the proc
>
> #FF,#15,#00,#00,#00,#00,-- 15: call dword ptr [pfunc] (#17)
>
> #59, -- 1B: pop ecx
> #89,#EC, -- 1C: mov esp, ebp
> #5D, -- 1E: pop ebp
> #C2,#00,#00,#00,#00} -- 1F: ret [argnum] (#20)
>
>
> constant offset = length( func_asm )
>
> global function new_pfunc_cdecl( atom callback, integer args )
> atom func_addr, func_retval, func_pfunc, func_args
>
> func_addr = allocate( length(func_asm) + 4 * 12 )
> poke( func_addr, func_asm )
> func_retval = func_addr + offset
> func_pfunc = func_retval + 4
> func_args = func_pfunc + 4
>
> poke4( func_addr + #05, args )
> poke4( func_addr + #0F, func_args )
> poke4( func_addr + #17, func_pfunc )
> --poke4( func_addr + #20, ( args + 0 ) * 4 )
>
> poke4( func_pfunc, callback )
>
> return { func_addr, func_args }
> end function
>
> atom my_cdecl_args
> function my_cdecl_func()
> sequence args
> args = peek4u( {my_cdecl_args , 2})
> -- do stuff
> return 1
> end func
>
> object my_cdecl_callback
>
> my_cdecl_callback = new_pfunc_cdecl( call_back(routine_id("my_cdecl_func")),
> 2 )
>
> my_cdecl_args = my_cdecl_callback[2]
> my_cdecl_callback = my_cdecl_callback[1]
> -- Now you can pass my_cdecl_callback to a dll that uses cdecl
Hey Matt,
By George I think youve done it!
ITS ALIVE! hehe 
I havent done extensive test on the routine but it works so far.
I should have more test done on this tonight and I'll let you know
what happens.
Only draw back thus far is, it sure is alot of extra typing.
But I sortof expected this.
Later,
Euman
euman at bellsouth.net
8. Re: cdecl support
Karl Bochert writes:
> Is it really that simple, or am I overlooking something?
For most Euphoria programs, preserving the stack pointer
as you describe, will probably solve the problem,
but there's a bit more to it than that.
According to the notes I made a year ago,
structures, and floating point values (C doubles), are also
passed and returned differently. Structures don't matter
to us, but doubles occasionally do.
Here are the notes I have. I found that this stuff
is very poorly documented.
Calling Convention Info
=======================
Common to BOTH __cdecl AND __stdcall:
1. Arguments are pushed on the stack from right to left.
That is, the last argument is pushed first.
2. Registers EAX, ECX and EDX are not saved and restored when a
call is made.
__cdecl:
- The calling routine will remove the arguments from the stack.
- Floating-point values are returned in the same way as structures.
When a structure is returned, the called routine allocates
space for the return value and returns a pointer to the
return value in register EAX.
__stdcall:
- All C symbols (extern "C" symbols in C++) are suffixed by "@nnn"
where "nnn" is the sum of the argument sizes (each size is rounded up
to a multiple of 4 bytes so that char and short are size 4).
When the argument list contains "...", the "@nnn" suffix is omitted.
- The called routine will remove the arguments from the stack.
- When a structure is returned, the caller allocates space on the stack.
The address of the allocated space will be pushed on the stack
immediately before the call instruction. Upon returning from the
call, register EAX will contain address of the space allocated
for the return value. Floating-point values are returned in
80x87 register ST(0).
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: cdecl support
-------Phoenix-Boundary-07081998-
Hi Robert Craig, you wrote on 2/26/02 9:19:35 PM:
>
>For most Euphoria programs, preserving the stack pointer
>as you describe, will probably solve the problem,
>but there's a bit more to it than that.
>According to the notes I made a year ago,
>structures, and floating point values (C doubles), are also
>passed and returned differently. Structures don't matter
>to us, but doubles occasionally do.
>
It seems that the problems are in four areas:
1) Different Stack cleanup:
Fairly easy.
2) Different Name Mangling:
Doesn't Euphoria already depend on the programmer
using the decorated name?
3) Different double return location:
Give 2) above, doesn't the C function name
describe the calling convention?
4) Different structure handling:
Ditto 3)
Karl
-------Phoenix-Boundary-07081998---
10. Re: cdecl support
Karl Bochert writes:
> 2) Different Name Mangling:
> Doesn't Euphoria already depend on the programmer
> using the decorated name?
>
> 3) Different double return location:
> Give 2) above, doesn't the C function name
> describe the calling convention?
Unfortunately, there is no consistency.
You don't have to have "@n" in the name for it
to be _stdcall. Just look at all the Windows API routines.
My notes were taken from one particular C compiler,
and all C compilers have a way for the programmer to
change the function name to anything he likes.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
11. Re: cdecl support
-------Phoenix-Boundary-07081998-
Hi Robert Craig, you wrote on 2/27/02 2:53:54 PM:
>
>Unfortunately, there is no consistency.
>You don't have to have "@n" in the name for it
>to be _stdcall. Just look at all the Windows API routines.
>
>My notes were taken from one particular C compiler,
>and all C compilers have a way for the programmer to
>change the function name to anything he likes.
>
What a pity.
Functions which take parameters reveal their convention
by changing ESP, or not.
Return values that are something other than doubles, floats,
or structures are the same in either convention.
Functions which return structures are not supported by
Euphoria.
Currently Euphoria only fails on _cdecl's that return
float or double. Compilation with a compiler other than
Watcom causes failure on all _cdecl's that take
parameters.
Euphoria could easily be modified to only fail on
_stdcall's that returned a float or double,
and took no parameters
and were named with a leading underscore.
Alternately:
It could easily be modified to only fail on
_cdecl's that returned a float or double,
and took no parameters
and were named without a leading underscore.
Is that about right?
The changes would extend Euphoria's coverage from
maybe 97% of dll's to maybe 99%, which is either
a small or a large gain, depending on how you
look at it.
If any source code hacker is interested, I can supply
the fixes that restore Euphoria-like behavior to
the output of LCC.
Karl Bochert
-------Phoenix-Boundary-07081998---
