Letters

And the Winner is...

Dear DDJ,

Regarding Wesley Stout's Y2K patent application mentioned in "News and Views" (DDJ, October 1998): This gets an award for the "U.S. stupid patent department" if it gets a patent! Not that it's a silly idea, it's just that a DDDCYY format date has been around for at least 20 years. I worked on life insurance systems (which have always had to handle dates beyond 2000, and before 1900) that had this format in 1982, and they were already old systems! I personally have probably written >1000 modules using this format, not to mention having processed a few billion dates in that format...

I know the U.S. patent department will patent anything, but this (if possible) is creating a new area of silliness.

Ian Quick
[email protected]

More on Win32 Debugging

Dear DDJ,

Fritz Lowrey's article "Examining the Win32 Debug API" (DDJ, November 1998) describes how to grab OutputDebugString text with the specific purpose of debugging NT services. Although this approach works, it is overkill. Since v3.51 NT has provided ODS text as a memory-mapped file and manual reset event pair so that it could be viewed w/o running under a debugger. This technique works with services, as well as any other type of process or application.

For a discussion of how this works, see my article "A DBWin32 Debugger for Windows" (C/C++ Users Journal, October 1996). You also can grab the latest version of DBWin32 (w/ source) at http://www.halcyon.com/ast/swdev.htm.

Andrew Tucker
[email protected]

Quicksort Improvements

Dear DDJ,

Jon Bentley and Robert Sedgewick's November 1998 "Algorithm Alley" presents improvements to the standard Quicksort algorithm. Another surprisingly useful and easy to code variant of the standard Quicksort algorithm to mix a simple bubble sort into it. As the left and right pointers move toward the center of the array, have them do pairwise swaps with the array position they previously read and the one to which they are moving. That is, instead of simply using lft++, use {swap(a[lft], a[lft++]); lft++} and rgt -- becomes {swap(a[rgt], a[rgt--]) in their respective loops. This assumes that swap() will do the proper testing.

Because Quicksort takes advantage of any existing sort order, this little trick can make each succeeding recursive call to a partition run faster than it would have without the sort. An even better improvement can be had if the hardware supports a pairwise-exchange function to allow us to build a specialized version of swap().

Joe Celko
[email protected]

Ah Hah!

Dear DDJ,

Regarding the Microsoft's AARD code described in "Examining the Windows AARD Detection Code," by Andrew Schulman (DDJ, September 1993): This cinches it for me and maybe for others as to Microsoft's intentions. The error code #4D53 seemed suspicious in the alphabetic ASCII region (when treated as hex character codes). Sure enough, 4D is "M" and 53 is "S." A coincidence? I think not.

Todd Stephan
[email protected]

WinCE Terminology

Dear DDJ,

I am writing in response to James Wilson's article "Windows CE Device Driver Development, Part I" (DDJ, October 1998). As I work at Microsoft documenting device driver development for Windows CE, I was very interested to see the article. I was quite pleased with the overall message conveyed in the article, and I look forward to reading Part II.

Nevertheless, I feel that a clarification is in order. James spends a fair amount of space (on page 72) discussing the meaning of the terms "installable device driver" and "built-in device driver" as they relate to categories of device drivers supported within Windows CE. That attention is certainly warranted, as those terms were indeed confusing. However, we have changed them in version 2.x of Windows CE, for reasons discussed later. The new terms are "stream interface driver" and "native driver," respectively. I realize that in the world of magazine publishing there can often be substantial lead times between when articles are written and when they are published, so it is not surprising that James wrote his article in part on the basis of documentation that has since changed.

It is worthwhile to explain some of the history behind this decision. Much of the early Windows CE documentation was associated with the first Windows CE device, the Handheld PC (H/PC). That platform, although produced in several slightly different varieties by different manufacturers, was well defined in the sense that all H/PCs had a common set of operating-system services, and all contained a common core set of peripheral devices. Those similarities meant that it made a great deal of sense for each class of device driver, corresponding to the classes of built-in devices common to all H/PCs, to have a custom interface to other parts of the Windows CE operating system -- primarily Graphics, Windowing, and Events Subsystems (GWES). By doing so, we were able to standardize the behavior of those devices and provide a common code-base for H/PC manufacturers to work from. Recognizing that there was a need to add arbitrary new device drivers, both for third-party hardware vendors and for addition hardware added by H/PC manufacturers to their own Windows CE products, Microsoft also implemented the "installable" device-driver model as James discussed. Thus, in the Windows CE 1.0 timeframe, there was an excellent correspondence between the term "built-in device driver" and the devices that were actually built into the first generation H/PCs. Similarly, there was good correlation between the term "installable device driver" and any after-market or additional devices that could be connected to an H/PC.

As Windows CE evolved toward version 2.x, however, many of the drivers included in typical Windows CE products changed to use the "installable" driver interface rather than their own special purpose "built-in" interfaces to GWES. Display drivers who wanted to manufacture PC Card-based display adapters to write drivers for their devices are a prime example of this. Such changes took place for several other classes of device drivers as well. Thus, the terms "installable driver" and "built-in" driver ceased to have a good correlation between the interface model used by the drivers themselves, and exactly the sort of issue that James discussed in his article resulted.

Thus, for the current generation of Windows CE documentation, the terms have been changed. Now the terms to describe Windows CE device drivers are related to the types of interface between the drivers and the rest of the Windows CE operating system. The terms no longer have any bearing on whether the device served by a particular driver happens to be built into a Windows CE product, or is added later by an end user. If a device driver uses a custom interface that is native to that type of driver, then the driver is called a "native driver." Conversely, if a device driver uses the stream-interface functions (FileOpen, IOControl) it is called a "stream-interface driver."

As the lead writer for Windows CE device driver documentation, I bear much of the responsibility for not identifying this issue and resolving it earlier. I am very interested in continuing to improve our documentation and am very interested in any input readers may have. I am writing this letter, however, in an attempt to forestall any additional confusion that may be caused by the explanation in James's article. I am concerned that developers who read James's article prior to obtaining the Windows CE Embedded Toolkit or Visual C++ products may expect to see the old device driver terminology, which no longer matches what is present in the product documentation itself.

Jason Black
[email protected]

Real Real-Time

Dear DDJ,

Your October 1998 issue on real-time computing brought back many memories of things learned, some the hard way. I've been writing software for 35 years, with some of it being event-driven, real-time applications. My most recent system is an environmental sound monitoring system with multiple test points spread over several miles. The Windows-based PC controller communicates with the instruments via spread spectrum RF modems. It also uses a Davis Instruments system similar to the one Richard Smith mentioned in his article "A Real-Time Weather Station."

The definition of "real time" needs careful examination. Robert Krten's definition in the opening paragraph of his article "Device Drivers & Real-Time Systems" (which I enjoyed very much, by the way) gives a reasonably good flavor but is lacking some important ingredients. Rather than just responding to "events in a deterministic (and, hopefully, fast) manner" the designer has to determine if the loss of data is important. The system can be both deterministic and fast and still lose information. Is this important? It depends on the application.

Real-time instruments (that is, FFT spectrum analyzers) seem to fall into two categories. Manufacturers will call their instruments "real-time" but that can have two very different meanings. The better, in my opinion, means no loss of data. That is, they can process a buffer to calculate and display its FFT as fast or faster than the system samples its next buffer. However, some manufacturers call their system "real time" because the system gives the visual appearance to the operator of always displaying results. The system might be dropping out 20 percent of the data, but if the display keeps updating with no noticeable blank periods, then it's real time by their definition. If your bank didn't credit you with 20 percent of your deposits but handled everything "in a deterministic (and, hopefully, fast) manner," would you be happy?

To me a system is real time if it can respond to events (time is just one type of event; so is a switch changing state) and do what needs to be done without having to resort to some kind of special processing to deal with more events than it can handle. Obviously, if you throw events at a system fast enough, it will reach the point where it can't fully process everything. At this point, the system stops being real time. This does not mean the system itself should quit, just that it has to resort to some method, typically based on priorities, for dealing with the issue. For example, if a real-time process control has to deal with monitoring reactor pressure, updating a display, and handling other events, it would, I'd hope, continue to monitor the reactor over updating the graphics display when other events make it busy!

Because our major software product can interact with other computer systems, we occasionally get requests that the information in the Windows application be updated in real time. That prompts us to ask what they mean by "real time." What this usually means is they want the data to quickly get into the application from the other system. If a few seconds is "quickly," then it can be done.

Windows, of course, is not a real-time operating system, and woe to any programmer who thinks otherwise. Even its multitasking capabilities are basic; it relies on cooperation between programs. If you're not careful, you can easily write an application that hogs the CPU and prevents other apps from running.

If you're careful, keep everything in one application, and don't run other Windows programs at will, VB can do a fairly decent job of handling various tasks on an event basis. The environmental monitoring program mentioned earlier is a VB app. We do sampling from multiple instruments and the weather system, write data to disk, update a display map, print reports, and plot past data in "real time." Each midnight, the system also creates the new day's disk files and closes out yesterday's without loosing a beat.

Beware of the time event, however. It doesn't work as you might guess. You can set up a timer event for, say, one second, but it doesn't work that way. Robert Krten discussed latency and other aspects of time, so I won't repeat them. However, do be careful when using the VB clock, because while you can read the time to something like a millisecond, it really only "ticks" in something like 55 ms increments (I'm writing this from memory, so I may misquote a bit). In any case, you can't get a nice, even one-second interrupt!

We wanted one-second sampling, so we added a National Instruments board and tied a one-second time driven by line frequency from the board to a spare hardware interrupt. The board and companion software makes it easy to do. The result was an extremely reliable one-second sampling interval. I was intrigued by Robert Krten's idea about using the serial port to generate a timer event. I need to think about that for a while. It seems to me that it may need constant "feeding" to keep up the data stream that generates the clocking. I wonder if it'll maintain its interval over long time. But the price is certainly right.

The one piece of advice someone should get from all this is that when the term "real time" is used, be sure there's agreement on the definition, or you may not get what you expect.

Norman R. Dotti, president
Knorr Associates
[email protected]

Errata

In Figure 2 of "Smart Cards and the Open Terminal Architecture," by Edward K. Conklin (DDJ, December 1998), the upper-right box should read "Nonvolatile Extended Memory (Module Repository)." The lower-right box should read "Nonvolatile Extended Memory (Databases)." We apologize for any confusion.

DDJ