I'm new to Windows system programming and I'm trying to learn the CreateProcess() function.
I know that it's possible to run a new process, for instance, notepad.exe or cmd.exe by the calling program by giving the name (notepad or cmd.exe) as parameter to the CreateProcess() function in the calling program.
What is the use of doing that, and could you explain any real world application for that?
Can I use this create process function to clone itself and do something in parallel?
What is the use of doing that, and could you explain any real world application for that?
CreateProcess is the way to create new processes on Windows. Obvious examples of its use would be for the shell to start new applications. Or for the command line interpreter to execute external commands.
Can I use this create process function to clone itself and do something in parallel?
No. Windows processes don't use the *nix fork idiom. There is no analogue in Windows to forking.
Can I use this create process function to clone itself and do something in parallel?
Not so much a clone, no. But the calling app can spawn a separate instance of itself, by specify its own filename, possibly with command-line parameter(s) to tell the spawned process what to do. So in that regard, yes, you can have multiple instances of your app running in parallel.
Related
I have a Windows program -- a vendor-provided benchmark utility -- that launches an existing game on my system using a set of launch options. I'd like to figure out what those launch options are. Is there any way to detect how the benchmark utility is launching the game?
More generally, is there some tool I can use to detect when and how one process launches another process on Windows?
As I was faced with the same problem, I figured out a simple, yet for my needs great solution.
I exchanged the called program with a simple custom-written c-program which prints all passed arguments into a logfile.
I am working on a project, where I need to execute multiple unix script from PHP environment. Could this be possible to open a single unix shell and execute all the unix scripts.
Currently im using shell_exec for each of the scripts execution. This makes the application slow, as each time shell_exec,a new shell is being opened and the script is executed.
Thanks in Advance,
No, the underlying shell is not accessible.
You could try few things:
Optimise the scripts so you have to do fewer execs. Pipe them or something like that
I am not sure if it will work but you should be able to start a bash process and send commands to it (see proc_open). This way you could be able to manually and reuse the shell. But I imagine it will be a nightmare, especially in parsing the responses from the scripts (if you need that).
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.
I would like to run a shell script from my cocoa app when clicking on a button. I can easily use the system() call to do that, but that's not all i need. I need the app to close as soon as it calls the script, or even before it calls the script. Basically the script should take a few seconds to run so i need the app to close by that time. The reason i need this is because i'm writing a simple application that puts the mac to sleep, but before that it does lots of cleaning up via a shell script and i basically don't want this app to be open when i brind the system back from sleep.
Would using a fork or something like that do the job or do i need some special magic to do this?
Thank you
If you're in Cocoa, you'll want to use NSTask. If your script needs admin privileges, there's always STPrivilegedTask.
You can use popen() instead of system(). The init process should inherit ownership of the script you run once your application exits. You could also fork/exec, but popen will be simpler as its semantics are much closer to that of system().
In Windows -- and probably Unix for that matter -- using the chdir() function in a (32-bit) program doesn't change the directory when the program exits. (It does in a 16-bit Windows program.)
Does anybody know how to do that in a Windows 32-bit program?
Uhm... IMHO it's exactly one of the things that the OS must guarantee not to happen. The current dir is a per-process property, a child process usually inherits it from the parent process, but the reverse should not happen (and it doesn't).
To obtain what you want, the parent could actively watch some information (message, file, shared memory...) in which the child process stores the new directory, and then call chdir() with the new value.
As far as I know, Windows' cmd.exe doesn't have any mechanism like that.
Actually, by using code injection techniques (e.g. CreateRemoteThread) on the parent process it could be possible to force it to do something unexpected, but it's a very dirty trick, not at all good neither general.
Win16 was different: there was a single "msdos" state for all the programs, but it was a limitation, not a feature.
It sounds like you're asking one process (your Win32 program) to change the CWD of another process (your shell). As far as I know, this is impossible without the latter process providing an API for such a purpose. The nearest I can come to any sort of reference for this assertion, however, is the following quote from MSDN:
A parent process can directly alter the environment variables of a child process during process creation. This is the only situation when a process can directly change the environment settings of another process.
Well yeah it's true the popular API calls to change directory change it for the process. ... BUT ...
(1.) 16-bit windows programs can change the global directory; probably because they run in the same process as the command.com thing. That's what I've been happily using for years; I assume XP somehow emulates this? ... But now Windows 7 64-bit won't run 16-bit programs anymore! (?)
(2.) Both Windows and Unix "cd" commands can of course change directories for the calling process -- presumably because they are built-in commands of the command shell. But successor Windows shells manage to accomplish this, or at least I hope PowerShell can do that. All built-ins?
(3.) The way I've wound-up doing it is modifying my programs that used to call the API to simply emit "cd \dst\directory" to stdout, then in a procedure do
chdirprogram >t~.bat
call T~.bat
Which works great. And of course the usual point of a change-directory program is to provide the functionality in a batch procedure with a computed destination. Which of course you can do in Unix with Bash etc. variables, but not in Windows batch files, although maybe (?) in the numerous successor Windows procedure things, which I don't want to use. ... Since this functionality is obviously useful, I was hoping someone knew of a sneaky Windows call what'd do it. The explanation that it's somehow wrong for a process to change the directory for a calling process is one of those bogus, "you're not supposed to do that and I won't tell you why" excuses. ... But I guess I'll just stick to my pitiful little batch files.
Are you talking about the SetCurrentDirectory function of Windows API? The article says that the function "changes the current directory for the current process". In for instance Delphi, there is a function ChDir that actually calls this API function.