6 ms·

I think that it also having preemptive multitasking also made a huge difference to make the system responsive and feel fast. The GUI, with its windows and gadge

I think that it also having preemptive multitasking also made a huge difference to make the system responsive and feel fast. The GUI, with its windows and gadgets (= "widgets"/"controls") ran in Intuition's task. The mouse pointer was moved by a vblank interrupt and could thus never lag. On Macintosh, the whole GUI ran practically in the active app's event loop. The whole system could be held up by an app waiting for something. Microsoft made the mistake of copying Apple when they designed MS-Windows. Even this day, on the latest Windows, which although it has had preemptive multitasking since 1995, a slow app can still effectively hold up the user interface thus preventing you from doing anything but wait for it. When Apple in the late '80s wanted to make their OS have preemptive multitasking, they hired the guy who had written Amiga's "exec" kernel: Carl Sassenrath.

jchw 1y ago
> Even this day, on the latest Windows, which although it has had preemptive multitasking since 1995, a slow app can still effectively hold up the user interface thus preventing you from doing anything but wait for it. Could you explain what you mean here? If you were to make your event loop or wndprocs hang indefinitely it would not hang the Windows interface for the rest of the machine, it would just cause ANR behavior and prompt you to kill the program. As far as I can remember it's been that way since at least Windows 2000.
- zozbot234 1y ago
  I think what OP's saying is that on the Amiga it was idiomatic to let the UI be handled by a dedicated thread/task. That was also the norm on other notable systems such as BeOS. It's still a good guideline today but not so easy to apply.
- Findecanor 1y ago
  I mean the windows. An app can open a window and hold it there, and meanwhile you can't move the window, you can't move it to the back and you can't minimise it.
  - jchw 1y ago
    Oh I see. I'm not familiar with the model used by Workbench and how it differs exactly. (edit: and to be clear, I did read the article and see what it said, but without more detail I'm not 100% sure what it really looks like in practice, and why it would be less likely for applications to have situations where they become unresponsive.)
    - orionblastar 1y ago
      Amiga computers are expensive these days, you are better off with an Amiga Emulator like Amiga Forever. I remember the Amiga had the checkered beach ball bouncing demo and others copied it, then on the Amiga they opened up several copies of the demo all multitasking and bouncing at the same time. The only downside of the Amiga was the dreaded Guru Meditation Errors when memory went corrupt or something. IIRC AmigaDOS/Workbench had no protected memory features.
      - zozbot234 1y ago
        > IIRC AmigaDOS/Workbench had no protected memory features. This was a limitation of the original MC68k CPU architecture. Though the Amiga operating system was indeed designed to leverage a single address space throughout, which made it significantly harder to retrofit memory protection after the fact.
- flohofwoe 1y ago
  An example I run into almost each day: run a non-trivial build in Visual Studio which consumes all available CPU cores. Now try to use the trackpad to scroll some random window content, it just doesn't work, at best you get a UI view that jumps around instead of smooth scrolling. AFAIK Windows is supposed to boost the CPU priority of the UI during user input, but apparently that doesn't work. AmigaOS also boosted the CPU priority of the UI during mouse movement, except it actually worked. PS: and instead of fixing the issue from the ground up in the OS (which admittedly is probably impossible) the VS team instead added a feature called 'Low Priority Builds': [1] https://developercommunity.visualstudio.com/t/Limit-CPU-usage-of-Visual-Studio-during/436208 https://developercommunity.visualstudio.com/t/Limit-CPU-usag...) [2] https://devblogs.microsoft.com/cppblog/msbuild-low-priority-builds-in-visual-studio/ https://devblogs.microsoft.com/cppblog/msbuild-low-priority-...

jchw 1y ago

> Even this day, on the latest Windows, which although it has had preemptive multitasking since 1995, a slow app can still effectively hold up the user interface thus preventing you from doing anything but wait for it. Could you explain what you mean here? If you were to make your event loop or wndprocs hang indefinitely it would not hang the Windows interface for the rest of the machine, it would just cause ANR behavior and prompt you to kill the program. As far as I can remember it's been that way since at least Windows 2000.

zozbot234 1y ago
I think what OP's saying is that on the Amiga it was idiomatic to let the UI be handled by a dedicated thread/task. That was also the norm on other notable systems such as BeOS. It's still a good guideline today but not so easy to apply.
Findecanor 1y ago
I mean the windows. An app can open a window and hold it there, and meanwhile you can't move the window, you can't move it to the back and you can't minimise it.
- jchw 1y ago
  Oh I see. I'm not familiar with the model used by Workbench and how it differs exactly. (edit: and to be clear, I did read the article and see what it said, but without more detail I'm not 100% sure what it really looks like in practice, and why it would be less likely for applications to have situations where they become unresponsive.)
  - orionblastar 1y ago
    Amiga computers are expensive these days, you are better off with an Amiga Emulator like Amiga Forever. I remember the Amiga had the checkered beach ball bouncing demo and others copied it, then on the Amiga they opened up several copies of the demo all multitasking and bouncing at the same time. The only downside of the Amiga was the dreaded Guru Meditation Errors when memory went corrupt or something. IIRC AmigaDOS/Workbench had no protected memory features.
    - zozbot234 1y ago
      > IIRC AmigaDOS/Workbench had no protected memory features. This was a limitation of the original MC68k CPU architecture. Though the Amiga operating system was indeed designed to leverage a single address space throughout, which made it significantly harder to retrofit memory protection after the fact.
flohofwoe 1y ago
An example I run into almost each day: run a non-trivial build in Visual Studio which consumes all available CPU cores. Now try to use the trackpad to scroll some random window content, it just doesn't work, at best you get a UI view that jumps around instead of smooth scrolling. AFAIK Windows is supposed to boost the CPU priority of the UI during user input, but apparently that doesn't work. AmigaOS also boosted the CPU priority of the UI during mouse movement, except it actually worked. PS: and instead of fixing the issue from the ground up in the OS (which admittedly is probably impossible) the VS team instead added a feature called 'Low Priority Builds': [1] https://developercommunity.visualstudio.com/t/Limit-CPU-usage-of-Visual-Studio-during/436208 https://developercommunity.visualstudio.com/t/Limit-CPU-usag...) [2] https://devblogs.microsoft.com/cppblog/msbuild-low-priority-builds-in-visual-studio/ https://devblogs.microsoft.com/cppblog/msbuild-low-priority-...