8 comments

[ 2.9 ms ] story [ 18.4 ms ] thread
Assuming you own all the executables in the project:

I would have compiled the main functionality into a DLL which exports a single function, and then invoked that function for the individual executables. This approach avoids the additional process and I'd expect the executables to be a bit smaller as well.

> It glues the strings together, calls CreateProcessW, waits for it to exit (WaitForSingleObject), retrieves the exit code (GetExitCodeProcess), and exits with the same status. (The stuff that comes for free with exec(3).)

So does Windows not support a unix-style exec where the new process replaces the old one?

The Windows C library appears to have exec, with the usual semantics:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/exec-...

How is that implemented?

Presumably they start a new process and then exit the current one. `CreateProcess`[0] can allow the new process to inherit handles, etc.

[0]: https://docs.microsoft.com/en-us/windows/win32/api/processth...

>Presumably they start a new process and then exit the current one

that's not exactly the same thing though. eg. if your parent process is waiting for you to exit, then creating a new process and then exiting will produce incorrect behavior. The same applies for anything that relies on pids.

I mean sure, it doesn't work exactly like Linux. It can't. Note there's nothing in the doc linked by twic that say these function maintain pids.

> Each _exec function loads and executes a new process. All _exec functions use the same operating-system function (CreateProcess).

I guess they could better emulate Linux using another layer of abstraction but I don't think they do. It is true that large parts of the C library in Windows is there only to emulate Unix like behaviour so as to make porting easier. But it's not meant to emulate Linux exactly (that's what WSL is for).

(comment deleted)