11 ms·

A general purpose operating system. As a business graphical OS it was lovely to develop for. It made sense with a delightful conciseness that Windows and X coul

A general purpose operating system. As a business graphical OS it was lovely to develop for. It made sense with a delightful conciseness that Windows and X could only dream of. Executables of equivalent capability could, quite literally, be an order of magnitude smaller. There were few warts - AmigaDOS because of the BCPL roots as it was an extremely last minute addition when the planned CAOS never materialised, and icons were a pain to work with. Thirty years of working on other things and I still believe they got 95% just so. The plug and play of Win 95 was pathetic compared to AutoConfig (IIRC what it was called), in Zorro 1. MFM and IDE hard drives compared to SCSI on its own DMA channel etc etc. Stuff that took decades to arrive on Win. As for a reboot - I can imagine an Amiga like OS experience on several platforms, but hardware? I find it difficult to even imagine how something could have the quantum leap that Amiga was compared to everything else on the market under $50k.

derefr 7y ago
Are there any architectural features from AmigaOS (whether kernel components, syscall ABI, or OS libraries) that would be an improvement even compared to today's OSes? Or: if one were building a hobbyist OS today, what would be the key takeaways to pull from AmigaOS?
- hansjorg 7y ago
  See this excellent answer by vidarh to the same question in 2015: https://news.ycombinator.com/item?id=9935892 https://news.ycombinator.com/item?id=9935892 Highlights: * DataTypes * file system assigns * AREXX scripting of many/most programs
  - NeedMoreTea 7y ago
    Excellent answer. To which I'll add: IFF standards. In today's world it would be an unthinkably open approach taken by open source only. Even more surprising it came from a joint venture between Commodore Amiga and EA! Every single graphics program understood, and via datatypes understood in a standard way, IFF graphics. Saving, processing or reading. They were so prevalent and expected that you would be hurting your chances to release something with a propriety only format. Same went for sound and no end of other things. Had the Amiga thrived there'd no doubt have been an IFF in place of many of the multimedia formats. With a standard OS level library call to decode them, etc. The conciseness of approach, necessary in a system providing proper multi-tasking in 256K, meant all the services other platforms placed at least partially in the .exe were usually in the OS. There were system libraries you could rely on without the absurd version dependent dll hell of windows. I'm sure had the Amiga persisted there'd be some version annoyance, but I can't imagine it reaching the stupidity of now. Windows had far more than glue code in the exe. If you needed to use a file requester, accept messages, have a window that could be resized etc there was tons of unique OS related code in the exe for all that etc etc. Update the OS and unless you update the source and rebuild the exe it will clearly and obviously be of the previous Windows release. Or as was so often the case buy the latest office and the look is clearly of the next, unreleased Windows. Amiga had it such that all that rubbish was nearly all external. Set up your structures, call the API, get woken up when there's something you need to care about. If you updated OS, all your window chrome, file requesters etc, would be of the new OS. No ridiculous dependencies on v 3.2.152 of MSVC.dll, and 3.3.x not being acceptable, meaning you end up with 12 different installed versions etc. Only apps doing something clever - like CygnusEd with its hand written assembler scrolling that remains, 30 years later, my benchmark for "fast and smooth enough" editor scrolling. Essentially nothing has yet matched it, though Sublime is probably closest just without smooth scrolling. It was really difficult to come to accept - in some sense I still haven't - that I had to do so much of this OS housekeeping for myself each and every time, in every application for other platforms. I often used to wonder what Windows was, in fact, adding as it always seemed like I was doing everything myself. I gave up complete on Windows programming pretty quickly as a result. :) AmigaDOS may have been a bit of a last minute, ugly addon, but in use it felt like a lightweight single user *nix. Proper filenames, priorities, comments, proper scripting and ARexx if you needed additional integration. Sure, it was far happier on a HDD, but what aside from DOS - more a program loader than OS - wasn't? :)
    - vidarh 7y ago
      IFF actually lives on thanks to Microsoft and IBM in large part. RIFF is basically a little endian IFF,and used for AVI, wav and Webp among others. What hasn't lived on, of course is a concerted push for an ecosystem around tools for working with the underlying container format instead of the specific formats. This is what made the biggest difference in the Amiga: to a great extent when coming up with a storage format,the question was increasingly "which IFF chunk types are suitable" rather than a question of designing a format from scratch.
      - derefr 7y ago
        PNG is a very similar format to IFF, though for some reason, despite have essentially the same needs and despite the PNG working group being aware of IFF, they chose to be incompatible with IFF. Nerdier trivia: Erlang's BEAM VM emits compiled bytecode files in an IFF format. (Which is a strange choice, honestly, since they could have easily chosen to use a purpose-made executable-binary container format like ELF, which would have made .beam files more amenable to analysis using standard compiler toolchain tools.)
        vidarh 7y ago
        Didn't know that about Erlang. Reason is probably that ELF wasn't that widespread until the late 90s. When I started using Linux around 94, a.out was still common. It took several more years for ELF to become dominant.
      - LocalH 7y ago
        Don't forget about AIFF, as well as Maya's variant of IFF.
      - rasz 7y ago
        and AT&T, DjVu ebook format is IFF based.
    - squarefoot 7y ago
      " ... like CygnusEd with its hand written assembler scrolling that remains, 30 years later, my benchmark for "fast and smooth enough" editor scrolling. Essentially nothing has yet matched it ..." Here it is: https://www.youtube.com/watch?v=L41oIvre9K0 https://www.youtube.com/watch?v=L41oIvre9K0 For those who never used CED on an Amiga, this is how it ran on now 30 years old hardware clocked at 8 MHz.
  - vidarh 7y ago
    It's always fun when my old comments get dug up... Actually recently I've started thinking about what it would take to create a toolchain to do the minimum to provide the pieces of AROS (for the uninitiated: AmigaOS "reimplementation" though it goes beyond the original in some respects) that might make sense on Linux and provide a compatibility layer to make it work. AROS itself can run hosted on Linux, but not integrated well with Linux apps, but quite a lot of AROS relies on relatively small subsets of the AmigaOS API, and it'd be a fun experiment to e.g. bring data types to Linux, possibly combined with a fuse filesystem as a fallback to do on the fly conversions for apps with no support. I'd love to see if some of those things could gain traction if suitably modernized.
    - jacobush 7y ago
      I am thinking about what would make something revolutionary today. The only, but very important thing I can think of is that software today has no time constraints. All interfaces feel sluggish at some point. What if we could make an OS with constraints, or an app store with a vetting process, or both complementing each other, to the effect that: A widget pressed or touched or interacted with could always be trusted to respond in time - or fail in an understandable manner. - No launching screens on touch interfaces suddenly being sluggish. - No waiting for apps to download and install and can not be used during that time. (Solved by having updates installed quietly in the background.) - No stutter or slowdowns, ever, no audio lags, ever. the main thing should be that what you are interacting with must never feel like it's sluggish, no more than the water flowing out of a faucet starts to lag or freeze/unfreeze suddenly. The interface should feel so solid and "real", that if it stuttered you would be so shocked as if a thrown ball in real life stuttered in mid air. Possible means : Give GUI code very high priority. This will have to involve putting some intelligence in GUI code, or the interface will appear to be unresponsive or do strange things when underlying IO or network is being slow. : Focus on determinism and time budgets, not raw performance throughput : Vetting of applications : Constrain apps to hard RAM budgets : IO budgets for apps? : Have apps allocate and bid for network performance and available bandwidth I have a feeling much of this would not need a ground up rewrite. Probably Android or Linux could be used as a basis for such a system.
- tombert 7y ago
  Well "improvement" is a bit of a loaded word, but AmigaOS's exec kernel was a microkernel, and one of the few to pull it off without many problems. Compared to Linux's monolithic, or Windows/Apple's hybrid Mach thing, it's actually something that's still a bit uncommon. It's still experimental, but RedoxOS is really the only newish OS that I know of that does the Microkernel design.
- basementcat 7y ago
  I would argue that a major defining characteristic of AmigaOS was that it ran in the same flat address space and privilege level as the applications. As a result, message passing is lighting fast (just pass a pointer) and applications can easily obtain direct access to hardware. This has obvious downsides as well— unstable app takes down whole system, no security whatsoever.
  - joncrane 7y ago
    Yikes! Would never fly today, I don't think.
    - basementcat 7y ago
      A similar architecture is used in embedded operating systems like some versions of vxWorks! And RTEMS.
  - NeedMoreTea 7y ago
    Hardware memory protection only came into being with, IIRC the 68030 - Edit: though available as separate coprocessor 68851 chip for 020. Early Windows was no different, limited memory protection first came with the 286, wasn't it? BSOD just as often, instead of Guru meditation - at least a guru let you into a remote debugger. :) Without that it wasn't hard or unexpected for an unstable app to take down the system. Used to happen reasonably frequently on 68000 Unix systems. Certainly for every time that happened you might expect a couple of caught core dumps, but before hardware protection it was still wing and a prayer...
    - davedx 7y ago
      Think it was the 386 that first had protected mode...
      - jacobush 7y ago
        286 had too but no common OS used it. Too limited
- 13of40 7y ago
  I remember telling my computer science teacher how the floppy disk file system worked (a directory was a linked list of sectors, each one of which represented the head of a file, IIRC) and he refused to believe anyone would implement it like that due to the obvious perf issues.
  - sedatk 7y ago
    Yeah, that was a terrible idea and was later dropped with FFS.
    - vidarh 7y ago
      The ease with which you could drop in new filesystem drivers is another one of those things that was great. Aside from the official FFS there's been a number of other filesystems even long after Commodore went under.
    - NeedMoreTea 7y ago
      A terrible idea because they were backed into a corner. Had the third party producing CAOS delivered, there would have been no need for an insane timescale port of Tripos to become AmigaDOS. Then floppies wouldn't have got OFS which was a HDD filesystem hacked to fit in as little time as possible. dos.library would have escaped the horrible BCPL mucking about with BSTRs and BPTRs too.
- sedatk 7y ago
  The ability to run fast and smooth on a 7Mhz processor.
  - jacobush 7y ago
    It's insane. All these 80s computers have silly fast response times, which put all modern machines to shame. But, since arguably the Amiga is the only computer with a modern GUI and being super responsive, it really points out the absurdity of everything modern when you feel it. It can't be gleaned from youtube videos, either. You must hold that damn old mouse in your hand and click something or drag a window. To the brain, there's zero latency. NOTHING. You ARE the computer. (I think that is one reason why it's so addictive, it's one of the truly cybernetic devices. My modern Mac comes close, but not quite. Scrolling on some phone apps come close.)

derefr 7y ago

Are there any architectural features from AmigaOS (whether kernel components, syscall ABI, or OS libraries) that would be an improvement even compared to today's OSes? Or: if one were building a hobbyist OS today, what would be the key takeaways to pull from AmigaOS?

hansjorg 7y ago
See this excellent answer by vidarh to the same question in 2015: https://news.ycombinator.com/item?id=9935892 https://news.ycombinator.com/item?id=9935892 Highlights: * DataTypes * file system assigns * AREXX scripting of many/most programs
- NeedMoreTea 7y ago
  Excellent answer. To which I'll add: IFF standards. In today's world it would be an unthinkably open approach taken by open source only. Even more surprising it came from a joint venture between Commodore Amiga and EA! Every single graphics program understood, and via datatypes understood in a standard way, IFF graphics. Saving, processing or reading. They were so prevalent and expected that you would be hurting your chances to release something with a propriety only format. Same went for sound and no end of other things. Had the Amiga thrived there'd no doubt have been an IFF in place of many of the multimedia formats. With a standard OS level library call to decode them, etc. The conciseness of approach, necessary in a system providing proper multi-tasking in 256K, meant all the services other platforms placed at least partially in the .exe were usually in the OS. There were system libraries you could rely on without the absurd version dependent dll hell of windows. I'm sure had the Amiga persisted there'd be some version annoyance, but I can't imagine it reaching the stupidity of now. Windows had far more than glue code in the exe. If you needed to use a file requester, accept messages, have a window that could be resized etc there was tons of unique OS related code in the exe for all that etc etc. Update the OS and unless you update the source and rebuild the exe it will clearly and obviously be of the previous Windows release. Or as was so often the case buy the latest office and the look is clearly of the next, unreleased Windows. Amiga had it such that all that rubbish was nearly all external. Set up your structures, call the API, get woken up when there's something you need to care about. If you updated OS, all your window chrome, file requesters etc, would be of the new OS. No ridiculous dependencies on v 3.2.152 of MSVC.dll, and 3.3.x not being acceptable, meaning you end up with 12 different installed versions etc. Only apps doing something clever - like CygnusEd with its hand written assembler scrolling that remains, 30 years later, my benchmark for "fast and smooth enough" editor scrolling. Essentially nothing has yet matched it, though Sublime is probably closest just without smooth scrolling. It was really difficult to come to accept - in some sense I still haven't - that I had to do so much of this OS housekeeping for myself each and every time, in every application for other platforms. I often used to wonder what Windows was, in fact, adding as it always seemed like I was doing everything myself. I gave up complete on Windows programming pretty quickly as a result. :) AmigaDOS may have been a bit of a last minute, ugly addon, but in use it felt like a lightweight single user *nix. Proper filenames, priorities, comments, proper scripting and ARexx if you needed additional integration. Sure, it was far happier on a HDD, but what aside from DOS - more a program loader than OS - wasn't? :)
  - vidarh 7y ago
    IFF actually lives on thanks to Microsoft and IBM in large part. RIFF is basically a little endian IFF,and used for AVI, wav and Webp among others. What hasn't lived on, of course is a concerted push for an ecosystem around tools for working with the underlying container format instead of the specific formats. This is what made the biggest difference in the Amiga: to a great extent when coming up with a storage format,the question was increasingly "which IFF chunk types are suitable" rather than a question of designing a format from scratch.
    - derefr 7y ago
      PNG is a very similar format to IFF, though for some reason, despite have essentially the same needs and despite the PNG working group being aware of IFF, they chose to be incompatible with IFF. Nerdier trivia: Erlang's BEAM VM emits compiled bytecode files in an IFF format. (Which is a strange choice, honestly, since they could have easily chosen to use a purpose-made executable-binary container format like ELF, which would have made .beam files more amenable to analysis using standard compiler toolchain tools.)
      - vidarh 7y ago
        Didn't know that about Erlang. Reason is probably that ELF wasn't that widespread until the late 90s. When I started using Linux around 94, a.out was still common. It took several more years for ELF to become dominant.
    - LocalH 7y ago
      Don't forget about AIFF, as well as Maya's variant of IFF.
    - rasz 7y ago
      and AT&T, DjVu ebook format is IFF based.
  - squarefoot 7y ago
    " ... like CygnusEd with its hand written assembler scrolling that remains, 30 years later, my benchmark for "fast and smooth enough" editor scrolling. Essentially nothing has yet matched it ..." Here it is: https://www.youtube.com/watch?v=L41oIvre9K0 https://www.youtube.com/watch?v=L41oIvre9K0 For those who never used CED on an Amiga, this is how it ran on now 30 years old hardware clocked at 8 MHz.
- vidarh 7y ago
  It's always fun when my old comments get dug up... Actually recently I've started thinking about what it would take to create a toolchain to do the minimum to provide the pieces of AROS (for the uninitiated: AmigaOS "reimplementation" though it goes beyond the original in some respects) that might make sense on Linux and provide a compatibility layer to make it work. AROS itself can run hosted on Linux, but not integrated well with Linux apps, but quite a lot of AROS relies on relatively small subsets of the AmigaOS API, and it'd be a fun experiment to e.g. bring data types to Linux, possibly combined with a fuse filesystem as a fallback to do on the fly conversions for apps with no support. I'd love to see if some of those things could gain traction if suitably modernized.
  - jacobush 7y ago
    I am thinking about what would make something revolutionary today. The only, but very important thing I can think of is that software today has no time constraints. All interfaces feel sluggish at some point. What if we could make an OS with constraints, or an app store with a vetting process, or both complementing each other, to the effect that: A widget pressed or touched or interacted with could always be trusted to respond in time - or fail in an understandable manner. - No launching screens on touch interfaces suddenly being sluggish. - No waiting for apps to download and install and can not be used during that time. (Solved by having updates installed quietly in the background.) - No stutter or slowdowns, ever, no audio lags, ever. the main thing should be that what you are interacting with must never feel like it's sluggish, no more than the water flowing out of a faucet starts to lag or freeze/unfreeze suddenly. The interface should feel so solid and "real", that if it stuttered you would be so shocked as if a thrown ball in real life stuttered in mid air. Possible means : Give GUI code very high priority. This will have to involve putting some intelligence in GUI code, or the interface will appear to be unresponsive or do strange things when underlying IO or network is being slow. : Focus on determinism and time budgets, not raw performance throughput : Vetting of applications : Constrain apps to hard RAM budgets : IO budgets for apps? : Have apps allocate and bid for network performance and available bandwidth I have a feeling much of this would not need a ground up rewrite. Probably Android or Linux could be used as a basis for such a system.
tombert 7y ago
Well "improvement" is a bit of a loaded word, but AmigaOS's exec kernel was a microkernel, and one of the few to pull it off without many problems. Compared to Linux's monolithic, or Windows/Apple's hybrid Mach thing, it's actually something that's still a bit uncommon. It's still experimental, but RedoxOS is really the only newish OS that I know of that does the Microkernel design.
basementcat 7y ago
I would argue that a major defining characteristic of AmigaOS was that it ran in the same flat address space and privilege level as the applications. As a result, message passing is lighting fast (just pass a pointer) and applications can easily obtain direct access to hardware. This has obvious downsides as well— unstable app takes down whole system, no security whatsoever.
- joncrane 7y ago
  Yikes! Would never fly today, I don't think.
  - basementcat 7y ago
    A similar architecture is used in embedded operating systems like some versions of vxWorks! And RTEMS.
- NeedMoreTea 7y ago
  Hardware memory protection only came into being with, IIRC the 68030 - Edit: though available as separate coprocessor 68851 chip for 020. Early Windows was no different, limited memory protection first came with the 286, wasn't it? BSOD just as often, instead of Guru meditation - at least a guru let you into a remote debugger. :) Without that it wasn't hard or unexpected for an unstable app to take down the system. Used to happen reasonably frequently on 68000 Unix systems. Certainly for every time that happened you might expect a couple of caught core dumps, but before hardware protection it was still wing and a prayer...
  - davedx 7y ago
    Think it was the 386 that first had protected mode...
    - jacobush 7y ago
      286 had too but no common OS used it. Too limited
13of40 7y ago
I remember telling my computer science teacher how the floppy disk file system worked (a directory was a linked list of sectors, each one of which represented the head of a file, IIRC) and he refused to believe anyone would implement it like that due to the obvious perf issues.
- sedatk 7y ago
  Yeah, that was a terrible idea and was later dropped with FFS.
  - vidarh 7y ago
    The ease with which you could drop in new filesystem drivers is another one of those things that was great. Aside from the official FFS there's been a number of other filesystems even long after Commodore went under.
  - NeedMoreTea 7y ago
    A terrible idea because they were backed into a corner. Had the third party producing CAOS delivered, there would have been no need for an insane timescale port of Tripos to become AmigaDOS. Then floppies wouldn't have got OFS which was a HDD filesystem hacked to fit in as little time as possible. dos.library would have escaped the horrible BCPL mucking about with BSTRs and BPTRs too.
sedatk 7y ago
The ability to run fast and smooth on a 7Mhz processor.
- jacobush 7y ago
  It's insane. All these 80s computers have silly fast response times, which put all modern machines to shame. But, since arguably the Amiga is the only computer with a modern GUI and being super responsive, it really points out the absurdity of everything modern when you feel it. It can't be gleaned from youtube videos, either. You must hold that damn old mouse in your hand and click something or drag a window. To the brain, there's zero latency. NOTHING. You ARE the computer. (I think that is one reason why it's so addictive, it's one of the truly cybernetic devices. My modern Mac comes close, but not quite. Scrolling on some phone apps come close.)