I've read in a couple of places that ShellExecute() and ShellExecuteEx() calls CreateProcess() internally, is this true? is it documented somewhere in MSDN?
Yes, ShellExecuteEx calls CreateProcess internally, as you can easily show by setting a breakpoint on CreateProcess and then making a call to ShellExecuteEx:
Related
I need to execute another application and I'm wondering if there's a reason why I should use WinExec instead of ShellExecute or vice versa.
Which are differences between two methods? Is there one that should be preferred?
WinExec is long deprecated and retained only for backwards compatibility reasons. It is used to start executables. Don't use it, due to its deprecation. As stated in the documentation:
This function is provided only for compatibility with 16-bit Windows. Applications should use the CreateProcess function.
ShellExecute is not deprecated, but also should not be used since it cannot report errors properly.
Use ShellExecuteEx to execute shell verbs.
If you wish to create a process, and you know the executable file name, use CreateProcess. Unless you need to execute elevated in which case you need ShellExecuteEx with the runas verb.
I want to know how the mechanism of debugger injection works. Why is "Image File Execution Options" so special?
I have two guesses.
CreateProcess will call an internal function that checks against the list of registry keys. If it is found, then it manipulates the arguments and calls the debugger exe instead.
There is some other service listening for CreateProcess calls and intercepts them. It kills the original call or message (if createprocess is a message or message-like), then it runs the new process as if the original caller called it.
My desire is to verify and update components before an application starts. I like the IFEO "feature" but i need to run the original process after the verification step so I need a way to run it without recursing into the updater. I hope that by learning more about the injection system I can get this system working.
This article explains how it works.
In Windows XP and 2003 the user-mode CreateProcess code reads the registry and, if required, launches the debugger instead.
In more recent versions of Windows this functionality has moved into kernel mode.
But neither case seems to involve a general interception mechanism for CreateProcess.
If you use CreateProcess, it only works on .exe's, apparently. What's the best way to make this work with other executable file types?
The best we have so far is to prepend cmd /c to such cases. Is that really the correct approach?
Batch files aren't technically executable files, they are just registered to open with cmd. As you mention that you need the ability to manipulate I/O handles, your best bet is indeed to use CreateProcess with cmd /c.
In POSIX, there is the fork() function to create a sub-process. How can I achieve fork()'s functionality in Windows?
There is no direct equivalent of fork() on Windows.
CreateProcess() is the native function that can be used to create a new process (but, again, the semantics are rather different to fork()'s).
To put this another way, on Unix it is possible for a process to cheaply create a clone of itself. There is no inexpensive way to do this on Windows.
If you don't care about the cloning aspect of fork(), then CreateProcess() should do just fine.
What is counterpart of SIGKILL(in POSIX) in WIN32. VS cannot recognize SIGKILL.
API function TerminateProcess is probably closest. SIGKILL is special anyway in POSIX and not really a signal. You need to open the process handle with OpenProcess and close it afterwards with CloseHandle.