DllMain and LoadLibrary

[Jeffrey Walton]

Hi Group,

I have a Dll that wants to do some initialization (at runtime) during DllMain. I want
to determine available features.

Richter states not to call LoadLibrary(...) during DllMain. However, the features I
want to query are housed in advapi32.dll. The Dll will configure itself appropriately
1 time, based on LoadLibrary(...) and GetProcAddress(...).

advapi32.dll is not a prerequisite of all DLLs. If I make it so (by including a
function available on Win NT 3.5 and Win 95 (not any particular OSRs), can I safely
call load library on advapi32.dll (since I have made it a prerequisite)?

I would think since my Dll is dependent on advapi32.dll, the loader will work out the
dependencies and a LoadLibrary(...) would not fail.

Thanks in Advance,
Jeff

[Mike Gallacher [MSFT]]

I think you're tempting fate to ingore the DllMain documentation, which is
abundantly clear not to do this, and for very good reason. Just because it
doesn't crash on your machine really tells you nothing about your end
user's machine.

Why not just do what most people do in this situation and create an
inintialization routine that is called by the calling process? One's risky,
the other's a few lines of code. :-)

Mike Gallacher, Visual C++ Team
This posting is provided AS IS with no warranties, and confers no rights.

--------------------
>From: "Jeffrey Walton" <jwa...@umbc.edu>
>Subject: DllMain and LoadLibrary

[Jeffrey Walton]

"Mike Gallacher [MSFT]" <mgal...@online.microsoft.com> wrote in message
news:riMvj6c6...@cpmsftngxa08.phx.gbl...

Hi Mike,

| I think you're tempting fate ...
Agreed.

| create an initialization routine ...
This is what I wanted to avoid.

I was hoping by creating a static dependence, I could ensure the loader would already
have the dll (advapi32) in memory. I would then assume LoadLibrary(...) would not fail
(and lock the system).

All I am interested in is the results of the GetProcAddress(...).

Jeff

[David Lowndes]

If you've explicitly linked to the DLL, you could try using
GetModuleHandle to find the module handle to use with GetProcAddress.

Mike - would using GetModuleHandle have the same issues as using
LoadLibrary in this circumstance? I can't see any mention of it in the
documentation.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

[Mike Gallacher [MSFT]]

>If you've explicitly linked to the DLL, you could try using
>GetModuleHandle to find the module handle to use with GetProcAddress.
>
>Mike - would using GetModuleHandle have the same issues as using
>LoadLibrary in this circumstance? I can't see any mention of it in the
>documentation.
>

GetModuleHandle would most likely not have this problem, because
GetModuleHandle() suceededs only if it has been already loaded (load-time
or link-time). The only very odd situation I can think of is where the
module could have been loaded but not initialized (per DllMain
documentation), but you'd have to work hard to get this to happen. Like,
you yourself called LoadLibrary(advapi32.dll) in another DllMain (which may
not have initialized advapi32.dll correctly) and then tried to used
GetModuleHandle(advapi32.dll) later in this DllMain.

So, GetModuleHandle() should be OK, but there's a problem. How would you
guarantee that advapi32 is *always* loaded *before* your dll? You can't,
unless you are only using LoadLibrary on your DLL after app initialization.
If this is the case, then an initialization method makes sense anyway. I
still think the init routine is by far the best. What is the hesitation
you have? Not code size or effort, since asking the newsgroups about
workarounds takes longer than just writing the init function. :-) I am
curious why the resistance....

--

[Jeffrey Walton]

"Mike Gallacher [MSFT]" <mgal...@online.microsoft.com> wrote in message

news:WctRggl6CHA.1760@cpmsftngxa06...

| GetModuleHandle would most likely not have this problem, because
| GetModuleHandle() suceededs only if it has been already loaded (load-time
| or link-time). The only very odd situation I can think of is where the
| module could have been loaded but not initialized (per DllMain
| documentation), but you'd have to work hard to get this to happen. Like,
| you yourself called LoadLibrary(advapi32.dll) in another DllMain (which may
| not have initialized advapi32.dll correctly) and then tried to used
| GetModuleHandle(advapi32.dll) later in this DllMain.
|
| So, GetModuleHandle() should be OK, but there's a problem. How would you
| guarantee that advapi32 is *always* loaded *before* your dll? You can't,
| unless you are only using LoadLibrary on your DLL after app initialization.
| If this is the case, then an initialization method makes sense anyway. I
| still think the init routine is by far the best. What is the hesitation
| you have? Not code size or effort, since asking the newsgroups about
| workarounds takes longer than just writing the init function. :-) I am
| curious why the resistance....
|
| --
| Mike Gallacher, Visual C++ Team
| This posting is provided AS IS with no warranties, and confers no rights.

Hi Mike,

| What is the hesitation you have?

This is a COM Dll for a VB client. IMHO, it is outside the spirit of VB programming to
call things such as Init() (the VC++ guys are on their own). VBer's should only have
to 'Dim x as new MyObject', and then work with the MyObjects running around in the
program.

Otherwise, each constructor will have to check for initialization, and call Init() as
required. I did not want to take this route either, since DLL main is the perfect
place for library wide initialization.

Jeff