At 12:54 �� 2/7/2001 +0200, you wrote:
>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
Yes I understand they are not standard. However a quick check on each for
existence on "unknown" extensions, would give my program at least a clue on
what it is. Furthermore a database-like search file could be used that
would interactively (ie by asking the user the first time it encounters
that file about the type) would store the type so it would be used from
then on :-)
Phoebus
