Office 2003 apps object model affect COM specification?

[Shodan]

Hello All,

Please look at following code:

HRESULT hr;
Outlook::_ApplicationPtr pApp;
hr = pApp.CreateInstance(L"Outlook.Application");

Outlook::_ExplorerPtr pExpl;
hr = pApp->ActiveExplorer(&pExpl);

// do something else...

if (pExpl)
hr = pExpl->Close();
--
When the user already have a running instance of Outlook, my code (last
line) will just close it. It will be very strange behaviour for end user,
when another process will close his Outlook. By MSDN CreateInstance will
_create_ a new object instance using IClassFactory::CreateInstance, which
_create_ an object. But I will get an existing running Application (instead
of new created). On the other side there is a COM specification, which states
that in case of changing method semantics you should create new interface.
Return existing Application instance instead of creating a new one is a
semantic change, so there is a violation of COM rules?

Another sample, about Word:

{
HRESULT hr;
Word::_ApplicationPtr pApp;
hr = pApp.CreateInstance(L"Word.Application");

// do something...

hr=pApp->Quit(&vtSave); // unload winword exe
}

Quit method is only one way to unload Word process, 'cos even when all
references to Word objects are released, winword.exe stay in memory. Upon
leaving method scope there is a first-chance exception catched by OLE, 'coz
proxy dll loaded in my process cannot reach stub code, which was unloaded
with Word process. Exception raised during execution of smartpointer's
destructor (ApplicationPtr), called leaving method scope. I think such
behaviour and existing of Quit method is inconsistent with COM model and
rules.

So Office apps really have inconsistency with COM rules, or I miss something?

 

[Sascha Trowitzsch]

Hi,

This is a part of MSDNs explanation on IClassFactory::CreateInstance:

"In general, if an application supports only one class of objects, and the class
object is registered for single use, only one object can be created. The
application must not create other objects, and a request to do so should return
an error from IClassFactory::CreateInstance. The same is true for applications
that support multiple classes, each with a class object registered for single
use; a CreateInstance for one class followed by a CreateInstance for any of the
classes should return an error.

To avoid returning an error, applications that support multiple classes with
*single-use* class objects can revoke the registered class object of the first
class by calling CoRevokeClassObject when a request for instantiating a second
is received. For example, suppose there are two classes, A and B. When
IClassFactory::CreateInstance is called for class A, revoke the class object for
B. When B is created, revoke the class object for A. *This solution complicates
shutdown* because one of the class objects might have already been revoked (and
cannot be revoked twice)."

HTH,
Sascha