@twilen: if even o.s. components used undocumented stuff, then I raise the white flag...

P.S. Regarding the bootable AmigaDOS disks, I remember that there should be a trackdisk.device pointer in some register that can be used to make other (read) requests. I used it load some sectors, and then give the control to my track loader. It should have been all "legal" (using public APIs/documentation). But after more than 20 years I might be wrong.

It isn't that simple (Implement only public API). For example most programs that come with bootable amigados disk would not have worked at all if only public APIs were implemented. It would have been totally useless ROM replacement.

Either you have code that can be used or you have code that looks nice and is great and shiny but is useless in real world. Make your choice.

For example there is _huge_ amount of undocumented BCPL stuff hidden under the surface that needed to be exactly right or even the most basic WB commands would break totally. (Even 3.0+ WB disk still have some BCPL remains left)

I agree that A3 = seglist is a bad idea because it appears to be randomly chosen register for jump address calculation, it has nothing to do with undocumented dos feature.

The problem here is that, applying this principle for every badly written application, you ends-up with a pile of extra, unwanted, "specs" to maintain.

Specifically, this case should be simple to handle, because the compressed applications would have been uncompressed, and compressed again with another o.s.-compliant packer (even a fixed Shrinkler).

However Toni shown that applying a fix for it is way faster than this discussion.

@cdimauro

I agree with you in principle, but if we prevent programs that were compiled in the 1990s (for example) from running, only users suffer.

@ncafferkey: I've a different approach. I'm for implementing only the public APIs.

I really hate the idea of fixing something only because lamers don't know how to write good code, and take any bad chance only to make their life easier.

Anyway, I saw that Toni Wilen already provided a fix for this "issue".

Quote:

We usually only implement what's officially documented, but we make exceptions sometimes for the sake of compatibility, especially for m68k programs that can't be easily recompiled IMHO it would make sense to implement this feature in AROS if it can be easily done.

Cdimauro: I think the answer to your question is yes. The packer takes advantage of the fact that all known kickstarts uses a3 in the same way when launching executables. This may not be officially documented behavior, but it seems that some apps have safely relied on it. The replacement rom should do the same if the goal is maximum compatibility, right?

Deadwood: I will do that. I didn't think Toni worked on the ROM also, but he seems to be able to do everything at once

@Hannibal

Hello and welcome. Thank you for the bug report. In case you don't get any response here, I think it would be good to post your findings also in this thread:

http://eab.abime.net/showthread.php?t=56211&page=19

I think Toni is more active on EAB.

The point should be different: must A3 point to the loaded segment list?

Note from the author of Shrinkler: "I have not looked at the AROS executable launcher code, but my guess is it leaves registers in a different state than the AmigaOS launcher. Shrinkler assumes that A3 points to the loaded segment list (4 bytes before the entry point) which is true for all Amiga kickstarts but might not be for AROS.

If A3 points to garbage, it could give the behavior you describe for mini-compressed executables (such as Octorubber) but executables crunched using the normal or overlap modes would likely crash earlier on."