Counting on AllocVec's size memo..

[itix]

5. OS4 tries to enforce certain programming rules and punishes hacking.

Still many OS4 programs depend on undocumented side effects and features ;^) It is nature of programming. Coders always did and will use all means to reach goal with minimal effort. If it is possible to exploit an undocumented feature there is always someone doing so.

[itix]

Ok, the location of AllocVec()'s size storage has become something like a "fact". But that's the point: it never really was a fact

This could be compared to how some OS4 programs handle r2 register. AmigaOS 4 uses SysV ABI and according to specification general purpose register r2 is reserved for system. However it is publicly known that r2 is not used by the system at all. Thus using r2 as a spare register in assembler routines is safe and I know OS4 native programs doing so. But this is not stated in development documents, "everyone" just know this feature.

Is it bad? I don't know. In MorphOS, killing r2 is illegal, but os4emu (;-)) occasionally abuses the system and kills r2 against all rules :-)

[itix]

"Killing" any register not known to be defined as volatile on any specification is bad. Do what the hell you want to a register in your own code but be sure to save/restore anything not volatile.

r2 is quite exceptional: it is either used or not. Killing r2 is not very expectional either. It is just about is it good coding style or not - while using r2 for own purposes is maybe deprecated its functionality is known (i.e. unused in OS4).

Would you blame the C/C++ compiler's compatibility here or the developer if we substituted the word "AllocVec" with "malloc" or "operator new[]()" ?

AllocVec() stayed the same last 15 years. Memory lists have existed last 20 years. I'd say API was rock solid many years...

Similar problems with compatibility existed moving from 1.3 to 2.0 and that was a much smaller technical step than the changes from 3.9 to OS4 / MOS.

In those times software was developed actively and companies could not let their software to fail under 2.0 especially because productivity users went for 2.0. Today I dont see software companies (what companies?) recompiling their software for MOS and OS4.

Gamers despised 2.0 and A500+ was considered being bad buy because of poor compatibility. A1200 users could not play many games until proper tools (WHDLoad and JST) were invented and games patched.

Of course something must be sacrificed always. I know why Diavolo Backup 68k doesn't work fully in MOS and OS4 and it is only because coder did extremely small mistake in threading code. It could be fixed by small adjust in the DOS side though.

[itix]

Neither of them do. SnoopDos68K runs in fact "better" than SnoopDosOS4 (you can't open the "Functions" window anymore).

That results from a nice "trick", doing some write accesses to const data sections. Nice, eh? SnoopDos68K doesn't break because 68K programs are still allowed to do this.

Program overwriting its own const data is not illegal as such and in SnoopDos it happens only because some strings are unexpectedly placed into .rodata section. There is nothing wrong in SnoopDos 68k; bug was created in 68k->PPC transition. Only PPC version of SnoopDos (inluding MorphOS port) writes to const data.

Fixing const data problem does not give you working packet monitor though.

If one looks at the practice to rely on the memory size notation of AllocMem(), one must say: Why do you do this? It's "forbidden", there is no real problem to do own notation of the alloc'd size, just do it the "right" way.

Even OS4 developers do it. DiskSpeed OS4 assumes that memory returned from AllocVec() is aligned to 8 bytes boundary. It is not documented feature but is "public knowledge". Neither is documented what newlib startup code (one that is statically linked to newlib programs) is doing. Build hello world program and link it against newlib and you are already using undocumented features.

[itix]

The real issue is that developers shouldn't habitually point loaded guns at their own feet and wonder why they might lose some toes one day

Is the real issue that Amiga developers in 80s and 90s were not very good afterall? :-) I mean, when old programs stop working when internals of the OS have changed is it because Amiga software is POS or Amiga operating system is POS? Or both? Or none? Obviously SW developers do mistakes (think about original IBrowse 2.3 issues in OS4) but if mistakes are common practise it is better fix the OS than software. The OS exists for the software.