Libraries

[Dennis Marer]

> Hi!
> 
> I think that having the seperate concepts of module, library and object 
> is overkill. Can't we merge these into a single concept and simplify life?
> 
> Michael

I think the reason I came up with these concepts in the first place had to
deal with what was being loaded into memory at one time.  Objects tend to be
small, and if they were each loaded seperately, linking would be hell and
take up lots of overhead.  The concept of a module is to put into a single
unit a group of related objects *and* functions *and* data (not just objects).
It is a *tightly* related collection of things.  A library is a more loosely
related collection of modules, and doesn't really concern the kernel at all.
It was thought of originally as a convention for storing stuff on disk.

Windows and OS/2 have DLLs, which would be equivalent to what I call a module.
A "library" in my mind is a much larger entity than a module, but a module is
the smallest chunk of code which will occupy a portion of memory allocated
by the kernel.  All code in a module sits at a particular priviledge level.

I can't see doing away with the concept of a library - our system stuff itself
may need 20 to 30 modules, the GUI may need 10 or 20, and so on.  Combining
these into a library simplifies life on disk, so this is a concept important
to the filesystem only.  (A group of files within a file?)  If the *entire*
system library were loaded at run-time, we'd have the same problem as OS/2
and Windows - it would take tons of memory to run.  To load only those parts
necessary, libraries are broken into modules which can be loaded and linked
to at run-time of an application.  If an app runs and the module exists in
memory already, no load is necessary.  (Just like DLLs, just different names.)
Only those portions used by a program are loaded, at run-time.

In this scheme, a program *is* a module with (in C terminology) a "main"
function to be called once the program is loaded.

Again, if objects are loaded individually the overhead would be tremendous -
if the entire OS or GUI is put in a single module, memory usage would be
outrageous.

I think some of you were asking why not make modules and programs objects?
This would be nice, except who would benefit?  The only entity responsible
for (and allowed to) manipulate modules is the kernel.  Nobody else needs
really any interface at all to modules except information gathering for
linking purposes. It's really a toss up - it's a nice convention to make
everything an object, but it may not be useful.  We'll see!

			Dennis