Dear DDJ,
I've read the discussions on software patents with great interest. That the current system is unworkable seems proven; I like Jeff Duntemann's idea of replacing it with an ASCAP-like licensing scheme. (Ideally this would be integrated with a software-component market.)
There is another trend which I would like discussed, an increasingly strident tone concerning "software quality." For example, IEEE Spectrum recently published an e-mail conference on "the security and vulnerability of information technologies." ("A Security Roundtable," IEEE Spectrum, 8/'92, pp. 41-44.) The participants were six "outstanding security authorities."
At least four share a strong opinion that information systems are unacceptably dangerous because of inadequate controls on their development. Only one questions (or qualifies) this judgment; the rest argue about the mechanism for imposing control. The preferred methods seem to be government regulation, "consumer-oriented code-termination" and an "anti-czar" ("a Ralph Nader of information technology...to start the whole process of public consciousness").
The extraordinary things about the Spectrum conference are the generality of the indictment, the contempt for current practice, and the lack of critical consideration of the proposed solutions.
Although Spectrum's opening remark asked whether systems are "increasingly vulnerable to malicious action," the respondents have much broader concerns:
"There is no standard...on whether to design (and pay for) very resilient systems;" "We must recognize the risks in trusting computers...to do jobs we ourselves cannot do reliably on the scale and with the timeliness demanded;" "I want to know exactly who wrote the Windows 2 code, DOS 4.01;" etc.
The actual systems mentioned, in addition to MS-DOS and MS Windows, are a nonfunctional accounting system and a faulty radiation-therapy control program. It is left unclear which solutions are meant to solve which problems.
The contempt surprised me. Programmers are "techies" who need to be prodded to consider "values beyond making something work." (Apparently, profit is an inadequate motive for us to properly value user interfaces.) The following assertion is made and not challenged: "No designer of any essential software did a reasonable analysis of the risk of an implementation." Is this true, for example, of the Space Shuttle avionics? The participants ignore more than criticize the existing standards and certification processes.
The ideas on how to better develop systems are the following: To have "users take a more active role in the design," that "all professionals, just like artists, should sign their work," a rather vague wish to see "the reward structure changed for techies," and a mention of "good software-engineering practice." There is more substance in the discussion of how to exert control. One method involves using the fear of computer viruses to increase "user consciousness" to the level required for a Ralph Nader type activism. Lawsuits get favorable mention. The consensus, however, relies on government regulation: "Legislative control is essential in security. Is information technology different in this respect from chemical or nuclear engineering? No!"
But chemical and nuclear engineering were crippled by politics. Is it in the public interest to do the same to information technology? None of the proposed mechanisms of control have good records of intelligently addressing problems. Moreover, existing software-engineering practices are controversial and (in my opinion) rather rapidly improving. Overreactions may lead to decreased safety by requiring the wrong techniques and by preventing the development of improved systems.
I fear that these "outstanding security authorities" will win if unopposed. Please read the article.
Ed Butler
Reston, Virginia
Dear DDJ,
This is in defiant rage against Jeff Duntemann's irresponsible and dangerous article in his August "Structured Programming" column. If Jeff has his way, none of us will have a job as a professional programmer. Instead, we will all be completely broke from researching for, applying for, and defending against, patent violations. In fact, we will be so busy with these activities there will be no time to do what we get paid to do, program computers.
Clearly Jeff doesn't get it. As a software developer I am paid to come up with solutions to problems utilizing today's microprocessors. I believe that this is what most software developers get paid to do. I also recall, from my college education so long ago, that we were taught ways to solve problems using various logical methods and algorithmic approaches, utilizing a solid foundation in mathematics and logic.
I can still remember, from programming my computer just this morning, that today's microprocessors provide a very limited form of expression. They still execute a sequential set of instructions, performing simple math and logic operations. Given this limited set of instructions, I try to solve computational problems every day in my professional life. Now don't get me wrong. I'm a very clever fellow, and I come up with ideas, almost every day, that just make my little ego burst with pride. However, Jeff would have me perform a patent search every single time I hack a clever piece of code!
The point is, nothing a good programmer does is obvious! I don't get paid for being dumb! I get paid, like many other talented engineers, because I can hack good code, trim cycles, and push the metal. Maybe you don't remember this kind of programming, but for many of us it is our bread and butter, day-to-day, patent-violating profession.
The concept of patenting software is ludicrous. A computer executes a simple set of logic operations. It's like coming up with a good solution to a chess problem. Given the constraints of the board, and limited ways that the pieces my be moved, a chess master can come up with fantastic solutions to achieve a winning game. However, he doesn't run out and try to patent his winning chess move. But instead make that a fast sort algorithm, and watch out!
In many other professions, individuals achieve reward and advancement for good ideas (people in advertising, marketing, sales, and investment, just to name a few). Imagine the chaos if these professions filed patents for every new or perceived new idea they ever had! Proposing that a series of add/subtract, compare, and memory move instructions can be patented is both irresponsible and dangerous. It puts engineers out of work, while large corporations, who treat patents like war chests, and lawyers, assert their growing control on a once creative industry. (Let me point out right now, that no patent filed describes its process as a series of add/subtract and memory move instructions, even though that is how we would ultimately express it with today's machine architectures. Instead each patent is filled with such obfuscation and technical mumbo-jumbo that describing how to boil a pot of water would read like the technical reference manual for an Iraqi nuclear device.)
If this letter sounds angry, you are getting the right tone. Am I being ridiculous? Hell no! Think about it. Patents have been granted again and again based on efficient forms of computation. Most of us make a living out of efficient forms of computation. I've written self-modifying code on many different microprocessors. The result of this coding effort was invariably a hot product, not a hot patent!
The patent issue is being raised around me, at a personal level, constantly. I develop simulation products for a game company. My colleagues and I make a living developing computer games that do things the rest of the industry doesn't feel is possible. Imagine writing a 7-frame per second 3-D flight simulator on a 4.7-MHz IBM PC computer. My friend Ned Lerner did so when he wrote Chuck Yeager's Flight Trainer in 1986. Not a single patent was filed, or patent search performed. In Jeff's world people like Ned and I don't have jobs.
In summary, I ask, "How can we perform our jobs as creative and talented engineers, if we must, every day, perform patent searches, and apply for the same?" Join the real world and help fight this madness, not foster it!
John W. Ratcliff
St. Charles, Missouri
Dear DDJ,
Sitting at the bottom of Africa sometimes gives us the advantage of objectivity. In answer to Jeff Duntemann's final question in his June "Structured Programming" column ("Hey already, when is somebody going to do me up a Visual Pascal?"), I have the following suggestion:
Switch your allegiance to the Macintosh. The Macintosh Toolbox and operating-system interfaces were all specified in Pascal terms, and as a result the Macintosh has a much stronger Pascal following than the dreaded PC. Equip yourself with AppMaker 1.5 from Bowers Development, and THINK Pascal 4.0 from Symantec. An unbeatable combination.
Add to this copies of Inside Macintosh, volumes 1-4, and you're away. It's programming heaven and about 100 times more professional and productive than anything else I have ever worked with.
Mike O'Hanlon
Claremont, South Africa
Dear DDJ,
I refer to Mark R. Nelson's article "File Verification Using CRC" in the May 1992 DDJ. Mark suggests that the CRC calculation is noninvertible in the sense that on changing the contents of a file it is difficult to avoid changing the CRC and that trial and error is required to restore the former CRC. This is not the case.
If a region of the file is modified and there are four extra bytes following the region (without extending the file) which can also be modified, then you simply calculate the CRC over that region before and after the changes, calculate the difference with a bit-wise exclusive-OR, and then exclusive-OR that value into those four following bytes. The CRC over the whole file will then be unchanged.
Better still is the fact that the CRC of a file can be arranged to come out to any chosen value if only there are 32 consecutive bits that can be modified somewhere in the file. The bits do not even have to be aligned on a byte boundary.
The CRC that would result from each of the bits alone (without pre- or post-inversion) is calculated and those values assembled as the rows of a binary matrix. The matrix can also be obtained by powering a suitable sylvester matrix. The difference (exclusive-OR) between the current CRC of the file and the desired CRC is calculated and is multiplied by the inverse of the matrix. The nature of the polynomial guarantees the matrix is nonsingular. The result is exclusively ORed into the chosen field in the file.
If the location for the CRC patch is a fixed distance from the end of the file, much of the calculation can be done in advance.
There are legitimate applications. The first method could be used to keep the CRC over a database file constant after updating one record, without having to read the whole file. The second could be used to arrange that an executable file or a ROM had a particular CRC, say, 42 hexadecimal.
But the CRC is not a good defense against viruses. Presently it is useful because the viruses do not account for CRCs, but as shown, it is neither hard nor time consuming.
Gavin Puche
East Brisbane, Queensland
Australia
Dear DDJ,
As a participant in your C++ GUI "shoot-out" (see "Sizing up Application Frameworks and Class Libraries," by Ray Valdes in the October 1992 issue of DDJ), we felt that this type of forum does indeed provide the reader with a broader view of an array of product solutions than could be accomplished by a limited review. Additionally, the coverage for each product is better balanced. We do, however, feel compelled to clarify the following misconceptions noted regarding our product, object-Menu.
First, the article notes that our mouse icon is nonstandard from a Windows or Mac point of view in that it points to the right. In fact, our mouse icon can be dynamically customized to any shape, including allowing an animated mouse icon. Several sample icons are provided with the product for those less-creative folks. By using a right arrow in our demonstration programs we attempt to illustrate our flexibility, not nonconformity to a standard.
The second note refers to the table of implemented features to the DDJ HWX browser. Two of the items were "Select letter by keyboard" and "Select instance by keyboard." It was erroneously noted that our implementation did not have these characteristics. We expect this must have been an oversight since object-Menu has extensive keyboard support built in to all objects.
A final issue is a somewhat picky, but important distinction in the characterization of the supported platform. object-Menu was noted to be the only "DOS-based" product covered in the article. Earlier in the article, Borland's TurboVision was referenced as also supporting "DOS apps." The important distinction to be made is that not all DOS-based support is equal. object-Menu supports DOS graphics apps, whereas TurboVision is suited only for DOS text-based apps. This clarification is particularly significant in a market already undereducated about DOS-based Microsoft Windows alternatives.
With the popularity of Microsoft Windows, OS/2, etc., there is strong demand for an aesthetic user interface for every product. We salute DDJ for presenting a non-Windows alternative in this coverage of user-interface solutions.
Lisa Herman
Island Systems
Burlington, Massachusetts
Copyright © 1993, Dr. Dobb's Journal