From: B.J. Guillot To: All Thread: BGFAX 1.70 Revision H (1/5) Date: 18-Jul-97, 4:40pm (Ref# 5531) Beta versions can be obtained from my web site, http://www.blkbox.com/~bgfax/ Or, by FidoNet FREQ of magic name "BGBETA" from 1:106/400 Or, by good old fashioned BBS download from +1 713-507-9620 1.70 Revision H Friday 18 July 1997 ~~~~~~~~~~~~~~~~~~~ Please note that as of the last beta, I adjusted the pricing for BGFAX. The price for BBS sysops and other non-business users continues to remain at USD$25.00. However, if you want BGFAX to be registered in the name of a business, the price is USD$68.00. If you are a small business and cannot afford the $68 price, then simply register BGFAX in your own personal name and I'll accept the $25 cost. (I won't turn down money.) 1. Fixed a bug introduced in the last beta of VIEW.EXE that caused very strange things to happen after the user instructed VIEW to print a fax. 2. When BGFAX /HOST mode is in /PS:xxx (Poll Server) mode, the host mode idle info screen will replace the "Mail crash call" line with the new "Number of inbound polls" line. Since Poll Server mode should not be used with adaptive answering, no data calls means no possibility for mail crash calls. 3. If an inbound poll comes in during Poll Server mode, BGFAX will now correctly log this entry to the FAXOUT.LOG file. A "P|" will be prefixed before the filename to indicate to the user the file was sent as a poll rather than as a /SEND. e.g. 07-17 18:27 00:23 11012 9600 P|1234567.FA 713 507 9620 .. 1 Finished 4. Added feature to QCONTROL.EXE which allows the user to show faxes that are no longer in the queue, but faxes that were not actually sent by the POLYFAX/BGFAX combo. Recall this happens if you manually delete a fax from the queue via QCONTROL or if POLYFAX took the fax out of the queue because of meeting some kind of error constrant. You CANNOT actually undelete the files from the queue, but this option allows you to judge just how well the queue went. To make QCONTROL show these sent-but-not- really-sent-faxes, just specify a command line parameter. (Any command line parameter, i.e., QCONTROL /SS). 5. New POLYFAX command line switch #LS:nnnn (Lowest Speed) If POLYFAX has trouble sending to a specific fax number multiple times, POLYFAX will force the maximum rate to 4800 bps. If this number is too low, you can adjust the lowest speed by adding a #LS:7200 or #LS:9600 switch to the end of the POLYFAX command line. This can also be an argument in the list file, or ASCII file dropped into POLYFAX.NEW. 6. New POLYFAX command line switch #MA:nnnn (Maximum Attempts) Previously, the only way to remove a job from the POLYFAX queue was if the threshold for maximum failures (#MF:nnnn) was met, or if you manually killed the job (via QCONTROL.EXE). The #MA:nnnn is similiar to the #MF:nnnn, except that #MA:nnnn will also count trivial "failures" such as BUSY, etc, which, is not technically a failure. This can also be an argument in this list file, or ASCII file dropped into POLYFAX.NEW. 7. Fixed a bug in POLYFAX that caused POLYFAX to abort if you put more than 10 files into the POLYFAX.NEW directory. POLYFAX was not properly closing one of the files, and it was running out of file handles. 8. A piece of debug code was left in MAKEFAX 1.70e that was causing MAKEFAX to beep when it detected an <EOF> character during an ASCII-to-FAX file conversion. This debug code has been removed. 9. The /AN switch (Alternate Naming convention) introduced in the last beta of BGFAX was not always saving the files in the proper place. It was ignoring the rp= variable in BGFAX.CNF. This has been fixed. Another bug relating to the /AN switch caused the idle info screen during BGFAX /HOST mode to mark a received fax as an aborted fax. This related bug has also been fixed. 10 Fixed a small glitch in VIEW and BGFAX that involved the decoding off TIFF file headers. Both executables were still looking at the full 32-bit numerical field even if the field was denoted as an 8-bit or 16-bit field. This was usually not a problem except on some programs that generate TIFF files which don't null out the remaining 24 or 16 bits of an 8 or 16-bit field. 11 <NSF> frames have been logged to the BGFAX.LOG for the last few versions, but many people e-mail me and tell me the frames are being logged backwards. Since the "NS" in NSF stands for "non-standard", it is not surprising that some fax machines use a different order than others. So, BGFAX will now log the <NSF> frames in both directions. e.g.: 17:23:39 <NSF> [ EUB.J. Guillot ] [ tolliuG .J.BUE ] BGFAX logs only ASCII characters in the alpha-numeric range. Notice the first group is the string "EU" followed by my name, nad the second group is identical to the first group except that it is saved backwards. It should be noted that logging the <NSF> frames are not really an important thing to do, but sometimes they provide interesting information. 12 It has been requested that BGFAX also log <NSC> frames when detected. I have added the code to do this, but I have no way of checking whether this works or not since my stand-alone fax machine does not seem to be able to generate this frame. The <NSC> frames will be logged in a way identical to the <NSF> frames, as mentioned above. 13. Added command line option to VIEW.EXE, /FH for "Force High" resolution. In some cases, when BGFAX in working in rear-end mode operation (when a BBS or Fido Mailer answers the phone and passes control, some modems will send the resolution information to BGFAX too late, and if you try to print such a fax, it may take two full length pages to print a single page fax. The /FH will tell VIEW to force the page as high resolution rather than the default of low resolution. Most people should never need to use this switch. I mentioned to at least one person that this beta version would contain some additional POLYFAX controls for limiting the time of day that POLYFAX uses when sending faxes, as well as putting some kind of network support into POLYFAX so that multiple computers could work at sending a job of broadcast faxes. Unfortunetly, I will have to post-pone these two changes until the next beta due to another project that just popped up. Rather than delay the entire beta another week or two, I've decided to go ahead and release a beta now. (There are already 13 changes in this one, anyway.) Regards, bgfax author
From: Alto Speckhardt To: B.J. Guillot Thread: BGFAX 1.70 Revision H (2/5) Date: 20-Jul-97, 11:10pm (Ref# 5537) Servus! May I ask why you changed your archiver from ARJ to ZIP? Personally I not only liked ARJ better then ZIP but also found the "verifiable" ARJ quite advantageous. Now your archives can as well be repacked to another format, files can be added or left out without anybody noticing. RU! (48o18'13''N/10o10'32''E) --- XP - Just say no! * Origin: Weissenhorn Ost (2:2487/4000)
From: T.J. Mcmillen, Jr. To: Alto Speckhardt Thread: Re: BGFAX 1.70 Revision H (3/5) Date: 22-Jul-97, 2:36am (Ref# 5542) AS> May I ask why you changed your archiver from ARJ to ZIP? Personally I not o AS> liked ARJ better then ZIP but also found the "verifiable" ARJ quite AS> advantageous. Now your archives can as well be repacked to another format, AS> files can be added or left out without anybody noticing. That's just his BETA revision releases. The original program is (full version) is still in ARJ format. --- Renegade v5-11 Exp * Origin: The Titantic BBS . - FidoNet - . 1-412-694-9701 (1:2610/33)
From: Curtis Brewington To: B.J. Guillot Thread: Re: BGFAX 1.70 Revision H (4/5) Date: 23-Jul-97, 4:53pm (Ref# 5544) -=> Quoting B.j. Guillot to All <=- Something About: BGFAX 1.70 Revision H on 07-18-97 16:40 BG> 1. Fixed a bug introduced in the last beta of VIEW.EXE that caused BG> very strange things to happen after the user instructed VIEW to BG> print a fax. Disregard my netmail on this. Will grab this version! ___ Blue Wave/DOS v2.30 [NR] --- TriToss (tm) v11.0 - #0 * Origin: Paradigm Shift East * (33.6 x2) * Mt. Vernon, NY (1:2625/141)
From: B.J. Guillot To: Alto Speckhardt Thread: BGFAX 1.70 Revision H (5/5) Date: 24-Jul-97, 11:48am (Ref# 5548) > May I ask why you changed your archiver from ARJ to ZIP? Personally I not onl > liked ARJ better then ZIP but also found the "verifiable" ARJ quite > advantageous. Now your archives can as well be repacked to another format, > files can be added or left out without anybody noticing. BGFAX, both beta and full release versions where usually released in ARJ format before September 1995. Why did I use ARJ? Because, like you, I find ARJ a superior program. When compared to newer versions of PKZIP, ARJ does not really have that much of a compression advantage, but then one thing ARJ offers is super flexibility. ARJ must have over 100 different possible command line switches. :-) ARJ has come in handy numerous times, and I liked it enough that I registered it and bought one of the authentication keys as well. That cost me $90, and I still use ARJ for all internal operations over here. Now, what's so special about September 1995? An article about BGFAX was published in the Fox Pro Advisor magazine. I had people calling like crazy wanting to get a copy of BGFAX. The problem was that not any one of these people had ever heard of "ARJ" and had no idea what to do with the BGFAX150 (or was it BGFAX160) ARJ file. Since then, I've been careful to make full releases of BGFAX available in ZIP form to cut back on the phone calls I get asking how to decompress the ARJ file. I don't mind people calling me about questions on BGFAX. I actually like to get calls about BGFAX, but I don't like to get calls on other things (like "Who do I uncompress this ARJ file", or "How do I install this door game for my BBS?). (Someone even called me once asking how to get PC Board setup, no, not PC Board set up with BGFAX, just PC Board. Since I don't even USE PC Board, I had no idea why I got this call.) Okay, but getting back to ARJ vs. ZIP. So, after that Fox Pro Advisor article, the full releases were always ZIP, and I stuck with using ARJ for the beta releases. I figured that if someone does not know what an ARJ file is, they have no business being a beta tester. Since I always run public betas (I always have considered private betas to be silly--it's just not worth the time coordinating a "top secret" operation), using ARJ for the beta makes sure that the people using the beta actually know a little bit about things. I suspect the reason you asked this message was because with the BGFAX 1.70h beta release, on my web site, was in ZIP format. On my BBS and via file request it is still available in ARJ format. So, why is it ZIP on the web site? My Internet provider recently upgraded his server and put a newer version of (whichever) Unix he uses on, and updated a whole bunch of other stuff at the same time. Since this was the machine that he runs the web server off of, the new version of software had some strange side effects that I guess he hasn't had the time to fix yet. One of the side effects of the upgrade was that some of my GIF's and html files on my web page were not accessible by the world. This was easily corrected by using the "chmod" command. Apparently the previous web server software was not as secure as the current version. On to the second problem... Every time I put a new release or beta on my web site, I do a test download using Netscape just to make sure I put the file on the server correctly (using BINary mode instead of ASCII mode when I FTP the files to the server). When I ran this test for 1.70h, Netscape was not seeing the file as a "downloadable" file (probably the wrong terminology), but it kept putting the actual ARJ file on the web browser screen as if it were a text file. I think there's just a little configuration glitch on my ISP's web server program, and as soon as he gets it corrected, the next beta will probably be back in the good old ARJ format. Sorry for the long message. :-) Regards, bgfax author