v2.0

Changes from previous version:

Add support for identifying when an application switches execution to another process

By @andshrew in #6

There are some applications that subsequently launch another executable, or perform some other action, which results in the originally launched application being detected as no longer being loaded; and so RunExit would attempt exit Windows while that application was still actually running.

This release includes significant changes to how RunExit determines if the launched application is still running. It will now iterate through the currently loaded modules, and attempt to match loaded modules with that of the launched application based on the paths matching (ie. launching C:\SC2K4WIN\SC2000W.EXE would match with modules containing C:\SC2K4WIN in the path).

If a related module is found, then RunExit will continue waiting until all related modules are unloaded before exiting Windows.

See Related Module Matching for further details and additional configuration options which are available.

This change can be reverted by starting RunExit with the /legacy parameter.

Add support for generating a log file

By @andshrew in #6

Starting RunExit with the /log parameter will create runexit.log at the root of the default drive (eg. c:\runexit.log).

If using multiple parameters this option should be the first supplied in order to capture the most amount of information in the output.

runexit.log is overwritten each time that RunExit is run with the /log parameter.

Example

win C:\runexit\runexit.exe /log c:\mps\gpm\gpm.exe

Full Changelog: v1.5...v2.0

v1.5

Changes from previous version:

Override the working directory of the application

By @lexarvn in #4

There are instances where an application may require a different working directory to that of where it's executable is stored. It is now possible to set this using the new /pwd=[path] parameter on RUNEXIT.EXE.

Example

Run application D:\WIN31\RBJR.EXE with the working directory as D:\RESOURCE.

win C:\runexit\runexit.exe /pwd=D:\resource D:\win31\rbjr.EXE

Full Changelog: v1.4...v1.5

v1.4

Changes from previous version:

Delay the launch of the target application by up to 30 seconds

Option to delay by @lexarvn in #3

There can be instances where an application launched immediately after Windows has started does not work properly, for example because the audio device has not had time to initialise properly. It is now possible to delay the launch of the target application by a number of seconds (up to a maximum of 30) using the new /delay=[seconds] parameter on RUNEXIT.EXE.

Example

Run application C:\CASTLE\CASTLE.EXE with a 5 second delay before launch.

win C:\runexit\runexit.exe /delay=5 c:\castle\castle.exe

Fixes a bug causing the ~10 seconds of exit Windows attempts to fail

Added in v1.2, the feature was supposed to automatically retry the exit from Windows for up to 10 seconds if the request to exit had failed. GetTickCount (the number of ms the OS has been up) was being stored as a Word instead of a LongInt, resulting in this not functioning properly ~66 seconds after the OS had been running.

New Contributors

• @lexarvn made their first contribution in #3

Full Changelog: v1.3...v1.4

v1.3

Changes from previous version:

The state of the application window can now be set on startup (ie. launch the application maximized or minimized)

Add /show=N parameter to allow override of SW_SHOWNORMAL in application launch by @greg-kennedy in #2

The default application startup SW_SHOWNORMAL can be overridden to a different value by passing a /show=[number] parameter to RUNEXIT.EXE, before the application path. This allows starting the application minimized, maximized, or in the "background" (not activated). A list of valid values are here.

Example

Run application C:\WEP\JEZZBALL.EXE in a maximized window.

win C:\runexit\runexit.exe /show=3 c:\wep\jezzball.exe

New Contributors

• @greg-kennedy made their first contribution in #2

Full Changelog: v1.2...v1.3

v1.2

Changes from previous version:

• The trailing \ is removed from the application directory path
  When parsing the application path to determine what the working directory should be set to, the original version would include the trailing \ within the path and pass that through to ShellExecute.
  eg. C:\MPS\GPM\GPM.EXE would set the working directory as C:\MPS\GPM\
  While this didn't seem to be a problem when using DOSBox 0.74, after I switched to using DOSBox-X the application was no longer launched. Debugging this I found that ShellExecute was returning a File not found error.
  This version now sets the working directory without the trailing \, and works in both variants of DOSBox that I have used:
  C:\MPS\GPM\GPM.EXE now sets the working directory as C:\MPS\GPM

• Exit Windows will keep retrying for ~10 seconds
  I found that, depending on the application being launched, the exit from Windows after the application had finished would intermittently (but consistently) fail.
  The ExitWindows API doesn't really give any useful information as to why an exit request failed, so this version of the application will keep trying to exit Windows for ~10 seconds after the application has finished. If it still cannot exit Windows then it will prompt the user that it has failed.
  I suspect the issue was just a matter of timing, as the exit from Windows still happens almost instantly following this change (it just actually happens now).

• ShellExecute error codes are now displayed
  If ShellExecute fails to run the application, then a message box is now displayed along with the error code. A list of error codes are here.

v1.1

This tag contains the original source code of the version of RunExit that this repository has been forked from (original release date 26th May 2013).

https://www.shdon.com/files/runexit.src.zip

Redistributed here with the permission of Steven Don.