home *** CD-ROM | disk | FTP | other *** search
/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / UTILITY / AVIEW66A.ZIP / WHATSUP.DOC < prev   
Text File  |  1994-05-08  |  10KB  |  240 lines

  1. 05/08/94
  2.  
  3. Support has been added for an additional archiver, SQZ.
  4.  
  5. 01/26/94
  6.  
  7. Cygnus Data Systems has relocated to Woodinville, WA.
  8.  
  9. Cygnus Data Systems
  10. Daniel Durbin
  11. 14027 NE 181st Street #B-103
  12. Woodinville, WA
  13. 98072-6846
  14. (206) 481-3484 (voice)
  15. (206) 481-9582 (bbs/fax)
  16. FidoNet 1:343/181
  17. dand@eskimo.com
  18.  
  19. 11/30/93
  20.  
  21. Cygnus X-1 BBS is currently down, but will be up at its new location in
  22. Woodinville, WA shortly after the first of the year.
  23.  
  24. 10/21/93
  25.  
  26. Cygnus X-1 BBS is relocating to the Seattle area (most likely Redmond, WA).
  27. The BBS will be shut down on 5 November, 1993 and will start up again sometime
  28. thereafter in Redmond, WA.  All accounts outside the 619 area code will be
  29. maintained indefinately.  The next release of AViewCom will contain the new
  30. address and phone numbers.
  31.  
  32. 02/24/93
  33.  
  34. Cygnus X-1 BBS is undergoing some major changes.  I am moving away from
  35. using Perspective as the BBS and into using BinkleyTerm/Maximus/Squish.
  36. I have added the FidoNet node 1:202/227 and am working on adding a
  37. uucp <-> FidoNet gateway.  AViewCom is continuing to evolve.  I hope to
  38. make it more generic and to interface readily with a variety of BBS
  39. software.  A major documentation overhaul is also planned.  However, the
  40. registration rate is still low - I have 500 unregistered callers and only
  41. 300 registered callers with accounts on my system.  If you have been
  42. using AViewCom for more than 30 days, please consider registering it and
  43. contributing to its further development.
  44.  
  45. 09/08/92
  46.  
  47. Errors will occur using PKZIP V1.01.  Upgrade to v1.10
  48.  
  49. 07/06/92
  50.  
  51. The v3.50 of WildCat has corrected the problem with line 30 in the DOOR.SYS
  52. file.
  53.  
  54. 05/17/92
  55.  
  56. Added a few new command line parameters.  Please review the AVIEWCOM.HST
  57. file for details on changes, and AVIEWCOM.DOC for further information on
  58. the new parameters.  Also, PKUNZIP v1.1 recognized -x and -e as parameters,
  59. but the new PKUNZIP v1.93 only recognized -e.  Further, PKUNZIP v1.01 only
  60. recognized -x.  I have chosen to use the -e parameter.  If you do not have
  61. PKUNZIP v1.1 or newer, please upgrade to a newer version.
  62.  
  63. 04/15/92
  64.  
  65. AViewCom will detect if DesqView is resident and will enable the patch
  66. to prevent crashes.  Part of this is a pause for keypress before shelling
  67. to an external program.  If your system does NOT crash while reading a
  68. text file with earlier versions of AViewCom, then include the -q parameter
  69. on the command line to disable this pause.
  70.  
  71. 04/14/92
  72.  
  73. Thanks to some supportive help from Robert Cole from Mustang Software,
  74. I have found a patch that seems to avoid the problem of AViewCom crashing
  75. while running under some DesqView systems.  The problem resides either in
  76. the gettext() or spawnlp() functions of TurboC as I am using them.  I will
  77. be talking with Borland and QuarterDeck to come up with a true fix for the
  78. problem.  For the moment, I have implemented a patch to hopefully avoid the
  79. problem.  If you run a DesqView system, please let me know if you have any
  80. trouble with "Reading a text file" or "Downloading a file" while using this
  81. version.  There are many who have helped me over the years narrow in on this
  82. problem.  I can't mention all of them, but I'd like to offer a special thanks
  83. to Dave Codey, Minos Tsaussis, Pat Nefos, Scott Burch, and Rick Hemming.
  84.  
  85. 04/05/92
  86.  
  87. PAK.EXE v2.51 is a memory hog and will take all remaining memory when
  88. called.  With 400 kbytes free, PAK.EXE would not extract the file I
  89. requested and gave no reason.  I guess the 400 kbytes wasn't enough.
  90.  
  91. 03/30/92
  92.  
  93. In an attempt to loacate and fix the DV bug in AViewCom, I have
  94. completely re-written and re-structured the code.  I had hoped that in
  95. the process, to fix the bug which has caused DV users so many headaches.
  96. However, I was unsuccessful.  I am now using the SMALL memory model
  97. instead of the LARGE memory model to compile the program.  It will run
  98. faster now.  It now uses 103 kbytes of memory.  Also, the maximum
  99. filename capacity of files within an archive has been increased from a
  100. limit of 255 to no limit.  The filenames are stored in a temporary file
  101. called AVIEWLST.nnn where nnn is a number from 0 to 999 allowing 1000
  102. nodes to use seperate temporary files simultaneously.  I have also
  103. addes several useful new features to the program.  In addition, the
  104. documention has been completely re-written.
  105.  
  106. 03/11/92
  107.  
  108. I must apologize to several people for being so unavailable for the past
  109. few months.  I've been involved in another project and worked 80 hours a
  110. week for the last 15 weeks of 1991.  I spent the first couple months of
  111. this year recovering.  I'm back now and am working on v6.2.  For DesqView
  112. users, there was a mention of a STEALTH.TEC text file posted on Quarter
  113. Deck SW Support BBS which has a fix for the memory conflict problem with
  114. AViewCom.  I haven't read this, can someone let me know if this fix works?
  115. Some DesqView users are not aware that DVANSI.COM should be loaded prior
  116. to running WildCat to allow AViewCom to properly display ANSI characters.
  117. Be sure to include DVANSI in your CAT.BAT batch file.
  118.  
  119. 10/12/91
  120.  
  121. It has been brought to my attention that at times, AViewCom will report
  122. that a user's download kbyte limit has been exceeded when they attempt
  123. to download a file.  This happens sometimes because WildCat improperly
  124. writes line 30 in DOOR.SYS.  It should write the DAILY DOWNLOAD KBYTES
  125. TOTAL, but instead, it is writing the same value as line 48 which is
  126. TOTAL DOWNLOAD KBYTES (from day one!).  Since AViewCom is used with 
  127. other types of BBS's and reads DOOR.SYS which is created properly by
  128. them, I will not change AViewCom to adjust for this WildCat bug.  Instead,
  129. WildCat SysOps should request a bug fix from Mustang.
  130.  
  131. 10/10/91
  132.  
  133. For those running multi-nodes under DesqView, it has been discovered
  134. that using LOADHIGH causes AVIEWCOM to lockup when attempting to
  135. extract a file from an archive.  Removing the LOADHIGH operations
  136. alieviated this problem in one DesqView installaion.
  137.  
  138. 09/19/91
  139.  
  140. I have implemented the update user function by reading USERINFO.DAT
  141. and modifying the last two lines to reflect the number of downloads
  142. and download kbytes.  However, this is supposed to be a read/write
  143. file but WildCat does not yet read this file back in and update the
  144. allusers.dat file.  Since there is too much risk in corrupting the
  145. database by having AViewCom update the database, the update user
  146. function will not be active until WildCat reads back in the
  147. USERINFO.DAT file.
  148.  
  149. 09/05/91
  150.  
  151. AViewCom v6.1c is the first release which will read the DOOR.SYS
  152. file.  I was amazed that the number of inquiries about this version
  153. far exceeded the number of registrations I have received to date.
  154. The shareware version has some functions disabled including reading
  155. the DOOR.SYS file.  The shareware version will still run correctly
  156. under WildCat v3.n even without reading DOOR.SYS.
  157.  
  158. 08/25/91
  159.  
  160. Work has started on supporting WildCat v3.0.  I have added the
  161. function to read in the DOOR.SYS file, but I still need more
  162. information than is provided in that file:  system upload/download
  163. ratio limit, and maximum download kbytes allowed.
  164.  
  165. 06/08/91
  166.  
  167. Work will start soon on supporting the WildCat v3.0 databases.
  168. I've spent multi-hours on the phone with two generous and helpful
  169. sysops trying to debug the desqview problem with moderate progress.
  170. The cause is still unknown, but I have found that pkunzip is NOT
  171. the problem.  AViewCom locks up before getting to that point.
  172.  
  173. 05/25/91
  174.  
  175. I have found several systems that have successuflly run WildCat
  176. under DesqView with no problems, but other systems which will lock
  177. up every time when AViewCom shells out to pkunzip.  My system with
  178. a test copy of these programs works well.  The investigation as to
  179. the cause of this problem with some systems locking up is ongoing.
  180.  
  181. 04/21/91
  182.  
  183. The number one bug report currently is that AViewCom will lock-up
  184. the system when shelling out to pkunzip and running under DesqView,
  185. and WildCat.  I understand that with older versions of DesqView
  186. and WildCat this did not happen.  I am planning on investigating
  187. this problem further.
  188.  
  189. 09/28/90
  190.  
  191. AViewCom now performs dynamic disk swapping.  There are five
  192. modules within the program which are swapped out as they are used.
  193. This will reduce the memory usage some, but the major memory usage
  194. still remains with the archiver which AViewCom shells out to.  As a
  195. note, PKUNZIP requires 260K of memory!  Also, VIEW.OVL is no longer
  196. required.
  197.  
  198. 08/21/90
  199.  
  200. I have tested AViewCom v4.4e with DesqView v2.26 with direct screen
  201. writes enabled, and as far as I can tell (I'm not a DesqView
  202. user!), it works okay - AViewCom doesn't overwrite other screens
  203. when you're in other windows.  I have also added the PIF file which
  204. you should review and change as needed.
  205.  
  206. 07/04/90
  207.  
  208. Mustang has release v2.15.  I have had reports that the AVUSER
  209. functions is not working properly with the new version.  I will
  210. have this fixed with the next release which will also work under
  211. DeskView and multi-node systems.
  212.  
  213. 03/04/90
  214.  
  215. Mustang will soon be releasing a v2.15 which will create the CALLINFO.BBS
  216. file when spawning out to the arcviewer.  I believe this file is different
  217. from the one that aviewcom made but I don't know what yet.  AViewCom v4.5
  218. will be able to use it, and will properly function in the avuser mode.
  219. Sysops are cautioned on the use of the avuser function until this function
  220. is verified with the new version.
  221.  
  222. 01/01/90
  223.  
  224. I have incorported the functions of CALLINF2, AVSETUP, and AVUSER into
  225. AVIEWCOM.  These are accessed by command line switches beginning with
  226. a slash.  To invoke AVSETUP, type AVIEWCOM /S.  To invoke AVUSER, type
  227. AVIEWCOM /U.  To invoke CALLINF2, type AVIEWCOM /C.
  228.  
  229. 09/23/89
  230.  
  231. AViewCom will now update the user database to reflect: 1) total
  232. downloads, 2) total download kbytes, 3) daily downloads, and 4)
  233. daily download kbytes.  It does not update number of accesses for
  234. the files downloaded (USERFILE.DAT is the only file altered).
  235. The updating feature does not work with multi-node systems.
  236. AViewCom v3 will be updated for the ShareWare market and will not
  237. support WildCat v2.0.  AViewCom v4 will be updated for Registered
  238. users only.  Mustang is working on a WildCat version 3 which will
  239. eliminate the need for AVIEWCOM /C and AVIEWCOM /U.
  240.