CF>
  > This program will never be run on a LAN, so I don't see the problem with
  > it writing to itself.
CF>

JP>  The prohibition on writing to a running EXE is nothing to do with
JP>  LANs.  It's to do with the way that OS/2 demand loads the code of a
JP>  running application from its EXE.  In order that everything remains
JP>  consistent whilst the application is running, OS/2 requires that the
JP>  contents of the EXE file do not change.  Hence it holds the executable
JP>  open in deny write mode.

JP>  UNIX does the same thing, for the same reason.

CF>
  > For that matter, there lots of programs with cfg files that won't
  > run properly on LAN's.  The world doesn't revolve around LAN's.
CF>

JP>  Other people writing poor, stupid and shortsighted software is not an
JP>  excuse for your doing so.

JP>  Don't limit your users simply because you yourself don't use a
JP>  network, either.

Jon, 

Let him shoot himself in the foot if he wants to.  

To Carl Foreseter :

    Check out the August 94 issue of Dr. Dobbs. there is mention of an
undocumented OS/2 API called DosReplaceModule(). The prototype is :

APRET APIENTRY DosReplaceModule(PSZ pszOldModule, PSZ pszNewModule, 
                                PSZ pszBackupModule);

It is located at DOSCALLS.417. You will have to set up an IMPORT for it in your
program's .DEF file. 

"The contents of pszOldModule are cached by the system, the file is closed, and
a backup copy of the file, pszBackupModule is created for recovery purposes,
should the routine performing the module replacement fail. The new module
pszNewModule then takes the place of the original module on the disk."

This can be used on an .EXE file that is in use by the system. Happy hacking!



  > JdeBP <
JP>

___
 * MR/2 1.52 NR * Radioactive halibut will make fission chips.

--- WILDMAIL!/WC v4.00h