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

[Fats]

This causes serious side effects. Consider following example:

void foobar(char *name)
{
   struct FileInfoBlock fib;
   TEXT buffer[108];
   BPTR fh;

   strcpy(buffer, name);
   strcat(buffer, ".txt");

   Printf("Open file %s\n", buffer);

   fh = Open(name, MODE_NEWFILE);
   Write(fh, buffer, sizeof(buffer));
   ExamineFH(fh, &fib);
}

Looks like you have to fix dos.library first.

I did not say that you could use libs without any change. And it will not only be dos but also exec, gfx, intuition, ...
In this example I don't see anything that can't be handled by dos internally, although the proof will be in the pudding.

 You are going to have other indirect implications. Think about this:

void PlaySound(BYTE *buffer, LONG bufferlength)
{
   io->Command = CMD_WRITE;
   io->Buffer = buffer;
   io->Length = bufferlength;
   DoIO(io);
}

If the buffer is allocated from stack this will cause problems. I agree.

Ooops? You must document what API calls can take data stored on the stack.

On Linux this is solved by having kernel code run under the kernel context without access to all memory without any restrictions. On a MP amiga OS this may sporadically be needed for efficiency reasons and limit the cases where API restrictions are needed on passed pointers to lib functions.
I would like to limit the code running under this 'god' context though and not evolve to a monolithic kernel; from the other side I am for some pragmatism and not some almost religious following of OS concepts like most of the microkernels guys have been doing.

This is why I dont like MEMF_PUBLIC crazyness.

To me it is not about enforcing MEMF_PUBLIC/MEMF_PRIVATE or not.
It is about how to put public data on stack and make the stack auto-extending. Do you have another solution for that ?

greets,
Staf.

[itix]

I did not say that you could use libs without any change. And it will not only be dos but also exec, gfx, intuition, ...
In this example I don't see anything that can't be handled by dos internally, although the proof will be in the pudding.

It must be handled by dos internally. It is way too much work for user code to always copy filenames etc to temp buffer.

It is about how to put public data on stack and make the stack auto-extending. Do you have another solution for that ?

Go 64 bits ;-) There you should have got enough address space for next 10 years...

But anyway... experiment it and tell us how it went ;-)

[orb85750]

Turing Award to be given to individual that successfully implements MP on Amiga.  (Is it really so important?)

[Methuselas]

unified build environment for MOS, AOS and AROS so in one go a binary is built for each of these OSes from the same source code, ...

This is what I've been talking about from the get-go. Fats, you have my total support on this and anything can do to help bring this about, don't hesitate to ever ask me.

After reading this, I realize that you and I have argued in the past, for no reason, as we both wanted the same thing. You have my sincerest and most humble apologies.

[obscurepanic]

Appropriate amount of elegant line of codes would do the trick. Sort of like the time-proven classical UNIX approach.

[freeaks]

i've just stumbled on this thread ..
it's alway good to see more discussion about MP.
one way or another something must be done for stability on amiga-like OSes.

if some them (amiga-like OSes) prefer to stay true to original os3.x api, good for them though i prefer emulators for that.
i hope in the lot (aros, os4, morphos) there will be at least one which will keep the look and feel and general user experience but whose base will improve and evolve a bit.
in 2010 basing an OS api on 80s and 90s standards, and planning to keep it that way for the foreseeable future sure looks a bit sad to me..

especialy sad since if i remember correctly, the original dev team of amigaos planned to introduce MP in some later system update which unfortunately never came. the commodore bankrupt and all. they hadn't time to introduce this update in amiga api and that's too bad.. we'd be a lot better today if they had time to deliver this update.

imho the goal of aros, os4 and mos should be that.. guesstimate what the original team envisionned for that MP update and do it.
for classic software needs there's emulators (uae).

memory gestion in os3.x api is just not good enough.
so far all 3 mentioned above OSes are still as weak as amiga OS 3.x was. meaning any bad behaving app or system component or anything can, and DO crash the whole system.
i can't believe it each time it happen and how many times .. it's ridiculous.

there must be some kind of general rule that make it possible to kill properly an app and free all its resources nicely. any bad behaving program should be killed by that rule before being able to do any harm on the system and other apps.

the crashs must stop..
be it by implementing MP, or any anything else, black magic, chicken sacrified in a red and white checkered pentagram i don't care but something must be done

[freeaks]

crashing like that was tolerable when the other did as bad or worse..
at the time, macOS7,8,9 and windows 3.11,95, 98 and "me" were all as bad ..
but now, windows and macos changed some flaw of design, they got updated and they are a lot .. a hell of a lot more stable. there's nothing you can compare with amiga-like OSes anymore, be it aros, os4 or mos ..

it's seriously time someone make the necessary update to os3.x api too ..
having all our amiga "ng" focusing on backward compatibility at any cost is too bad .. specialy when the cost is so high it places you below average standard...

i'd say, keep the look and fell, OS filesystem layout/structure with libs: fonts: c: sys: and so on, keep the general idea, but , make a rock solid base and screw the backward compatibility ... at best include, integrate uae .. like macOS did when transitionning from macOS9 to maOS X, they create "classic" environment to execute from inside OSX

lacking proper tracking resources and means to kill apps in amigaOS is a proof of serious design flaw.

[Boot_WB]

My only contribution to this thread, (which, by the way is a cracking read):

This was acceptable 15 years ago. I think it's not today. Much like monotasking OS isn't acceptable, even for a phone... Would you use some DOS-like monotasking OS today ? don't you think having a GUI or not is an academic discussion ? after all you can do everything you want with just a simple console, right ?

PS3 runs a monotasking OS. Whilst not a desktop computer, it is in general use by several million people as a web browsing, file (mis-)managing, incredibly restrictive monotasking OS (albeit with a GUI).

Carry on...

[Piru]

imho the goal of aros, os4 and mos should be that.. guesstimate what the original team envisionned for that MP update and do it.

The whole contribution of the original team is some forward looking text file which throws in the air some things you should keep in mind in order to stay future system compatible. The instructions are incomplete and contradicting (for instance use of MEMF_PUBLIC). You can't blame them really, there's no way they could foresee the future development of multicore, memory management units in all CPUs etc.

Doing complete rework of the OS design to allow full memory protection and then running old apps inside UAE, what's bad in that you ask? If you're going to cook up your own design you'll in for 10+ year project reinventing the BSD/Linux wheel. Well, why bother with that, why not use use Linux and run UAE on top?

No, I personally don't feel like doing that.

Something like running your own lightweight kernel and userland and on top of linux kernel might make more sense. You wouldn't need to bother with the low level things then. Sounds much like Amithlon, with the exception that you'd replace the userland with newer one and perhaps not bother that much with HW emulation.

Everyone, feel free to steal that idea (albeit it isn't exactly original).

For now I'll rather keep working on MorphOS as it is now.

[dammy]

Something like running your own lightweight kernel and userland and on top of linux kernel might make more sense. You wouldn't need to bother with the low level things then. Sounds much like Amithlon, with the exception that you'd replace the userland with newer one and perhaps not bother that much with HW emulation.

Everyone, feel free to steal that idea (albeit it isn't exactly original).

For now I'll rather keep working on MorphOS as it is now.

That was Anubis-OS plan actually.

[Crom00]

"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. "

Apple actually did a good job with this. When flakey ass 0s9.2 would rear it's ugly head.... just force quit the os9.2 app and viola. What a relief not to have a crash bring down the whole system. The whole way it ran 68k, and PPC on the same system was quite well done.

[DBAlex]

Windows may have memory protection since XP (as well as all versions of NT of course but that's not a desktop OS) BUT Windows still gets ass raped at the mere sniff of a TCP/IP connection so why is it so important?

[freeaks]

@piru

The whole contribution of the original team is some forward looking text file which throws in the air some things you should keep in mind in order to stay future system compatible. The instructions are incomplete and contradicting (for instance use of MEMF_PUBLIC). You can't blame them really, there's no way they could foresee the future development of multicore, memory management units in all CPUs etc.

we can't blame them of course. but (!) what we can see is that they deemed adding MP important and *it was planned for a later update*.
it was meant to be, they just had not enough time to finish it and deliver..
so maybe yes the documents they left were incomplete and contradictory,
but what's important here is to notice they wanted this for amigaos.

iirc, when i read about this, there was even a mention about inevitably breaking compatibility a bit for that update. (that wouldn't have been the 1st time) but anyway that was at a time aos devel was looking forward..nowdays all we have is focusing on backward compatibility..
like if it was everything ..

Doing complete rework of the OS design to allow full memory protection and then running old apps inside UAE, what's bad in that you ask? If you're going to cook up your own design you'll in for 10+ year project reinventing the BSD/Linux wheel. Well, why bother with that, why not use use Linux and run UAE on top?

well, with the work that went thru the creation of all the 3 "ng" systems (aros, os4 and mos) such platform would exist already.

what i'm saying is that when each of those project got started, the vision was not good enough from the start. the goal was to have amigaos 3.x api compatible "ng" OSes.. so they got what they wished for.. aos with all its strong points and weaknesses too ..

the strong points are obvious:
small size, small footprint,
responsive
customizable
look and feel (user interface)
simple and logical system structure
(almost too good to be true list)

the minus:
(now here's the catch
prone to crash, very much so

a better objective would have been to create a strongly amiga inspired OS
keeping *as much as you can* from amiga, but at least have the memory gestion area reworked.. and maybe some other amiga little weaknesses here nd there corrected too.
you have to take in account the original dev noticed the problem and wanted to correct it themselve too... current os3.x api wasn't meant to be final. obviously for an OS, being able to kill tasks, and free their alocated resources properly is a crucial point.

Something like running your own lightweight kernel and userland and on top of linux kernel might make more sense. You wouldn't need to bother with the low level things then. Sounds much like Amithlon, with the exception that you'd replace the userland with newer one and perhaps not bother that much with HW emulation.

as the solution mentionned above, both could be interesting, which one would fit best, i can't say this is something that need to be tested..
using a linux kernel with an amiga layer on top could be interesting, but only if the linux kernel is really in charge... not like amithlon or morphos.
 (in mos, the abox runs on top of qbox .. even if qbox remain stable and untouched, the abox can freeze thus needing a reboot anyway even if qbox is just fine, so the MP and stability problem isn't addressed .. same for amithlon using a linux kernel but it's not in charge of amiga layer .. which just use the usual exec)
using a linux kernel, along the line of what anubis wanted to do would solve a lot of problems, stability and driver wise.

For now I'll rather keep working on MorphOS as it is now.

i don't know how you can ..
it's looking good, it's fast, small, customisable ..great, but crashy.
i just can't be interupted in the middle of a lenghty post like this, to have the machine freeze because of other tasks running in background may or may not have caused havoc in memory .. having to retype all again ..
having to suspect or fear sudden freeze all the time, forcing me to save all the time, "just in case", in the middle of an irc chat, being rebooted all of sudden ... you left the machine on to finish some downloads and you come back in the morning and it's all frozen download only progressed by few percent before everything froze .. and such

so, sure the os looks nice, logical, simple, it's fast and customisable and all but, this stability problem it spoil everything . at least for me .

[freeaks]

@piru

plus, and i'm not saying this is the way to go but,
no need to reinvent unix/bsd wheel, no need to reinvent everything..
it's possible to pick bits and bobs here and there and customize and mix it all together..
linux kernel can be modified to use a filesystem structure that look like the one on amiga. there are already such project .. gobolinux is one example, but surely not the only one... anubis wanted to do that too.
linux kernel can be cutomized a lot, there's even distribution that fit on one floppy.. so size too isn't a problem.
look at what osx did .. (in its own (kinda bloated) way) .. using linux kernel doesn't mean the result will look like "yet another linux distro.

of course there's also the possibility of creating a new original OS with its own kernel (with MP and resource tracking) but that would take longer to create i think .. so unless there's ppl motivated enough for that, why not simply reuse and customize the existing ..

what i don't understand is why aros, os4 and mos users can't properly kill tasks and free their resources.

[trekiej]

Would running Aros on a Linux Kernel mean that when I launch a new Aros app. that the Linux Kernel would create another space to run that app?
Sorry, I am back to studying c++, but I am not fully versed yet.
I would not have a problem with a Linux distro that is Amiga/Aros oriented.
http://www.xamiga.net
This could be a possible roadmap to a better Aros os with all we want in it.

[trekiej]

The Syllable OS team was creating a version of Linux for server purposes. It would have there own gui and libs, if I remember correctly.