Volume 4, Number 43 23 November 1987 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief: Thom Henderson Chief Procrastinator Emeritus: Tom Jennings Contributing Editors: Dale Lovell, Al Arango FidoNews is published weekly by the International FidoNet Association as its official newsletter. You are encouraged to submit articles for publication in FidoNews. Article submission standards are contained in the file ARTSPEC.DOC, available from node 1:1/1. Copyright 1987 by the International FidoNet Association. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact IFNA at (314) 576-4067. The contents of the articles contained here are not our responsibility, nor do we necessarily agree with them. Everything here is subject to debate. We publish EVERYTHING received. Table of Contents 1. ARTICLES ................................................. 1 Fido v12 Support Echo Conference ......................... 1 An Informal History of FidoNet ........................... 2 FidoNet en Sudamerica .................................... 6 Preferred and Alternate Inbound: A Routing Proposal ...... 8 2. COLUMNS .................................................. 13 The Regular Irregular Column ............................. 13 3. NOTICES .................................................. 17 The Interrupt Stack ...................................... 17 Jewish and Hardware Echos Planned ........................ 17 Latest Software Versions ................................. 17 FidoNews 4-43 Page 1 23 Nov 1987 ================================================================= ARTICLES ================================================================= John Hamilton 1/117 FIDO Help! Fido v12 Support Echo Conference Just a reminder to all SysOps running Fido v12 that there is an echomail conference dedicated to supporting you, named FIDO. It is carried on the backbone nationally, and has Tom Jennings' active participation. If you have enhancements you would like to see incorporated in future releases, just netmail them to me at 1/117 and I will include them in a list which will be forwarded to Tom from time to time for his comments. The list and comments will be posted in the echomail conference every few months. If you need advice or assistance with v12, and it isn't life threatening or otherwise critical, you can call 1/117 or netmail to it a copy of the question. If we can't answer it, we will ask Tom to and get back to you. This way, we can hopefully give TJ more time to relax (ha!). I would like to make an open request to all utility authors to consider v12 when they are enhancing current programs or designing new ones. FIDO Help! is more than willing to gather any information required to do this, and to help in any other way feasible. If you have a utility which works with v12 and would like to let everyone know, put a notice in the echo or netmail 1/117 and we will put it in for you. FIDO Help! will attempt to keep an up-to-date list of what works and what it does for anyone that is interested. More information on this will be posted in the echo conference in the near future. Finally, thanks to everyone who has helped to get the conference off the ground, and especially to Tom Jennings for being actively supportive from the start! ----------------------------------------------------------------- FidoNews 4-43 Page 2 23 Nov 1987 Ben Baker, 100/76 An Informal History of FidoNet TJ once told me he began work on Fido around Christmas, 1983. He wasn't sure exactly when. In early 1984, I was preparing to put a CBBS on line for the CP/M SIG of our computer club at Macdonnel Douglass when I was approached by the club president to make it a club-wide BBS. The club had a commitment from DEC for an indefinite loan of a Rainbow. The theory was that the Rainbow had a Z-80 and could run CP/M, so it should be able to run CBBS. When I finally got the manuals for the Rainbow I discovered that the Rainbow's Z-80 did not have access to the I/O ports, so it could NOT run CBBS! I immediately began a frantic search for BBS software which would run on the Rainbow, which led me to John Madill's board in Baltimore. There I engaged in a message exchange with Tom Jennings, who was frantically searching for someone to write a comm driver for FIDO_DEC. No, I didn't do the comm driver (don't remember who did), but I did get a copy of the first Rainbow version (which was, I think, originally intended for John Madill's home machine -- don't know if he ever put it up). By mid March I had it running on the club's Rainbow 100. I don't know when TJ began numbering Fido installations, but at that time there were at least 6, but no more than 8. He would not assign me a number until he could "list" me in his informal Fido list, and I did not get a phone line assigned to the system until sometime in April. When I could finally give him a publishable phone number, I was listed as "Fido 10," the second St. Louis Fido (Tony Clark was Fido 4). I began with a late Version 3, but by the time I was listed, I think I was running Version 5. In May, Fido began to blossom, and by Memorial Day there were around 15 Fidos on line. St. Louis had 5 of them -- 4, 10, 16, 17 and 22. (TJ had begun assigning Fido numbers when he mailed out diskettes, many of which never did come on line). Curiously, all but Tony Clark were running Fido on Rainbows! Sometime in late May or early June I was talking on the phone with TJ and the subject of networking the BBSs together came up. "Wouldn't it be neat if one Fido could automatically call another and send it messages and files -- automatic software updates!" That night TJ logged into Fido 10 and uploaded FIDO_DEC V6, a brand new program called FIDONET, and a new system file called "NODELIST.BBS." With that, FidoNet was born. Version 6 implemented a very primative amorphous network with just one hard-wired schedule. Traffic level grew rapidly as everyone experimented with this new toy, and it soon became apparent that most of the time we were butting heads, and many FidoNews 4-43 Page 3 23 Nov 1987 messages never went through. We needed more elaborate scheduling and some means of defining message routing. But how do you develop and do controlled testing on something like that without spending a fortune on phone bills? St. Louis which by this time had added a 6th Fido (51), could model a real network with local phone calls! No other city could boast more than 2 Fidos. That is how I became involved in difining Fido's routing language with TJ. TJ wrote, we tested, we fed back results and needs, TJ wrote, sometimes two releases in a day! By August we had version 7, with its routing language, ready for distribution, and FidoNet began to change shape toward what we see today. TJ was maintaining the nodelist. When he received a change request, he would write it down on a small slip of paper and stick it to the wall. Frequently the slip would fall from the wall and disappear behind his computer, never to be seen again. By September the nodelist was a shambles! I'm not sure if we volunteered or WERE volunteered, but Ken and I agreed to take over nodelist maintenance, and on September 21, 1984, we (well, mostly Ken) published the first "St. Louis Nodelist." It took us a couple of weeks to weed out all the bad numbers and drop-outs, but by the middle of October we had a pretty solid nodelist. TJ had been bit once or twice with fake node number requests. (I'm sure many of you have heard a version of the famous "little old lady." It actually happened. He accepted a phone request for a node number. After several complaints from the net about no-answer, he called the number during the day and got an earfull!) So we established our first FidoNet policy: ya gotta request a node number via net mail. Of course, TJ was still passing out node numbers with diskettes, and we still had a few bad ones. It took another month to persuade him to stop, and to publish "our policy" in the docs. It was October or November that TJ published the first issue of our irregular weekly newsletter, FidoNews. I don't think he had ever intended to continue with the newsletter very long, and in January he passed that baton to Thom. I remember at the time I had never heard of Thom Henderson! Who the hell is he? Ken didn't know either. Hey Ken did you ever figure out who this Thom Henderson is? What kinda name it "Thom" anyway? I think we were in Fido Version 8 when, in the Spring of 1985, we were rapidly approaching Fido's 250 node limit. A nodelist that size was becoming difficult for one man to manage and still find time to kiss his wife occasionally! Our computer club and the local DECUS chapter brought TJ to St. Louis to speak at a joint meeting on April 10th and the next day we had an all-day meeting at Ken's house. After an 11 hour session we codified what was already taking place. With the advent of a routing language, FidoNet was collecting itself into local groups or "nets," usually around a node willing to foot the bill for long-distance calls. So we created the net/node addressing scheme. Node numbers within a net would no longer have to be unique on FidoNet, only within the FidoNews 4-43 Page 4 23 Nov 1987 local net. Thus the "network host" could maintain his own net list. But that still left about 100 or so nodes scattered throughout the hinterlands and not alligned with anybody. The net implied routing. How about a different kind of "net" that did NOT imply routing -- a Region. TJ reached into his knapsack (hey, that's the way he travels, knapsack and skateboard) and pulled out two or three hugh U.S. maps. We spread one out on the floor and with a felt pen, began carving. We divided up the country into ten pieces we hoped represented more-or-less equal populations (at 10pm on a Thursday night we were not in a scientific mood) and dreamed up names for the ten new "regions." TJ went home and got back in the "a version a day" mode. Ken and I put a freeze on the nodelist and began creating net and region files and assigning new net addresses. By early May the software was beginning to stablize and we "went public." As I recall, we set June 15 as the cut-over date to the new addressing scheme (with a silent prayer that we could get everything in place by then). We found ten people willing to be regional coordinators. We unfroze the nodelist and gave hosts a formula for assigning node numbers (until the cut-over, they still had to be unique). Finally the the fateful day came for us to all use the "3" command and set our new net addresses. I was expecting total chaos. I was not at all prepared for just how smooth the transition happened! Oh sure, there were a few stragglers and even a few drop-outs, but still, one day we were an amorphous network and the next FidoNet was partitioned into local nets and regions -- and the mail kept flowing as if nothing had happened! It took a good deal of coordinated effort by a great many people, and it proved we COULD function as a body! It was about that time that TJ first suggested a membership association. After all, we had proved we were an organization, so why weren't we an officially sanctioned organization. I was originally cool to the idea. Providing tee shirts and bumper stickers was not the kind of service foundation I thought appropriate, so I dragged my heels. With the Tsimpidis affair still fresh in my mind I saw a need for a strong collective voice, but I didn't have any idea how to get there. I'm sure there were events of moment, but I don't recall much more as 1985 slid quietly into 1986. A 500 node limit came and went, almost without notice. TJ said "This new version (11) can handle 1200 nodes. That ought to hold us for quite a while." We coined the name "International FidoNet Association" and used it a first line in the mailing address. FidoNet began appearing more frequently in national publications Like it or not, we were a growing force and we were being noticed. Ken began receiving donations in the name of IFNA, and they helped defray the costs of our new-found recognition. Two things happened in 1986 to crystalize the IFNA concept and one to definitely polarize it. First, an April conversation between Ken and his accountant went FidoNews 4-43 Page 5 23 Nov 1987 something like this: "You've got to pay income tax on these 'donations.'" "But that's not my money!" "I know, but what IS IFNA? Can you prove to the IRS that it exists?" "Well. . . er. . . uh. . ." Total receipts for 1985 were only a few hundred dollars, but still, that's a non-trivial tax burden and 1986 revenues had already exceeded 1985's. Then in May we were asked by COSUG, "How would you like to help us put on a Sysops' Conference?" Sounded like a good idea to us and we immediately went to work on it. Then in July they said "Looks like we might have a small surplus. We will gladly share it with IFNA, but we can only do that if IFNA is a bona fide not- for-profit corporation. So, with some trepidation, Ken filed IFNA's incorporation papers in late July or early August. On reflection, we should have said "Keep the money -- let's see what happens at the conference first." Marvelous thing, hindsight. Then came the conference in August. From that momment to this our history becomes a blur to me. I recall that a self-appointed IFNA spokesman put us in deeper, hotter water every time he opened his mouth. I recall that, with no authorization save the aforementioned spokesman's, IFNA memberships went on sale. I recall a disasterous "business meeting." I recall Ezra putting out the fire under the tar pot. I recall a by-laws committee, a New Hampshire meeting, a Chicago meeting, flames, counterflames. I recall twice throwing in the towel and twice being persuaded to reconsider my action. But can I put order to all of that? 'Fraid not -- it's all a blur. Another historian will have to pick up from the conference; one with clearer recollections (or perhaps records). Has it all been worth it? For me, the first two years were an unqualified success. As to the last year, only time will tell. I think we now have the skeleton of a potentially successful, and useful, organization. Now, lets get some meat on the bones. Ben I have told this abreviated history from my own perspective. I have left out many people and events really important to the development of FidoNet. The list is long and I will not attempt to enumerate them for fear of omitions. You know who you are. Most of you know who "they" are. I would simply say to all of you -- THANK YOU. ----------------------------------------------------------------- FidoNews 4-43 Page 6 23 Nov 1987 Pablo Kleinman Node 368/1 FidoNet en Sudamerica ===================== Today there are five registered Fidonodes in South America: one in Suriname and four in Argentina. The growth of the net in this southlands is somewhat limited by the "deficit of phone lines" (very high in the most developed countries of the region). Since right now, these countries are having a "democratic comeback" (specially Argentina, Brazil and Uruguay), there is no control at all over the phone lines and the establishment of new BBS is not limited by any political reason (like there can be in a country with a dictatorship like Chile or Paraguay, where the gov't wants to control all the communications and may find BBS and Email as something dangerous). You must not expect an easy grow of nodes like in North America, it is much more difficult to install BBSes here, and that is determined by some facts like the deficit of phone lines and the lack of technical support. To change that, I (with a group of hobbyists) started a campaign to promote BBSes and Fido all over the region. But some things must be done soon: - Translation of all the software needed to setup a node. - Getting support from the gov'ts and organizations. (we are now working on that) The first Fido in Argentina was installed in June. To contact IFNA it took me 3 months of researching at various sources including CompuServe and Delphi. I finally found Harvey Nehgila (thanks, Harv!) at CompuServe who gave me Ken Kaplan's number (I had Fido v10j and its manual was pretty obsolete, I tried to call 1-415-864-1418 which said was Tom Jenning's node's for a week at NMH without success, until I dialed manually and found out that the number was disconnected! I asked San Francisco's operator for the new number but there wasn't a new number...). In June, I started to organize a National FidoNet and I convinced four sysops in Buenos Aires to switch to Fido (that was in September). We formed TangoNET for Buenos Aires city. Now, there are a couple of nodes working in the second and the third largest cities in the country, but as they don't have direct dialing to the USA, and we don't have yet an independent region or zone, they aren't able to join FidoNet. That's why I'm asking IFNA to form a separate Region in Zone 1 or to form Zone 4, even if there are only 6 or 7 nodes. FidoNews 4-43 Page 7 23 Nov 1987 We need help from experienced FidoNet sysops. Also from the creators of at least one of the available FidoNet- compatible BBS systems in order to get the source code and manuals to make a version in Spanish. If you can help, or want to know something else, please send mail to FidoCenter (Node 368/1). Our mailing address is: FidoNet Sudamericana Suipacha 1322 Suite A 1011 Buenos Aires, CF Republica Argentina Thank you very much, -Pablo Kleinman Note: If you are interested in participating in the effort of building the Network in South America please contact either myself (368/1), Travis Good (102/851), or Juan Davila (367/3). We also have an echo called LATINO which we'd be happy to have you join. ----------------------------------------------------------------- FidoNews 4-43 Page 8 23 Nov 1987 Jack Decker 120/73 (Private node via 120/64) PREFERRED INBOUND AND ALTERNATE INBOUND: A ROUTING PROPOSAL (This article is NOT COPYRIGHTED and may be reproduced by anyone, in any form, with no strings attached.) The present scheme of regions, hosts, hubs, and nodes within Fidonet was developed in an era when, by and large, all telephone costs were distance-sensitive (and where the costs always increased when your call terminated at a more distant point). Even at that time those assumptions were not always true (due to the use of leased lines and the generally higher cost for in- state calls as opposed to out-of-state calls) but now that we have PC Pursuit and AT&T's Reach Out America plan, distance is often of no consideration in making modem calls. Still, nets are often arranged geographically, with all BBS's in a given region grouped together on a geographic basis. This works well enough when an entire net is located in a major metropolitan area, but it often does not meet the needs of Sysops in more remote areas. The major reason that it doesn't work well is that the backwater Sysop's HOST is probably accessible only via the long distance phone system, and the HOST itself may be in only a medium-sized city. Consider, for a moment, the disadvantages that our rural Sysop will face: 1) He will probably be expected to POLL his host for mail on a regular basis, even though the volume of received mail may be very low. 2) He probably does not yet have access to an alternate long distance carrier, let alone a packet network or PC Pursuit, so his calls to the host will be at AT&T long distance rates. If the host is located in the same state and is some distance away, those rates may be VERY high, even at night! 3) If the host is not in a PC-Pursuitable city, other Sysops will charge their users to send mail through to the remote board (if they allow it at all). This, in turn, will lower the volume of received mail, making the prospect of having to poll the host regularly even less attractive. What we are talking here is COST. The Sysop who is out of the mainstream of traffic may have expenses that are many times those of a sysop living in a larger city. But inefficient routing can also affect Sysops in more populated areas. For example, if your inbound host is a long distance call (and is not PC Pursuitable), it's still going to cost you to connect with him even though you may be able to access other hosts (of other nets) for free or for less money. I'm sure that others have suggested that the whole Fidonet system FidoNews 4-43 Page 9 23 Nov 1987 be reconfigured to take maximum advantage of PC Pursuit or Reach Out America or some other quirk in local calling rates. There are a couple of major problems with that, however. The first is that if the service that the net is configured around goes down or has a dramatic rate increase, you're right back to inefficient routing (for example, if the proposed FCC regulations go through and PC Pursuit is discontinued, I can guarantee you that there will be some major changes in the way that Echomail is being routed!). The second is that the geographic unity of a net is not something that should be easily cast aside. It is nice (and usually very beneficial) to be in frequent communication with other Sysops in your own area! Therefore, I have a proposal that would retain the present net/hub/node structure but would allow calls to be rerouted based on least-cost principles, where the sysop of the receiving board is willing to put a little effort into making it happen. My proposal involves new comments in the miscellaneous field of the nodelist: AI:net/node - An alternate inbound routing that MAY be used if it is less cost to the calling board. PI:net/node - A PREFERRED alternate inbound routing that SHOULD be used by the calling board if it is the same cost or less cost than host routing or direct routing. This might be used when it is a toll call from the receiving board to the net host, but a "free" (PC Pursuit, possibly?) call to the preferred alternate. In either case, more than one net/node may be specified. Let me give a hypothetical example of how such routing might save some money. Since a picture is supposed to be worth 1,000 words and I'm tired of typing, please refer to the following diagram of nodes in imaginary net 999: 999/999 999/123 888/888 777/777 BACKWATER <-----> SMALLTOWN ----> HUBTOWN -----> METRO x x | | (TELENET (PC PURSUIT x x ACCESS) INBOUND CITY) HOST 999/0 (TOLL CALL) Let's assume that BACKWATER is at the edge of nowhere, but is within the local telephone calling area of SMALLTOWN, which is, presumably, in the middle of nowhere! In our hypothetical example, the Net 999 Host is a toll call for both boards but the Sysop of the Smalltown board happens to be a business owner with a direct line (foreign exchange or WATS, perhaps) to HUBTOWN, which as it happens is the location of a HUB for net 888 (unfortunately, that's NOT part of the same net!). Our Smalltown BBS operator POLLs the Hubtown node daily to pick up echoes and whatever mail might be incidentally routed that way. Meanwhile, the Hubtown node operator, which has access to a Telenet local line, places a daily call via PC Pursuit to POLL node 777/777 in METRO for mail. FidoNews 4-43 Page 10 23 Nov 1987 Under the present setup, both the Backwater and Smalltown Sysops would have to POLL their host to receive incoming matrix mail. Of course, they could realign themselves to be under Net 888, ASSUMING that the host of node 888 has no objections and the regional coordinator(s) involved are willing to allow the transfer - but what if, two months later, the Sysop of the Smalltown node decides to pull the plug on his system? Then the Backwater Sysop is left high and dry, with no connection to Net 999 and the possibility of a not-too-satisfying relationship with Net 888. Let's suppose, however, that our Backwater Sysop would take the initiative to contact all of the nodes involved and set up the following arrangement: METRO 777/777 receives mail for Backwater - this in effect makes the Backwater board PC Pursuitable for mail purposes - and HOLDs it for pickup by HUBTOWN 888/888. HUBTOWN 888/888 in turn HOLDs it for pickup by SMALLTOWN 999/123. When 999/123 receives the mail packet, he immediately CRASHes it to 999/999 because it's a local call. This much of it is all workable under the present system. The only problem is that any Sysop that simply runs Xlatlist, without knowing about this arrangement, will automatically route mail for 999/999 to the Host (999/0) which, as noted earlier, happens to be a toll call for the Net 999 boards in question. Now, if our Backwater Sysop could some convince everyone to ARC his mail TO 888/888 or 777/777, he'd be in fine shape. He wouldn't have to Poll the host to get his mail. So how does he do this? Under my proposal, he would place this comment in the nodelist: PI:888/888 777/777 This would tell other Sysops that, if it is a toll call to his board, he would prefer that mail be routed to 888/888 or 777/777 rather than to the Net 999 Host. On the sending end, the program that handles the mail (that would have to be written to implement this scheme) would use this logic to route the outgoing call: 1) Is 999/999 a local/zero cost call? If so, direct route it. 2) Is 888/888 a local/zero cost call? If so, route it via 888/888. 3) Is 777/777 a local/zero cost call? If so, route it via 777/777. 4) Is the HOST (999/0) a local/zero cost call? If so, host route it (the HOST may still receive some inbound mail for this node, but he may be able to Arc it To a node in the Backwater system's "free" path, if the call is also "free" for him.) 5) If all of the above are toll calls, then check the cost FidoNews 4-43 Page 11 23 Nov 1987 fields to determine which of routing direct to 999/999, indirect via 888/888, indirect via 777/777, or indirect via the host (999/0) is the least expensive and use that method. 6) Where the costs are the same, the first choice would be direct routing. Since this was set up as a Preferred Inbound, the second and third choices would be to route via 888/888 or 777/777. Host routing would only be used if it was clearly the lowest cost choice for the sender. Now let's change the scenario a bit. Suppose that the above diagram is the same except that the HOST happens to be a local call. In this case, the Backwater Sysop isn't out anything when he polls the host, so he doesn't care if other boards send mail directly to his board, or route it via his Host. The only problem with this scenario is that the Host isn't in a PC Pursuitable city, which means that users in distant areas have to pay their Sysops to send mail to Backwater. Now, instead of PI: (Preferred Inbound), the Backwater Sysop would use AI: (Alternate Inbound). This simply reverses the priorities so that Host routing would be preferred over the use of 888/888 or 777/777 for inbound mail, BUT if it is a zero cost (or lower cost) call for the originating BBS, it MAY route via one of the other two boards. Of course, the above describes one particular situation (any similarity to a real-life situation is purely coincedental) but the ability to use the PI and AI comments (one or both) in the comment field might permit mail to flow at a lot lower cost. More importantly, I think, is that existing Net bonds are not destroyed and if something changes, changing the preferred or alternate routing is as easy as making a change in the nodelist. Now, how would a PI: or AI: be used at the sending end? Well, the lo-tech method would be for a Sysop to manually eyeball the nodelist and look for the PI's and AI's. Let's suppose he found the Backwater BBS and, because he was a PC Pursuit user, could call 777/777 for free. He would then insert a statement such as ArcTo 777/777 999/999 in his route control file. Most Sysops wouldn't enjoy doing this very much (although they might make the necessary adjustments for frequently-called nodes), so I'm sure that someone would write a utility that would scan the nodelist (after xlatlist processing) and generate appropriate statements for the route control file. Such a utility, when it encountered a PI: or AI: statement, would check the cost fields of the boards referenced by the PI: or AI: and generate any necessary statements based on the logic outlined above. If the board with the PI: or AI: statements happened to be a Host or a Hub, then the routing for all boards below that host or hub would also be checked and changed if the alternate routing could be accomplished at lower cost. Ultimately, a new version of xlatlist might handle all of this automatically, or a newer version of the BBS or mail-handler program (whichever brand you're using) might read the comments and make the necessary adjustments in calling patterns. FidoNews 4-43 Page 12 23 Nov 1987 As with anything, this kind of alternate routing capability could be misused (I can envision "super" mailboards in the large PC Pursuit cities becoming nearly impossible to reach due to overloads), so it would have to be used with some restraint to spread the message traffic evenly. But I also think that many Sysops would welcome this method of reducing costs for outgoing mail, while at the same time encouraging a freer flow of mail to the boards in the outlying areas. Comments on this proposal may be left to me via the BIXNET BBS (120/64, 616-361-7500 300/1200/2400bps), although I really can't do much more to develop it. The idea is simple, could be implemented NOW in a limited manner, and when appropriate software is written could be more fully implemented. For the present, a Sysop could just ignore the PI: and AI: comments and continue to Host route mail, or could manually make changes to his route control file for as many boards as he cares to make the effort. I hope that this idea will receive some consideration among those in the Fidonet community. Jack Decker ----------------------------------------------------------------- FidoNews 4-43 Page 13 23 Nov 1987 ================================================================= COLUMNS ================================================================= -- The Regular Irregular Column -- Dale Lovell 157/504 So far, so good. It looks like I should be back to my weekly schedule for the next few weeks. Not only should I have the time to write, but I should also have a profusion of new software, updates to old software, and discoveries. I'm beginning to discover that Robert Heinlein's comments on writing are correct; once you start writing, you can never quit. In the meantime, let's get this monkey off my back this week. -- Brief (Solution Systems, $195.00) -- I've been hearing about Brief for over a year from various sources (friends, programmers, echomail) and decided it was time to take a look at it myself. Needless to say, everyone else was right. It is a phenomenal program and I can already see the day coming when I won't know how I got along without it. While it is a text editor (versus a word processor), it contains many capabilities not found in high-end word processors. It has the ease of use of Norton's Editor, the windowing capabilities of Microsoft Word (more on the new version of Word in a few weeks), and the macro capabilities of WordPerfect. Combined these features would make many a secretary drool, yet it is clearly designed for the programmer. This isn't to say it couldn't be used as a word processor, just that it isn't designed for it (no spell checker, thesaurus, etc.). One of the first things that will clue you off to the fact that it's a programmer's text editor is the capability to compile the file(s) you're working on from within Brief. During the installation you instruct Brief on what file extensions are special (C for C programs, ASM for assembly language, etc.) and what compiler you're using, it knows about many of the compilers on the market today so it isn't too hard. Once you're done editing a file all you have to do is press F10 and your compiler's Brief macro and it will automatically compile the file (a buffer in Brief terminology) you've been working on. Some compilers can coexist with Brief, for others Brief unloads itself and compiles. I've been tempted to try and tie Brief in with Microsoft's make utility, but am holding off until I'm more comfortable with it. An added advantage of this is Brief will automatically locate any errors. You can look at a list of errors in the current file and jump to the next or previous error. While this may not be as ideal to many used to the immediacy of the Quick/Turbo series of programs, it can be a big step forward to those of us used to printing several pages of errors and trying to remember if we've added 4 or 7 additional lines when we go hunting for the next error. FidoNews 4-43 Page 14 23 Nov 1987 Brief also excels in it's search and replace capabilities. Where most text editors and word processors only let you decide if it should be case sensitive and possibly allow wildcards, Brief overflows with possibilities. When you do a search (or search and replace) you can enter an expression. The expression could be straight text, or you could enter one of the special functions within Brief. For example, if you wanted to find all the occurrences of "STR(10" and "STR(20", you would enter "STR(1|20" and Brief would only look for those two expressions. Some of the expressions available allow you to define groups and character sets. If you were editing a BASIC program and wanted to find all LOCATE commands that were using a variable you might enter "LOCATE [~,0-9]" and it would go look for them. That last example tells Brief to look for "LOCATE " followed by anything except a comma or a digit. This is only a small example of the power of these expressions. Some of the descriptions include a means of defining a range (inclusive or exclusive) or character set, a group (want to look for all occurrences of "him" or "her"). In addition you can decide where you want the cursor positioned after a search, at the beginning or end of the characters. These capabilities are not only limited to searching for text, but can be used when doing a search and replace as well. Brief also has the ability to edit an unlimited number of files at the same time. Each file is loaded into it's own buffer and there are several commands that allow you to switch between the buffers or load a new buffer. This can be nice if you're working on a program that is contained in several different source files and have organized your hard drive properly. Entering "b *.c" at the DOS prompt will bring up Brief and load every file with the "c" extension into its own buffer. When you're ready to compile just switch to the "main" program and start the compile. All from within Brief of course! This probably wouldn't have too impressive except that Brief also has windowing capabilities like Microsoft Word. You can create as many windows as your screen will allow (Brief knows about 43 line EGA displays). Each window could show a different (or identical) part of the same buffer or entirely different buffers, mix and match as you please. I've gone so far as to have 8 different batch files on the screen at once in 10 different windows. Granted they were all small batch files, but it was impressive to see. A much more practical use would allow a programmer to examine and edit a call to a subroutine, the subroutine itself, and his working notes all at the same time. If you write software and haven't wished for this capability at least once, I'd say you've been blessed (a condition which I decided I wasn't long ago). While Brief is a "high-end" text editor, I believe it is definitely worth the money. If it wasn't for the fact that I depend on an electronic thesaurus and spell checker, I would be tempted to give up my word processor and only use Brief. Solution Systems bills it as "The Programmer's Editor" and is very close to the truth. While it is definitely aimed at the programming community, I can't help wondering if there might not be a WP- Brief around the corner. The WP standing for word processing. FidoNews 4-43 Page 15 23 Nov 1987 From what I've learned about Brief in the past week, it surpasses the capabilities of most word processors in some ways and I'm not even close to mastering the product. The macro language appears to be one of the most powerful I've ever seen, and you can edit your Brief macros from within Brief. I'd recommend it to anyone who is currently developing software for a living or writes a large amount of code. I have never before seen a text editor as powerful as Brief. Having seen just a glimpse of its power, I honestly can't imagine choosing to use a different text editor. Brief macros are among the most powerful I've ever seen. I'm currently using WordPerfect to write these columns and I go through some unusual routines to make an ASCII file that FidoNews can accept. I completely write and edit the text in WordPerfect. When I'm satisfied with the column, I use WordPerfect's DOS text printer to create a file called DOS.TXT. After renaming the file to LOVELLnn.COL (with nn being the column number), I use a text editor to take out all the additional spacing (headers and footers primarily) and the FF (control-L) characters. With this completed I have a file I can send off that Thom's newsletter generation program will accept. In the past I've been doing this last step manually. In case you have the same software (WordPerfect and Brief), I'll mention that I use WordPerfect's default page format and only change the line format to a left margin of 0 and a right margin of 64. Sometime soon I'll include the macro I've written that will automatically do this last step for me. This is a good example of how software can make your life easier. Instead of taking a few minutes, I'm only going to take a few seconds. -- Winding Down... -- Some of you reading this may remember the first "x-rated" computer game, Softporn from Sierra On-Line for the Apple II computers. Well, Sierra has done it again with "Leisure Suit Larry in the Land of the Lounge Lizards" (Sierra On-Line, $39.95). Many of the situations seem almost identical to Sierra's earlier product. If you played it, you'll have a head start on everybody else playing this game. The new twist is graphics, like those in Sierra's King's Quest series. While the game greatly resembles its predecessor, there's more than enough new twists and turns to amuse everyone. I've greatly enjoyed playing Lounge Lizards and would recommend it to any adult game players. Every time you start the game you have to go through a short quiz. After asking you your age, your have to answer a series of questions. The questions are based on your age, and should be fairly easy if your claimed age is correct. If you miss 2 questions or are under 18, the game exits. While this may not be the greatest means of preventing "youths" from playing Lounge Lizards, it should be adequate for most. I heartily recommend Lounge Lizards, it is both humorous and enjoyable (as well as being unusual). As always, I would like to hear any comments you may have on my columns. If it's a correction or something I missed, I'd like a chance to set things right. I try to respond to all the mail I FidoNews 4-43 Page 16 23 Nov 1987 receive, although sometimes it sits around awhile before I get to it. Below you'll find my US mail, FidoNet and Usenet addresses. If you're sending me a message through FidoNet, please mention to your sysop that mail to me must be routed through 157/1 since I'm a private node. Dale Lovell 3266 Vezber Drive Seven Hills, OH 44131 FidoNet 1:157/504.1 uucp: decvax\ >!cwruecmp!hal\ cbosgd/ \ >!ncoast!lovell ames\ / talcott \ / >!necntc/ harvard / sri-nic/ ----------------------------------------------------------------- FidoNews 4-43 Page 17 23 Nov 1987 ================================================================= NOTICES ================================================================= The Interrupt Stack 7 Dec 1987 Start of the Digital Equipment Users Society meeting in Anaheim, CA. Contact Mark Buda at 1:132/777 for details. 9 Jan 1988 The next net 104 FidoNet Sysop Meeting. Contact Oscar Barlow at 104/0 for information. 25 Aug 1988 (pending BoD approval) Start of the Fifth International FidoNet Conference, to be held at the Drawbridge Inn in Cincinnatti, OH. Contact Tim Sullivan at 108/62 for more information. This is FidoNet's big annual get-together, and is your chance to meet all the people you've been talking with all this time. We're hoping to see you there! 24 Aug 1989 Voyager 2 passes Neptune. If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. ----------------------------------------------------------------- Bernard Aboba, 143/444 The MailCom Message Center of Palo Alto, CA has started two new echos and is looking for subscribers. The echos are Henani -- The Jewish Echo, and an Electronics Echo. Sysops interested in carrying the Henani or Electronics echos should contact Bernard Aboba via FidoNet mail at 143/444. Henani is meant to serve as a forum for discussion and information on Jewish issues, religous practices, and philosophy. The Electronics Echo is intended to aid hobbyists and electronics professionals in designing electronics projects or microprocessor based systems. ----------------------------------------------------------------- Latest Software Versions BBS Systems Node List Other & Mailers Version Utilities Version Utilities Version Dutchie 2.71* EditNL 3.3 ARC 5.21 Fido 12d* MakeNL 1.10 ARCmail 1.1* Opus 1.03a Prune 1.40 ConfMail 3.2* SEAdog 4.10 XlatList 2.84 EchoMail 1.31 TBBS 2.0M MGM 1.1* FidoNews 4-43 Page 18 23 Nov 1987 * Recently changed Utility authors: Please help keep this list up to date by reporting new versions to 1:1/1. It is not our intent to list all utilities here, only those which verge on necessity. ----------------------------------------------------------------- FidoNews 4-43 Page 19 23 Nov 1987 __ The World's First / \ BBS Network /|oo \ * FidoNet * (_| /_) _`@/_ \ _ | | \ \\ | (*) | \ )) ______ |__U__| / \// / Fido \ _//|| _\ / (________) (_/(_|(____/ (jm) Membership for the International FidoNet Association Membership in IFNA is open to any individual or organization that pays an annual specified membership fee. IFNA serves the international FidoNet-compatible electronic mail community to increase worldwide communications. ** Name _________________________________ Date ________ Address ______________________________ City & State _________________________ Country_______________________________ Phone (Voice) ________________________ Net/Node Number ______________________ Board Name____________________________ Phone (Data) _________________________ Baud Rate Supported___________________ Board Restrictions____________________ Special Interests_____________________ ______________________________________ ______________________________________ Is there some area where you would be willing to help out in FidoNet?_______ ______________________________________ ______________________________________ Send your membership form and a check or money order for $25 to: International FidoNet Association P. O. Box 41143 St Louis, Missouri 63141 USA Thank you for your membership! Your participation will help to insure the future of FidoNet. ** Please NOTE that IFNA is a general not-for-profit organization and Articles of Association and By-Laws were adopted by the membership in January 1987. The first elected Board of Directors was filled in August 1987. The IFNA Echomail Conference has been established on FidoNet to assist the Board. We welcome your input on this Conference. ----------------------------------------------------------------- FidoNews 4-43 Page 20 23 Nov 1987 INTERNATIONAL FIDONET ASSOCIATION ORDER FORM Publications The IFNA publications can be obtained by downloading from Fido 1/10 or other FidoNet compatible systems, or by purchasing them directly from IFNA. We ask that all our IFNA Committee Chairmen provide us with the latest versions of each publication, but we can make no written guarantees. IFNA Fido BBS listing $15.00 _____ IFNA Administrative Policy DOCs $10.00 _____ IFNA FidoNet Standards Committee DOCs $10.00 _____ Special offers for IFNA members ONLY: System Enhancement Associates SEAdog $60.00 _____ ONLY 1 copy SEAdog per IFNA Member. Fido Software's Fido/FidoNet $65.00 _____ ONLY 1 copy Fido/FidoNet per IFNA Member. As of November 1, 1987 price will increase to $100. Orders including checks for $65 will be returned after October 31, 1987. SUBTOTAL _____ Missouri Residents add 5.725 % Sales tax _____ International orders include $5.00 for surface shipping or $15.00 for air shipping _____ TOTAL _____ SEND CHECK OR MONEY ORDER TO: IFNA P.O. Box 41143 St. Louis, Missouri 63141 USA Name________________________________ Net/Node____/____ Company_____________________________ Address_____________________________ City____________________ State____________ Zip_____ Voice Phone_________________________ Signature___________________________ -----------------------------------------------------------------