When I first saw a whole stack of low latency C++ Win32 based servers running on Windows supporting an interest rate trading business back in 2004 I was amazed. Talarian SmartSockets was used for interprocess pub/sub between servers. There was no COM. No thread pools, just a handful of threads in each process executing distinct code. Very clean async design. Back then Linux didn't have lightweight threads, IIRC. I think this is the kind of thing Windows Nano might support. Is that what you had in mind when you look forward to Windows as a server OS?

Windows IO completion ports and the way threads are scheduled are probably only beaten by Solaris and Aix specific APIs.

Most FOSS devs never care to learn such APIs and stay with the lowest common denominator that happens to exist in GNU/Linux and *BSD.

> are probably only beaten by Solaris and Aix specific APIs.

They're definitely not. AIX copied the IOCP interface almost verbatim, but missed one critical piece: associating an IOCP with a desired concurrency level. Solaris added event ports, but again, they missed the concurrency link too.

The root of the problem on UNIX is the readiness I/O model.

See https://speakerdeck.com/trent/pyparallel-how-we-removed-the-... for more info.

Thanks for the heads up. It's been a decade since I touched Solaris and Aix.

Do you think this will change with the popularity of node.js and libuv? That is, people using said capabilities in a cross-platform manner more.

I doubt it. On the enterprise space from our customers, no one cares about them.

It is all about .NET, C++ and additionally the JVM when going outside Windows.

You should see what you can do today with Registered I/O and the new threadpool APIs. It is phenomenal. (And literally decades ahead of anything UNIX offers. OS X comes close with GCD.)

I am aware of it.

Even though I used UNIX a lot on my career, I have always been with foots on both lands and enjoyed Win32 more than POSIX, claimed as portable, but full of nuaces per UNIX clone.

"C++ instead of bare bones unsafe C" is C++ really much safer than C?

"an OOP ABI (COM)" you really think this sort of thing is super great and there's nothing like it on "UNIX clones"?

I have heard interesting things about windows async i/o syscalls, but as you'll see in another sub-thread, IIS still has a major component in the kernel, because the overall syscall overhead of windows is apparently somewhat high.

This wouldn't be the first time I've heard of super-fancy windows subsystem designs which in practice were sabotaged by just generally over-complicated implementations. I recall a blog post by Mark Russinovich around the time Vista came out about the new, quite advanced file copying algorithms: http://blogs.technet.com/b/markrussinovich/archive/2008/02/0... - but that file copying performance was often significantly reduced when playing an mp3 file due to the "multimedia class scheduler" - http://superuser.com/questions/18600/107mb-s-network-file-co... - either because i/o and execution priorities didn't actually work, or the engineer assigned to do this didn't know what he was doing and neither did anyone he worked with. Who knows?

This sort of thing is all over microsoft's stuff. Theoretically super advanced, in practice just over-complicated. It's closed source and hugely complicated, so we'll never really know why it doesn't work as well as it should.

> "C++ instead of bare bones unsafe C" is C++ really much safer than C?

If one codes as "C with C++ compiler" then no.

If one makes use of the features that fix C unsafety, then yes.

> "an OOP ABI (COM)" you really think this sort of thing is super great and there's nothing like it on "UNIX clones"?

Which UNIX clone provides a standard OO ABI, as well as, a shell close to the Xerox PARC user experience?

Taligent failed.

>As an hybrid kernel

I must ask, what exactly makes the current NT kernel a 'hybrid' kernel ?

It still makes use of the original micro-kernel design,with kernel level RPC to separate modules. Thus still offering a micro-kernel cleanness in a monolithic space.

Also since Windows Vista many drivers are now implemented in user space, with minimal kernel primitives.

>with kernel level RPC to separate modules.

Is this what is described as LPC ? Could you elaborate on how it separates the modules (as opposed to unix subsystems) ?

>Thus still offering a micro-kernel cleanness in a monolithic space.

What does this 'cleanness' provide, and how ? It's all in kernel space so if one module crashes the whole kernel crashes ?

First of all, yes memory corruption will still bring the whole thing down. Only pure micro-kernels can survive it.

What Windows does, is that there aren't any direct calls between modules, only kernel level RPC calls.

All parameters are packed into the RPC message, it is dispatched, unpacked, validated as much as possible on the receiving end, then processed.

Messages and its validation introduce an indirection layer that improves safety.

It is based on the original micro-kernel design Windows NT had, before they moved graphics back into the kernel.

So the micro-kernel message passing is still there, but simplified since now everything runs on the same space. But as of Windows Vista, UDF was introduced for user space drivers.

The "Inside Windows" book series go into great detail how everything works.

Exactly. It gets the modularity and some fault isolation without the vastly-reduced attack surface of kernel mode. ;)