Thinking to change to the dark side (blue)

[Georg]

Protecting unused memory isnt improving stability, but is nice for debugging.

At least with standard Exec Memory Lists unused/free memory is not really completely unused. Because the unused memory chunks are linked together through MemChunk structs. So code like this:

  Forbid();
  FreeMem(mem,100);
  *mem = something;
  Permit();

can cause trouble (it's bad/stupid/ugly anyway). The Forbid() protection does lock other memory allocations, that's true, but after the FreeMem() the first 8 bytes at address might be in use for the unused-mem-chunk-linking.

[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 ? there is no resourcetracking
in either AOS4 or MOS. Atleast not for old apps.
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
But as I said, it doesnt improve stability or
in any way protect against apps crashing the system.

According to Hyperion that's very common reason for SW crash. Time will tell how it affects.

Well, they should know Okey, there is more apps that does this. But using wrong pointers is a *much* more common problem. They say this because theyve just implemented a feature that is_supposed_to_fix_this. if they didnt, they wouldnt say it. simple.

[Kronos]

A few notes:

There are several problems preventing MP on AOS:

Lots of OS-structures that need to be directly written to (and lots of SW
that does it on sructures that do have a "save" API), and allmost all
structures are open for reading.

Message-ports, those are used for Intuition, Arexx and other purposes.
2 Tasks that interact via these can't be protected against each other.

Problem that allmost all apps interact wiith these with the kernel ....

BOOPSI  :-o  there is just no way for the DOS-loader to see where the app
ends, and where custom-classes defined in the same file start. And there
is no way to know if both parts may share global variables.

Lots of OS-functions to expect the app to pass a pointer to data, which
might not be copied to OS-memory.

None of these can be changed without having some sort of box (and remember
those are bad, real bad :-P ), and none of them could be just recompiled
to an new APi without some major changes in the app code.

Thats why R.S. decided from start that there had to be provisions for
a clean cut.

[blubbe]

At least with standard Exec Memory Lists unused/free memory is not really completely unused. Because the unused memory chunks are linked together through MemChunk structs. So code like this:

Forbid();
FreeMem(mem,100);
*mem = something;
Permit();

can cause trouble (it's bad/stupid/ugly anyway). The Forbid() protection does lock other memory allocations, that's true, but after the FreeMem() the first 8 bytes at address might be in use

Well, this is true, exec keeps track of free memory
by linking free memoryblocks. Question is if this is
considered when blocks are marked as free.

Edit: ok, I see how it could improve stability now.
 
 

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

[blubbe]

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

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.

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

We all know how "fast" Windows/Linux is. QNX & BeOS are good examples that memory protection / boxing does not necessarily slow down the system. (I think, @ work & so far it kills the application, we have extremely tight realtime requirements...)

Apples and oranges. QNX and BeOS are not shared memory address systems. They use the Unix way of packaging each task into discrete memory areas like virtual machines. They can't physically overwrite each other's data. AmigaOS is not like that. Nothing that can have any compatibility with AmigaOS can be like that - without sandboxing.

Your previus information vas not valid. But that last one (above) is new to me. Hmmm... I do not figure yet how it would be any harder than in any other resource tracked systems.

Can you mention any resource tracking OS's that store allocated memory as linked list nodes? I don't know any. Such a thing is not practical.

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

[blubbe]

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.

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

[alx]

On the A1 with Articia there are documented DMA problems

It appears as if that issue has been settled at last, for OS4 :-D

[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-)

[Piru]

@ksk

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

How exactly?

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

Protecting unused memory is only improving stability due to the fact that the memory freelist is (partly) protected. Not everything can be protected however, due to MMU page size aligment restrictions. Full memory list protection would require totally new memory subsystem.

This kind of partial "memory protection" is far for perfect, and it's debatable if it's worth the effort anyway. Most of the fatal hits are specifically to *allocated* memory (used memory by other apps/OS).  It is going to catch only a fraction of the critical hits (freelist mc_Next or mc_Bytes).

Certainly I would not call this Memory Protection, because it is not.

[blubbe]

I missed this

>1. So ?
No competition & HW alternatives. High prices. Risky. See x86 success vs apple success ...
>2. Whaat ?
Well it was. Initially I thought they were building memoryprotected boxed system (I believed the hype, stupid me). Instead they were building Abox and everything was being put in it. MOS was "just" going to grab AOS market. HUGE disappointment to me.
>3. Whaat ?
See 1.
>4. Whaat ?
It was that way. Then. IMO, more appealing. The AOS I know & love being developed forward. Connection to "world fastest growing industry" even, as those fellow work mates @ Linköping said.

>Somehow you seem Pro-OS4 but your listed resons just dont
expalin why.

There's really no use of explaining or was there? People see these things differently. Some do not see (not meaning any person particularly).

1. how is it different from Genesi ? High prices ??!??
Risky, sure, what isnt.
2. now I forgot what the initial question was, but
I fail to see what negatives you see in this.
"Huge" dissapointment that it is compatible ? Let me repeat, Whaaat ?
4. I just dont have a clue.

[falemagn]

Yes it does.
The app with the "fuzzypointer" is more probably detected & killed before it messes up the memory of other apps/OS.

Sorry, but it's not as simple as you make it sound. For one, you can't just kill the culprit task, if you do, you risk to really damage the rest of the system, as that task might be holding information that another task has got a pointer to, for instance, or it might be holding a semaphore (and no, you can't safely just release the semaphore, as that might leave the data it was protecting in an incoherent state), or whatever else can come to your mind.