On Sun, Jul 01, 2001 at 05:21:47PM -0400, ZN wrote:
> On 7/1/01 at 7:15 PM Dilwyn Jones wrote:
> 
> >Executables can be tested via the FTYP function (type 1 is executable)
> >of Toolkit 2.
> 
> Yes, they could also be identified (and some more interesting info gleaned)
> from the first couple of bytes, the executable header. Don't remember the
> definition of the top of my head, but I know hex 4AFB appears in it :-)

its just a convention, not strictly required for executables. 

c68 programs can be easilly recognised, they have 'C_PROGRAM' as program 
name before it gets overwritten by the jobs real name.

> Resident extensions cannot be recognized as they are just pieces of code,
> they are called after they are loaded (LRESPR), but don't have any defined
> headers etc.

they can be recognised because every piece of code that is not a job
must be a resident extension and code as such should be recognisable 
although it is not quite trivial.

Another type of extension with a distinct header are extension ROMS, 
they wont appear as files very often.

> There is also file type 2 (or was it -1?) for linker files. Pity the file
> type isn't used more often.

No!!!!!!!!! It is fundamentally flawed to store filesystem metainformation
and application specific data at the same place.. in the very same byte.
There are only 255 possible types and the filesystem may need more in the 
future. There were already cases in the past where the types clashed,
Hirschbiegel's subdirectory devices used the same type 2 as qmac relocatable 
object files.
Last not least it adds necessity for additional checks in the filesystem
code, it must test whether a set-header operation sets the header to
a value that doesn't conflict with its internal use. Have great fun if 
you define a filetype of 3 or 4 and transfer such a file to a Thor 
machine (they used this values to mark subdirs).
The use of the executable filetype and dataspace is somewhat excusable 
as it was probably intended to be used in a 'load & execute' trap (that 
was never implemented) and thus of immediate relevance for the OS.
Everything else should be abandoned or at least marked obsolete.

Quite a number of formats (jpg,gif,tar,gzip,zip,bzip*) are very
easilly recognisable with the 'file' program, I suppose it could be
extended to handle all QDOS specialities.

Bye
Richard

Reply via email to