|DÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ |Dº |5On the Editor's Desk |DºÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ |DÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ ^C^1On the Editor's Desk ^Cby ^CDaniel Tobias In this column, I give news and reviews of products and developments that have reached my desk. A major element of the computer industry news lately seems to be a wave of litigation. It seems everyone in the industry is suing everyone else these days. First Lotus sued some other software companies over the "look-and-feel" issue of software copyrights, even though its own look and feel was largely taken from the earlier VisiCalc program. Now, Apple is suing Microsoft over alleged violations of its copyright to the Macintosh user interface, even though ^1that^0 was largely taken by Apple from an interface developed by Xerox in their PARC laboratories. All of this is a shame. In the old days when hackers controlled the field, everyone worked together in a spirit of cooperation; the competition within the industry was a friendly rivalry between fellow enthusiasts, fought on a technical level as everyone tried to come out with the most ingenious new hardware and software products. Now, with personal computers a big money field, the whole complexion is different; while the "techies" may still prefer hacking to litigation, they no longer control the corporations that their 1970's enterprises have evolved into. These days, corporate lawyers control legal policy in the computer industry, and everyone else is the loser. There's another case presently in the courts which, while it's not getting as much press as the Apple/Microsoft battle, will create important precedents with regard to the legal status of bulletin board systems (BBS's). Linda Thompson of Indiana has sued Bob Predaina, the sysop (System Operator) of the Professional's Choice BBS. In this suit, she alleges that the sysop exposed to public view a number of private messages she exchanged with another user of the BBS. It is also alleged that the sysop terminated her access to the system (presumably after she complained about her private messages being exposed) even though she had paid a fee which was supposed to guarantee her access for a year. This case is interesting in that it's the first one involving BBS's to be filed under a recently-passed Federal law guaranteeing privacy of electronic mail. Existing laws guarantee privacy of older forms of communication like paper letters and phone calls, but E-Mail was formerly unprotected from snooping, whether by private individuals or government agencies. This law is primarily intended to apply to commercial E-mail services like MCI Mail and CompuServe. BBS's, while they provide similar services, are usually run by hobbyists, and are generally much more informal. However, they are still E-Mail providers, and hence subject to the same law. This means that users who enter private messages have some legal guarantees of the privacy of these messages. If the allegations in this suit are correct (I haven't seen any statement by the sysop in question, so I have no way of knowing the merits of the case), then the sysop was acting in a highly unethical manner, and probably deserves to be sued for it. However, I hope that this case doesn't have repurcussions that lead to BBS's being entangled in legalese and government regulation. A hobbyist running a BBS in his spare time can't exercise the same level of care that a multi-million dollar corporation puts into its commercial service, and slipups might be made that can be construed as violations of various laws, such as accidentally including private messages in a publicly-viewable listing. One hopes that lawsuits under the E-Mail privacy law remain limited to cases of gross violations with malicious intent rather than simple mistakes, but given the state of litigation in general these days, I kind of doubt it; there may end up being such a rash of litigation that many "hobbyist" sysops end up shutting down their systems for good. Product review department: For years now, we've been producing products sometimes referred to as "magazines on disk." Well, now, Infocom (125 Cambridge Park Dr., Cambridge, MA 02140) has come up with a new twist on this genre, with a line of ^1comic books^0 on disk. The ^1Infocomics^0 series consists of stories told with words and graphics on your screen. They're not adventure games: the story has only one ending, which you can't affect. However, you ^1can^0 change viewpoints at various points in the story, switching from one character to another. The one I looked at, "Gamma Force in Pit Of A Thousand Screams," featured the origin story of a team of three superheroes arising to overthrow the oppressive dictator of their home planet. It wasn't great literature, but the intended audience of youngsters should find it interesting. I suggest you make few viewpoint shifts the first time through (when I took advantage of all shift opportunities I rapidly got totally lost, viewing the ongoing adventures of characters who I didn't even recognize), and then go back and go down other paths to get the rest of the story. Some plot elements don't become entirely clear until you've seen them from more than one angle. It's basically a fun idea. However, I wonder if they'll sell many at the $12 price tag; regular paper comic books are still available for as low as 75 cents. Even the high-priced "graphic novels" of the comic book world are usually less than $12, and offer better story and art (the IBM's CGA is sorely limited in color and resolution). One more thing: as a comic fan myself, I'd like to point out that simplistic stories, such as those found in the InfoComics, are not the only kind of "comic book" stories there are. Recent comics like DC's "Dark Knight" and "Watchmen", and many overseas comics in France and Japan, show a great amount of sophistic- ation, and have many adult readers. I hope, if Infocomics are successful, that they don't have the unfortunate effect of reinforcing the public impression that comics are just "kid stuff." Maybe Infocom (or another publisher) can try producing some more-adult material (in the sense of increased intellingence and sophistication, not necessarily sex and violence) in a similar format of a graphics-and-text storyline accessible by multiple viewpoints. Followup department: A couple of months ago, I reviewed Procomm-Plus from Datastorm Technologies. Since then, I have made some more involved use of its script language, Aspect, to write complex scripts involving the automated transfer of electronic mail. While I still think the program and its script language are very good, I found some serious flaws I'd like to point out. First of all, when you use the script command FGETS to read a line from a text file, it comes out with a linefeed at the end. This causes problems when, for instance, you need to read from disk the name of a file you wish to download or upload; the file handling commands don't like linefeeds at the end of the names they use. The only way around this that I've found is to read the name one character at a time, stopping when a linefeed is reached without appending it to the string. Unfortunately, this is very slow, since it involves doing a loop with GOTO statements, which requires a scan of the entire script file to find the place to go to. This can be speeded up somewhat by placing it near the beginning of the script file, but it can still cause a simple input to take as much as 30 seconds, where it would have taken less than a second if FGETS could be used. This is not very desirable if you're in the middle of a long-distance connection, or online with an expensive commercial service. There also appears to be a problem with incoming characters sometimes being lost while Procomm+ is in the middle of doing other operations in a script; this can cause the "WAITFOR" command to wait forever for a target string that's actually already come, if it comes too quickly after the previous command in the script was reached. This can generally be remedied by careful crafting of script files, for instance by doing any lengthy computations or other operations before the carriage-return is sent to the modem to signal the remote service to start sending more information. Finally, I haven't found a very good way to output an end-of-line sequence (Carriage Return and Linefeed) to a text file being written to from a script. The caret sequences ("^^M") which work in sending text to the modem are not supported in the commands to send lines to a text file. This is a problem when you want to create a text file with multiple lines. The only way around this I could figure out is to create a file LINEFEED.TXT containing a linefeed character, then read it into a string variable at the start of your script, and output that string whenever you need a CR/LF. (The Carriage Return apparently gets added automatically when a Linefeed is sent.) I called Datastorm's technical assistance department, and after considerable deliberation (and placing me on hold at long-distance rates several times), they finally told me that the linefeed-on-input-string matter was a real problem that they hadn't been aware of, and that they would fix it in the next release. However, since the present release (1.01A) is already out, there's no telling how long it will be until the next release. In their attempts to solve my problem, at one point one of their programmers suggested that I use the STRLEN function to get the length of an input string in order to use SUBSTR to remove the linefeed. Problem is, there isn't any STRLEN function in Aspect. That's another thing they plan on adding in the new revision, now that I've pointed it out to them. Regarding the output of linefeeds, they told me to use "BINARY" files instead of "TEXT", and that the "caret" commands would work in this case. I tried it afterward and it didn't work. Maybe the new revision will take care of this by enabling caret sequences in disk I/O strings as well as modem I/O. Anyway, despite these flaws, I still find Procomm+ to be an excellent program, with many powerful features, and these flaws shouldn't get in the way of most users with less demanding tasks that don't require scripts that read and write text files on a line-by-line basis. But if you do wish to make use of the full sophistication of the script language, then maybe you should hold off purchase of Procomm+ until the flaws are fixed in a later version.