What makes the OS for QL any better, different, unique ?

[NormanDunbar]

What ToFro said!

Plus, if you are masochistic enough, you can compile your own Linux Kernel, and choose which scheduler you need/want in the various config options.

Admittedly, I've not done this for a long while, no need, the current Linux scheduler works fine for me. I wouldn't like to build a new kernel for a Raspberry Pi Zero though....


Cheers,
Norm.

[stephen_usher]

Personally, I also liked PSION's BASIC, as found on the S3.

I LOVE MY PSION 5 mx PRO! And the language is not BASIC, it's named OPL (Organizer Programming Language, later renamed to Open Programming Language)

A mobile computer (fits into the inner pocket of a normal jacket) with a much better office than XChange, which operates for about 1 month with 3 AA batteries

And of course a preemptive multitasking OS (written in C++).

I believe OPL was a development of the language used initially in QL Archive.

[RalfR]

I believe OPL was a development of the language used initially in QL Archive.

I have read that elsewhere long years ago, so I think, you are quite right.

[bwinkel67]

And, properly written applications assumed, there shouldn't be any noticable difference from an end-user's perspective between a pre-emptive or cooperative design.

So I thought the same thing regarding "properly written applications" until I started to dig a little deeper into cooperative multitasking again. The idea of properly written ends up being at the perspective of the coder plus how to divide that code up so that it behaves the way one would expect (i.e. as in preemptive) is not trivial. The Moire program, for instance, why on earth wouldn't that just keep going in the background when you open up a text editor. The programmers decided that it would behave this way, versus that way, and it would be hard to call them out saying "you are doing it improperly." So when you give control to the developer and there are thousands of developers with each having a different perspective, the end results seems a bit chaotic.

When I ported my shell environment with scripting language, in retrospect I never realized how difficult it was to actually get an interpreter to behave properly in cooperative multitasking. You'd think (I did as I was recollecting) that it's just about calling GetNextEvent at the top of the loop, but playing around with it under System 7.5, there are plenty of occasions when it takes more time from the OS than expected and things in the background just stall out, or you have to wait for a loop to finish. Sometimes events get out of sequence having been queued up while running in the background and a loop will finish before the keyboard events are then caught. Or how slow a simple sprite animation (Globe) becomes when running in the foreground (or when Moire is running in the foreground). It's just crazy and the Mac was supposed to be the most prolific cooperating multitasking kernel out there that lasted almost 20 years.

I recommend you give it a try with the Mini vMac emulator as it is one that you can slow down to real-time. I was using Basilisk and on my current machine and that thing runs so fast you can't glean anything from it when multiple programs run to see how the OS behaves (though overall it is a better emulator). Side-by-side to the QL, which behaves the way you'd expect, it's just crazy. It definitely didn't meet my idea of how I expected cooperative to work and I thought I properly wrote my shell on the Mac (and as mentioned, it was well received -- reviewed by technical editors from MacUser and MacWorld so I would have thought they would point out if they felt it misbehaved). It's been almost 20 years since I actively used a Mac with System 7.5 and after having gotten used to modern Windows/OS X/Linux it was surprising how much we put up with back then :-/...and of course playing with a QL, when I say that it behaves as expected I guess I mean that it behaves like all the modern OS's currently do which is pretty remarkable for a 48K kernel form 83/84 so kudos to Tony Tebby!

[ql_freak]

I believe OPL was a development of the language used initially in QL Archive.

It's similar as C and C++, they have the same base syntax, but C++ is a totally different language. Archive is a language just for Archive. OPL is a language of it's own, which runs directly under EPOC. OPL is extensible as SuperBASIC, EPOC has a SQL database engine (unfortunately joins are not supported) which can be used from OPL and it has much more command/functions than the Archive language.

[pjw]

Personally, I also liked PSION's BASIC, as found on the S3.

I LOVE MY PSION 5 mx PRO! And the language is not BASIC, it's named OPL (Organizer Programming Language, later renamed to Open Programming Language) <>

Ah yes, OPL was the name. Organiser Programming Language. I believe it was later changed to Open PL, and used on other, non-PSION, devices too. Ok, so it wasnt BASIC, but it belongs to that group of languages, rather than, say, C.

I still have my Series 3 somewhere, but its unusable as the menu buttons packed up after less than a year and I could never get them fixed. Other than that it was well built, and had, to my mind, a perfect form factor. A modern version of the Series 3 would be great! With a fast processor, 600x400 OLED screen, (micro)SD, maybe a SIM card or two, USB,.. and, of course, OPL! Oink!

[bwinkel67]

Since the AmigaOS was the other preemptive OS in the 80's on a microcomputer, I was curious how it compared to QDOS in it's implementation. It seems there is some discussion on whether it was true preemptive or more of a cooperative multitasking kernel (Wiki actually doesn't call it directly a preemptive kernel but one that enabled preemptive multitasking -- kind of weird wording). Linus called it cooperative since a process could take full control if it wanted (either by explicitly disabling the scheduler or by forgetting to release memory which the kernel didn't keep track off), and because the kernel ran in user mode. Of course Linus didn't like any OS's of the day (I think he didn't like that QDOS was in ROM) and we are better off today because of it and Linux.

Not sure about the disabling feature. It could be seen as a good thing since, if you look at modern OS's, the reason that cooperative still exists in systems is the need to be able to a) share the processor but also b) run uninterrupted at times for critical things. So in that scenario preemptive can be harmful, though with process priorities I suppose one could just max out ones priority and have that be a trigger in a preemptive to reduce being swapped out. Although if you really are doing such a critical task I suppose you, as the process, would want to decide and so I can see the need for Forbid/Disable option in AmigaOS having a use. I could also see that never being a good thing for a server platform kernel like Linux.

BTW, what's a good emulator for the Amiga, esp one that can run the older OS's and the Amiga in realtime. I ask because I had this problem on Mac emulators recently. I used Basilisk but there is no way to throttle it down and so I found Mini vMac which allows you to run a particular Mac at its realtime speed.

[tofro]

Linus called it cooperative since a process could take full control if it wanted (either by explicitly disabling the scheduler or by forgetting to release memory which the kernel didn't keep track off), and because the kernel ran in user mode. Of course Linus didn't like any OS's of the day (I think he didn't like that QDOS was in ROM) and we are better off today because of it and Linux.

I don't quite agree with Mr. Thorvalds here, calling a system cooperative just because a task can effectively stop the scheduler is not very valid. You may call it unprotected because of the lack of protective mechanisms in the hardware - But that's mainly a fault of the CPU hardware rather than the system - There's simply no way to inhibit that because the poor old 68000 doesn't have the proper mechanisms.

With the same argument, you could call QDOS cooperative, because every job can use TRAP #0 to go into supervisor mode and effectively block the scheduler.

[ql_freak]

With the same argument, you could call QDOS cooperative, because every job can use TRAP #0 to go into supervisor mode and effectively block the scheduler.

CORRECT!

BTW: I have written a lot of programs, where I have blocked the scheduler. But I have blocked it for about 4 to ten (short, in the meaning of timing, aka processor cycles) instructions . And then (without the danger of any failure) go ba ck to user mode (to reenable the scheduler).

[bwinkel67]

Linus called it cooperative since a process could take full control if it wanted (either by explicitly disabling the scheduler or by forgetting to release memory which the kernel didn't keep track off), and because the kernel ran in user mode. Of course Linus didn't like any OS's of the day (I think he didn't like that QDOS was in ROM) and we are better off today because of it and Linux.

I don't quite agree with Mr. Thorvalds here, calling a system cooperative just because a task can effectively stop the scheduler is not very valid. You may call it unprotected because of the lack of protective mechanisms in the hardware - But that's mainly a fault of the CPU hardware rather than the system - There's simply no way to inhibit that because the poor old 68000 doesn't have the proper mechanisms.

With the same argument, you could call QDOS cooperative, because every job can use TRAP #0 to go into supervisor mode and effectively block the scheduler.

Probably a nuanced argument by him with regard to his point about memory allocation and the lack of control the Exec kernel exerts. I have read other complaints though that the Exec kernel did not use the TRAP mechanism of the 68000 and thus ran under user mode (again, not as familiar with the AmgiaOS and its Exec kernel so it's hard for me to support their argument). So perhaps it's not that one can block the scheduler but whether one can in user mode and not in supervisory one? Obviously that's also nuanced if every job can get access to supervisory mode but perhaps the fact that one not in supervisory mode that can block the kernel is where the hair gets split?