🚀 go-pugleaf

Date sent:  5-OCT-1992 19:06:39

        You know what I REALLY HATE???  It's people who BITCH AND
        MOAN and really don't say much of anything relevant.

Example:
Gary@Ithaca writes:
>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.

        Wow, how utterly devoid of information.  What's wrong with
        a 15 year old method?  They've been talking about progress
        for years and we still use shovels to dig holes.

>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.

        Learn to understand your linker.

>2. Transfer tables should go away.

        Bzzz.  Wrong.  See below.

>3. Shareable image version numbers should go away.

        Bzzz.  Wrong.  See below.

>#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.

        So what's your point?  In some cases you WANT the section
        writeable.  In others you don't.  It has to default to
        something and you'll have to option/other_method it
        to do the non-default.  If your whole moaning and whining
        is because it defaults to shared write, why not make this
        a specific beef instead of whining about version numbers.

>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

        Oh yeah right.  Like I want a symbol table in every image.
        Perhaps you simply don't UNDERSTAND that the use of shareable
        images is for the creation of SMALLER and more efficient
        images.  A Tranfer table avoids the possibility of mapping
        incorrect vectors as well as not passing the translation
        buck to the image activator.

>ago, I said "naah, that can't possibly be fast enough - image
>activation will be slowed down bigtime." Being scientific, I

        Being human (I don't know what A Scientific is) I usually
        look at the big picture.  In this case you will need to
        give the symbol table to every final image.  Gone will be
        the days of user-PATCH-proof code, gone will be the security
        of SYMBOLS THAT CHANGE THEIR MEANING IN DIFFERENT VERSIONS
        and FOREVER must keep the obsolete name.

>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".)

        And of course because I disagree with #2 and have shown
        why you oughtn't get rid of it, I concur that version numbers
        are still required.

>You'll recall that version-number unpleasantness on Vaxcrtl.exe is
>what got us started on this thread originally.

        Yes.  Bugs can occur.  However, your ``solutions'' present
        more theory than reality.  It reminds me of other Scientifics
        I've had to deal with.  Very good on theory, but useless
        in real life.

        So this hacker, field service engineer, and a Scientific
        are in a car and coming down a steep hill the breaks appear
        to fail.  The Hacker (who is driving) pumps the break and
        downshifts and finally the car comes screeching to a halt
        JUST at the edge of the precipice with two wheels over the
        edge.

        The Hacker suggests they fix the breaks.
        The field service engineer suggests they call in an expert.
        The Scientific says "Let's start moving and see if the
        brakes fail the same way again."

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

        It sure would.  Why don't you come up with some method
        of defaulting linker options and then we can all be happy.
        You won't have to understand option files, and I won't have
        to explain to people who use my images why they are bigger,
        take longer to transfer, and have lots of obsolete and
        not-to-be-mentioned-in-polite-company symbols, and why
        they shouldn't patch them.

>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.)

        Ah yes, another example of a Scientific not giving any
        informatin.  I'm sure you know it all, so why not fix
        it all and then let us know so we can send you shareware
        money or accolades or Encyclopedia Brittanicas or whatever
        you Scientifics (tm) do for fun...

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


        Aww mom, why are people afraid of options file?
                It's ok little Ehud, people are always afraid of things
                they have a fear of.

        Ehud

--
Ehud Gavron        (EG76)
gavron@vesta.sunquest.com
"The world bores you when you're cool."