🚀 go-pugleaf

5 Mar 2006 15:58:34 +0100, nicolasr <nicolasrNOSPAMATSIGNgmx.net> wrote:

> Problem: the above DllMain() gets never called. Instead
> the DllEntryPoint() function seems to be called directly.
> Like BCB ignores the direction to call DllMain().
>
>
> Any ideas how to solve this?


Here is my understanding of entry points vs Dll.

When loading time is involved the entry point is DllMain.
(Ex. COM in-process server DLL).

When running time is involved the entry point is DllEntryPoint.
(Ex. LoadLibrary get called).

So to answer your question.
If DllMain never gets called could it be because of the nature of the call ?


-- 
JF Jolin

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 :-(

Nick


>> Problem: the above DllMain() gets never called. Instead
>> the DllEntryPoint() function seems to be called directly.
>> Like BCB ignores the direction to call DllMain().
>>
>>
>> Any ideas how to solve this?
>
>
> Here is my understanding of entry points vs Dll.
>
> When loading time is involved the entry point is DllMain.
> (Ex. COM in-process server DLL).
>
> When running time is involved the entry point is DllEntryPoint.
> (Ex. LoadLibrary get called).
>
> So to answer your question.
> If DllMain never gets called could it be because of the nature of the call 
> ?
>
>
> -- 
> JF Jolin 

9 Mar 2006 02:38:36 +0100, nicolasr <nicolasrNOSPAMATSIGNgmx.net> wrote:

> 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

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 

"nicolasr" <nicolasrNOSPAMATSIGNgmx.net> wrote in message 
news:440afc9e@newsgroups.borland.com...
> Hi,
>
> I'm trying to rebuild a VS DLL project with BCB.
> I created a new DLL project with the VS option
> checked, removed the created main cpp file
> and added the source code files from the VS project.
>
> After some tweaks it compiled and linked fine
> but I have problems with the entry point function.
>
> Since I used the VS option the entry point expected
> is DllMain() at least this is what I see in the .bpf file.
>
> This DllMain() function is implemented as follows:
>
> // Comment from the original VS project:
> // If we declare the correct C runtime entrypoint and then forward it to 
> the DShow base
> // classes we will be sure that both the C/C++ runtimes and the base 
> classes are initialized
> // correctly
> extern "C" BOOL WINAPI DllEntryPoint(HINSTANCE, ULONG, LPVOID);
>
> BOOL WINAPI DllMain(HANDLE hDllHandle, DWORD dwReason, LPVOID lpReserved)
> {
>    //MessageBox(0, "DllMain", "", 0);
>    return DllEntryPoint(reinterpret_cast<HINSTANCE>(hDllHandle), dwReason, 
> lpReserved);
> }
>
> The referenced DllEntryPoint() function is implemented
> in the "base class library".
>
> Problem: the above DllMain() gets never called. Instead
> the DllEntryPoint() function seems to be called directly.
> Like BCB ignores the direction to call DllMain().
>
>
> Any ideas how to solve this?
> thanks,
> Nick


Talke a look at the following article in borlands developer network site:
http://community.borland.com/article/0,1410,22432,00.html