Dear DDJ,
I thoroughly enjoy Jeff Duntemann's "Structured Programming" column in DDJ. It's always easy to enjoy someone I agree with! Besides having a fondness for structured programming and Turbo Pascal, I also share his coolness towards C. Which brings me to the main reason for this letter. I have a software project where I must use some C routines provided for me in .LIB files. I have Microsoft QuickC out of necessity, and Turbo Assembler/Turbo Pascal 5.5 out of preference. What I would like to do is somehow hook the canned C routines from Turbo Pascal. The kind of applications I'll be working on lend themselves well to objects, as does my way of thinking. My hope is that there is some way to build a TP unit that has TP procedures/functions that actually are calling the C functions. Once this unit is established I could happily turn my back once again on C. What I'd have is a reusable unit with the C hidden an arm's length away.
Is a hook like this possible? Perhaps some assembly interface calling the C and in turn being called by the TP code? I don't have access to the C library source code itself but maybe I could write enough C code to call the canned functions with built-in hooks? I've done more in TP than either C or assembly but have dabbled in both. I have worked with externals written in assembly and called from Turbo Pascal, modifying already written code, but need a little hand holding if this is the route to go with this problem. I'd really appreciate any help Jeff could offer.
Dale Lucas
Cedar Rapids, Iowa
Jeff responds: Without being able to modify and recompile your C libraries, you're stuck. It's a matter of who cleans up whose messes. When C code calls a C function, the caller sets up the stack frame, calls the function, and then (when the function returns control to the caller) the caller cleans up the stack by removing parameters.
Pascal, on the other hand, requires that the function (or procedure) clean up the stack before returning control to the caller. The caller assumes that it receives a clean stack after each call. The two systems are completely incompatible, although, some C compilers, including Microsoft's, allow you to specify Pascal calling conventions as an option. If you could recompile your C code, you could invoke this option and make the two worlds coexist peaceably.
C does what it does to allow the number of parameters passed to a function to vary from one call to the next. To each his own; some people eat fugu and deserve whatever they get. I take some comfort in nothing that operating system API calls use the Pascal calling conventions; evidently OS architects draw the line at risking the system's neck for this kind of silliness.
But that doesn't solve your problem. If you only have .LIBs, well, shucks, you have two choices:
Dear DDJ,
Many times during the last year I was on the verge of deciding to let my subscription to DDJ lapse, as it had apparently turned into a fanzine for 386 and DOS groupies. One more article on cute tricks in C, how to write TSRs, and the 640K barrier would have done it.
Then Michael Swaine's interview with Hal Hardenbergh made me give it one more month. The September issue made me give it another year, and I have sent in my renewal. Five out of six articles were of interest to non-DOS, non-PC programmers!
For 1990, please make at least half the articles in any issue independent of platform and language, i.e., of interest and value to programmers on any machine using any language.
If you wonder where I am coming from, I am a chemist; I write about 10,000 lines of code a year for my research, in Pascal (by preference), C (by necessity), and (ugh!) Fortran. I use a VAX station and a networked VAX cluster for programming, PCs for document processing, and Macintoshes for making slides and figures. I am currently using neural nets and simulated annealing. I am sure you have many readers who, like me, do no programming on PCs, but who are always on the lookout for new programming techniques and useful algorithms.
Ernest W. Robb
Glen Rock, New Jersey
DDJ responds: You've hit on what DDJ is really all about, Ernest -- sharing new programming techniques and handy algorithms -- and we'd like to hear from anyone who has some to share.
Dear DDJ,
I read Rabindra Kar's article "Data-Flow Multitasking" in the November 1989 issue of Dr. Dobb's Journal and enjoyed it very much. The title of the article attracted my attention first because, as part of my job for the past three years, I designed and was principal developer of a data analysis system based on what he termed data-flow multitasking (I've been calling it data-flow processing). Currently this system consists of 58 fittings (programs which tap into a data flow) with support libraries consisting of 264 functions. Fittings may be written in either C or Fortran, and the system runs under Unix and VMS.
This system (which I call the Data-Flow System or DFS) takes a slightly different approach to establishing the aggregate task. Instead of making each processing element of the task a function in an application, each element is itself an application which can be "connected" to any other element. The main reason for this approach was to make it easier for the user to construct aggregate tasks without the need to deal with a programming language. This approach also allows fittings to be written in the programming language which best implements the task.
The variety of fittings in this system is quite broad. There are fittings for reading and writing data, analysis, dataflow management, and data visualization. It is also easy for a user to develop a new fitting to match any special needs. The DFS also has several different interfaces; they include a batch type interface, an interpreter, and a fully menu-driven interface. We have also developed a specialized interface which a user can navigate through and create an SQL query. This query is then integrated into an aggregate task, which extracts the data from one or more data nodes in a network (a distributed data base) and then presents the data locally for viewing.
The system I've described is in use where I work (The Institute of Geophysics and Planetary Physics at UCLA)and at several other locations which are involved with space physics research. I'd be happy to supply more information if anyone's interested. I must compliment Robin on the clarity of his presentation and the succinct way in which he described the concept. It was a very good article.
Todd King
Los Angeles, California
Dear DDJ,
Just finished Al Stevens's column in the October issue, with special interest in his item on dynamic strings in C. The ease of string manipulation in Basic is one of the reasons I keep using it and haven't switched entirely to C (besides the fact that I still have to keep the old Z80 Radio Shack alive for my wife).
A few years ago I picked up Alcor C for the R/S. Never did anything big with it because I couldn't fit much into a 30K workspace anyway.... When I saw Al's item on strings I dug up the old manual because I remembered that Alcor had dynamic strings in those old days using a structure defined in stdio, along with a couple of conversion functions and extensions of printf and scanf. Their implementation was a simple structure with a length byte and a char array, but it worked.
Alcor C is still around. I think it's MIX C now; at least the company is in the same town and still lowballs everybody on price. It was available back then for Apple II, CP/M, and Radio Shack machines. I got it originally as a learning tool, which it served well as. It was not industrial strength; any word on the condition if MIX these days? At the price ($19.95 last I saw) it must be worth something.
Al, keep up the good writing. By the way, this comes via US Mule because I couldn't find a CompuServe address for you or DDJ. I did find the DDJ Forum, but no listing for Al to send a message.
Michael Brady
Fresno, California
Thanks, Michael. Al's CIS address is 71101, 1262; DDJ's is 76704,50.
Dear DDJ,
In regard to Michael Swaine's column titled "Unbundled Integration," in the August 1989 issue of Dr. Dobb's Journal, I would like to make the following observations. The "most interesting"feature of the Apple System Version 7.0 release, the InterApplication Communications architecture (IAC) is indeed an interesting development. Over a year ago, Hewlett-Packard demonstrated this capability as a feature of its NewWave environment. (I guess imitation really is the sincerest form of flattery, especially when the imitator has pending legal action against the imitatee for imitating the imitator!) NewWave is part of the user interface proposed by the Open Software Foundation as Motif.
HP's term for dynamic cut-and-paste is "shared links." With NewWave, a user "shares" and "establishes a view to" data, while an IAC user "publishes"and "subscribes to" data. It probably makes little difference to a user which set of new terms must be learned to use this feature, but I think I'd prefer almost any set of terms that doesn't remind me of the recent spate of renewal notices I seem to keep getting from computer industry publications, in direct proportion to the number of years for which I've renewed my subscriptions to them! The important thing to remember is that it looks like the folks responsible for these windowing environments are making good on yet another implied promise -- software that remains integrated even after one program changes. More power to them all and the Flames of Swaine!
Lawrence T. Prevatte, III
Cape Canaveral, Florida
Dear DDJ,
Donald Smith's article (October 1989), "Finite State Machines for XModem,"was a timely help. I recently proposed an FSM design to a client who had not heard of FSM. Donald's article added credibility to my proposal.
I have used FSMs to manage communication protocols, to manage user interfaces, and to implement control logic. Using FSMs often, I implemented a translator and C library called "The State Machine," which is just what Donald suggested as a coding technique. Interestingly, the code that this translator generates looks remarkably similar to Donald's hand-coded state machine. I have developed an example, "MENUS," which uses an FSM to control the navigation about a menu-driven user interface. The state diagram that was the original design document for this example was directly encoded into a language called "State Transition Description Language"(STDL). The state machine has a number of unique features: It aids memory reduction and improved productivity by supporting encapsulation with both macros and callable substates. The capability to call substates is very useful when implementing user interfaces with submenus. Debugging is simplified by a trace option which can generate a log of all state transitions that occur during execution. This option can be turned off to minimize memory requirements. Actions are C functions which can have any number of arguments. An event or stimulus is defined by a Boolean C function. The state machine comes with several predefined action and event functions.
There are many parallels between the implementation philosophy of the state machine and the mini-interpreters described by Abrash and Illowsky in their article (September 1989), "Roll Your Own Minilanguages with Mini-Interpreters."
For those with a champagne budget, there is a sophisticated CASE tool available from i-Logix called "Statemate." It has several powerful features: Statemate is a graphic tool. State diagrams are drawn interactively. The tool integrates a data base and an interpreter that supports complex events and actions. Documentation can be generated automatically from the data base. State diagrams can be executed using Statemate's simulator or they can be executed from C or Ada code generated by Statemate's prototyper. FSMs defined by Statemate can be decomposed. This capability is based upon a rigorous mathematical theory developed by David Harel. It is important for complex systems which would otherwise explode into hundreds of states.
Rob Buck
Aerosoft
Fairfield, Iowa
Dear DDJ,
I found the interview with David Parker in Michael Swaine's column entitled "Parker's Perceptions" in the October, 1989 DDJ especially interesting since I'm a very satisfied user of his "AcroSpin" graphics software. I'd known nothing about the person behind it!
Swaine says "it [Acrobits] seems to have a good product," and I can testify that it does indeed. My colleagues and I need to do 3-D graphics in a variety of languages, on a number of different IBM PC compatible machines. We also cannot afford fancy hardware; my own machine doesn't even have a hard drive.
AcroSpin is the only product I've seen that does the things I need on the hardware I've got. On all our PCs at this institution, I've yet to encounter one that has some kind of graphics and cannot run AcroSpin. It's clean, simple, and does exactly what the manual says it'll do.
Matthew D. Healy
Zoology graduate student
Duke University, North Carolina
Dear DDJ,
Funny how time alters everything. When Jeff Duntemann opened his September 1989 "Structured Programming" column with a mention of his high school days, I had to pull out my copy of the Lane Arrowhead '70 and look him up. If he still has his copy, he can find me on pages 27 and 126. He must have picked up on computers in college.
OOPs, it still leaves me in the dark. I guess for my PUNishment, I will have to rewrite Fortran into Basic. I enjoyed his column. Take care.
Thomas Kocourek
Carrollton, Georgia
Dear DDJ,
In Michael Swaine's November editorial on innumeracy, his accusation of an error in John A. Paulos's book, Innumeracy, is based on a misunderstanding of the term "order of magnitude." He starts off okay, by stating his deduction that Paulos uses the expression "order of magnitude" to mean "a power of ten." He goofs when he asserts that magnitude (plural) means "powers of one hundred." This is wrong. Any scientist will tell you that scientists use the term "orders of magnitude" to mean "powers of ten," for example:
If quantity A is ten times greater than quantity B, then A is said to be one order of magnitude greater than B. If A is one hundred times greater than B, then A is said to be two orders of magnitude greater than B.
Getting back to the example of the malaria safety index that Swaine cited, for the malaria index to be "orders" of magnitude lower in most of the world than in the United States merely means that the actual risk of malaria (defined as the total population count divided by the number of people in that population who catch malaria) is at least one hundred times higher (i.e. at least two orders of magnitude higher) than in the United States. (Remember that on Paulos's scale, the lower the index number, the greater the risk.) By using the correct definition of "orders of magnitude" we see that Paulos's assertion is indeed within the realm of plausibility.
Swaine's misunderstanding of the term "order of magnitude" is understandable, because written definitions of this term in dictionaries (even scientific ones) are hard to come by. The use of orders of magnitude in calculations has been spread by word-of-mouth among scientists and has not been exposed to the general public (except by Carl Sagan in his Cosmos series). Despite the mistake, I thank Mr. Swaine for addressing the issue of innumeracy in his editorials.
Gregory B. Goslen
Research Triangle Park, N. Carolina
Dear DDJ,
We read with interest Al Stevens's column on C++ in the October issue of DDJ. Imagine our surprise, when on pg. 128 we read the statement: "...not until Borland and Microsoft introduce C++ compilers, complete with integrated development environments and hotshot debuggers, can PC developers get serious about it."
Are you actually saying that only a couple of vendors are allowed to produce a C++ system for MS-DOS? That sort of statement belongs in company marketing literature, not in a well-respected publication like DDJ, where developers look for impartial editorial content.
Zortech has over 50,000 users now, including virtually every major corporation. Many are switching to the Zortech C++ compiler as their preferred development tool. How much more serious can developers get than to switch from C to C++ for their next generation products? This is happening now, and we would be delighted to provide Al with a list of major corporations who are developing with Zortech C++.
Incidently, the "integrated environment and hot-shot debugger" requested by Al is now available with the release of Zortech C++ V2.0 Developer's Edition. It is a full-blown development system including the world's first MS-DOS C++ Source-Level Debugger, AT&T C++ V2.0 compatibility, and many other enhancements. Our entire company is focused on C++. It isn't a sideline for us and doesn't play second fiddle to other languages, wordprocessors, spreadsheets, or database packages.
Walter Bright
Director of Technologies
Zortech Inc.
Dear DDJ,
The correct answer to the question posed to Michael Swaine in New Orleans (December 1989 DDJ), "Where you got your shoes?" is "You got your shoes on your feet!"
I had to tell you...
Harold O. Koenig
Scottsville, Virginia
Dear DDJ,
Thank you for publishing Mr. Guthery's informative article, "Are the Emporer's New Clothes Object-Oriented?" in the December 1989 issue. Amidst all of the hype, it's good to see some reason appear. Now, I can say: "OOPS! Did they really do that?" Rather than being an advance, object-oriented programming seems to be regressive.
Regressive? Yes, it's a return to "spaghetti code" and violates the basic tenets of writing well-structured programs. It was this type of violation by the excessive use of GOTOs that led to Dykstra's letter to the ACM in 1969 and the ensuing interest in structured programming.
In well-structured programs, the structure is a tree whose nodes are the program modules. Each node in a tree may have one and only one father, but, of course, may have has many children as necessary to do the job. As defined in the literature, an object is a module that may receive a message (be called) from any number of sources and may send messages to (call) other objects. Thus, an object is a structural node that may have more than one father -- a rather unnatural situation! Can you imagine the difficulties when trying to debug a module entered from who-knows-where?
Instead of coming up with new buzz words like OOP, the language of developers should heed our desires for more granularity in the libraries associated with various compilers. This was pointed out admirably by Bruce W. Tonkin in his "Examining Room"column on PDQ in the same issue.
If you keep coming up with articles like the two I've mentioned, I'm afraid I'll have to subscribe to DDJ. Thanks.
Dan W. Crockett
Queen Valley, Arizona