AROS World Exec
Development => Development (General) => Topic started by: deadwood on May 06, 2020, 12:22:19 PM
-
Hello,
I wanted to share with you something I've been working on for some time. The project is called AxRuntime and it allows re-compiling existing Amiga/MorphOS/AROS software as Linux applications.
The runtime allows developers to continue developing Amiga applications in unmodified way while at the same time being able to utilize modern development tools available on Linux like IDEs, debuggers, profilers, etc.
This solution lets developers compile their Amiga API-based applications as Linux binaries. Once the features are implemented, tested and optimized using the runtime on Linux, developers re-compile their applications for their Amiga-like system of choice and perform final quality checking.
Applications created with AxRuntime can be distributed to the Linux community giving developers a much broader user base and a possibility to invite developers from outside general Amiga community to contribute to the application.
Here are some videos of AROS applications running under Linux:
Wanderer: https://www.axrt.org/media/axrt-Wanderer.mp4
MPlayer: https://www.axrt.org/media/axrt-MPlayer.mp4
More images in gallery: https://axrt.org/index.php?tab=gallery
Download & Instructions
====================
https://axrt.org/index.php?tab=download
Release notes
====================
AxRuntime v41.2 - 2022-04-04
This release uses bases components of AROS ABIv11 release 20220318-1.
See AROS ABIv11 20220318-1 release notes (https://axrt.org/index.php?tab=releasenotes-aros-v11#ABIV1120220318-1) for details.
AxRuntime 41.2 changes:
Functionalities:
Updated to use the same ABI as AROS x86_64. (deadwood)
This resulted in updating the major version string from 2.0 to 4.0.
Note that both major versions of AxRuntime can be installed
side-by-side.
Enabled execution of AmigaDOS shell scripts (deadwood)
Enabled using native AROS x86_64 libraries (deadwood)
Enabled running native AROS x86_64 programs directly under Linux (deadwood)
Adjustements needed to allow developing AxRuntime programs using Pascal (deadwood)
Support passing command line arguments to AxRuntime programs (deadwood)
Moved configuration required for compilation and linking to specs file (deadwood)
User can now customize configuration via USERSYS:S/User-Startup (deadwood)
Exposed functions to control Amiga to Host path conversion (deadwood)
Fixes:
Debian packages are now standard compliant (deadwood)
Expose only few required symbols from binaries instead of all symbols (deadwood)
Improvements to Amiga to Host path conversion (deawdood)
Application changes:
MPlayer 1.1
Re-compiled for 4.0 major version. (deadwood)
WookieChat 3.2
Nick provided during initial setup is user for pre-configured channels. (deadwood)
Re-compiled for 4.0 major version. (deadwood)
AROS-Shell 41.3
Initial release allowing AmigaDOS scripts to interact with complete Linux filesystem. (deadwood)
Final Writer 7-Demo
Initial release. (Final Writer Development Team, deadwood)
-
I will keep updating the first post as new release happen. Please post your questions, comments, suggestions below.
-
this deadwood thing is very interesting, but i'm not a programmer, let's hope someone benefits :)
-
Hi All,
I released a new version of AxRuntime.
Major highlights are:
- Introduce network support (bsdsocket.library)
- New version of MPlayer with updated ffmpeg and audio driver fixes
- First version of WookieChat
More information in first post.
-
Brilliant idea! just the kind of solution that can help Aros. Hope it encourages more developers to port apps or develop new ones.
Congratulations for you fantastic job as usual, Deadwood.
-
Hi All,
I'm currently working on refreshing of AxRuntime. If you are using Linux, it would be helpful if you tried building current version. I extended build instructions with building Linux-native Wanderer. Please let me know how this works for you:
https://github.com/deadw00d/AROS/blob/alt-runtime/INSTALL.md
-
Hi All,
I'm currently working on refreshing of AxRuntime. If you are using Linux, it would be helpful if you tried building current version. I extended build instructions with building Linux-native Wanderer. Please let me know how this works for you:
https://github.com/deadw00d/AROS/blob/alt-runtime/INSTALL.md
/home/vinny/myrepo/AROS/AROS/rom/exec/./newaddtask.c:76: undefined reference to `pthread_yield'
/usr/bin/ld: warning: creating DT_TEXTREL in a shared object
collect2: error: ld returned 1 exit status
make[1]: *** [mmakefile:1575: /home/vinny/myrepo/AROS/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/AROS/boot/runtimelinux/Libs/exec.library] Error 1
[MMAKE] make --no-print-directory TOP=/home/vinny/myrepo/AROS/alt-runtimelinux-x86_64-d SRCDIR=/home/vinny/myrepo/AROS/AROS CURDIR=rom/exec TARGET=kernel-exec --file=mmakefile kernel-exec failed: 512
[MMAKE] Error: Error while running make in rom/exec: No such file or directory
make: *** [Makefile:121: all] Error 10
-
Thanks! What Linux are you using?
-
I made some change, please refresh your repo
$ cd myrepo/AROS
$ git pull --rebase origin alt-runtime
$ cd ..
and then run
$ ./rebuild.sh
again
-
Thanks! What Linux are you using?
Pop!_OS 21.10 x86_64
Kernel: 5.15.15-76051515-generic
gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0
-
Ok, that's quite new gcc, but should be ok. Let me know if the changed fixed the build for you.
-
I made some change, please refresh your repo
$ cd myrepo/AROS
$ git pull --rebase origin alt-runtime
$ cd ..
and then run
$ ./rebuild.sh
again
| ^~~~
make[1]: *** [mmakefile:176: /home/vinny/Documents/projects/myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/gen/arch/all-hosted/filesys/emul_handler/emul/arch/emul_host.o] Error 1
[MMAKE] make --no-print-directory TOP=/home/vinny/Documents/projects/myrepo/alt-runtimelinux-x86_64-d SRCDIR=/home/vinny/Documents/projects/myrepo/AROS CURDIR=arch/all-unix/filesys/emul_handler TARGET=kernel-fs-emul-runtimelinux --file=mmakefile kernel-fs-emul-runtimelinux failed: 512
[MMAKE] Error: Error while running make in arch/all-unix/filesys/emul_handler: No such file or directory
make: *** [Makefile:121: all] Error 10
-
Ok, exec problem has been solved. Can you paste some more (previous) output from build - I need to see previous errors.
-
Ok, exec problem has been solved. Can you paste some more (previous) output from build - I need to see previous errors.
Do you know if it is kept in a log somewhere? I can then attach the whole file perhaps.
-
It might be in alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/gen/errors
-
Check on Discord. I have attached the file there
-
Ok, I see where the problem is. I'll look into a solution.
-
Fix pushed. Please update and rebuild. :)
I did a complete build under Pop!OS 21.10 so you should not get more surprises. One thing to note is that Right-Buttom menu displays underneath the Pop!OS top bar. It is there, but not visible. If you move your mouse to it, submenus will become visible.
-
Fix pushed. Please update and rebuild. :)
I did a complete build under Pop!OS 21.10 so you should not get more surprises. One thing to note is that Right-Buttom menu displays underneath the Pop!OS top bar. It is there, but not visible. If you move your mouse to it, submenus will become visible.
Makedepend workbench/classes/datatypes/jpeg/jpegclass.c...
Makedepend bin/runtimelinux-x86_64/gen/workbench/classes/datatypes/jpeg/jpeg/jpeg_end.c...
Makedepend bin/runtimelinux-x86_64/gen/workbench/classes/datatypes/jpeg/jpeg/jpeg_getresident.c...
Makedepend bin/runtimelinux-x86_64/gen/workbench/classes/datatypes/jpeg/jpeg/jpeg_start.c...
/home/vinny/Documents/projects/myrepo/AROS/workbench/classes/datatypes/jpeg/./jpegclass.c:36:10: fatal error: jpeglib.h: No such file or directory
36 | #include <jpeglib.h>
| ^~~~~~~~~~~
compilation terminated.
Compiling bin/runtimelinux-x86_64/gen/workbench/classes/datatypes/jpeg/jpeg/jpeg_start.c
Compiling bin/runtimelinux-x86_64/gen/workbench/classes/datatypes/jpeg/jpeg/jpeg_getresident.c
Compiling workbench/classes/datatypes/jpeg/jpegclass.c
Compiling workbench/classes/datatypes/jpeg/stubs.c
Compiling workbench/classes/datatypes/jpeg/memory.c
/tmp/ccxoDELJ.s: Assembler messages:
/tmp/ccxoDELJ.s:444: Warning: setting incorrect section attributes for .text.romtag
Compiling bin/runtimelinux-x86_64/gen/workbench/classes/datatypes/jpeg/jpeg/jpeg_end.c
Compile failed: /usr/bin/gcc -iquote /home/vinny/Documents/projects/myrepo/AROS/workbench/classes/datatypes/jpeg/./ -iquote /home/vinny/Documents/projects/myrepo/AROS/workbench/classes/datatypes/jpeg -iquote . -mcmodel=large -mno-red-zone -I /home/vinny/Documents/projects/myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/AROS/Development/include -D__AROS__ -O0 -fno-omit-frame-pointer -fno-common -Wno-pointer-sign -Wno-parentheses -g -fPIC -fvisibility=hidden -DAROS_BUILD_TYPE=AROS_BUILD_TYPE_PERSONAL -DADEBUG=1 -DMDEBUG=1 -DMYDEBUG -DAROS_LC_SETFUNCS -I/home/vinny/Documents/projects/myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/gen/workbench/classes/datatypes/jpeg/jpeg/include -include /home/vinny/Documents/projects/myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/gen/workbench/classes/datatypes/jpeg/jpeg/include/jpeg_deflibdefs.h -D__AROS_GIMME_DEPRECATED__ -D__SRCFILENAME__="workbench/classes/datatypes/jpeg/jpegclass.c" -c /home/vinny/Documents/projects/myrepo/AROS/workbench/classes/datatypes/jpeg/./jpegclass.c -o /home/vinny/Documents/projects/myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/gen/workbench/classes/datatypes/jpeg/jpeg/jpegclass.o
/home/vinny/Documents/projects/myrepo/AROS/workbench/classes/datatypes/jpeg/./jpegclass.c:36:10: fatal error: jpeglib.h: No such file or directory
36 | #include <jpeglib.h>
| ^~~~~~~~~~~
compilation terminated.
make[1]: *** [mmakefile:1031: /home/vinny/Documents/projects/myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/gen/workbench/classes/datatypes/jpeg/jpeg/jpegclass.o] Error 1
make[1]: *** Waiting for unfinished jobs....
/home/vinny/Documents/projects/myrepo/AROS/workbench/classes/datatypes/jpeg/./jpegclass.c:36:10: fatal error: jpeglib.h: No such file or directory
36 | #include <jpeglib.h>
| ^~~~~~~~~~~
compilation terminated.
[MMAKE] make --no-print-directory TOP=/home/vinny/Documents/projects/myrepo/alt-runtimelinux-x86_64-d SRCDIR=/home/vinny/Documents/projects/myrepo/AROS CURDIR=workbench/classes/datatypes/jpeg TARGET=workbench-datatypes-jpeg --file=mmakefile workbench-datatypes-jpeg failed: 512
[MMAKE] Error: Error while running make in workbench/classes/datatypes/jpeg: No such file or directory
make: *** [Makefile:121: all] Error 10
Not sure what you mean about the submenu. Take a screenshot if you can.
-
You are missing a development package on linux side. The list from install instructions should take care of it. :)
$ sudo apt install subversion git-core gcc g++ make gawk bison flex bzip2 netpbm autoconf automake libx11-dev libxext-dev libc6-dev liblzo2-dev libxxf86vm-dev libpng-dev gcc-multilib libsdl1.2-dev byacc python-mako python3-mako libxcursor-dev cmake genisoimage libjpeg-dev
-
I ran them at the beginning but I ran them again. I had this message. Just FYI.
However the following packages replace it:
python3-mako
E: Package 'python-mako' has no installation candidate
removed python-mako from the list and had no errors this time. I saw it grabbed the libjpeg or some like that. Now it's cooking with the right oil :)
Waiting for the script to finish..
-
inking AROS/Development/Debug/Tests/utility/utility50...
Linking AROS/Development/Debug/Tests/utility/vartags...
[MMAKE] Making boot in boot
Writing /home/vinny/Documents/projects/myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/AROS/AROS.boot...
[MMAKE] >> Making AROS
2496 /home/vinny/Documents/projects/myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/gen/errors
Looks like it completed? Going to the next steps of validating now..
-
SUCCESS!!!
-
Great! Now you can browse your entire file system with Wanderer. You can't yet create directories with Wanderer, but that will come at some moment. You can also try compiling other parts of AROS. Some of them may already work, some may not yet. For any other executable, you just need to copy the loader. For example the AHI settings programs (which is already compiled), should also work now :)
-
That's very interesting!
So, what if I want to compile a simple SDL2 hello world for AROS, can I use AxRuntime the other way around?
-
I think the best answer is for your case is like this: think about AxRuntime like a set of additional libraries that you can use in your Linux application. If you application uses SDL2, it will use Linux-side SDL2 which will open a Linux window that is not controlled by Intuition. However in the same application you can use Dos calls to read files, or show Intuition requesters or use Datatypes. This will work together with Linux-side SDL2. Of course this application won't be available under AROS, because we are missing SDL2 port ATM.
-
Hi,
Some update from me: I'm currently working on making AROSShell to be available under Linux. This means AmigaDOS commands and scripts can be used directly when using Linux.
(https://axrt.org/media/axrt-shell.jpg)
-
I am only wondering what you are aiming to?
a kind of linux distribution with look&feel and all libraries from aros?
-
There are two directions.
From developers point of view, this should shorten development cycle and let you use modern tooling available on Linux, which is not always available on Amiga-like OSs. There is already one uses describe here: https://www.sicpers.info/2020/05/continuous-integration-for-amiga/
From users point of view, eventually this can lead to what you describe. A system with look & feel & behavior of AmigaOS, but running on wide range of hardware as well as having modern applications (read: browser). Ideally someone who is interesting in building distributions would step up to this, I would focus on providing software.
-
There are two directions.
From developers point of view, this should shorten development cycle and let you use modern tooling available on Linux, which is not always available on Amiga-like OSs. There is already one uses describe here: https://www.sicpers.info/2020/05/continuous-integration-for-amiga/
From users point of view, eventually this can lead to what you describe. A system with look & feel & behavior of AmigaOS, but running on wide range of hardware as well as having modern applications (read: browser). Ideally someone who is interesting in building distributions would step up to this, I would focus on providing software.
sounds interesting. There should be people interested in supporting it, f.e. a new version of icaros desktop. It sounds a little (naiv said of course ;) ) like what Michal already started. Perhaps you two could work together on it.
-
I assume you refer to Arix? As far as I know Michal wanted to take it one step further that I do - create a new, better API. I think both project have similar trajectory and they could definitely share code between each other. I think Michal has his hands full with emu68 at the moment though.
-
I assume you refer to Arix? As far as I know Michal wanted to take it one step further that I do - create a new, better API. I think both project have similar trajectory and they could definitely share code between each other. I think Michal has his hands full with emu68 at the moment though.
And what is your vision? Creating a "aros layer" like the win32 api on 64bit windows?
Yes Michal sounds like he wants to go further. But perhaps there is some room to work together. And yes I think too he is busy with emu68 at the moment (and propably for some time)
-
There are two goals I want to eventually reach. First is to turn a standard Ubuntu/Linux Mint desktop into something that feels like an Amiga-like system so that on a surface you don't see a difference between this and native AROS. Second is to extend lifetime of still-developed Amiga applications by giving authors a much much bigger user base (= Linux community).
-
There are two goals I want to eventually reach. First is to turn a standard Ubuntu/Linux Mint desktop into something that feels like an Amiga-like system so that on a surface you don't see a difference between this and native AROS. Second is to extend lifetime of still-developed Amiga applications by giving authors a much much bigger user base (= Linux community).
sounds like a concept :)
perhaps the maintainer of icaros desktop is interested to make something. That would be something people always asked for
-
Hi
I'm sharing with you results of my latest developments! So far it was possible to build an Amiga application as a Linux executable with AxRuntime. I already recompiled MPLayer and WookieChat so time ago and I'm actively using AROS MPlayer under Linux Mint as my media application. What was so far not possible however is to run an executable from within AxRuntime program itself. Think Shell - it is a command line program that allows you to run other programs, write scripts that run other programs, pipe output of one program to another and so on. Now, with the latest developments I've made a step towards enabling this where a program that is compiled to work with AxRuntime can be started from Linux but at the same time can be started from AROS Shell. Here is a nice screenshot:
(https://axrt.org/media/axrt-shell.jpg)
We are not yet fully there, more work is needed but it is functional enough to provide first preview builds. Since this is work in progress build, there is no new AxRuntime release yet. The archive below packages together AROS-Shell with runtime so that it is fully independent and can be started without installing additional dependencies. You can download AROS-Shell from here: https://axrt.org/development/AROS-Shell-20220221.zip
I'm open to feedback and I'm always available to help out if you want to try to compile your Amiga application to run natively on Linux using AxRuntime.
-
Impressive. One question: are "Ax applications" able to communicate each other, like on Amiga o.s.? Or is each application fully isolated?
-
@deadwood
really impressive
-
Impressive. One question: are "Ax applications" able to communicate each other, like on Amiga o.s.? Or is each application fully isolated?
That's a complex question to answer - depends on what do you mean by "communicate". Each Ax application is an separate Linux process so by default they have separate address spaces.. however if an Ax application is started from another Ax application (RunCommand, System) they then share address spaces. I think in future it will even be possible to have communication between two Ax applications started from Linux - it all depends on needs of developers. If there are valid use cases for this I will look into providing such functionality.
-
one question... is it possible to combine Linux components with aros? I mean f.e. using a Zune GUI that access linux components using linux API?
-
Yes, you can :) You can create applications that have Zune API and use all other Linux libraries. For example, Ax-compiled MPlayer uses Zune GUI but the C library is the Linux C library, not the AROS one.
-
Mr. Spock would say "fascinating" :)
-
I think to create interest in the community you must have something to show. I mean f.e. having wanderer desktop running on it and you launch linux applications that would create a lot of interest in it. I saw video running wanderer on top of linux already. It would be nice (naive said) if it would also include linux apps so you could launch firefox from it as if it would be a aros app. And of course wanderer in full screen mode as a full desktop.
-
I follow your reasoning and I will definitely help and suggestion with regards how to interest people in using it once I have ground work done. I'm still experimenting with certain aspects.
-
I follow your reasoning and I will definitely help and suggestion with regards how to interest people in using it once I have ground work done. I'm still experimenting with certain aspects.
yes just ideas...
I think if ground work is done and wanderer works like a linux desktop integrating both aros and linux apps there will be real interest at it
-
Impressive. One question: are "Ax applications" able to communicate each other, like on Amiga o.s.? Or is each application fully isolated?
That's a complex question to answer - depends on what do you mean by "communicate". Each Ax application is an separate Linux process so by default they have separate address spaces.. however if an Ax application is started from another Ax application (RunCommand, System) they then share address spaces. I think in future it will even be possible to have communication between two Ax applications started from Linux - it all depends on needs of developers. If there are valid use cases for this I will look into providing such functionality.
The current implementation is certainly better, because it offers part of processes isolation which was completely missing on Amiga o.s. & co..
Communicating between two application was usually common on the Amiga o.s. land. AREXX was the most notable example of applications that communicate each other via message passing, using the AREXX runtime which was a facilitator, and of course this requires sharing the same address space.
However, and as I stated at the beginning, the current implementation of the AxRuntime is more solid and definitely preferable. The option to share the address space is second priority.
-
I think message passing will be doable across separate address space processes. Message, unlike a memory location (a pointer passed around), is always "owned" by one of the processes, so you can think of copying the message back and forth between processes address spaces. Of course the sender could be modyfing a message after it was sent (and that's agaist the idea of messages) and this case won't work.
-
when you have done the foundations I would be really interested in it. It is a little like Aros 68k was, with it you could mix Aros and Amiga components and create something new. AxRuntime offers the chance to do the same with Linux. Great project 8)
-
I think message passing will be doable across separate address space processes. Message, unlike a memory location (a pointer passed around), is always "owned" by one of the processes, so you can think of copying the message back and forth between processes address spaces. Of course the sender could be modyfing a message after it was sent (and that's agaist the idea of messages) and this case won't work.
Not only that: if the message is a complex structure containing pointers... then passing it to another process doesn't work either.
-
@cdimauro
True, that's the case of "randezvou" address in memory. Programs using this will be problematic at least.
-
when you have done the foundations I would be really interested in it. It is a little like Aros 68k was, with it you could mix Aros and Amiga components and create something new. AxRuntime offers the chance to do the same with Linux. Great project 8)
The question is what would be the "next step" from user perspective. You described Wanderer as Linux desktop replacement. That's sizable amount of work and Wanderer will still be subpar to any "Linux" desktop. It would be good to figure out what are smaller steps that are useful to people. Another thing to think through is whether we can engage not only current Amiga community, but also people who used Amiga back in a day and today use Linux. Give them a way to reminiscence past without sacrificing what they are used to.
-
I am not sure if both groups are not different. You have current community and you have people outside, in best case with amiga memories. I think to make users of current community happy a amiga desktop is best even if it is not on same level as current linux desktops. To attract users from outside with some amiga background perhaps using a normal desktop with lots of configuration is best and adding amiga software or to be precise amiga-like linux software.
-
Well, here we're talking of having Amiga applications ported to Linux. So, not Amiga-like: they ARE Amiga applications. :D
The point is how much important is trying to port Wanderer to Linux. Wanderer mimics our beloved Workbench, but both were/are quite limited, and is the reason why alternatives (DOpus is the best example) were born. IMO it's better to port the alternatives, at this point in time.
A future thing which might be implemented is porting 68K applications as well. I mean: applications that use 68K assembly in their source codes. So, you have the possibility to compile them, getting native binaries (and much better performances, since you can optimize the generated native codice way better).
The 68K emulator/JITer could stay on a shared library, to reduce the footprint AND making its core easy to update (while not requiring a recompilation of all applications. Unless for big / major changes).
This is something which I think about since years (as well as the 68K "virtualizer". Which is similar to the work being done on Michal's Emu68), but it's a quite complex project.
With the same approach, many things from the original hardware could be ported to native applications. O.s.- friendly applications (e.g.: applications that relay on the Amiga hardware, but using the o.s. APIs for accessing it) should be easier to port (most of the code is already on AROS). But this is, again, a complex stuff to implement.
-
I think message passing will be doable across separate address space processes. Message, unlike a memory location (a pointer passed around), is always "owned" by one of the processes, so you can think of copying the message back and forth between processes address spaces. Of course the sender could be modyfing a message after it was sent (and that's agaist the idea of messages) and this case won't work.
Pardon the intrusion but isn't that what IPC (on/via the host system) can be used for ?
You can then even share address space (virtual memory) between processes. Perhaps a bit more complicated than directly communicating between two applications but can be implemented in a way that is fairly easy to use. Free Pascal for instance has such a (3th party dynamic loadable) library (supporting several hosts such as Windows, Mac, Linux, etc.). That makes things (relatively) easy to use, so that for instance you can communicate amongst different programming/scripting languages, e.g. Free Pascal, Python, Go, C, etc.
Would love to test that with a proof of concept with Free Pascal but axrt looks to be so intertwined with gcc that it would require a lot of hoops (and loss of control) to get that working for FPC.
To to get back on point on the last messages of this thread on what axrt (imho) means is that such an implementation is an excellent example of what axrt could be used for: Test such a concept, then try to 'backport' that to pure Aros code so that Aros itself can be improved.
-
@magorium
I haven't looked in IPC or other forms that can be used, so I won't comment on this part.
You mentioned you asses Ax is intertwined with GCC - what do you mean by this? Can you given an example?
-
I am not sure if both groups are not different. You have current community and you have people outside, in best case with amiga memories. I think to make users of current community happy a amiga desktop is best even if it is not on same level as current linux desktops. To attract users from outside with some amiga background perhaps using a normal desktop with lots of configuration is best and adding amiga software or to be precise amiga-like linux software.
I think they are different and will require different approaches to attract. It's a complex problem where it is probably easier to attract people from current community, but the long term success will be measured by ability to attract people from outside.
-
yes indeed
I am (up to now) not a big linux user and only installed a free version now and then to look at but amiga has a number of nice advantages compared f.e. to windows. Simplicity is one and what I like are concepts like datatypes or xad and general installing drivers by copying in a directory. That should be transferred somehow to a new platform. And of course you need different approaches for current community and for potential users outside that never used amiga or only a long time ago. In that context wanderer is certainly potentially more interesting to current community. For the others using a "modern desktop" and configuring it is certainly the better approach. I personal would propose to concentrate first on the group that is easier to become interested, current community. To use another desktop later not sounds like that big problem to me. Also features like mounting adf or ISO are important for current community (diskimage device).
One thing I like about magellan (and miss at wanderer) are filetypes. You can define a filetype for any kind of file (I use ending for it like .png) and then attach icon, define context menu and define what happens if it is double clicked. Is that somehow possible?
-
@magorium
I haven't looked in IPC or other forms that can be used, so I won't comment on this part.
That is ok. Just saying that if someone out there would feel inclined to do so one could add a generic platform independent shared lib for IPC communication and add to axrt or simply use it from their individual AROS application(s).
You mentioned you asses Ax is intertwined with GCC - what do you mean by this? Can you given an example?
Sure thing :-)
Albeit that said, atm it is hypothetical based on what i've read in the readme/docs and source-code of axrt.
In case you are able to remember, it is similar to the situation you helped me with when linking against static aros libraries (in opposite to the normal way of doing things with FPC, namely opening/closing the shared libraries manually from disk and FPC assigning the library entry points in order to make API calls).
If i look at your distribution calculators example's makefile, i read:
# axrt.ld needs to be added to list of objects passed to linker for proper section ordering
# axrt.specs needs to be used for default libraries selection
That means i need to use a custom linker script. That should be doable for Free Pascal.
Then there is "the library selection", that links the libraries... ok, i have no idea right now but, let's assume i am able to do such a thing with FPC.
Then, i downloaded the deb file libaxrt-2.0-dev_40.2-1_amd64.deb and extracted the readme which reads, in chapter 4 (How do I build an application using runtime?):
4.3) Detailed - Linking
i.) Add startup.o and axrt.ld to objects being linked, example:
OBJ += /usr/lib/x86_64-linux-gnu/startup.o /usr/lib/x86_64-linux-gnu/axrt.ld
ii.) Select axrt.specs linker specs file, example:
LDFLAGS = -specs=/usr/lib/x86_64-linux-gnu/axrt.specs
iii.) Add additional linker libraries to resolve symbols, example:
-lmui -lamiga -lstdc.static -lstdc -lcodesets -lkeymap -lexpansion -lcommodities
-ldiskfont -lasl -lmuimaster -ldatatypes -lcybergraphics -lworkbench -licon
-lintuition -lgadtools -llayers -liffparse -lgraphics -llocale -ldos
-lutility -lexec -lm
So, i need to add startup.o (same as the static linking solution back then as mentioned at the beginning of this part of my reply).
Let's take a look at the startup file in your tree (https://github.com/deadw00d/AROS/blob/5f70d1d7564124c0370855e921a256651a078e5f/arch/all-runtime/axrt/startup/startup.c)
In the first part afaik, i see there the same symbols that needs to be defined/exported in my Pascal source, according to my wishes. Note, that when i do so
i have already given control over from FPC startup code to AROS startup code, meaning that if anything goes wrong FPC is not able to catch it, c does but that does not help me in particular :-)
Then, i go further down and i see some other (for me) terrifying startup code, this time on/for the Linux side :shivers:
I have no idea what this line of code does:
const char dl_loader[] __attribute__((section(".interp"))) = "/lib64/ld-linux-x86-64.so.2"
But assuming that it defines a variable for the linker to pick up, and the fact that it points to ld (and even more because it seems a static location) sounds horrifying to me.
Assuming that my code is still alive, then we see a function named __runtimestartup, that sets and runtime environment and kickstarts and seems to be invoked from routine _axrt_start, that routine seems to be resolved by the linker and automagically invoked ?
.. and finally we arrive at open64, which also seems to be invoked due to some linker magic ?
Every time the linker matches the symbols that get called automagically, i literally have lost control over to the c runtime library (whatever runtime library
that is, be it AROS or linux-host. referred by me as "gcc intertwined"). And that is assuming that everything linked as intended. If not then it is for me a needle in the proverbial haystack to find out what went wrong where exactly (and why).
That is, if i all interpreted the documentation and source-code correctly.
And then there is the question of the axrt.so file. I can load and open it, but is there anything else that needs to be done from my side of things ? e.g. usually one opens a library and calls a (specific) function in order to initialize things properly.
Does that answer the question that you've asked ?
-
@magorium
Thanks, that is enough explanation. I assume FPC can compile executables for Linux and can open ELF shared object (dlopen-like)? Is that they case?
If yes, would you be interested in working together to see if FPC can use AxRuntime under Linux? Many of the things that you mentioned are effect of dual-run nature (being started from Linux and from within AxRuntime). For first iteration for Pascal, things should be fairly easy IMHO and it would help me greatly to validate that AxRuntime can be used from another language.
-
I think message passing will be doable across separate address space processes. Message, unlike a memory location (a pointer passed around), is always "owned" by one of the processes, so you can think of copying the message back and forth between processes address spaces. Of course the sender could be modyfing a message after it was sent (and that's agaist the idea of messages) and this case won't work.
Pardon the intrusion but isn't that what IPC (on/via the host system) can be used for ?
You can then even share address space (virtual memory) between processes. Perhaps a bit more complicated than directly communicating between two applications but can be implemented in a way that is fairly easy to use. Free Pascal for instance has such a (3th party dynamic loadable) library (supporting several hosts such as Windows, Mac, Linux, etc.). That makes things (relatively) easy to use, so that for instance you can communicate amongst different programming/scripting languages, e.g. Free Pascal, Python, Go, C, etc.
IPC is a broad term: it's a general term to indicate that two or more processes can communicate.
How is it done is the tricky stuff, and strictly depends on how it's implemented.
Amiga o.s. uses message passing on a fully-shared address space, with all goods (superfast) and bad things (no security / no ownership / no solidity) that can happen.
I don't now the IPC implementation that you talked about, but I assume that it's a form of message passing, mapping those messages to the various processes' virtual memory spaces (not necessarily on the same virtual addresses), and probably some sort of marshalling (otherwise it's difficult to see how your mentioned languages can communicate, since they are very different).
However marshalling means also slow, especially if you want to pass complex structures. It also means that the existing Amiga applications require could requite notable changes to use this new mechanism.
-
It could remain a project for the developers :)
-
???
-
I use Aros every day Odyssey still allows me, I hope you also take into account that many users would like to use the native system :-\
-
I use Aros every day Odyssey still allows me, I hope you also take into account that many users would like to use the native system :-\
so you do not want to use a new browser and prefer the old one? I do no longer understand the world :-\
-
I would like to like at least I hope, use an updated browser for native aros :)
-
I didn't understand it seems strange that a desire to use Aros every day :-\
-
I didn't understand it seems strange that a desire to use Aros every day :-\
your preferred system will not vanish by that. But you have a new option with modern software and lots of drivers and additionally aros software. Because all software is linux you can use the linux components and linux software and aros software compiled for linux. To me that sounds like Aros 68k where you can mix amiga and aros components and software and do something new. Potentially this new platform could not only solve the typical problems of a niche system (no modern software, no drivers, no modern development software) it would open a new universe to aros. For me that sounds similar interesting than Aros 68k was when I started with it. So I really do not understand why you not want it. As I wrote... you can stay on aros pure of course, it is there and stays there.
All would be Linux.. You start a configured wanderer as desktop, there you have aros and linux software in it (aros software is linux software too), then you start firefox (linux) and Wookiechat (linux now too but a port from aros/amiga). That is my vision how it can be.
-
I don't care if Aros is a niche system also because it is not difficult to configure a computer with a few euros without problems and all that has been done so far excites me and I don't think I'm the only one to appreciate this, a solution with Linux I don't like it all here, it would no longer be the workbench for x86, perhaps and better if anything, if you feel the opinion of all users attending the forum
-
I don't care if Aros is a niche system also because it is not difficult to configure a computer with a few euros without problems and all that has been done so far excites me and I don't think I'm the only one to appreciate this, a solution with Linux I don't like it all here, it would no longer be the workbench for x86, perhaps and better if anything, if you feel the opinion of all users attending the forum
you are free to have your opinion and do not need to use or support it
but please do not continue this discussion here
-
you are not in the condition of deciding what I have to write my friend ;)
-
I would like us to look at a bigger picture. Everyone here has their own preferences.
Some are interested in native AROS as their main system as much as possible and here is where I develop ABIv0 i386. There is already a library of application for it and we have actively maintained distributions.
Some are interested in the classic Amigas and here is where I provide AROS 68k builds. Again, we have old and new 68k software and distributions.
There are some people showing interest in 64-bit space and here is where I develop ABIv11 x86_64 AROS. We probably have around 5 third party applications by now, but we also have a distribution here!
Lastly, there are people who use Linux on daily basis - the poll I did two years ago showed that 50% of people who replied had some form on contact with Linux on regular basis. Here is where AxRuntime comes into play to bring Amiga way of doing things to Linux.
The key thing to understand about those 4 projects however is that they share 99.99% of code base.
A stream of improvements coming from one of the directions will eventually benefit other variants. My last week's work on AxRuntime resulted in several commits that were done to shared code base and will be available in 68k and 64-bit first and ABIv0 after some time.
Please keep that in mind and support each other.
-
@deadwood
At the time I started with Aros 68k I was very lonely but the attraction was to combine aros 68k with amiga components and see where it gets. The same potential I see about this.
I will certainly try to do a distribution based on it. Who not likes it should not use it. Simply as that.
And yes we should work together and motivate each other and not say what we do not like.
-
ok deadwood :)
-
I believe that fragmentations lead to a slowdown in development, Linux for years has never exceeded 2% of users in the world, precisely because of its fractionations and the many distributions that have slowed progress.
Windows is the most used system in the world just because it has always focused on one system.
I don't care about Linux and host systems, my passion is Amiga and native AROS, if AROS were to run on Linux for me it would no longer be AROS, if I need particular applications I have Windows that guarantees quality, security and speed in doing things.
I abandoned OS4 for the same reason, because of the Linux software introduced in the system.
-
Ax it NOT about fragmentation. As deadwood clearly stated: "4 projects [...] share 99.99% of code base."
I'm also not interested at all on Linux (I use Windows), but the improvements of such "cross-collaboration" could be shared by all such AROS "flavors" (let's call them like that). And in future Ax might also be ported to Windows doing the same thing that was made for/on Linux.
So, I'm quite in favor of this project (and, in general, of all AROS-related/made/derived projects).
-
In my distribution certainly more than 90% are amiga components, even the desktop is different. The base is still aros. So what is it now?
The same could potentially be with Linux.You have aros desktop, you have lots of technologies in it that are from aros but the base is linux and there is software in it from linux. What is it now?
If it feels & looks like amiga people will be happy. I am against any ideologic discussions here. Who not like it will not use it. Simply as that
-
In my distribution certainly more than 90% are amiga components, even the desktop is different. The base is still aros. So what is it now?
The same could potentially be with Linux.You have aros desktop, you have lots of technologies in it that are from aros but the base is linux and there is software in it from linux. What is it now?
If it feels & looks like amiga people will be happy. I am against any ideologic discussions here. Who not like it will not use it. Simply as that
AROS must not look like AMiGA, it must be AROS and it must walk on its own feet.
In my AROS 68k I try to use as little as possible of Amiga software, only the indispensable and I would like it to become totally native AROS 68k in the future.
If I have to add AMiGA software on AROS 68k, I might as well use directly the new Amiga OS3.2, AfA One or Amikit !
-
As I already wrote to Salvo everybody is free to do what he likes
nobody has to do something or use something
that is true for myself too
-
But as Deadwood said he will not die anything with regards to ABIV0 and ABIV11 :)
-
In my distribution certainly more than 90% are amiga components, even the desktop is different. The base is still aros. So what is it now?
The same could potentially be with Linux.You have aros desktop, you have lots of technologies in it that are from aros but the base is linux and there is software in it from linux. What is it now?
If it feels & looks like amiga people will be happy. I am against any ideologic discussions here. Who not like it will not use it. Simply as that
AROS must not look like AMiGA, it must be AROS and it must walk on its own feet.
In my AROS 68k I try to use as little as possible of Amiga software, only the indispensable and I would like it to become totally native AROS 68k in the future.
If I have to add AMiGA software on AROS 68k, I might as well use directly the new Amiga OS3.2, AfA One or Amikit !
"must" "must" "must"...
You can do whatever you want, but don't talk about other people: everybody has a personal, legit opinion.
-
You can do whatever you want, but don't talk about other people: everybody has a personal, legit opinion.
I am not in the habit of talking about people, where did you read this ? I just expressed my thoughts.
---- Italiano -----
Non è mia abitudine parlare delle persone, dove hai letto questo ? io ho solo espresso il mio pensiero.
-
"must" -> AROS developers should do (only) what you said.
Anyway, deadwood already expressed his opinion / vision, and I agree.
-
@Everyone
As I said each of us has their own preference and I respect and support all of them. Please stay on topic of this thread and move the discussion on preferences to another thread or private messages.
-
"must" -> AROS developers should do (only) what you said.
Anyway, deadwood already expressed his opinion / vision, and I agree.
You misinterpreted my English, it was just my opinion "in my opinion" no it was directed to the developers !
--- Italiano ----
Hai interpretato male il mio inglese, era solo la mia opinione "a mio parere" no era diretto agli sviluppatori !
-
I assume FPC can compile executables for Linux and can open ELF shared object (dlopen-like)? Is that they case?
Your assumption there is correct :)
If yes, would you be interested in working together to see if FPC can use AxRuntime under Linux?
I am interested. Though having said that, i do anticipate that to be somewhat of a (undiscovered) journey which would also require a lot of tweaking/work from my end (so could take a while). As long as that is not a problem for you....
Many of the things that you mentioned are effect of dual-run nature (being started from Linux and from within AxRuntime). For first iteration for Pascal, things should be fairly easy IMHO and it would help me greatly to validate that AxRuntime can be used from another language.
It's exactly the dual-run nature that has me worried :-) In basics FPC supports only one type of target a time to compile for (ABI/OS wise).
For the rest it sounds good. I'll make some preparations and get back to you.
-
For the rest it sounds good. I'll make some preparations and get back to you.
Great! Please setup your Ax build directly from source: https://github.com/deadw00d/AROS/blob/alt-runtime/INSTALL.md. Once you are ready, please either start a thread here or email me directly :)
-
Sorry for the delayed reaction cdimauro. I simply lost track of your message.
IPC is a broad term: it's a general term to indicate that two or more processes can communicate.
How is it done is the tricky stuff, and strictly depends on how it's implemented.
It is for sure, but i hope my reply is able to make it a bit more practical.
Amiga o.s. uses message passing on a fully-shared address space, with all goods (superfast) and bad things (no security / no ownership / no solidity) that can happen.
For Amiga it is indeed fairly easy to accomplish because there is hardly any protection whatsoever. Even if you do follow the guidelines you can mess with things.
But, i was talking specifically in the case of axrt, but it does not have to end there.
As deadw00d wrote, each and every AROS program (when started with axrt) uses its own (linux) address space. As such the ipc requires to follow the linux guideline with regards to IPC.
I don't now the IPC implementation that you talked about, but I assume that it's a form of message passing, mapping those messages to the various processes' virtual memory spaces (not necessarily on the same virtual addresses), and probably some sort of marshalling (otherwise it's difficult to see how your mentioned languages can communicate, since they are very different).
Let's make it a bit more practical then. It is just a (simple) example, but please have a look here (https://wiki.lazarus.freepascal.org/SimpleIPC_Library). If i remembered correctly then you did not seem shy of a bit of Pascal code, so please do follow the github link and take a look at the code.
In the end it is just a generic library and simply offers a generic API that can be used for every platform/programming language. You can make such thing as complicated and/or simple as one wish it to be.
However marshalling means also slow, especially if you want to pass complex structures. It also means that the existing Amiga applications require could requite notable changes to use this new mechanism.
For sure it is/can be. But how do modern programs use IPC ? Take note that there are several programs that even do this kind of things using networked connections (either local, lan or wan) and that there are several protocols each and everyone with their own individual pros and cons.
In the specific instance that i've made my remark i was more thinking along the line of being compliant (from a outside point of view) rather then suggesting each and every program that wants IPC should make use of it. As you pointed out perfectly, Amiga OS has it's own proofed and tested implementation(s) that for sure will have more pros than cons.
The only other way i am able to see a implementation that might be a better solution (but would require more work) is a complete implemented VM for the axrt, so that the vm can decide what each individual axrt process is allowed/disallowed to do. So there would have to be provisions (read extra layer inside the vm) for that.
But perhaps you have another and/or better idea ?
-
Great! Please setup your Ax build directly from source: https://github.com/deadw00d/AROS/blob/alt-runtime/INSTALL.md (https://github.com/deadw00d/AROS/blob/alt-runtime/INSTALL.md). Once you are ready, please either start a thread here or email me directly :)
Sorry for the inconvenience but i seem to have stumbled upon a bump in the road already ???
I've followed the instructions from github in order to compile axrt and checked with wanderer, which outputted:
<<INFO>>: AxRT 41.1
<<INFO>>: Using absolute paths.
<<INFO>>: AXRT_ROOT environment variable set
<<INFO>>: RUNTIME_ROOT: /home/magorium/bin/AXRT/
<<INFO>>: AXRTSYS : ROOT:home/magorium/bin/AXRT/
<<INFO>>: USERSYS : ROOT:home/magorium/.axrt/
Illegal instruction
However, I _did_ do some modification for my setup, that differs from the github instructions.
For the configure setup i copied the files/dirs as mentioned to the .axrt directory in my homedir (*)
Then i copied all files/dirs from myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/AROS/* to ~/bin/AXRT/* in order to accommodate my preferred setup. (*) and exported the AXRT_ROOT variable accordingly.
So the question would then become: is the illegal instruction due to my custom setup or .... ?
TIA
-
Exporting of AXRT_ROOT seems fine. I think there are problems with content of ~/.axrt directory.
Do the following
$ cd myrepo/alt-runtimelinux-x86_64-d/
$ make runtime-package-deb-libaxrt
The navigate to: myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/gen/boot/libaxrt-4.0/usr/lib/x86_64-linux-gnu/axrt/4.0. The directories you see there should be copied to ~/bin/AXRT. Delete ~/.axrt. One you start Wanderer, runtime will detect you are missing USERSYS and should copy it automatically to ~/.axrt.
-
@deadw00d:
Thx for the quick response.
Instructions executed, resulting in exactly the same error when starting Wanderer.
The .axrt directory is indeed 'created' automagically (with contents).
I copied the directories as instructed but was not sure if i needed to clear the destination directory from its existing dirs/files first, so i overwrite all existing dirs/files. Just mentioning it in case it matters.
The error as presented, is that an error as generated by the axrt runtime environment or an actual cpu illegal instruction ?
TIA
-
Actually how I work most of the time, I point AXRT_ROOT to myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/AROS/ so I don't need to copy anything.
Let's find out what is the problem. Point the AXRT_ROOT as I mentioned above for now and run gdb:
$ gdb ./Wanderer
-
@deadw00d:
gdb ./Wanderer results in:
run
Starting program: /home/magorium/bin/AXRT/System/Wanderer/Wanderer
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
<<INFO>>: AxRT 41.1
<<INFO>>: Using absolute paths.
<<INFO>>: AXRT_ROOT environment variable set
<<INFO>>: RUNTIME_ROOT: /home/magorium/bin/AXRT/
<<INFO>>: AXRTSYS : ROOT:home/magorium/bin/AXRT/
<<INFO>>: USERSYS : ROOT:home/magorium/.axrt/
[New Thread 0x7ffff7bc2700 (LWP 18829)]
[New Thread 0x7ffff6b3e700 (LWP 18830)]
[New Thread 0x7ffff633d700 (LWP 18831)]
Thread 2 "Exec bootstrap" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7ffff7bc2700 (LWP 18829)]
0x00007ffff7fbf2aa in _mm_set_epi8 (__q00=0 '\000', __q01=0 '\000', __q02=0 '\000', __q03=0 '\000', __q04=0 '\000', __q05=0 '\000',
__q06=0 '\000', __q07=0 '\000', __q08=0 '\000', __q09=0 '\000', __q10=0 '\000', __q11=0 '\000', __q12=0 '\000', __q13=0 '\000',
__q14=0 '\000', __q15=0 '\000') at /usr/lib/gcc/x86_64-linux-gnu/8/include/emmintrin.h:621
621 return __extension__ (__m128i)(__v16qi){
and for good measures lscpu:
magorium@sparky:~/bin/AXRT/System/Wanderer$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 36 bits physical, 48 bits virtual
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 37
Model name: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz
Stepping: 5
CPU MHz: 1723.249
BogoMIPS: 4818.55
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 3072K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid dtherm arat flush_l1d
I am not too familar with using gdb so any instructions you are able to provide that is able to help you better/more is appreciated.
edit: the only hit i was able to get on that illegal instruction was found here (https://stackoverflow.com/questions/56745957/illegal-instruction-with-mm-cmpeq-epi8-mask), which mixed responses/solutions. The only wonder i have is how on earth is the compiler able to compile sources and produce code that isn't supported by the cpu it is compiled on. Another gcc murder mystery for me ;D
-
I think it has to do with stack being misaligned, which is not good. You are compiling this under Ubuntu 20.04 right?
Once you get a crash and drop to gdb command line, please do
$ bt
to list backtrace and paste it here.
-
boards immunify issue, can't preview. Will edit this post later.
I think it has to do with stack being misaligned, which is not good.
Ok, so something else than i expected....
You are compiling this under Ubuntu 20.04 right?
No, not exactly ubuntu 20.04 :)
https://sparkylinux.org/tag/nibiru/ (https://sparkylinux.org/tag/nibiru/)
There is a next point release of Sparky 5.15 “Nibiru” of the stable line ready to go. This release is based on Debian stable 10 “Buster”.
lsb_release -a
No LSB modules are available.
Distributor ID: Sparky
Description: SparkyLinux 5.16 (Nibiru)
Release: 5.16
Codename: sid
cat /etc/os-release
PRETTY_NAME="SparkyLinux 5.16 (Nibiru)"
NAME="SparkyLinux"
VERSION_ID="5.16"
VERSION="5.16 (Nibiru)"
ID=sparky
ID_LIKE=debian
HOME_URL="https://sparkylinux.org/"
SUPPORT_URL="https://forum.sparkylinux.org/"
BUG_REPORT_URL="https://sourceforge.net/p/sparkylinux/tickets"
Hopefully that is enough with regards to the identification.
The board refuses to post/accept my backtrace......
https://pastebin.com/2GKXe2up
-
bump. (and sorry for the boards behaviour that screw things up).
-
magorium is a pleasure to read you, too bad I do not understand anything about programming!
-
Ok, that was unexpected. :/ Its most likely a stack alignment issue, but why it triggers on your setup it a bit of mystery to me. I need to think this through. :/
One workaround might be to go to AROS/arch/x86_64-all, delete utility directory there and rebuild.
-
Sorry for the delayed reaction cdimauro. I simply lost track of your message.
np. I also reply when I can: we all have a real life. ;)
As deadw00d wrote, each and every AROS program (when started with axrt) uses its own (linux) address space. As such the ipc requires to follow the linux guideline with regards to IPC.
However Linux has several IPC mechanisms. AFAIR there are 6 that can be used (depending on the specific needs).
I don't now the IPC implementation that you talked about, but I assume that it's a form of message passing, mapping those messages to the various processes' virtual memory spaces (not necessarily on the same virtual addresses), and probably some sort of marshalling (otherwise it's difficult to see how your mentioned languages can communicate, since they are very different).
Let's make it a bit more practical then. It is just a (simple) example, but please have a look here (https://wiki.lazarus.freepascal.org/SimpleIPC_Library (https://wiki.lazarus.freepascal.org/SimpleIPC_Library)). If i remembered correctly then you did not seem shy of a bit of Pascal code, so please do follow the github link and take a look at the code.
Thanks, and you're right: before Python it was Pascal/Delphi my beloved programming language.
In the end it is just a generic library and simply offers a generic API that can be used for every platform/programming language. You can make such thing as complicated and/or simple as one wish it to be.
Basically it does what I was suspecting. In fact, it gives a basic layer for establishing a communication (client / server) with a few API for sending some common data types (int32, string), but nothing else.
In fact, for more complex data types, you need to choose some marshaling. They suggest Google Protocol Buffer:
"More advanced IPC: google protocol buffers in combination with simpleipc means you can send standardized data using the well known google protocol buffer mechanism (GPB). The GPB does not handle IPC for you, so when you need IPC mechanism to actually send and receive the google protocol buffer, why not use SimpleIPC?"
The good thing of that library is that it's simple: it exposes some basic APIs for establishing a communication between two processes and sending/receiving data.
The bad thing is that they tried to offer some APIs for exchanging data, but they cover only a bunch of common data types, and use to convert to string everyting, unfortunately, which is quite inefficient.
What's even worse, is that they sell this library as it makes easier to exchange messages using any datatype. As a pythonist, I can say that to achieve it you need a super-complex marshaling protocol that it's very very difficult to implement on languages other than Python.
I give you a basic example: integers. In Python integers have "unlimited" size: you can store very big numbers which are only limited by your memory. Whilst it's very easy for Python to marshal them to some format (classic conversion to string, for example, which is not that efficient but... effective: easy to understand, at least), how other languages will cope with that?
And this is a very basic example. Python offers a broad range of datatypes, both as built-in and in its standard library, and many of them can be freely combined. You can imagine how complex a data can become in Python. And how super difficult would be to find a way to marshal it AND be handled by different programming languages.
So, in short: the library is good for very basic message passing, but fails (and I'm polite here) on its claimed goals of being of general use.
However marshalling means also slow, especially if you want to pass complex structures. It also means that the existing Amiga applications require could requite notable changes to use this new mechanism.
For sure it is/can be. But how do modern programs use IPC ? Take note that there are several programs that even do this kind of things using networked connections (either local, lan or wan) and that there are several protocols each and everyone with their own individual pros and cons.
Indeed. And that's why the library is failing: it doesn't even give a protocol generic-enough for the more common needs. You have either to reinvent the wheel (new protocol) or use another protocol for marshaling the data.
Problem NOT solved...
In the specific instance that i've made my remark i was more thinking along the line of being compliant (from a outside point of view) rather then suggesting each and every program that wants IPC should make use of it.
Unfortunately it's not easy to use the library as it is: too much limited, and requires extra effort and/or external libraries for mashalling more complex data.
As you pointed out perfectly, Amiga OS has it's own proofed and tested implementation(s) that for sure will have more pros than cons.
The only other way i am able to see a implementation that might be a better solution (but would require more work) is a complete implemented VM for the axrt, so that the vm can decide what each individual axrt process is allowed/disallowed to do. So there would have to be provisions (read extra layer inside the vm) for that.
Yes. But AxRT then needs to know which applications can communicate in some way (Amiga o.s., SimpleIPC...)
But perhaps you have another and/or better idea ?
As a developer, I prefer to have a more general solution which works out-of-the-box for the most common cases.
SimpleIPC isn't good for the above reasons. It would have been better for this library to offer only a single, basic, API for sending and receiving a sequence of bytes.
So, leaving the data types marshalling to something else (GPB, JSON, YAML, XML, ...).
But offering the marshalling as already built-in.
-
Ok, that was unexpected. :/ Its most likely a stack alignment issue, but why it triggers on your setup it a bit of mystery to me. I need to think this through. :/
One workaround might be to go to AROS/arch/x86_64-all, delete utility directory there and rebuild.
Ah... ic. That seem to work as intended (*) :)
The only 'issue' i seem to have right now is that the left mouse button isn't responsive. Right mouse button shows the Wanderer menubar for me without a problem though.
(*) that was after i had a bit of a brain-blockage in that i did not grasped why it still crashed after launching Wanderer on a remote shell ... uhm :-[
Bit of a strange crash message btw:
Thread 2 "Exec bootstrap" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7ffff7bc2700 (LWP 17397)]
Exec_69_CloseLibrary (library=0x7ffff0026850) at /media/ramdisk/myrepo/AROS/rom/exec/./closelibrary.c:66
66 if(library!=NULL)
Do you prefer an official github issue report on my initial issue ?
@AMIGASYSTEM: Thanks, good to see you around here as well :)
-
@magorium
Yes, please create but report. What window manager are you using on your Linux? When do you get this crash with CloseLibrary?
-
Yes, please create but report.
Done :)
What window manager are you using on your Linux?
DE: Xfce
WM: Xfwm4
When do you get this crash with CloseLibrary?
When i launch Wanderer with a remote ssh terminal session (no x-windows setup for remote session). Basically a non-issue, since afaik axrt always requires x-windows.
If there is anything else i can do to be able to help with this issue (with regards to my initial bug report about crashed Wanderer) then please let me know. Also feel free to let me know in case this issue isn't worth the/your time (as it might be distro/setup related). Heads up though, as i won't be running Ubuntu any time soon.
edit: removed unsolicited font tags
-
@magorium
Thank, I believe I had a report of problems under Xfce so I will look at it eventually. The Wanderer crash through remote session is ok - you indeed need X running. I will be looking further into SetMem_SSE crash.
In the meantime do you want continue looking at using AxRuntime from Pascal? If yes, I will start a separate thread here.
-
@deadwood: thank you for the clarification(s).
In the meantime do you want continue looking at using AxRuntime from Pascal? If yes, I will start a separate thread here.
Yes, that is ok.
I think i have enough work to do in order to get something going/working for my current FPC setup. So the sooner the better, i guess ? :) TIA
-
I wanted to share with you a teaser of an experiment that I'm working on:
(https://axrt.org/media/axrt-shell-aros-executable.jpg)
What you see there is Info command execute twice from AROS-Shell running under Linux. The first Info command is a Ax-recompiled Info that you can find in the AROS-Shell package I shared last time. The interesting part is the second Info command. As the name suggests, it is a NATIVE AROS 64-bit program running under Linux :)
It may be that AxRuntime will allow running native AROS programs under Linux same way as Wine allows running native Windows programs under Linux. In the coming days I will see how far this experiment can be taken.
-
nice :)
now the same somewhen with linux native programs and I have no wishes left ;)
-
@deadw00d:
I have no idea what happened, because your instructions to fix my problem, indeed fixed my issue when testing. I was able to run Wanderer.
But i am currently faced with something quite similar when i followed your build instructions checking out the updated tree.
Output from terminal when starting Wanderer
./Wanderer
<<INFO>>: AxRT 41.1
<<INFO>>: Using absolute paths.
<<INFO>>: AXRT_ROOT environment variable set
<<INFO>>: RUNTIME_ROOT: /home/magorium/bin/AXRT_411/
<<INFO>>: AXRTSYS : ROOT:home/magorium/bin/AXRT_411/
<<INFO>>: USERSYS : ROOT:home/magorium/.axrt/
Illegal instruction
Output from gdb:
gdb ./Wanderer
(gdb) run
Starting program: /home/magorium/bin/AXRT_411/System/Wanderer/Wanderer
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
<<INFO>>: AxRT 41.1
<<INFO>>: Using absolute paths.
<<INFO>>: AXRT_ROOT environment variable set
<<INFO>>: RUNTIME_ROOT: /home/magorium/bin/AXRT_411/
<<INFO>>: AXRTSYS : ROOT:home/magorium/bin/AXRT_411/
<<INFO>>: USERSYS : ROOT:home/magorium/.axrt/
[New Thread 0x7ffff7bc2700 (LWP 16258)]
[New Thread 0x7ffff6b3e700 (LWP 16259)]
[New Thread 0x7ffff633d700 (LWP 16260)]
Thread 2 "Exec bootstrap" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7ffff7bc2700 (LWP 16258)]
0x00007ffff7fbf2aa in _mm_set_epi8 (__q00=0 '\000', __q01=0 '\000', __q02=0 '\000', __q03=0 '\000',
__q04=0 '\000', __q05=0 '\000', __q06=0 '\000', __q07=0 '\000', __q08=0 '\000', __q09=0 '\000',
__q10=0 '\000', __q11=0 '\000', __q12=0 '\000', __q13=0 '\000', __q14=0 '\000', __q15=0 '\000')
at /usr/lib/gcc/x86_64-linux-gnu/8/include/emmintrin.h:621
621 return __extension__ (__m128i)(__v16qi){
(gdb) Quit
And again, the backtrace refuses to post, so i added the whole shazam as mentioned above, including backtrace, and disasm as attachment.
Should i re-open the old issue, create a new one or ... ?
edit: The backtrace seem exactly similar ?
edit2: ah, ic. You didn't push the change to alt-runtime (yet) ?
-
That's correct. Fix will be posted to alt-runtime branch in near future. For now you can cherry pick the fix from master or just use the previous workaround.
-
Last time I shared with you something simple, like the Info command from AROS x86_64 ABIv11 being run under AxRuntime. Now it's time for something more advanced! And programmed not in C but in Pascal!
MCAmiga - now running nativelly under Linux ;D
(https://axrt.org/media/axrt-mcamiga-aros-x86_64-v11.jpg)
There are still some 64-bit issues but I'll works with @magorium to iron them out
-
cool thing :)
It will be exciting to see where the whole project will go
-
cool thing :)
It will be exciting to see where the whole project will go
Imagine someone compiling Janue-UEA for 64-bit AROS and having Amiga application running as "native" under Linux ;)
-
one question.... I would like to do another distribution based on wanderer (68k) on latest builds. Is the official nightly the most recent version?
-
There are no official builds (as it tested releases). Here are jenkins builds: https://build.axrt.org/download/builds/AROS-ABIv11/
-
There are no official builds (as it tested releases). Here are jenkins builds: https://build.axrt.org/download/builds/AROS-ABIv11/
thanx
-
Last time I shared with you something simple, like the Info command from AROS x86_64 ABIv11 being run under AxRuntime. Now it's time for something more advanced! And programmed not in C but in Pascal!
MCAmiga - now running nativelly under Linux ;D
(https://axrt.org/media/axrt-mcamiga-aros-x86_64-v11.jpg)
There are still some 64-bit issues but I'll works with @magorium to iron them out
What's the difference with AROS hosted, then?
-
What's the difference with AROS hosted, then?
Each program is an isolated process.
Each Intution window becomes a separate X window.
-
That's "enough" (!), thanks. 8)
I hope to see it working on Windows, in future (albeit it'll be a late future).
-
I hope to see it working on Windows, in future (albeit it'll be a late future).
This would certainly be more interesting since we all have Windows at home !
-
@cdimauro, @AMIGASYSTEM
I think that is already possible. I saw somethink called "Linux subsystem for Windows" which allows running Linux X11 applications on Windows. Since AxRuntime is just one such application it should be possible to "run" it under Windows. I don't use Windows on daily basis, but if you do and want to experiment, I'd be interested in results.
-
@Deadwood
Another question... I am just fiddling around a little with Wanderer. It is limited of course as known but there is scalos on contrib. Would it be possible to port that to Linux too. It is more advanced than Wanderer and would be a good option in my view.
-
@cdimauro, @AMIGASYSTEM
I think that is already possible. I saw somethink called "Linux subsystem for Windows" which allows running Linux X11 applications on Windows. Since AxRuntime is just one such application it should be possible to "run" it under Windows. I don't use Windows on daily basis, but if you do and want to experiment, I'd be interested in results.
Yes, there's WSL2. I use it frequently, but only from command line. I've to try how it works with X11/GUI applications.
Maybe someone has already experience with it, and can already try and share its experience.
-
@Deadwood
Another question... I am just fiddling around a little with Wanderer. It is limited of course as known but there is scalos on contrib. Would it be possible to port that to Linux too. It is more advanced than Wanderer and would be a good option in my view.
Yes it would, but not this time around. As said in another thread I'm wrapping up this release and moving onto ABIv0 work for some time. I'll keep that in mind for next release.
-
@cdimauro, @AMIGASYSTEM
I think that is already possible. I saw somethink called "Linux subsystem for Windows" which allows running Linux X11 applications on Windows. Since AxRuntime is just one such application it should be possible to "run" it under Windows. I don't use Windows on daily basis, but if you do and want to experiment, I'd be interested in results.
I'll see to configure a PC that has the right setup, I'm not Linux expert, I'll follow THIS (https://ciksiti.com/it/chapters/1518-use-linux-graphical-softwares-on-windows-via-x11-forwarding) guide to install "VcXsrv" I hope it's fit for purpose.
-
@cdimauro, @AMIGASYSTEM
Looking forward to results of your tests :)
-
Yup. I'm offshore for 3 weeks and I haven't my setup here, but I'll try once I'm back home. Anyway, following the development. ;)
-
On my Windows 10 laptop I installed "VcXsrv Windows X Server", "BvSshServer" and "BvSshClient" successfully and everything works perfectly see screenshot.
With XLancer I can start Linux applications included in the package but I don't know how to start other external Linux applications.
It seems that to have the Windows Subsystem for Linux (WSL) on Win10 you need to have a Bulid 14393 or higher, unfortunately I have an older Buld and therefore I can not install / enable WSL, any idea to solve this?
-
It seems that to have the Windows Subsystem for Linux (WSL) on Win10 you need to have a Bulid 14393 or higher, unfortunately I have an older Buld and therefore I can not install / enable WSL, any idea to solve this?
disclaimer: not a windows user, no experience with the process. I just post what i could find.
This (https://docs.microsoft.com/en-us/windows/wsl/install) documentation talks about doing it the easy way.
That requires an even higher build number but, does show a link (see here (https://docs.microsoft.com/en-us/windows/wsl/install-manual)) on how to how to install WSL manually (on a windows with a lower build number).
Note that in the first linked document there are also instructions on how to check your build and how to update your windows system.
(Funny that you asked how to update your windows, as the constant windows background updates was reason for me to quit windows altogether).
fwiw:
I am confused on how MS advertises the requirements, as they seem to differ on every other document. One page tells you that you cannot update to wsl2 on windows 10 (only windows 11) while another document writes that it is no problem. There are even pages that claim that you can't run x-server on windows 10 *period* and that you need to update to windows 11.
Would be interesting to know where the truth ends up :P
-
magorium I have read and followed that tutorial and many others, unfortunately my Windows 10 Enterprise which I find great (boots in 3 seconds, see link) is outdated and doesn't include the necessary software, also my Windows 10 is 32Bit, WSL requires a 64Bit Win10 system.
https://drive.google.com/file/d/1TaRVsm2B8KmRfb8J13_PJKX4Pz-9HV7C/view
-
@AMIGASYSTEM: it should be possible to upgrade your Windows 10 to the latest version, which supports WSL2 and GUI applications.
WSL(1) is really too outdated and with a lot of issues: it's usable only from command line.
-
Builds lower than version 18362 do not support WSL2, I have a Build 14393
https://docs.microsoft.com/it-it/windows/wsl/install-manual
-
That's what I meant before: upgrade your Windows to a later version (the last one, ideally), and you should be able to install WSL2.
-
Hi All,
A new version of AxRuntime is now available! AxRuntime lets developers compile their Amiga API-based applications as Linux programs.
The highlights of release v41.2 are:
1) AROS-Shell, an AmigaDOS-compatible Shell, is now available for you as a native Linux program. You can write DOS scripts and use shell commands to interact with Linux filesystem.
2) AxRuntime becomes a bridge between AROS x86_64 and Linux by allowing running native AROS programs as standalone Linux programs. In this function AxRuntime is similar to Wine. Wine allows running Windows programs on Linux, AxRuntime allows running AROS programs on Linux.
This release comes with 4 applications: AROS-Shell, MPlayer, WookieChat and Final Writer 7 (demo). Additionally AROS x86_64 applications like MUIbase can also be used!
A full change log of this release is available here: https://axrt.org/index.php?tab=releasenotes#AXRT412. To download AxRuntime packages and applications go to https://axrt.org/index.php?tab=download.
If you are interested in using AxRuntime for your projects or even contributing to AxRuntime, please contact me via email or PM on one of the listed sites: https://axrt.org/index.php?tab=community
Below you can see a selection Amiga programs running on a linux desktop. For more screen shots, visit https://axrt.org/index.php?tab=gallery
(https://axrt.org/media/axrt-desktop-20220404.jpg)
-
thank you deadwood :)
-
I've finally managed to run FinalWriter using the AxRuntime on WSL2 (see attached screenshot).
It took sometime because I've messed-up my WSL2 configuration, and trying to find the root cause and fix it was a nightmare. Anyway, for Windows uses that want to use GUI Linux applications on WSL2, please just follow the below guidelines and do NOT try something else!
Run Linux GUI apps on the Windows Subsystem for Linux (preview) (https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps)
Running WSL GUI Apps on Windows 10 (https://techcommunity.microsoft.com/t5/windows-dev-appconsult/running-wsl-gui-apps-on-windows-10/ba-p/1493242)
However and I don't know if it's FinalWriter and/or AxRuntime, but it's quite unstable: it easily segfaults. Likely it's caused by my multimonitor system (I've two completely different monitors). In fact, the application opens on the left screen, but if I right-click with the mouse then the menu appears on the right one, and if I try to reach it... it segfauls:
[FWMouse] ms_setmouse(): IDCMP_MOUSEMOVE above correct word / no text!
[FinalWriter] ctm_DoEvent()
XError 3 (Major=15, Minor=0) task = Intuition menu handler
BadWindow (invalid Window parameter)
Segmentation fault (core dumped)But at least I was able to execute something. :P
-
@cdimauro
Thanks a lot for doing these experiments! Greatly appreciated. :)
I think the most possible answer to stability issues you are having is "both". AxRuntime was not tested with dual screen setup and its possible I made some hardcodes there that assume single monitor. On the other hand, FinalWriter is still in beta and probably does have some issues still.
Could you make another test? Use MPlayer or WookieChat instead of FinalWriter as well we disconnect your second monitor?
-
Sure. Unfortunately there are the same stability issues, even using only a monitor. It happened with all applications: FinalWriter (checked again), MPlayer, and WookieChat.
Full logs for MPlayer:
cesare@Conan:~/MPlayer$ ./gmplayer
<<INFO>>: AxRT 41.2
<<INFO>>: Using absolute paths.
<<INFO>>: RUNTIME_ROOT: /usr/lib/x86_64-linux-gnu/axrt/4.0/
<<INFO>>: AXRTSYS : ROOT:usr/lib/x86_64-linux-gnu/axrt/4.0/
<<INFO>>: USERSYS : ROOT:home/cesare/.axrt/
Xlib: extension "XFree86-VidModeExtension" missing on display "192.168.2.126:0".
<<INFO>>: CURRENT_DIR : ROOT:home/cesare/MPlayer/
<<INFO>>: PROGRAM DIR : ROOT:home/cesare/MPlayer/
<<INFO>>: PROGRAM NAME: gmplayer
AxRuntime does not support AllocAbs(nommu_AllocAbs)
MPlayer UNKNOWN-9 (C) 2000-2012 MPlayer Team
VO: [cgx_wpa] Preinit.
File not found: 'PROGDIR:conf/lastplaylist.pls'
Failed to open PROGDIR:conf/lastplaylist.pls.
Error while opening playlist file PROGDIR:conf/lastplaylist.pls: No such file or directory
XError 3 (Major=15, Minor=0) task = Intuition menu handler
BadWindow (invalid Window parameter)
MPlayer interrupted by signal 11 in module: unknown
- MPlayer crashed by bad usage of CPU/FPU/RAM.
Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
gcc version. If you think it's MPlayer's fault, please read
DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
won't help unless you provide this information when reporting a possible bug.
and for WookieChat:
cesare@Conan:~/WookieChat$ ./WookieChat
<<INFO>>: AxRT 41.2
<<INFO>>: Using absolute paths.
<<INFO>>: RUNTIME_ROOT: /usr/lib/x86_64-linux-gnu/axrt/4.0/
<<INFO>>: AXRTSYS : ROOT:usr/lib/x86_64-linux-gnu/axrt/4.0/
<<INFO>>: USERSYS : ROOT:home/cesare/.axrt/
Xlib: extension "XFree86-VidModeExtension" missing on display "192.168.2.126:0".
<<INFO>>: CURRENT_DIR : ROOT:home/cesare/WookieChat/
<<INFO>>: PROGRAM DIR : ROOT:home/cesare/WookieChat/
<<INFO>>: PROGRAM NAME: WookieChat
AxRuntime does not support AllocAbs(nommu_AllocAbs)
******************************************************************************
wookiechat.c (55) main() - WookieChat - Transmission begins...
XError 3 (Major=15, Minor=0) task = Intuition menu handler
BadWindow (invalid Window parameter)
Segmentation fault (core dumped)
Applications crashes as usual: when right-clicking with the mouse, and trying to use the menu.
AROS-Shell works, but it has no menu, so it doesn't crash.
-
The segfaults can be easily reproduced:
1) right-click with the mouse;
2) an extra horizontal bar with the menu appears;
3) move outside of the AROS application window frame.
-
The segfaults can be easily reproduced:
1) right-click with the mouse;
2) an extra horizontal bar with the menu appears;
3) move outside of the AROS application window frame.
Thanks for coming up with sequence that casuses the crash. I created a bug report here: https://github.com/deadw00d/AROS/issues/67
Does the crash happen only if you move the pointer outside of AROS application? There was a bug with right-click crash earlier, but it happened immediatelly after right click.
Are you able to run the program through GDB and get me a trace of crash?
-
No, the crashes happened only when moving the mouse pointer outside of the AROS "window area". In fact, I was also able to select some menu entry when the menu was reachable within the window area.
OK, next time I'll try to use gdb.
-
@Deadwood
the problem with Scalos prefs still exist. Fortunately i found a workaround by doing it with Scalos prefs in 3.X and then copying it over. These pref files work in both Aros 68k and X86. Perhaps it is solved later. Scalos is nice, in some areas not as good as Magellan but perhaps more like amiga user expect.
-
Are you able to run the program through GDB and get me a trace of crash?
Just added a comment on your GitHub issue, with log and screenshot.
The trace is very limited, but I hope that it's useful.
Let me know if you need more or some different tests. ;)
-
Thanks, let's continue investigating in the bug ticket on github.
-
Run Linux GUI apps on the Windows Subsystem for Linux (preview) (https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps)
Running WSL GUI Apps on Windows 10 (https://techcommunity.microsoft.com/t5/windows-dev-appconsult/running-wsl-gui-apps-on-windows-10/ba-p/1493242)
Hi, I'm writing up documentation on using AxRuntime on Windows and I have a question about the links your provided. The first link is Microsoft one and it sounds very simple to get WSL2 running. However the second link seems to be about WSL (the first one) and using a third party application to gets things working. I assume these are redundant, that is if you have recent enough version of Windows 10 you should use the first guide, if not use the second one. Which approach (WSL2 or WSL + 3rd party application) are you using for testing AxRuntime under Windows 10?
-
@deadwood:
Please note that the first link is not intended for use with windows 10:
You will need to be on Windows 11 Build 22000 or later to access this feature. You can join the Windows Insiders Program to get the latest preview builds.
That is why I wrote earlier that m$ (as usual) is messing things up. From their own technical documents: You can and can't use x-server with WSL1, you need windows 10 build blah in order to be able to install WSL2, oh, it is actually windows 11 on another document etc. etc.
The only thing for sure is that cdimauro knows the requirements and what steps he took to get things running for him. Unfortunately (actually yeah!) no windows for me anymore so can't help there, sorry.
-
Thanks, I didn't notice that. Let's wait for cdimauro response.
-
Run Linux GUI apps on the Windows Subsystem for Linux (preview) (https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps)
Running WSL GUI Apps on Windows 10 (https://techcommunity.microsoft.com/t5/windows-dev-appconsult/running-wsl-gui-apps-on-windows-10/ba-p/1493242)
Hi, I'm writing up documentation on using AxRuntime on Windows and I have a question about the links your provided. The first link is Microsoft one and it sounds very simple to get WSL2 running. However the second link seems to be about WSL (the first one) and using a third party application to gets things working. I assume these are redundant, that is if you have recent enough version of Windows 10 you should use the first guide, if not use the second one. Which approach (WSL2 or WSL + 3rd party application) are you using for testing AxRuntime under Windows 10?
The problem that I had is that just following the first link it didn't worked out. I wasn't able to launch any GUI application from WSL2.
Only when I've installed VcXsrv I was able to do it (and providing the IP of my Windows machine on the DISPLAY envar).
Maybe my configuration is still messed-up (I haven't reinstalled from scratch my WSL2 Ubuntu image). Someone else with an "untouched" Windows 11 machine could just try the first link and see if everything works.
@deadwood:
Please note that the first link is not intended for use with windows 10:
You will need to be on Windows 11 Build 22000 or later to access this feature. You can join the Windows Insiders Program to get the latest preview builds.
That is why I wrote earlier that m$ (as usual) is messing things up. From their own technical documents: You can and can't use x-server with WSL1, you need windows 10 build blah in order to be able to install WSL2, oh, it is actually windows 11 on another document etc. etc.
There's nothing messed-up, besides my current WSL2 machine maybe. ;)
It was clear and documented that WSL1 was a command-line only tool.
As it was clear that GUI support for WSL2 (not 1) was officially coming with Windows 11 (which I've).
P.S. If Microsoft products are messy, then you have not enough experience with Linux et all. ;D
I was able to have working Wi-Fi on my AMD C50 subnotebook only after installing one of the many Ubuntu derived distros: all previous ones (also not Ubuntu-based) failed miserable. It was my last resort and fortunately it worked out, otherwise the subnotebook was stored taking the dust now...
-
I'm not in for a full debate on this topic, but just click the first link (read that windows 11 is prerequisite), then read and click the first link that says you need windows 10 build blah.
It was clear and documented that WSL1 was a command-line only tool.
Hmz, I wonder why ever VcXsrc was being written.... and what it can be used for ;)
As it was clear that GUI support for WSL2 (not 1) was officially coming with Windows 11 (which I've).
Officially perhaps yes. But it was already possible with Windows 10 (and with WSL 1, using x-forwarding).
You _can_ take that with a grain of salt because I do not have any hands-on experience with WSL (1 or 2) but a gentle search on quack quack fly seem to do wonders (and actually makes sense as well).
P.S. If Microsoft products are messy, then you have not enough experience with Linux et all. ;D
True :P
In the end, deadwood is in search of a reliable source so that he can quote from that (or base his documentation on it). Your experience helps (thank you for sharing) but I am assuming that it is common knowledge that x works for WSL2 on win 11. I am also assuming that it is the niche (WSL1/win10 or perhaps even wsl2/win10) that is currently of more interest.
-
I'm not in for a full debate on this topic,
Not needed: let's just clarify the situation, for the benefit of the other users. :)
but just click the first link (read that windows 11 is prerequisite), then read and click the first link that says you need windows 10 build blah.
Sorry, but I don't see Windows 10 on it. The first link which I encounter (going through the above first link of the two that I gave) points to the Windows Insider Program, which is general for both Windows 10 and 11.
It was clear and documented that WSL1 was a command-line only tool.
Hmz, I wonder why ever VcXsrc was being written.... and what it can be used for ;)
That's a different story. As I've stated, WSL (1) officially supported Linux only for command-line.
But Microsoft did nothing to prevent people for enabling GUI applications on it. It's simply (well, not that simple: it required some changes which where not really straightforward.) extra stuff that external people tried and succeeded. ;)
As it was clear that GUI support for WSL2 (not 1) was officially coming with Windows 11 (which I've).
Officially perhaps yes. But it was already possible with Windows 10 (and with WSL 1, using x-forwarding).
Sure. Nothing to say about that: see above.
In the end, deadwood is in search of a reliable source so that he can quote from that (or base his documentation on it). Your experience helps (thank you for sharing) but I am assuming that it is common knowledge that x works for WSL2 on win 11. I am also assuming that it is the niche (WSL1/win10 or perhaps even wsl2/win10) that is currently of more interest.
Correct.
-
Hi All,
Thanks to efforts of @cdimauro, AxRuntime is now confirmed to be working on Windows 11 using WSL. There were some issues that required a new release, 41.3 which is now available: https://axrt.org/index.php?tab=download. More information can be found in the documentation: https://github.com/deadw00d/AROS/blob/alt-runtime/arch/all-runtime/docs/distribution/README or a few post above. Enjoy!
(https://axrt.org/media/windows-desktop-20220506.jpg)
-
interesting :)
-
Dear friends. When I started my retirement life, I was pretty much into hobbies. Kuksa glass, wooden spoon, my real profession is like painting. Now, clearing up this huge mess, I started to get involved with the amiga, which has made my life a painter-graphic designer. However, I noticed some things. According to my investigations in this area, Amiga os 3.2.1 is for original hardware, Amiga os 4.1fe is for new amiga clone hardware, but with an emulator. "MorphOs" is for new amiga clone hardware and older hardware with Apple Power processors. Finally, I reviewed Aros 32 and 64. Aros x32 seems to have single processor support. Aros 64 multi-processor support. It seems that Amiga developers always have a weakness. Not focusing on up-to-date hardware and competing seems to have followed no rational path. I want to know this. What applications can be called vital that work on Aros 32 and not on Aros 64? Like emulators. Could you give information. Which version (x86-x64) is currently in active development? Has there been an effort to add multiprocessor support for x32? Thank you in advance for your interest. I can't even imagine what it would be like today if the Amiga had progressed in the right way. stay with love.
-
Hi braincure, to know the situation just read the various discussions on this forum, sure AROS x86 ABI-v0 is the system that has remarkable softawre, all the others have no dedicated software except some sporadic application.
The problem is that AROS developers are few while users theoretically are "many" even if passing through, just look at the movement of this forum, so many visitors but only very few linger to discuss, as a result there is no growth and right information.
I do not know the technical functions of the CPU on AROS x86 ABI-v0, but I can assure you that on my Dual-Core AROS x86 is blazingly fast.
-
Dear friends. When I started my retirement life, I was pretty much into hobbies. Kuksa glass, wooden spoon, my real profession is like painting. Now, clearing up this huge mess, I started to get involved with the amiga, which has made my life a painter-graphic designer. However, I noticed some things. According to my investigations in this area, Amiga os 3.2.1 is for original hardware, Amiga os 4.1fe is for new amiga clone hardware, but with an emulator. "MorphOs" is for new amiga clone hardware and older hardware with Apple Power processors. Finally, I reviewed Aros 32 and 64. Aros x32 seems to have single processor support. Aros 64 multi-processor support. It seems that Amiga developers always have a weakness. Not focusing on up-to-date hardware and competing seems to have followed no rational path. I want to know this. What applications can be called vital that work on Aros 32 and not on Aros 64? Like emulators. Could you give information. Which version (x86-x64) is currently in active development? Has there been an effort to add multiprocessor support for x32? Thank you in advance for your interest. I can't even imagine what it would be like today if the Amiga had progressed in the right way. stay with love.
Hi Braincure,
here are on aros-exec are mostly developers and distribution maintainers visible active. Users not so much, f.e. ApolloOS (that is based on Aros 68k) is discussed on discord. Why there never were many posts from X86 users is outside of my knowledge. There are not many 64bit apps right now. Perhaps you can look at this: https://vmwaros.blogspot.com/p/64-bit.html
I do not know how up to date it is though. I also have not heard of much new software on Aros 64bit recently. And that there is not much development is simply related to not many developers. Kalamatee seems to be active again and Deadwood. Michal is also Aros developer but currently more active with emu68 on PiStorm. No one gets money from it so you must do it for personal fun. I do not think that anyone currently tries to implement SMP on X86. It simply makes no sense. X86 with one core is more than fast enough for all existing apps and games, SMP is needed for more powerful stuff but for that 32bit RAM is not enough. Then you end again in 64bit. And "right way" making everyone happy is impossible in my view ;). People in community have very different interests. And (in my view) you always have the problem of limited resources with not enough drivers and a small software base. That is impossible to overcome as a niche system. In this sense the idea of AxRuntime to get amiga components (including desktops) working on Linux as Linux software is the only realistic way forward. But even if you have something that is linux based and includes many amiga components and the look&feel, even then people will moan that it is linux not amiga and/or not Aros. As I wrote.... it is impossible to make everyone happy
-
Still supporting x86 doesn't makes sense "per sé" (by itself), not only because of SMP.
In fact, this ISA was already EoL from long time.
Since years no PC or similar device is sold with an x86 chip: all of them are x64.
In the last years also Linux distros are released only for x64 (I haven't checked all of them, of course: only some tenths of the most famous / used ones).
So, x86 support could be dropped as well on all o.s.: it's really too old.
I don't say that it's a retro/legacy architecture, because it's still largely supported (and with a lot of software), but the future is clearly and definitely x64 and definitely not x86.
Let x86 (naturally) die (by age)...
-
Thank you for your interest and answers. When the powermac apple, on which Morphos leans, leaves, its throwback is not valid for AROS. As far as I can see, Aros is missing the opportunity to have a great future. Looking back at history, the Amiga was making its own hardware. Currently, with the M1, apple has just reached this stage. here Amiga focus is on Multitask, sound graphics capabilities. The answer to the question of what should I expect when I look at Aros: The harmony of sound, graphics and operating system. However, as you said, it is impossible to provide these in a pc industry without the support of thousands of hardware and their drivers. While examining Aros, I hit hard walls such as single cpu, lack of drivers. However, I have a special admiration for the coding of such a system. However, in the capitalist system, unfortunately, when there is no money, there is no product, applies.
-
In fact, this ISA was already EoL from long time.
Since years no PC or similar device is sold with an x86 chip: all of them are x64.
just as a sidemark, this is quiet wrong actually.
there is no x86_64 CPU at all, they all are x86_32 which can be switched into 64 bit mode as well, but they are booting in x86_32 mode and then be switched to x86_64. That's the reason its so easy to make 32bit and 64bit applications side by side in Linux/Windows, the 64bit is just an extension of the 32bit part (which in part is just an extension of the 16 bit x86 part, "protected mode" anyone?) so it is not EOL (except the x87 FPU, which is marked as deprecated)
The real 64bit CPU would be IA64 which is (or better was) Itanium which only has 64bit and just emulates the 32-bit x86
-
This is about AxRuntime. If there is interest in a system discussion like 32bit X86 versus 64bit AMD64, ported software to 64bit and so on we should create a new thread for it
-
Hi All,
Thanks to great work of Damir, AxRuntime page has now a new, great design. Check it out: https://axrt.org/
If you have a webpage to create/update I highly recommend contacting @damir!
Best regards,
Krzysztof
-
The dark characters are not seen well :-\
-
Thamk you Damir for fix the web site ;)
-
Thamk you Damir for fix the web site ;)
I thought that you had browser caching issues, but Ive forgot to replay :P
-
no they were the fonts did not see each other well
-
I checked with Firefox now the problem is Odyssey on Aros but the site works
-
I checked with Firefox now the problem is Odyssey on Aros but the site works
I have to make tests in Odyssey to see what can or can't be done.
Do you know where else can I get more info (beside wiki) about Odyssey capabilities?
-
Odyssey is based on the Leopard webkit engine I don't know what to tell you more
-
Release v41.4 of AxRuntime is now available. Main feature is that interacting with Intuition windows (moving, resizing, etc) now happens via Intuition gadgets and there is no longer window decoration duplication. Checkout this video to learn more: https://www.youtube.com/watch?v=1pvu76Lmp0Q
AxRuntime v41.4 can be downloaded from:
https://axrt.org/downloads
https://github.com/deadw00d/AROS/releases/tag/AxRT_41.4
If you are interested in developing using AxRuntime, contact me on this forum or visit https://axrt.org/contact.
-
Great Deadwood!
-
Fantastic!! Well done! :)
-
@deadwood great thank you :)
-
Release v41.5 of AxRuntime is now available.
It is a small, bugfix release.
AxRuntime v41.5 can be downloaded from:
https://axrt.org/downloads
https://github.com/deadw00d/AROS/releases/tag/AxRT_41.5
If you are interested in developing using AxRuntime, contact me on this forum or visit https://axrt.org/contact.
-
thank you Deadwood
-
Pretty Awesome seeing wanderer on debian bookworm!! :)
Github instructions work great. I couldn't get your .deb package to work as I'm not using your reference system (libjpeg8 I believe is only supported on ubuntu now).
One small problem for me was that I couldn't get ./Wanderer to start a second time unless I went through the configure setup, copy loader and then ./Wanderer again.
Output is;
<<INFO>>: AxRT 41.5
<<INFO>>: Using absolute paths.
<<INFO>>: RUNTIME_ROOT: /usr/lib/x86_64-linux-gnu/axrt/4.0/
<<INFO>>: AXRTSYS : ROOT:usr/lib/x86_64-linux-gnu/axrt/4.0/
<<INFO>>: USERSYS : ROOT:home/gavin/.axrt/
<<INFO>>: USERHOME : ROOT:home/gavin/
<<ERROR>>: Runtime not found at /usr/lib/x86_64-linux-gnu/axrt/4.0/
<<ERROR>>: Aborting...
So, I know why its not working, I just don't know how to fix it. No /axrt/4.0/ folders were created and I cant figure out what I need to put in them either :/
I didn't notice any errors during installation, if I did, I probably would have tried sudo or from root.
Help needed :)
-
@G-linx
I'm glad you liked it :)
Looking at your output, the runtime in started in "absolute paths mode". This is the default mode it works for example when installed from a .deb package.
In order for it to work in "relative path mode", you need this line
export AXRT_ROOT=<myrepo-absolute-path>/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/AROS
Reading from your explanation, you probably opened a new linux console window later to run Wanderer. In that case you need to execute this line each time you open a new console window. :)
-
Brilliant!!
Made a #!/bin/bash and a .desktop file to get an AxRuntime icon on the desktop. A one click wonder! :)
-
Apart from Wanderer, there is also a collection of other applications you can use:
https://axrt.org/downloads
I for example use MPlayer daily on my system :)
-
..I ran into the libjpeg8 problem again. I tried git cloning but didn't get very far. I'll set up a LinuxMint 21 ssd to make it easier to get going and keep up with this :)
Google tells me that debian moved to libjpeg-turbo years ago, and ubuntu uses its own strategy to keep libjpeg8 going. But, if ubuntu moved to (only) libjpeg-turbo in the future would this mean all the packaged .deb files you (and hopefully many others) have already made will have to be re-configured all over again?
-
Yeah, I guess so. In Linux world it looks more like every major version of distribution has all the packages re-build for it. That's unlike Amiga (and Windows) where binary backwards compatibility is kept. Have you tried intalling ubuntu's libjpeg8 package on debian? Maybe it can co-exist with what debian offers.
-
I tried an ubuntu package but it took me in circles. Another google suggested enabling multi lib but as this is my main desktop machine and not really for experimenting on. But it really doesn't mater, Your creation is beautiful!
Once the community establishes our own back-end system you can can customize the heck out of it to suit your/community needs :)
Linux Mint install coming up later today for me :)
Once again I was late to the party, this time in realizing the potential of AxRuntime!
-
Note that you can also run 64-bit AROS version of MPlayer on AxRuntime. You however need AxRuntime-version AROS Shell to do this (which might not work due to libjpeg), but this way you overcome problems. AROS MPlayer depends on AROS jpeg.library, not Linux library.
It's good to hear you are enthusiastic about AxRuntime :)
-
Great!
I just realized that the acronym of an AxRuntime OS would be AxROS :)
-
@G-linx:Actually it is AXRT or if you prefer: AxRTOS :)
-
I leave deadwood to cast his preference :)
-
Let's come back to this discussion when there is something that resembles an OS ;-)
-
Due to Aros-Exec shutting down, this thread is locked and moved to arosworld.org
https://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1118