Letters

pEGAVGA.BGI     Offset 0950H
CGA.BGI         Offset 0B80H
HERC.BGI        Offset 0B00H
ATT.BGI         Offset 0B90H
IBM8414.BGI     Offset 01270H
PC3270.BGI      Offset 0AD0H

To test your work, before and after, in Turbo Pascal 6.0 (or earlier) compile and run the sample program BGI-DEMO.PAS. For anyone interested in modifying other fill styles, 1 mention that the 12 style strings of eight bytes are in this order: LineFill, LtShashFill, SlashFill, BkSlashfill, LtBkSlashFill, HatchFill, XHatchFill, InterleaveFill (sic), WideDotFill, CloseDotFill, SolidFill, EmptyFill.

I have written to Borland's Pascal Technical Support about this problem with each version of Turbo Pascal since 3. The response has always been to deny that any problem exists, with no indication that anyone has actually looked at it.

I wonder if Borland is going to abandon its languages eventually. While they are upgraded in various ways, in some ways they are relies. For instance, the current flagship language, Borland C++, manuals still go on and on about how to program the CGA, and offer nothing on the Super-VGA. Nor does C++ or Turbo Pascal give you a mouse unit. C++ does, but Turbo Pascal does not give options for using extended memory. Neither C++ nor Turbo Pascal have compiler options for using any processor other than the 286. While I am happy to receive packages like Turbo vision, the Help Compiler, and the Whitewater Resource Toolkit, I must belong to the vanishing race of those who need to program for themselves rather than plug into prepackaged kits, and program on modern equipment.

I would like to program a mouse on the graphics screen in Turbo Pascal, to get results like the Norton Utilities user interface. No help from the Turbo Pascal or Borland C++ manuals. So I bought the Microsoft Mouse Programmer's Reference, 2/e. Its Appendix E, "Making Calls from Borland Turbo Pascal Programs," attracted me. It contains one Pascal program, printed in such a way that it appears to be actual code. It was first annoying that throughout the book, mouse calls have four-integer parameters, but in this program there are five, but let it pass. However, when I reached "If... begin... end; else..." on page 316, lines 5 up through 4 up, I lost all confidence and want my money back.

Harley Flanders

Ann Arbor, Michigan

Dear DDJ,

In the September 1992 "Letters" column, Charles Manning noted that in 1980 Fortran, the function MOD(x,y) does not return a value in the range 0..n-1, "as any sane person would expect" (and as the mathematical function does ~ see Knuth, vol. 2, pp. 38). As a newcomer to the world of computer science. I had been wondering whether the common, erroneous mod function found in languages for the IBM PC was an aberration of those languages alone or of computer science in general; it appears that it is the latter. Can any old hands give an explanation for this peculiar implementation of a standard mathematical function?

Regardless of the origin of the problem, it seems to me that the best solution is not to try to patch the existing function but to write a new one that works properly; for example, in C the code:

           while (x>-y) x -y1
           while (X<0) x+=y:

will set x to the proper value of the mathematical function x mod y, where y is required to be positive (as is usual in mathematics). This function is slightly slower (about 10 percent) than the one given by Mr. Manning or the more common one (x=x%y,if(x<0) x+=y1), but still is almost instantaneous. On a 16 MHz 386, 20,000 random repetition require less than one second, which should be fast enough for most purposes.

Knuth extends the usual mathematical mod function by setting x mod ()=x and allowing y to be negative, with x (mod(~y) being the negative of (=x)mod y. Obviously, these could be incorporated in the above function if desired. The computer-science version of the mod function does not allow y=0 and does not agree with Knuth in any instance where x and y have opposite signs.

B.J. Ball

Austin, Texas

Dear DDJ,

John McKnight (June 1992 "Letters") seems to have gone out of his way to miss the point of my letter which you printed in the March 1992 Dr. Dobb's Journal.

To begin with, he objects to my referring to Clipper as a Nantucket language. Perhaps he would have preferred something like "the Clipper implementation of the dBase language," but I avoided that terminology for two reasons: 1. Clipper embodies both a subset and a superset of the dBase language; and 2. my remarks were concerned with the implementation of the language, rather than its grammar and syntax. There seems to be no misunderstanding when we speak, for example, of differences between VAX Fortran and Microsoft Fortran; I'd have thought that it was obvious that it was in this sense that I referred to Clipper up a Nantucket product. I fail to see what bearing Borland's recent acquisition of Ashton-Tate, while newsworthy in its own right, has on the present discussion.

Second nothing in my letter denigrated Clipper's grammer or syntax. I explicitly recognized Clipper's screen manager as a valuable tool. I am well aware that Clipper was designed to work with databases but I see no reason why I should be denied the right to use Clipper's excellent screen manager for whatever purpose I choose. I do, however object to having to carry the overhead of those routines which I choose not to use. Third compile/link speeds obviously depend on the compiler, the linker, and the machine on which they run. (I used Optlink, which is the fastest of the three linkers on my rather slow machine.) What is perhaps less obvious is that linking speed also depends on the organization of the time library. My point was precisely that linking is as John observes the slow step in any Clipper job. Clipper is by no means the only language which suffers from this fault.

I am well aware are that a faster machine We would reduce turnaround times but I prefer to do my development (or at least the final stages of testing) on a minimal machine. The reason for this will be obvious to anyone who has ever lost a potential sale because the client was either unwilling or financially incapable of upgrading his or her machine to take advantage the latest technology.

An obvious alternative to Clipper is Turbo Pascal plus Software Science's Topaz package. The executable" for Turbo's null program is just over 1 Kbyte. If you force Turbo to include the SAYGET4 module wackily implements the screen manager this will add about 12 Kbytes. The DBF4 module which communicates with the database adds about 20K; and using both of these together yields an .EXE file of about 25K. Compile plus link times on programs that are of moderate size seem to be about three times as fast as those with Clipper plus Optlink and the executables are typically about 30 percent smaller. Obviously Borland has a better idea of how to build a run time library. Is there any excuse for the voracious libraries with which we are routinely plagued?

Yes John let's choose the right tools for the job whenever we can. I've programmed on a dozen or so machines in at least 31 dialects of 17 languages. I believe that my 35 years of experience in System development 12 of them spent as manager of technical systems for a Fortune 50() chemical company have given me some insight into what factors contribute to productivity in a programming shop. I believe that I'm qualified to judge what constitutes an effective tool for a given application in the DOS world I'm still searching.

Arpad Elo Jr.

St. Johnsbury, Vermont

Dear DDJ,

I should like to comment that the issue of undocumented features is not so much technical as it is social. There is a kind of intrinsic tension to the relationship between the operating-system developer (OSD) and the application-program developer (APD). In order not to forfeit the role of managing computer resources the OSD must add functionality in response to the APD's needs. But it is always in the APD's immediate interest to make frivolous requests by way of offloading his own work onto the OSI). If the OSD treats every request or suggestion of an OPD as a command the operating system will come to contain essentially all of the logic of every application as its size balloons into impossibility. Somehow the OSD has to assess the credibility of each APD and react accordingly.

This situation is not confined to operating systems and applications programs. It also exists between the developers of operating system and processors. and as Tracy Kidder has shown, between the microcode and hardware-design sections of a processor-design team. In cases where the antagonists know each other personally. the situation is moderated by social amenities and by each participant's desire to maintain his reputation for technical skill. When they are strangers with a full range of ultimately conflicting interests, however, all parties are likely to grab everything they can.

I suggest that undocumentation, as practiced bv Microsoft and Apple, has to be seen in this context. The unspoken rule seems to be that the OSD will maintain a fair assortment of undocumented features out there, and if you, the APD, are prepared to go to the trouble of hacking the system to find the undocumented features, you can use them, provided you don't use them lightly or for no very good reason, and that, when and if the OSD really does have to change them, you are prepared to fix your program to conform and to make it all right with your customers. Additionally, information can be leaked to the APDs of known probity, who can be trusted not to simply gang up and spike their code with undocumented features in an attempt to present the OSD with a fait accompli. Similarly, their requests for new features can be taken more seriously.

The problem with this is that in the first place, it is undoubtedly an "old-boy network", with Microsoft's APDs as charter members? and as such liable to the antitrust laws. Secondly? someone like Mr. Schulman presents problems for this system. Obviously he believes that if a feature is there, it is meant to be used--and is intent on forcing the entire corpus of undocumented features into the official API. Together, I think these imply that undocumentation must be replaced by something else.

A possible alternative would be a system whereby APDs may commission new features in the operating system, subject to some kind of published price schedule, with orderly procedures for the notification of interested panies, etc.

Andrew D. Todd

Philadelphia, Pennsylvania

Dear DDJ,

I've also added code to compensate for some hardware platforms that don't keep the proper count vs. output consistency needed for accurate timing in all circumstances.

Finally, since the VTD can return erroneous values (decrementing time),I've added code to ensure that decrementing values are never returned.

Tom Roden

Irvine, California

Copyright © 1993, Dr. Dobb's Journal