Re: Sockets in MFC Extension DLL
From: Mark Robinson (mark_at_simsol.co.uk)
Date: 05/19/04
- Next message: Balboos: "Re: A question in an interview"
- Previous message: KS: "TCHAR* and PostMessage in a thread .. memory leak question"
- In reply to: Helge Opgård: "Sockets in MFC Extension DLL"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 19 May 2004 16:44:44 +0100
"Helge Opgård" wrote:
>
> I'm trying to use a software licensing tool (FlexLM) from within an MFC
> Extension DLL. It works for local license files but not with a license
> server. I suspect that this is because the license server must be
> contacted by using socket communications.
>
> I'm trying to check the license server from DllMain (dwReason ==
> DLL_PROCESS_ATTACH) and it fails.
> Moved the same code into an MFC console application and it works there.
>From the documentation for DllMain (Note that calling sockets functions
during an attach is strictly forbidden):
--------------------------------------------------
Warning On attach, the body of your DLL entry-point function should
perform only simple initialization tasks, such as setting up thread
local storage (TLS), creating objects, and opening files. You must not
call LoadLibrary in the entry-point function, because you may create
dependency loops in the DLL load order. This can result in a DLL being
used before the system has executed its initialization code. Similarly,
you must not call the FreeLibrary function in the entry-point function
on detach, because this can result in a DLL being used after the system
has executed its termination code.
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. While it is acceptable to create synchronization objects in
DllMain, you should not perform synchronization in DllMain (or a
function called by DllMain) because all calls to DllMain are serialized.
Waiting on synchronization objects in DllMain can cause a deadlock.
To provide more complex initialization, create an initialization routine
for the DLL. You can require applications to call the initialization
routine before calling any other routines in the DLL. Otherwise, you can
have the initialization routine create a named mutex, and have each
routine in the DLL call the initialization routine if the mutex does not
exist.
--------------------------------------------------
Cheers
mark-r
-- A banana flies like fruit Arrow flies like thyme
- Next message: Balboos: "Re: A question in an interview"
- Previous message: KS: "TCHAR* and PostMessage in a thread .. memory leak question"
- In reply to: Helge Opgård: "Sockets in MFC Extension DLL"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
