Looking for an equivalent of the Unix "exec" shell command under Windows ?

[for.fun]

Hi everybody,


Under Unix, when a command is started with the "exec", the command is
executed in place of the shell and no new process is created.

I would like to get the same behaviour under Windows.

For example, I want to execute a command from a Windows command shell
(.cmd) without creating a new process. Consequently, the shell code
with be substituted by the command code and no more process will be
created.

I am not looking for an exact port of the Unix "exec" command but only
a command which has a similar behaviour.


Thanks in advance for your help.

 

[frodo]

start /wait

 

[for.fun]

(e-mail address removed) a écrit :

start /wait

In facts, "start /wait" only makes the command shell wait for the
termination of the child process. A new child process is created so it
does not solve my problem.

I copied/pasted the functions prototype from the MSDN ("execv" is a
standard C run-time library routine which also exists on Unix systems)


Prototype:

intptr_t _execv(const char *cmdname, const char *const *argv);


I got the following description from the Unix man pages (clearer than
the MSDN description) :

"Each of the functions in the exec family replaces the current
process image with a new process image. The new image is
constructed from a regular, executable file called the new process
image file. This file is either an executable object file or a file of
data for an interpreter. There is no return from a successful call
to one of these functions because the calling process image is overlaid
by the new process image."


Because "execv" is implemented under Windows, I suppose it is possible
to have an exec-based commands that start a command without creating a
new process.


=> Do you know if an "exec" shell command was already developped by
anyone ?

 

[for.fun]

Perhaps I said something wrong.


The MSDN says this about the "_execv" function :

"_execv, _wexecv Execute new process with argument array "


Does it mean that "exec" will execute the code from the current process
(the process which called "_execv" function) or will it create a new
process for this ?

In order to check this, I wrote a small C program which simply open a
"test.txt" file with the "notepad.exe" Windows application.
I use "_execl" which has the same behavior as "_execv" :

_execl("C:\\WINNT\\System32\\notepad.exe", "test.txt", NULL);


The "_execl" calling application open the "notepad.exe" in a new
process before closing itself (Notepad stays opened)

It seems that the Windows "exec" does not behave as the Unix "exec"
since Windows always create a new process.


Can anyone confirm that and tell me a way to do a Unix exec-like ?

 

[David Candy]

If you want to ask about unix go to a unix group. If you want to ask about C go to a C group. What you suggest for windows is stupid. Windows is both a windows based OS (meaning that all interactions between the OS and programs is via the program's window) and a process based OS. The process is the basic unit. There is nothing stopping your propgram loading an exe, doing the fixups, and jumping to the entry point. However it is still the first program's process.

Perhaps you need to research job objects. Any number of processes can join a job. Terminating the job terminates all attached processes.

 

[for.fun]

David Candy a écrit :

If you want to ask about unix go to a unix group.

I you read the subject of my post, you will see that I ask about
Windows.

If you want to ask about C go to a C group.

The C sample was just intended to explain the "exec" function behavior
and to show that Windows also had the "exec" feature.

What you suggest for windows is stupid.

I am not suggesting anything.
I am just looking for an equivalent of "exec" under Windows.

Windows is both a windows based OS (meaning that all interactions betweenthe OS and programs is via the program's window) and a process based OS.

The windows based IHM is built over a multithreaded OS like Unix OS (it
can be compared to CDE interface under Unix)
So both OS can be compared.

The process is the basic unit.

Not correct. The thread is the basic unit.

There is nothing stopping your propgram loading an exe, doing the fixups,and jumping to the entry point.
However it is still the first program's process.

I think you misunderstood what I was asking for.

Perhaps you need to research job objects. Any number of processes can join a job. Terminating the job terminates all attached processes.

In facts, I have to run a "java.exe" from a CMD shell with SrvAny using
the Windows service manager.
The CMD shell create a child "java.exe" process.
The "NET STOP" command will stop the parent CMD shell and not the
"java.exe" process.
That is why I need "exec".


Anyway, it does not matter, I started another thread about SrvAny in
this forum.

 

[David Candy]

What happens is exactly what one expects to happen. Windows had processes before threads were invented, threads are sub units of process. Most taxes are paid on process creation. The whole point of windows is processes are independent from each other.

--
--------------------------------------------------------------------------------------------------
How to lose a war in Iraq
http://webdiary.com.au/cms/?q=node/1335#comment-48641
=================================================

If you want to ask about unix go to a unix group.

I you read the subject of my post, you will see that I ask about
Windows.

If you want to ask about C go to a C group.

The C sample was just intended to explain the "exec" function behavior
and to show that Windows also had the "exec" feature.

What you suggest for windows is stupid.

I am not suggesting anything.
I am just looking for an equivalent of "exec" under Windows.

Windows is both a windows based OS (meaning that all interactions between the OS and programs is via the program's window) and a process based OS.

The windows based IHM is built over a multithreaded OS like Unix OS (it
can be compared to CDE interface under Unix)
So both OS can be compared.

The process is the basic unit.

Not correct. The thread is the basic unit.

There is nothing stopping your propgram loading an exe, doing the fixups, and jumping to the entry point.
However it is still the first program's process.

I think you misunderstood what I was asking for.

Perhaps you need to research job objects. Any number of processes can join a job. Terminating the job terminates all attached processes.

In facts, I have to run a "java.exe" from a CMD shell with SrvAny using
the Windows service manager.
The CMD shell create a child "java.exe" process.
The "NET STOP" command will stop the parent CMD shell and not the
"java.exe" process.
That is why I need "exec".


Anyway, it does not matter, I started another thread about SrvAny in
this forum.

 

[for.fun]

David Candy a écrit :

Thanks for the trick about the Windows jobs.

I wrote a program which join my processes into a single job.
I configured "SrvAny.exe" to start my join process program.

Unfortunately, "SrvAny.exe" do a "TerminateProcess()" on the join
program. Consequently, termination handlers (WM_CLOSE message catching)
are not called so the processes are not terminated.

 

[David Candy]

Why are you using a batch file (or cmd). Why can't you write your program as a service.

--
--------------------------------------------------------------------------------------------------
How to lose a war in Iraq
http://webdiary.com.au/cms/?q=node/1335#comment-48641
=================================================

Thanks for the trick about the Windows jobs.

I wrote a program which join my processes into a single job.
I configured "SrvAny.exe" to start my join process program.

Unfortunately, "SrvAny.exe" do a "TerminateProcess()" on the join
program. Consequently, termination handlers (WM_CLOSE message catching)
are not called so the processes are not terminated.

 

[for.fun]

David Candy a écrit :

Why are you using a batch file (or cmd). Why can't you write your programas a service.

Good question !

The problem is I can't.
The process I have to run as a service is a Java process ran by the
Java machine "java.exe". Writing the program as a service would mean
re-writing the Java machine as a service.
Moreover, I need the CMD batch to set the environment (PATH, CLASSPATH
....) and redirect the "java.eve" standard error and output into log
files.


SrvAny seems to work like this :

1/ SrvAny listen to service messages through its service control
handler.

2/ When SrvAny receive a NET STOP message, it calls TerminateProcess()
on the started process. As far as I am concerned, this is CMD.EXE.

=> Only CMD.EXE is terminated because "java.exe" is a child of CMD
which does not receive any message from CMD.EXE (because it is
destroyed by TerminateProcess(), no close message is sent to
"java.exe")

That's why implementing jobs does not solve my problem.

 

[David Candy]

Write your own cmd. You need to implement CreateProcess and there are functions for you to do your own redirection. Search msdn for sample code using the phrase
"Creating a Child Process with Redirected Input and Output"

You can make your own environment and give it to CreateProcess to use.

--
--------------------------------------------------------------------------------------------------
How to lose a war in Iraq
http://webdiary.com.au/cms/?q=node/1335#comment-48641
=================================================

Why are you using a batch file (or cmd). Why can't you write your program as a service.

Good question !

The problem is I can't.
The process I have to run as a service is a Java process ran by the
Java machine "java.exe". Writing the program as a service would mean
re-writing the Java machine as a service.
Moreover, I need the CMD batch to set the environment (PATH, CLASSPATH
....) and redirect the "java.eve" standard error and output into log
files.


SrvAny seems to work like this :

1/ SrvAny listen to service messages through its service control
handler.

2/ When SrvAny receive a NET STOP message, it calls TerminateProcess()
on the started process. As far as I am concerned, this is CMD.EXE.

=> Only CMD.EXE is terminated because "java.exe" is a child of CMD
which does not receive any message from CMD.EXE (because it is
destroyed by TerminateProcess(), no close message is sent to
"java.exe")

That's why implementing jobs does not solve my problem.

 

[for.fun]

David Candy a écrit :

Write your own cmd. You need to implement CreateProcess and there are functions for you to do your own redirection. Search msdn for sample code using the phrase
"Creating a Child Process with Redirected Input and Output"

You can make your own environment and give it to CreateProcess to use.

Thanks for the trick but I already tried it.
I wrote a process which simply do a "CreateProcess()" instead of the
CMD calling my process. In facts, "CreateProcess()" creates a child
process the same way "cmd.exe" creates the process specified into the
CMD script.

Consequently, the behaviour is the same : the "CreateProcess()"
application is terminated by SrvAny (using TerminateProcess()) and my
child process never receive any signal since its parent because it was
killed by force.

The issue would be to rewrite a SrvAny which send a WM_CLOSE message to
the process in order to close all the chain properly but I have no time
for this.

I think I am going to write a specific Service Kill command which look
in the registry service table and stop the matching service instead of
a NET STOP.