http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #43 from oiaohm oiaohm@gmail.com 2011-04-06 08:23:51 CDT ---
Okay, so let me try to summarize to see if I've got it right:
CLSCTX_INPROC_SERVER creates and manages OLE objects in the same process as the application that uses them. This is fine if the object is not shared between multiple applications, for example, because each instance of an application can only use its 'own version' of the OLE object, which is different in every process.
This is what you missed. INPROC SERVER has a CLSID
CLSCTX_LOCAL_SERVER creates and manages OLE objects on the same machine, but on a different process than the user application. Ie. the application containing the object we want to use has to be launched, it will itself call CoRegisterClassObject on startup, thus registering itself as an OLE object (in our case, with the CLSID {629f8434-0530-41e6-b7c5-61a82faa3df2}) so that any application on this machine can access the same, shared instance of this object running in a dedicated process.
And Local Server has a CLSID.
CLSCTX_INPROC_SERVER and CLSCTX_LOCAL_SERVER start something to handle a CLSID call. One is in the same process one is not.
That is why the alteration works for your application. Problem is this is not always the case. Yes more often than not it will not be the case. Because if it was the programmer would have used inproc instead.
Problem is also handler for INPROC and LOCAL could be two different things as well ment to give application 2 different results even that is the same CLSID.
CLSID is a point in the road where you can cross the streams and appear to have everything working when really its a timebomb waiting to explode. Since CLSID does not tell if it what is for is INPROC or LOCAL. Call flags to operations tell it if its INPROC or LOCAL that should be connected to.
LOCAL Server is one group of trouble. INPROC is another.
Some of this is a question do you need test cases.
Basically there is a devil here. I would recommending testcasing how windows handles no LOCAL_SERVER but a INPROC_SERVER being on hand yet a connection to LOCAL_SERVER has been requested. I would not be surprised if windows has some strange fail through system. But this would not be override flag every time. Sometimes connecting to LOCAL_SERVER would happen.
At this stage not enough information to know exactly what is going wrong. Either is something warped in windows or LOCAL_SERVER is not registering in the installer for some reason. Basically something has gone wrong.
Patch you had created is just masking not fixing.