Dear DDJ,
I'm new to C++ and to Zortech's implementation, so I really enjoyed Tom Green's "A C++ Multitasking Kernel" in the February 1989 issue. There is a simple error in Listing Two line 58. The new task, workspace constructor method should end with a closing brace instead of the opening brace as shown in the listing.
After entering all the listings, MASM was nowhere to be found. Since the Zortech compiler (ZTC) calls the assembler program automatically (and assumes MASM), I thought that I would probably not be able to produce an .EXE program. By using Borland's Turbo Assembler and temporarily renaming it, I was able to produce an .EXE program that is 14,685 bytes long (small model).
This was an interesting experience in piercing together a running program. Keep up the good work.
James H. Wilbanks
Dacula, Georgia
Tom responds: I am glad you enjoyed my article. It was a lot of fun to write. You are correct; there is an error in the code. When I got the first proofs back from DDJ, there were a couple of lines of code missing. The last line of the task class constructor was one of the missing lines. I guess we got crossed up on what the missing line should be. As you also found out, Borland's TASM works just fine with my code and with the Zortech C++ compiler, if you rename it so that the ZTC shell can find it. In taskdemo.cpp, I say that you must use MASM 5.xx. I use some of the advanced features introduced in MASM 5.0 (such as .MODEL, .DATA, etc.). TASM also supports all of these features. I use both TASM and MASM with my Zortech C++ compiler. Here are two more errors in the code: In Listing Two, line 49 reads: task( ); // destructor, but should read: ~task( ); // destructor. In Listing Two, line 78 reads: task::task(void), but should read: task::~task(void).
Dear DDJ,
Your magazine is informative as usual. In reading through the letters to the editor (February 1989), I couldn't help but notice where Frank Little of Clydach, Swansea brought up the topic of paper transfer vs. computer transfer. I also couldn't help but notice that he seems to lack a basic understanding of the human. I'm not putting down, just amplifying the missed point. Frank, did you ever see any student open only one book at a time when really digging in to study?
Currently, one of the major differences between humans and computers is that humans rely extensively on pattern recognition for even the most common of day-to-day survival and computers (percentage wise) have yet to recognize any patterns beyond simple binary "text" (instructions). Even on a CAD/CAM system, the computer cannot point out the file cabinet on the floor plan. And you and I each received and processed numerous patterns in order to navigate our way to work today (and in "real time" no less).
To further belabor the point, even children that were raised by wolves and such, who speak "no language," recognize weeds, rabbits, and rabbits in the weeds. Try getting your computer to pick out your child or sweetheart in the picture there. The "raised wild" child can.
More: I read Jay van Santen's request for help on large arrays, and I do not understand Tonkin's reply. Jay made a straight request, and Tonkin simply went off in his own world. I too now want to know: How large is the data segment?
More: Mr. Douglas Mohr is quite correct; Intel propagates ineptitude at an alarming rate, and at the chip-level no less. Zilog has superior design and implementation at most all levels of IC CPUs. I also agree that "ol' CP/M" is still a better operating system. Data loss was far less than in my experiences with MS-DOS, and data recovery was almost always possible, even in multiuser environments. Data recovery under MS-DOS is almost nonexistent. The file following (linked list) method of data storing is full of trouble. Always has been, always will be. If you break the chain (lose the pointers), you get to fish for your "anchor" (data) at the bottom of the bay with all the other discarded anchors (released data blocks). Even under the best of conditions, I find data recovery attempts impractical fewer than 50 percent of the time under MS-DOS.
Who knows, Mr. Mohr, maybe someday MS-DOS will actually be documented so users can use it. I'd even settle for consistent reactions to a given program. Don't hold your breath though. I'm not.
Steven L. Turner
Sacramento, Calif.
My God, what a bunch of cry babies in your February letters page! Since there were only three letters, may I respond to each of them?
To Mr. Frank Little, about your sentence "(Programmers') salaries are sky high ..." I've read this often, and my response is always "balderdash!" (Frequently expressed in a pithier, shorter word.) I don't think I'm overpaid. My clients don't think I'm overpaid. If they did, they would hire someone else. (On the other hand, my wife thinks I'm underpaid.) I'll gladly charge less once someone decides that my gasoline, housing, utilities, and taxes will be comparably reduced.
To Mr. van Santen about QuickBasic and Bruce Tonkin in his reply: First, Mr. van Santen obviously meant to say that QB uses the Compact memory model, not the medium model. The 64K restriction is, as everyone knows, an artifact of the Intel architecture. Every language implemented for the 80x86 family has this problem, and most offer at least one way around it.
To Mr. Douglas Mohr (whose whinning prompted this letter): First, I'm sorry you were "forced" to use a PC at work, and I hope you will soon be allowed to work on a PDP 11 again. In the meantime, I'd like to douse your flames.
Flame Zero: Yes there is abysmal PC software, and maybe Aztec C is one example. There are terrible restaurants, terrible cab drivers, and terrible cities as well; very few of them come with free upgrades.
Flame One: In the Intel architecture, programmers must pick the memory model for the same reason that they must pick the variable types, file structures, and sorting algorithm. "One size fits all" might work for muu muus, but it makes lousy code. I also prefer a linear address space, such as the 680x0 architecture provides.
Flame Two: Yes, you are being naive. In the case of the C Users Group, you are getting unsupported source code for whatever machine and compiler someone chooses to upload. If you use CP/M, and don't have BDS-C, then buy it! If you were looking for executables, write to PC-SIG or FOG.
Flame Three: If you truly want a TECO-like editor for the CP/M, look at VEdit (from CompuView) or PMate (from Phoenix, I think). Why not write your own TECO, starting with source code from Edward Ream's public domain ED editor, or David Conroy's micro-Emacs?
Flame Four: I also prefer Unix, but that's not where the market is. NeXT is the next step up from CP/M? Funny, I thought it was a step up from Macintosh.
Mr. Mohr, you have the right to bitch as much as you want. DDJ editors, why must you inflict this bitching on us readers?
Arthur Metz
Los Angeles, Calif.
I read with considerable interest Douglas Mohr's letter in the February 1989 issue of DDJ. I couldn't agree more! I am a programmer by profession; I write and test software for my company's line of IBM compatible, industrial computer systems. 8086 assembly code and MS-DOS bring home the bacon, but I have little love for either. So I'll add a few more flames to the fire.
Continuing where Mohr left off. Flame Four: Why did Intel create, and Microsoft propagate, a set of assembler pseudo-ops that are totally unnecessary? MASM and its clones require high-level language constructs, such as "PROCedures." What does that have to do with assembly language?
MASM also insists upon knowing the contents of segment registers. Why? Having programmed just about every microprocessor from the 4004 forward, I have never seen such a disastrous assembler. It is obvious that MASM is an assembler for the C programmer, what with structures and records and such, not an assembler for the experienced assembly language programmer. I use the version that runs under CP/M-80, although an MS-DOS version is available. It isn't perfect, but it allows programmers to write in assembly code, not in a pseudohigh-level language.
Flame Five: Mohr is right in his statements regarding MS-DOS. What do you expect from an illegitimate cross between CP/M and TRS-DOS? Except now it's a three-way incestuous cross with Unix as well. The original MS-DOS combined the worst features of CP/M and TRS-DOS, with the best features of neither. If you want that, you're much better off the CP/M; it's a much friendlier development environment, even for alien processors. Now they're thrown in some Unix features. If you want that, you might as well go with pure Unix and get all the benefits!
Flame Six: Now that we have cheap AT-class machines with ten times the memory, we can write all our code in inefficient high-level languages, hog all kinds of memory, and get about the same level of performance as we got ten years ago from a 4MHz Z-80 running efficient machine code. The original 4.77MHz PX was a joke. My 2-MHz IMSAI will run rings around it.
Flame Seven: This is something that really doesn't matter, but I've never seen anyone say it before: MS-DOS machines in general, and the original PC/XT in particular, have to be the ugliest computers in existence. Just before the PC was introduced in 1981, we were starting to get some really nice, integrated systems like the TRS-80 model III/IV, the NorthStar Advantage, the Superbrain line, and so forth. Then along comes IBM with a system that instantly reminded me of a bad cross between a model I TRS-80 and an Apple II+. Suddenly, we were thrown back to 1977 with three boxes connected together by ten million miles of cables. And the three boxes didn't even go together. At least the old model I TRS-80's parts looked like they belonged together! I suppose I have to reluctantly agree with the thought that this allows you to select your own monitor and keyboard, which brings us to...
Flame Eight: Keyboards. There was a huge stink about keyboards when the PC was introduced, and it has never really died down. With the millions of replacement keyboards available, however, I have found only one that is acceptable, the Jameco that sold for $30 a couple of years ago, a surplus Televideo PC keyboard. IBM has totally ruined the world of keyboards. Almost all the keyboards made prior to the PC were similar. Look at a TRS-80, any older terminal, and especially an IBM Selectric typewriter. I'm not talking about layout; I have typed on everything from old manual typewriters to teletype machines, and can adapt to any layout. I'm talking about the size and shape of the key caps, and the slope. I am a very fast touch typewise, and I just flat cannot type on those flat IBM-style keyboards. I expect a discrete step between the rows of keys and these keyboards do not have it. The key caps are a different size, and many of the keys, such as Control, Shift, and Return are "stepped" for whatever insane reason. My kingdom for a decent keyboard! The above mentioned Televideo keyboard is pretty good; it is made in the old style, and I can type on it. It's in the original PC layout, which, yes, is dumb, but I can adapt to it if the keyboard is good. And the IBM keyboard clicks...
End of Flames: Overall, the IBM world has brought little to us in a new technology. So I'll just sit here in front of my IMSAI until a Mac II becomes affordable, or even the NeXT. Absolutely a real first step up from CP/M.
Mark D. Pickerill
Salinas, Calif.
Somewhere twixt the programmer and the printed page, our production equipment developed the habit of eating tildes (~) when they appeared in program listings over the last couple of months. We've solved the problem and you can be assured that it won't recur. (Neither the source disk nor the listings on CompuServe were involved.)
Two articles affected were May's "TAWK: A Simple AWK Interpreter in C++" by Bruce Eckel and April's "C Programming Column" by Al Stevens. Please note the corrections below. We apologize to readers and authors alike.
Listing 1, line 17: ~field( );
Listing 2, line 16: field::~field( ) {
Listing 3, line 17: ~csascii( ); // destructor
Listing 4, line 38: csascii::~csascii( ) {
Listing 6, line 32: ~token( );
line 50: ~parse_array( );
Listing 7, line 25: token::~token( ) { // delete heap if allocated:
line 119: case'~': // the "else" part of an "if" statement
line 135: "'(','<','?',':','~','.','p','m','c' or '@'");
line 207: parse_array::~parse_array( ) {
Listing 10, line 6: "@(0)","@(1)","@(2)","@(3)","@(4)@?4@: @~@.@(5)"
Listing 11, line 10: @~@.@~@?4@:@(4)
line 11: @~
C PROGRAMMING COLUMN
Listing 4, line 75: writecomm (~bno); /* 1s complement */
line 190: if ((nbn & 255) != (~blk & 255)) {
Copyright © 1989, Dr. Dobb's Journal