On Wed, 2004-03-10 at 15:10, David Brown wrote:
> On Wed, Mar 10, 2004 at 02:06:59PM +1100, skaller wrote:
> 
> > In MS-DOS, files *always* consist of a number of 256
> > byte blocks.

> Is this true with "modern" version of DOS?  FAT has a length-in-bytes
> field in the directory entry.

No, its not true in Windows 3 style DOS which uses the newer
FAT, eg my Win 98 box: however the point was simpler.
Unix' idea that a file is a sequence of bytes is simply
wrong. The abstraction is convenient on the surface,
but underneath its the wrong idea.

In fact the older IBM-DOS systems (I mean 360 machines
not PCs :) was and still is closer to reality: those
systems needed macros for every different kind of device.
VSAM files were quite different to Indexed Sequential
disk files (which were supported directly by HARDWARE
disk operations).

The thing is, abstraction is a tricky game. There's no
way you can sensibly abstract a graphics interface to a
file concept for example. Nor a sound card, etc.

My point isn't to be critical, so much as to indicate
that when one *does* try to be too abstract, something
is sure to be lost. For example 'length of channel' simply
doesn't make sense on non-storage devices. How long
is a terminal file?

Worse, 'length of channel' doesn't really make sense
on storage devices either. The actual stored length
is indeterminate and irrelevant if the data is compressed.
And the 'length read by the client' could be equally
meaningless .. consider the output from a database
select * statement ...

In other words, the length_in_channel problem is really
a symptom of an intractible problem: we need abstraction,
but there is never really any good one for something
like storage devices or I/O devices, because underneath
they're different.

The only real solution is Standards, and they're
not so good either :D

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners