C++ using COM  
Author Message
DougJohnson





PostPosted: Mon Dec 11 06:38:58 CST 2006 Top

Visual Studio C++ >> C++ using COM

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);

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));

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)
{
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.

If anyone has experience with this and have ideas as to why this is
happening, it would be much appreciated.

PS. I'm no C++ wonder, so try to keep any reply without too many C++
specific terms unless acompanied by some links, thanks :)
(I'm a C# kinda guy myself).

/Aidal

Visual Studio82  
 
 
Ulrich





PostPosted: Mon Dec 11 06:38:58 CST 2006 Top

Visual Studio C++ >> C++ using COM
> BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID
> lpReserved)
> {
> CoInitialize(NULL);
>
> HRESULT hRes = pFtpCmdParser.CreateInstance(
> MyInterop::CLSID_FtpCmdParser);
>
> 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));
> if(buffer == NULL)
> {
> CoUninitialize ();
> return 0;
> }
> else
> {
> return 1;
> }
>
> case DLL_PROCESS_DETACH:
> free(buffer);
> return 0;
> }
>
> CoUninitialize ();
> return 0;
> }

Look up the documentation for DllMain() in the MSDN[1]. You will see when
this is called. Then, imagine the case of your program, step through the
function and look at what it does. You will notice:
- some parts will never be called
- some parts that should only be called once are called multiple times

Further, what is 'buffer'? Why isn't it just a static array, because that's
what it is used as! Also, why the strange size of 255 characters? Oh, and
BTW, the size of a C++ 'char' is by definition 1, no need for it in the
call to malloc(). Lastly, DllMain returns a BOOL, and while this is
technically no difference, it would be better if you used TRUE and FALSE
instead of 1 and 0 as returnvalues.

Uli

[1] msdn.microsoft.com

 
 
Tom





PostPosted: Mon Dec 11 06:42:20 CST 2006 Top

Visual Studio C++ >> C++ using COM
> 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
 
 
Aidal





PostPosted: Mon Dec 11 07:33:44 CST 2006 Top

Visual Studio C++ >> C++ using COM Tom Widmer [VC++ MVP] skrev:

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

Ulrich and Tom, thanks for your prompt replies, it's always great when
somone takes the time to lend a hand :)

For all the "why are you doing?" questions I can only say that the app
that needs to call this thing is very strict as to how things should
look, and I'm merely following the example I got to work from.

I'm gonna try to rewrite some stuff and see if I can fix the problem
which very much sounds like it has somthing to do with what Tom said
(plus that's what I understood the best hehe).