Hi! Ken,

On Thu, 13 Feb 03, you wrote to me:

 KH>> Great! Now, all we have to do is rediscover what it was that you
 KH>> did, back then. :)
 PQ>> Oooh, I'm talkin' about Win 3.0/3.1 - about 10 years ago.  :)
 PQ>> We ran an IBM 3270 teminal emulator that gave us that "error" 
 PQ>> message. I recall now... we used a DOS printer spooler, to
 PQ>> capture output from the mainframe to a disk file, which ran
 PQ>> as a TSR.
 KH> The TSR was the culprit, right?

:)  Here, take the cigar...

 PQ>> If it were me, I'd start checking the versions of COMMAND.COM
[ ...trim... ]
 KH> the PATH, in this config). To double check, I renamed the C:\DOS
 KH> version, and it didn't make a difference. FWIW, the problem also
 KH> occurs, intermittently, on my Win98SE system.

Curiouser and curiouser.  BTW, I'm running Win95(b) here, with Windows
being executed from the AutoExec.Bat; not from the MSDOS.Sys setting.

 KH> If you've got the time (and the inclination to run DOS AV programs),
 KH> maybe you can solve this, Paul. Here's the heart of VS.BAT:
 KH> c:\fprot\f-prot.exe %1 /archive /beep /collect /dumb /packed %2 %3 %4
 KH> %5 %6 if errorlevel 1 pause

I use F-PROT all the time.  Don't know what this sucker is, though...

 KH> c:\sc\scanpm %1 /all /allole /analyze /beep /mime /sub /unzip %2 %3
 KH> %4 %5 %6 if errorlevel 1 pause

 KH> I'd like to be able to run it from the command line, without
 KH> terminating the DOS session. I also want be able to execute it from a 
 KH> GUI right- click, via a registry association for 'Folder' (with 
[ ...trim... ]
 KH> to distinguish between the two methods of execution; you may want to
 KH> come up with something better.

This is either a complex method for doing something real simple, or, I'm
getting lazy in the way I do things.  Probably the latter.  As a rule, all
my downloads go to _1_ directory, then I run F-PROT from a Start menu icon
(.Pif) and go through the menu options to scan that directory.

I can do the same from a DOS boot-up (with network support) from any PC,
from the command-line, since the F-PROT directory is on their PATH (only 1
machine has F-PROT 'installed').

After virus scanning, I then manipulate archives and their contents with
Windows Commander.

 KH> I have it all working, but it took Charles Jennings' suggestion to
 KH> use KPUSH 3 CR 3 to ensure termination. Prior to that, I discovered 
 KH> that right-click-running it on a 'system' folder ('Printers', etc.) 
 KH> was a better test than doing the same on a 'real' folder'; YMMV.

Whoosh!  Over my head.  :)

 KH> Here's where the plot thickens. I made a temporary VS.BAT, for
 KH> testing purposes, that ran MEM/D/P, then DEBUG; and it wouldn't 
 KH> terminate, either (?).

It probably hung on the "/P".[giggle]

 KH> MEM's output did contain something interesting, though:
 KH> 00600                 96    (0K)  COMMAND      Data
 KH> 00606                272    (0K)  MEM          Environment
 KH> 00617             90,400   (88K)  MEM          Program
 KH> Here's what a 'normal' DOS window looks like, on this machine:
 KH> 00600                304    (0K)  MEM          Environment
 KH> 00613             90,400   (88K)  MEM          Program

That's different.  (Stating the obvious, I know.)  I never could count in
hex, having enough trouble with base-10.  Here's a dump from a DOS session
on this machine:

=== begin MEM_DUMP.TXT ===
[ ... ]
   003A9                 80    (0K)  MSDOS        System Program
   003AE                 80    (0K)  COMMAND      Data
   003B3                256    (0K)  WIN          Environment
   003C3              2,032    (2K)  WIN          Program
   00442                 48    (0K)  vmm32        Data
   00445              2,992    (3K)  vmm32        Program
   00500                288    (0K)  COMMAND      Data
   00512              5,536    (5K)  COMMAND      Program
   0066C              3,104    (3K)  COMMAND      Environment
   0072E                304    (0K)  MEM          Environment
   00741             90,464   (88K)  MEM          Program
   01D57            531,072  (519K)  MSDOS        -- Free --
   09EFF              4,000    (4K)  IO           System Data
   09FF9                 96    (0K)  SD           Data
[ ... ]
=== end MEM_DUMP.TXT ===

Did that help any?  Most machines would probably produce similar but
different variations on the basic theme.

 KH> Aside from a few bytes less for the prompt, (I add to mine, usually)

Same here, with ANSI: either FG/BG colours or a date/time combo.  Depends.

 KH> I also discovered that "windir" wasn't being set, in VS.BAT's
 KH> environment. I tried setting it explicitly, in the .BAT, but it
 KH> didn't help. Is it possible that "Data" (which doesn't exist, in a 
 KH> 'normal' DOS window) is being overwritten, but only intermittently?

Not having %windir% set is a fascinating side-effect.  I dunno what's going
on, but it's possibly a clue to something (basic) in your config, or
perhaps the method of execution you're using (right-clicking...registry
association).

 KH> The above would also appear to confirm that the problem, in this
 KH> case, is not being caused by the execution of Protected Mode
 KH> software.

More likely you're at the mercy of the software author.  There's
programmers and there's good programmers...

Cheers,
Paul.

--- Radius/W32 4.009-02.01.03/RC10