Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!elroy.jpl.nasa.gov!decwrl!deccrl!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!warwick!maumg From: maumg@warwick.ac.uk (Pop Mobility Freak) Newsgroups: comp.sys.acorn Subject: Re: invoking editors/draw/etc from other app.s Keywords: editors, RAMtransfer Message-ID: Date: 12 Apr 91 12:43:17 GMT References: <1991Apr11.215337.18049@comp.vuw.ac.nz> Sender: news@warwick.ac.uk (Network news) Organization: Computing Services, Warwick University, UK Lines: 27 Nntp-Posting-Host: orchid In article <1991Apr11.215337.18049@comp.vuw.ac.nz> gavin@comp.vuw.ac.nz (Gavin Flower) writes: > >Rather than transfer a file > > - how about allowing the editor to access the memory > of the calling application and passing pointers. > > - This would make for more efficient use of RAM for large files > especially with multiple applications in use. > This sounds fine in practice but is impossible in reality due to the paging performed by the MEMC. When in the desktop an application can only access its workspace and no other applications' workspace. This is a sensible idea as it prevents nasty things happening to other programs if the current one should crash. Also if you allow some other program to edit your workspace directly any information you store about your workspace (such as a pointer to the end of the memory used by data) will become incorrect. And what will happen if the editor wants to make the file bigger? Where would the extra data be put without any chance of overwriting information needed by the host application? What would be even harder than these impossible problems (sounds like mathematics to me, degrees of impossiblity??) would be what happens when a new page is needed to be allocated to the host application to store the data as a task cannot allocate more memory to another task. PMF