What is the recommended way to call Windows DLL's CDECL functions ?

[conferno]

Hi

It seems that Go can deal only with STDCALL functions and callbacks on Windows.
But some DLL have CDECL exports and callbacks, LIBTIFF to name one.
How to interact with them from Go code ?

[brainman]

On Wednesday, 24 August 2011 12:23:18 UTC+10, conferno wrote:

It seems that Go can deal only with STDCALL functions and callbacks on Windows.

Correct.
 

But some DLL have CDECL exports and callbacks, LIBTIFF to name one.

Never have used one. Please give more details.
 

How to interact with them from Go code ?

You could write a small dll adapter to translate from stdcall to cdecl and back.

Alternatively, you would have to add correspondent function to go runtime. The later should not be hard to do. But I am not sure such function belongs to standard go runtime. Unless there are many other dlls like that to be used.

Alex

[Paulo Pinto]

Hi,

Most Windows compilers for languages targeting Windows let you
choose the calling convention, so I imagine many other cases
might exist.

--
Paulo

[conferno]

2011/8/24 brainman <alex.b...@gmail.com>

Alternatively, you would have to add correspondent function to go runtime. The later should not be hard to do. But I am not sure such function belongs to standard go runtime. Unless there are many other dlls like that to be used.

There is some support for different calling conventions already in Go runtime: runtimeВ·compilecallback(Eface fn, bool cleanstack)

bool cleanstack determines the calling convention (true for stdcall, false for cdecl), but it is always used with true.

Anyway, it is not an important issue as it is related only to windows/386.

There is only one calling convention on windows/amd64.

[j...@webmaster.ms]

On Aug 24, 7:22 am, brainman <alex.brain...@gmail.com> wrote:

>
> > But some DLL have CDECL exports and callbacks, LIBTIFF to name one.
>
> Never have used one. Please give more details.

That calling convention is called __cdecl in contrary with __stdcall
when callee takes care on cleaning stack.
__cdecl is default and only calling convention on windows/amd64
__stdcall is default but not only calling convention on windows/386

In some cases __cdecl is used on windows/386:
1. legacy libraries (libtiff to name one) use __cdecl for all their
functions on all their platforms
2. functions with ellipsis expect the caller to clean up the stack, so
they cannot technically follow __stdcall convention
USER32.wsprintf() is one but useless example of a function which
cannot be called from Go on windows/386
more useful example: ShellMessageBox() http://msdn.microsoft.com/en-us/library/bb762155(v=vs.85).aspx

[brainman]

You are welcome to file an issue (http://code.google.com/p/go/issues/list) or send a CL (http://golang.org/doc/contribute.html).

Alex

[j...@webmaster.ms]

Done: http://codereview.appspot.com/4961045/