Hello AROS Developers and Community,
I'm starting this thread to discuss a long-term goal that I believe is crucial for the future of AROS on x86/x64: achieving a seamless integration of 68k AmigaOS software.
Currently, as I understand it, running 68k applications on AROS x64 requires booting a full 68k OS (like AmigaOS 3.x or an AROS 68k build) within the Janus-UAE environment. This provides great compatibility but results in a "sandboxed" experience, where the 68k desktop runs in a separate window, disconnected from the native Zune environment.
I'd like to propose and discuss the technical feasibility of a more ambitious approach: retargeting the 68k AmigaOS API calls to the native AROS x64 libraries.
The core idea would be to move away from emulating the Amiga chipset for graphics and instead focus on wrapping the high-level API calls. Specifically:
* Intuition Library Proxy: Create a "proxy" version of the 68k intuition.library. When a 68k application calls a function like OpenWindow(), this proxy library would not execute 68k Intuition code. Instead, it would:
* Marshal the 68k function arguments (e.g., NewWindow structure).
* Translate them into the native AROS x64 format.
* Perform a "cross-architecture" call to the native IIntuition->OpenWindow() method in the AROS x64 intuition.library.
* Receive the native Window* pointer and return a corresponding 68k handle to the application.
* Graphics and Rendering Redirection: Calls to graphics.library (like RectFill, BltBitMap, etc.) made by the 68k application would be intercepted and redirected to draw directly onto the native Zune window's RastPort. This would completely bypass chipset emulation for UI rendering, making 68k apps behave like native Zune citizens.
* Input Event Translation: Native AROS x64 input events from input.device would need to be translated into IntuiMessage structures and posted to the appropriate 68k application's IDCMP port.
This would be a massive undertaking, requiring a robust marshalling layer to handle data structures, pointers, and endianness between the emulated 68k environment and the native x64 host. However, the benefits would be immense:
* True Seamless Mode: Run legacy 68k applications (like PageStream, ArtEffect, or even simple commodities) as individual windows on the Zune desktop.
* Unified User Experience: Copy-paste, drag-and-drop, and overall system coherence would become possible between 68k and native apps.
* Performance: UI operations would be executed as native code, potentially speeding up interface rendering significantly compared to full chipset emulation.
Projects like WINE on Linux (for Win32 apps) or even the "JIT-ing" of PPC code on classic Amigas for MorphOS have proven this API-retargeting concept is powerful.
I'm aware this is not a weekend project, but I'd like to ask the developers:
* Is this a direction the AROS team has considered?
* What are the biggest technical roadblocks you foresee in the interaction between the Trance JIT environment and the native host system for this to work?
* Could the existing Janus-UAE integration serve as a foundation for this, perhaps by replacing its chipset emulation module with an "API-proxy" module?
Looking forward to a constructive discussion.
Best regards,
GermamCMan

It's impossible. A simple example: use the 64-bit pointer given back by a native API. Not only it's double the size (so, the 32-bit 68k environment can't use it, and can't even store it, because it's expecting a 32-bit one), but it's little-endian (the 68k is big endian).

Workarounds are possible, but only on simple cases: the more complex are the data structure, the more difficult is creating such workarounds (e.g. "proxies" / "mirrors" / "duplicates", up to a certain point were no workarounds can be created anymore.

Forget it, and live in peace.

You are absolutely right. A simple, direct "retargeting," as the thread's title might imply, would run straight into the fundamental problems you've mentioned (pointer sizes, endianness, structure complexity). I completely agree that such a direct approach is unfeasible.
In fact, your analysis serves as the perfect starting point for the real solution. By anticipating precisely these obstacles, the proposal has evolved into a far more robust and abstract architecture (which we could call ARUX), specifically designed to sidestep these issues:
* On Pointers & Endianness: No native pointers are ever passed. The system uses a handle system (32-bit IDs), and a communication bridge is responsible for all necessary endianness conversion. The 68k environment never has to store data it can't handle.
* On Data Structure Complexity: We don't mirror complex structures. For applications, the 68k proxy library interprets the programmer's intent and translates it into a high-level command. For games and hostile software, we simply redirect the final, rendered video stream, completely ignoring its internal complexity.
Therefore, your critique doesn't invalidate the goal; it reinforces the need for the more sophisticated technical solution now being proposed. Thank you for helping to demonstrate exactly why a smarter approach is required.

Please follow the New update that solves it all. ARUXhttps://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1431&pid=8567#post_8567

The main problem is that 68k applications do NOT use handles, but pointers. And they dereference pointers, and access the referenced data.

That's the reason why it's impossible to implement your idea.

Handles require a new OS which is able to work with them. But this is a completely different project.

P.S. Sorry, but I don't like Unix, and I will not follow the other discussion.

As the one who has done the so far only m68k integration I wish you good luck. I started something like you mentioned before I did janus-uae, but you will run into so many unsolvable problems, you won't come far. You would have to convert so many structures which can't be translated. Even if you can convert them you don't know how the user code accesses them.

But prove me wrong with code then I will believe in your way of doing it.

Although I do like Unix (those who don't don't understand it ;-) ), but I also won't follow any further discussion.

Thanks for your great work on Janus-UAE. Are there any chances for further development of this emulator, or at least compilation of the current version under x86_64?

It would be great to be able to run Amibridge on aros 64bit as well.

It’s a true honor to reach out to you. To me, your work on the emulator for AROS is absolutely fascinating, and I’ve thought deeply and extensively about it… May I ask you a few questions regarding it?
Initially, I had considered using Janus without Amiberry, but since it’s based on Linux, I saw an opportunity to take the simpler route and leaned toward Amiberry—though I always felt a pang about not having used Janus’ work.
You are very familiar with the emulation of the OS3.x API and custom chips.
This concept truly requires that level of knowledge, and your feedback on the ARUX repository would be invaluable to me. As you’ll see, it’s just a starter repo—I don’t want to add code until I’ve firmly established the foundations. I’m working on the ARUX SDK, and I want it to be as compatible as possible with MorphOS, OS4.x, and AROS x86/64. That may sound a bit crazy, but it’s really not—there’s a trick in ARUX that, as you’ll see, involves a very interesting accelerator that allows us to avoid starting from scratch. In fact, the result will enable a native AROS for ARM/x64 that’s truly unprecedented. I believe this path leads to a development approach that reduces programming time and boosts final performance—something the end user will greatly appreciate.
On top of that, Linux users will finally have a system that’s user friendly, something they haven’t quite achieved yet, as their systems aren’t built for "mouse-only" interaction. ARUX aims to be like AmigaOS: a system that doesn’t require CLI/bash except for rare or exceptional cases.
I invite you to take a look at the ARUX repository. Please feel free to use your preferred AI to explore the technical details.
Once again, I’m incredibly excited to hear your thoughts, as I admire all members of the AROS project—and you especially for your work on the JIT, which looks so impressive on ArosOne.
Thank you so much in advance. Whatever your comments may be, I will embrace them as wise words.

Janus-UAE is "just another uae", in fact it was e-uae if I remember correctly, which learnt to do some magic tricks to copy the windows contents of the m68k windows to native aros windows and which hides the real 68k screen completely. It then syncs mouse movements, forward menus events and window movements as well as keystrokes. So it gives you an illusion of integration.

Examples:
- You move a host x86 window => janus uae checks window movements and moves the m68k window on the m68k screen accordingly.
- User clicks the right mouse button in a m68k window, janus-uae detects it, copies the m68k menu structure to the x86 window and simulates a right mouse click there. Once the user selected a menu item, janus moves the m68k mouse pointer to the same - on the x86 selected - menu item and releases the m68k right mouse button.

It has nothing to do with jit (e-uae already had one), the native chipset (p96 screens) or most of that stuff you mentioned. Even the os3 API is not changed, just some normal os3 calls to get windows and menu data from normal os3 tasks.

It's just some "clever" syncing of mouse and other data/events between the host and the guest.

Thank you so much for taking the time to explain the internal workings of Janus-UAE in such great detail.

This is the core of ARUX. That is the Janus new vision like...

Instead of syncing a 68k AmigaOS window with an AROS window, ARUX proposes that the intuition.library/OpenWindow() call doesn't open a 68k window at all, but instead directly calls the GTK/Qt API to create a native Linux window. Instead of dos.library/Open() running in the emulated environment, it would be a proxy that makes a native POSIX open() call on the Linux filesystem.

The emulator (our idea is to fork Amiberry) would still be crucial, but its role would change: instead of running the entire system, it would act as a "compatibility server" for legacy components that are too complex to rewrite, such as ARexx or old datatypes.

We call this a "functional bridge" rather than a "visual bridge". (Amiberry will hide a modified aros68k)

And this is where, honestly, your collaboration would be invaluable. The person who has mastered the art of synchronizing events and data between the host and the guest is, without a doubt, the most qualified person in the world to design and lead the architecture of this new type of bridge. No one understands the challenges of latency, data serialization, and state management between these two worlds better than you.

We have outlined this vision in a document in our GitHub repository. We believe that the most complex and crucial piece of the entire project is precisely the "ARUX Execution Engine"—the fork of Amiberry that would handle this communication.

I know it's a bold proposal, but seeing what you achieved with Janus-UAE, I can't help but think you would be the ideal person to technically lead that part of the project.

I would love for you to take a look at our vision and architecture when you have a moment. Not to criticize your work, but because your work is proof that these ideas, while ambitious, are possible.

You can view the document here: https://github.co...TECTURE.md

Thank you again for your time and for your incredible work in the community.

I am also opening my arms to all users and developers of AROS, undoubtedly the community that thinks outside the box. AROS is not just the movement; it will be the future, and I believe the future requires certain changes in focus, taking into account new tools and possibilities.

The OS3.x API you all have created has inspired very good projects, and currently, MIRARI and PiStorm are new projects that can contribute from two different points of view that converge in ARUX. Here, we can culminate the genius of AROS in a parallel project that aims to be compatible with the MorphOS SDK, without needing transpilation or reinventing the wheel.

Best regards.

The link you provided leads to a 404..but I guess it is the text on the start page.

Sorry, I don't have any spare time at the moment and even if, I fail to really understand the stuff written there.

I guess you are using an AI to write all those texts?

Nevertheless, unless you have at least some kind of running code (or at least any code at all) I won't come back here and invest no time.

There is no point in inviting developers with kind words and euphoric sounding "world changing" goals, that's not the way to get them. Do some concrete stuff and others might join.

And no, an AI won't do any of the real work. It hardly can produce any reasonable results at all IMHO.