not sure if such an "object oriented" approach is not an overkill when applied in every case, but i would leave it to experienced developers to decide. apparent fact remains, that vampire asm driver seems to work reasonably fast with aros.

AROS is much "cleaner" coded, than AmigaOS3.1.

AmigaOS3.1 takes quite some shortcuts for speed, where AROS follows more the logical design.

For example, menus are real intuition windows in AROS. So when you click the right mouse button in AROS, a window containing the screenbar appears, then a window for every menu and for every submenu. AmigaOS simply draws directly to the screen bitmap. AmigaOS is much faster here obviously.

Hello,
is there any way to change that mc68000 compilation,
and missing mc68030 and mc68040,
implement code,
to be a good substitute for Amiga OS 3.1,
I believe that there is the way.

the main reason is that it is slow. not in executing binaries, as binary code executes same speed on same hardware of course, but calling system functions, especially in graphics area may be slow. vampire team have worked around it with their own driver written in asm which looks fast, but the native gfx aros drivers, using p96 wrapper are slow, and limited, for instance they tend to run out of graphics memory on the card (vram) or chip when opening multiple screens or loading a lot of imagery, as they arent able to swap out.

also aros is currently basically compiled for plain mc68000.

The status page is quite dated, I guess.

I like to understand the status of AROS for m68k, as a replacement of AmigaOS 3.1 on classic hardware.

In short, what are the major reasons we cannot just use it today as a proper replacement?

I gather that there are some performance issues, can someone elaborate a bit on it? What about completeness? Looking at the status page seems to indicate that a lot of things are in place, but there are also parts missing?

Are there people working on it?

Reference:
http://www.aros.org/introduction/status/everything.php