DELUXE ZORRAM

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@OlafS25

Quote:

OlafS25 wrote: @cdimauro in a perfect world and a living platform it would be fixed by the developers of the software. But on 68k we have a platform with mostly closed software so it is difficult to fix something. In this case either offer a workaround or accept that software not works. If it not breaks software and problem can be identified I am for the workaround.

WHDLoad shows that badly written or bugged software can be fixed.

BTW, I'm NOT fully against implementing workarounds at the o.s. level if this quickly solves the problem AND does NOT hurt the o.s. (its code and its future evolutions).


@OneTimer1

Quote:

OneTimer1 wrote: @OlafS25 Quote: OlafS25 wrote: in a perfect world and a living platform it would be fixed by the developers of the software. But on 68k we have a platform .... It's even worse, we have old software that will be never improved. So if Apple or Microsoft are marking an API as 'depreciated' most software will be updated to a new API quickly. On 68k we can't do this and every OS that should keep AOS Source code compatibility might run in the same problem. Making it difficult to improve the OS, just think about the reasons preventing a new AOS getting SMP or Memory protection. But that's a rant that is not really focusing on the problems with the ASL.library.

Indeed. The problem here is at the foundations: the Amiga os was badly designed, so its future was already crippled from the beginning.

There's no chance to have both backward-compatibility AND evolve/modernize it.

The 68k world and its "successors" should be kept as the they are, and run under a sandbox of a modern o.s. which is strongly inspired and partially compatible at the APIs level. However, that's a new thing, at thend.


@AMIGASYSTEM

Quote:

AMIGASYSTEM wrote: AROS 68k is considered an unstable system; the reason for this is that people want to use Amiga 3.1 software, which has poor compatibility, and if we then consider that OS 3.2 and 3.9 are completely incompatible. In my opinion, AROS 68k should only be used with native AROS 68k software, and Amiga software should only be used if it has been recompiled for AROS 68k; this would make it more stable and more appealing.

That shouldn't be the case: it's the wrong solution to the problem.

All Amiga/like o.ses should faithfully implement the original APIs. This is the foundation of any platform: the API (and ABI) should be clearly defined, the concrete implementations should implement them as expected, and then the general software should be written carefully following those interfaces.

This is the only way to guarantee overall compatibility (besides bugs).
Quote:

There is a lot of AROS x86 software that could be ported to AROS 68k, as well as software from other platforms. I have stopped distributing my AROS One 68k for this reason, mainly to prevent incompatible Amiga software from being installed and then being criticised for having an unstable distribution.

This Deluxe Music 2.0 issue/topic clearly shows what there are the solutions for running legacy software which isn't fully following the OS guidelines.

The net result is that AROS got improved and it's going towards it's primary goal: having Amiga o.s. 3.1 compatibility (binary, in this/68k case).

Stopping distributing AROS 68k versions slows down putting AROS at the same level of other Amiga o.s. (re)implementations.


@OneTimer1

Quote:

OneTimer1 wrote: @matthey Quote: matthey wrote: AROS 68k did not include Reaction last I looked. If it were compatible enough, it may be possible to install the predecessor ClassAct which is on Aminet. Reaction was 'officially' added to AOS3.1 + (n * 0.1) because Haage&Partner didn't had the rights for MUI. Haage&Partner had already included it into their Compiler and distributed it interdependently. So I'm asking myself if AOS3.1/AROS will be compatible enough to use newer AOS3.x programs (if some exist) if the library is installed exactly like AOS3.1 should be compatible to MUI applications if MUI is installed. A real compatibility breach with AOS3.1 would be catastrophic, on AOS3.5 or AOS3.9 you would still have AOS3.1 compatibility if you had installed the right libraries to AOS3.1. --- Making AOS3.2 partially incompatible to AOS3.9 would have been just another silly move of the AOS3.2 crew to split away from the only official AOS68k history tree we had. Distributing a slightly advanced AOS3.1 as AOS3.14 might have been valid but interfering with newer AOS3.x versions is just stupid.

MUI is NOT part of the Amiga o.s.. Yet, all post-Amiga OSes have implemented it.

The same can be done with Classact & Reaction.