and of course did not scale properly.
The single threaded version just polled all player sockets constantly, and the response times were atrocious with more than 15 players online
What the others have said: If you can't even do 15 players on a single thread without lag, then you're doing something wrong.
EverQuest did 150 players per zone over ten years ago, on not only single-thread, but single-core, single-CPU servers.
Btw: Windows *can* be used for servers. Aforementioned EverQuest used it. Arena.net (Guild Wars, GW2) does it. Xbox Live! also does it, and is a pretty big online gaming service. :-) It's sometimes a bit more painful or more expensive than Linux for many use cases, but if you know Windows and don't know Linux, it may be worth it to stay on Windows.
Really, unless the simulation code itself can't keep up with a 30 Hz update rate, then a single-threaded networked server should be able to keep up with up to 64 players just fine using select(), and probably 1,000 players if using single-threaded I/O completion ports. The way to add threads, if on Windows, is to then use more worker threads for the I/O completion ports that you tie your sockets to. And here, you should use one thread per core, not one thread per user.
Finally: If anyone thinks this means that I'd prefer to write servers on Windows, the answer is a resounding "no" -- I'm most effective on Linux and other UNIX flavors for servers. But Windows is not a "no go," and we shouldn't automatically dismiss it "just because."