Dear DDJ,
Bruce Schneier's article, "The Cambridge Algorithms Workshop" (DDJ, April 1994) lists three conditions under which an encryption algorithm should be secure. There is one class of encryption algorithms that not only satisfies these conditions, but has been mathematically proven to be impossible to break--those algorithms that allow the use of a key that is longer than the plaintext to be encrypted. In addition to being absolutely secure, these algorithms are the simplest to implement and the fastest to execute. The proof of unbreakability is quite simple and based on the following theorem.
Theorem: Any binary number N, when XORed with a random binary number R, produces a random number.
Proof:
If ciphertext C1 is unencrypted by XORing it with the random sequence K1, then we get plaintext P1. If ciphertext C1 is unencrypted by XORing it with cipher- text C2, then we get plaintext P2! Thus we see that, given any plaintext P of length ten, there exists a key that will produce P when the key is XORed with C1. That is, C1 could be unencrypted into any ten-character message, given the right random key.
One criticism of this type of data-encryption algorithm is that to encrypt ten megabytes of plaintext you need a random-number key that is ten megabytes long. In this age of CDs and laser disks, however, distributing large keys to those with whom you correspond is no more difficult than distributing short keys.
William D. Hause
Bryan, Texas
Dear DDJ,
After reading about Al Stevens's telephone experience (DDJ, March 1994), I can say only one thing: Switch to MCI! All the instructions I ever need are printed on the back of my MCI credit card, and they work. Access to MCI is (almost) always a local call, and when it's not, the 800 number works. No distance is too long or too short. My wife claims that she once had to use the 800 number because she got a private party on the other one, but I think that either she or the local telephone company screwed up and she got the wrong number.
AT&T has called me several times to offer me $50.00 to switch. I have refused because of a feeling that AT&T is the IBM of the telephone world. You know: Do it our way or don't do it at all. Reading the instructions on a lot of motel phones made me suspicious. Reading your article has confirmed them.
Long-distance telephone rates are lower than they have ever been, and they keep falling. Back in the early '80s, when I was living in Germany, it cost three times as much to call the States from Germany as it cost to call Germany from the States. Don't knock Judge Green. The best system in the world has gotten better, but it has changed. Switch to a company that understands the new situation.
Clair J. Robinson
Minneapolis, Minnesota
Dear DDJ,
In his article "Software Testing Cycles" (DDJ, February 1994), Scott Bradley prefaced his approach to automate testing with the phrase, "QA engineers who are not constrained by time_." In doing so, he announces that he is not dealing with the real world. Time constraints are often the reason people buy automated testing tools. It's time to admit that writing programs to test programs doesn't work and never has. Test- scripting tools are not news, they've been around for decades--yet the majority of testing is still manual. Why?
Scott also asserts that end users are consigned to using recording for their testing. The flaw in this conclusion is that users must be closely involved with test design from the earliest stages, yet recording is not possible until the application exists. Further, as the application moves into production and then maintenance, users bear the greatest responsibility for testing; with unstructured, sequential recordings, maintenance is almost impossible.
Linda G. Hayes
AutoTester
Dallas, Texas
Dear DDJ,
The May 1993 article by Joseph Newcomer, "Modeless Dialog Boxes for Windows," was particularly interesting to me. I have recently come across exactly the same requirements--namely, the need to simplify the main Windows message loop for multiple modeless dialogs and have iconized modeless dialogs to reduce screen clutter.
While the method of keeping a linked list of dialog handles is fine, it is totally unnecessary. I also thought that you needed to keep global variables for each modeless dialog box that your application had "active." This is not the case. If you read between the lines in the SDK documentation on IsDialogMessage (with hindsight) you can see that IsDialog-Message seems only to work on keystrokes to the (presumably) active dialog.
The method I use is very simple and will fit easily into the default dialog processing in Joseph's code. I can't lay claims to this method, as I first saw it in the Microsoft Knowledge Base. All you need is a single global variable for the window handle of the active dialog box. In Joseph's default-dialog processing routine, you process the WM_ACTIVATE message; if the dialog is becoming active, set the ghActiveDlg variable to that dialog handle; if it is being deactivated, set ghActiveDlg to NULL.
The keystrokes to move between the application window and modeless dialogs, (ALT+F6, ALT+SHIFT+F6) still work as before. Incidentally, has anyone else noticed that if you have multiple modeless dialogs, the behavior of these keystrokes is not quite what you may expect?
The simplicity of this method, shown in Example 2, highlights deficiencies in the SDK documentation (which is improving slowly). The only use of this method I could find was in the C7 CDDEMO sample program.
On the topic of minimizing modeless dialog boxes, I find that Joseph's method seems to have some redundant processing--notably the setting of the dialog icon word to NULL. In my experiments, the dialog-icon word is always NULL. The only reason I can see that he might need this is if some other application running has changed the dialog-icon word. This is a bit naughty--since all applications share the dialog class, no application should be changing the dialog-class word. Joe's approach then removes the need to process the WM_NCPAINT message and the other places where he sets the dialog-class word to NULL.
Minimizing the dialog works fine if the icon is outside the application window, but not if the icon is over the application's client area. This is because the icon's background is always the desktop bitmap, rather than the windows underlying the icon. We need to get windows beneath the icon to repaint before using DrawIcon, rather than the simple use of WM_ICONERASEBKGND. I can't help feeling that Windows should have already repainted any underlying windows, and the application should not be forcing the background to repaint anyway! Since modeless dialogs with icons are a requirement, maybe we need to ask Microsoft to provide these in a future version of Windows.
David Lowndes
Stoke-on-Trent, England
Dear DDJ,
Multimedia World and PC Magazine have decided to no longer accept advertising for erotic, pornographic "adult" multimedia or CD-ROM products.
Degrading and dehumanizing women into sex objects both contribute to physical violence against women and have been invaluable assets in the war against social, political, and economic equality for women.
The constitution protects the right of free speech. It does not guarantee the right to make a profit. I am writing to ask you to take a positive step toward promoting social, political, and economic equality for women by refusing to accept "adult software" advertising in your magazine. For equality and safety.
Lisa Gray
Bothell, Washington
DDJ responds: Thanks for writing; we appreciate hearing from you. While we agree in principle with your statements, we're curious about what led you to believe that Dr. Dobb's Journal accepts advertising for erotic products?
By the way, the constitution does, in fact "guarantee the right to make a profit," unless we missed some important news recently.
Dear DDJ,
I was happy to see Tom Swan's column on tries (DDJ, April 1994). Though I've been using tries to do many things (for at least ten years) I find that they are misunderstood in general by people who otherwise use binary trees and the like. And so they don't get much press (or use).
I find that for dealing with words, concordance programs and things like that, I almost always put one character in a node with downward links for the next character in the word, and also with sideways links for a similar word but with a different character in this location.
The diagram in Figure 1 shows a trie, which includes the words and, arts, and ant. Each leaf is a null, signifying end of word. This makes for a compact and easily searchable dictionary. I also add an additional item on each leaf, a number, which can be used as a counter. Thus, when a word is inserted into the trie, a count of the number of occurrences can be easily kept.
I also want to thank Tom for using pseudocode in his column. Far too often nowadays people will write a program and call it an "algorithm.'' They don't understand the difference between an algorithm and an implementation, which is something that I found disturbing, since I have been a Modula-2 user for many years and that distinction is so important to the language (and to Professor Wirth himself).
I've read of a time when Algol was the pseudocode of choice. I remember a time when pseudocode really was a readable nonimplementation (those were the days), and now it seems that C has become the pseudocode (which is a sad statement on the state of computer science).
John Andrea
Antigonish, Nova Scotia
Figure 1: Trying tries. Example 1: Securing secure algorithms.
/* Global variable - the active dialog handle */
HWND ghActiveDlg = NULL;
case WM_ACTIVATE:
if ( wParam == WA_INACTIVE )
{
/* Becoming inactive */
ghActiveDlg = NULL;
}
else
{
/* Becoming active */
ghActiveDlg = hDlg;
}
return( FALSE );
In the main message loop the modeless dialog processing is simply:
/* If one of the modeless dialogs is active process the message */
if ( ( ghActiveDlg == NULL ) || !IsDialogMessage( ghActiveDlg, &msg ) )
{
/* Otherwise process it as normal */
TranslateMessage( &msg );
DispatchMessage( &msg );
}
Copyright © 1994, Dr. Dobb's Journal