Thinking to change to the dark side (blue)

[ksk]

@blubbe
>>Protecting unused memory isnt improving stability,
>Yes it does.
>The app with the "fuzzypointer" is more probably detected & killed before it messes up the memory of other apps/OS.

>Whos going to kill it ?

You answered yourself by:

>More likely the user gets a window dispalying
erronuos accesses to memory and may decide to
quit the app before it does anything more dangewrous.

>(me would delete the app and forget about it

Right thing to do. In this case possible because of AOS4/MOS? memory protection.

>But as I said, it doesnt improve stability or
in any way protect against apps crashing the system.

?
Isn't "quit the app before it does anything more dangewrous" an improvement?

I give up.

[ksk]

>The access could as well have been to *allocated* memory
like say, some OS structure and we would have a direct DEADLY HIT, with immediate crash as result.

Yes, yes.

Let's say you have 1Gb of RAM.

You have one or a few new/old application running & 100Mb allocated memory.

If you do not have memory protection at all you have almost 0% chance of detecting random memory corruption done by dodgy SW.

If you have memory protection the popability of detecting it is  almost 10/1.

IMHO: That is an improvement. (even though it's still like playing "the russian rulet" when comparing to Linux MP)


Another viewpoint:

You said that it's good only for "debugging". Who will "debug" those thousands of legacy apps? Users.

[ksk]

@KennyR

>>ksk wrote:
>>Someday (after AOS4.1?) it might be possible to have more protection for new apps. Even in that case old 3.x apps might need to be recompiled / be run in a box.

>You can't change the way apps run without breaking compatibility, I told you.

You told the mem protection I described would not be possible.

On that post that you quoted I most likely was wrong in the "recompiling" part. AOS apps most likely require to be run "be run in a box", modifications might be too big otherwise. IIRC, Hyperion had something planned for 4.x apps & MP ...


>QNX and BeOS are not shared memory address systems.

I know. I did not say they were.
They were just my examples of how MOS with Qbox might be a good OS, even though Windows/linux suck in RT multimedia.


>Can you mention any resource tracking OS's that store allocated memory as linked list nodes?

No. I believe I have never examined the OS's way of "storing the memory"... (except some RTOS) That kind of information would be interesting to read & learn, though.

[ksk]

>Yes, they will *DEBUG* it. And MAYBE, they are kind enough
to report the bug before deleting the proggy
>Edit: if the author is still "present".

AOS ja MOS communities together could build a database of information about those dodgy apps anyway ...

[ksk]

@alx

There's no MAI without AOS4 ? 8-)

[ksk]

@piru
>How exactly?

I'm not going to go over it YET again.

>The memory used by other apps/OS is *allocated*, thus the hit will not be detected. Apps/OS will crash.

It does not change anything!

The propability of OS detecting misbehaving application becomes better when it detects access to unused memory (perhaps before it hits some used memory).

(uninitialized pointer is not the only case, accidental use of freed memory seem to happen often in OO code)

(and AOS is not the only OS using that kind of partial MP methode, I know a few million of users elsewhere for that kind of memory protection system (also using some other tricks))

>is far for perfect,

I'm not saying it is perfect. I never will.
It's just better than not having any protection at all.

> and it's debatable if it's worth the effort anyway.

:-) I kind of expected that kind of answer. I rather have it than not.

[ksk]

@blubble

1. Oh my. Read again.
2. "dissapointment that it is compatible" nope.
4. well, the roadmap looked better, the rest is history.

There's no use in going around with this matter. MOS has looked as good option, then bad, then good, then politics ...


@falemagn

Then do not kill it. But surely you rather know something/anything about the memory corruption proceeding in your system than just crash and loose all data.

[ksk]

@Piru

That MMU page limitation reduces that free memory protection usability. Thank for pointing that.

(and now that you mentioned it, that can be circumvented in our embedded situation, but most likely the same does not work in desktop...)

>>...I know a few million of users elsewhere for that kind of memory protection system (also using some other tricks))

>Really? I haven't heard of such systems. Care to list some?

I can not. But if you use a cell phone, preferably 3G. You most likely are using it.

>Just take a look at some of the sloppy coding practices used in "protected" environments..

Right.
(lucky that MOS with Qbox & MP is not yet usable) ;-) ;-)

>I rather would see true memory protection than such limited hack that has little to nothing to do with Memory Protection.

Ofcourse. Especially if the OS still remains efficient/flexible also for multimedia/realtime needs.


@Warface
>And will take considerable time to reimplement all internal 8 bit or planar stuff.

Most likely yes. I think Hyperion might have pretty good competence for that (higher than the original OS building competence).

Hopefully that is partly done when getting rid of all legacy dependant parts. And IIRC in some parts AOS was already capable of handling 32 bits per pixel.

((yet again, this is a place where co-operation would have been very productive, without a few too big egos ...))