 Installation ============  E You will probably have received BLDSHR as a VMS_SHARE archive, which  F you have presumably unpacked (by executing it as a command procedure).  J To create the binaries, execute @KITBLD with your default directory set toH the one containing the kit files. You will also have to edit one line in< BLDSHR.COM to identify the directory containing the utility.  E BLDSHR is copyrighted, simply so that nobody can start selling it for H profit without my consent. See CONDITIONS_OF_USE.TXT. Apart from sellingF it, you are free to use and distribute it in any way you like, and the1 author takes no responsibility for any bugs, etc.    About the code ==============  G BLDSHR grew out of an earlier hack, which used DCL to read through link J .MAPs, analyze image outputs, etc. This took many minutes of CPU and broke< every time DEC upgraded VMS and changed the listing formats.  F BLDSHR gets all the information it needs by scanning object code. ThisD makes it pretty fast, and less liable to break across VMS releases. F (I don't think DEC are into changing the format of object code: I haveI a few routines compiled on VMS 1.6 that still link and run OK. Of course, * once Alpha arrives all bets may be off :-)  K It had a troubled gestation. Version 0 ran in 1987 for me, but was a crock. < I was too busy on other things to tidy it up and release it.  G In February 1992 I foolishly mentioned it to the MACRO32 mail list, and M several folks asked for it. I hadn't realised at that stage what a disgusting E state it was in, and have spent the last few evenings shaking out the I bit-decay and assorted bugs. I think it's now supportable. I don't regard < it as one of my better bits of code, but is is quite useful.  J The main program, BLDSHR.FOR, is driven by a DCL procedure BLDSHR.COM thatE does most of the filename manipulation. BLDSHR has two passes. In the H first, it reads through a .OBJ file (created by BLDSHR.COM by extractingF the entire contents of your object library). It builds two tables, oneL of entrypoint names and the other of PSECT names with the WRT,SHR attributesG (which are probably FORTRAN common blocks that need to be overridden to ! NOSHR when you build the image).    H After the object file has been scanned, BLDSHR marks all names that haveJ already been handled in the previous version of the shareable image, whoseG transfer vector is defined by a file that I call a vector or .VEC file. F This is in fact macro-32, but mostly macros so it looks like a specialH file. Any entrypoints of PSECTS that are not already handled are writtenF out to an updates file (.UPD), which you edit. If there is no previousI VEC file, then you are presumed to be building the first-ever version 1.0 H of the shareable image, and all the symbols in the tables get written to
 the UPD file.   G Entries in the UPD file when you start editing have one of these forms:    	VECTOR name 	PSECT  name  E The former declares a transfer vector entry that will be added to the K previous transfer vector code (at the end, of course!). The latter declares O a PSECT that will have PSECT=name,NOSHR specified when the shareable is linked.   I If a routine is private to the library rather than callable by its users, E you should edit "VECTOR name" to "IGNORE name". If you are updating a I shareable, you can add VECTOR statements for previously IGNOREd routines. L You can delete PSECT lines if you really want the SHR attribute, and you canL override the shareable version number (see USERGUIDE), the default for which$ is to bump the minor version by one.  M The second pass reads the original VEC file (if any) again, and then edits it I using the information in the UPD file. The result is written out as a new E vector file. This mew vector file is assembled ($MACRO) together with E macro definitions in VECLIB.MLB to get a transfer vector object file. I Tlis object file is LINKed against the original object library to get the L shareable image, which is called SHAREABLE_xxxx.EXE, where xxxx was the nameI of the original OLB file. The second pass of BLDSHR also generates a .OPT P file used to link to SHAREABLE_xxxx, and a file of type .PSC which is an options( file used while creating SHAREABLE_xxxx.  M BLDSHR attempts to protect users from the disastrous consequences of meddling M with the order of the entries in a transfer vector. It does this by attaching L a (slightly encrypted) sequence number to each VECTOR entry in the VEC file.M If a user rearranges the VECTOR definitions, BLDSHR will notice and complain. H The 'encryption' is to stop him editing an obvious linear sequence, but 7 can be decoded in ones head should the need ever arise.   I THe first few lines of BLDSHR declare the maximum size of the tables used N for storing names. A table requires three longwords (INTEGERs) per entry, plusP enough longwords to hold a symbol's name as a counted ASCII string. The defaults/ will cope with a good few thousand entrypoints.     K OBJSCAN.FOR is the code that scans an object file looking for WRT,SHR psect ( definitions and entrypoint definitions.   I SYMTB.FOR are routines for manipulating a symbol table. The symbol lookup H uses a hash table for speed: this might be regarded as overkill, but theK routines were written for a different application and modified slightly for 
 use here.   I VECPARSE.FOR analyzes the contents of VEC and UPD files. ERROR.FOR issues  error and warning messages.    Contacting the author  =====================   N BLDSHR was written by Nigel Arnot, dept. Physics, Strand, London WC2R 2LS, UK.   phone: +44 71 873 2583  O e-mail NRA@UK.AC.KCL.PH.IPG   (for example, NRA%UK.AC.KCL.PH.IPG@UKACRL.BITNET) I                               (the UK is big-endian, your mailer may want F                                NRA@IPG.PH.KCL.AC.UK, or it may not...)  K If you find bugs, let me know. I don't guarantee to fix them, but if I have  time I probably will.   G If you make improvements or fix bugs, I'd also appreciate knowing about  the changes.  