AROS World Exec
Development => Development (General) => Topic started by: ENBphant on February 19, 2021, 08:03:14 AM
-
Heyo, new here. Gathering intel for an OS project of my own, maybe the most ambitious thing ever, probably beyond my skills, but who knows.
Looking to take inspiration primarily from Plan 9 and AROS, as they look like the coolest projects around. Issue is, AROS doesn't seem to be, um, documented. The user experience, sure, but the internals specs are drafts at best and outright missing at worst. I'm falling back to Amiga docs for now, as they're more complete, but I'm worried I'll miss some new things from AROS (I know portability and hosted operation in particular were not focuses of the original Amiga). I'm the kind of person who likes to know everything before starting out, rather than fumbling around and half-reinventing a lot of things in convoluted and inefficient ways.
So, what are the most significant new concepts of AROS over Amiga, and where are they documented, if at all? (Ancillary: which concepts from Amiga are rendered obsolete by AROS' innovations?) I'm looking for mechanisms and implementations, rather than APIs, as my goal for now is to understand rather than use.
-
Have you visited this site?
https://aros.sourceforge.io/
-
AROS is in many ways Amiga-like as in it's directory structure but it departs from Amiga in some ways.
The windowing system is Intuition based on Amiga but Graphics drivers are hidds and filesystems are handlers.
IcarosDesktop uses Dual-state PNG icons where Amiga used Legacy IFF Icons. There are many improved Libraries in AROS. Cybergraphics handle drawing better and faster.
-
Issue is, AROS doesn't seem to be, um, documented. The user experience, sure, but the internals specs are drafts at best and outright missing at worst.
I guess that can be experienced as being the case.
In origin AROS follow the same basics as amigaOS did with regards to DOS, Graphics, intuition, gadtools etc. so you can indeed use Amiga documentation (for example RKRM's) for that.
I'm falling back to Amiga docs for now, as they're more complete, but I'm worried I'll miss some new things from AROS (I know portability and hosted operation in particular were not focuses of the original Amiga).
As user Miker also wrote, a new concept is for example the hardware independent device drivers (hidds), but also teh upgrade from intuition to MUI and AHI for audio (both things that Amiga originally not started out with having). Perhaps you are able to get something out of reading https://en.wikibooks.org/wiki/Aros/Developer/Docs (https://en.wikibooks.org/wiki/Aros/Developer/Docs) as well.
I'm the kind of person who likes to know everything before starting out, rather than fumbling around and half-reinventing a lot of things in convoluted and inefficient ways.
Well, then you are in luck..... AROS is completely open source and the source-code is freely available (so you can actually check everything out into detail... and beforehand) ;)
So, what are the most significant new concepts of AROS over Amiga, and where are they documented, if at all? (Ancillary: which concepts from Amiga are rendered obsolete by AROS' innovations?) I'm looking for mechanisms and implementations, rather than APIs, as my goal for now is to understand rather than use.
From my point of view there isn't actually anything obsolete except perhaps for the hardware banging. But you can do that anyhows when running AROS on original Amiga (compatible) Hardware (although also there it is advised to not to peek in & poke to the hardware registers directly)
Besides that some other new concepts had to be implemented such as miker also wrote such as cybergraphics but for example also trident USB stack. We also have tlsf memory management, support for other modern hardware concepts such as pci/usb/acpi/etc and of course also some modern software/drivers were ported such as mesa/nouveau. But from a simple software developer point of view you only have to deal with such things directly when you have a particular need for it (so it might interest you in case you are doing OS development).
If you look at the abiv1 development then a new concept is for example smp to support multiple cores/threads and there were some discussions with regards to memory protection but for example also integrated legacy emulation. Not all of the latter mentioned discussions ended up being actually implemented/supported though. Some of these things are idea's or concepts that where discussed. Sometimes a developer feels the need to make a proof of concept to see if it is actually possible (that is how smp support started out for example), and if it is deemed successful then ends up in the actual source-tree.
But, in case you wish to know more then i would advise you to pick the brain of one of the AROS system developers (they usually do not come around here and hang around @ slack-eroo)
-
All quiet at Slack channels lately. Developers are taking a Siesta. 8)
Well, there is one lone developer on the Slack channels experimenting with things, and of course @deadwood hangs out here fixing things like HDAudio and updating the 32bit sources.
Developers are curious cats. :) They are always peeking and poking and breaking things just so they can later come back and fix it again. It keeps things interesting.
-
All quiet at Slack channels lately. Developers are taking a Siesta. 8)
Ah, that is very unfortunate. Sorry that i did not know, i don't do closed-source....
Well, there is one lone developer on the Slack channels experimenting with things, and of course @deadwood hangs out here fixing things like HDAudio and updating the 32bit sources.
Crapperoo. Indeed deadw00d does hang around here. My bad, sorry.
Developers are curious cats. :)
Ask Mazze :P (although that looks more like a hungry cat)
They are always peeking and poking and breaking things just so they can later come back and fix it again. It keeps things interesting.
Besides that. What else is one to do during this pandemic ? Work@home, curfew@21:00, no public transport unless required, no alcohol allowed after 20:00, all stores are closed (except shops that sell food), no schools, no visitors allowed except one/day etc. etc. You can only wink at your spouse so many times before even that get's boring.
Seriously derailing a source-tree and see what happens even sounds like fun ... even when you need to fix later on ... wait ... did i not have a git account somewhere :back laterz: :P
-
Issue is, AROS doesn't seem to be, um, documented. The user experience, sure, but the internals specs are drafts at best and outright missing at worst.
I guess that can be experienced as being the case.
Yes, this is how it is experienced. There are bits of AROS that have been documented somewhere, but there is no single medi-ary that documents all of AROS, and therefore nowhere is everything kept up-to-date.
In this vain: AROS used to be non-Amigaic in having AROS dos as a device. This was quite the departure, and at some point it was shifted to an AROS dos-library, or something like that. But being able to access dos as a device was a neat approach. Has this been lost in the shift, or is there still a device approach to do this?
-
Mysha if you may be interested there are also important siyi for AROS:
https://www.arosworld.org/
https://axrt.org/downloads-aros
https://aros.sourceforge.io/
http://archives.aros-exec.org/
-
Thank you for the reaction. But can I get a reply in long hand?
-
In this vain: AROS used to be non-Amigaic in having AROS dos as a device. This was quite the departure, and at some point it was shifted to an AROS dos-library, or something like that. But being able to access dos as a device was a neat approach. Has this been lost in the shift, or is there still a device approach to do this?
I don't know how it was historically, but currently DOS is a library.
Also if you have any development questions or bug reports please post them (preferably on arosworld.org).
-
Yes, this is how it is experienced. There are bits of AROS that have been documented somewhere, but there is no single medi-ary that documents all of AROS, and therefore nowhere is everything kept up-to-date.
Developer's time is limited and usually they are destined to write detailed information on internals. Rather than spend (read: waste) time on that the source-code is available for those that really want to know.
Let alone, keeping things up to date... Unfortunately it is what it is.
In this vain: AROS used to be non-Amigaic in having AROS dos as a device. This was quite the departure, and at some point it was shifted to an AROS dos-library, or something like that. But being able to access dos as a device was a neat approach. Has this been lost in the shift, or is there still a device approach to do this?
I am not quite sure if I understood what you wrote there. That means that either it was a feature before my time or perhaps you got some things mixed up (or it is me that is confused :) ).
I am mostly confused by the part "access dos as a device". Did you mean accessing physical hardware as a device (using its device driver) ?
-
In this vain: AROS used to be non-Amigaic in having AROS dos as a device. This was quite the departure, and at some point it was shifted to an AROS dos-library, or something like that. But being able to access dos as a device was a neat approach. Has this been lost in the shift, or is there still a device approach to do this?
I don't know how it was historically, but currently DOS is a library.
Yes, I know we currently have DOS as a library. But people put a lot of effort in the code for DOS as a device, in the past. Does the march of history mean that DOS as a device is now lost altogether? Or is the code for DOS as a device still somewhere in a historical archive section? (I wouldn't know: I don't know how GIT works, Hence I don't know whether moving to it has deleted access to historical SVG(?) versions.)
Also if you have any development questions or bug reports please post them (preferably on arosworld.org).
OK, at <http://www.aros.org/>, we link to AROS EXEC at AmgaLife, but obviously we're not there now. I don't see an AROS Website forum, though. So though I tried to report that, I don't know whether I sent is somewhere where people will act upon it.
-
Yes, this is how it is experienced. There are bits of AROS that have been documented somewhere, but there is no single medi-ary that documents all of AROS, and therefore nowhere is everything kept up-to-date.
Developer's time is limited and usually they are destined to write detailed information on internals. Rather than spend (read: waste) time on that the source-code is available for those that really want to know.
Yes, but see it from the other side: Developers can't be bothered to actually document, even comment, their code. As a result, entry into AROS is complicated. The one person who does know, doesn't spend good time on documenting, and thus EVERY other person, who doesn't know, has to spend bad time on excavating.
If only there was a single location, designated to be the entry point for all things AROS: An AROS Reference Manual if you will. It wouldn't immediately solve everything, but at least if information wasn't there, there would be a demonstrable need for that particular part of documentation.
In this vain: AROS used to be non-Amigaic in having AROS dos as a device. This was quite the departure, and at some point it was shifted to an AROS dos-library, or something like that. But being able to access dos as a device was a neat approach. Has this been lost in the shift, or is there still a device approach to do this?
I am not quite sure if I understood what you wrote there. That means that either it was a feature before my time or perhaps you got some things mixed up (or it is me that is confused :) ).
I am mostly confused by the part "access dos as a device". Did you mean accessing physical hardware as a device (using its device driver) ?
To the best of my knowledge, it was before your time, yes. DOS as a library is actually a rather ugly duckling. It only quacks that way because of the Amiga legacy. Thus, at first, we had AROS DOS as a device, just like it was originally intended. Eventually, it was decided not to break compatibility with Amiga OS over that, and go to a library. (I don't know why; I wasn't there at that time).
What I am asking, is whether this resulted in a two-pronged approach, with the As a Device pronge probably laying dormant at the moment. Or whether that development was lost altogether.
-
Does the march of history mean that DOS as a device is now lost altogether? Or is the code for DOS as a device still somewhere in a historical archive section? (I wouldn't know: I don't know how GIT works, Hence I don't know whether moving to it has deleted access to historical SVG(?) versions.)
All the historical versions have been preserved when moved to GIT, so yes, also any previous versions of DOS are available in repository if someone wanted to reuse them.
-
All the historical versions have been preserved when moved to GIT, so yes, also any previous versions of DOS are available in repository if someone wanted to reuse them.
OK, that is good to hear. Of course, I have no idea whether it would be relevant in the current state of AROS. But it would provide an incentive to be human. ... Is there an AROSgit to get out a Buddhist version of AROS?
-
@Mysha:I think I am beginning to understand what you are referring to... you meant dos as a device as it was when AmigaOS started out as tripos ?
Also note that AROS is (or at least suppose/intends to be) 100% API compatible with AmigaOS 3.x, therfore the same RKRM's can be used to develop for AROS. The thing that is new however is hidd devices which is an abstraction layer between hardware OS..
Having said that the RKRM's will ofc. tell you nothing about how things are actually implemented/structured in AROS.
-
@Mysha:I think I am beginning to understand what you are referring to... you meant dos as a device as it was when AmigaOS started out as tripos ?
I guess, but here were talking about the early days of AROS (by today's standards). Sure, Amiga had taken DOS as a library as a quick solution. But AROS was not going to make that same mistake; it had instead implemented DOS as a device, as it should be. The advantage was obvious: AROS didn't need anything special for DOS. I expect the disadvantage was also obvious: For AROS to behave like ADOS it needed constant exceptions to behave more like a library.
At some point while I wasn't there - being fed up with all the errors accepted as normal - AROS was switched to DOS as a library. After that, no more talk about DOS as a device, but I can't help but feel we lost something, there.
Also note that AROS is (or at least suppose/intends to be) 100% API compatible with AmigaOS 3.x, therfore the same RKRM's can be used to develop for AROS. The thing that is new however is hidd devices which is an abstraction layer between hardware OS..
Yes, but even apart from the hidds, we have plenty details that are different. For one thing, by law we can't copy the AROS manuals. For another, the history revealed in the manuals is often different, and with it comes a different set of example programs. Also, the tools we developed, and which should be described, are often different because they stress other aspects.
Having said that the RKRM's will ofc. tell you nothing about how things are actually implemented/structured in AROS.
There is that.
If we continue with this, do we have a moderator who can spilt this sub-thread off from its parent? I don't think we're on-topic any more.
-
If we continue with this, do we have a moderator who can spilt this sub-thread off from its parent? I don't think we're on-topic any more.
We do have a moderator but it is mostly self-moderation as the main AROS discussion forum is now located at https://arosworld.org
As long as it isn't going completely off-topic and into flame wars we are good to go, unless you prefer to split things up. In case the latter then it is probably a good idea to pm admin (as afaik he is currently the only moderator)