I just read through this thread on AW.net, (https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=43751&forum=42&start=40&viewmode=flat&order=0) which seemed to have a very positive response from almost all members there, and wondered if I had missed the discussion of it here, so I came back and searched, only to find nothing. So I decided to start a thread here, to make sure that those members here who do NOT visit AW.net, would have a chance to see it, and discuss it.

I imagine that AxRuntime would be very useful to many MorphOS 3rd party developers, as well as the AROS and AmigaOS developers, but correct me if I am wrong.

I see little point in this. Not only it is incompatible in numerous ways, such as forbid, disable etc, tasks / processes are using separate address spaces (as I understand it), it is also lacking GUI toolkits completely. In practice this is much like AROS was in the 90s. If you want something like this, use hosted AROS.

I'd as far as to challenge the usefulness of the thing: It is likely that your code will end up a #ifdef hell that has exceptions for native vs "ax" environment, trying to get things working at all. It will likely only build toy applications without major headaches.

People are reading way too much into usefulness of this thing. Notably most of these comments are coming from non-developers.

[ Edited by Piru 12.05.2020 - 21:35 ]

The whole point in the existence of MorphOS (and OS4) was that they could run Amiga software on newer hardware under a more up-to-date OS design without having to recompile them. As after all most were not open source and/or written in non-portable ways. To do that it was forced to accept the restrictions of the original AmigaOS, i.e. shared memory address, no SMP, etc.

It's like AxRuntime forgot this whole compromise ever happened and has gone back to the thing we rejected 30 years ago. I'm afraid it won't see much use - for the same reasons.

Quote:

Interesting response, and since it is coming from someone I regard very highly in the MorphOS Dev. Team, I don't need to dig any deeper into figuring out what AxRuntime is and how exactly it works.

The description of it running on multiple cores, and having protected memory usage, seemed like a "Good Thing" to have, plus some mention of being able to use modern Linux programming tools, like a debugger, etc., while creating the beginnings of your code, before then working out the "Native" requirements to get the coding project to work properly on the target platform. If that is not an advantage for most MorphOS developers, and the existing MorphOS SDK has all the needed tools, this thread can be closed, if the moderators want.

I'm a self proclaimed "Noob", programmer who is trying to learn, and always looking for anything that can help me.

Quote:
This is excellent description what is wrong with aros x86, aros arm and axruntime.
As long as there is compatybility with old 68k apps we may accept that there is no memory protection, no drivers, no smp, no java etc.
After breaking compatybility all of this should be fixed.
Nobody need exec dos devices etc with all its flaws that are not compatible with old 68k apps.


[ Edited by ppcamiga1 13.05.2020 - 06:34 ]

Quote:

But MOS devs don't use and know AROS (hosted). If you run one AROS instance (runtime) per (big) app things like isolated address space/memory protection (between app A running in AROS instance/runtime #1 and app B running in AROS instance/runtime #2)/resource tracking/multiple core use come automatically and for free.

Now for allowing ~ SMP (multiple core tasks/processes) *inside* each AROS instance/runtime which I'm skeptical about too, it's surely possible to have that a runtime option so it can be decided per-app (runtime) whether to activate this or not, as most apps would not take big advantage of it (and system tasks like Intuition/input.device hardly need any cpu resource).

Here is an old video of more than 20 AROS instances (~runtimes) running at the same time. Each Amiga-looking window/app is from a different instance. All 4 cpu cores of the machine used.

https://vimeo.com/191163338

The desktop/icons in the backround is Linux stuff, also there's some Linux terminal windows intermixed.

Quote:
As it is now, this project allows to turn (some) AROS applications into Linux programs that run in completely isolated sandboxes, which brings both benefits and limitations.

Unless a MorphOS third party developer plans to release software for AROS and to use the AROS APIs (Zune, etc.) anyway, there is not much there that might be of real-world use.

As Piru pointed out, even if you are an AROS software developer, you might potentially have to invest a lot of work to support AxRuntime depending on your specific project.

I am glad deadwood is "back" and still involved. He is a capable and selfless developer, who gave back most money he earned from AROS bounties and donated it to other projects. I wish him and this project the best.

From a technical perspective, this is an interesting project but it remains to be seen if developers will actually adopt it because they deem it to be advantageous compared to their existing workflow of crosscompling on Linux and testing via "AROS hosted" in a window.

For smaller projects, Hollywood is probably still the way to go to write software that runs on multiple platforms.


@Georg

Your Vimeo link does not appear to be valid.

Quote:

Really? Does the video show up if you search for "AROS Semi Rootless 2"?

419iqd.jpg