Dear DDJ,
I think you were both too hard and too soft in dealing with MS Pascal 4.00 in the June issue.
Kent Porter was too hard on Microsoft when dealing with comparisons to Borland's "Turbo" Pascal 4.00. Microsoft's implementation is, in my opinion, much closer to the ISO standard, and because it uses an external linker and a recognized object module format it is much more universal. I can, and have linked modules written in MS Pascal with routines written in assembly language and MS C--a task much more difficult, if not impossible, when using "Turbo" Pascal. I also agree with Charles Linett's comments about the defects in the Borland manual. Nevertheless, do use the implementation on account of its graphics library.
Porter was too easy on Microsoft because he did not compare this release with the previous version 3.32. In this regard, I can find no justification for the change in major version number. As a devoted MS fan, I upgraded at a cost of $100 (Canadian). I expected to find, in addition to the support for Windows and OS/2, some real improvements in the implementation of the kind that were evident between Fortran 3.32 and 4.00. Shouldn't we have received 1. new manuals, 2. implementation of the "Unimplemented Features" (how can a feature be unimplemented?), and 3. a PL driver equal in features to the Fortran and C drivers--both in the use of environment variables and options? Why was there no graphics library similar to the one available with C Version 5.0x?
Charles Chapman
London, Ont., Canada
Dear DDJ,
I would like to clarify Bruce Tonkin's dismissal of the Forth language as being "generally hard (or downright impossible) to read without significant study" (July issue). He points out that "spaghetti code is always the programmer's fault." The same argument could be applied to readable code. if a portion of Forth code is unreadable, it is probably due to the outrageous flexibility offered by the language: whereas most languages dictate a fixed syntax, Forth does not.
While most languages allow only certain characters in the names of user-defined procedures, Forth carries no such restrictions. Since a Forth program is built by extending the language, these factors have a huge impact. A good Forth programmer can produce very readable code, and a bad Forth programmer can hack out chaos. That's the price of flexibility.
As to Basic's being superior to other languages on the basis of having so many things built-in," nonsense. With the abundance of C libraries on the market, a C programmer can have virtually any function, user interface, btree manager, etc. without carrying along a bulk of dead code.
"If C is a scalpel, Basic is a Swiss Army knife." I couldn't agree more. But a surgeon doesn't use a Swiss Army knife.
Dave Ruske
Milwaukee, Wisc.
Dear DDJ,
Bruce Tonkin raises some interesting points on different Basic compilers in his July article "Getting Down to Basics," but his annoyingly parochial attitude about the 8087 chip makes his article useless for evaluating the different Basic compilers for engineering applications. Where does he get his information that "most" computers do not have it? It is essential for any PC used for engineering programs and is one of the firs additions I made to my computer. Most, if not all, of the computers available to students in the Colorado State University College of Engineering have hardware and math chips. It certainly speeds up Lotus 1-2 calculations.
In his table and text on page 60, Tonkin claims that Turbo Basic is 160 times slower than Microsoft Basic in long integer additions, without specifying whether or not he used the 8087 chip in his benchmarks. Since it is critical to know whether a mathematical benchmark operation was or was not performed with the 8087 chip, it is unprofessional to assume that everyone else has only bought the same enhancements as Tonkin and his friends.
I hope that this does not represent the caliber of all articles in DDJ.
Don Baker
Ft. Collins, Col.
Dear DDJ,
The only debugger I know of that is set up to handle device drivers as Gary Hornbuckle needs to do (July issue) is the Quaid Analyzer which is advertised on page 85 of the same issue in which his letter appears. I've had fairly good results with it in the year I've used it; the manual is a tad terse, but those who know enough about systems software to write loaders and drivers should be able to dope it out. (Its price has doubled in the past year--looks as though the wayward jet stream has blown some of that good old U.S. greed north of the border.)
As for the detailed structure and loading process for .EXE programs, I believe that is fairly closely-held proprietary information; Dr. Hornbuckle should not be surprised to receive a warning shot from the litigious folk at Microsoft. However, the QuaidAnalyzer ought to make it fairly simple to step through the loading process and observe what is done to the program and how control is transferred to it.
I assume by "DOS function 75" he means function 4Bh; it seems to have been Big Chief Face-on-the-cover who started this silly-and potentially misleading-custom of referring to DOS functions be decimal instead of hexadecimal numbers. Why does DDJ go along with it?
John S. Cikoski, Phd
Columbus, Ohio
Dear DDJ,
I have a few suggestions for Dr. Gary Hornbuckle (DDJ "Letters," July issue) on information about the format of EXE files and debugging device drivers.
First, the best book about programming with DOS is Advanced MS-DOS by Ray Duncan (Microsoft Press, 1986). It has a detailed description of the EXE file header, though not of the relocation tables and such. It probably does not have enough information for you to write your own loader, but it may have enough for you to use DOS function 75 for your purposes. It also has a good description of the structure as a device driver.
Second, for debugging a device drive, I highly recommend the Periscope debugger from the Periscope Company. it is a memory-resident debugger that can be loaded as a device driver for debugging other device drivers or used to debug normal programs. I have not actually used it to debug a device driver, but I have used it extensively for debugging non-DOS real-time multitasking systems as well as ordinary DOS programs. Periscope is available as a software-only debugger or with protected-memory hardware to keep the debugger from being overwritten, or with hardware-level breakpoints and an instruction trace buffer. (I've used all three configurations.)
It has many other capabilities and is generally a pleasure to use.
Jim Hewitt
Beltsville, Maryland