🚀 go-pugleaf

As an update... I've found that if I change all the __stdcall 
declarations to __cdecl, the random crashing behaviour goes...  I know 
__cdecl manages the stack differently but I don't really know what 
happens.  

I made sure that originally, everything was __stdcall which should have 
meant things would be fine... Not sure if there's a bug there or just an 
oversight on my behalf?

Another problem I've now encountered, is the number of times 
DllEntryPoint gets called.  I'm outputting some debug to see what the 
reason is, and it doesn't quite add up.  I now also realise this is not 
the place to do any initialisations!

I'm getting a DLL_PROCESS_ATTACH followed by a DLL_THREAD_ATTACH which 
makes sense to me.  What doesn't quite make sense is that I have three 
DLL_THREAD_ATTACH dll entries, and then when the dll is unloaded, I only 
get one DLL_THREAD_DETACH followed by an expected DLL_PROCESS_DETACH.

If there are additional threads being created by the VCL form and their 
components, this might explain why I get the additional two 
DLL_THREAD_ATTACH, but unless the threads are not being terminated, why 
do I not see the correct number of DLL_THREAD_DETACH?  Is this normal?

Another issue I have is how a dll is shared by the main application.  
I'm trying to create two separate instances of the DLL which means I'm 
calling LoadLibrary twice with two different instance handles.  It seems 
to always share the first one which means I don't actually have two 
separate instances, all the dll variables in the header are shared.  Is 
this normal?  Is there a way of loading the same DLL twice and creating 
to separate instances?  This is the way I'd like to do it, otherwise I 
have to manage the creation of the objects in the DLL manually - not a 
problem but I'd prefer to keep them separate.

Thanks,

Loz