A Visit to Redmond - Part 5

Introduction

The week before last I popped on over to Redmond to have a chat with the guys at Microsoft on the future of Visual C++, MFC, and the new .NET world. Instead of presenting a point list of what we can expect in the future, I wanted to give you guys a taste of what a visit to Redmond is like from a personal point of view.

Please be aware that this isn't an in-depth technical treatment of .NET - there are a million magazine articles and a ton of stuff on Microsoft's own site to get the basics. The .NET specific stuff presented here will mostly be new information that I wasn't aware of, and that I felt you guys would be interested in, or was simply a vague thought that came to me while slurping through tubs of Ben and Jerry's Fudge Chocolate Disaster ice cream.

A quick Thanks goes to Dundas Software and Microsoft for making this trip possible.

Part 5 - The Compilers

This was going to be a discussion on the libraries (namely MFC, WTL, ATL etc) but I wanted to talk a little bit more about the compiler.

Personally, I would hate to be working on the Visual C++ compiler. The guys who wrote the C# compiler must, I'm sure, wander around to the dark murky depths of the Visual C++ Compiler Developer's cage and lounge around and talk at length on how nice it is to be able to develop a compiler from scratch for a language that is so compiler friendly (well, compared to VC++). Because of the design of the C# language the C# compiler can process up to 3 million lines of code a minute. I'm also guessing there are no C# compliance hassles for the C# compiler team - though once ECMA gets through with the language there is, of course, no gaurantee that non-compliance may sneak in. A standard is merely a standard, and anyone who chooses to implement a compiler is free to change their implementation to whatever suits them (or their market) best.

This is the main problem with the Visual C++ compiler. It's up to something like its 13th incarnation, and each version is building on previous versions, with each new version being backwards compatible with those previous versions. So if someone, way back in version 2.0 made a bad call on a particular feature, then too bad - future generations are stuck with it or are forced to make horrible workarounds to cope with it. Fixing these non-compliance issues is often non-trivial but the guys at Microsoft are at pains to emphasise that when dealing with non-compliance they work at fixing the most used features first. Obviously there are economic (and time) considerations as well. Microsoft has in the past worked towards imposed deadlines (whether or not they ever met those deadlines is another story) and as the deadlines loomed certain features that were deemed, well, optional, were tossed overboard. They no longer want to work this way, and if it means release dates are strung out a little then that's the way it will be. The focus is on quality, not timeliness. Compliance was always on their minds but never as much as some would like, but they do recognise this and are trying to remedy the situation.

Let me digress and pose a question. Templates seem to be an area where religious fanaticism on compliance is particularly rife, but is this really an issue to most developers? Templates can certainly make life easier for a developer, but what about the developer who takes over the project when the original developer leaves? In the face of increased labor shortages is it really wise to be developing apps using specialised techniques for which you or your company will have serious problems finding developers who can maintain your code? Even if you do find such a developer, that person may charge a premium on their specialised services, and/or may cost more in the long run because of the extra time needed to get fully acquainted (and work) with the templatised code. Maybe I'm just a wuss and like taking the easy route to code writing, so I'd be interested in hearing your points of view.

I asked Ronald about the compiler internals and he said that the compiler gets full rewrites only occasionally. There was a rumour that the compiler code was so spaghetti-like in it's internals that no one - no one - wanted to touch the thing. He said it wasn't quite that bad. The last rewrite for the compiler was for Visual C++ version 4. Each version after this has had various revisions, additions, bug fixes, 'feature' additions (you guys know what I'm talking about) and maybe a #pragma or two to keep things interesting. All in all though, the versions of the C++ compiler we've had since Windows 95 development came into vogue are refinements on the original VC4 compiler.

As with each previous incarnation the latest Visual C++ compiler has even undergone further optimisation. Given that this is around the 13th review of the compiler, with each version gaining incremental, and smaller performance increases over the last version, it is amazing that they have tweaked a further 5% performance out of the compiler.

I've already mentioned some of the newest improvements to the Visual C++ compiler: a new crash recovery feature that allows an application to be restored to its state immediately prior to crashing allowing post mortems to be carried out; 'Edit and Continue' has been improved, and there is now public access to the debug info file

On top of these, there is also now a new /GL switch that allows the compiler to perform global optimisations across all files in a project instead of being confined to per-file optimisations. Given varying applications and files there is expected to be a gain of around 5%-10% speed increase in a typical app. Note that this switch is only a 'final-build' option, since it significantly increases compile time.

The compiler also (with the appropriate switch) now inserts buffer overrun checking code into apps that stops the possibility of buffer overrun attacks. This is a major source of attacks in applications such as internet applications and is the subject of many millions of dollars of investment by companies searching for solutions. By simply recompiling your app in VC7 (with said switch) your application will be protected. If you suspect buffer overruns may occur you can simply add your own buffer overrun event handler as a last-ditch 'I've tried everything' resort. Other problems such as the use of uninitialised variables are treated in a similar manner, and you can include your own handler in your code to take care of any uncaught instances of these.

Finally, there are new Processor Packs that you can add to the environment that allow you to target specific processors, such as Pentium III's, processors with 3D Now! etc. Gone are the days of convoluted inline assembly to target these cases. As more processors come out, more processor Packs will be distributed. Any thoughts on why Microsoft would be adding the ability to target different processors so easily? I'm sure they are just looking after us .

Next Instalment...

The Libraries.