🚀 go-pugleaf

Loz <noemail@nowhere.com> wrote:

>I seem to be talking to myself a lot at the moment!

A sign of madness ...

>My current findings are thus...
>
>I don't think there ever was an issue with __cdecl or __stdcall, I think 
>it was more an issue of additional threads calling the DllEntryPoint 
>multiple times which was confusing me.
>
>I've encapsulated my initialisation code within the DllEntryPoint by 
>checking for DLL_PROCESS_ATTACH and then my uninitialising / destructor 
>code within the entry point by checking for DLL_PROCESS_DETACH when it's 
>finally unloaded.  This works fine.
>
>My issue regarding multiple instances of the DLL - I've since discovered 
>that I can only load one instance of a DLL per 'process'.  Every time I 
>load the dll using LoadLibrary, it simply increments a count within the 
>dll .  I think this means that any globals within the DLL are shared 
>within the calling process so I don't actually have a separate instance.  
>To create, manage and use multiple instances of classes within the DLL, 
>I need to create my own management code.  Is this correct?

Yes, that is correct. If you got a separate instance of the DLL (rather,
of its data segment - the code and const data segments should never
change, so can be shared between processes) each time you loaded it
without previously unloading it, you could really blow Windows out of
the water.

(Under 16-bit Windows, it wasn't even per process - you got one copy of
the DLL between all processes currently using it. I implemented a shared
memory manager that way allowing memory to be passed between programs.
Don't go there - converting to 32-bit Windows took ages.)

>For example, within my dll I have classes that declare TCP and UDP 
>Client and Server engines.  Access to these components is through a 
>defined interface.  If I want to create both a TCP and UDP Server, I 
>would have to create two pointers internal to the DLL, one for managing 
>the TCP object, and one for the UDP object.  
>
>What I was trying to do before was declare one pointer per 'dll 
>instance' that would access the 'instance object type' but because I 
>can't create 'separate DLL instances', the pointer was being use to 
>create one object, and then being used again to create the next object.  
>Hence this didn't work!  
>
>I think I've got it right?  Can anyone confirm this for me please?  

Still correct.

The problems you've been having explain much of the rationale behind
COM. With COM, you don't 'load a DLL', you create an instance of an
object, and the framework loads the DLL if required (assuming in-process
COM objects here). Then, the actual 'instance pointers' are the COM
interface pointers, and you write your COM objects to not have global
pointers.

Effectively, the COM framework does the management that you've just
worked out you need to do.

I'd suggest that the clean, elegant way to do this would be to create
COM servers.

Alan Bellingham
-- 
alanb@episys.com