I did a lot of development on OS/2 applications in the mid 90s, mostly on the Warp 3.0 version. Eventually we switched to Windows NT4 once it became clear that OS/2 had had its fifteen minutes.
I quite liked it at the time, but to be honest I think the wistful "could have changed the PC world completely" stuff I sometimes hear is just rose tinted nostalgia. It was a very good OS for its time; its main competition then was Windows 95, and there was certainly no contest there. But the NT kernel was a different matter, especially after it got a saner UI in NT4. There were no huge advantages to one or the other there (with one exception, see below). Compared to very different modern OSes such as OSX or Linux, OS/2 and NT4 were close siblings.
OS/2's one real Achilles heel, which gave us endless trouble, was the synchronous input queue, shared by all programs that had a GUI (including the OS desktop). The upshot of this was that, if a user-facing program crashed, it was very likely to freeze up the OS and require a hard reboot. When we switched to NT4, the vast improvement in reliable uptime was a breath of fresh air (if nothing to write home about by modern standards). I gather they partially fixed this in OS/2 4.0, but by then the writing was on the wall. OS/2 faded away before the rise of modern malware had really hit its stride, but I suspect the SIQ problem would also have led to all sorts of security issues. For example, look up "shatter attack"; that was bad enough on Windows, but I'm pretty sure OS/2 would have been even more vulnerable to that sort of technique.
While I certainly wouldn't claim that son-of-NT's victory over OS/2 had anything to do with its technical merits, I do think that, at least between those two lines of development, the (slightly) better OS won.
Former OS/2 developer here (I still have an OS/2 t-shirt around somewhere). While the single event queue was a problem, at the time the major competitor was Windows 3.x, which also had cooperative eventing for the UI. NT changed that for the better.
What OS/2 had was multi-threading. If you had to do some operation that might take longer than 1/10th of a second, the guidance from IBM was to put it on it's own thread. So by necessity, OS/2 developers became expert multi-threaders.
I think it was Stardock that had an excellent newsgroup reader for OS/2 -- it was multithreaded, so you could queue-up several requests for your newsgroups (alt.binaries.*, {ahem}) and the UI remained responsive and you could go do other things, like fire up GoldenCompass for your Compuserve fix. ;)
As a cs student, I must say that I'm very impressed. A dev kernel from the era where while(true); was absolutely forbidden cause of the lack of preemption in windows. Seems like a piece of History for me.
Would you accept to tell us more about what your team did, what were the goals and concerns about your system ?
I was a contractor, so I worked on several systems for various customers (banks, mostly).
There were a few approaches - one was multi-threading, the other was to divide your task up into small enough pieces to not violate the 1/10th sec. rule, and the other was to install another product that gave you Message Queueing.
When splitting up your unit of work, you would define your own custom events such that when the event loop came around to processing your events, the granularity was small enough to keep the system responsive. BTW, events were prioritized by the OS, so not all events were treated equally. Same with NT. So you'd think of your application as a state machine, with the transitions being driven by the OS events appearing.
Message Queueing (the current darling of the scalability crowd) has been around a lot longer than people realize. :)
Also understand that for line-of-business applications, once the screen was done painting and you were waiting for user action, the event loop went into "idle" state. So in most cases you only had to worry about timeouts when you were communicating with a server (database or mainframe).
I haven't seen this edition, but if the comments are correct, try and find an original from 1994 (has a shiny cover with big red letters) to avoid the printing errors.
It's written for a general audience, but still has some technical details in it. It's more interesting from a business and personality standpoint - at that level of software development doing things like kicking holes in your office walls becomes a little more acceptable (that would have gotten me fired at any job I've held)
History best viewed as "thank goodness we crawled out of that mud" ... it was not good, not a fun way to program when you had to do any significant task but not freeze the rest of the system; or if you screwed up an accidently went into a hard loop....
In Windows 3.x modulo the DOS boxes allowed by 386s and beyond; they and the Win16 subsystem were preemptively scheduled, and a lot of good software targeting Windows deliberately used those boxes running ancient, decrepit DOS.
OS/2's one real Achilles heel, which gave us endless trouble, was the synchronous input queue
So there was basically one global event loop for the entire OS? Interesting. I can see how that would make the window system a lot simpler to write -- not unlike the reasons why Node.js and other evented web frameworks have become popular.
At the same time it is, as you mention, an approach that would have been doomed to fail spectacularly by the late '90s when it became commonplace for desktop OSs to run unverified code downloaded from the Internet...
Or had a parent/child relationship or owner/owned relationship across every thread, or installed a journal hook, or... Don't get me started on Window's non-nicety if you want cross thread/process window relationships and want to be able to keep your primary UI thread from locking up if the child thread does.
I quite liked it at the time, but to be honest I think the wistful "could have changed the PC world completely" stuff I sometimes hear is just rose tinted nostalgia. It was a very good OS for its time; its main competition then was Windows 95, and there was certainly no contest there. But the NT kernel was a different matter, especially after it got a saner UI in NT4. There were no huge advantages to one or the other there (with one exception, see below). Compared to very different modern OSes such as OSX or Linux, OS/2 and NT4 were close siblings.
OS/2's one real Achilles heel, which gave us endless trouble, was the synchronous input queue, shared by all programs that had a GUI (including the OS desktop). The upshot of this was that, if a user-facing program crashed, it was very likely to freeze up the OS and require a hard reboot. When we switched to NT4, the vast improvement in reliable uptime was a breath of fresh air (if nothing to write home about by modern standards). I gather they partially fixed this in OS/2 4.0, but by then the writing was on the wall. OS/2 faded away before the rise of modern malware had really hit its stride, but I suspect the SIQ problem would also have led to all sorts of security issues. For example, look up "shatter attack"; that was bad enough on Windows, but I'm pretty sure OS/2 would have been even more vulnerable to that sort of technique.
While I certainly wouldn't claim that son-of-NT's victory over OS/2 had anything to do with its technical merits, I do think that, at least between those two lines of development, the (slightly) better OS won.