synchro.net

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

/ synchro.net / synchro.net.tar / synchro.net / main / TEXT / WWIV9207.TXT < prev next >

Wrap

Text File | 2001-07-30 | 31.2 KB | 592 lines

┌┐┌┐┌┐┌┐┌┐┌┐┌────┐┌┐ ┌┐┌─┐ ┌┐┌────┐┌┐┌┐┌┐┌────┐ ╔═════════════││││││││││││└─┐┌─┘││ │││ └┐│││┌───┘│││││││┌───┘═════════════╗ ║ Volume 3 ││││││││││││ ││ └┼┐┌┼┘│ └┘││└───┐│││││││└───┐ July 25 ║ ║ Issue 3 ││││││││││││ ││ ││││ │┌┐ ││┌───┘││││││└───┐│ 1992 ║ ╚═════════════│└┘└┘││└┘└┘│┌─┘└─┐ └┼┼┘ ││└┐ ││└───┐│└┘└┘│┌───┘│═════════════╝ └────┘└────┘└────┘ └┘ └┘ └─┘└────┘└────┘└────┘ ┌─────────────────────┐ │This Month's Features│ ┌──────────────────────────┴─────────────────────┴────────────────────────────┐ │ Random Factors.......................................Wayne Bell (1@1) │ │ │ │ Compucom Bites The Dust..............................Omega Man (1@5282) │ │ │ │ TechnOTES............................................WWIVnews Staff │ │ │ │ Optimizing HS/Link for WWIV 4.21.....................Lance Halle (1@6211) │ │ │ │ Filo's Mod of the Month..............................Filo (1@5252) │ │ │ │ Dateline: @#$*()#!...................................Omega Man (1@5282) │ └─────────────────────────────────────────────────────────────────────────────┘ ───────────────┬─────────────────────────────────────────────┬─────────────── │ Random Factors │ │ Creative Commentary by Wayne Bell (1@1) │ └─────────────────────────────────────────────┘ First, I'd like to make some comments on distributing mods to WWIV. I (obviously) have no objection to distribution of mods, but people need to be careful of distributing too much original source code along with the mods. To quote from the WWIV source docs, "If your modifications would require you to distribute over 100 lines of the initial BBS code, you should contact me before you distribute it, sending me a copy, and asking if it's OK. Most likely it will be." Do not just distribute the modified routines, or (even worse) the whole modified files. There are freeware versions of the program 'diff' floating around, that will show you exactly which lines were modified. In creating 'upgrade' files for new versions of the BBS, I use the diff program to help create the upgrades. It really isn't that difficult, and actually might help you to catch some change you might have forgotten to document. Secondly, on subboard add/drop requests. Please do >NOT< post a message on a sub, saying "please drop my system from this sub." Whenever I see a message like that, I simply delete it and ignore it. Sub add/drop requests should come through E-Mail only, from user #1 on the system to be added/dropped. Or, if possible, use automated add/drop requests. Posts about adding/dropping are likely to be missed by a sysop skimming posts (or not read at all, if the sub is moderated by a co-sysop), and E-Mail from non-#1 accounts is meaningless, as it could be anyone on the system sending the E-Mail. Thirdly, WWIV v4.21a will probably be out in early August. Lastly, net31 will probably be out at the end of July. net31 will return E-Mail to unknown users, fixes up a few minor bugs here and there, has some additional interfaces for other programs to interface to the net software, and will support automated gathering of subs.lst info. I'll go into more detail in the automated subs.lst feature after net31 has been out for a while, as it won't be very worthwhile until many people are running net31. All you will have to do is create a text file listing the sub types you want automatically reported, and the net software will do the rest. ───────────────┬─────────────────────────────────────────────┬─────────────── │ Compucom Bites The Dust │ │ Investigative Report by Omega Man (1@5282) │ │ With Contributions by The WWIVnews Staff │ └─────────────────────────────────────────────┘ Two months ago, TechnOTES reported rumors that Compucom, manufacturers of some of the lowest-priced high-speed modems, had ceased operations. While rumors had persisted on the netted subs for months of financial problems and production setbacks, some of which were reportedly related to the recent death of a major Compucom executive, few took them seriously as the same rumors were also being passed around regarding both Hayes and US Robotics. IN SEARCH OF A CORPSE ───────────────────── As the May issue of WWIVnews went to press, the rumors apparently became fact, as calls to the Compucom purchase and support lines either went perpetually busy or perpetually dead. Those few who could get through the lines to ask about the rumor were greeted with a recorded announcement informing of the company's demise, and who they could contact for more information. As expected, this information spread like wildfire throughout the computer networks. However, some doubt was cast on its validity as _PC Sources_ reported that Compucom was releasing two new versions of the Speedmodem during the summer. A spokesperson for the advertising department of _PC Sources_ explained that the report had been confirmed and sent to press two months prior - a standard procedure in the journalism industry - and that at that time Compucom was still in business. Naturally, this further confused the issue for all interested parties, especially when none of the other major computer publications were mentioning anything regarding Compucom's status. SEANCING THE GHOSTS ─────────────────── Only last month, _Boardwatch_ magazine became the first publication to confirm Compucom's collapse, which has been verified by subsequent follow-ups by members of the WWIVnews staff. One such follow-up resulted in the following statement from a former Compucom employee, which has since been reposted on several netted subs in the past few weeks: ───────────────────────────────────────────────────────────────────────────── Compucom Statement Compucom has closed its doors (due to unforeseeable financial circumstances). We here at technical support would like to continue to support the product as long as we can ON OUR OWN VOLITION. At this time, we can NOT provide you with refunds, RMA's, or Exchanges, though we can help with various support issues. We can upgrade you to the latest EPROM, providing you either pre-pay for the roms, or have previously returned ROMS. A number of us speedmodem supporters are currently planning to establish our own Company, which will give us the ability to support the entire line of speedmodems. We will continue to make important announcements and information available on the San Diego Support BBS (The General) at (619) 281-2622 and in the various speedmodem conferences. Q. & A. Q. I want my money back A. The company is gone, we at tech support on our own volition, are trying to inform/help. You may have financial recourse depending on how you paid. Q. What about firmware? A. We are in touch with the chief design engineer, and hope to work with him in continued development. Q. What about RMA's? A. We will try and send it back to you. Q. Warranty? A. The Company is out of business. ───────────────────────────────────────────────────────────────────────────── Shortly after this statement began circulating, Shawn Stamps (2@4401) posted the following additional information regarding Compucom's European division: ───────────────────────────────────────────────────────────────────────────── [..] the American arm of Compucom is dead. However, the company still thrives in Europe (Compucom Europe, Ltd, in Glasgow) and they have been trying to keep working on the upgrades, though with Lightning Communications licensing CSP (the Compucom proprietary protocol - nasty thing that it is), the european counterpart is terminating even the low level of support it has graciously provided. I have been keeping in touch with them in the hopes that MAYBE I could get ahold of the development hard/software for the damn thing, not to make new modems, but to locate new parts and to try to fix the dern things. ───────────────────────────────────────────────────────────────────────────── Finally, a former Compucom employee in the tech support division, who asked to remain nameless, made the following commentary to a WWIVnews in e-mail on Usenet: ───────────────────────────────────────────────────────────────────────────── The company had been experiencing financial problems for months. That much we all knew. What we didn't know was just how bad those problems really were. Most of us kept the information to ourselves, though; not because we feared losing our jobs, but because we felt really strongly about our work. For most of us, it was a labor of love, and we really busted our asses to make sure each Speedmodems performed as flawlessly as possible. We really feel what we produced weren't just high-tech tools, but works of art with a little bit of our souls along for the ride! Don't give up on the Speedmodems just yet, tho. We're still trying to supply some amount of tech support on our own, and we're trying to arrange some sort of financing so we can resurrect the company under our ownership. If you're really interested in keeping up with what's going on with what's left of CompuCom, regardless of what we wind up calling ourselves, you can keep in touch by calling this BBS in San Diego: THE GENERAL BBS, at (619)281-2622. ───────────────────────────────────────────────────────────────────────────── DR. QUINCY SAYS: DEATH BY HAYES? ──────────────────────────────── For every answer regarding Compucom's demise, there are quite a few questions still unanswered. While those who've purchased eprom upgrades may still be able to get them from the continued tech supporters, it's not known what recourse is available for those who've not yet received modems purchased from Compucom prior to closing. At press time, Compucom had reportedly not filed for any form of protection under bankruptcy, and as stated above there may not be any satisfaction to be gained from the tech support staff with this respect. On the bigger picture, there's this nagging question: from a business standpoint, what factors actually contributed to the company's financial breakdown? Were they related to mismanagement, or was Compucom just another victim of the proprietary protocol curse? If the former, which might not be likely if the positive customer satisfaction reports prior to closing were true, then chalk it up as another example of the decline of American business. If the latter, which is far more likely, then perhaps it might be wise to keep an eye on Telebit, USR, and any other modem manufacturer that deals in non-Hayes proprietary protocols. While we all would love to see the price hold Hayes has on high-speed transfer protocols that work, the fact that Hayes essentially holds the patent on the "better" (read: first at bat and/or biggest kid on the block) mousetrap may be too strong to ignore. Until someone comes up with a communications protocol that offers severe benefits over those offered by Hayes, buyers should consider only buying those high-speed modems that support Hayes protocols in addition to their own proprietary ones. As it stands right now the risk of getting burned may be a bit too high for most of us to take the chance on something that's not 100% compatible with Hayes at all speeds. Which, of course, just might probably be where Hayes wants us all along. ───────────────┬─────────────────────────────────────────────┬─────────────── │ TechnOTES │ │ Compiled by the WWIVnews Staff │ └─────────────────────────────────────────────┘ ...brief shareware nOTE: one of shareware's few real success stories, Vern Buerg, has become the latest to be infected by the Greed Virus. The next release of his List utility, 1.84, will be the first commercial release of the product. The new Enhanced List will feature both ASCII and EBCDIC support, 7 and 8-bit file formats, a hex reader, and built-in utils for managing files compressed with several of the major archivers. ...While these new features may be handy, especially for WWIV sysops who use List to view their logs, the price tag is still a bit too pricey for something that used to be a hell of a lot cheaper. While one can't fault Buerg for trying to make his efforts more worth his financial while, one can't help but recall how Qmodem registrations dropped dramatically after John Friel sold it to Mustang Software for commercial release. A trimmed-down version for the shareware market that helped make Buerg a success would be very prudent, especially when very few sysops need EBCDIC support anyway! ...brief shareware nOTE #2: one of shareware's other few real success stories, Phil Katz' PKZIP, still hasn't seen an official release of the long-awaited version 2.0. Although there was a beta release of the new version, numbered v1.93, according to Katz himself this version was extremely buggy and has also been altered so that it appears to be an official release of a 2.xx version. PKZIP users are urged not to use any version of PKZIP identifying itself as a 2.xx release until further notice. The WWIVnews staff is looking further into this matter, and next month's WWIVnews will feature a more in-depth look into the current status of PKZIP 2.xx. ───────────────┬─────────────────────────────────────────────┬─────────────── │ Optimizing HS/Link for WWIV 4.21 │ │ by Lance Halle (1@6211) │ └─────────────────────────────────────────────┘ After talking at length with Sam Smith, the author of HS/Link, I think I have the proper setups to make HS/Link work reliably with PC Pursuit. I also found out a couple of other things that really speed HS/Link up for regular transfers. The first part of this document defines some terms that are used in the rest of this discussion. The second part discusses ways of setting up HS/Link to optimize normal WWIV BBS connections. The third part describes the problems involved using HS/Link on WWIV with PC Pursuit, and how they can be taken care of, and part 4 deals with optimizing HS/Link for use with your terminal program. DEFINITIONS ─────────── BLOCK HS/Link sends data in packets (blocks). Normally each block contains a unique sequence number and checksum info to aid in data verification and error detection and recovery. BLOCK SIZE (-s) Size of each block in bytes. CONFIGURATION FILE An ASCII file that is used to set HS/Link's options. This file can be created with HSCONFIG, or with your editor. The default configuration file is HSLINK.CFG. This is the file that HS/Link looks for if no other is specified on the command line. To specify another configuration file start your command line as follows: "HSLINK -@filename". Don't type the quotes. The filename is the name of the alternate configuration file you want HS/Link to use. This MUST be the FIRST option on the command line. CURRENT HS/LINK VERSION Be sure to use the LATEST release of HS/Link. While the current version is always compatible with older versions, you will not get the benefit of the latest enhancements and fixes if you are using an old version. At the time of this writing, the latest RELEASE version is 1.12. FORCE REMOTE TO USE LOCAL OPTIONS (-!) This option causes the remote (called) end to use some of the options specified by the calling end. This does NOT affect any of the options having to do with security, such as the upload path, or the overwrite option. It does affect block size (-s), xon/xoff (-hx), and windows (-w). HARDWARE HANDSHAKING - CTS/RTS (default) A means of flow control where the modem asserts the CTS (clear to send) line when it is able to receive data from the computer. If it's buffer fills up, it drops the CTS line. In the same way, the computer asserts the RTS (request to send) line when it is able to receive data from the modem, and drops it if it is busy. This scheme is used by High Speed modems that can operate with a port speed that is higher than the connect speed. SLOW HANDSHAKE (-hs) Sends Xoff or lowers RTS during disk I/O. This causes the computer to signal the modem not to send any data during disk I/O. It is available for systems with slow disk access. It may help if you get frequent CRC errors of COM overruns on clean lines. WINDOW (-w) The number of blocks HS/Link will send before stopping and waiting for an acknowledgment (ACK) XON/XOFF (default) A software method of telling the other end to suspend/restart sending data. It is not generally necessary for error correcting modems, but no harm is done by leaving it enabled. (Do not disable this if Slow Handshaking (-hs) is required by your system) OPTIMIZING HS/LINK FOR WWIV BBS'S THAT DO NOT MAKE NET CALLS VIA PCP ──────────────────────────────────────────────────────────────────── If you operate a WWIV BBS that does NOT make NET callouts via PCP, then the following HSLINK.CFG file settings and INIT settings should be optimum for you. HSLINK.CFG - use HSCONFIG or a word processor to create -A /* don't send ACKs */<< don't type the >> -S4096/* sets 4k blocks */ << comments >> -W0 /* do not wait for ACK /* INIT settings for HS/Link Description : HS/Link Xfer OK code : 0 Require MNP/LAPM : N Receive command line: HSLINK -P%2 -E%4 -U%3 Send command line: HSLINK -P%2 -E%4 %3 Receive batch command line: HSLINK -P%2 -E%4 -U%3 Send batch command line: HSLINK -P%2 -E%4 @%3 Bi-directional transfer command line: HSLINK -P%2 -E%4 -@ @%3 OPTIMIZING HS/LINK FOR WWIV BBS'S THAT MAKE NET CALLS VIA PC PURSUIT ──────────────────────────────────────────────────────────────────── OK, now for the problem with PCP. Being a timeshare net, it does not transmit data continuously, especially during busy times. There may be delays in data transmission. If the HS/Link default block size of 1024, or 4096 is used, and the default window of 8 is in effect, HS/link will send 8 of these blocks before stopping for an acknowledgment. If PCP is busy, this may be more data than it can "swallow" in one gulp. Once PCP gets behind, it may have problems recovering, in which case the data may or may not get through. Even if it does, the ACK may not get back to the sending end, in which case HS/Link waits for it's internal timeout, before trying again. Often PCP cannot recover at all, and HS/Link will finally about the transfer. This problem can be resolved by using smaller blocks, and smaller windows. A setting of 512 or smaller for the block size is recommended, and a window of 4 should work fine. This will give PCP smaller blocks of data, and HS/Link will stop more often to check that the data has been received. This sounds easy to implement, but there is one problem with WWIV that we have to overcome. We are able to set the command line that HS/Link uses for regular BBS callers by using the INIT program, BUT we have no way of controlling the command line that the NETWORK uses for it's callouts. This means we are stuck using the same configuration for both our NET calls and our regular callers. There is a workaround that will do the job for those systems that make NET callouts via PCP, but still want their regular callers to get the best speed out of HS/Link. We can set the options we want to use for NET callouts in the HSLINK.CFG file, since that is the one HS/Link looks for by default. Then we can create another configuration file to use when a regular caller activates HS/Link. We can specify that alternate configuration file on the HS/Link command lines in INIT. If you called your alternate config file BBS_CALL.CFG, and it was in your C:\WWIV directory, then your HS/Link setup in INIT should look like this: Description : HS/Link Xfer OK code : 0 Require MNP/LAPM : N Receive command line: HSLINK -@C:\WWIV\BBS_CALL.CFG -P%2 -E%4 -U%3 Send command line: HSLINK -@C:\WWIV\BBS_CALL.CFG -P%2 -E%4 %3 Receive batch command line: HSLINK -@C:\WWIV\BBS_CALL.CFG -P%2 -E%4 -U%3 Send batch command line: HSLINK -@C:\WWIV\BBS_CALL.CFG -P%2 -E%4 @%3 Bi-directional transfer command line: HSLINK -@C:\WWIV\BBS_CALL.CFG -P%2 -E%4 -@ @%3 Your default HS/Link config file that will be used for the NET callouts should look like the following. It should be named HSLINK.CFG, and should be in the same directory as HS/Link. This is the optimum setup for use with PCP: -! /* force remote to use these settings */ -S512 /* use 512 byte blocks */ -W4 /* wait for ACK after every 4 blocks */ Your alternate config file for use with regular callers should look like this, and the name should match what you specified in INIT on the HS/Link command line (ie. BBS_CALL.CFG), and should also be in the same directory as HS/Link. -A /* don't send ACKs */ -S4096/* sets 4k blocks */ -W0 /* do not wait for ACK /* These should provide optimum setup for those WWIV BBS systems that callout via PCP and want the best for their non PCP callers. Regular PCP callers should configure their terminal programs to use a setup like the HSLINK.CFG mentioned in part 4. HS/LINK AND YOUR TERMINAL PROGRAM ───────────────────────────────── The calling party has the responsibility of determining the best HS/Link configuration options for his/her particular situation (PCP, Non PCP, etc). You should configure HS/Link for your terminal program, and include at least the following options in the .CFG file. Be sure to include the (-!) to force the remote to also use your preferences. If you are calling via PCP, then your HS/Link config file should look like the following one. You should also use PCP's default handshaking: -! /* force remote to use these settings */ -S512 /* use 512 byte blocks */ -W4 /* wait for ACK after every 4 blocks */ If you use "direct" connections ( regular lines), then your HS/Link config file should look like this: -! /* force remote to use these settings */ -A /* don't send ACKs */ -S4096/* sets 4k blocks */ -W0 /* do not wait for ACK /* In the event that you do both PCP and Non PCP calls, you can give one of these files a different name (ie NON_PCP.CFG), and then on the HS/Link command line for your Non PCP calls, include the following as the FIRST option: -@NON_PCP.CFG Be sure to include the path name, ie @C:\TELEX\NON_PCP.CFG ───────────────────────────────────────────────────────────────────────────── I hope this takes some of the mystery out of HS/Link operation. Sam Smith (HS/Link author) has looked this over, and it has his blessings. If you have any problems, or discover something I have overlooked, or described incorrectly, PLEASE notify me as soon as possible. I will attempt to update this document as new information becomes available. ───────────────┬─────────────────────────────────────────────┬─────────────── │ Filo's Mod of the Month │ │ by Filo (1@5252) │ └─────────────────────────────────────────────┘ The Mod-of-The-Month Selection represents my choice of what appears to be a useful, practical mod to WWIV. It does not mean it is the best mod posted or even that it works as I may not have tested it. Given the limitations of this media, uuencoded mods are NOT eligible for selection as mod-of-the-month. This month's selection is a combination of two mods posted earlier. Each mod provided a means of permitting users that experience logon trouble to send feedback to the Sysop. Since this problem occurs frequently, it seems to be a useful mod. Braves's (1@8131) combination of the two other mods seems to be a colorful approach. ───────────────────────────────────────────────────────────────────────────── This mod was made for WWIV 4.21. I always wanted a mod that would allow users to be able to do something if they forgot their password or just hit the wrong macro or Whatever. I saw this mod and another one on the Mod net and tried them. I liked them but wanted what each of them had into one so I combined them and added some stuff. I hope you like it. Well on with the Mod! Difficulty - .0001 out of 10 Backup your source! (Unless you feel real Lucky!) /* == */ existing code! /* ++ */ add! /* += */ change! Ok Load up LILO.C } while ((!hangup) && (!ok) && (++count<3)); /* == */ if (count==3) { /* += */ pl("6User not found..."); /* ++ */ outchr(12); /* ++ */ pl(" 3╔══════════════════════════╗"); /* ++ */ pl("1Would you like to: 3║ 2R)7etry logon 3║"); /* ++ */ pl(" 3║ 2L)7ogon as a newuser 3║"); /* ++ */ pl(" 3║ 2G)7oodbye (hang up) 3║"); /* ++ */ pl(" 3║ 2E)7mail Braves (hang up) 3║"); /* ++ */ pl(" 3╚══════════════════════════╝"); /* ++ */ outstr(" 1Your choice: "); /* ++ */ ch=onek("LRGE"); /* ++ */ switch(ch) { /* ++ */ case 'R': /* ++ */ nl(); /* ++ */ getuser(); /* ++ */ break; /* ++ */ case 'L': /* ++ */ nl(); /* ++ */ newuser(); /* ++ */ ok=1; /* ++ */ break; /* ++ */ case 'G': /* ++ */ hangup=1; /* ++ */ ok=0; /* ++ */ break; /* ++ */ case 'E': /* ++ */ email(1,0,0,0); /* ++ */ hangup=1; /* ++ */ break; /* ++ */ } /* ++ */ } /* ++ */ checkit=0; /* == */ okmacro=1; /* == */ That's It! Save it and Compile! ───────────────┬─────────────────────────────────────────────┬─────────────── │ Dateline: @#$*()#! │ │ Editor's Notes by Omega Man (1@5282) │ └─────────────────────────────────────────────┘ 32767 bytes per file. It's not just a good idea, it's the law. Wellll...maybe not quite *that* good an idea... This month, that "law", along with the last-minute addition of an in-depth look at the demise of Compucom, took it's toll on the space I had allocated for my editorial. Since I've rescheduled that editorial for next month's issue, I'll take what little space I've got to enlighten everyone on yet another major change to WWIVnews that's about to take place in the next couple of months. Laws that are detrimental to that which they are designed to protect can be changed if those affected pursue the proper channels of authority. Or, at least that's what they told us in our civics classes, right? Well, in the case of WWIVnet and WWIVnews, this meant 1@1 himself, Wayne Bell. After consulting with - ok, ok, *begging* - Wayne at length on the matter, with the release of Net31 the file size limit will essentially be removed for WWIVnews. What Wayne has devised is a way for WWIVnews to be transmitted over the network in 32k segments, and reassembled by Net31 into one complete file. What this means is that WWIVnews will see yet more expansion following the release of Net31. Some of the original plans for the revamping included some regular features that were dropped ue to the file size limit. These features included such standard publication staples as a Q&A column, a regular Group events update section, a networked sub review column, and a regular update piece for onliners and utils. So, once Net31 has had time to be distributed and installed - at least one month, maybe two - expect to see these features to finally see the light of day. Of course, if you're interested in writing one of these features, feel free to drop me a line at 1@5282. Lord knows we're going to have space to fill for a change :-) Speaking of that file limit, It seems I've got just enough space left for the closing credits. Stay tuned, people - the WWIVnews Adventure is about to really get a really swift kick in the butt! ┌───────────────────────────────────────────────────────────────────────────┐ │ Closing Credits │ ├───────────────────────────────────────────────────────────────────────────┤ │ WWIVnews is an independent newsletter published monthly as a service to │ │ the WWIV community of sysops and users. The opinions and reviews expressed│ │ herein are the expressed views of the respective writers, and do not │ │ necessarily reflect those of the WWIVnews staff. Reproduction in whole or │ │ in part is allowed provided proper credit is given. All rights reserved. │ ├───────────────────────────────────────────────────────────────────────────┤ │ The distribution sites for WWIVnews are the Klingon Empire BBS (512-459- │ │ 1088), WWIVnet node @5282, and the WWIVnews Editorial Desk networked │ │ subboard, subtype 15282 host 5282. Information regarding article and │ │ editorial submissions, back issue requests, and the WWIVnews Writer's │ │ Guide, can be requested in e-mail from the WWIVnews editor, 1@5282. │ ├───────────────────────────────────────────────────────────────────────────┤ │ WWIV and WWIVnet, copyright 1986,1990 by Wayne Bell │ └───────────────────────────────────────────────────────────────────────────┘