CODEWITHSUNDEEP
cominteropcom-interopcom-server
kbisang
kbisang

Reputation: 576

How do I identify if a client of a Microsoft COM-Server is out-of-process or within the process?

I am not so familiar with the Microsoft COM Technology. In a nutshell I have an Microsoft Out-of-process COM Server that is implemented in the executable file foo.exe. The environment is C++ and the Microsoft Foundation Classes Framework (MFC).

There is a client bar.exe which uses functionality within foo.exe over the Microsoft COM Technology. Within foo.exe there are some Dynamic Link Libraries involved which uses also functionality provided by the COM Server foo.exe (for example fooBar.dll).

So far so good. I am on the road of searching a way to determine if the client of the COM Server foo.exe is in an other process or even within the same process as foo.exe such as fooBar.dll in the example above. Does anyone knows such a way?

Edit: With other words: Obvious the COM Server foo.exe can act as an in-process or an out-of-process COM Server. To add up to the comment of Hans Passant and the answer of Joe Willcoxson who is proposing to address the calling DLL via GetModuleHandle to determine if the COM Server acts currently as in-process Server, in case when I got the handle and in case when I not got the handle as out-of-process Server. So it seams that when the COM Server is aware of well-known DLLs which uses functionality from that server within the same process, we could say that the COM Server acts in this moment as in-process Server and in other case as out-of-process Server. Do I misunderstand something or are these considerations correct?

My investigations for the moment are not mentionable so I hoping there is a Microsoft COM Expert in the community who knows how the barrow runs.

Thank you very much for help!

Upvotes: -1

Views: 187

Answers (2)

kbisang
kbisang

Reputation: 576

Within the COM Server foo.exe you can do following.

CTheApp::InitInstance()
{
    [...]
    bool runAsOutOfProcessServer = false;
    CCommandLineInfo commandInfo;
    ParseCommandLine(commandInfo);
    if(commandInfo.m_bRunEmbedded || commandInfo.m_bRunAutomated)
    { 
           runAsOutOfProcessServer = true;
    }
    [...]

    if(runAsOUtOfProcessServer)
       AfxMessageBox("Out of Process Invocation");
}

Obvious there are two members in CCommandLineInfo which indicates that the process is started up as OLE Automation Server or started up to edit an embedded OLE item. With ParseCommandLine you got the information over call by reference to the local variable commandInfo. Then you can check if the members m_bRunEmbedded or m_bRunAutomated are set to determine if the COM Server within foo.exe is started up. Then at the end you can pop up your message box only if the local variable runAsOutOfProcessServer is true.

Upvotes: 0

Joseph Willcoxson
Joseph Willcoxson

Reputation: 6050

I am not sure of how you would do it once you already have a COM pointer. However, there is a way when you are creating the object.

The CoCreateInstance() function takes flags CLSCTX_INPROC_SERVER, CLSCTX_INPROC_HANDLER, CLSCTX_LOCAL_SERVER, CLSCTX_REMOTE_SERVER.

Usually the default arguments when you use something like ATL is to combine the flags and it just returns whatever is available. Instead of doing that, you can try the flags individually and see if the object gets created with a particular flag.

I should add that there is sort of a way if the object is actually an OLE object/server. If that is the case, then you can query for IViewObject. If it's in-process, it won't have that interface. If it's out of process, then it will have the interface.

One other thing, if the object implements IRunnableObject and you did not do anything to specifically put it in the running state, then an in process object will most likely be in the running state, and the out of process object will not be in the running state.

A very simple hack may be to call GetModuleHandle() with the name of the DLL. If it returns a handle, then it is in-process. It's not a generic solution, it requires you know the name of the DLL beforehand.

Upvotes: 1

Related Questions