Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id: <200002151634.KAA03715@hp2.xraylith.wisc.edu>
To: Oliver Nittka <nittka AT esem DOT com>
cc: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: __stdcall in 3rd-party dll 
In-reply-to: Your message of "15 Feb 2000 10:17:53 +0100."
             <uya8m3jum DOT fsf AT esem DOT com> 
Date: Tue, 15 Feb 2000 10:33:37 -0600
From: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>

Oliver Nittka <nittka AT esem DOT com> writes:
> 
> hi everyone !
> 
> after some diggin' in the mailing-list archives and on dejanews, i've
> got some insight in the following situation, but still don't know how
> to resolve it, perhaps somebody can give me a hit over the head with
> the appropriate literature ;-)
> 
> i've got me a DLL (gpib-32.dll from national instruments), where i
> want to link against some functions (ibdev, ibwrt, ibrd: perhaps
> somebody's got that dll and wants to look for him/herself)

If I understand correctly, you have a foreign DLL that you want to link
to, and the functions in this foreign DLL are stdcall (which makes sense
since that allows LoadLibrary/GetProcessAddress to work), and you want
to create an import library to link against.

> according to the headerfile, those functions are __stdcall, but they
> are exported from the dll undecorated (without @nn).
> 
> - if i delete __stdcall from the header, my program crashes as soon as
>   it calls ibdev (stack corruption i suppose)

Wrong approach.

> 
> - if i leave the .h-file as is, i get unresolved symbols ibdev AT 24,
>   ibwrt AT 16 etc.
    ^^^^^^^^ (See later on this particular one).

Correct.

> 
> - if i create myself an import-library, using a decorated .def-file,
>   it still crashes (does it link to the correct functions, anyway ?)
>   using an undecorated import-lib still gives me unresolved symbols.

You can create an import library that will do the following:
  - create a lib with decorated names, and
  - use the undecorated exports from the DLL.

That's the kind the w32api package deals with, and here's how:

Given the following prototypes
  extern int __stdcall ibdev  (int, int, int, int, int, int);
  extern int __stdcall ibwrt  (int, void *, long);
  extern int __stdcall ibrd   (int, void *, long);

Create a .def file that looks like the following:
  
  LIBRARY "gpib-32.dll"
  EXPORTS
  ibdev AT 24
  ibwrt AT 12
  ibrd AT 12

and so on, and create the implib in the usual way:
  
  $ dlltool -k --output-lib libgpib-32.a gpib-32.def

Now you should be able to link against this import library in the usual
way.

I don't understand why you see ibwrt AT 16, it should be ibwrt AT 12 given the
prototype, since there're 12 bytes in the parameter list, not 16 (long
and int are both 4 bytes on ix86 running 32 bit OS).

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com