Books or Webpages on the Windows Philosophy

For *nix, I found that Eric Raymond's The Art Of Unix Programming expressed the ideas behind the Unix philosophy pretty well. The whole book is online, I recommend this chapter to see what I am talking about. It basically lays out the unifying concepts behind Unix operating systems and their applications. For Example:

• Rule of Modularity: Write simple parts connected by clean interfaces.
• Rule of Transparency: Design for visibility to make inspection and debugging easier.

He then goes in how these rules are applied.

What makes up the Windows Philosophy?
I have never really understood the philosophy behind Windows operating systems, and have never really known anyone who knows enough to answer the question. Googling this for me just brings up a bunch of rants. Is there an equivalent book or set of articles to The Art Of Unix Programming, but for Windows operating systems?

I would also be interested if someone thinks they have a good answer, but that might be just too long a post.

Have a look at MSDN's channel9. There you get incredibly much insite into what Microsofts engineers intended / reasoned about a certain prouct or feature.

For Windows: My absolute favorite is Dave Probert's video blog about the windows kernel (with some remarks about the differences to Unix): http://channel9.msdn.com/shows/Going+Deep/Windows-Part-I-Dave-Probert/ .... and the other part 2-4 .... (you might also like to look at the other "Going Deep" videos :-).

Have fun.

HTH, Thomas

PS: Aditionally you find very much information in the books "Inside Windows NT", the first part edition wasquite remarkable for understanding WIndows NT's inner workings.

Unix, from the "pipe" upwards, is designed around processes communicating in plain text protocols. Hence the design of various internet protocols - SMTP, HTTP, IMAP, POP, etc are all human-readable. So developers have to write protocol writing and parsing code, but it's often straightforward to interoperate with programs you don't control.

Windows by contrast is built around the procedure call / method invocation. COM and successors provide ways to extend procedure calls into DLLs, across threads of a process, across processes, and across the network. All this is fairly transparent, especially in object-orientated languages. This makes it easier to write very large, networked applications - so long as you control all the components. It makes it harder to swap out part of the complex interlinked system for a new piece of code. For example, the Microsoft Word file format is very strange as a file format, but straightforward as a representation of the objects in memory used by Word. The Exchange wire protocol is MAPI-over-DCOM: from the point of view of the Outlook developers, all they need to do is get a mailbox object and call methods on it, whereas people attempting to implement alternative clients and servers see a wire protocol that isn't easy to interoperate with.

Raymond Chen's blog (http://blogs.msdn.com/oldnewthing/) is a fantastic source for this kind of info, as well as providing down 'n' dirty details on why certain things are the way they are in Windows (example: why do you have to click on Start to shut down? Because during testing when users were asked to shut down their PCs, that was where they clicked).