ReAction isn't part of the normal API, it's just a newer library that was added later, and not a whole lot of software used it.
Err, what? Reaction (or classact - that is its historical name) is a collection of boopsi classes that logically extends the already present Os interface. If you look at Os 3.1, then it already shipped with a couple of "reaction classes" aka "boopsi classes", namely the colorwheel.gadget, the tapedeck.gadget and the gradientslider.gadget. The preferences system makes use of them, and includes an additional gadget that was not factored out as a separate class, namely the sketchpad.gadget. The classes that shipped with 3.9 were a logical continuation of this development as it extended the existing classes, made some of the existing classes openly available (such as the sketchpad.gadget) and added new classes that filled in missing functionality. Thus, this was a very logical step that continued the direction in which the Os was going anyhow.
Isn't that pretty much a library vs API? At least that's how I always viewed classes.
AmigaOS really hadn't moved on 20 years ago, while AROS is still being developed.
Eh, what? We are moving on here. The pace is slow, but there is certainly movement. And no, it's not that "we screw 4.x". A lot of development from 4.x is merging into the 3.x line right now, but we need to make sure - and this is the real work - that it is compatible to the existing software basis, avoiding compatibility problems to the highest degree possible, and to make it run at acceptable speed even on low end machines.
The problem I see with AROS and the like is that - unfortunately - quite some software depends on undocumented internal featuers of the Os, and that the line between "official features" and "implementation details" is not very clearly drawn. Consider for example how "Monitor drivers" work (would that stuff work on AROS?) or how a user shell can be launched and written (would that work on AROS?). Whenever you deprecate such (non-)interfaces (probably to the best of the software development, understood) you also break programs depending on it. The willingness to make such steps is quite different, depending on the development goals, and I would assume that AROS has different goals than the 3.x team.
Quite frankly, I do not quite understand what AROS is about, or why one would follow this type of development. After all, AmigaOs is not a very good operating system in first place (see above for some reasons), and *if* I had the motivation to rewrite one, I would certainly not start at AmigaOs. There are better open source architectures, more suitable ones. Either compatibility has priority - but then you need to work with the existing code base - or clean code and clean design has priority - but then AmigaOs is not the right starting point.
[/quote]
Fair, I wasn't talking about the fine and fantastic work you guys have been doing with improving 3.1. It is great and I've bought it for the 500, 4000 and 4000T (even though I don't actually have a 4000T, I have a Toaster Oven 4000....)
I still think a fully open source AmigaOS would be more useful though. Though I do think 3.1 should be open source instead of having to recreate everything from scratch, which is why it's taken AROS so long.
