3D Modeling
Dear DDJ,
Regarding the "News & Views" entitled "Speeding Up 3D Modeling" in the January 1999 issue of DDJ: I am concerned about the completeness and accuracy of the data sent to the program. If there is one scanner from a fixed point gathering data on a real-world 3D object, then only the surface that the fixed point would see could be recorded. Everything behind that front surface cannot be recorded and, therefore, will not exist to the scanner. Are multiple scanners from different locations around the object being used? Is anything being done to scan the inside structure of the object?
I am also concerned about the accuracy of the data being received. The B2 Stealth bomber was specifically designed to reflect any energy (light, sound, and so on) hitting its surface from several random directions. Thus a scanner trying to detect a B2 would receive a weak and diffracted B2 signal. Other objects found in nature have similar properties. Is anything being done to ensure the integrity and accurateness of the signal being received by the scanner?
Lastly, regarding the software itself, does the program do any checking on the data it receives? Also, does the program just work with surfaces or can it also process true 3D interior structures?
James H. Sylvester
Yorba Linda, California
DDJ replies: You raise some good points, James. You can find out more about the techniques by contacting Cyra Technologies at http://www.cyra.com/.
Bill's Inferno
Dear DDJ,
When reading Al Stevens' January 1999 column, I could not help but laugh out loud at his woes with the D-Flat 2000 classes. When I first started programming for Windows in 1989 (Windows/386 at the time), I too was quite stubborn. I did not want to learn the API; heck, there were something like 450 functions! But when I couldn't find a decent interface library to make my life easier, I was forced by circumstances to "hunker down" (whatever that means in programming terms) and get a grip on the Windows API.
And interestingly enough, that was the worst thing to happen to me as a programmer but paradoxically the best thing for my career as a programmer. On the one hand, I bought into the awful state of Windows instruction hook, line, and sinker -- I abandoned any sort of structured design in favor of page after page of message-handling switch statements. But at the same time my higher programming faculties were dying on the vine, my career could not have been more assured. For as I have written before, one's value as a programmer for Windows does not consist in one's abilities as a programmer. Rather, one's value consists in one's arcane knowledge of the many tricks, traps, pitfalls, and outright bugs and mistakes in the Windows API.
Now I'll confess that I just couldn't keep up after Windows for Workgroups. The API quickly grew beyond its initial horrendous size to encompass the thousands of calls -- more if you count all the various ActiveX property/method gadgetry now under the hood -- that it is today. But I still never lack for work for a simple reason: Lots of people were as stubborn as Al was. And this has left them utterly clueless beyond the confines of MFC, OWL, and the like. Welcome to the entire Windows API. Al, I suggest abandoning all hope at your earliest possible convenience. Or perhaps I should be more explicit: Welcome to Hell.
John B. Williston
Al replies: John, many thanks for your enjoyable letter. Beware. You remind me of an old friend who decided, in the early 1980s, to establish himself as the world's reigning authority on the MS-DOS phenomenum called the "terminate and stay resident" program (TSR). He built an ASM library around this peculiar construct, wrote articles, spoke at conferences, gave seminars, and built a company based on this specialty. Eventually, when TSRs became extinct, he went broke and is, at last report, producing adult web sites for a living. I wouldn't want that to happen to you.
More On the Crouch-Echlin Effect
Dear DDJ,
There has been more than enough "snake-oil" purveyed to a relatively unsophisticated and vulnerable target market in the course of this Y2K run up. In this particular instance, principled engineering and business practices combined to correct the condition you report about the so-called "Crouch-Echlin Effect" described in your February 1999 "News and Views" column.
I am a senior systems engineer with Compaq and have been a principal investigator of the Crouch-Echlin Effect since it was first called to our attention. Our specific interest has been determining 1. whether or not this supposed Y2K phenomenon actually affected any Compaq platforms; and 2. what, if anything, such an effect required Compaq to do to obviate difficulties for our customers.
In conjunction with Intel and others, Compaq has conducted exhaustive tests that yielded, essentially, no evidence that this purported phenomenon affects any contemporary ISA PC platform, and most certainly none of Compaq's. Further, Compaq does not endorse or offer for sale any "software fix" purported to address this "effect."
It is true that an agency of Digital Equipment Corp., prior to the acquisition by Compaq, was involved with Crouch and Echlin in investigating this phenomenon and, for a short time, that entity did license, from Echlin, the right to distribute, for itself, his "software fix." However, once a comprehensive technical investigation was conducted within Compaq, we determined that it was inappropriate for Compaq to appear to endorse or distribute this product and this activity was promptly terminated.
Whatever the "root cause" of this phenomenon -- still not conclusively determined, at this writing -- there is no evidence to support the proposition that it can or should be addressed in software. Any platform that displays anomalous or disorderly "behaviors" of the character and magnitude attributed to this or any similar phenomenon should simply not be used. Applying some "software fix" in a vain or misguided attempt to ameliorate such a condition is absolutely the most inappropriate response. Advocating such a response would be quite unethical and contrary to the best interests of both the advocate and the target audience/market.
Both Compaq and Intel have published detailed statements concerning the investigation and significance of the Crouch-Echlin Effect. The Intel statement is particularly useful in debunking most of the misinformation that has been bruited about on Usenet and the Web concerning this phenomenon. Readers can find relevant information at both http://www.compaq.com/year2000/year2000-qa.html and http://www.intel.com/support/year2000/ under4.htm.
I am not an authorized spokesperson for Compaq on this or any other matter. I did, however, participate fully in the investigation and disposition of this issue. My sole interest, as a DDJ subscriber and as an individual well informed about all aspects of this whole Y2K issue, is to counter the incorrect information about Compaq that you caused to be published.
Austin Fletcher
Compaq Computer Corp.
Myopic about File Names
Dear DDJ,
I thought that "A Java Applet Search Engine," by Tim Kientzle (DDJ, February, 1999) was useful and interesting. The textual comments and highlight that "Java is somewhat myopic about filenames," however, prompted me to respond with some information that seems not to be widely known. The question of filenames and URLs first came to my attention about a year ago on the Java Developer Connection and I answered it with an application developed on NT under JDK 1.1.3. I am sending along new applet code developed under 1.1.7B on Windows 98. (The complete source code is available electronically; see "Resource Center," page 5.) The code has been tested with appletviewer, HotJava, and Microsoft Internet Explorer 4.01. The applet has not been tested on other platforms, but should work, assuming a proper JVM implementation.
The first piece of information regards CodeBase and DocumentBase. For whatever reason, getCodeBase() returns the applet path MINUS the applet name. getDocumentBase(), on the other hand, returns the entire path, including the document name. CodeBase can be used immediately. If DocumentBase is necessary, one answer is to substring the value from its beginning to the last instance of the file separator character (using the system property "file.separator" or the File variable "separator") and prepending that to the file name.
Second, the File class has a method, getCanonicalPath(), which will return the system dependent form of the file path. After properly setting up the URL and using URL.getFile(), this method will return the full path properly formatted for the native system. In the example applet, I was lazy and used CodeBase. For testing purposes, I created a directory named "data" off the application directory and created a file named "test.txt," so my entry was "data/test.txt." After pressing OK, the applet shows information regarding the bases and path. As Tim noted, it is unlikely that the current directory will be that of an applet running from a browser, therefore the complete path is normally needed for a file (as opposed to URL) entry.
Joe Sam Shirah
Ficl Update
Dear DDJ,
Thanks to Randy Leberknight, I have an update to my article "Ficl: An Embeddable Extension Language Interpreter" (DDJ, January 1999). In the example illustrating Conditionals on page 74, the positive|zero case underflows the stack. A dup and a drop fixes the problem.
: signum ( x -- sign )
dup 0< if drop -1
else
0= if 0 else 1 endif
endif
;
John Sadler
DDJ
Copyright © 1999, Dr. Dobb's Journal
