On Mon, Jan 29, 2001 at 11:22:19PM -0500, Pierre Phaneuf wrote:
> Ari Heitner wrote:
>
> > > Note that it isn't the linker that gets libraries in the components
> > > directory, it's XPCOM itself, using dlopen (or whatever the platform
> > > uses, through NSPR).
> >
> > That's the whole point. In the COM framework, you don't know what libraries
> > the code you depend on resides in until runtime. This has a key problem: you
> > can't tell if you've resolved your dependencies at install time!
> >
> > The result: software that doesn't run because of evil dependency errors.
>
> As I already explained, this is both a curse (as you describe) and a
> feature.
no no no! it's *only* a curse! it provides no new functionality!
>
> For example, my Quadra game can run both using Xlib or Svgalib. It
> shouldn't require both or one specifically, it should just use what is
> there. If I linked explicitly with Xlib, then it wouldn't be able to run
> in an Svgalib-only environment, and the reverse.
that's a borken example, i'm sorry. SVGAlib and Xlib are not equivalent
(except conceptually). This is more like having a Vesa-based and a
Windows-based version, in the M$ world (did just that once years ago;
required the same damn games).
A *good* example is GL. I can have the software Mesa renderer installed, or
any of several flavors of hardware GL from my vendor, or even perhaps funky
stuff like a distributed-rendering GL.
*all* obey the contract of
- living in libGL.so.<version>
- providing the GL functions
now obviously you may need some magic to get around compiler-specific
name-mangling. But that doesn't mean you can't by standard bind some
functionality to some library and then play typical COM games (i.e. extern
"C" factory function in the library; standard-vtable interface objects
passed across library borders).
There aren't that many examples of this on Unix -- it's not as pervasive.
Perhaps this is because examples where you actually need that flexibility
aren't that common -- it's rare for there to be multiple implementors of a
given interface. Pretty much the only sane instance i can think of is the GL
case -- hardware-specific driver-type stuff.
In other cases (in the OSS world) there's generally only one implementor for
anything (why waste effort?). But if you *did* want to allow multiple
implementors, it would work fine.
...
Actually, debian does this a hell of a lot -- allows you to install one of
several packages which provide a "virtual package" -- i.e. some bit of
functionality that's implemented one of several different ways. so different
people can provide /bin/vi for example.
...
so yeah, i don't see what the COM people are gaining by not knowing what
library their expected functionality resides in, except for the fact that
they have *zero* guarantee *ever* that their program will run! as long as my
program links against libGL.so.1, i know that if that file is available,
*someone* is agreeing to provide *something* like the right stuff, so at
least my application will start up :)
>
> > Windows is *the same* as Unix in every major respect except the way the
> > distribution is managed :)
>
> Managing the Windows infrastructure? Isn't that the kind of thing little
> gnomes come and do at night? ;-))
>
lol! they must be the same as those nasty car-key gnomes ...
ari
