Welcome back to the autumn term! We hope you had a great summer. We've been hard at work roasting marshmallows, making gimp bracelets, and learning how to make a baked brie using only twigs and berries. It's all part of our commitment to provide the best possible camping experience for our readers.
A couple of months ago we asked for your opinions on our balance of editorial coverage. We received lots of great replies, both in favor of covering upcoming technologies and against it. We even touched off a bit of discussion when a well-read blog by Joel Spolsky (How Microsoft Lost the API War) split Microsoft into two "camps"—the MSDN Magazine camp, promoting the latest and greatest, and the Raymond Chen camp, which is dedicated to backward compatibility. (Raymond is a Microsoft blogger whose writing is highly recommended—see Myth: You need /3GB if you have more than 2GB of physical memory.)
It was quite a heady discovery to find we've had such influence, but we wondered, are these two camps really at odds? So we asked Raymond what he thought. He's an incredibly bright guy with deep knowledge on a wide variety of industry issues. In short, he could be a formidable enemy of the MSDN Magazine camp. We were ready to crush him like a bug, when he summed up the "war" in the following manner:
MSDN Magazine: "Go use cool technology xyz (version 1.0)"
Raymond: "And don't be afraid of obsolescence because version 2.0 of technology xyz will still support 1.0 clients"
Very cute. Great way to weasel out of a humiliating defeat, Raymond. But honestly, he makes a very good point. Backward compatibility means that if you do try out version 1.0 of a technology, you don't have to worry about your code working with version 2.0. Part of our role is to help ease your migration to the current and future versions of the .NET Framework. A perfect example of that kind of migration can be found in our October 2002 issue (see Serial Comm: Use P/Invoke to Develop a .NET Base Class Library for Serial Device Communications).
If you read it you'll learn that the standard signal format on a GPS device includes RS-232 as part of its spec, but there's no support for serial ports in the .NET Framework 1.0! We mentioned this problem in an Editor's Note, and after a search, we found an author who created a serial comm wrapper for the Framework. Two years later, it's still one of our most popular code downloads.
The serial comm piece shows one way the .NET Framework made the core Win32 API arcane. Serial comm in Win32 was not easy, to say the least. With no native API, it was just exposed through the CreateFile function:
hPort = CreateFile("com1", GENERIC_READ | GENERIC_WRITE, 0, 0,
OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0);
Why would anyone want to do this? Visual Basic was a great step forward for programming because it provided the MSComm control. You could put MSComm on a form and say:
MSComm1.PortOpen = True
Looking at that Win32 CreateFile version, why is it a shame that it's consigned to the dustbin of obsolescence by a .NET class wrapper? It's not, and any one of the millions of programmers using Visual Basic will tell you that. And this is just one of many examples you can dig out of the Win32 SDK.
Over the years, the Win32 API became unruly. That's because Windows is such a rich operating system; the .NET Framework made things more logical (and a bit easier), and that's why we embraced it in our magazine. Just like Visual Basic before it, .NET makes programming simpler so you can concentrate on the features of your app, rather than which CreateFile arguments go where.
The Raymond Chen camp is looking to make sure that future versions work with the code you've written today, even if your code is the one with the bugs in it. MSDN Magazine is looking to make sure you understand how the future versions work so that you don't introduce those bugs in the first place. For instance, in this issue you'll get first looks at the new Express Editions of Visual Basic 2005 and SQL Server 2005. Brand new? Yes. But, they're available for testing now, and your existing code will run fine on them. Maybe both camps can be happy after all.
Thanks to the following Microsoft technical experts for their help with this issue: Kawarjit Bedi, Josh Benaloh, Christopher Brumme, Antoine Cote, Thierry D'Hers, Michael Fanning, Rajesh George, Robert Green, August Hill, Michael Howard, Raman Iyer, Doron Juster, Shai Kariv, Peter Kim, Hao Kung, Duncan Mackenzie, Ronald Laeremans, Enzo Lombardi, Ivan Medvedev, Gang Peng, Brian Sabino, Matt Tavis, and Maura Van Der Linden.