Kernel32.INSTANCE defaults to wrong calling convention

[Groostav]

I saw a number of Unrecognized calling convention: 3 exceptions while trying to use Kernel32.INSTANCE methods. In poking around at calling conventions, I simply decided to try the other one, setting Library.OPTION_CALLING_CONVENTION to Function.C_CONVENTION in a custom instance of Kernel32, and my named pipe tests --well your named pipe tests really-- were able to create pipes and send messages without a problem.

My machine is Win 10 x64, running JVM 1.8u77 x86, on JNA 4.2.2.

Any idea whats going on?

this relates to #531, UniversalMediaServer/UniversalMediaServer#714

[twall]

The x64 native code is supposed to ignore requests for stdcall calling
convention, perhaps something changed recently so that is no longer the
case?

On Thu, Sep 29, 2016 at 8:10 PM, Geoff [email protected] wrote:

I saw a number of Unrecognized calling convention: 3 exceptions while to
use Kernel32.INSTANCE methods. In poking around at calling conventions, I
simply decided to try the other one, and my code, --well your code
really
https://github.com/java-native-access/jna/blob/master/contrib/platform/test/com/sun/jna/platform/win32/Kernel32NamedPipeTest.java--
was able to create pipes and send messages without a problem.

My machine is Win 10 x64, running JVM 1.8u77 x86, on JNA 4.2.2

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#710, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAuMrfZNa0DBdfo3d1NJamra5MdS_mOZks5qvFOHgaJpZM4KKm8K
.

[matthiasblaesing]

I just build 4.2.2 and run the Kernel32NamedPipeTest successfully on Oracle JDK 1.8.0u92 with 32bit and 64bit VM.

Could it be a mix of different versions of JNA and JNA-Platform?

Helpful would be if you could reproduce the problem standalone ant provide the steps.

[Groostav]

Sorry guys its been frantic, I'm planning on spending some time on an SSCCE here soon.

[Groostav]

So this was a simple misunderstanding. A copy jnidispatch.dll from an older version of JNA was on the path and getting loaded my copy of JNA 4.2 had a chance to load its functioning copy.

This issue was a red-herring, sorry for wasting your time guys.

[matthiasblaesing]

Thank you for investigating! Its good to see this resolved.