Counting on AllocVec's size memo..

[whose]

@piru:

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

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.

AmiDisk works fine, HDRec does so, too (in fact, now you can use certain functions to the extent, because Petunia runs even faster with Final, about 2 times faster).

What breaks now is FinalWriter, WordWorth7 is doing its Job fine here. Even TurboPrint works flawlessy here (with reset proof option disabled).

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.

There is no need to stay compatible here. If older applications break for this, update the application or make an alternative for it.

Greetz

[whose]

@piru:

It was about AllocVec, but still: I agree fully.

Yes, my fault. Was in a hurry

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.

Well, they "didn't". Nowadays developers should avoid even to ask for this. Well, they don't, I know. But where's the point to discuss the compatibility question for older programs, when a programmer actually asks for this OS private special? Newer applications should avoid such tricks for any price! There is no excuse to rely on such a "feature" nowadays.

There is no reason to remove compatibility here.

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.

I don't rely on the size notation of AllocVec() and I don't even ask for it. I simply don't need it. But there are enough "tricks" to achieve the goal in another, OS friendly way (the mentioned wrapper, just notice the size at the beginning of the wanted memory space + (type)1 and give back the address + (type)1. This is the simplest way, there are more clever ways to do this).

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.

Well, you don't have to replace everything. There are very few apps that break. Even for SnoopDos there is a replacement now. So, you don't need so much developers to write replacements.

But the will to do so is quite small in most cases. Mostly developers find it easier to e.g. ask for AllocVec() specials to invest lots of work to get such stunts compatible for all known systems. Not very clever, I think.

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

Yes, I know this. If it would be possible I would invite you here to Germany to see it working yourself.

Some other users had problems which I helped to solve (especially on AW). Much of their problems resulted from not obeying the installation instructions (clean install) or failure of 3rd party programs (especially IBrowse installing old MUI classes, but some older libraries made problems, too, which could have been avoided by using the newest versions, for example expat.library).

For HDRec you could ask the author, he obviously did some speed tests for HDRec with OS4 final and gives the same results I achieved.

[whose]

@itix:

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.

Well, I would it call illegal, if everybody should know that these sections are write protected (well, in fact they weren't until final, but NDK states it).

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

But this is a complete other topic, isn't it? Or does it break because of the new memory system? I would think that this a question of correct OS function use.

Even OS4 developers do it. DiskSpeed OS4 assumes that memory returned from AllocVec() is aligned to 8 bytes boundary.

I see... hence it is a good practice to encourage such methods by refering to historical errors made and giving them a late "absolution"? I don't think so.

Show them the correct way, if you know about. Don't discuss old "tricks" and the compatibility break of these tricks a new designed OS gives or will give.

Damn easy.

Greetz

[whose]

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

Ok. Well, but in this case it would have been sufficient to say: "this doesn't work anymore, it is not documented and therefore "forbidden" to use. It will break with OS4, don't use such a detail".

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

Maybe. But one should ask himself, if such tools would work with OS4 or other OS. If (perhaps or sure) not, search for another, working, way. There are ways to develop such tools in a friendly way, even for OS4.

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

Greetz

[whose]

@piru:

Not directly, that is true. 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?

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

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

Greetz

[whose]

@piru:

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.

First: It was and is not meant as a personal offence, really.

Well, if I read more to your comments, why shouldn't (unexperienced) developers do? They will do it, and that's the problem. I spoke of "late absolution" given to such practices, this is an example.

Yes, was that in question anyway?

More or less.

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

Shouldn't it? Why? To support this tricks several decades more? To gain compatibility to broken software and discourage new developments in this direction?

I think that time will tell what the better way was. I don't see any real disadvantage for OS4 regarding the AllocVec() question.

Greetz