delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1998/01/20/13:30:48

From: colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp (Colin Peters)
Subject: Re: mingw32: .exe -> .a import libs for DLLs?
20 Jan 1998 13:30:48 -0800 :
Message-ID: <01bd24a9$2fc8be80$fa173185.cygnus.gnu-win32@gbird0.fu.is.saga-u.ac.jp>
Reply-To: "Colin Peters" <colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp>
Mime-Version: 1.0
To: "Peter Dalgaard BSA" <p DOT dalgaard AT biostat DOT ku DOT dk>
Cc: "GNU-Win32" <gnu-win32 AT cygnus DOT com>

You almost have it. The problem is that the symbols baz and zip are
actually pointers to thunk functions in the DLL (and similarly the symbol
bar is a pointer to a thunk in the executable). The thunk functions simply
look up the appropriate pointer in the jump table for the DLL and call
that function. Obviously this won't work for variables. What you have to
do in that case is something like

extern int* __imp__zip;
#define zip    (*__imp__zip)

in your DLL code (but not in the executable). This only works because we
know that dlltool names each of the entries in the jump table
__imp_<symbol> (and the actual symbol for zip is _zip, but anyway). This
may change in the future (especially since MS's standard is something like
_imp___zip IIRC), but for now it will work.

On the other hand I'm sure you know that global variables are evil. :)

Good luck,
Colin.

PS. I think MS does this basically the same way, except the compiler knows
how to handle it all internally based on the __dllexport (or some such)
keyword.

-- Colin Peters -- colin at fu.is.saga-u.ac.jp
-- Saga University Dept. of Information Science
-- http://www.fu.is.saga-u.ac.jp/~colin
-- http://www.geocities.com/Tokyo/Towers/6162


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019