Aw, Who's Counting?

January is always a challenge. While there is definitely a sense of anticipation for what the new year will bring, there is also last year's leftovers. Projects, promises, and the best of intentions wind up on your to-do list, subject to the yearly triage of a new appointment calendar. For those of us who have merged into the bitstream for all our appointments and planning, the ritual includes backing up files and wiping out all those electronic artifacts of the last 12 months.

In keeping with the new year's urge for cleaning off the desk and deleting bloated directories, this month I'll be updating some of the threads we've touched on in the last year, including some of your feedback on this column. While this does mean putting off my rant, er, discussion of WinCE for another month, I trust you'll survive the delay. After all, my concise preliminary verdict is that WinCE is irrelevant to most embedded applications. And if you are working on that one-in-10,000 application that could profit by using WinCE, there's probably little on the subject I could add that you haven't already discovered through the embedded school of hard knocks.

War is peace. Justice is perverse.

When Microsoft introduced WinCE 2.0 at the fall Embedded Systems Conference, it was with the tag line of "new directions in embedded systems." I took this to be an implicit admission that the product was inappropriate for most existing embedded applications and let it go at that. Recent Microsoft pronouncements, however, have demonstrated a rather Orwellian approach to redefining common technical terms.

Take "product" for example. One of the key aspects of Microsoft's response to those annoying Depart-ment of Justice matters is the company's insistence that Internet Explorer is not really a product, but instead an enhancement to the Windows operating system. Indeed, the guys and gals in Redmond are so caught up in the thrill of enhancing operating systems that they are now offering versions of Internet Explorer for the Mac, Windows 3.1, and (gasp!) Unix.

Being the word monger I am, I couldn't help noticing that the employees extolling the virtues of the IE strategy had those old fashioned titles, "product manager" and "group product manager." You would think they would change those job titles before the Justice lawyers can grab some business cards as evidence. I would suggest titles like "enhancement manager" and "group un-product manager" to really confuse the prosecution. Following up on the Soviet style of naming things could really help in motivating the troops as well. Miss your product milestone and you could be whisked off to the gulag and pronounced an "un-developer."

Another classic Soviet strategy was to loudly denounce your critics, and Microsoft has recently tried that approach as well. The company filed an attack on the Justice Department's "perverse" anti-trust stance. To show just what technoweenies they were, they not only filed their response in court, but they posted the response on their Web site. Take that, DOJ cyber-peasants!

Alas, it didn't take long before reporters were calling Microsoft to find out why they couldn't access the file using Netscape browsers. Oops. In what has got to be the lamest excuse offered since that high school classic, "the dog ate my homework," reporters were told that the person who normally posted files had been stranded by winter weather, and the person drafted to do the Web publishing had made a little mistake in the file that disabled Netscape access. Sorry, it was an accident. Really. Bad dog! Bad dog!

In retrospect, I can believe some parts of Microsoft's story, but I don't understand why their regular Webmaster couldn't handle things. I thought all Microsoft employees were issued laptops and Borg-like T-1 implants when they joined the company. The notion that a naive user could generate a Web document that was unfriendly to Netscape browsers, on the other hand, is all too believable. Sure, using plain HTML to post a legal brief is the way most civilians would handle things. But making the default behavior of their Web-authoring products incompatible with Netscape would certainly be consistent with Microsoft's past performance. The big mystery is how this episode is supposed to persuade the Justice Department lawyers that they are mistaken about Microsoft's predatory tactics.

Want a Headache? Try Buffering.

Back in the July 1997 column ("Oh, Those Pesky Details!" p. 9), I offered to reconsider my skepticism on Microsoft's ability to handle security issues, and challenged readers to send in examples of security areas that the company hadn't bungled. The resulting silence was deafening. It's not hard to understand why.

Consider: as I write this, the latest hole in Internet Explorer has shown up on the 'Net. It seems that feeding IE 4.0 a "res://" address longer than 256 characters causes the browser, er, OS enhancement to choke. Actually, that's not the real problem. The nasty part of the bug is that the trailing part of the buffer overrun stays resident in memory. If that string should happen to contain instructions and somehow get executed-well, you get the picture.

While the damage control experts were quick to point out that the bug hadn't been exploited on any known Web sites and no customers had reported problems, I didn't find the response all that reassuring. The folks who found the problem were able to demonstrate it adding a comment to an autoexec.bat file, but it wasn't hard to see that more dangerous and more subtle attacks could have been launched instead.

If you're wondering about the embedded implications, consider that this bug is just the latest in a series that have been found by customers, not Microsoft engineers, and the bug was only caught after the company shipped all those IE 4.0 CDs. So the 64-kilobyte question becomes: if this litany of bugs is what happens to a high-profile (un-)product like IE with a large support staff, how secure do you suppose your little embedded WinCE application will be?

Dead But Not Forgotten

One of the problems with Microsoft's aggressive moves is that competitors occasionally get spooked into making stupid moves. A case in point: Sun's recent gaffe in posting a "cooked" Java compiler. The folks at Sun were so pleased with their apparent ability to beat Microsoft's performance on NT platforms that they forced a public disclosure of a major screwup.

The problem first showed up when the folks at Pendragon Software were testing the Solaris 2.6 compiler's performance on their CaffeineMark 3.0 benchmark software. Noticing that performance in one area had increased about 300 times, they decided to investigate further. Imagine their surprise to discover that 600 byte-codes of their benchmark were lurking in the megabytes of compiler code. It was almost as if the compiler were looking for that 600-byte sequence and then "optimizing" the code out of existence. Indeed, when they changed the order of arguments for a short-circuit evaluation in the code so that the 600-byte block no longer matched, the Sun compiler suddenly reverted to the old performance range.

Given the wide range of CaffeineMark values, it seemed unlikely that anyone at Sun had been deliberately trying to fool people. Unfortunately, the company initially wouldn't back down on the overly optimistic results, and the folks at Pendragon felt obligated to go public with the situation.

Sun's eventual explanation was that by some unexplained process, an engineering test version of the compiler had been accidentally released. The cooked version of the compiler was just meant to demonstrate how dramatic the results would be with a compiler that aggressively optimized programs with dead-code elimination techniques. While not entirely satisfying, the explanation is just wonky enough to be believable. After all, how many times have you been blind-sided when your management took an internal demo version of your software to the customer?

Unfortunately, embedded systems are inclined to use just the sort of ostensibly pointless memory accesses that a too-smart compiler could sabotage. While most developers are used to guarding against such problems in C compilers, it's worth remembering that the problem will be with us in Java projects as well.

Some Readers, Plus or Minus

It's fitting that a column devoted to the topic of the numerically-challenged should end with reader feedback on the alleged Year 2000 crisis. I half expected to be pilloried for my skeptical comments in the November issue, but most of the e-mail I received was positive. I was called to task for my imprecision on a few points, however.

One reader wrote to lament my use of the phrase "millennium bug" for improper handling of the year 2000 rollover. The millennium, you see, won't actually arrive until January 1, 2001. This has something to do with the early Christian calendar being programmed in Fortran, where indices originate at one. If only they had started counting with year zero (and used C), we would be able to celebrate the arrival of the millennium on January 1, 2000. Oh, the benefit of technical hindsight!

Actually, I have always taken the populist position on this issue, and interpreted the matter as an interval of a thousand years. I don't worry about the base of the pointer, only the offset. In this case, we can expect that both computers and people will go nuts at the beginning of 2000. Admittedly, they may still be going nuts at the beginning of 2001, but by then it will no longer be a millennium condition, just normal flaky behavior.

Although no one was gauche enough to phrase it this way, some of the responses strongly hinted at the incompetence of either managers or programmers when it comes to reported Y2K problems. One reader remarked that his bosses were unimpressed at his assurance that he didn't accept or use year information in an application. They still wanted a formal Y2K audit performed so that they could appear responsible to their customers.

More pragmatic was the comment of Garth Wilson at DRE Communica-tions, who remarked that he had programmed some applications to assume that all years greater than say, 65, would have a century offset of 1900 and other values would use 2000. His comment that the test only took a single line of code wasn't the disturbing part. What got to me was that we had already seen reports of ATMs that were unable to handle cards with "00" expiration dates. Why did the original programmers make this situation into a problem? Are we really worried about someone inserting a Visa or MasterCard issued during the McKinley administration?

Demonstrating that students often ask better questions than we old fogies, Cameron Kellough, a self-described "soon to be graduating Electrical Engineer" at Harvey Mudd College, queried me on Y2K problems related to Global Positioning System satellite data. It was, of course, news to me. Upon investigating, I found that the GPS satellites have a week counter that rolls over roughly every 20 years. So GPS receivers will be tested with the first "EOW" roll-over transition at 0000 hours, UTC, on August 22, 1999. It remains to be seen how serious this case will be.

At least the EOW situation was documented in the system specification. The Air Force only recently discovered a "GPS Millennium Bug" that may cause some GPS receivers to get confused near the Y2K transition and reset their date information to a stored reset value. This date could be in 1980, or 1984, or the date the unit was first operational. Yikes! If you have a stake in GPS technology, you'll want to check the status of things at www.laafb.af.mil/SMC/CZ/homepage/y2000/ .

Perhaps the best Y2K comment of all came from Don Glaeser of the Baylor College of Medicine. He noticed the dichotomy between the common usage of Y2K to indicate the year 2000, and the established computer tradition of using "K" to indicate powers of two. Hence his tongue-in-cheek concern that my usage of Y2K was actually an attempt at procrastination, to put off dealing with the rollover issue until January 2048.

While there is merit to his observation, in practice the binary/decimal distinction is ineffective against management thinking. I've tried the same pitch in negotiating salary figures, for example, but without success. It seems that when managers encounter figures ending in "K," they simply keep rounding down until either the number or the engineer vanishes. It's a brutal but effective approach.

Finally, let me take this New Year's opportunity to thank all of you who took the time to send in comments this past year. I don't always have time to reply, but I do appreciate the feedback. Even the messages with anatomically impossible suggestions (which I forward to Editor-in-Chief Lindsey Vereen for his amusement). The other, more charitable responses I consider when plotting future columns. You've been warned.