Nice reply, good job. ------------- Original Text From "WirtAtmar" <[log in to unmask]>, on 3/27/98 10:11 PM: Doug Greenup writes: > >Wirt's amazingly low-priced and full-featured emulator! Works over > >wires, through walls and locked doors, and over oceans. Doug lists a number of things that he believes are serious defects in QCTerm: > [QCTerm] won't even make Telnet connections? Clearly, Doug has not been paying attention. Telnet works extremely well in QCTerm, both in "standard" mode (the way that telnet is implemented in Reflection and MS92) and "advanced" mode (a half-duplex mode that greatly increases human perceptual satisfaction and cuts the packet count in half). The only time that a user will generally run into trouble is when the "advanced" mode is selected and the target HP3000 lies behind another box (a UNIX firewall perhaps) that is not accurately relaying the telnet commands to the HP3000. In such a case, all the user needs do is drop back to "standard" mode. If QCTerm still won't work in those cases, neither will anything else. There are several additional features that would siginificantly help the half- duplex mode be even more efficient and more satisfactory to use -- and those are being actively investigated. > QCTerm .4 Alpha does not script, That's true. A scripting language can't be written until the basic terminal emulator is completely finished. > [It} does not have file transfer, That's also true. We've considered file transfer a secondary priority item. But it will come. > [It] does not do NS/VT, As I've mentioned before, I'm not sure that we will ever support NS/VT. The modified telnet that we've been working on is nearly identically as efficient as NS/VT, the real difference being that telnet is a universal standard -- and unfortunately, NS/VT is not. > [It] does not handle 132 worth a darn, Please allow me to disagree vigorously with you on this point. We did design 132/200 column support differently than a standard terminal (or R1 or MS92) does it. Rather than squish the characters down to make them look like Clint Eastwood in a spagetti western put on TV, we left the characters in their proper proportions by making the font size a little smaller and providing a cinemascope look to the screen. Before we went ahead with this design, because it would be "different" from what people might expect, we genned up prototypes of both formats and asked approx. a hundred people who happened to come through which format they liked better: squished or cinemascope. Cinemascope won unamiously. And we're still asking people. The latest askee was Ernest Hill, a member of this list who normally resides in Saudia Arabia. Ernest was here Wednesday night and got the standard treatment: an enchilada dinner, a tour, and then two hours of tortuous grilling, comparing side-by-side the features of QCTerm and Reflection to see which of the various features he liked better. On the subject of 132 column display, Ernest, like everyone before him, voted for cinemascope. Clearly, we're eventually going to find someone (perhaps Doug) who doesn't like this format, but you can blame Ernest (and all those who came before him :-). And you can ask us for your money back. > [It] does not support append forms, I don't understand the "append" part of the comment, but QCTerm does support forms. > [It] does not handle em220, That's true. DEC emulation has been considered a second priority item -- although I know that once we get it in, it will make QCTerm a "big seller" with universities. Now that the vast majority of the basic functions are in the emulator, putting in a mode switch in escape processor will not be a great deal of trouble. > [It] does not work with Smith Gardner MACS package, That comes as news to me. However, if anyone should find any program that the emulator QCTerm does not work perfectly with, please let us know. If we have your permission to dial into a dummy account on your machine where you can recreate the problem, we can debug it relatively quickly. If you have reservations about letting us dial in, there is a debug sequence in QCTerm that allows a recording of all incoming and outgoing communications traffic, regardless of the transport medium. The QCTerm-specific sequence to turn communications logging on is: Esc&k12345X and Esc- to turn it off. When you're in debug mode, the communications panel at the bottom of the screen lights up in red. The log file is c:\aics\temp\debug.txt. If you would e-mail us that output (and possibly a fax or e-mail of your screen), we can see precisely what caused the problem. > [It] does not run on Macintosh, does not run on Dos, does not support Java, That's all true -- and probably always will be. > [It] does not allow for any keyboard remapping (Block mode ENTER is not the ENTER key) Doug is absolutely correct: the block mode ENTER key is not the RETURN key. They are completely separate functions. We've hard-assigned the F12 to be the block mode ENTER key. F12 is a convenient place for it -- and if you miss and hit an adjacent key, none of them do you much, if any, harm. However, based on user comments received, primarily from Ted Ashton, the numeric pad ENTER key will be allowed to be defined as an auxillary block mode ENTER key. Look for that in the next release (currently scheduled for Monday). >does not support passthrough printing on NT or Windows 95! That's also true at the moment. Passthrough printing (generally used for PostScript and PCL graphics) is clearly a second-level priority, but we outselves need it as much as anyone, so that won't be much longer in coming. Standard screen printing, however, works quite nicely in QCTerm, better I believe than in Reflection (unfortunately, I've never seen a copy of MS92's output). > MiniSoft 92 installed in over 6,000 HP3000 sites sells for as > little as $59.00/copy (educational/non-profit pricing) or $79.00/copy (for > the rest of us) over here in the U.S. and we feature a toll-free 800 number > for support (works from anywhere in the world) included with the license. > One or two support calls to AICS long distance (assuming you can get a hold > of them) and you have burned up the savings, especially from South Africa. > Frankly with the state of this ALPHA .4 product you will be making a quite a > few tech calls! Actually, so far only one person has called. Everyone else has corresponded by e-mail -- and those correspondences have come from all over the world -- and all have been answered in just a few hours. Support is something we take very seriously. However, let me say, that if you're in the US, I would appreciate it if you would call rather than e-mail us a description of your problems. Voice conservations tend to carry an immensely greater amount of information that does a succession of e-mails. Our numbers are: (505) 524-9800 and (800) AICS-INC > I am sure AICS will eventually achieve some level of functionally and > reliability. Doug may have missed the original conversations regarding letting QCTerm go in stages. No one is more picky that I am about quality and reliability. In the voting that occurred regarding whether to let QCTerm go in incremental stages or hold it until it was completely done, the vote was again unamimous to release it in stages. Ordinarily, we shield our products from inappropriate criticism by releasing them to only a small group of intense users -- and refine them over and over again until we know of absolutely no errors in their behaviors -- before we release them to the general public. Because QCTerm is a free product -- and because having it be used by so many people at once is to our advantage -- we changed our mind for this one instance, based partly on the vote here on the list, and partly on the fact that we should be able to get the errors out of QCTerm all that much faster. But the downside of such an approach are clearly the inevitable misunderstandings, such as Doug's. Finally, Ted Ashton wrote: > > Also it would > > be nice to be able to set QCTerm to go away when I logoff. > >I can handle having it not go away, it's a minor thing. I found it irritating, >though, that when, upon discovering that it wasn't going to disappear on it's >own, I hit ALT-F4 (the usual Windows sequence to make things go away) it >refused to leave. QCTerm's terminal emulator is programmed as a "child" form. The "parent" is the opening screen (the petroglyphs). ALT+F4 works there, as it does on any parent form, but it doesn't work when only a child form is visible. We did program up CNTL+Q, Macintosh-like, as a way to quit the terminal emulator and return to the main screen (from where, you can type ALT+F4 if you wish). We also programmed up the close box as a direct quit, for those who don't want to perform two operations. The reason that QCTerm is being programmed in this manner is there will be a number of similar child forms that branch from the parent, the terminal emulator being just one of them. Some time ago, I was in a meeting with Steve Cooper at HP in Cupertino where Steve said that the single item holding the HP3000 down was its dowdy terminal interface. Steve's comment made a substantial impression on me (like much of what he has to say). Rather than wait for someone else to solve the problem that universally bedevils us all, I thought we might as well do it. It wouldn't be all that expensive. I originally allocated $150,000 to build a better interface and simply give it out to everyone at no charge. So far we're about 40% done and have spent only about $40,000, so we're well under budget, if not time. Clearly, no one will be forced to use any of this. I doubt that QCTerm will ever be as fully featured as Reflection -- but there are substantial advantages in keeping a product as simple as possible. Each additional configurable item increases the probably that someone will get it a little screwed up -- and increase the support costs for us all. QCTerm -- and the coming screens -- will simply be available for your use if you wish to take advantage of them. Wirt Atmar