Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty
From: scotty@l5comp.UUCP (Scott Turner)
Newsgroups: comp.sys.amiga
Subject: Re: Further file format problems
Message-ID: <154@l5comp.UUCP>
Date: Tue, 26-May-87 17:57:51 EDT
Article-I.D.: l5comp.154
Posted: Tue May 26 17:57:51 1987
Date-Received: Sat, 30-May-87 06:42:36 EDT
References: <8705250320.AA18887@ingres.Berkeley.EDU>
Reply-To: scotty@l5comp.UUCP (Scott Turner)
Organization: L5 Computing, Edmonds, WA
Lines: 50
Summary: File identification is out of your worst nightmares.

In article <8705250320.AA18887@ingres.Berkeley.EDU> hatcher@INGRES.BERKELEY.EDU (Doug Merritt) writes:
>I am still having problems with distinguishing between different types
>of executables (program, font, lib, dev, handler). BTW, although there is
>supposed to be a "moveq #0,d0  +  rts" in non-program executables,
>this is far from dependable.
Yeah, I for one don't put in the moveq rts mumbo jumbo. It isn't required and
if a user executes my code instead of using as I DOCUMENT well Mr. Guru will
keep the world from imploding. :)

>rules that seem to make some files unidentifiable at all. Perhaps
>there is something about hunks that might straighten this out. Where
>are they documented???
Hunks are documented in the AmigaDOS technical reference manual from Bantam.
But don't expect this info to make life easier for ya. The Amiga binary file
structure is a just a way for storing data. It makes no comments on WHAT it
is storing.

>	If that fails, search an indeterminate amount forward for
>	RT_MATCHWORD == 0x4AFC [ as defined in exec/resident.h ], and if
>	found, interpret that as the first field of a struct Resident
>	and see whether the rt_Type field is equal to NT_DEVICE (0x03)
>	or NT_LIBRARY (0x09).
You should also verify that the RT_MATCH_TAG is correct before jumping in with
both feet. Be aware when digging through raw hunk data that this data can in
many cases change in value due to it's being patched by the relocater after
it gets loaded. For references inside the same hunk this shouldn't cause you
any trouble, but for links to hunks OUTSIDE the current hunk this CAN cause
problems. The easy solution to ALL your trouble with trying to decode the
hunk structure is just to do what the system does when it wants to get at
the code. Use the LoadSeg call from dos.library to load the file into ram
and then stare at it. Then when done call UnLoadSeg to toss it out of ram.
LoadSeg and UnLoadSeg are documented in the Bantam book. (see above)

>	If that fails, then it is either a regular program, a handler,
>	or a non-conforming library or device, which is a very uncomfortable
>	amount of ambiguity. The translator.library is not identifiable
That's life. Being able to identify what a file is was never it seems a real
concern in the minds of the people that designed the dog. But then again my
UN*X system has the same problems. :)

>	Finally, I can't find any method for distinguishing handlers from
>	regular executables at all. Anyone know how?
And finally we get down to the $64,000 answer. You RTFM that came with the
product. Which is why it's handy to get a FM in the first place.

Scott Turner
-- 
L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM.
GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020
If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs
[ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)