Pierre Phaneuf
2004-01-30 16:21:25 UTC
Avery Pennarun wrote:
Moving this to xplc-general...
Your module loader will know exactly which dlls provide which UUIDs
(or monikers), and you could write a little script to grab just
those, throw them in a zip file, and ta da! Instant linker.
Yeah, but it won't know what a program or a module needs (there's no
direct equivalent to "nm -u" or "ldd"). So you don't know what to grab.
This is a pretty difficult problem, which I am just ignoring at the
moment, hoping that nobody will really notice. :-)
For example, imagine that programs and modules could somehow specify
what they want. We'd have to separate what they positively need (and
can't run at all without) and what they can use optionally. With
categories, you might want to specify that you need at least component
of a category (it doesn't matter which component exactly). With
monikers, you might want to have at least some specific monikers, or
some monikers of a kind at least or something (monikers are especially
loosely bound, which is their coolest feature, but is most annoying in
this attempt to find some static information).
To top this off, a module advertising a UUID is not garanteed to provide
it. It might decide that you are missing some other stuff (for example,
a component to support MNG files (which are a superset of PNG files)
could need a component providing support for PNG files), so just looking
at a module and seeing a given UUID doesn't mean that you're good.
One thing that could be feasible would be a program that has a special
tracing module loader and loads a module that you give as a parameter,
and would then be able to report the UUIDs that the module attempted to
load (real easy) and in which modules it found these UUIDs (not as
easy). That wouldn't be perfect, but could be helpful.
Moving this to xplc-general...
XPLC is going to have the same problem...
http://www.joelonsoftware.com/articles/PleaseLinker.html
But it's only 18 *kilobytes*. ;-)
I don't understand... how can you have the same problem?http://www.joelonsoftware.com/articles/PleaseLinker.html
But it's only 18 *kilobytes*. ;-)
Your module loader will know exactly which dlls provide which UUIDs
(or monikers), and you could write a little script to grab just
those, throw them in a zip file, and ta da! Instant linker.
direct equivalent to "nm -u" or "ldd"). So you don't know what to grab.
This is a pretty difficult problem, which I am just ignoring at the
moment, hoping that nobody will really notice. :-)
For example, imagine that programs and modules could somehow specify
what they want. We'd have to separate what they positively need (and
can't run at all without) and what they can use optionally. With
categories, you might want to specify that you need at least component
of a category (it doesn't matter which component exactly). With
monikers, you might want to have at least some specific monikers, or
some monikers of a kind at least or something (monikers are especially
loosely bound, which is their coolest feature, but is most annoying in
this attempt to find some static information).
To top this off, a module advertising a UUID is not garanteed to provide
it. It might decide that you are missing some other stuff (for example,
a component to support MNG files (which are a superset of PNG files)
could need a component providing support for PNG files), so just looking
at a module and seeing a given UUID doesn't mean that you're good.
One thing that could be feasible would be a program that has a special
tracing module loader and loads a module that you give as a parameter,
and would then be able to report the UUIDs that the module attempted to
load (real easy) and in which modules it found these UUIDs (not as
easy). That wouldn't be perfect, but could be helpful.
--
Pierre Phaneuf
Mad Scientist, NITI R&D
Pierre Phaneuf
Mad Scientist, NITI R&D