[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

4927: Re: [MUD-Dev] Dynamic Loading of Modules

[Full Header] [Plain Text]
From: "Chris Gray" <cg@ami-cg.GraySage.Edmonton.AB.CA>
Newsgroups: nu.kanga.list.mud-dev
Date: Sat, 21 Mar 98 11:03:48 MST
Organization: Kanga.Nu
[Niklas Elmqvist:]

:Yes, I do know that Windows has dynamically linked libraries, just like
:Sun and Linux and whatnot (I think they had that *before* it went
:32-bit, however). However, I suppose you did not read the earlier
:part (this may be blamed on my too-active-snippage), where I explained
:about my "discovery" where a server binary with a base class called aClass
:could dynamically load a module which implemented a subclass of aClass
:called bClass and *still* use the bClass (as a reference to an aClass
:object, of course, using polymorphism) even though the server had no idea
:of its existence at compile-time. (Phew.) According to my RL friend (I
:have no personal experience in this), this scheme is impossible to
:implement using Windows DLLs -- I believe he tried after hearing me
:explain about it.

Well, I hate to think I'm becoming knowledgeable about Windows, but I
guess its actually true. A co-worker and I have been playing with a small
DLL on NT, and the debugger and paging interfaces. We haven't been using
C++, however, just C, so there may be some extra stuff we haven't noticed.

In order to get your dynamic stuff working right, you have to (of course)
ensure that the main code and the dynamic code are compiled by the same
compiler, so that the mangled names come out right. You also normally
use the '__cdecl(dllexport)' magic word with DLL entry points. So, you
would need the partner '__cdecl(dllimport)' on the declaration of the
function pointers you use. I don't know whether that is syntactically
allowed or not. If its not, then perhaps you don't want your exported
routines to actually show up as DLL entry points. That makes it harder
to find them in the loaded DLL code. One way would be to have a standard
entry point in each DLL, say 'getPointers', which returns a vector of
function pointers and names, so that your base code can then find the
proper ones at run time. Those routines wouldn't need the magic decoration.
So, I don't see any reason why your scheme wouldn't work with DLL's.

Oh yes, make sure everything is compiled with the same linkage convention,
such as '_cdecl'.

--
Chris Gray   cg@ami-cg.GraySage.Edmonton.AB.CA