Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!sdcsvax!darrell
From: darrell@sdcsvax.UUCP
Newsgroups: mod.os
Subject: Re: Who needs files?
Message-ID: <2915@sdcsvax.UCSD.EDU>
Date: Thu, 26-Mar-87 21:02:56 EST
Article-I.D.: sdcsvax.2915
Posted: Thu Mar 26 21:02:56 1987
Date-Received: Sat, 28-Mar-87 15:42:50 EST
Sender: darrell@sdcsvax.UCSD.EDU
Organization: Amdahl Corp, Sunnyvale CA
Lines: 29
Approved: mod-os@sdcsvax.uucp

>In article <2859@sdcsvax.UCSD.EDU> johnl@ima.ISC.COM (John R. Levine) writes:
>>In article <2850@sdcsvax.UCSD.EDU> bagwill@decuac.DEC.COM (Bob Bagwill) writes:
>>>
>>> ... Why not define all storage as extended memory structures
>>>that may be loaded as needed.  ...
>>
>> ... it makes device independence very hard. ...
>>
>>The other reason that you want files is that they have an existence and a
>>naming structure separate from the programs that manipulate them, which is
>>kind of unavoidable.  You as a human would probably rather call a file
>>/usr/fred/games/source/pinball_bounce.c, while your program would rather
>>have a nice handle like a memory address of 0x18723d70 or a file handle of 5.

Actually, there are operating systems that let you do this sort of
thing.  (Well, maybe it's just a sufficiently close approximation.)
The Dartmouth College Time Sharing system provides an "address file"
system call which maps a file into your virtual memory space.  The
program now has a nice handle on the file which is a memory address,
the operating system having performed the translation between a user
supplied treename (pathname) and a memory address.

The program can now access the memory mapped file using a suitable
data structure.  Device independence is not a problem.

Back before DCTS implemented this system call, some people were porting
IBM PL1 programs which apparently did similar things.

-- Chuck