16 Dec
1998
16 Dec
'98
11:02 a.m.
< If you look through memory, you can find the string BARSBAIT.
<
< > The Commodore's filetypes are silly. PRG, SEQ and USR are all just seq
< > Only REL is truly different.
generally in OS design there are only a few significant extensions
(filetypes). the most common are:
.EXE (executable, generally fixed address)
nearly always a binary loaded at a nominal standard address.
.COM also executeable but vary in composition
Can be a binary, often in DEC systems it's a command file (SCRIPT).
.SYS commonly drivers or system specific and usually loads differently
(unique address or relocated).
Most others are application specific and the OS treats them as "files"
and it's up to the apps to do the right thing. Clearly Windows has
carried that to the opposing extreme such that the extension determines
the action but that is not at the file level it's at the command
processor (GUI) level. Likely the extreme at the other end of the
spectrum is CP/M-80 where .com is significant to the command processor
and all others are only significant to apps. It allows for TYPE FOO.COM
where FOO.COM is a binary that would load at 100H and looks like Greek
on a vt100.
In most OSs at the basic file level (FILE SYSTEM) one type is the same
as another. the differentiation often occured at a higher level where
the user command are interpreted and acted on. Exceptions abound but,
they often do not add any value and are system specific. One that comes
to mind is NS* DOS and the OS/FileSystem and command processor are so
tightly bound that they live as only monolithic 2.5K(or so) block of
code. It has some economies but ofthen its simplicity is a trade off.
An alternate to this is having file information inside the file as a
header block that binds the file to it's respective application. Correct
me someone but I think the Apple MAC OS does this. It removes the need
for the extension driving the application.
Allison