Counting on AllocVec's size memo..

[Piru]

OS4 developers choose to change this with no good justification. There is no urgent need to REMOVE the size from the ptr-4, it could well have been kept there for backwards compatibility alone. OS4 developers did not do this, and as a result some existing applications ceased to work.

I call that breaking.

Naturally applications relying on this are broken aswell, but there was no need to reduce the compatiblity in this way.

[Piru]

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.

[Piru]

I don't say "let all the old applications crash and burn". I say "keep (wrong) compatibility as long as it is bareable, but sacrifice it if that would prevent really necessary improvements". And the new memory system really is a big step forward!

While not commenting the qualities of the new memory system, nothing in it required dropping the backwards compatibility here. And this is my point.

during all the beta testing of OS4 GoldED really was the *only* bad application.

It was? According to who? How broad set of applications were tested? How was it made sure that all memory allocations were tested in each app?

I think the Friedens would have decided the other way if more than this single program had been affected. But that was not the case.

Well, if they really think they caught the only program abusing this trick, they are gravely wrong.

[Piru]

So, OS4 "Final Update" with the new memory system is out.

I suppose no important software has suddenly broken with it?

[Piru]

@Karlos

Of course the developer of the app is at fault here, too.

But so are OS4 developers. In insisting on removing the compatibility (even if undocumented!) they've broken important application that worked just fine before. Again, there is no good reason for not to have the compatibility there. Removing it will only break apps.

Reading the local forum, SnoopDOS, AmiDisk, HDRec are all crashing.

QED

[Piru]

Regarding crashing applications: Those apps do crash for the local OS4 user. I have no way to verify those findings.

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.

It was about AllocVec, but still: I agree fully. Programmers should use the correct way and avoid depending on the size being at -4. But they don't. There are such apps, and not all of them can be replaced.

There is no need to stay compatible here.

There is no reason to remove compatibility here.

If older applications break for this, update the application or make an alternative for it.

And if the source code is not available and the application is some important one? You seriously think everything can be replaced? AROS / OS4 / MOS doesn't have enough good developers to write replacement for everything.

[Piru]

@whose

But where's the point to discuss the compatibility question for older programs, when a programmer actually asks for this OS private special?

Historical context, and implementation details. He did ask if it had changed, too.

Also, in some rare occasions such details might be needed (for example debugging tools).

I bet there is. But I'm not "skilled" enough to judge or explain it. The Frieden brothers can explain it much better, I think.

Well, nothing in their explanation is good enough reason to justify this change (and I consider myself qualified enough to comment on this). See earlier posts in this thread.

[Piru]

@whose

I really don't understand why it is so important to use such tricks, which are already blamed decades before, sry.

I am not promoting use of such tricks.

[Piru]

@whose

But you do it indirectly by saying, that e.g. MOS supports such a practice and hence is "more compatible" (or better). See the difference?

No. I know AmigaOS 2.x, 3.x and MorphOS works this way. If I knew how AROS works, I would have included it aswell. I see you're reading more to my comments, though.

OS4 discourages such practices active and I can't believe that they (the OS4 developers) did it to just say "hurray, we broke more applications than any other amiga-like OS".

That's fine. MorphOS does the same, really, but it tries to avoid breaking things if only possible. In this case the size could have been left to ptr - 4 without any ill effects.

It's now time to say "good bye" to tricks like this one (and some other).

Yes, was that in question anyway? The fact is that old, existing applications use such tricks, and the OS should not be broken here (even though such tricks are "illegal" and "undocumented").

[Piru]

@whose

I've explained it already, but lets repeat once more:

Shouldn't it?

It shouldn't.

Why?

To avoid crashing old applications.

To support this tricks several decades more?

The only reason to have it here is to avoid crashing the apps that read the size from the ptr - 4. Nothing else.

To gain compatibility to broken software and discourage new developments in this direction?

Compatibility with old existing software. Debugging tools for the OS (or the debugging mode of the OS itself) should complain loudly if someone uses such tricks.

In fact, OS4 could have easily retained the "size at ptr - 4" for m68k apps (as far as I know). However, this was changed for both new and old apps. Why?

[Piru]

dupe (can be deleted if some mod runs into this)

[Piru]

MAllocVec will write zeropage if AllocMem fails, fixed version:

Code: [Select]

APTR MAllocVec( unsigned long byteSize, unsigned long requirements )
{
    if (SysBase->LibNode.lib_Version >= 36)
    {
        return AllocVec(byteSize, requirements);
    }
    else
    {
        unsigned long *data;

        byteSize += sizeof(unsigned long);
        data = (unsigned long *)AllocMem(byteSize, requirements);
        if (data)
        {
            *data = byteSize;
            data++;
        }
        return data;
    }
}


Small fix to MFreeVec aswell, in case this routine is to be used as drop-in replacement for FreeVec:

Code: [Select]


void MFreeVec( APTR memoryBlock )
{
    if (SysBase->LibNode.lib_Version >= 36)
    {
        FreeVec(memoryBlock);
    }
    else if (MemoryBlock)
    {
        unsigned long byteSize;
        unsigned long *data;

        data = (unsigned long*)memoryBlock;
        data--;
        byteSize = *data;
        FreeMem(data, byteSize);
    }
}


Excuse me, I just can't help myself. ;-)

[Piru]

Wikipedia: Indent Style#BSD/Allman style

Basically it's easier to read: More "spacious" and it's easier to see where blocks start and end (just find  visually matching brackets).

This is not the universally superior indent style, but it is fairly common. However, the most important thing is to stay consistent: When you choose a style, stick to it. Don't change styles (at least not within the same project).

See more at Wikipedia: Programming style

[Piru]

Oh no, yet another holy war... But of course it's a matter of taste....






Except that BSD/Allman is teh bestest!!!1






:-D