Re: Windows x64 jna DLL

I poked at this a bit (merging python libffi fork into
standalone  
libffi) and got some of the configury done and got something
to build,  
but got stuck not having a working dejagnu/expect harness to
run the  
tests.

Apple has some python-based tests derived from the dejagnu
ones, which  
might be easier to get running.

It's a bit tricky to put back into standalone libffi b/c
that expects  
gcc; you'd need to beef up some of the wrapper scripts to
get the MS  
compiler and assembler to work properly within the
framework.

It also looks like x86 stdcall is not yet implemented.

On Apr 18, 2008, at 10:20 AM, Albert Strasheim wrote:
> Hello,
>
> On Fri, Apr 18, 2008 at 4:06 PM, Thomas Börkel
<thomasboerkel.de>  
> wrote:
>> HI!
>>
>> Someone already tried compiling the jna lib on
Windows x64?
>>
>> There are x64 versions for Linux, Sun and MacOS on
the web site,  
>> but not
>> for Windows...
>
> The last time I checked, the patches for Windows 64-bit
ctypes  (which
> is what JNA uses to talk to the native library) only
existed in the
> Python ctypes code base, and not in standalone ctypes,
GCC ctypes or
> JNA's ctypes.
>
> Someone who knows what they're doing probably needs to
merge the stuff
> in Python ctypes with standalone ctypes.
>
> Cheers,
>
> Albert
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: users-unsubscribejna.dev.java.net
> For additional commands, e-mail: users-helpjna.dev.java.net
>

Timothy Wall schrieb:
> I poked at this a bit (merging python libffi fork into
standalone  
> libffi) and got some of the configury done and got
something to build,  
> but got stuck not having a working dejagnu/expect
harness to run the  
> tests.
> 
> Apple has some python-based tests derived from the
dejagnu ones, which  
> might be easier to get running.
> 
> It's a bit tricky to put back into standalone libffi
b/c that expects  
> gcc; you'd need to beef up some of the wrapper scripts
to get the MS  
> compiler and assembler to work properly within the
framework.
> 
> It also looks like x86 stdcall is not yet implemented.

You're talking about AMD64, on 64-bit Windows, right?
AFAICT, there is only one calling convention:

http://msdn2.microsoft.com/en-us/library/ms235286.aspx


Thomas