From:	MERC::"uunet!WKUVX1.BITNET!MacroMan"  5-OCT-1992 22:07:13.16
To:	MACRO32@WKUVX1.BITNET
CC:	
Subj:	Re: VMS shareable images, what's wrong with them?

In a recent article I wrote:
>> DEC ought to redo their shareable-image technology. The current method
>> was invented almost 15 years ago and has a variety of problems.

And Nigel Arnot responded:
>        I'm curious. I know that making a shareable image can be tedious,
>but once put together they seem to work rather well. What improvements
>do you have in mind, and has anyone done something like them already?

The Big 3 that come to mind:

1. Writeable psects should default to "no-share" in all the higher languages.
2. Transfer tables should go away.
3. Shareable image version numbers should go away.

#1 is an artifact of the way someone at DEC was thinking about
virtual memory in the early days. The rule became "if you're shared,
and you have a Fortran common block, say, you MUST be trying to
communicate through writeable shared memory - why would any user
program want to be shared otherwise??"   Only later did code
modularity, and library shareable images, become interesting
concepts, and by then it was too late to change the defaults.
Everyone with portable code nowadays has to has to use a linker
options file to override all the compiled psect declarations.

The way to achieve #2, the departure of the transfer table, is by
"lazy binding" of symbols - the linker just checks that the symbols
needed are there in the current version of a referenced shareable
image; the image activator does the work at run-time of making the
final symbol-to-address binding. The first time I saw this, years
ago, I said "naah, that can't possibly be fast enough - image
activation will be slowed down bigtime." Being scientific, I
immediately set out to prove my foregone conclusion. Un-for-tunate-ly,
in all the torture tests I could dream up the slowdown due to the
dynamic binding was either trivial or completely undetectable. And
since then CPU's have gotten a lot faster. (The activator code I was
testing was probably a BSD4.3 Unix derivation on a Sun. They did a
good job of that code.)

The primary purpose in life of #3, the shareable image version
numbers, is to guard to the transfer table against "accidents". Once
the transfer table is gone (#2) one can immediately do away with the
version numbers (or change the default setting to "match any".)
You'll recall that version-number unpleasantness on Vaxcrtl.exe is
what got us started on this thread originally.

Wouldn't it be nice to build a shareable with a simple /SHARE,
no options file and no assembler code?

Finally, Mark Porter points out to me privately that there is a
security problem in this area. Which I won't go into. (As far as I
can see he's right.)

Garry Wiegand --- garry@ithaca.com --- Ithaca Software, Alameda, California