Ken Kozman wrote:
> > 1. Reduce functionality of XPCOM.DLL to ONLY maintain components
> > and component registry - equal to CoCreateInstance, CoInitialize
> > etc...
>
> This is a point well taken. We should just make an XPCOM API. This does
> include the component manager stuff as well as the memory stuff though.
> Basically everything which is in the MSCOM CoApi...
One thing that I did in XPLC that I think is a good improvement over the
MSCOM API design is having a single point of entry into the "XPLC DLL",
which hands you access to the API through the interface.
This way, it is easy to do versioning. One thing I am thinking of adding
to my "getComponentManager" call (the single entry point in question) is
a version parameter, which would come from a #define in the XPLC
headers, so that the XPLC DLL could be able to detect a version
discrepancy in a dynamically linked application and the XPLC DLL and
either give something else (maybe an interface to a wrapper around the
current API to support older applications, instead of the actual API
interface) or not give anythign at all (in the case where the API has
changed in a too fundamental way to provide support).
PNG has something similar. It pretty much amazed me when I installed an
RPM package of gif2png on my computer, which ran properly (the ELF
soname for libpng was compatible), but complained that the older libpng
I had did not support a specific feature I was trying to use (gamma
compensation or somesuch), and worked for other cases. Excellent
versioning, which yielded partial functionality, but better than a
dialog box saying something like "DINPUT.DLL not found" or ld.so
complaining that it can't launch an application because of missing
libraries.
--
"The number of Unix installations has grown to 10, with more expected."
-- The Unix Programmer's Manual, 2nd Edition, June 1972
