From: MERC::"uunet!WKUVX1.BITNET!MacroMan" 6-OCT-1992 00:00:19.44 To: MACRO32@WKUVX1.BITNET CC: Subj: Re: VMS shareable images, what's wrong with them? 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."