Re: Virtual Memory

[root@icon.pp.se (Daniel Eriksson)]

In <9502132140.AA05922@amazon.cs.duke.edu>, Scott Bigham writes:
> 
> Not necessarily.  MiNT already does some auto-detect magic to determine
> whether it should enable memory protection; could it not determine in a
> similar fashion whether or not to enable VM? [In fact, wouldn't it be
> under exactly the same situation?] Barring that, we could always have
> one MiNT binary with VM and one without, and a smattering of
> "#ifdef VM"'s in the source code.

Making MiNT capable of determining wheter to use VM or not is probably
very easy, just as you say. However, the difficult part will be how to
use it from programs without making the programs incapable of running
on systems without VM. In the end you will end up with either 2
different binary distributions of the program or one distribution that
doesn`t make use of the new functions (f.ex. a non-blocking fork()).

In the first case people with 030s wouldn`t generally want to put the
extra time and effort into making a second 000-compatible version,
especially not if it would involve rewriting parts of the code. This
would mean lots of 030-only ports of popular utilities (and as far as
I can tell most of the "power users" out there that provides us with
those great ports of Unix-programs are 030-users). For lucky bastards
like myself (F030-owner) this wouldn`t be any problem, but for the
numerous ST/STE/Mega-users it would be a disaster.

In the second case all our efforts of implementing VM into MiNT would
be a waste of time.

I don`t see a solution to the problem, but I sure as h*ll would like
proper VM in MiNT. :-)

All above is of course IMHO. I`m no MiNT-expert, and I`m probably wrong
about lots of things...

-- 
|       Daniel Eriksson, root@icon.pp.se (UUCP), der@astrakan.hgs.se       |
|  Voice +46 26 72905, Fax +46 26 72123, F030/14/2000/Tower/17"/CDROM/DAT  |
|"Peacekeeping - it`s not a job for soldiers, but only soldiers can do it!"|