Subject: C++ classes in DLLs
From: [email-masked] (Colin Peters)

4 Apr 1997 09:05:11 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <01BC410B.FA35B240.cygnus.gnu-win32@gbird0>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Original-To: "'GNU-Win32'" <[email-masked]>
Original-Sender: [email-masked]

I was experimenting last night with building DLLs which contain C++ classes
and found that in order for the program that loads a DLL to derive classes
from a class implemented in the DLL the DLL needs to export 'type info'
symbols (beginning with __ti in the nm output).

Actually I was surprised this worked. Dlltool creates 'thunk' symbols which
when called as functions, look up the appropriate __imp_ version of the
real symbol and call that.

This process messes up when what you really want is a reference to something
that's not a function, like a variable declared in the DLL, or, I thought,
virtual function tables or run time type information. The reference in the
calling function just ends up getting the value of whatever bytes happen
to be at the beginning of the *thunk code*. In some cases you can work
around this by actually referencing the __imp_ version of the symbol
(which will point at the location of the real variable in the DLL), but
with vtables and type info this would seem to be impossible.

However, exporting the vtables and type info symbols with dlltool creates,
at least for the simple example I have, a program which works.

My question is: Does anyone know why this works (or should not, beyond
what I talked about above)? Are the __ti... and __vt$... symbols actually
functions? The __vt$ appear to be "text" (i.e. executable code), but the
__ti symbols are "common" (which means?).

Also, as a point of interest, presumably the linker handles dynamic or
shared symbol references differently on other platforms where they are
fully supported (instead of requiring an extra utility like dlltool).
How hard is it going to be to adapt that strategy for Win32? How does
the compiler properly generate calls to functions in shared libraries
(i.e. how does it figure out that a reference needs to be 'fixed up'
as opposed to a normal static reference).

I just know if exporting the type info symbols in general will produce
a safe C++ class in a DLL implementation, or if it is just dumb luck
that my program doesn't crash.

Colin.

-- Colin Peters - [email-masked]
-- Saga University Dept. of Information Science
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".