There are some interesting technologies available to make writing secure code on the Microsoft platform easier.  A couple that I've been thinking about recently are PreFAST (with SAL) and ASLR.

PreFAST is a build-time tool that checks how APIs are used in your code.  It does this by referring to statements made about those APIs in the source.  If you take a look through the Visual C++ include directory you'll see a lot of examples, using SAL, the Standard Annotation Language.  A typical (fictional) example might be: -

The SAL annotations are the things that start with a double underscore.  Let me see if I can explain what they all mean...

__checkReturn tells the compiler to emit code that checks the data returned from the function.

__out_z_opt (which in this case refers to the function's return value) says that the value is output only, that it must be null-terminated, and that it's optional (i.e. it can be null).

__in says that the parameter it applies to is input-only

__out_ecount_opt(sizeInWords) says that the parameter is out-only, is optional (can be null), and that it is an array where the number of elements is specified in the parameter called sizeInWords.

There are many more possible SAL statements, but hopefully you can see that they follow a predictable pattern so it's not too hard to remember them.  It's worth remembering that you can use SAL in your own definitions and thereby check the way your application calls your own code.

Initially, PreFAST was available only in the higher-level SKUs of Visual Studio 2005.  That is, the necessary /analyze switch on the compiler was not available at the lower levels.  Recently though, the Windows SDK (certainly from the Beta 2 bits) has included a version of the compiler that does support /analyze, so now there's no excuse not to use it :-)

Turning now to ASLR (Address Space Layout Randomization), its aim is to make it harder for exploit code to work reliably.  Let's say that some bad person has managed to get their code into your process' address space (in spite of your using /GS, DEP (NX), and PreFAST), and they manage to get their code executed.  Typically, exploit code tries to invoke some well-known APIs based on an expectation of where those APIs are loaded in your address space.  A good example would be LoadLibrary.  As of Windows Vista, each time you boot your system, these key APIs are moved into one of a set of 256 possible locations.  This means that any exploit code has only a 1 in 256 chance of actually calling the intended API.  If it makes the wrong choice, the process will crash, which is better than the alternative.

Taken in combination, these features are making it increasingly difficult (we'd never say impossible) for malware to execute on our PCs.   All it takes is for developers to be aware of these things, and take the time to learn and use them.