Date   : Tue, 03 Apr 1984 03:40:00 MST (Tue)
From   : Keith Petersen <W8SDZ@Simtel20.ARPA>
Subject: NSWP202 buggy - removed from SIMTEL20

Numerous bug reports on NSWP202 have been received by various RCPM
operators - some are detailed below.  It has been removed from
SIMTEL20 and I recommend that you erase your copies.
--Keith

-----
Msg #1006 posted 03-23-84 at 06:19:19 by PICONET CP/M
To: IRV HOFF      About: nswp2 bug? (13 lines)
 
NSWP2 has this quirk that cost me some time.  If you have your BDOS set
up to make user 0 public and you try to copy or rename a file from user
0 to another user, only the first extent gets moved. Since no source is
at hand, all you can do until it gets fixed is avoid using NSWP2 to move
files from user 0 to another user while user 0 is public.  If anyone
knows of a version that has this fixed, please let me know (either
PICONET CP/M or RICHARD RELPH).
 
Other than this bug, the program has the really nice feature (for those
who make user 0 public) that it does not use the BDOS to find out what
files are members of the user area, which means that it will not show
user 0 files while in user 1.
Rich
..........
 
 
 
Msg #1024 posted 03-24-84 at 10:21:33 by JIM MCMURRY
To: ALL USERS     About: nswp202 (2 lines)
 
the dif between nswp201 and nswp202 is you cannot squeeze real small
files below 3 k, at least that is what dave rand says
..........
 
 
 
Msg #1075 posted 03-27-84 at 05:37:26 by RICHARD RELPH
To: IRV HOFF      About: nswp202 bug? (10 lines)
 
Thanks for passing along the info. I have another major gotcha. I don't
yet know enough about it to say what all the pertinent circumstances are
but when I tried mass copying from c0 to b0 (1 .def, 6 .com, 3 .ovl) the
result was that the .def file moved ok, but the .com and .ovl files
got truncated to 16k (I presume this to be the buffer size in NSWP202).
I entered NSWP202 from c3. I'll be doing more research when I can better
afford to lose files (as soon as I clear another cartridge). I'd like
to be able to contact those in the know directly. Should I call Dave or
is there someone else to go through?
Rich
..........
 
 
 
Msg #1088 posted 03-27-84 at 17:58:14 by BILL MEYER
To: IRV HOFF      About: nswp202 (21 lines)
 
Irv,
    Pulled down NSWP2, largely because of your comments on the board.
Found a bug right away!  On entry, Rand saves only the top entry of the
CP/M stack as his return point, not the CP/M stack pointer.  This is, of
course, enormously different, and makes the assumption that only the top
of stack was relevant at entry to the application.  As luck would have
it, my bank-switching system locks up tight due to this fault.  As this
is not a run-of-the-mill problem, I decided to call Rand about the prob-
lem.  What a waste of money!  I have never, in talking to author's of
public domain software, encountered a more arrogant, conceited individ-
ual.  He tells me that the fault is in my system, but nowhere do I find
a spec which guarantees that only the top entry of the stack need be
saved on entry to the application program.  I suspect that this approach
would cause problems when used from within programs like wordstar, with
the run command.  I believe this is the same symptom which I reported to
you on your one of your earlier programs, which you promptly chnaged for
me.  I know that this is the same problem as I reported to Frank Gaude'
on DISK7 and COMM7 where he used the same system you original developed
that Rand is apparently still using.  Thought you might want to pass it
along, I've given up...
                                Bill
..........
 
 
 
Message # (603-1198)? 1097
 
Msg #1097 posted 03-28-84 at 05:25:57 by RICHARD RELPH
To: IRV HOFF     About: NSWP202 bug? (12 lines)
 
To let you know what I have, I'm running a Big Board II with CP/M 2.23B
which has a built in 1793 for my floppies (1 Persci 277) and a built in
SASI I/F for my 2 IOMEGA 10Mby cartridge drives. I am using 9 1k sectors
on the Persci for a total per 8"SSDD disk of 670k (after directories).
The Persci is drives A and B and the IOMEGA is Drive C (right now the
BIOS cannot handle the other IOMEGA or even ther rest of the first).  I
was trying to copy from C to B, which implies that (other than picking a
bit) the hardware is probably ruled out as well as anything in the BIOS
past the section that determines which driver to call (which is first as
you would expect).  Thanks for taking the time to look at it.  I, too,
will be trying some more experiments here and will let you know.
Rich
..........