Aidal wrote:
Hi NG.
I have a little problem with a C++ DLL.
I have a flow like this:
------------------------
SomeWin32App -> C++ DLL -> COM
When the App opens the C++ DLL (gets a handle for it) the DLL
instantiates an object of the COM component right away.
The idea is that the App opens the C++ DLL and calls one of it's
functions which then calls a function from the instantiated COM
component.
Once the App is done with the C++ DLL it closes the handle for it.
All of this works fine...
The problem is that if the App:
-------------------------------
1) opens the dll (gets a handle for it)
2) calls a function in the C++ DLL.
3) calls a function in the C++ DLL.
It appears that between calls the C++ DLL creates new instances of the
COM component instead of reusing the one already instantiated.
I can see this because one of the tasks of the COM component is to use
FTP.
i.e.
- open a connection with some login info
- change to some dir
- upload a file
- download a file
- close the connection
If the App uses the C++ DLL to first (1) open a ftp connection and
then (2) uplaod a file, then (2) will fail because it doesn't have an
open connection eventhough it was just created in step (1).
The COM component works as supposed because I've tested it in many
ways and an object is able to perform all kinds of FTP commands once a
connection is opened.
It's the C++ DLL that doesn't seem to reuse the instantiated object of
the COM class for some reason.
Here is some of the code:
(Try to ignore any code looking anciant like FAR PASCAL because it's
required by the App.)
------------------------------------------
char* buffer = 0;
const int STRMAX = 255;
MyInterop::IFtpCmdParserPtr pFtpCmdParser;
#ifdef __cplusplus
extern "C"
{
__declspec(dllexport) char* FAR PASCAL FtpCommand(long, unsigned
char*);
}
#endif
BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call,
LPVOID lpReserved)
{
CoInitialize(NULL);
HRESULT hRes =
pFtpCmdParser.CreateInstance(MyInterop::CLSID_FtpCmdParser);
That's problem 1:
You should not call CreateInstance or even CoInitialize inside DllMain.
Ideally, your DllMain should actually be an empty function, and you
should initialize the necessary things "lazily" when your api functions
are called.
See http://www.microsoft.com/whdc/driver/kernel/DLL_bestprac.mspx
switch (ul_reason_for_call)
{
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
return 1;
case DLL_PROCESS_ATTACH:
buffer = (char*)malloc(STRMAX* sizeof(char));
Really, you should avoid even malloc and free calls, since malloc
requires mutex locking.
if(buffer == NULL)
{
CoUninitialize ();
return 0;
}
else
{
return 1;
}
case DLL_PROCESS_DETACH:
free(buffer);
return 0;
}
CoUninitialize ();
return 0;
}
_declspec(dllexport) char* FAR PASCAL FtpCommand(long dummy, char* args)
{
This should start:
if (!initialized)
{
CoInitialize();
pFtpCmdParser.CreateInstance(MyInterop::CLSID_FtpCmdParser);
buffer = (char*)malloc(STRMAX* sizeof(char));
//add error checking!
initialized = true;
}
USES_CONVERSION;
_bstr_t bstrB(args);
BSTR b = bstrB.copy();
BSTR* bp = &b;
pFtpCmdParser->ParseCommand(dummy, bp);
char* char_p = W2A(c);
return strcpy(buffer, char_p);
}
------------------------------------------
The code works fine but as described each call to FtpCommand appears
to be using their own instance of the COM class which wasn't the idea.
Your code for DllMain called CreateInstance once when the process loaded
the DLL, and then once for every thread - I suspect that was what you
were seeing.
Tom