[vidarh]

I have used AmigaOS and "descendants" like AROS many times in recent years, so I'm not just looking at this with rose-tinted nostalgia. In fact, I've contributed code to AROS.

And yes, there are still awesome things about it.

I've pointed out here before, for example, that I can booth AmigaOS or AROS on modern hardware (either under an emulator in the case of AmigaOS, or the Linux hosted version in the case of AROS) and have it boot straight into a text editor, and that whole process starts faster than Emacs on my laptop.

And there are still massive amounts of functionality that isn't readily available in mainstream OS's today.

Exactly because attitudes like yours means that lots of developers ignore a lot of the lessons these systems have for us - it's not just the Amiga.

[nirai]

> And there are still massive amounts of functionality that isn't readily available in mainstream OS's today.

Can you specify?

> lots of developers ignore a lot of the lessons these systems have for us

what lessons are you talking about?

[csixty4]

> Can you specify?

One thing that always gets brought up is the datatypes API. I never got to experience it first-hand (as my username suggests, I'm more of a C64 guy). But the idea is that different types of media are handled independent of applications.

So something like Deluxe Paint could load a PNG by asking WarpPNG.datatype to parse the PNG file and return an IFF (the default data format for audio & video on AmigaOS). If it wanted to display the PNG without modifying it, Deluxe Paint could tell WarpPNG.datatype to display the file at (X,Y) at (Width, Height) and it would get rendered without any special code being added to the application.

This future-proofed applications. Imagine if Photoshop, Chrome, Preview, and Pages could all work with webp images as soon as you added a library and it registered itself to handle "pictures".

[vidarh]

> Can you specify?

A few examples:

Datatypes lets most newer Amiga programs load any type of file of a format that people have written datatype libraries for. E.g. all image viewers and editors that supports datatypes (pretty much all the were still under development when datatypes where introduced) can load pretty much any image format you can think of without any explicit application support as people are still writing them. Datatypes support also exists for e.g. music, word processing documents and others. For some applications it makes sense to have their own custom filters for some formats, but datatypes provides a minimum level of support for even obscure formats, as well as continued support for new formats for applications that are no longer in development.

Similarly any app that supports XPK can transparently decompress and compress any compression format you drop a library for into the right directory (and in fact there's a XPK datatype, that if installed lets any application that supports another datatype - such as for images, or documents - support compressed versions of the same).

Assigns is one of my favorites: Amiga applications typically load libraries from "libs:". "Libs:" is a virtual directory that is the union of a set of paths that typically includes "progdir:libs/" (but doesn't have to). "progdir:" again is a virtual directory that refers to the directory the application is installed in. It's somewhat like $PATH, except you can create your own assigns, and lookups are handled at OS level. You can somewhat simulate it on Linux with combinations of various obscure filesystem drivers, but there's nothing like the ease of use of assigns. Assigns are also given special treatment in filesystem dialogs/requesters, which meant that e.g. having a "docs:" and "pics:" assign or similar was common ways of creating shortcuts to the stuff you used the most, without needing any explicit support anywhere.

And these names also extends to volumes/labels of physical media. Think backup application that knows the label of the DVD you burned file X to. Want to restore it? Backup application could ask you to insert DVD labelled "August 2014", or on AmigaOS it would just try to open the file "August2014:X" and AmigaOS will ask you to please insert volume "August2014" with no application support needed. This is admittedly a feature that was far more important when dealing with physical media was more common.

OS support for running controls/widgets (gadgets in AmigaOS) in separate threads ensures a high degree of responsiveness even when the machine is under high load.

Ease of writing filesystem drivers means you find stuff like FrexxEd - a text editor that exposes the open buffers as files, so that you can operate on the open buffers with any tools that can process a file.

Pervasive AREXX support meant pretty much every application can be fully scripted, either "natively" in AREXX, or from pretty much every language by talking to the applications AREXX port.

> what lessons are you talking about?

Decomposing applications and treating the system as a whole, for starters. For AmigaOS this was an absolute necessity: You wouldn't have the space to effectively multitask on a machine with 512KB RAM if everyone needed to pull in huge amounts of different dependencies. So there was a lot more effort into standard components, or replacements for standard components, that allowed applications to do more with very little.

Not being wasteful, certainly. Above I mentioned FrexxEd. The custom filesystem in FrexxEd might seem like unnecessary bloat. But on a small system it meant that you did not have to write to a temporary file in T: which would commonly be assigned to RAM:T/ which would mean you'd suddenly have a second copy of the file in memory, instead of just processing what was already there. Similarly, the way cut and paste is implemented in AmigaOS is intended to be able to deal with efficient buffering to T: in case it has been re-assigned to a slow device (even a harddrive would have been slow enough to make the UI sluggish if you were to cut and paste a large chunk of data).

But the things that made these applications work well on such small machines also makes them blazingly fast on modern machines where UI's are somehow still sluggish even when they don't add much functionality (it's another matter if a super-complex UI is slow)

[nirai]

the apple II, the C64, the mac, the Amiga, and later the PC, the Internet, Windows, Linux and then the IPhone and Android, dozens of other amazing projects, products, technologies and movements (e.g. open source), all revolutionized and transformed our lives or at least had some impact on the history of computing,

but how does an API for handling image formats amount to that today?

isn't it fair to say that the Amiga had its day in the 80s and 90s, and that time is now past?

Or to put it in Mr. Praline famous words: 'E's not pinin'! 'E's passed on! This parrot is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies! 'Is metabolic processes are now 'istory! 'E's off the twig! 'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisible!! THIS IS AN EX-PARROT!!

[SteveMoody73]

Datatypes were a very cool feature, not just a simple API. For an application to be able to support new format be it an image, video, spreadsheet, document or anything the application has to be updated to use a library or to add native support for that format.

Imagine if you could add a Datatype for an image format such as EXR and you would instantly be able to open it in Paint, embed it in Word and Powerpoint without having to update the apps. A DOCX Datatype would allow Wordpad to open Word documents. A new video format on the internet? No need to wait for browser support, just add the Datatype and it would work.

Another advantage of a system like this would be for security. If an serious exploit was found in a popular image decoding library then you could delete the offending Datatype and none of your apps could be exploited until the fault is fixed. May be inconvenient but at least it would be safe. Shared libraries could be used to handle this to an extent but most apps would probably crash if you deleted a required library and who knows if the app is using the shared library or a statically linked version?

There was a few nice features that were in the Amiga operating system but this was one that i wish had been implemented in other operating systems.

[function_seven]

Many of the abstract concepts introduced by the Amiga have not been replicated since. All the amazing things we do today we do by brute force. By throwing more clock speed and storage capacity and memory at the problems. Meanwhile, every application developer has to explicitly write—or include a library for—every format they want to support, every codec they want to be compatible with, etc.

Even with all of our gigahertz and gigabytes, we misty-eyed nostalgics know that it could have been so much better, more elegant.

> isn't it fair to say that the Amiga had its day in the 80s and 90s, and that time is now past?

Yes, it's totally fair to say that. But don't mistake all the love letters people write for the Amiga as irrational pining for "the good ole days". There's real substance there, real things that were lost, as vidarh's comment shows.

[vidarh]

Tomorrow a new image format comes out (like it has many times over the years; consider WEBP for a reasonably new example). None of your applications supports it.

Suddenly you have to update everything before you can use it, and because it's like that for everyone, getting the new format into use is hard.

Except, your apps uses datatypes, so you just download a single datatype library and description, put it into the right directory, and suddenly your browser, your desktop publishing software, your paint program, your word processor, your image viewer all supports the new format and will happily load and/or save images from/to the new format.

Sounds familiar? Probably not, because it doesn't work like that on any modern platform. It did on the Amiga.

That's why datatypes are worth remembering.

As a demonstration of how this helps future-proof software, consider that most commercial Amiga software stopped receiving updates in the mid 90's, many of them before the advent of even png, and certainly before webp and similar. Yet all of the ones that supports datatypes for image access today support png and webp with no changes to the applications needed.

> isn't it fair to say that the Amiga had its day in the 80s and 90s, and that time is now past?

Of course it does, but that doesn't mean these concepts deserve to be forgotten.