We've been around on this before.  Empirically, DOS Based windows use
WinOldAp as the virtual machine interface for console applications.
WinOldAp invokes conagent to do non-file related work for the application
that it doesn't do.  Conagent doesn't handle files at all.  When you use
conagent, closing the SETI CLI for any reason will leave the lock.sah file
opened in exclusive mode, which prevents the CLI from restarting until you
reboot.  This is definitely not good.  PIF files provide additional
instructions to WinOldAp about the environment in which to run the console
application.  Windows NT and its descendents have a _default.pif file in
%systemroot% and it includes the "Close on Exit" option checked by default.
Fortunately, NT doesn't use PIF files for any Windows program (16 or 32
bits) - just for DOS applications.

As to running _default.pif in a folder other than %systemroot% (c:\windows),
I don't know if that will work or not.  I said to copy _default.pif to the
folder with the CLI and rename the pif file to match the CLI.  This will
make the PIF file specific to the client.  Make sure "Close on Exit" is
checked.

You are correct that the real problem with DOS programs is that they don't
listen to the WM_CLOSE message that Windows ships to all programs when it's
shutting down.  However, Win32 Console programs can detect and respond to
WM_CLOSE messages - I know because I wrote a test program to test this while
writing SETI Driver.  I believe from my testing that the SETI CLI does
listen for and handle the WM_CLOSE message on NT based systems, but without
the source code, I can't say for sure.

Unfortunately, Microsoft didn't implement Win32 Console Application support
properly in Win9x and instead chose to implement support for this class of
software with WinOldAp, leading to the widely known system shutdown problems
with the CLI.  The only two methods to avoid them are with a PIF file
(documented) and with conagent (undocumented).

Mike.


"David Woolley" <david@djwhome.demon.co.uk> wrote in message
news:T1085817003@djwhome.demon.co.uk...

Message-ID: <0GStc.14321$Tn6.2113@newsread1.news.pas.earthlink.net>
From: "Michael D. Ober" <obermd.@.alum.mit.edu.nospam>

Conagent is an undocumented "helper" program that DOS Based Windows

versions

(95, 98, and ME) use to interface Windows 32-bit command line programs,
Windows 16 bit (Windows 3.x) and DOS applications to the underlying OS.
However, it doesn't handle files properly.  To handle files properly,

That's not true.  The problem is that console mode programs and DOS
box programs don't listen for Windows messages, so they don't know that
the window is being closed until it is too late for them to clean up.
Whilst cleaning up can involve closing files, it can also involve writing
out cached data, etc. (e.g., a hypothetical SETI@Home client could respond
to a Windows close by writing out the state file), and more importantly,
it can make sure that it doesn't stop halfway through writing something
to a file (the S@H clients can, occasionally, lose all their work in
a session because a file is corrupted by being half written, although
some code was added to include the oufile position in the status file to
minimise this problem - this may only be a problem in the CLI version,
as the GUI version does respond to Windows messages and ought not to
see the close request when halfway through writing to files).

including the shutdown problem (SETI doesn't close on shutdown),

download

the default.zip file from my SETI Driver site.  Unzip this file into

This doesn't fix the underlying problem, it simply lies to the operating
system that all DOS box applications are safe to be stopped abruptly,

without

actually making them safe.  (There is actually no safe option for
shutting down the S@H client.)

c:\Windows and reboot.  This will fix the shutdown issue in a fully
documented and MS supported method.

I don't believe putting _default.pif in an application directory is
documented, although it is likely to be safer than putting it in the
Windows system directory, if it works, as it will limit the damage to
the S@H client, which has no options for a clean shutdown, anyway.
Also, if .pif were supposed to be supported for Win32 console mode
programs, you would be able to create an application specific .pif
file using the attributes menu on the explorer, etc., icon.  (I'd
accept that MS maybe forgot that this particular PIF attribute is
relevant to Win32 console mode programs, as well as DOS programs.)

Whilst the solution probably works, it should not be presented as
a completely clean solution, and should be presented as one that
suppresses a symptom, rather than fixing a cause.  It should also be
made clear that it can have undesirable side effects on all non-GUI
programs; it is changing a safe, if inconvenient default, into an
unsafe one.  For nearly all SETI@Home users, it will not cause a
problem, but not everyone just uses S@H.