Magnus Hagander wrote:
>
> If you reference the library during compilation (e.g. you link with the
> .LIB file that corresponds to the .DLL), the OS will handle that as part
> of the CreateProcess() call.
>
What if the required DLL is missing (as is the case with netmsg.dll) on some
system?
>
> As for the FreeLibrary problem, you also have to deal with:
> There are cases in which the entry-point function is called for a
> terminating thread even if the DLL never attached to the thread - for
> example, the entry-point function was never called with the
> DLL_THREAD_ATTACH value in the context of the thread in either of these
> two situations:
> * The thread was the initial thread in the process, so the system called
> the entry-point function with the DLL_PROCESS_ATTACH value.
> * The thread was already running when a call to the LoadLibrary function
> was made, so the system never called the entry-point function for it.
>
That is why it is better to do such a global initialization/finalization on
DLL_PROCESS_ATTACH/DETACH.
>
> In general, depending on doing things in DllMain is not a good idea.
> The fact that we do WSAStartup() in it is even deprecated in the docs
> now, for the same reason: "Calling Win32 functions other than TLS,
> object-creation, and file functions may result in problems that are
> difficult to diagnose. For example, calling User, Shell, COM, RPC, and
> Windows Sockets functions (or any functions that call these functions)
> can cause access violation errors, because their DLLs call LoadLibrary
> to load other system components".
>
In netmsg.dll case it looks very like "file function" because we load it as data.
In case of WSAStartup() consider the following scenario:
Application doesn't load libpq.dll explicitly, OS loads it during CreateProcess()
call. Suppose there is some sockets problem exists. What happens with
the application? Will it start up at all? What if this application is
still useful even without connection to DB?
>
> The question is if it should be moved to the connection functions, or if
> it shuold be left up to the application to do it. Moving it to the
> connection functino would be easy, but each call to WSAStartup() should
> have a corresponding WSACleanup() call...
> Or if we should just leave it :-) Because it appears to work...
>
The rcommended way is to have initialization/finalization functions in DLL.
>
>>If this is a problem, a possible answer is not to try to cache the
>>netmsg reference at all, but just to load and unload that DLL at the
>>single point where it's used. Since we only use it to translate
>>socket error reports, there's probably no big performance penalty
>>involved to do it that way.
>>
> That's probably the best idea.
>
>
>
>>(1) netmsgModule and winsock_strerror_buf are declared as static
>>variables in libpq/win32.h. Unless Windows has some truly creative
>>
That was my copy/paste bug, sorry again.
Regards,
Mikhail
