Which OS Would Be The Best Amiga Way Forward...

[Kronos]

You can´t expect the EmuAmiga guys to have a full working version when they are just starting out. If they keep at it, they will have a much better situation then e.g. the WINE-team because they already have source compatibitly. Compared to a Windows-ABI their job is indeed closer to the trivial side. It will take time though and the other guys are definitely ahead on this one.

a) Wine only works on x86-systems (endians being just one reason)
b) source code compability is actually a problem as it's even harder to keep both APIs seperate (don't expect a Win-app directly calling a Linux-function or a linux-app directly accessing a Win-DLL)
c) if an API is tightly defined and constructed with endians in mind it's "trivial" (like with Rosetta in OSX) if it's just ancient stuff rushed onto one very specific CPU and HW leaving lots of functionality to app-devlopers poking around in structures it becomes impossible.

For it to work it would need to have EVERY system-structure twice in memory both appearing at the same address (possible with MMU) for x86 and 68k. Both closely monitored for changes (also possible with MMU).

O.k. thats allready messy, but you would also know every 3rd party structures that may be shared between x86 and 68k at any point. Thats were we go into impossible.

[Kronos]

I
Because Piru knows that it is feasible.

And how would you know not only that it is feasible but also that Piru know it too ?

It's really just as feasible as a ColdFire-accel.
On 1st sight it seems trivial.
On 2nd sight it seems feasible.
Once you start impementing it you'll notice that you have to keep up of much more than you thought.
If you actually get it running it's performance will be dissapointing (Elbox's Dragon-proto peformt like a 020 and only ran preselected SW).

One has to remember what is the goal of EMUMiga, run x86 and 68k SW seamless, something which will only work if all API calls return the same results on both sides and if data is compatible. Problem is both sides expect the date to be sorted/orientied differently and thats where it end cos at one point you will into a situation where the OS/EMUmiga doesn't know wether a pointer points to an ULONG (change endians) or an array of BYTE (must keep the order).

Solution would be:
a) make an AROS where all data/structure are 100% identical to AOS68k not a big issue on bigendian HW, but a nightmare (and performance killer) on littleendian.
b) run a heavy MMU-setup monitoring all accesses to OS and 3rd-party structures. Also performance killing and by definition never complete.

Or c) Just use Janus-UAE and ignore the fact that you are running a 2nd OS hidden inside the emulation

Bout that UTube-clip, indeed not very funny but if thats enough to wind you up I'd recommed to grow some thicker skin.

I do remember avatars with characters peeing on an shooting at the MorphOS-butterfly (without anybody ever really bothering) or if you really insist I'm sure someone could post you to some rather nice ann.lu threads.... heck or just some more recent amigians.net ones ;(

Edit:
Or just this thread were someone claimed that a core MorphOS developer intentionally lied about the feasibilty of what one might consider a competing product.

[Kronos]

And what would be the point of that ?

Seamless means seamless, under MorphOS (and OS4 too) one can install a newer/better PPC-lib/MUI-class and all 68k useing that lib/class will benefit.

One can also write PPC-apps that rely on 68k libs/classes (when there is no PPC version available).

If all you want is to run 68k apps with the pure OS3.x API (Janus)-UAE is the far better choice.