http://en.wikipedia.org/wiki/OS/2
Its design was supposedly far better than NT
(it initially came on 50 5.25" disks, that was "fun" to install)
I think UPS was the largest user/developer.
You know the company Parallels that made Virtuozzo (and OpenVZ) - well it was initially formed to make virtual environments to run OS/2.
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.
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...
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. ;)
Would you accept to tell us more about what your team did, what were the goals and concerns about your system ?
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.
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).
http://www.amazon.com/Showstopper-Breakneck-Windows-Generati...
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)
The OS/2 project was a collaboration by Microsoft and IBM. Sometime around 1989-90, the latter was in charge of OS/2 2.0 while Microsoft was working on the next generation. The unexpected success of Windows 3.0 made Microsoft see they could do it on their own without IBM, so NT became the next generation of Windows instead.
IBM's OS/2 2.0-4.0 was a competent 32-bit OS for its era, but NT's design was more modern. The only thing OS/2 had going for it was a smaller footprint (it could run on 8-16MB of RAM while NT practically required 32MB) and a more innovative user interface, but this advantage was basically eliminated when Microsoft ported the superior Win95 UI to NT.
There was no way to do the assisted alignment you actually wanted. They'd pitched a fabulous, malleable, document-centric desktop. Technically it was all there. They didn't quite get it to the user. People who were fluent in C could probably have done some quick fixes and made it hum.
I think this was in version 2.0, and I watched it go unfixed in 2.1, warp. Can't remember if it was broken in 4, think so. Good example of the way OS/2 dev focused on ticking feature checkboxes (3d icons! a different dock! obscure mainframe compatibility features that mainstream users will never care about!) not users.
You could also use the Font panel to drop fonts into any application and it would change the UI font. Some apps actually saved that as a preference and remembered it on next startup but others didn't.
I got eComStation running in a VM a while back and I realized that my nostalgia for OS/2 didn't quite match the reality.
At the kernel level API it wasn't much different than Win32.
I bet if OS/2 had gotten a better future, nowadays we would see rants about it similar to Win32.
The SOM C++ API was quite interesting, a Smalltalk metaclass like system for C++.
Another nice thing was the Visual Age for C++ provided an image like environment for C++, which made compilations quite fast.
I never used, just read about it in DrDobbs back in the day.
If memory serves me right, it imported the C++ code into a database and the editor was able to manipulate the code AST directly, but it consumed lots of memory, both RAM and disk space.
Maybe someone with more knowledge can fill the gaps.
I think the MTA (in NYC) still uses it to process subway fares...
He got it up, and running, at home, and work. Reported (and I recall agreeing after playing with it) that it was a better environment to run windows / DOS applications than was Windows.
Our employer (the US Marines) was not officially interested in the idea ... and so the idea never went past that.
I used it for a while in the early 1990s as a contractor in an "IBM shop". Literally everything they bought was IBM. From the mainframe to Terminals, printers, PCs, OSes. I remember it being painfully slow.... but the PS/2 PC it was running on was probably underpowered (as is typical, contractors got the oldest hand-me-down workstations).