[Info-vax] Non-portable code

[Jan-Erik Söderholm]

VAXman- @SendSpamHere.ORG wrote:
> In article <hi1u2a$s9s$1 at news-01.bur.connect.com.au>, "Richard Maher" <maher_rj at hotspamnotmail.com> writes:
>> Hi Marc,
>>
>> <VAXman- @SendSpamHere.ORG> wrote in message
>> news:00A971CB.1A391FDB at SendSpamHere.ORG...
>>> In article <mn.2d1b7da1fb0d0bdb.104627 at brutele.be>, Marc Van Dyck
>> <marc.vandyck at brutele.be> writes:
>>>> G'd evening to all...
>>>>
>>>> I have a program on my systems, that was written in the VAX ages,
>>>> and that I use to display which version of layered products, tools,
>>>> etc,
>>>> are installed. It simply extracts from the image headers the version
>>>> info that has been put there by the linker, with the IDENT clause of
>>>> the link options file.
>>>>
>>>> Here is an extract of the code that does it (Pascal) :
>>>>
>>>> RESET ( f ) ;
>>>> buffer := f^ ;
>>>> CLOSE ( f ) ;
>>>>
>>>> addr := IADDRESS (buffer) +
>>>>        buffer[EIHD$L_IMGIDOFF+1]::$UBYTE +
>>>>        EIHI$T_IMGID ;
>>>> image_id.LENGTH := 0 ;
>>>>
>>>> LIB$MOVC3 ( word_integer_length := 1 ,
>>>>            source := %IMMED addr ,
>>>>            destination := image_id.LENGTH ) ;
>>>> addr := addr + 1 ;
>>>> STR$COPY_R ( destination_string := image_id.BODY ,
>>>>             word_integer_source_length := image_id.LENGTH ,
>>>>             source_string_address := %IMMED addr ) ;
>>>>
>>>> (Assuming that f is an executable image file and image_id the place for
>>>> the info that I want to obtain)
>>>>
>>>> EIHD$L_IMGIDOFF and EIHI$T_IMGID are declared as [EXTERNAL,VALUE]
>>>> variables and resolved at link time by inserting a .STB file (don't
>>>> remember which one, I'm at home here) in the link options file.
>>>>
>>>> This works perfectly well on VAX and Alpha. On Itanium, it compiles
>>>> but either gives false results, or even ACCVIOes (I suppose that it
>>>> happens when what I read in buffer[EIHD$L_IMGIDOFF+1] is absurdly
>>>> high).
>>>>
>>>> So, a few questions :
>>>>
>>>> For Integrity images, is the method I used above still valid - but with
>>>> wrong offsets - or am I completely screwed up ? If positive, what are
>>>> the offsets that I should use ? If not, how should I do ? Is it
>>>> documented somewhere ?
>>> This will NOT work on IA64.  You need too study ELF.
>>>
>>>
>>>> If the offsets EIHD$L_IMGIDOFF and EIHI$T_IMGID are wrong on Integrity,
>>>> why is it possible that the program compiled and linked with no problem
>>>> at all ? I would have expected that those either have the correct
>>>> value,
>>>> or do not exist at all, in which case the link would have failed. Where
>>>> am I wrong ?
>>> They're not wrong.  The image format was NOT devised by DEC/Compaq/HP and
>>> VMS engineering.  The chose to go with ELF.  Check $ELFDEF in STARLET.MLB
>>>
>>>
>>>> If I need to have code differences between the VAX/AXP and the I64
>>>> version, do I need to have two separate source files, or does Pascal
>>>> provide some way of conditional compiling ?
>>> Pascal specific questions are best left to John Reagan.  I've done
>>> what you are seeking to do in Macro32 with a common source file.
>>>
>>>
>>>> Many thanks in advance for your help. This is the first time I
>>>> encouter code which is not source-compatible between the 3 VMS
>>>> hardware architectures...
>>> You haven't looked very hard! :)
>>>
>>> -- 
>>> VAXman- A Bored Certified VMS Kernel Mode Hacker
>> VAXman(at)TMESIS(dot)ORG
>>>   http://www.quirkfactory.com/popart/asskey/eqn2.png
>>>
>>>   "Well my son, life is like a beanstalk, isn't it?"
>> Not sure if it helps but Tim Sneddon (pretty sure it was him?) put me onto
>> the DCL Symbol populating functionality with Analyze/Image.
>>
>> I'd include the bit from our KITINSTAL.COM (IA64) but I can't get there at
>> the moment as the IP Address regime is all over the place with
>> Browser\OS\Hardware versioning Tests :-(
>>
>> Anyway, IIRC at least for us it was the mut's nuts.
> 
> ANALYZE/IMAGE on the Itanium *WILL* create DCL symbols with the information
> he is seeking but it's not very practical from within a program.  I'm not a
> fan of SPAWNing a process to run a DCL command(s) to access information and
> there would be more than just SPAWNing to run ANALYZE/IMAGE as the symbols
> it would create would be visible only in the subprocess.
> 
> Reading the image file itself to garner the information isn't difficult but
> it's not as simple or straighforward as 'twas in days of VAX and Alpha yore
> to locate it.
> 

Right, my *guess* here is that he is identifying the target EXE's
from some DCL routine and then running the Pascal program one EXE
at a time to extract the IDENT. In that case (which is more plausible
then having the Pascal program also finding the EXE's) it just as
simple to run ANALYZE/IMAGE for each EXE as to RUN <the-Pascal-program>
for each EXE...

I do not think this has to be run that often that any performance
issues with a DCL script can be of any importance here.

I see absolutely no reason to try to read the EXEs directly when
ANALYZE/IMAGE does the same job for you. In a plattform idependant
way also.