🚀 go-pugleaf

Thanks. I tried to investigate this further and here is the result from my
very simple test case:

Projectgroup with three projects:

1) C++ DLL, VS style, that implements both DllMain and DllEntryPoint.
In the .bpf file DllMain is specified as the entry point.

2) C DLL, VS style, that implements both DllMain and DllEntryPoint.
In the .bpf file DllMain is specified as the entry point.

3) Simple application with two buttons that call LoadLibrary on either DLL.

Result: in any case DllEntryPoint is called! DllMain is ignored.

So I guess I have to find some workaround and modify the existing MS
"base classes" for which I luckily have source code.

thanks for your ideas,
Nick


>
>> thanks for your reply!
>> However, I think I do not quite understand the distinction you make.
>> My DLL is a COM in-process server. But does instantiating a COM
>> server not result in a call to LoadLibrary() finally?
>> I tested the DLL in a COM environment and now also called LoadLibrary()
>> on it myself. In both cases my DllMain() is not called :-(
>
> I made an assumption that a COM server always pass by a DllMain entry 
> point.
> That was based on Win32 Prog. Ref. under Structuring a Namespace 
> Extension:
>
> As a reminder, the construction of an in-process server DLL requires the
> implementation of a DLL that exports the following functions:
> DllMain DllGetClassObject DllUnloadNow
>
> That was reinforced by the fact that i use such a DLL with the following 
> declaration.
> extern "C" int WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID 
> lpReserved)
> Which is more a C declaration than a C++.
>
> But i also found on http://tinyurl.com/oecsq
>
> DllMain() is not the entry point in a C++ DLL, DLLEntryPoint() is.  (Remy 
> Lebeau)
>
> Sorry for the misleading.
>
> -- 
> JF Jolin