[coyotos-dev] DLL's

[Eric Northup]

On Wed, 2007-05-23 at 12:55 -0400, Jonathan S. Shapiro wrote:
[...]
> DLLs are a can of worms at the conceptual level. One problem is that
> applications rely on behavior in addition to interface. When a DLL is
> updated, the interface may remain the same while the behavior changes in
> a significant way. Many applications either (a) don't care, or (b)
> prefer the risk of upgrade to the risk of existing, unrepaired errors,
> or (c) prefer the risk of upgrade to the preservation of existing
> security flaws. Other applications are what we might call "qualified",
> in the sense that they have been tested against specific implementations
> and need to continue to use those implementations. This can be handled
> by static linking, but you may have noticed that static linking is going
> the way of the dinosaur. The latest numbers are that 20% to 75% of the
> code executed by a typical application comes from a library somewhere.
[...]
> 
> Finally, there is the issue that processes survive shutdown, and this
> violates many of our assumptions about how quickly a new DLL will be
> adopted by those applications that wish to do so.
> 
> So in the end, this all folds in to a general "object upgrade" problem
> that is one of the really nasty sleeping dragons in the entire
> object-based system story.

This isn't entirely related, but Dolstra, et al presented an interesting
paper at HotOS '07 (Purely Functional System Configuration Management),
which looks like it's at least the beginning of a framework with which
to describe the dependencies involved in DLL versioning.

The long-running processes problem isn't addressed by their framework,
though, unless there is a mechanism for them to dump/restore their state
(potentially across upgrades, even).

-Eric