AmigaOS 3.2 released!

[shades_aus]

Originally Posted by OlafSch

@shades_aus

as Olaf said AROS inherited the same advantages but also shortcomings of the old AmigaOS. You cannot overcome this without rewriting everything. And I would add... you still would have the same problems any niche OS has... not enough developer, driver and modern software. The idea to port important parts of Aros to a mainstream OS like Linux is much more promising (and that is what Deadwood is already doing).

Future will be in my view:
Aros 68k (including ApolloOS)
Aros X86 (VM and real Hardware X86)
Aros on Linux base (AMD64)

my personal favorites are the 68k branch for the amiga retro market and Aros on Linux

Haiku have branched and re-written most of the original OS into 2 flavours. The 32 bit BeOS program compatible version and the new, non-binary compatible 64 bit version. It's on their website.

[shades_aus]

Originally Posted by Olaf Barthel

BeOS is a creation of the 1990'ies, the Amiga operating system goes way back to around 1984/1985. The decisions which went into creating the respective operating system architectures were guided by what the hardware available at the time permitted, and at which cost.

For example, the contemporaries of the Amiga operating system were the operating systems used by the Apple Lisa and the Apple Macintosh. Both were, in terms of design, using established well-known concepts, such as that you would use a 68000 trap instruction to call an operating system function. RAM was expensive, so these machines had little to use (e.g. 64 KBytes, like a Commodore 64).

Also common at the time was the use of the first few "pages" of the adress space for operating system use, such as (I kid you not) was the case for the Commodore 64 (the "zero page"). The Macintosh operating system had a "zero page" and it took Apple years to wean developers off of its use.

Also "also common" was the use of a single shared address space for everything, code, data you name it. This is what the architecture flavour of the year was, as it was.

Fast forward some 10 years and you get BeOS, which did not use a shared memory space and offered POSIX APIs. It even had a Unix-style monolithic kernel to enable all of this. It could afford that because memory had become much cheaper during the past 10 years and the CPUs (yes: BeOS ran on the AT&T Hobbit, then the PowerPC, then the inevitable Intel offering of the day) had become more powerful and cheaper, too.

Unless a lot has changed since I last looked at AROS, it still shares the same early/mid 1980'ies advantages and limitations in terms of architecture which gave us the Amiga operating system. These lines are very hard to redraw unless you are prepared to abandon every bit of software ever written for the platform.

By comparison, BeOS had it "easier". Small bugs and errors do not bring down the operating system as swiftly as for Amiga OS, owing to memory protection and all those small but important foundational elements which Amiga OS lacks.

Sure, both AROS and Amiga OS still see development and incremental change, but it is much harder to build robust software. This is one of the major, major challenges to overcome in terms of "friction". You have to be exceptionally careful not to knock over something by accident, you have to be prudent to play within the narrow limitations of what is considered "safe" in terms of APIs and data structures.

This is 1980'ies style programming at its most sophisticated. Not everybody is cut out for that kind of task, to put it mildly. Passion will get you somewhere, but it will not get you everywhere and anywhere.

Of course not everyone is experienced enough to work through the challenge, I agree and it's part of the reasons I listed, however, it's not impossible to get there.

BeOS also has 2 different versions. The 32bit BeOS binary compatible version and the 64bit variant. Something "similar" should be considered with AMIGA OS if changes are needed to continue forward. As for memory management, some sort of functional MMU should be incorporated.
At least that way, you open up provision for sandboxing in legacy space if you choose to offer it.

I certainly am not advocating that AMIGA OS doesn't develop further. It needs to transition into something better/more modern and that opportunity, still exists, just like every other OS that's still worked on is doing. No one wants AMIGA OSx.x to NOT develop and stay in the dark ages. IBRowse and Miami were made as extensions to get on the web but now, it's too difficult to get more memory (as a shortcoming example) to remain functional on the Web? Amiga was about doing stuff no one said could be done. Like NewTek and the Toaster.
68k "may" have to be retired, like its parent company Motorolla did.

What was that famous saying about getting to the moon? We choose to do it because it is hard? The Amiga "experience" can be realised outside of emulation however, some tougher decisions are going to need to be made. Mac did, Microsoft did, BeOS/Haiku did...

[Samurai_Crow]

Quick note: the 2 versions of BeOS were PPC and x86. Both were 32-bit. Haiku is a BeOS replacement that spawned a 64-bit variant of x86_64 in addition to x86. I use the 64-bit variant on my tower and it's quite performant. I can't wait for the Radeon drivers.

[kamelito]

And AT&T Hobbit

[ma693541]

All this are Offtopic!!!! Stay Ontopic, AmigaOS 3.2.

[bubbob42]

Indeed. No one is going to fundamentally rewrite AmigaOS. It’s retro. Get over it.

[mfilos]

Quick question.

The GlowIcons that are shipped with OS3.2 are really nice work and while they look awesome on 64-256 colors, they seem a lot pixelated under higher resolutions and RTG screens.
Is there a compilation of these icons made without color degration?

[samo79]

Originally Posted by Olaf Barthel

Plenty

There are now some three months worth of bug fixes, changes and optimizations waiting to see a release. Some of the bugs are so old, they survived almost three decades of development work, performed by four developers, including yours truly. Putting your trust in the last guy to have reviewed the code which his changes were built upon (this includes a previous version of myself, of course) is dangerous.

The usual trouble of buffer overflows was to be expected, but there also was a disheartening number of integer overflows, misuse and misinterpretation of API parameters and not validating the parameters to begin with.

Basic functions such as Read(), Write() and Examine() were subtly broken. Not quite so basic functions such as ExNext(), ExAll(), ChangeMode(), MakeLink(), ReadLink(), SetFileSize(), SameLock(), LockRecord()/LockRecords() worked most of the time only because developers would follow the API documentation. Beyond these limitations, things only worked by a combination of luck and really dumb luck. If neither kind of luck was available, you'd be in for undefined behaviour very quickly.

My personal favourites among the (up until then) undiscovered old bugs involved the use of soft links with file notification, ChangeMode() not working consistently and closing a file always having the same "tragicomic" consequences.

mfilos is likely referring to the combination of soft links and file notification not playing together well, limiting their usefulness to exactly "none whatsoever". I found and fixed that one in November last year.

Because these and other bug fixes continued to move the total ROM space budget into a dangerous direction, size optimizations became necessary. Repeated review & rework of the code uncovered further issues, dead code, etc.

ram-handler is probably the operating system component which occupies the two top spots of importance in the operating system architecture and number of implementation issues.

Mmm these bugs are also present in and affect AmigaOS4?

[Olaf Barthel]

Originally Posted by samo79

Mmm these bugs are also present in and affect AmigaOS4?

I don't believe so. The ram-handler for AmigaOS4 had its own challenges, because, for example, virtual memory support in the operating system. What goes into RAM: should stay in RAM and not get paged out to disk. If you wanted that, you would have put it there already.

As with all the components which came from AmigaOS 68k, rewriting and reimplementation went along with bug fixing. I worked on ram-handler back then, for a long time, among other components.

What the AmigaOS 68k ram-handler did not receive was the kind of top to bottom and back, bottom to top review & rewriting it eventually got. Everybody who worked on ram-handler expected that the code was sufficiently robust as it was and changes were limited to getting things to work properly which were discovered as they appeared. Sadly, the code really needed much more work, but that could be said about the entire AmigaOS 68k operating system back when the work on AmigaOS 3.1.4 started.