Dr. Dobb's Journal August 1997
Dear DDJ,
We are pleased that Gary Kildall's family chose Monterey Peninsula College to receive the Dr. Dobb's "Excellence in Programming Award." An account in the amount of $1000.00 has been established.
The award will be advertised during the 1998-99 academic year as follows: Dr. Dobb's Excellence in Programming Award -- In Memory of Gary Kildall.
Two scholarships will be offered in the amount of $500.00 each, for students majoring in computer science.
Patricia Chapman
Monterey Peninsula College
Monterey, CA
Dear DDJ,
We discovered your 1997 "Excellence in Programming Awards" while doing a search on the late Gary Kildall, a friend. Our company, MacroCom, does the REAL/32 OS MaxFrame Zero Administration Pack for the IMS REAL/32 operating system, which is the current version of CP/M (CP/M-97).
In late 1994, Novell named two master VARs to continue the development and marketing of CP/M (at that time named "Novell DR Multiuser DOS") -- CCI (Concurrent Controls Inc., headed by Dawn DeBruyn), and IMS (Intelligent Micro Software Ltd., headed by Dr. Dave Crocker).
IMS released the first version of the renamed IMS REAL/32 on 08/18/95 with capabilities to run Windows 3.x in Enhanced Mode, and we released MaxFrame at the same time to automate setup and administration. The exclusive North American distributor of IMS REAL/32 is Logan Industries, headed by Alex Soya. IMS Ltd. also has its U.S. office at Logan Industries in Palm Bay, Florida.
The latest version, 7.60, of IMS REAL./32 has just been released, and the largest U.S. customer is IBM, which uses it as the OS for its flat-panel touchscreen POS systems for the hospitality industry. MacroCom, headed by myself and Bruce A. Sailors, works with IMS/LII with focus on the PC Server OEM market.
We invite you to access our web sites via our MaxFrame.com site, which provides links to IMS Ltd., Logan Industries, and Caldera (headed by Bryan Sparks and Ransome Love with Ray Noorda as the principal shareholder) along with other key companies that have become our friends and partners over the years to continue the work Dr. Gary Kildall started with Intergalactic Digital Research.
If anyone richly deserves an award for Excellence in Programming, it is most certainly Gary Kildall. I only wish that he could be here to see his work come to successful fruition. He was kind, brilliant, and did indeed create the very software structure that enabled personal computing as we know it today. Thank you for the May 1997 recognition of Gary with your award.
Jim Benfer, Jr.
http://www.MaxFrame.com/
Dear DDJ,
I have received a good deal of correspondence in reference to a published letter from Cameron MacKinnon ("Letters," April 1997) in which he cited my January interview with DDJ and questioned whether trusting a particular vendor's solution is any different from trusting the government with your key. As I see it, the entire question is moot.
The issue of trust is a highly personal one, regardless of whether it is trust of a friend, business associate, or government entity. While I may choose not to place a high degree of trust in the government's key escrow plan, others, including Cameron, may feel differently. I would maintain that the decision to choose a security implementation from a particular vendor is based on an individual's evaluation of other factors -- the strength of the encryption, authentication, use of hardware versus software, and so on -- that can engender trust in that vendor's solution.
DSN Technology developed the NetFortress from the standpoint of the strongest possible security. Beginning with its hardware-based design, we added state-of-the-art technology utilizing strong encryption, and fully automated authentication and key management. DSN chose IDEA because it is an advanced algorithm that has been open to scrutiny for almost a decade, without any known instances of being broken. If DSN did not have a high degree of confidence that our use of IDEA would provide our customers with the strongest possible security for their data communications, we would have chosen a stronger encryption algorithm for use in our product.
Like any business, DSN Technology's success depends on the strength of the reputation we are able to build in the marketplace. We have a direct interest in ensuring that the products we deliver meet the level of performance, quality, and security that our customers demand. By meeting that demand, DSN establishes credibility, confidence, and indeed "trust" with our customers. Without that, we might as well shut our doors today. While this may not be enough for Cameron to feel secure with our products, it works for many others.
Dr. Eva Bozoki
DSN Technology Inc.
eva@dsnt.com
Dear DDJ,
In reply to the request by Jan Kaluza for a "complete history" of which calendar was in use when..." ("Letters," DDJ May 1997). The definitive history is in Chapter 4 ("The Calendar") pp. 437-442 in the 1974 reprint of Explanatory Supplement to the Astronomical Ephemeris and the American Ephemeris and Nautical Almanac, published by Her Majesty's Stationery Office in London. This discusses several calendar systems, in addition to the Julian/Gregorian calendars.
A brief summary: The Gregorian calendar reform was promulgated by Pope Gregory XIII, to commence on October 4, 1582, Julian calendar, which became October 15, Gregorian calendar. (This date is usually considered as the "origin date" of the Gregorian calendar, and is used as such in the conversion programs I am familiar with.) The new calendar was adopted "on schedule" by the Roman Catholic Countries of Europe, and spasmodically over the next 340 or so years by the rest of the world. (The most recent adoption listed in the table on pp. 414-416 of the above-mentioned reference is Turkey, in 1927.) The Gregorian calendar was adopted by Great Britain and its dominions (including the American colonies) by act of Parliament, effective 1752, September 3/14; the start of the calendar year was changed from March 25 to January 1 at the same time.
Murray Lesser
mlesser@ibm.net
Dear DDJ,
Scott Meyers' letter on C++ constructors ("Letters," May 1997) made perfect sense to me. That is, until he got to the note about invoking the destructors: "...This is necessary to satisfy the C++ rule that destructors are called in the inverse order of constructors."
I see the rule relative to derived classes, but that's not what we're dealing with here. We've malloced some memory that we want to treat as an array of objects of type Foo. Then we use the "placement new" to construct these objects at offsets into that malloced memory. Now, what does any one Foo object have to do with any other that all must be "destructed" in a particular order? If I create a number of Foo objects on the heap, say, there's no problem in destroying them, whatever the order. How about using: new Foo[10], instead of malloc. Rather than the lazy instantiation of the Foo objects, as in the example to Scott's letter, we construct all Foos in the array. Again, I can certainly invoke ~Foo() for any element in the array, and "destruct" them in any order I choose.
Should I attempt to use those "destructed" Foos.... Well, that's my problem, not C++'s.
Frank Plochan
fjp@diginsite.com
Scott responds: The key observation here is that we're attempting to emulate an array, and C++ has the rule that objects in an array are constructed in increasing array index order and destructed in decreasing array index order. That is, C++ doesn't consider objects in an array as completely unrelated for purposes of destructor order, even if the array is on the heap.
As for using new Foo[10], instead of malloc: Right, but then what will happen when you delete the pointer you get back from new? You must do this to avoid a memory leak. That's why manually invoking destructors on array elements (or auto objects) is almost always an error.
Frank responds: Thanks for your response, Scott. Since the posting of my letter, I have located the rule regarding the order of construction and destruction of array elements (Sections r.12.1 and r.12.4, respectively, of Stroustrup's The C++ Programming Language, Second Edition). I find that this rule is consistent with other areas involving construction/destruction, as in section 5.5.1, Local Variables, in the same text.
Dear DDJ,
I just read the article "Symbolic Integration using CLIPS," by John Swartz (DDJ, June 1997) and found it very interesting. There were two points in it that I thought needed some comment.
The first is the remark in the introduction to the article about the results of numerical integration being hard to trust. It is true that there is always round-off error present, and a host of other problems can arise. However, when an algorithm that is appropriate to the class of function being integrated is applied, the results are overwhelmingingly reliable. A competent implementation of any numerical routine should include not only an estimate of the answer, but also an estimate of the error incurred. It is certainly possible for a symbolic integrator to make mistakes, too. Even high-quality symbolic packages such as Mathematica, Maple, and Macsyma make errors occasionally.
The second point is about the pedagogical comments on the instruction of integral calculus. Slagle's comment that instructors should teach the integral calculus by drilling an algorithm into the students' heads presupposes that the goal of the calculus is to master integration. This assertion has been rejected by the majority of math educators. The emphasis should be placed on understanding the concept of an integral and not on the mechanical aspects of the subject. If the primary concern of teaching calculus was to master the routine mechanical techniques of integration, then the course would have no point since we can simply teach the students how to use a symbolic package.
Jeff Graham
Dept. of Mathematics & Computer Science
Western Carolina University
jgraham@wcu.edu
DDJ