What is memory protection and why is it so hard to implement for the AmigaOS?

[sim085]

Hi,

I was reading the AROS FAQ and came accross the following;

Several hundred Amiga experts (that's what they thought of themselves at least) tried for three years to find a way to implement memory protection (MP) for AmigaOS. They failed. You should take it as a fact that the normal AmigaOS will never have MP like Unix or Windows NT.

So why is it so hard to have memory protection for the Amiga? Is there anywhere where I can read more about this?

[skurk]

So why is it so hard to have memory protection for the Amiga? Is there anywhere where I can read more about this?

It's due to the way the "kernel" was designed.  I think this post sums it up pretty good:
http://groups.google.com/group/comp.sys.amiga.advocacy/msg/7d0bf445a2c22d67?hl=en&

[sim085]

So in other words memory protection is not possible to implement because the developers of these operating systems (AROS and AmigaOS) want the OS to be backward competible (allow software from 3.1 to run) right?

[jj]

basically yes.  Mp would break all existing software

[itix]

It is not just that it breaks existing software. It is not possible implement memory protection without complete redesign of API.

[sim085]

So if they drop backward compatibility and decide to re-do the kernel then they can include memory protection right!? Or there is something in the AmigaOS philosophy that still makes this a hard task to achieve?

[HammerD]

So if they drop backward compatibility and decide to re-do the kernel then they can include memory protection right!? Or there is something in the AmigaOS philosophy that still makes this a hard task to achieve?

Well there was as chance with both MorphOS and OS 4.0 to  make a clean break and sandbox 3.X apps, and make new API's and basically start over fresh.

Both approaches didn't do that, however, probably to maintain backwards compatibility within the older applications.   Plus, defining all new API's is basically re-writing everything from scratch.  Maybe that was too much work given the available budgets and resources.

If it was me, and I had unlimited resources and time, I would sandbox legacy apps and start with a clean slate, adding features like SMP, etc.

[B00tDisk]

Well there was as chance with both MorphOS and OS 4.0 to  make a clean break and sandbox 3.X apps, and make new API's and basically start over fresh.

Both approaches didn't do that, however, probably to maintain backwards compatibility within the older applications.   Plus, defining all new API's is basically re-writing everything from scratch.  Maybe that was too much work given the available budgets and resources.

If it was me, and I had unlimited resources and time, I would sandbox legacy apps and start with a clean slate, adding features like SMP, etc.

Yup.  I seriously wish AROS had done this.

[LoadWB]

If Apple can move from OS9 to OSX with compatiblity for OS9 applications (IIRC, it is in an emulation layer, but compatible none the less,) then...

[HammerD]

If Apple can move from OS9 to OSX with compatiblity for OS9 applications (IIRC, it is in an emulation layer, but compatible none the less,) then...

From the wiki page on the history of MacOS X:

http://en.wikipedia.org/wiki/History_of_Mac_OS#Mac_OS_X

"...This is a compatibility layer in Mac OS X (in fact a Mac OS X application, originally codenamed the "blue box") that runs a complete Mac OS 9 operating system, so allowing applications that have not been ported to Carbon to run on Mac OS X. This is reasonably seamless, though "classic" applications retain their original Mac OS 8/9 appearance and do not gain the Mac OS X "Aqua" appearance."


So, it looks like they basically sandboxed older apps, and in fact the entire OS 9 to run on top of MacOS X.  Sort of like runnine E-UAE now on OS4, or WinUAE on Windows, although they made it appear more seamless, I think.

[outlawal2]

If Apple can move from OS9 to OSX with compatiblity for OS9 applications (IIRC, it is in an emulation layer, but compatible none the less,) then...

Yeah and that particular implementation was REALLY well done IMO...  I have often hoped that the new version of AmigaOS would include support for multi-processors as well as good memory protection... It would really be nice since a rewrite of the OS is required to implement these items, then add these items and provide a modern OS providing backward compatibility similarly to the OS9 support model used by Apple...  

Sadly, I doubt this will ever happen and we will continue to have two very different camps with different goals...

[HammerD]

@outlawl2

Well there are more than 2 "camps" if you wish to use that terminology

1) Classic users
2) OS4 users
3) MorphOS users
4) AROS users
5) Emulation users (amithlon/winuae)
6) Other (users of minimig, NatAmi), sort of classic users

Of course, many people are a mix of some or all of the above

[outlawal2]

That is true, but most of your abovementioned flavors were created with one of two things in mind..   Either:

Backward compatibility (MorphOS, Emulation users.)
Or
AmigaOS for the modern world and modern hardware. (supposedly)  (OS4)

[HammerD]

I think many users wanted backwards compatibility, thus you see the limitations on the modern incarnations of OS 3.x today.  Done that way probably because it would have taken too much resources to do it the way Apple did.

[Fats]

It is not just that it breaks existing software. It is not possible implement memory protection without complete redesign of API.

I disagree here. I think it would be possible to have minor changes to the API and provide memory protection to programs that follow certain policies. By the latter I mean no data allocation on the stack that has to publicly available, obey the MEMF_PUBLIC/MEMF_PRIVATE meaning, etc.
Programs could in the executable or during start-up indicate that they follow these policies (with the consequence they may be killed when not following them). Programs not having this indicator won't be able to have MP.
For this to work you have to implement a MP that fits with the Amiga API. This means not trying to enforce the Windows/Linux MP with address spaces for each process/task but getting your inspiration from single address space operating systems and similar systems.
The main extension of the API would consist in extending the memory pools API so programs can indicate which other programs may access certain memory pools in read and/or write mode.

greets,
Staf.