BGFAX 1.55 Rev Q ================ 1. On Class 1 attempts that failed, BGFAX will now do a ATH0 before DTR tog. 2. BGFAX will no longer go beserk if an invalid +FDIS response is received when working in Class 2 or 2.0 mode. (To workout a problem when sending faxes on a Dolphin 19k2 Terbo external with 1.16c firmware.) BGFAX 1.55 Rev P Sat 15 June 96 ================ Well, oh well, oh well... I found some more bugs. :-) 3. Fixed a _MAJOR_ Class 1 /SEND mode error! This error is so serious I have no idea how it was overlooked by me. Basically, when sending to fax machines that do not support 0 ms/sl, BGFAX would pad all image scan lines to the correct nn ms/sl length (which is correct), but it would also pad the RTC sequence at the end of the page, which, apparently is a BAAAAAD thing to do, as even my own Murata fax machine would choke (after the 1st page) in this situation. Yikes. Fixed now. Thanks to J.R Burger for bringing this to my attention. 4. Class 1 fax receive mode will now check the training information, and if more than 25% bad characters are received, it will send an frame to the remote, and will drop down to the next lowest speed. This is a feature that almost every other Class 1 software has had, but I just never got around to putting it in util now. Just in case it causes problems, you can use the /NT switch for "no training check", which will make BGFAX Class 1 receive mode behave as it always has instead of trying to validate the training into as it will now do by default. 5. Changed Class 1 timings in receive mode--no longer waits 40 ms before sending AT+FRM=96 before training and image receive. This change let me receive faxes at 9600 sent from an I-Modem to a SupraSonic. (Still unable to send at 9600 from Supra to I-Modem, though. Not sure if it's my fault, USR's fault, or Supra's fault, though.) 6. In Class 1 send mode, if an or frame is received instead of an frame after a page is sent, things will now be logged as such, and will proceed instead of reporting "Unknown T.30 frame". Don't want BGFAX to be known as "Trashware" :-) 7. After a Class 1 fax had been sent, previous versions of BGFAX would end the session by (a) toggling DTR, (b) sending ATH0, (c) sending the term string tc= from the BGFAX.CNF 1.55P version reverses (a) and (b) due to a glitch in the Supra (Rockwell?) firmware. Apparently, the Supra needs an "ATH0" to be sent before any kind of DTR drop (when in Class 1 mode) or it crashes the v.21 channel b transmitter for any subsequent fax receives. 8. NFAX.COM modified to use a different interrupt so that it no longer causes hangups with OS/2 dos-boxes. Be sure to reboot your system after you replace the new NFAX.COM and BGFAX.EXE !!! 9. VIEW's new sticky Alt-F mode when changing to different pages was not working if Alt-S shrink mode was also engaged. Fixed. 10 Attempted again to fix the VIEW.EXE /1024 problem when running under Windows 95. Might actually have found something significant this time. Apparently, when viewing more than one fax in a single VIEW session, VIEW was playing around with memory in $A000 (VGA/VESA memory) before actually switching to VESA mode. Is this causing the problem? I don't know, but VIEW isn't doing this anymore. 11 ATOTSR.COM modified so that it waits approximately 1 second after receiving the "DATA" response before sending "ATO", since some modems did not always "get" the "ATO" if the TSR sent it took quickly. 12. BGFAX /HOST:nn idle max timer was kicking in even an idle max "nn" value was not specified. This is fixed now. 13. BGFAX no longer needs an environment variable. If the "BGFAX" environment variable is not found, the BGFAX.CNF file will be looked for in the same directory as BGFAX.EXE. Any use of the "BGFAX" variable override this new logic. 14. The "Log File" and and "Config File" name will now be displayed on screen. It gets pretty confusing when I'm running multiple BGFAX windows, sending and receiving, under OS/2. Now I'll know which BGFAX window is writing to what log and reading what CNF file. :-) BGFAX 1.55 Rev O Mon 10 June 96 ================ Oh my, yet another beta! Will this program ever get released? :-) Hopefully, this will be the last beta so we can have a full release next week. (I think this is the 4th or 5th time I've said this now.) 15 VIEW.EXE will now automatically "flip" pages in a fax if you press Alt-F when viewing the first page. This just saves you a keystroke on each page, since you will no longer have to hit Alt-F on any page except the first if someone sends you an upside down fax. 16 New BGFAX command line switch /NX This tells BGFAX that when sending faxes on Class 2 modems to "not wait" for the initial XON to be received. This might be necessary on some older Intel(GVC OEM) fax modems. Do not add this switch unless you notice things in BGFAX.LOG indicates "initial xon not received". 17 If any English-like characters are detected in Class 1 frames, they will be logged. Why? While viewing a PMLM (Ray Gwinn's Poor Man's Line Monitor for OS/2) trace for a fax session, I noticed that when talking to my Murata fax machine, it would actually send MY name in the NSF frame preceeded by a "EU" pair. I had no idea this was happening, but some other fax machines may do this as well. Will have to see if this is truly Murata specific or not. (Apparently, the Murata was getting my name from the fax page top-of-page header setup.) Ex: 03:38:43 ->[ATS11=70X4M2&K3DT8939320] 03:39:00 f=[CONNECT] 03:39:00 dial result [CONNECT] 03:39:01 hr=NSF:[255.3.32.0.0.69.85.66.46.74.46.32.71.117.105. 108.108.111.116.32.32.32.32.125.203.16.3] 03:39:01 f=[OK] 03:39:01 [ EUB.J. Guillot ] 18 New switch for VIEW.EXE /PL:nnnn This lets you refine the "page length" of a piece of laser paper, in the number of laser-scan lines. Normally, VIEW uses 3380 scan lines for a piece of A4 paper, but I was told some A4 printers very, i.e.: Deskjet 500C A4 /PL:3170 or /PL:3320 is performation skip Deskjet 500 A4 /PL:3234 Oki Laserline 6 A4 /PL:3411 If you are using US paper size, this switch should not be necessary! 19 BGFAX will now put a few extra spaces in the FAX.IDX file. I was told Faxworks didn't like just one space, but required more. 20 BGFAX Class 1 send mode should no longer get confused if stray XON, XOFF, DLE, or DC2 characters somehow get injected into the receive command string. 21 New BGFAX command line switch /EM:nnnnn It has been reported that sometimes BGFAX will sit idle if a fax send attempt fails, with the elapased time counter still ticking down. I have not been able to duplicate this, but people who use BGFAX sending hundreds of faxes have observed this. This is more of a kludge than a bug fix, but it should work until I am able to duplicate the bug. /EM:1000 for example tells BGFAX to abort after 1000 seconds (about 16 minutes). You probably will not want to use such small values, because a long 10-20 page fax could easily take 16 minutes (/EM:1000 seconds) to transfer. You should not use this switch unless you have personally observed BGFAX doing it's countdown to infinity. This switch will not make a difference unless the actual elapsed time counter is moving. (Maximum /EM:65535 seconds) BGFAX 1.55 Rev M Tue 04 Jun 96 ---------------- Well, it looks like it might be a little longer before the full release. There are some minor problems fixed and some minor additions made, since I want this next release to be as bug free and feature rich as possible. This should take care of all known bugs except for one. (The one bug that is not fixed relates to sending faxes from an XT-class machine, in which the top-of-page header is the only thing that is recevied. It turns out that the XT is so slow, the time it takes to close the temp banner file, and then open the fax file to send, is enough for the remote fax machine to think the connect was lost. Since sending top-of-page banners can be aborted with the /NB switch, and since most people do not own XT's, and since it would require me to rewrite a major section of the code that could cause other bugs to surface, I've decided to shelve this bug until I have a little more free time to work on it.) If no other bugs are found in this version of the software, then we look good for a full-release to occur within one week. That should be enough time for people to play with it, and for me to update the documentation and help files. (Of course, this is the second time I've said that recently, so you never know.) 22 BGFAX /SEND mode can now send TIFF-Class-F files! This is a very nice addition, since it allows much greater flexible in what documents are sent. I tested sending TIFF-Class-F files made from BGFAX, Faxworks/2, and Word Perfect 5.1+/DOS, and all the documents faxed correctly. (BGFAX has had TIFF-Class-F receive capabilities for nearly a year now, and VIEW has had TIFF-Class-F viewing capabilties for several months now, but this is the first time /SEND has been able to process them.) 23 MAKEFAX, when converting PCX and DCX files to FAX mode will now "guess" as to what resolution flag to put in the fax header, so that BGFAX knows what to tell the remote fax machine about the resolution of the upcoming document. If the PCX or DCX file has a page with greater than 1200 scan lines, it will assume the fax is to be marked as high resolution. If less than 1200 scan lines, it will be assumed low resolution. MAKEFAX can be forced to put a high resolution flag in the header with a /HR switch, and a low resolution flag with the new /LR switch. 24 Electronic Counter Measure for "Batman hack". 25 BGFAX/2 would have trouble receiving faxes if storing in TIFF-Class-F mode if an existing BGFAX.$$$ file in the directory was bigger than the size of the incoming fax. This should be fixed. 26 BGFAX/DOS and BGFAX/2 would have trouble receiving faxes if storing in TIFF-Class-F mode if using a Class 2 or 2.0 modem in which case a "Problematic Fax Reception (EOP)" error was encountered (i.e., +FHS:nn or +FHNG:nn abort where nn>0.) This should be fixed. 27 BGFAX /SEND mode was not able to send faxes that were "read-only". It can now do this, as it will use outgoing faxes in "read, deny none" mode instead of "read, write, deny none" mode. 28 Ditto for VIEW, when attempting to select "read-only" faxes for viewing. 29 Revision J and K were writing the log file times out to the hundred of a millisec. I did not intend for that to leak out in the beta since I was using that for some internal Class 1 testing on my side. 30 BGFAX VESA view modes (e.g.) 1024x768 was not working properly with some video cards under Windows 95, but remained to work fine under DOS. I made a slight modification that might fix this in VIEW. BGFAX 1.55 Rev K Thu 30 May 96 ---------------- If all significant bugs are now fixed, expect to see the full release of BGFAX out very soon (a week or less). The only thing I have left to do is to make some changes to the BGFAX.DOC, and also I have to make some D'Bridge help files since I've promised several people that I would personally type some up. 31 BGFAX /HOST mode now betters handles conditions in which the number of rings is greater than one (ri=2 or higher in BGFAX.CNF). Before, BGFAX would wait up to 120 seconds before getting the two (or more) rings. Waiting two rings to answer the phone is for Caller ID purposes. What would happen is that someone would call, then hangup before two rings came, and this caused the Caller ID information for the next caller to not work properly. Now, BGFAX /HOST will abort if a second (or third, or etc.) RING does not follow the previous RING without 10 seconds. After the correct number of RING's are received, then the 120 second timeout is re-enforced. 32 VIEW.EXE will now double the number of scan lines of a low resolution fax during a PCX and DCX conversions so that it works better with OCR software that might be expecting more pixels to work with. To override this feature so that PCX and DCX conversions provide a one-to-one pixel conversion, use the new /RH switch (retain height). 33 VIEW.EXE now handles /PCX conversions differently. It seems that NOBODY liked my convention of converting multiple page fax files into PCX files. (If you had a 3 page fax, it would make HELLO.PCX, HELLO.P02, HELLO.P03 in the old version of VIEW.) It has been reported to me that most image editing software is brain dead and it will not acknowledge a file is PCX format unless it has a "PCX" extension, so here is how things work now: "VIEW 2letters.fax /pcx" will create PAGE0001.PCX and PAGE0002.PCX. Notice that the filename base is completely missing from the target files. I did this because I just personally HATE fax software that does a truncation to the base filename in order to stuff the page number at the end. So, how will the image editing software know about these funny PAGE*.PCX files? Well, know, VIEW will create a DOPCX.BAT file that says: CALL EXEPCX PAGE0001.PCX PAGE0001 CALL EXEPCX PAGE0002.PCX PAGE0002 So, you can now put the name of your image editing or OCR software in the EXEPCX.BAT file that you will produce, and pass the filename via the %1 variable (or %2 variable if you are using even brain-deader software that croaks if a PCX extension is given when the extention is already known to be PCX). Example using make believe OCR-THIS.EXE, EXEPCX.BAT would say "OCR-THIS %2.PCX" or just "OCR-THIS %1". By executing the DOPCX.BAT file, the make believe OCR-THIS will will run for both pages. Okay, for those of you who already wrote programs to handle the old way VIEW worked, simply add the /RF switch (VIEW file.fax /PCX /RF) to work in "retain filename-base" mode. This time, "VIEW 2letters.fax /PCX /RF" will make 2LETTERS.PCX and 2LETTERS.P02. The new DOPCX.BAT file will also be created, example: CALL EXEPCX 2LETTERS.PCX 2LETTERS CALL EXEPCX 2LETTERS.P02 2LETTERS Some people might like the /RF (original) method better. The %2 variable in this case isn't really meaningful, but I kept it there to be consistant with the non-/RF case. These two methods should provide the ultimate in flexibility. 34 New program included in this archive: ATOTSR.COM This program is for those of you using RPI modems which only offer Class 1 fax capabilities. These modems, while having adaptive answering features, could not previously have been used with BGFAX unless you were running in "BGFAX /HOST /ATO" mode, which meant no FidoNet mailers. A little background: Some Class 1 fax modems, when in adaptive answer mode, will return a "DATA" response code if a data call is encountered. Smart modems will also immediately return the "CONNECT nnnnn/xxx" result code. However, the RPI modems (and some others, like USR Class 1 mode) will require that an "ATO" command be sent to the modem so that it can resume data operations. This is very stupid, but hey, they didn't bother to ask me when designing their modems. The ATOTSR.COM file can be loaded in your AUTOEXEC.BAT file (don't forget to reboot). This file will only interface with your FidoNet mailer if you are using a FOSSIL driver, because it is the only easy way to intercept inbound characters and to "trick" the FOSSIL into sending an "ATO" command to the modem if your FidoNet mailer does not. Repeat: ATOTSR.COM will not function unless a FOSSIL driver is also present. Most FidoNet mailers use FOSSILs, so this is not a problem. If you are using Intermail, make sure you use FOSSIL mode instead of direct-comm mode. Note that this TSR only works under DOS sessions. It will not work in an OS/2 session with BGFAX/2. It might work okay in a Win95 DOS box, but I don't think it would work correctly in a Win95 32-console box. 35 Regarding low-speed (2400) data modem fix done in 1.55j, it allowed the sending of faxes normally, but when BGFAX tried to clean up and terminate, it was trying to send an "ATH0" command to the modem at 19200 instead of 2400, and the low-speed modem would not respond. Now, termination condition will have a 2400 DTE shift and this should fix the long wait caused by 1.55j on these low-speed modems. 36 MAKEFAX, when encountering a form feed in an ASCII -> FAX conversion, would not put any top margin on the next page like it was supposed to. This is now fixed. BGFAX 1.55 Rev J Thu 23 May 96 ---------------- This release is basically a hodge-podge of bug fixes. If any major bugs are found, I will probably have another quick beta release, followed by the full release. The last full release (1.55) was on January 8th, which was a LONG time ago, and registrations have started to slack off a bit, probably because people are afraid to register something they perceieve as "stale", so I'm going to try to get the next full release out quickly. Report any bugs to me via Fido 1:106/400, e-mail: bjg90783@jetson.uh.edu, the Fido BGFAX support echo (tag "BGFAX"), BBS: +1 713 893 9124 or even voice at +1 713 893 9320. 37 Some new PPI modems report "0,1,80" on the AT+FCLASS=? commands that BGFAX /SEND issues to determine what outgoing fax class to use when sending faxes. BGFAX did not expect to see the "80", and it was assuming that the modem had Class 2 capabilities when it really did not. It should now correctly use Class 1 on these new modems. 38 Reworked the Class 1 training sequence on fax sending slightly. It eliminated problems sending faxes from Windows 95 dos-boxes with Sportster 14400 modems. Also, reworked Class 1 image send sequence in OS/2 version--before BGFAX/2 had trouble sending to some machines in Class 1 at 12000 and 14400 bps. 39 MAKEFAX now supports DCX as a valid input file type. (Recall DCX is a multi-page PCX file), e.g., makefax sample.dcx output.fax or, makefax coverpg.pcx+notes.txt+document.dcx+signatur.pcx output.fax 40 VIEW was not allowing individual page print (ctrl-enter when viewing a specific page on screen) if conventional memory had been exhuasted (i.e., currently spooling to XMS or disk.) Now, VIEW will reserve 32K of conventional memory for the print buffer. 41 In abnormal terminate situations, VIEW was not releasing any used XMS memory back to the operating system. Bug fixed. 42 VIEW now supports printing to 9-pin dot matrix printers. Use VIEW /P9 to set VIEW into 9-pin mode. NOTE: In this mode, VIEW will print pages twice as long as they should be. So, a 3 page fax will take 6 pages to print. I've refused to support 9-pin printing in the past, because it is my opinion that faxes just are not worth printing to 9-pin printers. By printing one page as two, it allows us to get something printed that at least is readable. If you still have a 9-pin printer you really need to go buy a 24-pin or laser. 43 Had a report that the FAXIN.LOG file was not always updated if a failed fax arrived. This should be fixed now, but I was unable to test this fully, so if Warren Z. should try and see if it has been fixed. 44 Michel Ouellet reported the FAX.IDX file being created by BGFAX was not formatted in the same way as Faxworks wanted it to be. This should now be corrected. FAX.IDX represents the next index available, NOT the next index used. (FAX.IDX is used in Faxworks file format storage) 45 DOBBS.BAT and DOBBS.CMD will now have the PID number appended to them when BGFAX is running in /HOST /PID:nnn mode. i.e., /PID:4 will cause BGFAX to make DOBBS4.BAT files and BGFAX4.LOG files to keep things from getting "confused". 46. Minor cosmetic changes were made, as well as minor changes to prevent hacking. 47. For older 2400 data-modems with Class 1 or 2 fax modems, BGFAX /SEND mode was not always working correctly, because, even though these modems support a DTE rate of 19200, they "pretend" not to until the AT+FCLASS=1 (or =2) command is sent by BGFAX. These dinosaur modems should now work properly in send mode. (sp=2400 should be set in the BGFAX.CNF file for this special operation mode to work) 48. Candian Caller ID decoding in /HOST mode that was added in 1.55g was not working properly. Should be fixed in this beta. 49. BGFAX /HOST:nn idle timeout mode, makes BGFAX abort with an errorlevel 6 after approximately nn minutes of non-activity. This worked, but if midnight passed, BGFAX would get stuck and never exit until someone called into the system. BGFAX /HOST:nn mode will now always exit at midnight to prevent this problem. This does NOT affect regular /HOST mode. BGFAX 1.55 Rev G Thu 18 Apr 96 ---------------- (VIEW.EXE and FNTEDIT.EXE are unchanged since 1.55f) 50 BGFAX in /HOST mode was not saving faxes to disk if the fax failed without receiving all pages. This should not have affected rear-end mode, but /HOST mode only. Thanks to Warren Zatwarniski for finding this bug. 51 While working on the above bug, I found a new bug. Apparently, if a "live abort" happens during fax receiption, this too would cause BGFAX to exit without saving any partial fax. Now these too should be saved. (A "live abort" means while working, BGFAX receives either a "RING" or an "ERROR" response code from the modem--both of which mean something very wrong has occured.) 52 Still received a few reports that BGFAX was not functioning properly under DesqView with BGFAX 1.55f. I have made an additional change in the DV timeslice return logic, so let me know if this fixes the problem or if it is still broke. Vince Rifici and Glenn Fischer reported this. 53 Added new command line parameter for BGFAX, /IT /IT should only be used if you are having trouble with your modem occasionally stopping all image reception without notifying BGFAX that the image sequence has stopped. /IT is for "image timeout" detection. 1.55e added IT detection, but many reported problems with it, so it was modified in 1.55f, but even this still results in problems on some fast machines, such as Richard Boychuk's Win95 DOS box. So, the IT detection will now be turned off by default. 54 Added a Canadian Caller ID filter for Supra modems at the request of Sylvain Lauzon for /HOST mode. Let me know if it works, since I can't easily test it here. 55 MAKEFAX will no longer completely abort if one of the input files is missing. i.e., the command... MAKEFAX cover.pcx+filename.txt+file2.txt output.fax will still work even if "filename.txt" file is missing or locked by another application. MAKEFAX will alert the user on screen, and will also put a note on the fax file itself that the file was missing. 56 OS/2 version of BGFAX in /HOST mode was not responding to the keyboard when waiting for a call (i.e., to exit BGFAX was not working). This should be fixed now. 57 OS/2 version of BGFAX in /HOST mode will now turn the cursor off (like the DOS version) when it is waiting for calls, and will turn the cursor back on once activity starts. BGFAX 1.55 Rev F Sun 31 Mar 96 ---------------- 58 MAKEFAX can now handle multiple input files! Example... MAKEFAX cover.pcx+filename.txt+file2.txt output.fax or MAKEFAX @filename.lst output.fax Where "filename.lst" is a standard ASCII text file, with one filename per line. 59 MAKEFAX now supports 132-column mode. Example: MAKEFAX filename.txt output.fax /132 132-column, font #1 MAKEFAX filename.txt output.fax /132 /F0 132-column, font #0 MAKEFAX filename.txt output.fax /132 /HR 132-col, font#1, high-res Remember that MAKEFAX will default to 100-column mode unless you use the /80 or /132 switch to override. 60 The VIEW.EXE Alt-G (or Alt-J), "jump to page number" bug should be fixed. (This feature was introduced in the last beta.) 61 Had a report of BGFAX reporting a "fax image timeout" when trying to receive faxes on very fast machines. I've made a slight change that might fix this, but don't know if it will since I was never able to duplicate this problem. Only had one person report this problem, but it appears as if it could have been widespread. 62 FNTEDIT made more multi-tasking friendly. It will now return time slices when waiting for input from the keyboard. 63 FNTEDIT was not always saving changes to the last character edited. This should be fixed now. 64 MAKEFAX2.EXE (OS/2 version) now gives some time slices back to OS/2 during the conversions. This means the conversions will proceed slower than they have before, but it should not cause all the other applications to slow to a crawl as before. Let me know if people think it runs too slow now, and I'll add a switch to either enable or disable this so- called OS/2 friendly mode. The DOS version will still run at maximum speed. BGFAX 1.55 Rev E Sun 3 Mar 96 ---------------- 65 Have optimized the communications/timeslice routine in the DOS version somewhat. The DOS version should no longer take up 100% of the CPU when receiving or transmitting a page under OS/2. Also, the DOS version should run more smoothly with both DesqView and Windows. (CPUUSE.EXE for Windows 3.1 reported 4% usage when BGFAX/DOS is waiting for a call, 14% during page receive, and 38% spikes during interpage negotation.) 66 Fixed a major bug relating to saving files in TIFF-F format. Anybody telling BGFAX to save in Faxworks format should immediately upgrade to this beta version. The problem was that many faxes were getting scrambled because the byte-alignment filter in BGFAX was not working very well, resulting in faxes containing 50% bad scan lines. 67 VIEW.EXE has a new feature when you are in page-view mode. Alt-J and Alt-G will now allow you to jump ("goto") a specific page number. So, if you bring up page 1 and want to go to page 13, just hit Alt-J (or Alt-G, same thing) and type in "13" at the prompt. Note that if you save faxes in ZFAX format, the first time you use the "jump" function, a quick analysis of the page will be performed. On slow machines (less than 386), this may take a while. 68 The TIFF "filter" can also be turned on for ZFAX and QFX format with the /TF command line switch. This just makes sure that the T.4 data in the fax image is byte-aligned. This is of use mainly to me for testing purposes, or for developers who wish to directly manipulate the T.4 data. 69 Made some modifications to the Class 1 timeout parameters. If anyone has problems with this version (1.55c) getting "stuck", let me know ASAP and provide me with a clip of the BGFAX.LOG. I really want to get these "stuck" bugs fixed quickly. 70 Changed OS/2 version so that it answers the phone like the DOS version (i.e., waits for "RING" or "2"[numeric result] instead of waiting for the "ring indicator"). Some modems do not produce the "ring indicator" signal as well as some damaged serial cables, so that will help. 71 Changed OS/2 version so that it now works with IBM's stock COM.SYS driver. Previous versions of BGFAX2.EXE would only work with Ray Gwinn's SIO.SYS. Now, it can work with both. BGFAX 1.55 Rev B Sun 25 Feb 96 ---------------- 72 MAKEFAX finally can convert ASCII documents using 80-columns per line! Before, MAKEFAX would always transfer the file into a 100-column per line fax. I got numerous complaints about this, because the lettering looked a little too small on the received fax machine. Now, using the /80 switch on MAKEFAX, you will get larger output on the outgoing fax. I am also including a new BGFAX.FNT font file, because a few changes had to be done to about two dozen characters in order for the dual 80 and 100 char/line font to use the same 16x32 and 32x32 font defintions. Example... makefax test.asc output.fax /80 MAKEFAX will continue to default to using 100 columns per line to maintain compatibility with the older version of MAKEFAX. 73 I believe I have fixed the DesqView problem that was present in BGFAX 1.54 and 1.55. In the previous version, BGFAX would receive a one page fax under DesqView, but it come come in VERY slowly (300 cps instead of 1200 cps, for example), and never receive the second page. If you were one of the people that experienced that, let me know if this version corrects the problem. 74 BGFAX will now honor the FaxWorks's FAX.IDX file. This is a standard ASCII text file that will be present in the receive fax directory. If BGFAX finds it, it will find out the last fax number that FaxWorks thinks it has received, and use that as the maximum fax number. BGFAX will also update the FAX.IDX file. 75 The DCE rate in /HOST mode is now stored as a long integer instead of a word (unsigned standard integer). With people locking ports at 115200 and not setting their modem to report the DCE speeds, and with all the ISDN TA's popping up with 128000 DCE speeds, this was a necessary thing (and quite easy to fix). Before, BGFAX would report incorrect speeds if the DCE were higher than 65535 bps. 76 BGFAX /SEND mode will now create a SEND.DAT file after BGFAX finishes. The file will look like this: FaxFilename 2pages.fax FaxTelephoneNumber 7138939124 LastPageSuccessfullySent 2 TotalNumberOfPages 2 This is a regular ASCII file, which contains information about the last fax sent, including (most importantly) the last page successfully sent. To use this information, you would need to write a program to examine and see if "LastPageSuccessfullySent" is equal to "TotalNumberOfPages". If not, this indicates a transmission failure, and you will need to resend the fax using the /SP:lastpagesuccessfullysent+1 logic, so that you need not resend the entire fax. This may also be useful on some of the buggier fax modems, where they (sometimes) do not return a successfully condition upon sending the last page, even though it was really sent. What you would need to do, is see if the LastPageSuccessfullySent is one less than the TotalNumberOfPages, if so, you can "assume" (big assumption) that the last page might have actually gotten through even though the modem reports to BGFAX otherwise. Regards, B.J. Guillot