On Windows July 29, 2009

It’s been a while since I’ve posted anything - prime culprit being work. For about two months now, I’ve been hacking on Windows (gasp), and I’d like to share my experiences. Since I am under a NDA (pfft), I can’t give more details than I was working with the Windows Filtering Platform and had to write a “driver” to do some packet inspection in kernel space. For those who know me at all, I’m a Linux-boy through and through (signed, sealed and delivered ;-)), but I took this as a great opportunity to actually find out how good/bad Windows was. I’m trying to be unbiased, but like heck I will be.

The Development Environment

I had to use Visual Studio 2008 and their framework for driver development. Prior to using it, I respected Visual Studio a great deal. Unfortunately, I’m a Vimmr (i.e. Vim user), and Visual Studio is a nasty mouse-driven environment. I had GVim up and running within about 30 minutes, and used it hence forth. It was interesting to see that they support Emacs-mode commands like Ctrl-K Ctrl-C (comment selected lines), etc. They’ve dubbed them “chords”. I’m pretty sure they are trying to patent the idea too… Unfortunately their C/C++ support is crappy, and largely pointless.

To develop drivers on Windows, you need to download and install their “Driver Development Kit” (DDK). It is one of the shadiest work-flows/toolchains I’ve ever used. Not only are their build tools ancient (they don’t support spaces in pathnames - and Windows is chock-full of spaces), but installing modules is an arcane dance involving the Registry and mystical green fairies. At some point in time, I had thought GConf was just another Windows Registry, and given Windows some slack for this. GConf is a beautiful entity, with an elegant interface, and well defined role (I can imagine some people vehemently disagreeing with me here though). The Windows Registry is scary. The worst part of loading driver modules you’ve compiled is that their error messages are indecipherable. The solution to most problems is to un-register the “service” (module), move you files, and re-register them. All this stuff has to be done on Windows command line (scream). The easiest solution though is to use the “OSRLoader” from The NT Insider. The NT Insider is an awesome source of information for anything to do with Windows Driver development, and their articles are very enlightening. You have to register, but it’s free. I owe a lot of saved time to them.

The APIs

Back in my 12th class, when I first started “developing” software, I thought I’d try to make a UI on Windows (this was for the FluffWho program, so I thought it’d be better on Windows. Unfortunately, it turned out that most people on the group (and thus use the program) used Apple Macs…). It was my first encounter with the WIN32 API. After a thorough session of eye gouging, I made my decision to cross over to the Dark Side (Linux) with the firm knowledge that with such a crap-ridden (I apologize for the strong language) foundation, the platform would crumble and die pretty soon. I had to use the same crap-ridden API now, and the experience was pretty horrible initially.

That being said, their later development, C# and the .NET framework is most god-awesome. I have to applaud Microsoft for developing it. It is a pleasure to use, and with Platform Invoke (PInvoke), it’s a breeze porting C/C++ libraries to it. I can not emphasis how awesome it is, so if you’re the developing kind check it out now. Visual Studio is pretty amazing when it comes to C#, and has a lot of jazzy features from auto-complete to on the spot syntax checks. However, given it’s mousey-ness, I didn’t really use it too much.

Design and Engineering

Comparing the Linux iptables and the Windows Filtering Platform, I have to say that the Windows solution is a lot more solid and well designed. Though I must say, it might be too elaborately designed as well. There is a clear line distinguishing the two, in that the Linux solution is written to make a server-grade firewall with a command line interface, all the features you’d want (like “connection tracking”, synchronising with a backup server, etc.), where as the WFP is made for programs to inspect packets and other security features. I can say this because the Windows solution does not have any (decent) support for filtering on the “forward” layer, i.e. the layer which most routers, etc. will use, and lays more emphasis on filtering based on applications etc.. Given Linux’s unstable API (libiptc), I would have to give it to Microsoft. In my case though, I needed that forward layer, so Linux would have been kinder (though Windows was a lot of fun).

Also, having had the privilege to work in kernel-space, I have a few comments regarding it. First and foremost - synchronisation on Windows is evil re-incarnate. Technically, mechanisms like mutexes and spinlocks are supposed to be handled using atomic get-set instructions (which must be supported by the processor). Windows handles most of these by simply raising the IRQL level. And that causes general f00 and blue screens. Gah. They do have one mechanism (and that’s all you need) that does not use IRQL, but “guarded” regions instead (guarded mutexes). The interface to do I/O with devices is generally rather shady, since it is a device file, but Windows does not handle everything like a file the way Linux does. I have lots more to blabber about Windows, but I shall refrain myself in concern for your general sanity.

Summary

I haven’t done any kernel development on Linux, so it’s hard to compare the two evenly. My slightly (cough) biased opinion is that Windows is better designed and thought out now, but was built on a solid layer of crap; the inconsistencies will catch up with them soon. It is then that the Penguin Liberation Front shall strike and take over the world!

Edit (Post-sid0): After a good chat with Siddharth Agarwal (sid0), the resident Windows junkie, I’d like to mention that much of my bad experiences were caused by being a n00b (as is generally the case). He’s told me about the awesomeness of the VS command line, dump debugging in WinDbg. I wish I could go back and streamline a couple of things, but I’ll keep these in mind for the future.