DevSource: In http://channel9.msdn.com/ShowPost.aspx?PostID=20715 you said, "The next version of Visual C++, code-named Whidbey, will introduce several new security-protection capabilities." And then you proceeded to discuss the new security-focused changes." Based on an (entirely unscientific) poll on DevSource, about half the developers currently do nothing in particular to assure their code is secure. Will the new Visual C++ capabilities protect someone even if he isn't trying to be protected? (That is, will the features cut in only if explicitly asked-for?)

Currie: The security enhancements in Whidbey fall into two categories: those that protect code or diagnose issues automatically and those that have a learning curve but are then automatic.

In the first category (those that protect code or diagnose issues automatically), we have a few very powerful features. The /GS Buffer Security Check compiler option) automatically adds protection to your shipping binaries so that buffer overruns are not exploited. It serves as a last line of defense so that hackers cannot exploit many of the buffer overruns that you do ship. While /GS doesn't catch every possible case, it does catch a large number of issues and it gets better with every release. We aggressively optimize the code generated for stack protection so that the cost of shipping with /GS enabled is negligible. In fact, all major Microsoft applications are being built this way and /GS is the new default for VC++ 2005.

Also in the first category is PREfast, which will ship as part of Visual Studio 2005 Team System. (PREfast analyzes your source code in an attempt to find buffer overruns, uninitialized data, resource leaks, and a variety of other common problems that lead to incorrect behavior, suboptimal performance, or security holes. Just like /GS, all you have to do is throw a compiler switch, in this case /prefast, to get this additional analysis and protection. We use PREfast within Microsoft and find it to be immensely useful.

In the second category (those that have a learning curve but are then automatic) we have more great features. Whidbey introduces a new set of library extensions called the Safe CRT library extensions. When the CRT library was originally designed and specified by the community, high performance was favored over application security, which has led to problems where developers commonly write insecure code. For Visual C++ Whidbey, we have identified those functions in the CRT whose common use are likely to lead to security issues. For each of these functions, we have provided alternate secure versions. Some of these functions are simply modifications of existing function implementations that perform additional parameter validation, avoid static/global data, or fix other potential security holes. In these cases, the developer gets the more secure version without making any changes. For other functions, a new API with a new signature is created that takes additional information such as output buffer sizes (not just input buffer sizes). In these cases, the developer has to learn how to use the new APIs, which is easy, and then just use the safe versions wherever the unsafe versions would have been previously used.

DevSource: You're really involved in IJW. Tell me what's so cool about it (and what it is).

Currie: Millions of developers actively develop billions of lines of C++ code for Windows. With the shift from Win32 to .NET and WinFX, these developers are faced with the challenge of consuming the .NET and WinFX APIs, which enables them continue to produce 1st class windows applications, without losing the huge investments they have made in existing code. The IJW technologies enable developers to simply recompile their existing C++ code into .NET assemblies without making any source level changes. From there, developers can seamlessly extend their existing source bases to consume and expose .NET APIs. It enables them to stay on the leading edge of Windows development without restarting their applications from scratch or using clunky interoperation mechanisms.

To give you a better idea of how we make this work and what's involved, let's back up a few steps. At the most fundamental level, the IJW technologies enable .NET code to directly call existing C++ code and existing C++ code to directly call .NET code. To do this, we will generally compile C++ code to MSIL (the language used for .NET assemblies) just as if the CLR was another physical machine target. Once some code is compiled to MSIL, it can call out to other .NET APIs without any transition overhead and without any effort from the developer. Perhaps cooler is that the compiler is capable of compiling individual functions as either MSIL or native code and is capable of emitting both the MSIL and native code into the same EXE or DLL. The compiler transparently handles all of the wiring that is necessary to make calls between the MSIL and native code work seamlessly.

What this does is to give the C++ developer maximal flexibility in how he brings his existing code base forward to .NET and WinFX. We have essentially provided the developer with a dial that can turn up or down the amount of managed code used in a given EXE or DLL. Developers can leave the majority of their applications native and only bring in the CLR for a small set of value-added features; they can compile the majority of their application to MSIL so that they can integrate new .NET code everywhere; or they can do anything in between. And, they can do so in an extraordinarily granular way. We offer the ability to specify managed/native compilation on a per-function basis.

This technology is already becoming popular both inside and outside Microsoft. Inside Microsoft, it is used in Visual Studio, the CLR, Avalon, the Office team, SQL Server 2005, and pretty much any other team that is needs to preserve existing investments in C++ code while moving forward to .NET. In April, Autodesk shipped the latest version of their enterprise CAD software that uses the Visual C++ 2003 version of IJW to expose a managed object model for the application. A variety of other customers from control vendors to ISVs are also using the technology to consume .NET APIs and expose their code to .NET users.

DevSource: There's obviously a whole pile of new stuff in the next Visual C++. What do you personally think is the coolest feature? It doesn't have to be "important" — this isn't a marketing question. What was so nifty that you went home at the end of the day and told your dog, "This is so cool!" The dog, of course, was quick to agree. (A cat could care less.)

Currie: The coolest feature is probably MSIL Linking, which is also known as netmodule linking. In Visual C++ 2005, link.exe is capable of consuming netmodules generated by any .NET compiler (C++, C#, VB, COBOL.NET, whatever) as if they were C++ object files. This means that it is now possible to create a single file binary using multiple different languages. We have always been able to get separate binaries written in different languages to talk to each other; COM did this, as has .NET since its first release. With previous versions of .NET we were also able to have a single assembly that was generated from multiple source languages, but it had to span multiple files.

Now we can actually have those different languages working together in the same single-file EXE or DLL. This feature does enable some interesting scenarios. But more than anything, it's just really cool. (I talk about this further and have a demo at: channel9.)

DevSource: And which of the new features do you think is going to have the most impact on the way developers work? Even if it isn't sexy?

Currie: Visual C++ 2005 will have the largest impact on developers who write code against the .NET Framework. The most significant change in this space is that we have an entirely new syntax for targeting .NET.

Visual C++ 2002 and Visual C++ 2003 offered the Managed Extensions syntax for targeting .NET Framework with C++. The design philosophy behind Managed Extensions was based on the assumption that C++ developers were not willing to accept changes to the core C++ language syntax to support .NET programming. As a result, language extensions were provided using ISO conformant __ keywords (such as __gc and __interface) for proprietary vendor extensions and repurposed existing standardized operators. Unfortunately, while Managed Extensions preserved the purity of the earlier C++ language syntax, it broke the C++ programming idioms that C++ developers have come to rely upon. That is, it didn't respect the C++ programming model. As developer feedback clearly indicated, the C++ programming idioms are far more important than the details surrounding most syntax structures.

Consequently, for Visual C++ 2005, the Managed Extensions syntax has been deprecated. In its place will be a new C++ syntax for targeting the .NET framework. The design philosophy behind this new syntax is to bring C++ programming idioms to the .NET Framework and .NET Framework programming idioms to C++. Furthermore, these goals had to be accomplished with a highly usable and aesthetically pleasing syntax. The new C++ syntax for .NET is currently undergoing the standardization process with the ECMA standards body. For more information about the new C++ syntax for .NET development, see the draft specification for the language (PDF).