How can you break something that was never documented?
By changing the implementation for no other reason than to crash broken applications. That is not very smart.
1. it was never documented to be there
True. But the implementation is widely known, and abused in way more applications than just GoldEd.
2. it was no longer necessary with the new memory system
This is no reason to remove the compatibility.
3. PPC cache lines have different alignment than 68k cache lines and an additional offset of 4 would slow things down
Slow down? Yeah right, that must be massive slowdown there.
*cough*4. so far it did only break one major application (GoldED) and that has been fixed already
That
they know about. That is the thing with these changes: you never know when some obscure application breaks, and you have absolutely no way to test everything. And if some application suddenly crashes with new system update, how can you tell why it happens? You can't. Thus, it is a bad idea to do such modifications for no good reasons.
5. OS4 tries to enforce certain programming rules and punishes hacking.
Now we're getting closer to the truth. The change here makes no sense at all, all the above reasons are not good enough to remove the size at offset -4. IMO changes for the sake of the change itself, or trying to enforce new rules while breaking old applications is a very bad idea.
Similar excersise was "cleaning up" some dos.library return codes (-1 vs 1 for "true"). Good intentions turned out badly, as it broke varions programs checking for "traditional" return values.
The advantages of removing the size information by far outnumbered the disadvantages.
No it doesn't. Removing the size gives no apparent advantages, but instead makes some applications crash. That is NOT good for the end user.
And that's why it has been done.
I don't even try to understand why it has been done, there doesn't seem to be any sensible reason for it. If those indeed are the reasons for removing it, I fear OS4 won't run many legacy applications in the end. The compatibility will get worse and worse.
Compatibility is a big thing to maintain, but keeping undocumented features, which lead to hacking, is not always very wise.
So basically you're saying it's better to make old, existing applications to crash to make sure new programmers don't fall into the old traps? Wouldn't be smarter to provide good programming manuals and encourage good programming practices, rather than making the OS itself crash the programs? Remember, this is not helping the end user. Development tools should indeed make such hacks barf, and this is what tools like Mungwall do.
But relying on undocumented features should never be encouraged.
Agreed. But deliberately breaking compatibility to force the issue isn't the way either. Provide good development tools, and leave the end user out of the loop.
