paul marwick wrote in a message to Roy J. Tellason:

 pm>> If I knew completely, I might be able to avoid future 
 pm>> incidents... InspectA always did get upset at some things found 
 pm>> in FILES.BBS. 

 RJT> What things?  I don't recall any odd behavior of that sort here, 
 RJT> though I tend to use the dos version *way* more than the OS/2
 RJT> version.

 pm> A number of ASCII characters have been known to cause InpsectA 
 pm> problems. None of them should be in a FILES.BBS entry, but some 
 pm> of the entries that arrive here (especially in the games 
 pm> related areas) certainly do contain them.

That's really odd, I thought that it was a much better written program than
that...  And that behavior is a violation of something I read a while back,
written by P. J. Plauger,  to the effect that "no program should leave its
sanity at the mercy of its input"!

 RJT> And this was under OS/2?  Did a chkdsk find any bits of the old file
 RJT> around?

 pm> :-) I only run under OS/2... And no, CHKDSK found nothing - it 
 pm> was not a general system problem, just InspectA.

The info just disappeared?  Odd...

 pm>> David did fix the problem - the final beta that I have is much 
 pm>> better when it comes to large directories. Unfortunately, its 
 pm>> dangerous in other areas...

 RJT> Hm.  I did't know that there were other versions out there.

 pm> There problably aren't - I was betateting a new version when he 
 pm> pulled the plug on it.

What a shame,  really,  as I like the program a lot.

 pm>> Other bugs that affect my usage of InspectA - attempting to 
 pm>> examine a number of self-extracting archives causes InspectA to 
 pm>> abend, 

 RJT> I've never had a problem like that.

 pm> Hmm. It shouldn't be hard to find. As one example, the Netscape 
 pm> 2.02 archive from June 1997 (straight from IBM): os2en202.exe 
 pm> (4768313 16-08-97) 

 pm> If you place the cusor over this, press return, InspectA
 pm> will abend instantly. with a trap D:

 pm> 09-04-1999  11:25:34  SYS3175  PID 0669  TID 0001  Slot 0065
 pm> C:\USER\UTL\ISB\INSPECTP.EXE
 pm> c0000005
 pm> 0003561f
 pm> P1=00000000  P2=ffffffff  P3=XXXXXXXX  P4=XXXXXXXX
 pm> EAX=0000d07a  EBX=00009ab0  ECX=fe0741e1  EDX=17712087
 pm> ESI=0000fc2c  EDI=0000fffe
 pm> DS=003f  DSACC=00f3  DSLIM=0000fffd
 pm> ES=003f  ESACC=00f3  ESLIM=0000fffd
 pm> FS=150b  FSACC=00f3  FSLIM=00000030
 pm> GS=0000  GSACC=****  GSLIM=********
 pm> CS:EIP=001f:0000561f  CSACC=00fb  CSLIM=0000aab7
 pm> SS:ESP=003f:0000cc60  SSACC=00f3  SSLIM=0000fffd
 pm> EBP=0000cc66  FLG=00012a17

 pm> INSPECTP.EXE 0003:0000561f

 pm> It will do this under any version of OS/2, and on a number of 
 pm> other self-extracting archive files. The POPUPLOS.OS@ enty 
 pm> above is from the beta, not from the release InspectA, but the 
 pm> results are identical for either.

Ok,  let me see what I have on the OS/2 box that I can try this on...

I don't have that,  but there's a nets202.exe that's 3,813,751 bytes.  When I
hit  on that it comes back with "empty archive".   There's a
NETSCAPE.EXE that's 2,611,447 that dumped me into LIST rather than showing
archive contents (if that _is_ an archive,  it may just be the executable out
of the other one). Hm,  in netscape\download I have a number of files that are 
up over a meg,  and none of them do it (though I do get an error when I try to 
look at the *.dsk files).  Tried it on a whole bunch of stuff here just now
and except for that one "empty archive" message didn't have any behavior such
as you describe.

 pm>> using Insert to edit an existing FILES.BBS entry causes a 
 pm>> second entry to be generated rather than just editing the 
 pm>> existing entry, 

 RJT> Nor that one.

 pm> Its dead easy to reproduce. Find a file with a FILES.BBS 
 pm> listing. Use the insert key to open an edit window for the 
 pm> entry. Edit the entry. Then go look at the files.BBS "raw" -
 pm> you'll see that you have two entries for that file.

Never happened for me.

 RJT> I hit that one early on with the OS/2 version,  the first time I'd
 RJT> dealt with a partition that was all that big.  Under the dos/dv
 RJT> setup in this box I keep 'em small to avoid the cluster size issue
 RJT> to the extent possible.  It's a real irritation when it won't move
 RJT> or copy files because it insissts that there isn't enough room...

 pm> Should have been fixed ages ago (problem was known before David 
 pm> stopped development). Stil, its not the only filemanager with 
 pm> that problem.

Yeah,  well,  it's going to be a deciding factor for me if I've got to pick
out and learn a new product here...

 pm>> a number of characters in FILES.BBS will upset the InspectA 
 pm>> display, leaving spurious characters on unused parts of the 
 pm>> screen,

 RJT> I never had a problem with that,  but then mine are pretty 
 RJT> plain-vanilla for the most part anyhow.  It may be a good thing 
 RJT> that I don't just automatically use a FILE_ID.DIZ imported into 
 RJT> FILES.BBS automatically like some folks do. What characters 
 RJT> does it have a problem with?

 pm> A number of High ASCII characters. I normally use only standard 
 pm> characters, but too many of the files distributed through the 
 pm> various distribution netowrks have the full contents of 
 pm> FILE_ID.DIZ dumped into them as a description,m and those are 
 pm> not only often way too long, they also often contain 
 pm> non-printable characters.

That's one of the reasons I don't let the system import that stuff into
files.bbs on its own,  even though it's more work for me.  There are a number
of others.  Mostly relating to content...  

 pm>> it doesn't understand newer archive types (such as RAR 
 pm>> archives), 

 RJT> The inability to extend the archive list has also been a source 
 RJT> of irritation to me.  And there are a few in there that I have 
 RJT> never heard of or run into. But I haven't spent much time in 
 RJT> the config utility trying to rearrange that stuff...

 pm> It cannot be "rearanged" - since InspectA does not understand 
 pm> RAR (and a couple of other new formats), it is not able to do 
 pm> anything with them. All that can be done is to create a file 
 pm> association and call RAR when it hits a file with a .RAR 
 pm> extention. Not very satisfactory at all.

Yeah,  that's about what I've done on the dos box here.  And I'll probably end 
up writing a short batch file to convert those anyway,  so as to make stuff
more accessible to people...

 pm>> truncating long descriptions when copying files, etc.

 RJT> How long?  I have *something* in my setup (probably DLC,  my download
 RJT> counter utility) that truncates descriptions at 256 characters, 
 RJT> which is a real irritation at times.  I suspect that program because
 RJT> it's only files that have been downloaded that get that treatment...

 RJT> Maximus has,  if I'm remembering right,  a 1024-character limit in
 RJT> this,  so I'm not used to using *real* long descriptions.  Qedit
 RJT> can't seem to do more than 512 characters,  at least not the older
 RJT> version I'm using here,  anyhow.

 pm> InspectA will sometimes (and its not even consistent, 
 pm> unfortunately) truncate descriptions at 512 characters. Which 
 pm> mucks things up royally...

Since my editor won't go beyond that point I hadn't noticed.

 RJT> I was aware of the availability of that key,  but already had one
 RJT> .  Do you think that there is no possibility of source becoming
 RJT> available?

 pm> I would suspect none at all. Apart from the amount of 
 pm> bitterness that David seemed to feel over the whole subject 
 pm> (which I suspect was less than fully justified anyway), 
 pm> InspectA uses a number of custom libraries that David wrote 
 pm> himself. So source would have to include the libraries, and I 
 pm> suspect that there is little or no chance that he would release 
 pm> them.

Ah.

 RJT> I'm giving some serious thought to looking over the source code to
 RJT> midnight commander,  and seeing what I can do to it to make it more
 RJT> to my liking.  These people who write this annoyware stuff can all
 RJT> try and sell to each other or something (the term circle jerk comes
 RJT> to mind for some reason) and I'll go play elsewhere...

 pm> :-) If you have the skills, that might be the best option...

I used to hang out in C_ECHO,  ages ago.  Enough that I got invited to
moderate it twice (and turned it down twice :-).  It's been ages,  and I have
to get a handle on GNU,  the Unix Way Of Doing Things,  and assorted other
stuff,  but at least at this point I can look at some code and understand what 
I'm looking at to some extent.  I may just end up getting back into it,  I
don't know...

--- 
278/111
2433/225