sarum asks about the crappy TCP/IP stack in Windows. Years ago, a company named FTP Software had a nifty TCP/IP stack for DOS. They were the lucky owners of the ftp.com domain, now bought by NetManage (along with the rest of the company). FTP Software's stack worked with Crynwr packet drivers, NDIS and ODI drivers. It was an old-school TSR and when HiMEM/EMM and all that fun stuff was around it knew all about tricks to play to reduce its memory footprint. Then Windows 3.0 came out, and they supported that, with VxDs and other painful stuff, and the WinSock API was borne, in part through contributions from engineers at FTP Software. Yes, it was a commercial product, but it was damn good, and the programmers hung out on UseNet if you needed help. They had things like ICMP router discovery, TCP/IP Slow Start, Van Jacobson compression and a slew of other advanced TCP/IP RFCs before MSFT even know how to spell IP. Did I mention one of the founders of the company wrote the SLIP RFC? If you bought the dev kit, you pretty much got full source, assuming you could fathom the hairy C, x86 assembly, and interrupt mess that was the legacy of being DOS-based.
Some time after, Microsoft started shipping Windows 3.1 with a built-in TCP/IP stack. People started asking why they should pay for a stack when Windows shipped with on "for free". Well MSFT's stack was based on the BSD code, and it was a crappy port. With the release of Win95, third-party tcp/ip support was all but dead. The WinDOS implementation is still a crappy port, with bad default settings for MTU, RTT, TCP window size and so on.
In short, MSFT Borgified FTP Software and TCP/IP.
So now, you can't get a decent TCP/IP implementation for Windows. The WinNT/2000/XP isn't much better, but hey, MSFT and their partners get to charge consulting fees to help people configure their stacks to have half-decent performance.
How do I know all this? Do a search on the web for ugopher.