Dear DDJ,
I've always enjoyed reading Al Stevens' columns, in part because his name is shared by a manufacturing consultant from whom I learned a lot. I particularly liked his October 1998 column on getting a passport.
Many years ago, I renewed my passport for a trip. I did the paperwork at the Mountain View, California, post office. A few days later, I was attending a training session in San Francisco. I got a message from a clerk at the San Francisco passport office. How he found me, I will never know. He was concerned that if he mailed my completed passport, it might not reach me in time for my trip. He asked what he should do. I ditched the training session and went to the passport office that afternoon. I asked for the clerk by name. He gave me my passport. I found it very refreshing that a government bureaucrat took the time to think and felt "empowered" (a '90s term) enough to act on his opinion.
The timing wasn't really that critical. The passport would probably have reached me in time. But that isn't what's important. Al's column will also encourage me to get my passport renewed now, before I really need it.
Don Mackenzie
SocialNet Inc.
Dear DDJ,
I enjoyed Randall Cook's article "Real-Time Sound Processing" in the October 1998 issue. I'd like to pass on a couple of additional hard-earned tips I've learned from both writing and using Windows multimedia drivers that might be useful to DDJ readers. Both of them have to do with preparing and unpreparing headers in Windows code, and although I think Randall is avoiding both of the problems, I would still make a couple of nit-picky changes to his code.
The first is that, although Microsoft's documentation does not say that unpreparing a recycled header is required, some Audio Compression Manager (ACM) drivers certainly appear to make that assumption. Without an additional unprepare call, some ACM drivers leak memory and/or act improperly. If you are directly recording formats other than PCM, the sequence I would use to recycle a buffer is:
waveInUnprepareHeader(hdr, ...); waveInPrepareHeader(hdr, ...); waveInAddBuffer(hdr, ...);
Even if you aren't explicitly asking for a nonPCM format, it pays to be careful because the ACM manager can insert ACM drivers into the data stream if necessary to supply formats that your hardware will not directly support. Probably the best example of this would be a sample rate converter that might get inserted if your card supported only 22 KHz, but you asked for 44 KHz.
The second and more important comment is that failure to unprepare a header is bad -- with a capital "B." Under Windows 95, the unprepare is used by WINMM to release descriptor table entries. The translation between WINMM (32-bit) and MMSYSTEM (16-bit, which is where the drivers reside) requires allocation of two thunking descriptors per buffer: one for the header and one for the block. Failure to call unprepare properly in a long-running program can bring the system to its knees once you've run out of the 8192 selectors available. The reason this usually becomes a problem is that waveInReset does not return the buffers immediately if you have a WindowProc callback, and by that time, the waveInClose has already happened. If you are waiting to unprepare the headers in the callback, you open yourself up to this potential problem because the waveInUnprepare calls will fail with an invalid handle, and two more LDT entries will be lost. In Randall's example, the problem doesn't exist because he unprepares the headers in one fell swoop before the close. (Note that the problem isn't being avoided because he's using a callback function, since his function just turns around and posts messages anyway.)
My objection is to his comment, however, in WindowRecorder::Stop that it is "reasonable to ignore errors" since we're closing. I would put some error checking code around every prepare and unprepare for the aforementioned reason. Even if you don't think the problem can happen in your code, just throw an exception to assure yourself!
Otherwise, it was an excellent article. Keep up the good work!
Andrew J. Gryc
http://www.iex.net/~gryc
Dear DDJ,
I enjoyed Al Stevens' C Programming column about his trip to SD Asia in the October 1998 issue of DDJ. However, I have to disagree with him on one topic -- I hate to admit it, but Java is still and by far superior to C++ in the area of standard libraries.
I like the ANSI C++ language. I like templates and generic programming, and I lack them when I am programming in Java or Visual Basic. But I think the C++ standard falls short in what should be the real purpose of a standard -- allowing the interoperability of components, freeing developers from their compiler idiosyncrasies, putting the bases for a free market. Ironically, the C++ standard is more useful in a BG dream world, where everyone has an Intel PC on his/her desktop and uses only and forever Microsoft products, than in a multicompiler and multivendor world.
Graziano Lo Russo
lorusso@acm.org
Dear DDJ,
I just read Tim Pfeiffer's Online Op-Ed "Windows DLL's: Threat of Menace" at the DDJ web site and I agree. A major problem in modern software is the massive code bloat proliferated by the Windows/Intel symbiosis. The hardware grows to make way for bigger programs that grow to require more hardware. One of the areas of software development that is largely overlooked is a major player in the ever increasing size of things. Code libraries and link editors still function in pretty much the same way they always have. We need a new type of linker that can analyze the object code and embed and static link objects or create a dynamic link depending on estimated usage of a DLL's function. This should allow the compiler to produces slightly larger .exe files that do not depend on a large number of custom dll files and that makes maximum usage of the common dlls. What we really need is a linker that is as sophisticated as the current compilers and operating systems.
Gary Clouse
gclouse@mail.state.tn.us
Dear DDJ,
I have been following your discussions of software versus hardware encryption with some interest. The average computer user, however, wants neither to be an auto mechanic nor a mathematician. He only wants a machine he can turn on and use reliably and securely every time. (For the present, I will trust that man is still master of the machine!)
Personally, I want to encrypt not only the message, but want to conceal my identity from prying eyes as well, so that eavesdropping will not reveal with whom I am in contact.
This will require a hardware solution rather than software alone. And it will, at least in its final stages, have to be developed, manufactured, and marketed outside the United States to obviate archaic laws.
Let's see a PC card offering ultimate security to every computer user.
C.J. Hinke
cj@sala.icn.net
Dear DDJ
Regarding the Year 2000 problem: For free source code in C for Y2K calendar date- related functions, readers can visit my web page at http://www.geocities.com/ siliconvalley/heights/3836, which contains calendar date functions based on using Julian Day Number algorithms used by astronomers for dating long period recurring events accurately. These functions can be used with proper offset to say 1900-01-01 to use a single six-digit absolute number of days in date fields and provide easy ways to convert to calendar date in ISO format (yyyymmdd) or Julian day of year format (yyyyddd) as appropriate.
By the way, the IBM MVS TIME supervisor call (SVC) returns the date as a CYYDDD "packed" decimal format in a 32 bit register (actually digits 0CYYDDDF, where there is a leading zero, a trailing sign four-bit "digit" required by the packed decimal format on the 370 series CPU, and the other digits are four-bit digits interpreted as digits zero through nine, inclusive).
There is space there for expansion. A "C" value of zero indicates the 20th century, a value of 1 the 21st. I presume the format will change before another 100 years have passed. Unless the format is already in "packed decimal" format, a simple solution for Cobol programmers at least, on MVS platforms, would be to convert all character (EBCDIC characters on that platform) dates to packed decimal, and store the full mmddyyyy date value in just four bytes instead of six bytes for the six-character date. To make it easier on the source, expend another byte to accommodate a sign digit to make the date 0mmddyyyyF and you're still a full byte ahead.
Bruce E. Hogman
bruce.hogman@travel.eds.com
Dear DDJ,
In "VerCheck: Discovering Component Version Numbers" (DDJ, March 1998), John Graham-Cumming suggested using the FileVersion string resource to determine if a component is up-to-date. I think this statement is incorrect.
The Microsoft setup guidelines (for installation programs) say to use the binary FILEVERSION representation for version checking. InstallShield and my own programs work like this.
There are other reasons for using the binary FILEVERSION representation, instead of the textual one. Often the FileVersion string resource is not identical to the binary FILEVERSION. And while the binary FILEVERSION is more exact (2.20.4054.1), most textual representations are not that accurate (2.20.4054) -- they are more like a hint to the customer (who can check it via right-clicking the mouse).
I've seen DLLs where the FileVersion and binary FILEVERSION showed absolutely different numbers. Sometimes developers want to hide changes from the customer and change only the binary FILEVERSION so the setup programs update the files. Also, there can be more than one textual FileVersion -- one for each language. Finally, there's no guarantee that FileVersion is a number at all. Any text can be in it.
Thomas Fleischer
Thomas.Fleischer@datev.de
John responds: Thanks for your note, Thomas. Yes, FileVersion is inappropriate for the purpose you describe. However, what you describe wasn't my intent. My purpose in using the string-based resource is that it is the same information users get by viewing the file properties in Windows on a specific file. The purpose of VerCheck, you recall, was to help technical-support organizations quickly get the information from users. Hence, the string resource was appropriate.
You are absolutely correct regarding the Microsoft setup guidelines, and if you are going to do version checking on installation, you need to use the binary version. In addition, I would recommend that anyone sending out software have their QA department ensure that the binary and string versions match (we do that for completeness). And yes, there can be one textual FileVersion for each language. I assumed English only.
Perhaps you could write a simple addition to VerCheck that gets the binary version, formats it in an appropriate way, and outputs it as third column in the CSV file that VerCheck creates. Then a QA organization could use VerCheck to check binary-to-text compatibility. This is a simple enhancement that I would have thought most DDJ readers could make.
DDJ