WinExec function (Windows)

Switch View :
ScriptFree
WinExec function

Applies to: desktop apps only

Runs the specified application.

Note  This function is provided only for compatibility with 16-bit Windows. Applications should use the CreateProcess function.

Syntax

UINT WINAPI WinExec(
  __in  LPCSTR lpCmdLine,
  __in  UINT uCmdShow
);

Parameters

lpCmdLine [in]

The command line (file name plus optional parameters) for the application to be executed. If the name of the executable file in the lpCmdLine parameter does not contain a directory path, the system searches for the executable file in this sequence:

  1. The directory from which the application loaded.
  2. The current directory.
  3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
  4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
  5. The directories listed in the PATH environment variable.
uCmdShow [in]

The display options. For a list of the acceptable values, see the description of the nCmdShow parameter of the ShowWindow function.

Return value

If the function succeeds, the return value is greater than 31.

If the function fails, the return value is one of the following error values.

Return code/valueDescription
0

The system is out of memory or resources.

ERROR_BAD_FORMAT

The .exe file is invalid.

ERROR_FILE_NOT_FOUND

The specified file was not found.

ERROR_PATH_NOT_FOUND

The specified path was not found.

 

Remarks

The WinExec function returns when the started process calls the GetMessage function or a time-out limit is reached. To avoid waiting for the time out delay, call the GetMessage function as soon as possible in any process started by a call to WinExec.

Security Remarks

The executable name is treated as the first white space-delimited string in lpCmdLine. If the executable or path name has a space in it, there is a risk that a different executable could be run because of the way the function parses spaces. The following example is dangerous because the function will attempt to run "Program.exe", if it exists, instead of "MyApp.exe".

WinExec("C:\\Program Files\\MyApp", ...)

If a malicious user were to create an application called "Program.exe" on a system, any program that incorrectly calls WinExec using the Program Files directory will run this application instead of the intended application.

To avoid this problem, use CreateProcess rather than WinExec. However, if you must use WinExec for legacy reasons, make sure the application name is enclosed in quotation marks as shown in the example below.

WinExec("\"C:\\Program Files\\MyApp.exe\" -L -S", ...)

Requirements

Minimum supported client

Windows XP

Minimum supported server

Windows Server 2003

Header

WinBase.h (include Windows.h)

Library

Kernel32.lib

DLL

Kernel32.dll

See also

CreateProcess

 

 

Send comments about this topic to Microsoft

Build date: 3/7/2012

Community Content

Jim Michaels
no substitute for WinExec
you can use ShellExec, but I'm sure it fails on windows 7 because someone (common problem) accidentally messed up their file associations and now can no longer execute anything.

I don't think there is a real substitute for WinExec which I think can fire off a process that does NOT become a child process.  show me some way of doing this, because the "recommended CreateProcess" does not do it.  I wouldn't take this function away.  one of the things I need to perform is to kill the windows 9x/me spooler, delete the job files, and fire off the spooler process again (it's not a service, but s simple program).  you can't do that from batch files.  if it were a child process, then as soon as my spooler flush program exits, the spooler dies too, because it's a child process!  there may be other OS's and projects that need this sort of functionality.

so don't take this function away if it does what I think it does.

Martin Richter
Applications should use the CreateProcess function OR ShellExecute!

Shouldn't be there a hint to ShellExecute(Ex). I think this interface is much easier to handle than the more cryptic CreateProcess.