Sdílet prostřednictvím

VC++ 2005 Accelerator Lab

  • Článek

I've spent the past couple of days hosting a group of Independent Software Vendors (ISVs) here in Redmond, giving them a jump start on migrating to Visual C++ 2005. The lab format was two days, with lecture in the morning and porting lab in the afternoon. Day 1 focused on migrating to VC++ 2005 and Day 2 was about targeting .NET. Attendees came prepared, bringing laptops with Visual studio 2005 Beta 2 installed and set up with their source code and build environment. Our mission: port the ISV's code bases to Visual Studio 2005 in day 1, start compiling some modules for CLR in day 2.

Day One Presentations

Ray Stephenson from our Evangelism team led off by presenting the new IDE features as well as all of the various VC++ optimization technologies in VS 2005. The new code navigation technology was a big hit, as it enables not just symbol browsing but also allows you to follow call trees up and down, and it even understands macros and templates and works without compiling.

On the performance side, Performance Guided Optimizations (PGO, pronounced "pogo") raised a few eyebrows. Compilers and linkers are normally forced to be rather conservative about large-scale optimizations because they can't predict how an application will be run. Rather than relying on standard guessing tools of tea leaves and scalp contours, PGO uses profile data to guide the optimizer in how to get the best performance out of targeted scenarios. The general workflow of PGO- izing an application goes something like this:

  1. Compile and link your app with PGO instrumentation enabled.

For further reading, Kang Su Gatlin, a VC++ Program Manager, wrote a great article on PGO.

After Ray's presentations, I spoke on security, .NET, and the VC++ roadmap. There were a couple of information security ISVs in the room, so the security bits were particularly interesting to them. Other product groups within Microsoft, such as Windows and Office, rely on VC++ features as a part of their own security strategies, and we make these features available to all VC++ developers. The key security features for VS 2005 include:

  • Safe C Runtime (Safe CRT) libraries: We have created new, safe versions of every unsafe CRT function. Now, instead of calling, say, strcpy() and hoping for the best, you call strcpy_s(), which includes a parameter for buffer size information.

  • The /GS compiler switch has been further hardened to make return address and function pointer exploits much more difficult.

  • Static code analysis with the /analyze switch, which analyzes code paths at build time in order to detect errors before code is enters testing.

  • Safe STL iterators detect overrun/underrun conditions.

The .NET story with VC++ is pretty straightforward: it just works. The new C++/CLI syntax is a vast, vast improvement over managed extensions found in the current version of the product. Using C++/CLI you can mix managed and unmanaged code pretty much willy nilly. .NET interop is so seamless in VC++ 2005 that .NET pretty much becomes just like any other library. There's no need to have the heavy "managed vs. unmanaged" discussion at all. If you like the .NET classes you just use them, and you can mix managed and unmanaged classes without all of that p/invoke fuss.

Day One Lab

The goal of the Day One lab is to get ISV's code compiling on VC++ 2005 beta 2. This was a deceptively simple goal, given that some ISVs come to the table with applications that sometimes measure in the millions of lines of code. ISV projects included a mix of VC++ 6, VC++ 2002, and VC++ 2003. For the most part, project and solution conversion to 2005 went pretty smooth. There was one issue with a bad character in a .vcproj file, but that was identified and corrected pretty quickly.

As ISVs started to compile, the #1 issue to bubble to the surface was conformance. Improved conformance means formerly acceptable C++ constructs that are now deemed non-standard will no longer compile. Generally, the older the compiler, the more lax the conformance, so VC++ 6 users in particular had a number of conformance issues to deal with. However, most of these issues were not brain surgery, and understanding the handful of conformance issues common to a particular code base enables a developer to make pretty quick work with bringing the code base into shape.

ISVs also received the raft of security warnings the compiler now emits by default when it encounters use of an unsafe CRT function. We encouraged folks to fix these issues as they came up, as today's elbow grease may save you from tomorrow's security exploit.

One ISV also had issues with a particular third party STL library, which wasn't yet able to compile in VC++ 2005.

Day 2 Presentations

Stan Lippman started out the day with an in-depth discussion of C++/CLI. Stan's always entertaining and, having been a part of the original C++ team at AT&T Bell Labs, can speak with great authority on the language. The most interesting nugget I picked up from Stan's talk: Bjarne wanted a keyword in the language like "abstract" to denote a method with no implementation that an ancestor must override to use, however some pointy haired manager at AT&T decided it was too late in the cycle, so C++ became forever stuck with the cryptic "= 0" syntax.

Kang Su spoke next on taking advantage of hardware in VC++, discussing topics like 64-bit computing and threading/concurrency issues. Kang Su brought up an interesting topic to ponder: within a few years, all PC CPUs coming out of Intel and AMD will be 64-bit capable and multi-core. Because clock speeds are unlikely to continue to increase at the same rate due to heat problems, developers must look to concurrency and 64-bit as primary venues for improving performance. To help with this, VC++ 2005 provides tool sets to target x64 and IA64 CPU architectures and includes support for OpenMP for taking advantage of multiple cores and CPUs.

Day 2 Lab

While we hoped the ISVs would be ready to target CLR today, we were still working on the VC++ 2005 port. In about half of the cases, ISVs had actually got their code compiling but were now seeing runtime issues, typically due to previously existing but newly found memory corruption bugs. It was great that compiler-generated stack check code was working as advertised to find memory corruption problems before they became customer reported bugs or security issues, but it certainly wasn't helping my schedule in the lab. :)

There were a few other niggling issues with porting. One ISV found a bug in the MIDL compiler. Our third-party STL using ISV decided to move to the VC++ 2005 STL implementation (since their reasons for not using the VC++ implementation in the first place had since been resolved), but there wasn't enough time in the lab to fully make the switch over.

The nice thing about the lab format is that we had VC++ product team members on-hand in order to help ISVs work through the issues. For those issues we couldn't handle, the engineers that worked on whatever area may be in question were just a phone call or email away. In several cases, VC++ developers even made the trek over to building 33 to personally help an ISV with an issue in his or her area. It was actually a pretty cool team effort to behold -- it was obvious folks have a lot of pride in their respective area of the product and were interested in the ISV experience using their features.

Summary

All told, I was happy with the results of the Accelerator Lab. Within two days we managed to communicate the key reasons why upgrading to VS 2005 is important and get several ISVs ported or nearly ported to the new compiler and tools. Perhaps just as important, the Visual C++ development team was able to spend a good amount of time directly connecting with customers and then bringing that experience back into the development of the product.

Comments