LETTERS

Parallel Programming: An Old Hat

Dear DDJ,

For goodness sake, in Michael Swaine's new column (Programming Paradigms, May 1988) please do not reinvent and rediscover parallel programming. Pease read standard books (including mine!) on the subject, e.g.: Concurrent Euclid, the Unix System and Tunis (Holt, Addison-Wesley), and Operating System Concepts (Peterson & Silberschatz, Addison-Wesley).

At the University of Toronto, parallel programming has been taught using a high level concurrent language since 1974. We are now using the Turbo Plus language for this purpose.

Professor R.C. Holt

Toronto, Canada

Porting Virtual Arrays

Dear DDJ,

Although "Virtual Arrays in C" by Mark Tichenor (May, 1988) may run on a PC when compiled with Turbo C, it will definitely not run on many other machines. This is because Tichenor has hard-coded the lengths of integers, long integers, and so on into the majority of his software. For example, the statement:

ftvrite( &size, 4, 1, f);

should be:

ftvrite( &size, sizeof size, 1, f);

or maybe better yet:

(void)Jivrite( &size, sizeof size, 1, f);

The problem is that in this statement, the size of the variable is written out explicitly. If the software is ported to some other hardware, integers and longs may be a different size. On a VAX, for example, both are 4 bytes; this would cause the statement "irrrite( &rec__size, 2 to no longer be correct.

In Listing Two the following software is shown:

for( i = O; i < v_array ->
                    buf_size; i + +)
          *buf_ptr++ = filchar;

I am at a loss as to why this is not:

memset( buf_ptr, filchar, (size__t)
               v_array -> buf_size);

instead. Although this may seem like a small matter, the run-time library copy of memset( ) would likely be faster than executing the loop above. The reason is that quite a few processors have block-move or similar instructions which can be utilized inside memset( ) to rapidly set the area. Another possibility is that memset( ) could be treated as an in-line function, with the compiler generating the block-move without a function call at all.

Bill Mahoney

Omaha, Neb.

Writing a Loader for EXE Files

Dear DDJ,

We subscribe to your magazine and we often get useful suggestions from the articles. However, we now have a problem that has not been addressed, to our knowledge, in DDJ. Perhaps you can help us.

We need to write a loader for EXE programs that performs the same loading function as the DOS loader. A companion program will begin execution of the program (after massaging the data for our own purposes). We have tried to use the DOS function 75 to do the loading, but we do not have adequate information to complete our task and begin program execution. If we had the exact, detailed data structure of EXE files, we could write our own loader, but we still need information on starting the program. Our books only give cursory, general information. Do you know how we might obtain such information?

Also, as part of the same project we are writing a DOS device driver but having trouble debugging. Our driver works fine as a separate EXE program, but when running as a device driver it fails. DOS DEBUG is useless for device drivers, so we need a third-party debugger.

Dr. Gary D. Hornbuckle

Hornbuckle Engineering

Pacific Grove, Calif.

Porting Small C to the Mac

Dear DDJ,

I have undertaken porting the Small C compiler, as well as Small Mac and Small Link for CP/M-80 to the Macintosh. I took to heart Jim Hendrix' comment that the system could be used easily to create a cross compiler, and I'm trying to create a complete cross-development system. I would hope to be able to generate fully executable CP/M modules, ready for downloading.

My first question is this: Has such a thing been done already? Are there any readers who have experience porting Small C to other environments for purposes of cross-development? Can you offer me any tips?

My second question: At one time there were CP/M emulators for the Macintosh. Am I right in assuming that there are no CP/M emulators on the market now? Are there any readers who would be willing to sell me an old emulator?

Matthew Snyder

South Bend, Ind.

UUCP: inuxc!uivax!ndmath!matt

Bitnet: mjs@irishvm

(mjs@irishvm.bitnet@wiscvm.arpa

CompuServe 71450,2606

GEnie: MSNYDER

Put the Info Where?

Dear DDJ,

The discussion of where to store a programs' information (C Chest, February 1988) was fun, but left a bit much to the imagination. Specifically, how does one force the options structure to the physical end of the file? I presume by creating a file which only contains the structure, then referencing it last in the link list. But then why is stdio.h and fcntl.h included?

Regarding the checksum mentioned, I have inspected the header block of several files and found the checksum bytes to be zeros in all except the DOS utility files. Furthermore, changing a byte in a file had no effect on the ability of DOS to load and run it. I suspect that this aspect of the EXE header must be a holdover from older times.

Thomas Gettys

Lafayette, Col.

Setting Attributes

Dear DDJ,

Ignoring for a second the problems associated with synchronization on the CGA, do all IBM color cards work at segment B800 for text? In other words, if I write directly to the screen, will CGA, EGA, and VGA all use the same character-attribute bytes text-page format starting at B800:0? Are there any differences in the character-attribute technique with regards to VGA?

Will Estes

Saratoga, Calif.

Kent Porter replies:

The EGA and VGA both detect the kind of monitor attached and alter their behavior accordingly. If you have a monochrome tube hooked to an EGA or VGA, the adapter pretends that it's an MDA and starts video memory at segment B000.

The monochrome attributes then apply. When a color display is connected, the same text attributes apply to CGA, EGA, and VGA. All three behave identically in text mode. Of course, EGA has a 43-line mode and VGA has both 43-line and a 50-line mode, and you can also play some games with the number of columns. Mainly, however, it's only in graphics modes that they differ.

An excellent source of information about these matters is Bob Jourdain's Programmer's Problem Solver (Brady/Prentice Hall). Others are Ray Duncan's Advanced MS-DOS (Microsoft Press) and RA. King's The IBM PC-DOS Handbook. If you're doing serious programming, you need at least one, and preferably all, of these references, as well as others.