Some current debacles around Node.JS remind me of my first job. Actually my second or third job, since I already worked in private R&D during the last 3 years at University.
First, there was no Windows originally, there was just DOS throughout most of my years at University - we had those funny character-based windows systems, heh. When Windows came out, it was Windows 3.1.
As much as Node guys think they moved the reactive programming from GUI to the back-end, Windows 3.1 used the "cooperative multitasking". Basically, the entire OS was a single task/thread. Different processes/windows had to "react" to events (like mouse clicks whatnot) and then yield control.
If any of these windows kept control for too long, the entire system became unstable and unresponsive.
Just like Node.JS - that's the throwback :) Node.Js is again single-threaded, relying on smart programmers not to take control for too long.
Read on about making Windows preemptive, better looking and fail-safe.
If you don't know - preemptive is the opposite of cooperative: i.e. a preemptive system will take control from you and give it to some other task - this is the basis of serious multi-tasking.
My graduation project was a multi-threaded, preemptive kernel using the protected mode of the then-new i286, including pagination and TAS concurrency (oh so en-vogue on the JVM nowadays, heh). Writing assembly directly sucks, eh? Luckily, we had C, heh.
It was fun writing it.
I landed my first job at one of very few industrial automation companies, because of my experience writing this stuff.
We wrote an in-house real time kernel, used in Industrial Automation, controlling 20 thousand ton water turbines and chains of hydro-electric power plants and such. What we did with that was to turn Windows 3.1 into a preemptive proper OS, which we needed in order to have real-time response of our automation tasks.
Basically, our kernel booted before Windows and took control of the entire PC and Windows was just one of our tasks: the UI task, which we preemptively managed, so when the user was launching defragmention or whatever, the rest of the PC did not freeze in any way but continued to keep that 20 thousand ton water turbine from blowing up.
The thing I remember the most was the unofficial manual with the undocumented Windows interrupts - of which we had to mess with lots. Many hundreds of pages of interrupts. Needless to say, we probably knew the Windows core better than some of the guys that wrote it.
If you remember Windows 3.1, the first thing that hit you was how ugly it was. Having seen X-Windows, I decided that enough was enough and as my Master's degree wrote an entire Windows system from scratch - it was quite fast at the time, fully featured with view-port drawing etc including a hyper-text help system.
Question: what do you do when X may fail? Obvious answer: you get two of them!
One other thing we did was to build a fail-safe Windows system, with redundant hardware on hot-stand by. Given that windows was quite unstable, it could not be trusted to run a monitoring and alarming system that protected the lives of tens of thousands of civilians (for real).
Two PCs shared a display and worked in parallel, as a redundant system. Once a failure or delay was detected, a fancy algorithm running on our kernel decided which will take control and protect the lives of thousands or people at risk in that particular implementation, as well as take control of the shared display. While the one that was having trouble was quickly rebooted by our own software to become the stand-by.
Yes, that was probably the first time Windows was in fact fail-safe. One user, one display, two hot-swapped PCs. If the user initiated a slow de-fragmentation or ran any application to slow down the system, the algorithm immediately kicked in, swapping control to the other and rebooting this one.
Ahh - this was in the mid-nineties and those were the days. Then Windows came up with 95 with preemption capabilities... and much-better looking, with pagination etc - they also figured out how to use the new i286 "protected mode".
Windows is still unresponsive at times - its preemption could still be improved: while a lot better today, is still not as stable and fully preemptive as any Unix. Nor as adopted on the server side, in the enterprise or at large. Whenever we allow UI developers to dictate the backend we will end up with unstable systems.
Likewise, I fear, with Node.JS. There is a big push behind it, I'm really curious to see how it will work out.