🚀 go-pugleaf

>In article <1990Oct7.032409.22928@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>lron@easy.HIAM (Dwight Hubbard) writes:
[previous junk removed]
>
>Envision an editor that defaults to a 60KByte edit buffer, but goes into
>software virtual memory mode for larger files, and which I can control to
>open the memory buffer to a couple of megabytes if it is available and not
>needed to satisfy contention from background processes.  Now I have great
>performance on small files, pretty good performance on big files, and, while
>things may slow down a lot, it is still _possible_ to edit any file I can
>fit a copy of into my available hard drive space.  It is that quality of
>still being possible to edit large files that makes the effort to install
>software virtual memory worthwhile.
>
Are we talking about software VM (which in my opinion is a waste of time) or
editing files larger than physical memory (a very nice ability to have) adding
VM just to edit files larger than memory is a waste.  I don't see the reason
to add virtual memory for this special case.  In my opinion the better
solution would be for the programers to write the software so that it will
swap off of disk.  This is not an uncommon ability on MessyDos machines and
I believe that Matt Dillion did post an article a couple days ago explaining
a possible way of doing this.  The basic principles for editing a file
larger than physical memory are quite different than writing a software VM
system that would have to worry whether or not the system is going to crash
if this particluar chunk of code gets swaped out.

[Comments MessyDos virtual file handling removed]
>
>Kent, the man from xanth.
><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

--
-Dwight Hubbard,                      |-Kaneohe, HI
-USENET:   uunet!easy!lron            |-Genie:    D.Hubbard1
           lron@easy.hiam             |-GT-Power: 029/004