Christopher Blizzard wrote:
> Doug Turner wrote:
>
>> I think I take this statement back. I found a nice workaround. I
>> have tested Sun's JRE against my changes and it seams to work fine.
>> (I am using them because they use the service manager built against
>> xpcom around the time of netscape 6.0/6.1. I could have just as
>> easily used another plugin).
>
> I suspect you're just getting lucky. If you want to preserve
> backwards compatibility you have to maintain the old names of the
> interfaces as part of the calls into the service manager since the
> names of the types are used in the name mangling in C++. I would
> suggest just using nsIServiceManager and sticking big-ass warnings all
> over the header files that suggest using nsIServiceManager2.
I don't know about getting lucky. The 'solution' was to force the
correct type via casting. It is a sick solution, but the only one that
may work if we don't want a nsIServiceManager2.
The problem is this. There is this function member in nsServiceManager
which is used from plugins:
static nsresult GetGlobalServiceManager(nsIServiceManager* *result);
To maintain the symbol to pre-service-manager-change binaries, I need to
make sure that I do not change the parameter. My changes include
renaming existing nsIServiceManager to nsIServiceManagerObsolete. Now,
what do we do with this call? It need to return the old
nsIServiceManager named type, but I want the nsIServiceManagerObsolete
implementation returned. Okay, so I know how bad this is but, I force
the return type via casting. yicky.
What really sucks is supporting this static class anyway. Name mangling
fear should have stopped everyone from using this, but I guess there was
no other way to get the service manager. As of today, you can QI the
component manager (which is passed into your module) for the service
manager. After I check in my changes to the service manager, there will
be a new call NS_GetGlobalServiceManager. This call will be the
standard way to get the service manager.
