Dr. Dobb's Journal February 2004
Mainly because air travel is so painful these days, I don't do much in the way of shows and conferences. But I made an exception with this year's Microsoft Professional Developer Conference (PDC) that was at the Los Angeles Convention Center (LACC). I'd planned to get to and from the conference on the new LA subway system, which really works well. Of course, just as the conference started, the LA public transportation system was closed down by strikes. I still went to PDC, but I had to drive.
Now, I like to think of myself as a Los Angeles booster, but alas the LACC is badly designed, badly located, and badly run. The parking lot seems to be managed by fiends determined to make life miserable for those who need to park there, with gates closed for maximum inconvenience, parking areas mysteriously closed at random, and other such quirks. Perhaps the parking management people were reacting to the strike: "We don't care. We don't have to."
Also, the wireless network at LACC never did work properly. This is probably because PDC was oversold with more than 7000 people, which isn't all that large for a convention, but when every one of them had a laptop with wireless capability and a ravening desire to be connected...At least one keynote presentation crashed because the demonstration relied on wireless .NET access and the on-stage machines didn't have it.
To its credit, Microsoft quickly saw the problem, and by the second day the LACC was riddled with jury-rigged Ethernet connections at tables originally intended for wireless connections. Everywhere you looked there was Duct tape on the floor.
PDC began with preconferences divided into two streams: conferences for developers, and an all-day overview session for the press. The latter was quite well done. I learn more at WinHEC each year than at any other conference, but this one comes a close second. There was real meat in the technical sessions. Microsoft doesn't do PDC every year, and it's certainly not cheap, but if you are at all interested in the future of Microsoft software development, this is the conference to attend.
The big news for software developers was Longhorn, which won't be out until at least 2006. That's an inference, not a confirmed date, but it's pretty certain Longhorn won't be released before then.
Still, there were some prealpha elements released. In his keynote, Jim Allchin announced you could pick up early Longhorn code (http://www.winsupersite .com/reviews/pdc2003_allchin_keynote.asp), warning that you should run it on really fast machines—it will be slow. Don't put it on production equipment, and be careful how you connect it to the Internet or internal networks. Given all that, he said, here are some bits to play with, and we have never before released any bits this long before product release. Of course, one translation of this would be "We have never released a major product this late before."
Allchin's presentation featured Don Box, Microsoft's XML Architect and senior coding guru, showing Allchin how to write code (http://www.gotdotnet.com/team/dbox/ default.aspx?key=2003-09-13T05:04:32Z). The message was clear: Even senior managers can write working code with the new Longhorn tools.
Bill Gates gave the keynote (http://www.microsoft.com/billgates/speeches/2003/10-27PDC2003.asp) at the customary oh-dark-thirty hour he seems to favor. It might be interesting to speculate on why he likes talking at dawn. Does he count on stupor to generate more willing suspension of disbelief?
The capsule view is that we're moving on with the Gates vision first put forth in the "Information at your fingertips" of a dozen and more years ago. Information at your fingertips was a wonderful idea, but in those days the hardware and network connections just weren't up to it for anyone not on a campus with high-speed Internet connections. In 2003, the vision is "Helping people reach their full potential," whatever that means. It's certainly not as concrete a picture as "A PC on every desk and in every home." Coupled with that were marketing remarks, such as "Technology decisions must be justified for business reasons now." My translation is that what we have is often good enough, and there's no automatic reason to upgrade; a distinct change from a decade ago when everyone agreed these machines were too slow, and getting information took too long.
Gates has always understood Moore's Law better than anyone else in the industry. If you can make something run at all, get it out there—it may be slow and clunky, but hardware improvements will bail you out. If you wait until it's running perfectly on the hardware already in the field, it will be obsolete before it's released. This philosophy built Microsoft, and is the main reason Microsoft won the war IBM declared back in the OS/2 days.
Moore's Law was Microsoft's biggest friend in the past. It is now, I think, the biggest threat to Microsoft's revenue stream: The machines are so much better than the software that we expect spectacular improvements, not merely in how fast they do something, but in what they do. Anything that works at all now works fast, and if it's not yet fast enough, it will be. The result is that for most of us, upgrades (at least those we have to pay for) aren't automatic. We don't want to shell out more money until we're getting something spectacular in return because, for most of what we do, the software we have coupled with present generation machines—huge disk storage, fast CPU, excellent audio and visual—is already good enough.
The irony is that automated feedback loops—those bug reports Microsoft asks for after glitches and crashes, and which I always send—are teaching Microsoft how to make incremental improvements at the very time when incremental improvements don't drive the market. There's no question that those bug reports and crash analyses can identify bugs and generally show how to make things better—but they won't generate demand for complete new upgrades and a new revenue stream for Microsoft.
Software is now the bottleneck. It's good to know that Gates understands this too, although it's hardly astonishing. Of course, some efforts can be a bit ambitious in the wrong direction: Gates showed Microsoft Bob, as well as several other cuts, demonstrating that he can tell jokes on himself.
The screens are getting larger and video chips are getting better. We can have a lot more on screen, and have it faster. What will we put on those screens? Longhorn, Gates said, will be the biggest release since Windows 95, a complete overhaul—and then the demo screen came up. Longhorn, and in one corner of the screen was a window running VisiCalc. For good or ill, Microsoft is not abandoning legacy software users. There were cheers from the audience.
The Longhorn display looks a lot like the latest Macintosh display, too, complete with a sidebar. The favorite rumor in the Press Room was that Microsoft was going to reinvent the Channel Bar and monopolize it: Someone should write Judge Thomas Penfield Jackson and warn him.
Software is certainly the problem, but whose software? There's one question that nags me. I have on my web site, and thus on the local hard disk that contains the FrontPage source of my web site, a copy of Macauley's Lays of Ancient Rome. Why is it that I can start a local search in XP for that file, then go out onto the Internet and start a Google search for it and find it on my site among hundreds of millions of pages on the Internet before XP Search finds it on my local hard disk?
One PDC session was on known security vulnerabilities—not just in Microsoft products—across the computer world. All of those shown have been found and in theory eliminated, but some of them were frightening.
As an example, Microsoft showed a SQL database dummied from a real one. This one held book reviews and ratings. With a few operations, they were able to show how all the ratings for books by particular authors could be inflated, and words like "not recommended" turned into recommendations, while rival works were given bad reviews. All this was done from outside the database by SQL Injection attacks. Most of those holes were generated by buffer overflows.
Another PDC session was on the upcoming Service Pack 2 (SP2) for Windows XP that was so popular it was repeated, along with a closely related security panel (http://msdn.microsoft.com/events/pdc/default.aspx?pull=/ library/en-us/dnwxp/html/ securityinxpSP2.asp). The bulk of the session was about security measures that will be incorporated in SP2, and how a number of bugs can be fixed. The most common exploit involves buffer overflow.
Buffer overflow involves filling an input buffer with more information than it can hold, then including at the end a means of directing the computer to issue itself instructions of your own. This sounds complex and is; unfortunately, some highly gifted crackers have generated scripts usable by the malicious but nongifted. The scripts generate buffer overflow exploits to give the script kiddies control of machines even though they don't really understand how they work.
After about a half an hour of explanations on how buffer overflow exploits work, a light dawned, and during the break I went up to talk to the experts. "Wouldn't all this be prevented if the compiler did strong type checking and range checking at compilation?" I asked. The answer was long but essentially "Yes."
Twenty years ago we had the language wars in small computing. They raged on in BYTE and DDJ and other magazines seriously devoted to small computers, even if they were largely ignored by the old line "big iron" computing journals.
On one side were computer scientists like Niklaus Wirth who advocated strongly typed languages and range checking, insisting that their compilers be recursive: the compiler would compile itself in its own language. The compilers were very picky, and you had to be careful what you told them lest they issue compile-time errors. Once the program was compiled and the program would run, however, you had good reason to believe that it was doing pretty much what you had intended that it would do—and exploits like buffer overflow were impossible since input lengths out of range would not be accepted, and you couldn't compile the program if you didn't specify the acceptable size.
On the other side were advocates of the language known as C, led by Brian Kernighan and Dennis Ritchie. C was more assembler than computer language, and the C compiler would compile almost anything, including nonsense like sending off data of one type—say an integer—and having it return as another data type, such as a floating-point number. Worse, it could and did confuse data with program instructions and it was up to programmers to simulate the compiler in their head as they wrote the code, so that they wouldn't send the program into a data stack looking for instructions. Perhaps I exaggerate, but not much.
The language debates were heavy for a while. Artificial intelligence experts such as Marvin Minsky sided with the C people (although AI used languages like LISP and APL). Minsky once accused me of wanting to make programmers put on straightjackets before they could write code. The watchword was freedom! In the jokes about shooting yourself in the foot (http://www-users.cs.york.ac.uk/~susan/joke/foot.htm ), the line for Pascal (Wirth's strongly typed range-checked teaching language) was "Pascal won't let you shoot yourself in the foot," and the C programmer's answer was "Sometimes systems programmers have to be able to shoot themselves in the foot!"
Of course that's nonsense. Nobody really wants to shoot himself in the foot or incorporate dangerous vulnerabilities in systems code, and if you think you have to do that, you have not properly thought out what you are trying to do.
C won out as the systems programming language of choice, despite its obscurity (you still have to simulate the compiler in your head when you write C code; the compiler won't catch quite a number of easily made, but very serious, errors of the type change and out of range variety) and its near unreadability (it is notoriously true that an incoming code manager often finds it easier to rewrite from scratch than to understand his predecessor's C code). I say "despite," but perhaps I should be saying "because"—C is also known as the guru programmers' employment insurance language.
C won largely because the hardware during the critical period of the language wars was slow and clunky, and C would compile fast—minutes to hours rather than hours to days on big programs—and generated code that ran significantly faster than programs written in Pascal, Modula, and Oberon.
In fact, that latter isn't true. Structured program languages might generate slower runtime code, but they also indicated how you could improve runtime performance by hand-optimizing critical code loops and such. Mostly the speed advantages of C were in the code-writing phase of a project. On the other hand, it could sometimes take longer to debug a C program than to write it and get it out the door using Pascal and its successors. Structured languages made you think—you did have to wear the straightjacket and program planning took a lot longer—but once you had the structure set right, the actual code writing was comparatively quick.
I see that I'm fighting the language wars again, and that isn't quite my purpose just now. Just say that C won because it was faster back in the days when 20 percent faster might mean hours, not a few seconds.
My point was that if Windows XP had been written in a language in the Pascal/Modula tradition, rather than in the C tradition, there would have been strong type and range checking, and buffer overflow exploits would be impossible.
Interestingly, there was considerable agreement (with quibbles; I don't want to misrepresent anyone). But, I was told, there are range- and type-checking compiler switches in C#, and one of the fixes proposed for SP 2 of Windows XP is to recompile large chunks of the code with those switches turned on.
"Shout Hallelujah!" said I. Then came discussion. The problem, one senior Microsoft executive said, was that if they weren't careful, they would end up with a Service Pack larger than the original code distribution. For some reason, he thought that would be a Bad Thing.
I have been thinking about that ever since, and he's wrong. Replacing every line of Windows XP with more secure code would be a Good Thing, and it wouldn't be expensive. It would save Microsoft money in the long run.
The distribution cost increment comes from needing more servers, particularly when the Service Pack first comes out. The cost of storing 600 MB isn't all that much larger than the cost of storing 40, but if a lot of people want it at once, you will need more servers doling out the code.
Otherwise, the costs are pretty trivial. On the user side, sure, it takes longer to download 600 MB than it takes to download 40, but the return is well worth it; and, of course, you aren't going to download either if you don't have a high-speed Internet connection. If you're on dial-up you're going to order the disk, and it certainly costs little more to fill that CD than to ship it mostly empty.
I am convinced, and I am persuaded that many of the Microsoft gurus are convinced, that many of the XP security flaws will go away when the code is recompiled with proper range- and type-checking enabled. Of course, there will be programming issues: You have to generate code to handle what happens when an illegal type change or out of range error is detected. But again, those costs are small compared to what happens when SoBig or SQL Slammer hit the Internet.
I hope Microsoft will see it this way. And I can't resist saying it—I told you so. Twenty years ago.
The book of the month is Neal Stephenson's Quicksilver, an enormous 900-page novel that tells the story of the ancestor of the fictitious hero of Cryptonomicon. It's set in Restoration England, Counter-Reformation Europe just after the 30 years war, and the Americas in the time of the Salem Witch trials. You get the London Plague and Fire, Leibnitz versus Newton on the invention of calculus, the founding of the Royal Society, the second Siege of Vienna, and a partridge in a pear tree. It will take you a while to read it, and you'll love every minute.
The second book of the month is Paul Johnson's ART: A New History, and that will take you another two months to read. You'll be a better person for having done so. It's also very readable.
The computer book of the month is Michael Howard and David LeBlanc's Writing Secure Code that carries a cover blurb from Bill Gates: "Required reading at Microsoft." It discusses both philosophy and techniques, it's huge, it is not light reading, and I highly recommend it for anyone who has to deal with IT matters.
The game of the month remains Dark Age Of Camelot with the Atlantis expansion. That's fun. I had intended some extensive observations on computer game trends, but that will have to wait. I do wish one of the companies would go back to realistic turn-based strategy/tactics games simulating modern warfare. I'm weary of these "real-time" games in which three days of battle take place in an hour and the challenge is to think and click faster than a computer. That's no fun.
DDJ