Exec exception handling and a time interval implementation...

[tboeckel]

You could also use the undocumented msgport feature

Do you really think this is a wise decision? If it is not documented then there is a reason why it is not. Even if it may work now with one specific version of AmigaOS, nobody can give you a guarantee that it will work for all times.

Hacking like this makes further development of AmigaOS so extremly hard. Just because some very clever programmers think they are smarter than others exactly this kind of program will crash and burn in the future. One should have learned that lesson from history (OS1.x -> OS2.x, OS2.x -> OS3.x, etc)

[tboeckel]

All AmigaOS versions at least from 1.x to 3.9 support this mp_Flags = 3 trick. MorphOS supports it aswell.

I know that argument too well. A very similar discussion was held about if and where AllocVec() stores the size of an allocation. Some very clever people are really convinced that the size must always be stored in a ULONG before the returned address. This was never documented and the fact that it was done that way upto OS3.9 made some programs crash when OS4 beta introduced its new memory system. This system doesn't need to store such a size at all, and hence all assumptions were bogus.

Ok, you might try to tell me to keep up this behaviour even with the new system. But why? No Autodoc ever stated that AllocVec() would store the size anywhere, and if it did, nobody could tell where. The fact that the size was stored directly in front of the allocation was discovered by reverse engineering, hacking, very clever people or whatever. And from that point on it was considered as "almost documented" and some programs relied on this "fact". Even one well known text editor exploited this undocumented feature and therefore crashed instantly.

What I want to say is: NEVER rely on undocumented features. These are things that may change at any time, and sooner or later this change will happen!

But what about making this mp_Signal=3 thing official? I will put a question on the OS4 beta list.

[tboeckel]

In MorphOS we don't break compatibility (even undocumented!) unless if it's absolutely needed. AllocVec stores the size as ULONG before the actual allocation, dos.library MatchPattern[NoCase] return value was not changed just because of "cleanup" and so on.

So far it was only one application (GoldED) that failed badly with OS4's new memory system. Dietmar fixed this issue already, but in the beginning he was also refusing to accept the fact that any internal workings of AllocVec() were undocumented from the beginning. As a result AllocVec()'s old behaviour was kept up for 68k code, but dropped for PPC code (AFAIK), just to avoid future usage of such hacks.

That is only one very prominent example where it was easy to distinguish between old and new software. But that is not always possible. And if it breaks only some ancient software I prefer a cleaned up system with enforced adherence to the documented facts.

Ok, you might try to tell me to keep up this behaviour even with the new system. But why?

OK, supporting "undocumented" return values or features might seem silly, but IMO if supporting them is much more sensible than breaking them for no good reason. All these supported undocumented features add up to much greater software compatibility.

Maintaining backward compatibility is a good thing, as long as you don't encourage the usage of illegal exploits, like that AllocVec() thingy. If you don't put a stopper to such illegal behaviour people will continue to use it for all times, just because one clever person told them it works that way. And then you have to carry around tons of legacy code, just to support one ancient application which did things wrong from the beginning. And to carry on with these bugs because they never caused any problems so far is very stupid IMHO.

What I want to say is: NEVER rely on undocumented features. These are things that may change at any time, and sooner or later this change will happen!

I agree. But unfortunately this doesn't help with already existing applications that rely on these undocumented features (there are tons of apps that you can't fix/recompile). Thus, to get the best possible experience out of your OS, you need to support these things.

Sure, you're free to disagree, but this is what I think and try to maintain in my MorphOS work.

Keeping up compatability is a good thing. But you shouldn't encourage usage of things like mp_Flags=3. This was also completely new to me. If you know it, it's ok. You know about the limitations and dangers. But others don't know about it and nobody can read about that anywhere, because it is undocumented. Hence, better keep it secret.