home *** CD-ROM | disk | FTP | other *** search
/ Media Share 9 / MEDIASHARE_09.ISO / bbs / aview65b.zip / WHATSUP.DOC < prev   
Text File  |  1994-01-26  |  10KB  |  235 lines

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