On 26/jul/2005, at 14:34, C Y wrote:
>> Do we want to add a new option to decfun for specifying the calling
>> convention or do we want to convince/help the windows lisps to behave
>> like Allegro? I think the Allegro approach is much better, and allows
>> for more portable code between windows and unix.
<snip>
> 2005-06-08 04:41 Michael Goffioul has contributed a library for
> calling
> Microsoft Windows's GUI functions from ECL.
I took a look at those bindings and I see it uses C-LINES to #include
windows.h. I suppose that's what lets ECL (well, GCC or whatever) know
whether to use stdcall or cdedcl. I'm not sure if the Allegro approach
is easy/desirable for ECL (and GCL). Perhaps Juanjo can offer some
insight on this.
> I don't know of any others offhand, but I would definitely advocate
> a) the
> Right approach and b) more portable code between Windows and unix.
> b) especially would be a Big Win.
Another solution would be to define a calling convention globally
(clisp has this too) then one could do something like this:
#+win32 (set-default-calling-convention :stdcall)
#-win32 (set-default-calling-convention :c)
CLISP might have issues here though, since I suppose this could make
its fasls unportable across platforms. (another reason to push the
Allegro approach).
I guess that if we decide to try the Allegro approach, windows Lisps
that don't support this yet could simply default to cdecl (that's what
UFFI does atm anyway).
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt
On Monday 25 July 2005 23:17, Luis Oliveira wrote:
> ===
> Calling conventions
>
> If I understand correctly, wrt C, the only calling convention issue is
> between 'cdecl' and 'stdcall' on win32. I suppose it would be nice not
> being required to specify this. (UFFI doesn't support stdcall at all).
>
> Anyway, I noticed that Allegro doesn't require specifying cdecl vs.
> stdcall. I mailed Duane who quickly replied and explained to me that
> Allegro saves the stack pointer, and resets it after the call returns.
> That way, it'll work the same way whether it's the caller or the callee
> who is supposed to remove the arguments from the stack.
>
> Do we want to add a new option to decfun for specifying the calling
> convention or do we want to convince/help the windows lisps to behave
> like Allegro? I think the Allegro approach is much better, and allows
> for more portable code between windows and unix.
I'm thinking the better thing to do here would be to work with the windows
lisps - Camm at GCL <camm(a)enhanced.com> is always
open to suggestions and will undoubtedly be delighted to hear you are
working on a GCL port. I know less about Clisp's crew, but I think Sam
Steingold <sds(a)gnu.org> is probably the man to talk to about that. ECL
http://ecls.sourceforge.net/ also apparently works on Windows, and might
be a very interesting test case as it a) compiles with the free Microsoft
Visual C++ toolkit and b) has some sort of FFI based bridge to the Windows
GUI libraries:
2005-06-08 04:41 Michael Goffioul has contributed a library for calling
Microsoft Windows's GUI functions from ECL. The library uses ECL's own
implementation of the UFFI (Unified Foreign Function Interface) and
demonstrates that this is really usable. As examples, he has written both the
typical button example and a small, single window text editor. You can find a
screenshot at the project homepage
(https://sourceforge.net/project/screenshots.php?group_id=30035)
I don't know of any others offhand, but I would definitely advocate a) the
Right approach and b) more portable code between Windows and unix.
b) especially would be a Big Win.
Very exciting stuff!
Cheers,
CY
