Path: utzoo!attcan!uunet!world!decwrl!wuarchive!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Virtual Disk (Was Re: Files larger than available memory.)
Message-ID: <32892@nigel.ee.udel.edu>
Date: 9 Oct 90 16:46:49 GMT
References: <1088@ucsvc.ucs.unimelb.edu.au> <409@tlvx.UUCP> <1124@ucsvc.ucs.unimelb.edu.au>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 25
Nntp-Posting-Host: estelle.ee.udel.edu

In article <1124@ucsvc.ucs.unimelb.edu.au> U3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) writes:
>My idea:
>A virtual memory fixed disk.

Survey says:   BUZZZ!!!

If your application can use files on a disk, all you need to do is up
the number of buffers enough (via FACC, say, or whatever) and this will
work.  Unfortunately, most applications don't do this because the 
Unix-style filesystem is painful to use in increments. That is, it
is not easily possible to write code to get lines 15, 23, and 75
from a file. (It's not even especially easy to get just one line reliably.)
Therefore, for speed, most editors read the entire file into memory
that has been allocated (at some level) with AllocMem. Once loaded,
the disk is never accessed again.

Maybe building a virtual memory fixed disk on top of the swapping library
would be worthwhile.  But adding the kind of virtual disk you are
talking about is not going to give "files bigger than memory" capability
to any program that cannot already handle files bigger than memory.
	     -- Darren
-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, 
      Formal Description Techniques (esp. Estelle), Coffee -----