synchro.net

home *** CD-ROM | disk | FTP | other *** search

/ synchro.net / synchro.net.tar / synchro.net / main / BBS / HDISP16.ZIP / HDUDDIM.DOC < prev next >

Wrap

Text File | 1995-02-01 | 23.7 KB | 560 lines

SUPPLEMENTAL TECH NOTE for HACKDISP v1.666 The HACKDISP Universal Display Driver w/Intelligent Monochrome (HDUDD/IM) copyright 1995 James L. Powers =============================================================================== I. What happened with DOS 6.x? ============================== All versions of HACKDISP prior to HACKDISP with MOTAMA and HDUDD/IM used the host system's resident ANSI driver when displaying ANSI files. This was the primary HACK in HACKDISP. It simplified a lot of things and kept the program very small. Then came DOS 6 and some undocumented changes to the ANSI.SYS driver. HACKDISP v1.5's default behavior in a non-DESQview environment was to trap the screen display scroll interrupt (int 10h, func 06h) to prevent the display, which was output via the host system's ANSI driver, from losing the topmost line. HACKDISP accomplished this by re-vectoring interrupt 10h and inspecting every call to the interrupt for the value 0x06 in the AH register. When 0x06 was found, it was replaced with 0x0F (a harmless call to read the video mode), preventing the screen from scrolling. On program termination, the original interrupt vector was restored. The entire process was a cheap HACK (just like the rest of HACKDISP) and worked with every ANSI driver I tested except DVANSI.COM, which produced very weird results. Anticipating more weird results in the future, the /NOTRAP switch was added to HACKDISP. Nothing like foresight, eh? Smart guy! However, looking back with 20/20 hindsight, the proper course of action would have been to use a /TRAP switch, since most people who used HACKDISP seemed to be unaware the /NOTRAP switch ever existed. Both HACKDISP and DOS 6.0 came out in March 1993. I did not upgrade to DOS 6.2 until December of 1994. When I did, I learned about the problem. I still don't know when it started, but the /NOTRAP switch (that every HACKDISP user was blissfully unaware of even though it was well documented) took care of the problem. From the appearance of the displayed ANSI files, it's obvious (to me at least) that somewhere between DOS 6.0 and DOS 6.2 Microsoft started calling interrupt 10h function 06h for all carriage return/line feed pairs. It figures. Just my luck, I guess. A good HACK gone bad. Why they did this is anyone's guess, but I imagine it must have had something to do with running programs in a DOS window in Windows 386 Enhanced Mode, since the same thing happens (and is avoided with /NOTRAP) in a DOS window under OS/2. Apparently, this was similar to the problem with DVANSI.COM, which must send ALL characters through the scroll interrupt. At the time, the HACKDISP Universal Display Driver was complete but was never implemented in a public release of HACKDISP. It was a bad enough situation to warrant a new release of a program that I had, quite frankly, abandoned due to the sudden and startling revelation in May 1993 that there really is no substitute for ANSI, and that @-codes, as they were (and still are) implemented, were an inadequate substitute. After all, what is the POINT of making a tight, @-coded file if the very BBS software that is supposed to use it turns it into badly formatted ANSI? Obviously, it is simply an excersize in futility. More on this later. But the problems with DOS 6.2's ANSI.SYS demanded a new (and perhaps the FINAL) release of HACKDISP. The moral to this story is NEVER trust someone else's code to stay the same. =============================================================================== II. What ANSI functions are supported? ====================================== All color, monochrome, and cursor-positioning ESCape sequences are supported. Key redefinition, device status request (DSR), set mode (SM), and reset mode (RM) are not supported. The ESCape codes for these functions are NOT guaranteed to be stripped from the file. The "concealed" sequence, ESC[8m, sets the foreground attribute to the background attribute. This may or may not be the correct behavior, but I've seldom seen it used. Illegal color values may be a source of problems. Microsoft's ANSI.SYS driver for DOS has the amazing ability to make sense out of nonsense strings like: ESC[234214;43532124;199;43252;134345;65536;131314;574234132;2135464m but HACKDISP's driver might (or might not) barf on them. However, all cursor-positioning sequences are checked for maximum and minimum values. Some otherwise decent ANSI drivers don't do bounds checking and will send the BIOS an interrupt that will cause your machine to blink out and reboot. This appears to be a new variation on the old "ANSI Bomb" trick that affects only the ANSI drivers in some (not all, but I won't name names) offline readers. Cute. But if anyone asks, you didn't hear about it from me. An ESCape (hex 1B) *NOT* followed by a left bracket (hex 5B) is ignored. Therefore you cannot display the "" character with HDUDD/IM! ANSI.SYS acts the same way. (In TXT mode, ANYTHING is displayed. Laughing Dog and Binary files are not handled by HDUDD/IM and can use any character, although NULL's and hex FF's are transformed into spaces.) Scrolling is not exactly MSDOS ANSI.SYS compatible unless the /MSANSI switch is used. The only RIP sequence detected is "ESC[!". It is ignored. A "BS" character (or backspace, ASCII 8) is always a backspace. A "DEL" (or delete, ASCII 127) is always the character "" from the IBM character set. SOME TERMINAL PACKAGES HARD CODE ASCII 127 AS "DEL", so beware. The DEL/BS "animation" you see sometimes on old Unix systems will not be displayed properly. Tabs (hex 09) are only expanded with the /T switch. They are always eight spaces wide. If you like seven or nine space tabs, seek professional help. Formfeeds (hex 0C) will not clear the screen. Leaving this out is probably a mistake, but you really don't see it used much anymore. I have seen a curious combination of hex 13 (decimal 19) followed by hex 10 (decimal 16) that I don't understand. I have a suspicion that it's a mistranslation of hex 0D (decimal 13) and hex 0A (decimal 10), which is the carriage return/line feed combination. In fact a cr/lf is almost always followed by this mysterious pair. According to my sources, this (13h/10h) is a "DC3/DLE" (Device Control 3/Data Link Escape) sequence. I have no idea what that means, either by itself or in context with a cr/lf. Surprisingly enough, I don't care either. It seems to be relatively rare so I'm going to ignore it. There is no way at this time to control the display speed of the HDUDD. I like it fast! Finally, that GAWD-AWFUL cacophonus claptrap people call "ANSI Music" is NOT supported. HACKDISP strips it out and throws it into the bit bucket where it belongs! I toyed with the idea of supporting ANSI Music and pulled an old file out of my archives to see what was going on with it. I could NOT stand the dinkety-dink version of "Wabash Canonball" that screeched out of the speaker. It was so bad, I had to give the computer the old three-finger salute to get rid of it and I *NEVER* do that when it's running a program! ANSI Music will NEVER be supported! The debugging alone would drive me nuts, so please don't ask. Besides, after hearing one or two tunes, most normal people (those who use eight space tabs) usually don't care to hear any more. =============================================================================== III. Do I still need an ANSI driver? ==================================== Not for HACKDISP, unless you want to use the /MYDRIVER switch. HDUDD/IM does not exactly emulate the way ANSI.SYS scrolls the screen up although it displays a file as if it did. It always clears the bottom line of the screen to low intensity white on black. ANSI.SYS clears it to the last color attribute. This is generally not a problem. For a clearer discussion of why this is, see Rule Three in "MOTAMA.DOC". Many people (especially Windows folks) don't even bother to load one up. Sysops like to avoid using them because of ANSI bombers, or to save memory. Most BBS software, terminal programs, and offline readers have built-in drivers. Some door programs need an ANSI driver to correctly display locally. In fact, HACKDISP's ANSI driver is currently being implemented in a set of extensions for Ricky Belitz's CKIT door developer's programming library so that CKIT doors need not depend on external ANSI drivers either! I CHING - The Online Oracle v1.0, available at better BBS's everywhere, was the first BBS door implementation of HDUDD/IM. =============================================================================== IV. File Mutants ================ Whenever HDUDD encounters ANSI, Wildcat, PCBoard, or Synchronet color codes, they will be displayed. Prior to v1.666, HACKDISP had separate display routines for each format. Now, they are lumped into one routine and mutant files containing all the supported color coding schemes can be displayed. Hence the "universal" aspect of the HACKDISP Universal Display Driver. This is absolutely CERTAIN to cause SOMEBODY SOMEWHERE problems! Say, for instance, your name is Ed. You are an ANSI artist. You sign all your works with "@ED@". Well, Ed, I hate to tell you this, but your silly signature means "blinking brown background, magenta foreground" to Wildcat and you will NEVER see it when you display your ANSI artwork with HACKDISP. As for those black "smiley faces" (ASCII 1 or ""), they are, sadly, the Ctrl-A character, Synchronet's marker for their particular flavor of ANSI substitutes. If you use them in ANSI artwork, it probably won't work, depending on the character that follows it. Use the white guys ('s) instead and there won't be any problem. With my luck there's probably a Christian African American ANSI artist named Ed somewhere in cyberspace who has a fondness for smiley faces, oddball tabs, ANSI music, and is offended by the ".666" version of HACKDISP. Ed, if you're out there, leave me alone! =============================================================================== V. Intelligent Monochrome ========================= HDUDD/IM offers monochrome users the option of better viewing of ANSI and other display files that don't translate well on a monochrome monitor. Many characters simply disappear on monochrome systems! Some background and foreground combinations cause underlining, which is unsupported on (most) color monitors. HDUDD will try to create the most reasonable-looking monochrome translation of the color file when the "/M" switch is used with HACKDISP. The "/B" switch simply replaces every color attribute with low intensity white. Color users who've never experienced the wonders of a monochrome system can get a clue (sort of) as to what us poor chumps who can't afford color have to put up with. IM offers them a unique "duotone" look. This is a small feature of HDUDD, but you'd be surprised how many software developers just ASSUME their color screens are going to be readable on monochrome monitors. Laughing Dog and Binary files are not processed by HDUDD, but the IM feature is still available. Monochrome viewing on color systems with the resident ANSI driver (the "/MYDRIVER" command line switch) is not supported. =============================================================================== VI. PCBOARD AND SYNCHRONET USE =============================== It's no great secret that HACKDISP was originally a Wildcat utility. These systems are not completely supported since I run a Wildcat BBS and have no idea of the day-to-day features or problems with the software. There is a good possibility that may change in the future. PCBoard users will probably find the most bugs in HACKDISP's output, especially as it pertains to system codes. Any PCBoard @-code macro that HACKDISP doesn't understand should be left in the file. You may have to edit the output of the converted file. Synchronet's pause, date, time, and cursor forward macros are all supported. "Elite" text is displayed in the color of the last attribute encountered. HACKDISP's Moron-O-Tronic features may not perform as well with Synchronet files. So far the only native screens I've had to work with were the ones in the demo package. =============================================================================== VII. Wildcat BBS Features and HDUDD/IM ====================================== If you don't run Wildcat BBS, in particular version 3.x, skip this section. The flaws mentioned in this document are not to be construed to mean that the software that demonstrates them is in any way undesirable or unusable. First of all, if you coded your own screens or edited HACKDISP's output and you failed to capitalize the hexadecimal numbers A through F in an @-code, HACKDISP forces them to upper case and generates the correct color attribute. It will look fine with HACKDISP but display improperly on your BBS. Don't blame HACKDISP, it cut you some slack. (So, Ed, if you're out there, @ed@ or @Ed@ won't make it either.) All black-on-black attributes ("@00@") are removed. Some editors don't like them. Some don't care. HACKDISP never produces this attribute, even if your original uses it. HACKDISP's Universal Display Driver bends the rules when it comes to very long line lengths and 80 column files that have been @-coded. This is Wildcat 3.x specific but may also apply to PCBoard and/or Synchronet. Somehow I doubt it. It may or may not be a problem in Wildcat 4, but I really have no idea since I declined on the upgrade offer. Twice. These particular problems were either ignored or forgotten about for the lifetime of version 3. Only a few people ever actually complained about them (well, a few SYSOPS. Users loved to complain about it and they still do!). In fact, the sysop of a local BBS here in Columbus, Ohio actually gave Jim Harrer (in person) a disk with an example of the Tomcat ANSI translation problem on April 25, 1992. He never did get that disk back! I understand it was forwarded to the programming team, but it seems to have gotten lost in transit. Cheers. A. THE 256 CHARACTERS PER LINE LIMIT ==================================== Wildcat 3.x apparently reads one line, as delimited by a carriage return/line feed pair, into a buffer deep inside its guts. Then it proceeds to translate the FIRST 256 BYTES of that buffer into ANSI. If that line is larger than 256 bytes, you are out of luck. The rest of that line is gone forever and will not be translated. HACKDISP will display it, but your Wildcat version 3.x BBS will not. Truthfully, this is not NORMALLY a problem, but let's face some facts here and do a little simple arithmetic. In the worst case scenario, the longest possible line of @-coded junk would be if every character on a single line were a different color. That's five bytes (four for the @-code, one for the character) times 80 characters plus two bytes for the cr/lf. Don't go running for your calculator, that's 402 bytes. Exactly 146 less than MSI thinks you need. Add a few non-printing "macros" like @CLS@, @NOPAUSE@, and @NOSTOP@ and you can crank the minimum value up to around 425 bytes just to be safe. See the file "WORSTCAS.BBS", included with this archive, for a good example of this. This works backwards when Tomcat 3.x translates the @-coded file back into ANSI. The maximum line length of the ANSI translation is 256 bytes. So you can have an @-coded screen that has LESS than 256 characters per line, but the translation may still get messed up! For a graphic example of this see the files "BEFORE.BBS" and "AFTER.ANS", included in this archive. This demonstrates the same problem that was on the famous "Lost Disk of 1992". Note that the longest line in "BEFORE.BBS" is exactly 256 characters wide but many lines in "AFTER.ANS" are truncated at the 256 character limit. (Also take note that "BEFORE.BBS" is NOT a terribly complex screen by anyone's definition.) This is NOT A PROBLEM for HACKDISP. There is no 256 character limit imposed on @-codes! I've toyed with the idea of forcing HACKDISP to ruin the display of your file the way Wildcat 3.x would (for educational purposes only), but I don't want people to come crying to ME over a problem MSI never bothered themselves with. I also don't want to deal with the different bugs in all the different versions (the lone "@" problem of pre-3.5 Wildcat releases comes immediately to mind!). And besides, if I ever got them to look EXACTLY like they would in version 3.x, with my luck I would probably get dragged into court with a "look and feel" lawsuit! No, thanks! Remember: JUST BECAUSE IT LOOKS GOOD WITH HACKDISP DOESN'T MEAN WILDCAT VERSION 3.X WON'T SCREW IT UP ON YOUR BOARD! Out of self-defense, HACKDISP will yank your chain whenever an @-coded file's line length exceeds 256 characters (during file conversion only). DON'T say you weren't warned! If you haven't already noticed, this doesn't only apply to @-coded screens. Any ANSI (*.SCR) file that has line lengths greater than 256 characters will also get trashed. HACKDISP's ANSI output routines have been specially coded to force all lines of ANSI code to be LESS than 256 characters without truncating any display lines. But ANSI optimization is a tough nut to crack and HACKDISP won't necessarily give you the tighest file possible (working on it!). B. THE EIGHTY COLUMN SCREEN (LINE WRAP) PROBLEM =============================================== HDUDD goes to great lengths to display your @-coded files the way you want them to look. However, EIGHTY COLUMN @-CODED SCREENS ARE A PROBLEM! They are not MY problem. They may or may not be your CALLERS' problem. They are YOUR problem! HACKDISP goes through hoops to make 80 column screens, that is, screens with DISPLAYABLE characters on the 1st and 80th columns, display CORRECTLY (or INcorrectly, depending on your viewpoint). Throw them into Wildcat 3.x and watch each line get separated by a BLANK line on the local display. What the hell is going on here? Well... remember each line must be separated by a cr/lf or it gets hacked off at the 257th character. HACKDISP dutifully did EXACTLY what you wanted it to do. It took a perfectly decent ANSI file and automagically turned it into something Wildcat 3.x can destroy! Strictly speaking, HDUDD/IM should display that file with blanks between the lines. But it takes special note of these problems so that YOU won't go blaming HACKDISP for screwing up the file on your BBS. Take that 80 column screen and trim it down to 79 columns. It's the only thing you can do for now. HACKDISP is putting the cr/lf's where they belong; Wildcat 3.x is wrapping to the NEXT line after it hits the 80th column, finds a cr/lf, and outputs it, skipping the line it wrapped to. Hence, the blank lines. Wild, wacky stuff. What Wildcat 3.x SHOULD do is wrap to the beginning of the line it ran off the end of, THEN process the cr/lf. If it did, everyone would be happy and people wouldn't complain that their HACKDISP'd screens don't display correctly on their BBS. Be advised that ALTHOUGH WILDCAT SCREWS IT UP LOCALLY THE REMOTE USER MAY SEE A SCREEN *>WITHOUT<* BLANK LINES. Why? Because the terminal software is SMART! The software does what it SHOULD do. Surprise! The only person getting annoyed is YOU! Go ahead, DON'T take my word for it. Try it yourself sometime. It may not work with ALL terminal software. C. WILDCAT SYSTEM AND USER "MACROS" =================================== Wildcat v2.x system macros were never supported and still aren't! Version 4 may have added macros I'm not aware of. Sorry if this causes any problems. If you reconvert your present @-coded screens to take advantage of HACKDISP's Moron-O-Tronic Attribute Minimizing Algorithm (see "MOTAMA.DOC"), most common, NON-PRINTING "macros" will be stripped out. You'll have to put them back in either with HACKDISP's file suffixes and prefixes or by editing the file manually. This does NOT affect user and system variables (presently only the @DATE@ and @TIME@ macros are expanded during viewing; all the others will show up as "@NAME@" or "@BBS@" or "@[whatever]@" on the screen). If you use ANSI cursor positioning codes in these files (which you really shouldn't be doing because that runs counter to the primary intent of using @-codes in the first place), you will lose them, too, but the cursor will be moved correctly. When viewing files, you may have to hit [Enter] more than once to continue multi-screen files because a @PAUSE@ macro may appear at the last line, causing a "double-pause" situation. Using the /F (fast) switch with HACKDISP will force only macros to pause the screen. D. THE FUTURE OF @-CODES ======================== The last @-code bug fix that MSI ever made that I am aware of was the problem of displaying a single "@" character. This was fixed in Wildcat 3.5, but from versions 3.55-3.91 MSI seemed preoccupied with "graphical user interfaces" for Wildcat. Small wonder the @-code problems were left on the back burner. At the time of this writing, version 4.10 of Wildcat is scheduled to be released in about a month (to be exact, February 15, 1995, according to an article in Computer Reseller's News, January 16, 1995, page 55). Let's hope the problems with @-codes get fixed. =============================================================================== PCBoard copyright Clark Development Co., Inc. Wildcat & Tomcat copyright Mustang Software Inc. Synchronet copyright Digital Dynamics RIP copyright TeleGrafix OS/2 copyright IBM MSDOS & Windows copyright Microsoft DESQview copyright Quarterdeck Office Systems CKIT copyright Rickie Belitz Laughing Dog copyright Jeff Sloan & Yardbird Software HACKDISP, HDUDD/IM, & MOTAMA copyright James L. Powers =============================================================================== Oh yeah, almost forgot... @ED@ copyright Ed ===============================================================================