From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id EAA04251; Thu, 11 Mar 2004 04:20:17 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA04464 for ; Thu, 11 Mar 2004 04:20:14 +0100 (MET) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i2B3KVKW008018 for ; Thu, 11 Mar 2004 04:20:32 +0100 Received: from [192.168.1.200] (ppp114-118.lns1.syd3.internode.on.net [150.101.114.118]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i2B3Jvwn026823; Thu, 11 Mar 2004 13:49:58 +1030 (CST) Subject: Re: [Caml-list] Bug with really_input under cygwin From: skaller Reply-To: skaller@users.sourceforge.net To: David Brown Cc: skaller , Eric Dahlman , caml-list@pauillac.inria.fr In-Reply-To: <20040310041009.GA27787@davidb.org> References: <51FE3429-7219-11D8-8BF5-000393914EAA@atcorp.com> <1078888018.2452.52.camel@pelican.wigram> <20040310041009.GA27787@davidb.org> Content-Type: text/plain Message-Id: <1078975445.2452.87.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 11 Mar 2004 14:24:06 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 bug:01 cygwin:01 sourceforge:01 2004:99 2004:99 1100,:01 unix':01 abstraction:01 abstraction:01 sensibly:01 'length:99 'length:99 9660:01 glebe:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 109 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