From: colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp (Colin Peters) Subject: C++ classes in DLLs 4 Apr 1997 09:05:11 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com 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'" Original-Sender: owner-gnu-win32 AT cygnus DOT com 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 - colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp -- 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 "gnu-win32-request AT cygnus DOT com" with one line of text: "help".