You'd think Microsoft has learned the lesson. For years, they've gone unimaginably far to preserve backward compatibility and help even software vendors that ignore the specs. We could have always relied on Microsoft not to break our apps unless there was a really, really good reason for doing so (Raymond Chen's blog is full of interesting examples of this).

Well, they seem to think that there is one reason to rule them all - security. Microsoft's reputation in this field has not quite been stellar in the last few years. Someone decided to put an end to this and prove once and for all that Microsoft, when focused and committed, can do an excellent job with security. Thus we got Secure CRT (C Run Time library).

(Beavis and Butthead voice) “He said 'C runtime'. Heh. Hehehe. Hehehe.“. Who cares about C runtime in 2005? Just about everyone, implicitly. Even if you don't make a single call to C runtime you will be dependent on it if you make calls to C++ runtime because many functions in the C++ Standard Library will delegate most of its functionality to C library whether you like it or not. Python relies on C runtime, Ruby relies on C runtime, heck - Windows itself relies on (admittedly older version of) C runtime.

Now that it's established that we should actually care about what Secure CRT is all about I present to you one of the stupidest moves from Microsoft in a long time - in an effort to help everyone making CRT secure (noble goal), Microsoft will break practically all applications in runtime (assuming they are recompiled with the latest Visual Studio 2005 i.e. C++ compiler version 14).

The problem is that this is a runtime issue, not a compilation issue and is very hard to work around. In fact, Microsoft's own C++ Design-Time Breaking Changes has the following to say on this issue: “Work Around: None Available”.

What is the issue? I'll quote Microsoft on this one (taken directly from the document I just linked to above)

Many existing functions now validate their parameters and will call the invalid_parameter_handler when an invalid parameter is passed

This is good, no? Instead of blindly expecting the developer to do the right thing, Microsoft will do the work for you and validate all parameters you send to C runtime library functions. But what's this invalid parameter handler you might ask? That my friend is Microsoft provided function that will invoke Dr. Watson and terminate your app. Not good. Developers, developers, developers might be pissed (I know I am).

To be fair, there is a work around - if you want, you can set the invalid parameter handler to be your do-nothing function and you'll get the old behavior. But this is clumsy and requires me adding code to all apps plus it's hard for 3^rd party vendors that ship DLLs - should they set their own invalid parameter handler, or expect your app to do so? These handlers cannot be chained and the call to set a handler is not thread safe. Every DLL that sets this handler will overwrite someone else's and you can't even know if there was a custom handler set before. This is bad, bad, bad.

What you will see as a result is that many software vendors will opt to do nothing and will not move to Visual Studio (C++) 2005. I don't think this benefits anyone.

Call to action for Microsoft - please fix this in Service Pack 1. There is a simple way to work around this issue - provide a compile time switch that will affect the behavior so that one of the options is do-nothing. There are many benign calls to runtime with invalid parameters that can be handled by returning an error code, not terminating an app.

If this is what secure is supposed to be, I don't want to be secure. I want my apps that have been working fine for 10 years to continue to work.