AROS World Exec
Development => Development (General) => Topic started by: deadwood on November 20, 2021, 01:15:33 AM
-
Hello,
I will use this thread to share with you developments around my AROS-related projects. This will give you some insight in what you may and may not expect in coming months. First however I will give you a description of projects I maintain: AROS ABIv11, AROS ABIv0, AxRuntime.
AROS ABIv11
===========
ABIv11 is a code name I have given to my stable branch of AROS for 64-bit Intel and AMD processors. The code name is given to distinguish this version from the in-progress ABIv1 effort in main AROS repository. Stable branch in this context means that if a third party developer builds an application following these rules (https://github.com/deadw00d/AROS/blob/master/README.md#backwards-compatibility) today, I commit that the application will be working tomorrow, next month and in a year from now. This is the main place where changes from me and other developers happen.
ABIv11 is hosted in this branch: https://github.com/deadw00d/AROS
ABIv11 forms a base for the other two projects.
AROS ABIv0
==========
The version of AROS currently in use for 32-bit Intel and AMD processors. If you are using Icaros, Aros One or another distribution, you are most likely running ABIv0 as base system. Most of 3rd party applications available on Aminet or AROS-Archives are compiled for ABIv0.
ABIv0 is hosted in this branch: https://github.com/deadw00d/AROS/tree/alt-abiv0
ABIv0 "sits" on top of ABIv11. Most of the changes that are introduced to ABIv11, will eventually be flow to ABIv0 as well without additional effort from initial developers.
AxRuntime
=========
This is a set of Linux libraries that allows re-compilation of Amiga/AROS application into a native Linux application. More information is available here: https://axrt.org/index.php?tab=more
AxRuntime is hosted in this branch: https://github.com/deadw00d/AROS/tree/alt-runtime
AxRuntime "sits" on top of ABIv11. Most of the changes that are introduced to ABIv11, will eventually be flow to AxRuntime as well without additional effort from initial developers.
-
The approach I'm taking is having a small number of milestones achievable in a couple of months. Once these are done, next will be announced which will depend on my availability as well as interest at that point in time.
Here are current plans, as of 20211120.
1) Bring over selected changes from AROS repository (https://github.com/aros-development-team/AROS) to ABIv11 [DONE]
2) Bring over selected changes from Apollo repository (https://github.com/ApolloTeam-dev/AROS) to ABIv11 [DONE]
3) Release next version of ABIv11 [DONE]
https://build.axrt.org/download/builds/AROS-ABIv11/amiga-m68k-20211217-165106.tar.gz
https://build.axrt.org/download/builds/AROS-ABIv11/linux-x86_64-20211217-172953.tar.gz
-
Sounds good :) thanks
I am grateful that you do this
there are three issues I experienced on 68k with some of the applications and games
There was always a problem that the applicatios (f.e. a viewer) requested and expected f.e. a PAL screen but got something RTG related and then of course not worked
some of the applications open the file requester and then the system freezes. But only some, not all.
there seem to be a jostick related bug. In some games it seems the fire button is contantly pressed (while it is not). This again not affects all games
there are certainly other issues too,. The Vampire team did a lot of bugfixing on 68k.
-
Thank you very much Deadwood :)
-
@deadwood
It's good to have a plan moving forward.
We appreciate all your efforts and your willingness to help.
We will continue to do testing and provide you with accurate reports to help find problems and get them resolved quickly.
Thanks again for your insight and wisdom. :)
-
Thank you deadwood that you still believe in AROS, I still didn*t won the lottery but I keep donating!
-
https://github.com/deadw00d/AROS/blob/master/README.md#backwards-compatibility
One question deadwood, but are the updated distros ABIv0 found in this link usable, what are the improvements, can they be used?
-
https://github.com/deadw00d/AROS/blob/master/README.md#backwards-compatibility
One question deadwood, but are the updated distros ABIv0 found in this link usable, what are the improvements, can they be used?
Updates for ABiv0 are released from time to time. I will make separate threads here when this happens. The 20180415 is still the latest release.
-
Ok Thanks
-
@deadwood: to me it's logical to have a common source "core" to every AROS "distro", and separate repos/branches for specific targets.
However isn't cherry-picking stuff to all such repos too much a burden to do & maintain?
Another question. It looks like that your is a fork from AROS "official repository". I think that you cherry-pick from there most of the stuff, right?
Having several repositories with some relationship between them looks a bit messy to me. Any idea about a common repo, to have a central place where to look at, and to also reduce the maintenance effort?
-
@deadwood: to me it's logical to have a common source "core" to every AROS "distro", and separate repos/branches for specific targets.
However isn't cherry-picking stuff to all such repos too much a burden to do & maintain?
This depends on the traffic in other repos. Today it is managable. If there is a traffic of "tens" of commits per day, it might not be.
Another question. It looks like that your is a fork from AROS "official repository". I think that you cherry-pick from there most of the stuff, right?
My github repo is directly re-created from the AROS SVN commits if that is what you are asking about.
Having several repositories with some relationship between them looks a bit messy to me. Any idea about a common repo, to have a central place where to look at, and to also reduce the maintenance effort?
Don't know. My repo suits my specific needs and projects, similar to Apollo repo suiting theirs I guess.
-
Thanks for the clarification deadwood. One last question, since you mentioned: is the AROS SVN repo still used / the "master" repo, or is it moved to git (and development continues there)?
-
Thanks for the clarification deadwood. One last question, since you mentioned: is the AROS SVN repo still used / the "master" repo, or is it moved to git (and development continues there)?
Since middle of 2019 SVN repo is no longer used.
-
@deadwood: to me it's logical to have a common source "core" to every AROS "distro", and separate repos/branches for specific targets.
However isn't cherry-picking stuff to all such repos too much a burden to do & maintain?
Another question. It looks like that your is a fork from AROS "official repository". I think that you cherry-pick from there most of the stuff, right?
Having several repositories with some relationship between them looks a bit messy to me. Any idea about a common repo, to have a central place where to look at, and to also reduce the maintenance effort?
I think you underestimate the problems the multi-platform one source concept has. For example in the last years it happened frequently that 58k stuff was broker after updates/changes. I also saw devs fixing other platforms after commits. You would need a big testing infrastructure and lots of external testers for that. Both does not exist. In my view it is better to have seperate branches with some coordination. At the moment the main branch is dead anyway so there is not a real problem there.
-
Over last two weeks I've been working on re-design on ABIv11 C library. This is now pushed into repository and available.
You can find specification on new libraries here: https://github.com/deadw00d/AROS/blob/master/compiler/crt/SPECIFICATION
Be sure to note, that while libraries sound new, they build on years of prior work by Staf, Kalamatee, Jason and many others.
This also means, that effective today, stdc.library, stdcio.library and posixc.library are no longer part of the build of ABIv11. If you also created and published an application for ABIv11 that uses any of the deprecated libraries, please get in contact with me and we will figure out a solution.
If you have local builds of ABIv11, please rebuild them (including cross-compilers) from scratch after 'git pull'.
-
Some of the datatypes use posixc library.
I'll do a complete rebuild later today or tomorrow.
Thanks for the update.
-
Thank you deadwood :)
-
Some of the datatypes use posixc library.
I'll do a complete rebuild later today or tomorrow.
Thanks for the update.
These are good as tests beds. If you stop regression let me know via PM or separate thread.
-
Hi,
The planned topics are DONE. In the original post you will find links to releases.
For January, I plan to get back to ABIv0 and make a new release based on newer ABIv11 code base. I will share more once I do detailed planning.
-
ok deadwood thank you :D
-
But to fill out the source code of some programs that are on Archives in the new architecture, you must first fill out the source tree and then how can you proceed?
-
@salvo
I don't understand your question.
-
Excuse me I wanted to know to bring something in Archives on Aros X64, before I have to fill out the tree of the source
-
If you are looking for source tree of ABiv11, then the link is available in the first post.
-
ok thank you :)
-
Hello,
Some good news from me. I've been working over last 3 weeks to fully define ABIv11 call conventions which is now done. This also means there is first official release of ABIv11 for x86_64!
First, link to ABI documentation: https://github.com/deadw00d/AROS/blob/master/arch/x86_64-all/ABI_SPECIFICATION
Next, link to releases (bottom of page): https://axrt.org/index.php?tab=download-aros
I also prepared first "3rd party" application - a build of MPlayer is now available on Archives: http://archives.aros-exec.org/index.php?function=showfile&file=video/play/mplayer-1.0-v5.x86_64-v11-aros.zip
The change to calling conventions means that if you already created and published an application for ABIv11 they will no longer work. Please get in contact with me and we will figure out a solution. If you have local builds of ABIv11, please rebuild them (including cross-compilers) from scratch after 'git pull'.
The last month's C library re-design and this change are the last major impacting changes that I had planned for ABIv11. This nicely closes off 2021 and opens 2022 for incremental improvements and growth.
If you want to try compiling some applications, downlod the "System" archive, the "Contrib" archive and copy the files from "Contrib" into "System". This will install GCC 6.5.0 for you. Contrib archive also contains 'make' and other basic unix utilities which should help you with compilation. Be sure to run AROS with at least 256MB RAM (-m 256). When uploading to AROS-Archives, please use the "x86_64-v11-aros" suffix of archive file names (see MPlayer example).
-
Hello Deadwood,
one question... is it possible to compile mplayer also for 68k?
-
thanks deadwood I will try to compile something, at some point I get there that is to create the build system after I get stuck, for example if I download the source code of yquake2 and put it in a directory of the build system example "local" how do I compile it?
-
ok maybe
ls /local/yquake2/
make local-yquake2
?
-
@salvo
If you are a beginner the easiest path is to educate yourself on principles by compiling for Windows or Linux. There are hundreds of resources on the internet, tutorials, you tube videos etc. Once you understand how building using make works on popular systems, the AROS specific parts can be quickly learned.
-
ok deadwood :)
-
Hello,
Some good news from me. I've been working over last 3 weeks to fully define ABIv11 call conventions which is now done. This also means there is first official release of ABIv11 for x86_64!
First, link to ABI documentation: https://github.com/deadw00d/AROS/blob/master/arch/x86_64-all/ABI_SPECIFICATION
Next, link to releases (bottom of page): https://axrt.org/index.php?tab=download-aros
I also prepared first "3rd party" application - a build of MPlayer is now available on Archives: http://archives.aros-exec.org/index.php?function=showfile&file=video/play/mplayer-1.0-v5.x86_64-v11-aros.zip
The change to calling conventions means that if you already created and published an application for ABIv11 they will no longer work. Please get in contact with me and we will figure out a solution. If you have local builds of ABIv11, please rebuild them (including cross-compilers) from scratch after 'git pull'.
The last month's C library re-design and this change are the last major impacting changes that I had planned for ABIv11. This nicely closes off 2021 and opens 2022 for incremental improvements and growth.
If you want to try compiling some applications, downlod the "System" archive, the "Contrib" archive and copy the files from "Contrib" into "System". This will install GCC 6.5.0 for you. Contrib archive also contains 'make' and other basic unix utilities which should help you with compilation. Be sure to run AROS with at least 256MB RAM (-m 256). When uploading to AROS-Archives, please use the "x86_64-v11-aros" suffix of archive file names (see MPlayer example).
This change will also affect ABIv0 ?
-
This change will also affect ABIv0 ?
No, these changes will not affect ABIv0.
Actually you quoted the answer yourself already :)
This also means there is first official release of ABIv11 for x86_64!
e.g. it is named ABIv11 for a reason ;)
-
If you want to try compiling some applications, downlod the "System" archive, the "Contrib" archive and copy the files from "Contrib" into "System". This will install GCC 6.5.0 for you. Contrib archive also contains 'make' and other basic unix utilities which should help you with compilation. Be sure to run AROS with at least 256MB RAM (-m 256). When uploading to AROS-Archives, please use the "x86_64-v11-aros" suffix of archive file names (see MPlayer example).
ok understand I tried to compile something but I always receive mistakes, I stop here :-X
-
If you want to try compiling some applications, downlod the "System" archive, the "Contrib" archive and copy the files from "Contrib" into "System". This will install GCC 6.5.0 for you. Contrib archive also contains 'make' and other basic unix utilities which should help you with compilation. Be sure to run AROS with at least 256MB RAM (-m 256). When uploading to AROS-Archives, please use the "x86_64-v11-aros" suffix of archive file names (see MPlayer example).
ok understand I tried to compile something but I always receive mistakes, I stop here :-X
Fixing the errors is the most fun. ;)
-
This change will also affect ABIv0 ?
No, these changes will not affect ABIv0.
Correct
-
Thanks deadwood, specifically I was referring to the fact the new feautures will be ported to ABIv0 as well.
-
Thanks deadwood, specifically I was referring to the fact the new feautures will be ported to ABIv0 as well.
Ok, now I understand. The calling convention will not - it is specific to x86_64. The reworked C libraries will become available in ABIv0 at some point.
-
Hi,
As indicated earlier, I made plans for next milestones - you can find them below. They are listed in an order I plan working on them.
1) Release new version of AxRuntime based on recently releases ABIv11
2) Migrate ABIv0 from GCC 4.2.4 to GCC 6.3.0. This will provide better tooling for 3rd party developers.
3) Release new version of ABIv0 refreshed to common codebase from around 2019-03-01 (Today we are on 2018-04-15)
-
Hello Deadwood
question again (sorry do not want to nerve)
have you looked at the "software not correctly closes"? That was what I reported that f.e. demos but also applications not correctly close and you only get a empty screen and you have to reboot
-
Hi,
As indicated earlier, I made plans for next milestones - you can find them below. They are listed in an order I plan working on them.
1) Release new version of AxRuntime based on recently releases ABIv11
2) Migrate ABIv0 from GCC 4.2.4 to GCC 6.3.0. This will provide better tooling for 3rd party developers.
3) Release new version of ABIv0 refreshed to common codebase from around 2019-03-01 (Today we are on 2018-04-15)
Thank you deadwood :)
-
Hello Deadwood
question again (sorry do not want to nerve)
have you looked at the "software not correctly closes"? That was what I reported that f.e. demos but also applications not correctly close and you only get a empty screen and you have to reboot
It's on my list, but I haven't looked into it yet. Its probably more effective if you try interesting someone from Apollo team in this issue as well - they are more engaged with m68k than I am.
-
@deadw00d
It is of futile importance but on your axrt downloadpage (https://axrt.org/index.php?tab=download-aros) it is spelled desription (but should read description)
... and while i'm at it :)
@salvo:
In your sig: It is spelled Maintainer and not Manteiner
-
ok magorium ;D
-
@deadw00d
It is of futile importance but on your axrt downloadpage (https://axrt.org/index.php?tab=download-aros) it is spelled desription (but should read description)
... and while i'm at it :)
@salvo:
In your sig: It is spelled Maintainer and not Manteiner
Just minor infringements. Probably due to faulty keyboard layout. ;)
salvo though is a different matter. He just can't spell right.
-
I thought it was written correctly I never learned English ;D
-
@deadw00d
It is of futile importance but on your axrt downloadpage (https://axrt.org/index.php?tab=download-aros) it is spelled desription (but should read description)
Fixed, thank :)
-
Next, link to releases (bottom of page): https://axrt.org/index.php?tab=download-aros
I have been trying to compile MUIbase for x86_64-v11 and (after some changes [mostly ULONG -> IPTR]) everything compiles without serious warnings, but the resulting binary does not start.
I am using the https://www.axrt.org/download/aros/v11/AROS-20211231-1-linux-x86_64-system.tar.bz2 (https://www.axrt.org/download/aros/v11/AROS-20211231-1-linux-x86_64-system.tar.bz2) release, and built the corresponding toolchain using the instructions from https://github.com/deadw00d/AROS/blob/master/INSTALL.md (https://github.com/deadw00d/AROS/blob/master/INSTALL.md).
I tracked it down to global variables that somehow get missing in the binary. Here is an example.
The following compiles and runs as expected:
#include <stdio.h>
int main(void)
{
printf("Hello world\n");
return 0;
}
But when adding a global variable like this:
#include <stdio.h>
// I love global variables, in particular when they are called 'i' ;-)
int i;
int main(void)
{
printf("Hello world\n");
i = 0;
return 0;
}
The binary doesn't start. The output in the CLI window is: "hello: file is not executable" and the Linux terminal where I booted AROS from prints "[ELF Loader] COMMON symbol 'i'".
Thus, somehow the linker removed the global symbol 'i'. Any idea what is wrong?
Here is the command I used to compile (I made symbolic links from /usr/local to the directories where I unpacked and compiled v11):
/usr/local/aros-sdk/toolchain-core-x86_64/x86_64-aros-gcc --sysroot /usr/local/aros-sdk/SDK-core-x86_64 -o hello hello.c
-
I think the solution is either to initialize the global variable to 0 OR to add -fno-common switch to the compilers comand line.
I looked up the history and it seems this change has been made to make older gcc versions (like 6.5.0) behave the same as the gcc 10 and up.
-
Thanks, that worked! MUIbase now also runs on x86-64-v11.
Is there a way on AROS to detect whether AROS is compiled for i386 or x86-64? It yes, it would allow to pre-select the right binary in the Installer script.
-
Glad it worked :)
About your question, I see two ways:
1) aros.library (http://www.aros.org/documentation/developers/autodocs/aros.php) ArosInquireA with AI_ArosArchitecture tag. You get get a pointer to string like "linux-x86_64" or "pc-x86_64". You can grab CPU archictecture from there.
2) There is ABI environment variable you can read. Value of 0 most likely means it is i386 (however there was once ABIv0 for arm as well). Version of 11 means most likely x86_64 (though my builds of amiga-m68k also have version 11).
-
Env:ABI sounds good to me since that is easily accessible from within an Installer script. It is okay if it isn't right all the time since it will only be used for pre-selecting the binary to install and the user can still change it.
-
Here is another question. How do I correctly implement a function that takes variable number of arguments on AROS?
Here is a sample program:
#include <stdio.h>
#include <stdarg.h>
#include <libraries/mui.h>
#include <proto/muimaster.h>
#include <proto/intuition.h>
#include <proto/exec.h>
#define VARARGS68K __stackparm
struct Library *MUIMasterBase = NULL;
static void VARARGS68K ask(Object *app, const char *fmt, ...)
{
va_list va;
va_start(va, fmt);
MUI_Request(app, NULL, 0, "Requester", "*Ok", fmt,
(APTR)va->overflow_arg_area);
va_end(va);
}
int main(void)
{
MUIMasterBase = OpenLibrary((STRPTR)MUIMASTER_NAME, 0);
if (MUIMasterBase == NULL) {
printf("No MUI\n");
return 10;
}
Object *app = ApplicationObject, End;
ask(app, "6 * 7 = %d", 42);
MUI_DisposeObject(app);
CloseLibrary(MUIMasterBase);
return 0;
}
When running this on x86-64-v11 I get the funny result: "6 * 7 = 22160" :(
-
@muibase
Moved to another thread:
https://ae.amigalife.org/index.php?topic=852.0
-
Thanks, that worked! MUIbase now also runs on x86-64-v11.
Is there a way on AROS to detect whether AROS is compiled for i386 or x86-64? It yes, it would allow to pre-select the right binary in the Installer script.
Thank you steffen
-
Hi,
It looks like we are having Free Pascal compiler working on ABIv11 as well as several useful applications ported. :) See this link:
https://blog.alb42.de/2022/02/07/aros64-again-this-time-abi-11/
https://blog.alb42.de/2022/02/07/the-100-useless-aros-distribution-0-3/
Thanks go to ALB42.
-
yes good :)
-
Hi,
It looks like we are having Free Pascal compiler working on ABIv11 as well as several useful applications ported. :) See this link:
https://blog.alb42.de/2022/02/07/aros64-again-this-time-abi-11/
https://blog.alb42.de/2022/02/07/the-100-useless-aros-distribution-0-3/
Thanks go to ALB42.
A few days ago I tried to start it from VM but it doesn't seem to work, I don't like Host systems so I didn't try other modes.
-
Hi,
It looks like we are having Free Pascal compiler working on ABIv11 as well as several useful applications ported. :) See this link:
https://blog.alb42.de/2022/02/07/aros64-again-this-time-abi-11/
https://blog.alb42.de/2022/02/07/the-100-useless-aros-distribution-0-3/
Thanks go to ALB42.
A few days ago I tried to start it from VM but it doesn't seem to work, I don't like Host systems so I didn't try other modes.
AROS Hosted is great. One of the benefits is using the Host file managers to copy or delete data while AROS is running. It speeds up the process.
-
Yes I know miker but as said I'm not really excited about a Host system.
-
@deadwood
Discussing with ALB42 on AmiTube we have found that on AROS ABIv1, then AROS 68k and AROS ABIv11 there is a problem on the texts obtained after a search with AmiTube, in practice the texts are corrupted, to fix them you have to enlarge the GUI.
I specify that on AROS x86 ABIv0 everything works perfectly and there is no corruption on the text!
I attach a link to the discussion where ALB42 has attached a video that shows the artifacts on the text, while I attach a video on AROS One x86 where there is no corruption, the text is perfect.
http://eab.abime.net/showthread.php?t=109252&page=2
-
Thanks, bug report created: https://github.com/deadw00d/AROS/issues/61
-
Hi,
As indicated earlier, I made plans for next milestones - you can find them below. They are listed in an order I plan working on them.
1) Release new version of AxRuntime based on recently releases ABIv11
2) Migrate ABIv0 from GCC 4.2.4 to GCC 6.3.0. This will provide better tooling for 3rd party developers.
3) Release new version of ABIv0 refreshed to common codebase from around 2019-03-01 (Today we are on 2018-04-15)
Some time has passed since I decided on these milestones and I figured out an update is in order.
Over last weeks I've been focused on working on point 1) and doing some extended testing with @magorium and @muibase. I'm pleased to report that all experiments that I had planned in are now finished with success and I'm moving to phase of clean up and preparation for release. If all goes well the new release of AxRuntime should be available by end of this month. This means starting from April I will turn my focus on ABIv0 and having it catch up with features of mainline development.
-
Ok thanks deadwood, I will wait for April to update and distribute the new version of AROS One x86
-
ok deadwood thank you :)
-
@deadwood
Why on Wanderer is it not possible to rename a volume?
To change a volume name you have to do it from the Shell with the command relabel or from HDToolbox!
-
I don't know, probably a missing feature.
-
Yes it is a problem of Wander, but also of Scalos, as you can see from the screenshot the two systems give a different error.
No problem for Magellan, but this is normal since Magellan completely replaces "the Workbench".
-
Hi,
As indicated earlier, I made plans for next milestones - you can find them below. They are listed in an order I plan working on them.
1) Release new version of AxRuntime based on recently releases ABIv11 - DONE
2) Migrate ABIv0 from GCC 4.2.4 to GCC 6.3.0. This will provide better tooling for 3rd party developers.
3) Release new version of ABIv0 refreshed to common codebase from around 2019-03-01 (Today we are on 2018-04-15)
Hi,
Today a new release of AxRuntime has been made. With this, I will take a few days off and then move to ABIv0 topics, starting with upgrade of GCC.
-
Thank you for your work !
-
thank you deadwood :)
-
Hi,
As indicated earlier, I made plans for next milestones - you can find them below. They are listed in an order I plan working on them.
1) Release new version of AxRuntime based on recently releases ABIv11 - DONE
2) Migrate ABIv0 from GCC 4.2.4 to GCC 6.3.0. This will provide better tooling for 3rd party developers. - DONE
3) Release new version of ABIv0 refreshed to common codebase from around 2019-03-01 (Today we are on 2018-04-15)
Hi All,
Migration is now done and release made. See this thread: https://ae.amigalife.org/index.php?topic=909.msg10802#msg10802
-
Hi,
Being 2/3 done on my January list, I wanted to give you a bit more info on two concrete things I'm planning and a bit longer-term horizon.
Concrete planned items:
1) Release new version of ABIv0 refreshed to common codebase from around 2019-03-01 (Today we are on 2018-04-23)
2) Port Scalos to AxRuntime so that it can become Linux desktop manager
On a longer horizon, there will be a lot of work related to ABIv0 and AxRuntime. I want to update ABIv0 to be based on latest ABIv11 source code. This will be an enabler to having a version of AxRuntime that is capable of running ABIv0 32-bit programs on top of Linux.
Once all these things are in place, we will have a Linux-native desktop (Scalos) and ability to run AROS ABIv0 programs (32-bit), AROS ABIv11 programs (64-bit) and AxRuntime-recompiled programs (64-bit). This way existing Distros could be re-created using Linux as a base without loosing existing functionality for users, enabling a gradual migration from 32-bit to 64-bit.
It's a lot of work. If you are interested in helping out in any of these topics or just writing code for AROS, please let me know!
-
yes Deadwood I understand as soon as it will be released I will try Axruntime with the new scalos desktop is interesting as evolution, I don't know if I will be able to create a distribution but I will try :)
-
Hi,
2) Port Scalos to AxRuntime so that it can become Linux desktop manager
If there have been no new updates on Scalos, i would say that compared to Wandere at less speed and less compatibility, if on the other hand there have been updates that improve Scalos, then there will also be AROS One Scalos x86 version.
Thank you epr the much work you do for the community
-
I will worry about publishing TinyArosX ;), In the past I used Pascal Papara aeros but then it became obsolete, so your new project does not scare me even if I have always preferred the native version, good work Deadwood and thanks for everything, I use every day as a main system for years :)
-
Hi,
Being 2/3 done on my January list, I wanted to give you a bit more info on two concrete things I'm planning and a bit longer-term horizon.
Concrete planned items:
1) Release new version of ABIv0 refreshed to common codebase from around 2019-03-01 (Today we are on 2018-04-23)
2) Port Scalos to AxRuntime so that it can become Linux desktop manager
On a longer horizon, there will be a lot of work related to ABIv0 and AxRuntime. I want to update ABIv0 to be based on latest ABIv11 source code. This will be an enabler to having a version of AxRuntime that is capable of running ABIv0 32-bit programs on top of Linux.
Once all these things are in place, we will have a Linux-native desktop (Scalos) and ability to run AROS ABIv0 programs (32-bit), AROS ABIv11 programs (64-bit) and AxRuntime-recompiled programs (64-bit). This way existing Distros could be re-created using Linux as a base without loosing existing functionality for users, enabling a gradual migration from 32-bit to 64-bit.
It's a lot of work. If you are interested in helping out in any of these topics or just writing code for AROS, please let me know!
Thank you very much. I think there a good opportunity to create something new and interesting based on Linux, AxRuntime and Scalos as desktop. I am already looking forward to it. BTW cool that also ABI0 aros apps will run on it. So we finally really will be able to mix Linux and any aros app or component on one platform. That (together with Scalos) will certainly make some cool things possible...
-
Hi,
2) Port Scalos to AxRuntime so that it can become Linux desktop manager
If there have been no new updates on Scalos, i would say that compared to Wandere at less speed and less compatibility, if on the other hand there have been updates that improve Scalos, then there will also be AROS One Scalos x86 version.
Thank you epr the much work you do for the community
I already test Scalos on WinHosted and it looks pretty fast. I do not know what you mean. BTW there are a lot of preferences that influence both behavior and speed. And "less compatibility" than Wanderer? I do not understand.
-
(https://i.ibb.co/jkbyqfT/tinyx.jpg) (https://ibb.co/YBPcJQ3)
Work in progress.......
-
@salvo
you are ahead of the time ;)
-
:D
long live Aros
-
I already test Scalos on WinHosted and it looks pretty fast. I do not know what you mean. BTW there are a lot of preferences that influence both behavior and speed. And "less compatibility" than Wanderer? I do not understand.
To understand you have to make comparisons and test the software one by one, as soon as possible I will try again to test Scalos with the new deadwood updates, all the anomalies, incomatibilities software will be listed.
The slowness is about the delay of Icons shown in windows, a problem you also experience on Scalos 68k.
-
Thank you all for your support and encouragement.
To address the question of Scalos. This is not based on my own experience but mostly on comments from Olaf. As far as I understand Scalos is more feature-rich than Wanderer and usability is key for this effort. I can fix simple bugs, but adding new functionality is time consuming. That is not to say that Wanderer will not be ported. It's rather that I think it makes sense to port Scalos as more usable first and focus on adding missing pieces before moving forward.
If you however disagree and think that Wanderer can be more usable, I'd like to know your arguments, examples, comparisons (please start a separate thread in such case) to arrive at best possible decision.
-
BTW cool that also ABI0 aros apps will run on it. So we finally really will be able to mix Linux and any aros app or component on one platform.
One thing that is also interesting is that on ABIv0 you have JanusUAE, which makes m68k Intuition windows appear as AROS Intuition windows. On the other hand, AxRuntime makes AROS Intutiion windows appear as native X windows. I wonder if this will work to eventually "forward" m68k application to work "as native" Linux applications.
-
Thank you all for your support and encouragement.
To address the question of Scalos. This is not based on my own experience but mostly on comments from Olaf. As far as I understand Scalos is more feature-rich than Wanderer and usability is key for this effort. I can fix simple bugs, but adding new functionality is time consuming. That is not to say that Wanderer will not be ported. It's rather that I think it makes sense to port Scalos as more usable first and focus on adding missing pieces before moving forward.
If you however disagree and think that Wanderer can be more usable, I'd like to know your arguments, examples, comparisons (please start a separate thread in such case) to arrive at best possible decision.
Sorry to comment that... with all respect Amigasystem is sometimes "special" with his attitudes. He also talked against Magellan despite Magellan far more powerfull. Or against on Aros 68k mixing Aros and Amiga software. I have no problem there with different attitudes but it starts to be silly. For me personal a limited desktop system like Wanderer is no option. I want to attract people, people from current NG camp (AmigaOS or MorphOS) or even from outside. If only Wanderer is available I will wait for Scalos to do a distribution. Unfortunately for him I use Scalos currently on both X86 and 68k so if he starts to promote Wanderer I will talk against that. The funny thing for a purist like Amigasystem (Aros purist) the idea to mix different platforms is not interesting anyway. Desktop defines user experience. I think one of the main reason for Aros being a long time not taken seriously was the limited desktop (Wanderer).
Features from Scalos page:
100% Workbench replacement - All functions work like the original Workbench ones
Undo and Redo for most window and icon operation
64bit arithmetic - Correctly recognises harddisks over 4GB
Fully multitasking - Every window has its own task. While loading icons, any window function (e.g. Drag&Drop) is available
Icon imagetypes - All types are supported such as backfill or complement. Configurable surrounding iconborder
Icon datatype system - NewIcon datatype included. Icon support also visually highlights files which are soft-links in the file system.
Icon dragging is more stable - And far less flickery on graphics cards. Whilst dragging, icons are displayed with text and they become transparent over anything where they can be dropped! MUI-alike transparency on low colour screens. Real transparency if running at 15-bit or greater.
Cybergraphics and Picasso96 24bit color support
Window patterns - Unlimited and easily configurable via tooltypes
Optimised backgroundpatterns routine - Patterns can be tiled, centred or even scaled to fit into the windows. With the use of render.library, you get full control over the dithering and pen usage of your patterns
Live updating window scrolling - Supports middle mouse button panning too!
Drawer windows can be iconified
Menu preferences - You can enjoy fully configurable menus (includes ToolsDaemon and Parm import), including support for context-sensitive Popup menus
Application Interface (API) - Anything is possible from outside the program itself
Custom preference programs - For both palette and patterns. A pen-locker is not required any more
Nearly all Workbench preferences are used
Installation is very easy
Supports PNG icons with alpha channel and real transparency
Displays OS3.5 GlowIcons even on OS3.1 machines
Scalable icons
Thumbnail preview icons for images - Thumbnails can be permanently saved in icons
Completely confgurable, filetype-specific user-definable popup menus and tooltips
Plugin system to exchange or add features - It enhances the Workbench and makes it more configurable
Filetype plugins to display filetype-specific information. - Currently, EXIF information viewer for JPEG images is included.
Iconborders - Nice looking, Icontext variations (normal, shadowed, outlined)
Screentitle text - Shows what you want, how you want
Plugin included for 100% support of OS3.9 Workbench features
Plugin included for AREXX API compatible to OS3.9 Workbench
Online update with updater.module
-
BTW cool that also ABI0 aros apps will run on it. So we finally really will be able to mix Linux and any aros app or component on one platform.
One thing that is also interesting is that on ABIv0 you have JanusUAE, which makes m68k Intuition windows appear as AROS Intuition windows. On the other hand, AxRuntime makes AROS Intutiion windows appear as native X windows. I wonder if this will work to eventually "forward" m68k application to work "as native" Linux applications.
sounds cool :)
-
Thank you all for your support and encouragement.
To address the question of Scalos. This is not based on my own experience but mostly on comments from Olaf. As far as I understand Scalos is more feature-rich than Wanderer and usability is key for this effort. I can fix simple bugs, but adding new functionality is time consuming. That is not to say that Wanderer will not be ported. It's rather that I think it makes sense to port Scalos as more usable first and focus on adding missing pieces before moving forward.
If you however disagree and think that Wanderer can be more usable, I'd like to know your arguments, examples, comparisons (please start a separate thread in such case) to arrive at best possible decision.
There is no need to add "new features". Scalos includes already tons of preferences and new features compared to 3.1 and Wanderer is functionality wise more or less on the same level. There is nothing wrong to me to have different tastes and prefer a simple and limited 3.1 level desktop but I do not think that this would attract users to it. If some bugs are identified and fixed it would be perfect. There is no need to create a new scalos version with new added features.
-
OlafS3 sorry I never speak as a Fan or a Fan, I try to be as realistic as possible.
That Magelan or Scalos have a few more features does not mean they work better.
I usually look at functionality and love maximum compatibility on a system that needs to be direct and not leaning on third-party applications.
Try to configure Scalos and then compare it with a Wandere based AROS, of course the comparison should not be done with a night but with well configured AROs systems like IcarOS or my AROS One which you have probably never tried ! Try it and then maybe find out also with Wanderer you can do what you do with Magelan or Scalos but at a faster speed, in addition to using a real Amiga clone
-
OlafS3 sorry I never speak as a Fan or a Fan, I try to be as realistic as possible.
That Magelan or Scalos have a few more features does not mean they work better.
I usually look at functionality and love maximum compatibility on a system that needs to be direct and not leaning on third-party applications.
Try to configure Scalos and then compare it with a Wandere based AROS, of course the comparison should not be done with a night but with well configured AROs systems like IcarOS or my AROS One which you have probably never tried ! Try it and then maybe find out also with Wanderer you can do what you do with Magelan or Scalos but at a faster speed, in addition to using a real Amiga clone
Ha Ha
Icaros Desktop IS Magellan for a long time. Do your job
from icaros desktop site:
I've made some little changes to Magellan that should make us Icaros users happier. First of all, I found on DOpus 5 website a link to a newer version (a nightly build of v5.92 from 2016), which should be more polished and advanced than the one (v5.91) currently included in Icaros Desktop. I'm testing it right now without pain, so it should be good for 'production'. This was, indeed, a good time for two little changes I was thinking about for a while.
I do not care that you prefer your choice, you can do what you like to but do not try to make the other options look bad to promote your favorite. Because then I will heavily hold against it. It is of course Deadwoods decision what he supports. If it is Wanderer based on your descriptions then be it. Then I have the advantage to have more time to spend on other things ;). I will not do anything based on Wanderer. It makes no sense to me. Again I currently test Scalos on Win Hosted X86. Icons are shown very fast. And even if it would be a little slower compared to wanderer, it includes tons of options to configure it how f.e. icons are shown. Wanderer has nothing to offer in comparation.
-
Then why don't you make a side-by-side comparison of Wanderer and Scalos, to show the pros and cons / issues of each one?
Engineers like DATA. FACTs. In order to make an evaluation.
-
Ha Ha
Icaros Desktop IS Magellan for a long time. Do your job
There is no need to respond like this. On this path everybody looses.
-
Hi,
Being 2/3 done on my January list, I wanted to give you a bit more info on two concrete things I'm planning and a bit longer-term horizon.
Concrete planned items:
1) Release new version of ABIv0 refreshed to common codebase from around 2019-03-01 (Today we are on 2018-04-23)
2) Port Scalos to AxRuntime so that it can become Linux desktop manager
On a longer horizon, there will be a lot of work related to ABIv0 and AxRuntime. I want to update ABIv0 to be based on latest ABIv11 source code. This will be an enabler to having a version of AxRuntime that is capable of running ABIv0 32-bit programs on top of Linux.
Once all these things are in place, we will have a Linux-native desktop (Scalos) and ability to run AROS ABIv0 programs (32-bit), AROS ABIv11 programs (64-bit) and AxRuntime-recompiled programs (64-bit). This way existing Distros could be re-created using Linux as a base without loosing existing functionality for users, enabling a gradual migration from 32-bit to 64-bit.
It's a lot of work. If you are interested in helping out in any of these topics or just writing code for AROS, please let me know!
Yes, it's a lot of work because your goals are ambitious. But it doesn't look incredibly hard.
Let's see if, at the end of this path, we can finally see AROS 64-bit in a good shape, too.
-
Ha Ha
Icaros Desktop IS Magellan for a long time. Do your job
There is no need to respond like this. On this path everybody looses.
Sorry Deadwood
I was only a little nerved because he himself not uses Icaros Desktop obviously but try to convince me that I am wrong.
Decide what you think. I have written my view and let it there...
-
@All
My request is about information and facts comparing both desktops. The goal, for me personally, is to be able to run this desktop as a replacement of what i'm currently using under Linux Mint. So the comparison bar for me is not "better than Workbench", but "slightly worse than Caja" (Linux Mint file browser). I know what Wanderer can do from "insides", but probably I'm missing information on what it can be configured for. On the other hand I have no experience with Scalos and will have to evaluate it from grounds up - so comments on what I should look for are also welcomed.
-
BTW cool that also ABI0 aros apps will run on it. So we finally really will be able to mix Linux and any aros app or component on one platform. That (together with Scalos) will certainly make some cool things possible...
You have to consider that each AROS application running on / launched from AxRuntime has a completely separated process where it's running.
So, interaction with other AROS applications isn't possible: each one is completely independent from the other ones.
-
@All
My request is about information and facts comparing both desktops. The goal, for me personally, is to be able to run this desktop as a replacement of what i'm currently using under Linux Mint. So the comparison bar for me is not "better than Workbench", but "slightly worse than Caja" (Linux Mint file browser). I know what Wanderer can do from "insides", but probably I'm missing information on what it can be configured for. On the other hand I have no experience with Scalos and will have to evaluate it from grounds up - so comments on what I should look for are also welcomed.
I am currently working on a Win Hosted ABI0 distribution with Scalos. It is WIP of course but it is working and perhaps good enough to play around with it. Scalos has preferences with lots of options. I could upload it if you are interested
-
BTW cool that also ABI0 aros apps will run on it. So we finally really will be able to mix Linux and any aros app or component on one platform. That (together with Scalos) will certainly make some cool things possible...
You have to consider that each AROS application running on / launched from AxRuntime has a completely separated process where it's running.
So, interaction with other AROS applications isn't possible: each one is completely independent from the other ones.
from security point of view that is nice but at least some interaction should be possible like using Arexx ports or clipboard
-
BTW cool that also ABI0 aros apps will run on it. So we finally really will be able to mix Linux and any aros app or component on one platform. That (together with Scalos) will certainly make some cool things possible...
You have to consider that each AROS application running on / launched from AxRuntime has a completely separated process where it's running.
So, interaction with other AROS applications isn't possible: each one is completely independent from the other ones.
from security point of view that is nice but at least some interaction should be possible like using Arexx ports or clipboard
Clipboard will be shared, like it is shared between Linux applications. Arexx might be more tricky an need some hacks, but I think I will try to add it - after all Arexx is one of the "Amiga" things.
-
@All
My request is about information and facts comparing both desktops. The goal, for me personally, is to be able to run this desktop as a replacement of what i'm currently using under Linux Mint. So the comparison bar for me is not "better than Workbench", but "slightly worse than Caja" (Linux Mint file browser). I know what Wanderer can do from "insides", but probably I'm missing information on what it can be configured for. On the other hand I have no experience with Scalos and will have to evaluate it from grounds up - so comments on what I should look for are also welcomed.
I am currently working on a Win Hosted ABI0 distribution with Scalos. It is WIP of course but it is working and perhaps good enough to play around with it. Scalos has preferences with lots of options. I could upload it if you are interested
Yes. Please share it when you have it working. There is no rush though - working on point 1) from my list will take 1-2 months.
-
@OlafS3
I know Icaros very well, I have used Icaros for many years and dialogued many times with my friend Paolone also on Italian forums.
As said I will redo the tests and list all the anomalies of Scalos both on x86 and 68k, I will also make comparison videos to prove what I say, which I always do scrupulously.
Regarding Dopus5 I know all the versions even the Windows ones and I have used all of them even on OS3 and Windows
Finally, it is one thing to talk about software and another thing to judge people; I have never judged people, which you do, and not the first time.
-
Let's see when the primadonnas decided to open a proper thread and continue there their quarrels...
-
cdimauro, we are not prima donnas, i simply expressed my thoughts, for me the discussion ends here there will be no more of my interventions on these things
-
Yes. Please share it when you have it working. There is no rush though - working on point 1) from my list will take 1-2 months.
Thank you Deadwood
-
As said I will redo the tests and list all the anomalies of Scalos both on x86 and 68k, I will also make comparison videos to prove what I say, which I always do scrupulously.
Thank you!
-
Excellent and thank you!
Well done deadw00d :)
-
Deadwood I hope (but I'm not the only one) in a future not too far in an Odyssey update, however at the moment it is still usable thanks to your work, some sites are not reachable but it takes patience :)
-
Deadwood does everything possible I know it's a dream possible update
-
With ABIv0 release being done and even squezing some code porting/synchronization and fixes, time has come to refresh the plan:
1) Port Scalos to AxRuntime so that it can become Linux desktop manager
There are no further concrete actions planned at this time. This is due to uncertaity of above-mentioned work. Once I have a better visibility on progress, I will be able to plan further.
The long term horizon remains unchanged:
"On a longer horizon, there will be a lot of work related to ABIv0 and AxRuntime. I want to update ABIv0 to be based on latest ABIv11 source code. This will be an enabler to having a version of AxRuntime that is capable of running ABIv0 32-bit programs on top of Linux.
Once all these things are in place, we will have a Linux-native desktop (Scalos) and ability to run AROS ABIv0 programs (32-bit), AROS ABIv11 programs (64-bit) and AxRuntime-recompiled programs (64-bit). This way existing Distros could be re-created using Linux as a base without loosing existing functionality for users, enabling a gradual migration from 32-bit to 64-bit."
-
Sounds great Deadwood :)
-
Sounds excellent :)
-
the plan:
1) Port Scalos to AxRuntime so that it can become Linux desktop manager
...
we will have a Linux-native desktop (Scalos)
scalos as a native linux desktop ?! that sounds _very_ interesting !
would there be a part of the plan to have linux apps to export their menus to scalos menu bar too ?
kde, xfce and gnome are now able to have apps exporting their menus to a global menu bar.
it would be wonderful if that could be tweaked to work with scalos menu bar too.
i wish you best of luck with this plan, i'll be definitively looking forward to it.
a request:
for future endeavors can i suggest dopus5 too ? it's opensourced now..
dopus5 is the crown jewel of desktops (all systems confunded, even to this day)
and its listers are the best file manager experience i have ever seen on any system.
that being said, even though my all times favourite is dopus5,
having scalos on linux would be de-facto my desktop of choice.
do it, do it naow, we need it for yesterday.
-
would there be a part of the plan to have linux apps to export their menus to scalos menu bar too ?
kde, xfce and gnome are now able to have apps exporting their menus to a global menu bar.
it would be wonderful if that could be tweaked to work with scalos menu bar too.
If that is possible for linux-native desktops, than it will also be possible for Scalos, if first I succede with making it a native linux desktop.
do it, do it naow, we need it for yesterday.
True
-
this might be seen as a bit of a negative post but, here i share anyway
.. it is constructive criticism:
i hope you can keep scalos to be looking like .. scalos.
because quite frankly the way aros desktop turned up to be is an absolute horror.
the base look for aros was amigaos 3.1. stock default amigaos 3.1.
the user have to customise himself on his own.
this was nice and good.
aros made such a mess of UI elements, it broke consistency, you have gadgets of inconsistent height and look. you have the abominable, appaling , space wasting, gorilla icons.
you have disgusting window decoration themes. aros desktop look is _terrible_ i cannot underline this enough. it's as ugly as amigaos was beautiful.
that is to say: i consider amiga very good looking, and aros, very, very, ugly.
i attach a picture of a more sane looking scalos, that try to look normal.
it tries, but there is still many problems.
i marked them on the screenshot as an example.
if scalos is made to look like aros default destop, i wouldn't touch it with even a 10foot pole ;)
-
I agree with you on the gorilla icons, hate them!
Is it time to change the default to those used in icaros?
As for the window's.. I like the quirky retro look :)
My 2c :)
-
thanks for sharing.
to me even icaros looks bad.
i wouldn't be satisfied until aros could be made to look 1:1 with stock default amigaos 3.1.
there could be predefined themes, bundled with aros, ready to be applied, for convenience.
but default look and feel should absolutely be aos3.1.
if user want to customise, fine let him customise. but default is aos3.1
-
AROS can set it as you want even as a 3.1 OS, AROS was born as the evolution of Amiga i.e. a modern Amiga, and on an RTG screen using 3.1 screens is downgrading as well as ugly to see.
That is why I created my distribution AROS One (you should try it), just to have something modern that could not disfigure against modern OSes, which many users liked.
Regarding Scalos or Magellan , like Ambient on MOS I never liked it, having one program that handles everything is not the Amiga folosophy, the Workbench like Wanderer with its many Apps for each prefs in my opinion is the best choice as well as staying in the Amiga philosophy.
-
i went to see some screenshot of your distro.
to each his own but, for me, this is exactly the opposite of what i like.
for me, perfection is:
- rtg screen 16+k color,
- mui 3.8,
- magicwb icons,
- dopus5.
- no docks... i use custom menus (toolsdaemon style).
done. perfection.
see attached picture. (the wallpaper is not important here)
this is the natural look of amigaos.
if scalos looks like that on linux, then i have a new fav desktop coming.
if not, i'll continue working with amiwm. (https://github.com/nsklaus/amiwm)
-
Everyone has his own taste and it should be respected, I have I have almost all Amiga models and used all Amiga OSs, in the early 90s all Amighisti dreamed of something modern and advanced, Amiga has always been ahead, now instead I see that you row backwards.
This was my Amiga 4000 that I had already modernized 1990s
https://www.youtube.com/watch?v=pp8jtdIVQiw
This is my Magic Workbench 3.0, 1990s systema on Floppy HD
https://youtu.be/GfRB65MJnZw
This instead thanks to WinIAE is my OS Amiga 3.9 AfA One
https://www.youtube.com/watch?v=lXyV1PvkNvo
This and an old version of mine from AROS One x8e
https://www.youtube.com/watch?v=Fc8WAjouEBI
Here are some more of my screenshots:
https://ae.amigalife.org/index.php?topic=945.msg11900#new
-
@nsklaus, @AMIGASYSTEM
Please move the discussion on your preferences with regards to look & feel to a separate thread.
-
With ABIv0 release being done and even squezing some code porting/synchronization and fixes, time has come to refresh the plan:
1) Port Scalos to AxRuntime so that it can become Linux desktop manager
Hi All,
A short update from me. After a lot of work has been put into Scalos in July, I took a break in August to focus on some private topics. September also look like they will take majority of my time, so progress on the developer plan is expected to be slow this month.
-
No Problem Deadwood. Thanks for your work in the past and I already look forward to the next steps
-
deadwood don't worry you have already done so much, take all the time you need for your personal life.
-
Gotta do what you gotta do You come first, we'll be right here
-
@deadwood
No problem. We all need to take care of matters other than AROS development.
I have been away doing house repairs and building a storage shed for a couple weeks also.
-
Hi all,
With latest progress on Scalos on Linux, I'm now able to provide a more concrete development plan for coming months:
1) Proof of concept of Scalos providing a Linux desktop environment [IN PROGRESS]
2) Release new version of ABIv0 refreshed to newer common codebase
3) Enable most functionalities of Scalos under Linux
With experience working on Scalos, I split the initial one large item into two, more manageable. The goal is that by the time point 3) is finished, Scalos on Linux will have comparable functionality to Scalos on m68k, ABIv0 and ABIv11.
The long term horizon remains unchanged:
"On a longer horizon, there will be a lot of work related to ABIv0 and AxRuntime. I want to update ABIv0 to be based on latest ABIv11 source code. This will be an enabler to having a version of AxRuntime that is capable of running ABIv0 32-bit programs on top of Linux.
Once all these things are in place, we will have a Linux-native desktop (Scalos) and ability to run AROS ABIv0 programs (32-bit), AROS ABIv11 programs (64-bit) and AxRuntime-recompiled programs (64-bit). This way existing Distros could be re-created using Linux as a base without loosing existing functionality for users, enabling a gradual migration from 32-bit to 64-bit."
-
Thanks deadwood, you are doing a great job.
Creating a Distro with a Linux base for AROS x86, is more complicated for inexperienced Linux users like me, besides the difficulty of creating an ISO with Aros Included, or the inability to do user support.
Also to be considered is the heaviness and slowness of the native Linux system compared to Native AROS, which is super fast and runs even on old PCs.
In addition, the merger of the Linux plus the AROS data would result in a huge ISO of about 8GB
-
I understand deadwood thank you for all ;)
-
Hi all,
With latest progress on Scalos on Linux, I'm now able to provide a more concrete development plan for coming months:
1) Proof of concept of Scalos providing a Linux desktop environment [IN PROGRESS]
2) Release new version of ABIv0 refreshed to newer common codebase
3) Enable most functionalities of Scalos under Linux
With experience working on Scalos, I split the initial one large item into two, more manageable. The goal is that by the time point 3) is finished, Scalos on Linux will have comparable functionality to Scalos on m68k, ABIv0 and ABIv11.
The long term horizon remains unchanged:
"On a longer horizon, there will be a lot of work related to ABIv0 and AxRuntime. I want to update ABIv0 to be based on latest ABIv11 source code. This will be an enabler to having a version of AxRuntime that is capable of running ABIv0 32-bit programs on top of Linux.
Once all these things are in place, we will have a Linux-native desktop (Scalos) and ability to run AROS ABIv0 programs (32-bit), AROS ABIv11 programs (64-bit) and AxRuntime-recompiled programs (64-bit). This way existing Distros could be re-created using Linux as a base without loosing existing functionality for users, enabling a gradual migration from 32-bit to 64-bit."
I am interested in doing a distro in future too. If I understand it right you have to choose a existing distribution and then you develope a desktop (scalos) upon it. So I think easiest would be to say f.e. user should download and install f.e. Mint and then download and install my own additions (that rely on MINT)?
-
Mint and then download and install my own additions (that rely on MINT)?
You have to install "Linux Mint 21", with other Linux Distros it seems not to work, initially I had tried "LMDE" and Scalos did not work (unsupported executable).
-
This is exiting Deadwood!
You are for sure on the right path. With that kind of config. there will be no excuse for anything.
Looking forward to follow the progress.
-
But will there be no migration regarding native Aros? It's a great Axruntime project but there are those who want to use native AROS also :-\
-
Also for me AROS has to walk on its own legs, if I have to use Linux, I use Linux directly, if there is no development on native AROS, probably the development of AROS One will stop !
-
But currently there will be no migration to x64 so all the software that comes out will also work for native AROS
-
The native 32-bit AROS (ABIv0) will continue being maintained by me as described in the "long term horizon" section.
I don't plan on working on 64-bit native version. I know in the past Kalamatee worked a lot on 64-bit native version. Neil also seems interested in it.
-
ok deadwood :)
-
The native 32-bit AROS (ABIv0) will continue being maintained by me as described in the "long term horizon" section.
Thank you deadwood for the confirmation, otherwise there would be no point in carrying on AROS One, thanks to you AROS One has grown notevlly, work much aprreciated by many users.
-
The native 32-bit AROS (ABIv0) will continue being maintained by me as described in the "long term horizon" section.
I don't plan on working on 64-bit native version. I know in the past Kalamatee worked a lot on 64-bit native version. Neil also seems interested in it.
Yes when abiv0 will be aligned to abiv11 there will be the possibility to use some Hollywood plugins I plan to collaborate for some software thanks deadwood
-
Hi all,
With availability of beta of Intuition (window manager), I now consider the POC phase complete. This means I will start moving to second objective - a refreshed release of ABIv0. I will inform you separately what will be the target freshness of common codebase to which we well be upgrading.
1) Proof of concept of Scalos providing a Linux desktop environment [DONE]
2) Release new version of ABIv0 refreshed to newer common codebase [IN PROGRESS]
3) Enable most functionalities of Scalos under Linux
The long term horizon remains unchanged:
"On a longer horizon, there will be a lot of work related to ABIv0 and AxRuntime. I want to update ABIv0 to be based on latest ABIv11 source code. This will be an enabler to having a version of AxRuntime that is capable of running ABIv0 32-bit programs on top of Linux.
Once all these things are in place, we will have a Linux-native desktop (Scalos) and ability to run AROS ABIv0 programs (32-bit), AROS ABIv11 programs (64-bit) and AxRuntime-recompiled programs (64-bit). This way existing Distros could be re-created using Linux as a base without loosing existing functionality for users, enabling a gradual migration from 32-bit to 64-bit."
-
Thanks deadwood, you are doing a great and great job, I am looking forward to the ABIv0 upgrade.
Regarding the Linux base, as already mentioned not being a linux expert, I would not feel comfortable, and I would not be able to offer the support to the users in case of problems with the Operating System.
-
@Deadwood thank you attemp new release of abiv0 :)
-
Deadwood I told Andreas Falkenhahn about the new release of aros abiv0 and its hollywood plugins he replied like this
"Show me some code on how to manually initialize and deinitialize the C++17 (or better)
runtime in a project linked with -nostartfiles and loaded via LoadSeg(). C++ exception
handling must also work in that project! If that is possible on AROS, I can provide
builds of the plugins..."
Thank you in advance
-
I'll take that into account
-
ok thank you
All Best Deadwood
-
Deadwood Alfred Faust could bring a software on AROS only that there is a problem with the interface midi devices usb you should compile the driver that is in native assembly for 68k you could do something the software is an advanced midi sequencer
alfred wrote:
If you can have a look at the 68k-camd-driver (the bridge between Poseidons camdusbmidi.class and the CAMD-System)
I attach it here.
NB.: here is the text at the top of the source to the camdusbmidi.class
/*
*----------------------------------------------------------------------------
* camdusbmidi class for poseidon
*----------------------------------------------------------------------------
* By Chris Hodges <chrisly@platon42.de>
*/
/* TODO: Somebody needs to port the assembly 68k camd driver to something that is used under AROS! */
-
It's unlikely I will look into that.
-
okay thanks
-
Hi all,
With the release of ABIv0 20201110-2 its now time to refresh development plan for next couple of months.
Previous plan:
1) Proof of concept of Scalos providing a Linux desktop environment [DONE]
2) Release new version of ABIv0 refreshed to newer common codebase [DONE]
3) Enable most functionalities of Scalos under Linux
Current plan:
1) Synchronize code bases between repositories and release new version of ABIv11
2) Release first stable version of IntuitionWM
3) Release new version of ABIv0 refreshed to newer common codebase
As you can see the work on Scalos under Linux has been pushed out of current planning. There are two reasons:
1) At this point I'm not sure myself if I'd personally use Scalos under Linux instead of native Linux desktop manager. The plan is first to start using IntuitionWM and then decide
2) There is an uptick of activity in AROS which means getting ABIv0 to the same code level as ABIv11 is becoming more urgent. Not having these code bases synchronized is going to generate more cost down the road.
The long term horizon remains unchanged, however there are notable additions:
"On a longer horizon, there will be a lot of work related to ABIv0 and AxRuntime. I want to update ABIv0 to be based on latest ABIv11 source code. This will be an enabler to:
1) develop a version of AxRuntime that is capable of running ABIv0 32-bit programs on top of Linux and
2) develop an emulator that will allow running AROS 32-bit programs under 64-bit AROS.
Once all these things are in place, we will have a Linux-native desktop (Scalos) and ability to run AROS ABIv0 programs (32-bit), AROS ABIv11 programs (64-bit) and AxRuntime-recompiled programs (64-bit). This way existing Distros could be re-created using Linux as a base without loosing existing functionality for users, enabling a gradual migration from 32-bit to 64-bit.
For people preferring native AROS we will also have ability to use ~80% of the existing software base on 64-bit AROS, which then is an enabler to transition to 64-bit base system."
-
@Deadwood
thanks
we all appreciate what you are doing
-
Thanks Deadwood I am glad that the native mode and ABIv0, will have substantial updates
-
Once all these things are in place, we will have a Linux-native desktop (Scalos) and ability to run AROS ABIv0 programs (32-bit), AROS ABIv11 programs (64-bit) and AxRuntime-recompiled programs (64-bit). This way existing Distros could be re-created using Linux as a base without loosing existing functionality for users, enabling a gradual migration from 32-bit to 64-bit. For people preferring native AROS we will also have ability to use ~80% of the existing software base on 64-bit AROS, which then is an enabler to transition to 64-bit base system."
I like this plan, although I am not sue I'll have the skills to port Icaros to Linux.
-
Once all these things are in place, we will have a Linux-native desktop (Scalos) and ability to run AROS ABIv0 programs (32-bit), AROS ABIv11 programs (64-bit) and AxRuntime-recompiled programs (64-bit). This way existing Distros could be re-created using Linux as a base without loosing existing functionality for users, enabling a gradual migration from 32-bit to 64-bit. For people preferring native AROS we will also have ability to use ~80% of the existing software base on 64-bit AROS, which then is an enabler to transition to 64-bit base system."
I like this plan, although I am not sue I'll have the skills to port Icaros to Linux.
the idea is as I understand it you can mix aros and linux as you can do with amiga 68k and aros 68k based on scalos as linux desktop
-
To manage a Linux-based Distribution, you must know Linux, otherwise you will not be able to help and assist users !
I for one know little Linux and as a result I could not manage a Linux based distribution.
-
To manage a Linux-based Distribution, you must know Linux, otherwise you will not be able to help and assist users !
I for one know little Linux and as a result I could not manage a Linux based distribution.
I know barely anything about Linux. It's a major pain for me to use Linux. I would use it reluctantly. :-\
I do prefer AROS Hosted on Linux though. It allows me to use the Linux File Manager to quickly move files around. Other Linux tools are helpful too such as Scintilla for text.
-
Yes it is a convenience Linux Hosted, but even more convenient and faster Windows Hosted.
I agree with your statement, I never used linux because it is an operating system I don't like, too many permissions and too many obstructions.
I preferred Windows because it is more similar to Amiga and because I worked and managed the computers and software in my Company, I was a Fire Department Chief, done for 40 years, the last 10 years I managed the Computer Network and all Gestinal software.
Translated with www.DeepL.com/Translator (free version)
-
thanks deadwood attemp the new x64 native build and more software
-
"On a longer horizon, there will be a lot of work related to ABIv0 and AxRuntime. I want to update ABIv0 to be based on latest ABIv11 source code. This will be an enabler to having a version of AxRuntime that is capable of running ABIv0 32-bit programs on top of Linux as well as an enabler for having an emulator that will allow running AROS 32-bit programs under 64-bit AROS.
The last part is not clear (to me): do you refer to the possibility, given by using Linux as the "base" o.s., to run any kind of executable, or is it really possible to run AROS 32-bit executables under a (native) 64-bit AROS distro?
-
On Axruntime you can run applications abiv0, abiv11 and compiled for Linux
-
"On a longer horizon, there will be a lot of work related to ABIv0 and AxRuntime. I want to update ABIv0 to be based on latest ABIv11 source code. This will be an enabler to having a version of AxRuntime that is capable of running ABIv0 32-bit programs on top of Linux as well as an enabler for having an emulator that will allow running AROS 32-bit programs under 64-bit AROS.
The last part is not clear (to me): do you refer to the possibility, given by using Linux as the "base" o.s., to run any kind of executable, or is it really possible to run AROS 32-bit executables under a (native) 64-bit AROS distro?
It's both actually. I edited the initial post to make this more explicit.
-
"On a longer horizon, there will be a lot of work related to ABIv0 and AxRuntime. I want to update ABIv0 to be based on latest ABIv11 source code. This will be an enabler to having a version of AxRuntime that is capable of running ABIv0 32-bit programs on top of Linux as well as an enabler for having an emulator that will allow running AROS 32-bit programs under 64-bit AROS.
The last part is not clear (to me): do you refer to the possibility, given by using Linux as the "base" o.s., to run any kind of executable, or is it really possible to run AROS 32-bit executables under a (native) 64-bit AROS distro?
It's both actually. I edited the initial post to make this more explicit.
Thanks.
However I wonder how it could be possible, since the interaction between AROS 32-bit apps and the 64-bit o.s. should be problematic (at least) or impossible (e.g.: AllocMem giving 64-bit pointers to 32-bit apps). Same for 32-bit apps with 64 apps (message ports..). And also patching the o.s. (SetFunction).
Looking forward for your solution.
-
However I wonder how it could be possible, since the interaction between AROS 32-bit apps and the 64-bit o.s. should be problematic (at least) or impossible (e.g.: AllocMem giving 64-bit pointers to 32-bit apps). Same for 32-bit apps with 64 apps (message ports..). And also patching the o.s. (SetFunction).
I see it more in terms of emulator, like AROS hosted AROS. We'll see.
-
OK, then it makes sense and it's certainly doable (something like Janus-UAE, but with AROS x86 running instead of UAE/68K).
-
The 32-bit emulator is a very good idea. I am also looking forward to the Linux distribution that can run native AROS apps.
I have to agree about ScaleOS. I tried it in a more early release you did and I have problems with it. Not my cup of tean.
Great job you are doing here Deadwood.
-
The 32-bit emulator is a very good idea. I am also looking forward to the Linux distribution that can run native AROS apps.
I have to agree about ScaleOS. I tried it in a more early release you did and I have problems with it. Not my cup of tean.
Great job you are doing here Deadwood.
I do not share this view. Scalos is nice if you understand it. Basically you can do almost everything you can do with Magellan. It is much more configurable than wanderer but a lot more amiga-like as Magellan. The only problem currently it has some shortcomings, expecially regarding icon management and shortcuts not work at the moment,. But not impossible to solve. But as I understanf it Deadwood currently sees no priority in it and is no longer sure about it so I stop supporting it too for now.
-
I am sure you are right. ScalOS can be nice when you get used to it and when it is working 100%
What can be a little dangerous with Linux integration is if it becomes to much Linux.
As Amiga users we would like to see RAM disk and for most some kind of DOpus file management.
-
Developers prefer Linux, while common users prefer the native version, Scalos like Magellan, in my opinion will never be able to coexist with Wanderer, a mixed Os will never be perfectly compatible with all software, compared to a native OS.
-
Developers prefer Linux, while common users prefer the native version, Scalos like Magellan, in my opinion will never be able to coexist with Wanderer, a mixed Os will never be perfectly compatible with all software, compared to a native OS.
You do NOT need that Magellan or Scalos must be started after Wanderer
do not tell such a nonsense
you do not need a mixed OS
And why should software not run from Scalos or Magellan when it runs from Wanderer. Wanderer, Scalos and Magellan are desktops and not the OS
-
Wanderer is not just the Desktop, all the AROS system Apps are connected in some way to wanderer, see themes, see wallpapers, Icons and much altrom you use Maggellan, but underneath there is always something that belongs to the native Workbench (Wanderer)
-
I am sure you are right. ScalOS can be nice when you get used to it and when it is working 100%
What can be a little dangerous with Linux integration is if it becomes to much Linux.
As Amiga users we would like to see RAM disk and for most some kind of DOpus file management.
Please ignore Amigasystems noice and negativity...
Scalos was designed as a 100% workbench replacement whereas Magellan was designed as a modern desktop at its time but not as a pure amiga solution. So there are differences. For example filetype deifinition is easier on Magellan to me, on Scalos you get similar results but it is more complicated to understand. On the other hand you have lots of configuration options and (correct configured) it would look and feel 100% like workbench including menu and shortcuts. Of course it must be tested and 100% bugrfree and all working before. I read the old threads about scalos on different forums. Activity was around 2002-2006 and it was commercial. The problem was in my view too few developers tried to do too much at the same time. There was not only Scalos running on Amiga (68k) but also Scalos on 4.X and MorphOS. Finally it nowhere worked perfectly and they gave up (instead of concentrating on one platform and then starting the next). Typical for many amiga project who were "almost there".
-
Wanderer is not just the Desktop, all the AROS system Apps are connected in some way to wanderer, see themes, see wallpapers, Icons and much altrom you use Maggellan, but underneath there is always something that belongs to the native Workbench (Wanderer)
Themes work on Magellan, and Scallos. there is only two additional options in window that not existed on Wanderer (you mentioned that). For icons i use PeteK icons, on Icaros desktop also Magellan is used and certainly as replacement and not as addon. The rest of the prefs are the prefs from aros. No difference there. Software runs on the desktop or not, but not because of the desktop.
BTW Themes work perfectly on Scalos. Only on Magellan you see something using it simply because there are buttons added that not exist on wanderer. Magellsn uses its own system for windows.
-
I'm not against Scalos, I'm against mix systems, It's not a negativity it's a fact, all this was also found on OS3 !
Wrong to say AROS preferences, it is correct to say Workbench preferences (Wanderer)
-
I'm not against Scalos, I'm against mix systems, It's not a negativity it's a fact, all this was also found on OS3 !
sorry I use Magellan a lot longer than you and propably also did more with Scalos than you. You use it in a wired way in my view, do not use it as real replacements but only as addon, as another option to wanderer. Here we discuss using scalos or magellan as full replacements. That IS difference
-
I have known Magellan since the first version came out, about Peterk icons, read about magellan incompatibilities here:
https://eab.abime.net/showthread.php?t=64079&page=202&highlight=iconlib
On my A4000 I was also using Magellan and Scalos
https://www.youtube.com/watch?v=RIt6XcGoeJo
-
I have known Magellan since the first version came out, about Peterk icons, read about magellan incompatibilities here:
https://eab.abime.net/showthread.php?t=64079&page=202&highlight=iconlib
I use and develop my distribution for many years now, much longer than you. If you try to lecture me it becomes complicated. I like your distribution but I do not like it if you spread such nonsense from my point of view. Nikos now knows that your negative view is not standard and shared by everyone and we let it by that. At the moment Deadwood obviously is concentrating on different tasks and Scalos is not completed at the moment. If he perhaps start on it again I can show Nikos (or others who might interested) my experiences. Until that we do not need tp continue this nevrving discussions you started from day one when Deadwood said he would prefer scalos.
-
@Deadwood
I hope you help to fix Scalos on Aros even if you decide not to port it to linux. It is a very good desktop potentially becoming interesting for more users because near to woekbench but at the same time more sophisticated.
-
@Deadwood
I hope you help to fix Scalos on Aros even if you decide not to port it to linux. It is a very good desktop potentially becoming interesting for more users because near to woekbench but at the same time more sophisticated.
I don't know the answer to this question yet.
-
@Deadwood
I hope you help to fix Scalos on Aros even if you decide not to port it to linux. It is a very good desktop potentially becoming interesting for more users because near to woekbench but at the same time more sophisticated.
I don't know the answer to this question yet.
ok i understand
-
Olaf, everyone is free to express his opinion, I just said it is my opinion, that means it is debatable.
How can you say you use Scalos or Magellan before me? I know Magellan and Scalos from the first day they were distributed.
Talking about the themes, you can't say they are supported by Magellan, look at your Aros Vision window (screenshot), one of those gadgets and not only that, this is because there is no function to disable it and it is incompatible with AROS, to get rid of it you have to fix Magellan, for OS3 there is a corrected version of magellan:
Also not if you can use all the gadgets in Themes !
-
@AMIGASYSTEM, @OlafS3
Please take the discussion on Scalos vs Magellan vs Themes to separate thread. It is not related to the topic of this thread.
-
Sorry deadwood !
-
A short update from me on the plan:
1) Synchronize code bases between repositories and release new version of ABIv11 [DONE]
2) Release first stable version of IntuitionWM
3) Release new version of ABIv0 refreshed to newer common codebase
The work on IntuitionWM will mostly likely start somewhere in May.
The long term horizon remains unchanged:
"On a longer horizon, there will be a lot of work related to ABIv0 and AxRuntime. I want to update ABIv0 to be based on latest ABIv11 source code. This will be an enabler to:
1) develop a version of AxRuntime that is capable of running ABIv0 32-bit programs on top of Linux and
2) develop an emulator that will allow running AROS 32-bit programs under 64-bit AROS.
Once all these things are in place, we will have a Linux-native desktop (Scalos) and ability to run AROS ABIv0 programs (32-bit), AROS ABIv11 programs (64-bit) and AxRuntime-recompiled programs (64-bit). This way existing distributions could be re-created using Linux as a base without loosing existing functionality for users, enabling a gradual migration from 32-bit to 64-bit.
For people preferring native AROS we will also have ability to use ~80% of the existing software base on 64-bit AROS, which then is an enabler to transition to 64-bit base system."
-
deadwood
This seems like a very detailed plan for AROS development. And thank you for your hard work and dedication. :)
What is Intuition WM and how can we use it ? Is it based on AxRuntime as well ?
-
@miker1264
You can see it here in action: https://youtu.be/BFKy-8PfWmk?t=60
-
Oh, that's great.
-
Wow! That's really nice features for window management.
With some icon integration between Linux and AROS as far as a consistent theme then one might have the impression of simply running AROS instead of Linux and AROS.
Well done!
-
Thanks to me interested in using native aros is interesting implementation of the emulator on x64 :D
-
Any chance for screen dragging, too? :)
-
Any chance for screen dragging, too? :)
I don't know yet.
-
I just found this topic and read through it. It is a nice roadmap for AROS development.
I noticed some discussion around a Linux distribution. As a long-time Linux user and administrator since I stopped using my Amiga in 1999, I am quite familiar with the OS. I think creating an entire Linux distribution is kind of a lot of work. The effort presented here could be made into some software package for an existing distribution which configures it to behave as closely as possible to how a classic Amiga behaved. Automatic login and running of IntuitionWM is relatively easy.
-
I just found this topic and read through it. It is a nice roadmap for AROS development.
I noticed some discussion around a Linux distribution. As a long-time Linux user and administrator since I stopped using my Amiga in 1999, I am quite familiar with the OS. I think creating an entire Linux distribution is kind of a lot of work. The effort presented here could be made into some software package for an existing distribution which configures it to behave as closely as possible to how a classic Amiga behaved. Automatic login and running of IntuitionWM is relatively easy.
If I would do something with Linux I would plan to do exactly this. I would select a popular and appropriate distribution and would try to create something that sits upon it using a amiga desktop like scalos (if hopefully available) and aros components. The ground work like security patches should come from the linux distribution used as base. Everything else would be too much work and more probpably be like a full-time job
-
Hello,
Due to ArosExec going down in about a month, I moved this thread to arosworld.org. Thread is now locked.
https://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1114