It's amazing to see the phrase "screamingly fast" applied to the lumbering leviathan that is MASM 5.0 (Examining Room, February 1988). Compare the reviewer's measurement of 120 instructions per second to the greater than 1,000 instructions per second of Eric Isaacson's A86, which assembles directly to executable code and simultaneously creates a symbol file and embeds error messages in the source code. And it does all this quicker than MASM links. I used it to assemble a 12-module program to a .COM file in 4.8 seconds; it took MASM 54 seconds to assemble the same program and 5.7 seconds to link it.
The real purpose of this letter is to complain that MASM 5.0 no longer supports .COM files and nobody says anything about it. CodeView does not offer symbolic debugging of .COM files and MASM 5.0's symbol file is not compatible with Symdeb or other symbolic disassemblers. So even if you're satisfied with the creepy-crawly rate at which MASM 5.0 assembles and links, you have to give up .COM files or symbolic debugging.
I wish you would have a person review assembly-language products who does not think that assembly language is the "most tedious of programming languages" and that "the emphasis is shifting away from assembler as a primary language" and does not call assembly language "assembler." A person who can't be bothered to distinguish verbally between the language and the translator and who thinks that assembly language is unpleasant will not pay attention to details important to assembly-language programmers.
I ask you: in what other language can you write an assembler that assembles 1,000 instructions a second while it does other things and ends up occupying 20K? Or in what other language can you write a utility that searches for a file name in a full 10-Mbyte, 70-subdirectory hard disk in 12 seconds? Why do advocates of one tool (a higher-level language in this case) disparage others?
Kent Porter responds:
In comparison with earlier releases, MASM 5.0 is "screamingly" faster. There are even faster assemblers, and I'll take George's word that A86 is one of them. It's true that MASM 5.0 doesn't produce .COM files directly; you have to run the end product through EXE2BIN if you want a .COM. It's also true that I didn't mention that, and I apologize on behalf of all us reviewers who haven't said anything about it.
Assembly language is indeed tedious. That doesn't mean it's bad, nor did I suggest that it is. It's a tool and it has its place. Most developers have switched to C, Pascal, or Modula-2 because they're more productive (that is, less tedious) languages, writing only high-overhead routines in assembly language. Thanks, George, for setting us straight on the proper use of terminology. When I started programming IBM mainframes in the early 60s, we called the language "assembler," and I think I overheard some other professional programmers still misusing that same term just last week.
It's a revelation to learn that writing about structured programming makes me an "advocate" in some grandiose struggle for language supremacy. Let's try to keep things in perspective, shall we?
I am embarrassed to say that I must retract two statements I made in my letter published in the November 1987 issue of DDJ on the subject of teletypewriter terminals. I was careful to get my facts concerning teletypewriters correct, but I was not as careful with the examples I gave of other standards that had outlived the reasons for the standards being set the way they were. I received a letter from Mr. Clive J. Grant, a professional engineer, debunking both of these examples.
I have forgotten where I read the story of the Roman emperor and the railroad gauge, but it was interesting and plausible and I fell for it. According to this tale, the Roman military had a problem with ruts. Ruts in unpaved roads tend to enforce at least a local standard on wheel spacings because a vehicle with a wheel spacing not matching the rut spacing is in difficulty. The trouble was that in different parts of the Roman Empire, there were different local standards, and this created problems with chariots and other military vehicles when the legions were moved from one place to another in the empire. Therefore, the emperor issued a decree standardizing wheel spacings in the empire, and this standard, enforced by the ruts, endured long after the empire had fallen. When the railroads were first started, so the story went, the developers turned to the carriage makers for the rolling stock, and this resulted in the standard being transferred to rail spacing. In fact, when Stephenson established the railroad gauge, rail systems were in use in the Cornwall mines and he took an average of the mine rail spacings, which varied widely. There is some evidence that there was a Roman standard for wheel spacing, but it may have applied only to Rome and the immediate vicinity and in any event had no connection with the railroads.
The typewriter keyboard tale came from an article advocating the new keyboard layout that is supposed to be much faster. Mr. Grant points out, however, that Sholes, who originated the QWERTY keyboard, never revealed why he arranged the keys in that manner, so any reason advanced for it is speculation. Further examination of this particular speculation shows that its motivation was not to slow the typist, but rather to reduce key pileups.
On the old mechanical typewriters, if a new key was struck before the previous keystroke had retracted, then a pileup occurred. Therefore maximum typing speed was limited by the time required for the spring to retract the previous keystroke after the key had been released. However, many pileups occurred when a new key was struck with a different finger before the previous key had been released. The speculation was that the keyboard was arranged to assign groups of keys apt to be struck in succession to the same finger and thus ensure that one key would be released before the next was struck. This is not quite the same as trying to slow typing. I hope that my blind acceptance of interesting stories I have read has not caused too much of a problem by misleading your readers.
David S. Tilton
Manchester. N. H.
I appreciated Mike Swaine's comments concerning HyperCard in "Running Light" in the January issue of DDJ. Many of his points were right on the mark. Others, however, were wild shots that may sound logical but not to an ol' Mac end-user. HyperCard will indeed bring about a proliferation of stackware, and no doubt there is going to be a lot of sloppy programming. This, I agree, is inevitable. Will it threaten the Mac user interface as you suggest? This I seriously doubt.
HyperCard is merely the growing momentum in computerdom to making the world of computers more user friendly." Stackware may indeed become polluted for awhile, as everyone with a new Mac jumps into the programming ring. But when all the smoke finally clears, what you will have is the availability of narrowly focused programs that serve a limited consumer base that would not otherwise be met by commercial programmers. The reason? Lack of interest, lack of monetary reward, and most of all lack of knowledge in or about these highly specialized areas.
The authors of many of these stacks will be professional people like myself who have an interest in a particular area and are acutely aware of special needs. Our reward for meeting those needs will transcend monetary gains. We are by nature not "sloppy," particularly in our work or whatever interests us. It doesn't mean we will challenge Microsoft or even rival Danny Goodman's work, but it will be good. Above ail it will meet the needs of small groups of people who would otherwise be ignored.
I don't believe Hyper-Card spells the end of anything. Just as the Macintosh has made computers easier "for the rest of us," so will programs such as HyperCard make producing programs easier. That is as it should be. The progress that has been made in making computers easier to use in both the hardware and software will not only continue but will also accelerate.
Programming will not be immune from this progress. We will see "home videos" in software, but Microsoft or even your local computer store won't be selling them---any more than NBC or your local T.V, channel shows home videos. There will be a lot of amateurish stuff around, but it won't hurt anything. Indeed, it will help. It will stimulate imagination and generate interest. There will be a lot of really good stuff that you will never hear of because of limited interest and distribution. No, HyperCard isn't the beginning of the end, or even the real beginning---that occurred with BASIC or perhaps even before. It is just one more milestone in the evolution of the information era.
Ronald L. Cox
Poplar Bluff, Mont.
I've been thinking lately about how unfortunate it is that there is so little standardization in the computer industry, making it impossible to run programs written for one machine on another. I have an idea that could alleviate some of the compatibility problems, and I'd be interested in readers' responses to it.
The idea is this: Design a standard intermediate language, similar to a language that would be generated by the syntax-analysis pass of a compiler (for input to the code generator). Then, use this new language as the form in which software is distributed for use on computers, instead of as native code that is specific to a particular system. The program loader on each computer would recognize the special intermediate-language file and invoke a fast code generator to translate it to native code prior to beginning execution.
There are problems with this---one being that different systems have different capabilities and different hardware. Most systems, however, have a display device that can display ASCII characters and a printer. For many programs this is all that is needed. The intermediate language could include instructions to determine the capabilities of the system (for example, display size), allowing the program to adapt to different machines.
Another problem is that the program distribution medium is different for different systems. Even computers that use floppy disks typically each have their own disk format. This is indeed unfortunate, and manufacturers should be severely taken to task for not standardizing disk format. Perhaps it's still not too late to do this, though.
Nevada City, Calif.
It was with some dismay that I read Allen Holub's C Chest column in the February issue. Saving configuration information in the .EXE file is the easiest way I know of to discourage the use of a program on a local-area network. If users must be able to write to the .EXE file to use the program, then the program becomes a hole in system security, an opening for Trojan horse programs. Second, if users need to write to the .EXE file, multiple instances of the program cannot be run at the same time.
Often a program that has not been written with the LAN environment in mind may be used on a LAN with no modification, provided that the program may be configured dynamically. If the program may be run when its file attributes are shareable and read only, it may be possible that the program can be run on several nodes concurrently.
My preferred method is to use the traditional configuration file, but if the file is not found in the current directory, the environment should be searched for a variable named CONFIG that contains the path to the default configuration file. Using this method the disk does not have to contain redundant copies of the configuration file, but it can be customized for each user on the LAN through appropriate batch files.
Paul B. Hill
Allen Holub's method of hiding configuration information in an application's .EXE file (C Chest, February 1988) is elegant and quite instructive, but I would like to raise a point or two in favor of keeping configuration information in separate files.
Most shared applications on a local-area network are located in shared public directories that are accessed via the DOS path or an equivalent network function. Users of the shared applications are usually granted read-only access to these public directories. Most users cannot be allowed to modify files in the public areas as this would be an invitation to disaster. Application programs that write into their own .EXE file do not work well under these circumstances and can cause LAN managers severe headaches. The result is that you end up with several complete copies of the application program scattered about.
It is possible for a LAN manager to arrange for the proper storage of an application's configuration file if the program is designed with some thought to the problem. I believe the best way to handle the location of the configuration file is for the application to accept a command-line parameter that points out the complete path where the configuration file is located.
The LAN manager usually has methods of setting environment variables when users log on to a LAN that can specify user names of physical workstation numbers. These environment variables can then be used with shared public batch files to execute the application and specify the appropriate configuration file for a particular user or workstation.
It is useful to be able to specify a configuration file in association with a physical workstation because most networks have a variety of workstation hardware.
The programs that are most convenient to install and use on local area networks are those that keep things simple. The best applications are often those that consist of a single .EXE file with no other external files. These are also the programs that LAN managers will purchase in quantity rather than those applications that cause difficulties in configuration, installation, and maintenance. Most of the software currently used on LANs are not the large expensive packages that do strange tricks with configuration and security information but the same simple single-user products that work so well on Personal Computers.
Phillip M. Nickell
I was happy to see the review of The Norton Guides (Examining Room, February 1988); however. I was reminded of these words by Lewis Mumford in the Pentagon of Power: "Unfortunately, `information retrieving,' however swift, is no substitute for discovering by direct personal inspection knowledge whose very existence one had possibly never been aware of, and following it at one's own pace through the further ramification of relevant literature. But even if books are not abandoned, but continue their present rate of production, the multiplication of microfilms actually magnifies the central problem---that of coping with quantity---and postpones the real solution, which must be conceived on quite other than purely mechanical lines: namely, by a reassertion of human selectivity and moral self-discipline, leading to continent productivity. Without such self-imposed restraints the over-production of books will bring about a state of intellectual enervation and depletion hardly to be distinguished from massive ignorance."
As a reasonably happy owner of The Guides, I eagerly dug into the review, which upon reading, I'm afraid to say seemed like a cursory tidbit that I had not expected to find in DDJ. I feel there are three major problems with it:
- 1. I originally thought that the 37K memory residency TSR requirement was a gnomish munchie, but after looking at the 38K file size on my floppy, I thought there was definitely a mistake here. I have run this program on both an IBM PC and an IBM AT compatible with PC-DOS/MSDOS, and it takes up 71,920 bytes installed.
- 2. One of the original problems with the advertising, and especially on the box my program came in, was the reference to being able to run it on a floppy-disk-based system. This is possible if you have drives that hold more than the 600K needed for either the MASM or C database. A hard disk is probably required rather than recommended, unless you wish to write your own or just use a BASIC database. I was not pleased to find that the assembly-language database would not run on my IBM PC floppy system. The review made no mention of this possible predicament.
- 3. One of the most useful aspects of the program is the capability of The Guides (given the right active menu) when initially activated to do an automatic lookup of the entry for the word by the cursor. It's a handy feature to have enabled but nary a mention of it in the review.
I would think that if you're going to do these reviews, you need to have people to do them who have more than a passing interest in the material. As the ultimate end-user of some of this software, I'd like to get information other than what I can get from ads and the users booklet. I'd also like to see how the product compares with others that purport to do the same thing but cost less.
Richard L. Henley
Kent Porter responds:
Let's go by the numbers:
- 1. We're both wrong according to CHKDSK; it takes 72,032 bytes on my AT. The NG.EXE file is 37K, not RAM resident.
- 2. Good point. I haven't run it on a floppy-based system, but Richard's point makes sense because the databases are large.
- 3. Auto-lookup is indeed a dandy feature. If it got short shrift, it's because space in these reviews is limited.