Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!netserv2!deven From: deven@rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Amiga Resource tracking & Protection. Message-ID: Date: 6 Mar 90 19:39:46 GMT References: <208.25f3c82b@waikato.ac.nz> <10013@cbmvax.commodore.com> Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 43 In-Reply-To: valentin@cbmvax.commodore.com's message of 6 Mar 90 06:30:53 GMT On 6 Mar 90 06:30:53 GMT, valentin@cbmvax.commodore.com (Valentin Pepelea) said: Valentin> Your argument over shared libraries might be correct, but Valentin> the question is moot anyway. Now let me rehash something Valentin> clearly: Valentin> 1. Memory protection can only be implemented by redefining Valentin> the MEMF_PUBLIC flag. Well, not exactly true. But EFFECTIVE memory protection would likely require this. Valentin> 2. Then it would be trivial to implement memory protection, Valentin> but *all* applications would then crash and have to be Valentin> revised. Even the shared libraries on the workbench disk Valentin> would have to be revised. All applications? Including any which don't need to allocate any MEMF_PUBLIC memory in the first place? (assuming the system software itself had been updated...) Valentin> If you guys want to give Commodore the mandate to go ahead Valentin> and drop backwards compatibility completely for the sake of Valentin> memory protection, then go ahead and say so, but keep in Valentin> mind that the above two points are the Gospell truth. I don't entirely agree it's gospel truth, but backward compatibility is important enough that this should not be done at this point. Now, the thought of using an MMU for VM (multiple virtual Amigas) is an intriguiging one... then an errant process could crash one virtual Amiga but not the machine as a whole. And you could run software that takes over the machine along with normal stuff. Neat implications. But a bitch to implement. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.