5 ms·

This is not enough of an explanation as these things are still possible with CreateProcess. I do remember reading the real explanation -- it was easier to impl

by R0b0t1 6y ago

This is not enough of an explanation as these things are still possible with CreateProcess. I do remember reading the real explanation -- it was easier to implement fork. That's it.

bollu 6y ago
I'd like a reference for this explanation :)
saurik 6y ago
These things are possible with APIs like CreateProcess or posix_spawn, but involve the API ending up with a million little customizable parameters in the attempt to simulate all of the behaviors that can trivially be implemented if you just support "let me run some code in the target process before I replace its memory"... which is like, exactly why "easier to implement" sort of means: something is often easier to implement if it is a single universal and general primitive that forms an elegant solution to a wide set of problems rather than being a myriad collection of hacks for various use cases. As an API--particularly on systems with copy-on-write pages--fork is amazing.
- deleted 6y ago
  [deleted]
pjc50 6y ago
Running code in the target process space before the target executable is loaded is not possible with CreateProcess. Configuration of the target process has to be done by the operating system, via an ever-growing list of attributes you can pack into STARTUPINFOEX. https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute https://docs.microsoft.com/en-us/windows/win32/api/processth... UNIX fork/exec is also significantly faster than CreateProcess, but I'm not sure how much of that is necessary rather than contingent, or results of an ever growing list of "security" programs insisting on a veto. https://stackoverflow.com/questions/47845/why-is-creating-a-new-process-more-expensive-on-windows-than-linux https://stackoverflow.com/questions/47845/why-is-creating-a-... Fork+IPC architecture - effectively multithreading but where the processes don't automatically share memory and can crash separately - also requires fork(). However this has very much fallen out of fashion. () I suppose you can emulate fork by calling CreateProcess with an empty executable and CREATE_SUSPENDED, then use various debug APIs to overwrite its memory map with your own, but this is very messy.
- R0b0t1 6y ago
  I know, but running code in the target's process space isn't necessarily required nor does the API need to take on an amazing slew of options. That the NT API did is merely indicative of its growth, not an indication that fork is the one true way.

by R0b0t1 6y ago

This is not enough of an explanation as these things are still possible with CreateProcess. I do remember reading the real explanation -- it was easier to implement fork. That's it.

bollu 6y ago

I'd like a reference for this explanation :)

saurik 6y ago

These things are possible with APIs like CreateProcess or posix_spawn, but involve the API ending up with a million little customizable parameters in the attempt to simulate all of the behaviors that can trivially be implemented if you just support "let me run some code in the target process before I replace its memory"... which is like, exactly why "easier to implement" sort of means: something is often easier to implement if it is a single universal and general primitive that forms an elegant solution to a wide set of problems rather than being a myriad collection of hacks for various use cases. As an API--particularly on systems with copy-on-write pages--fork is amazing.

deleted 6y ago
[deleted]

pjc50 6y ago

Running code in the target process space before the target executable is loaded is not possible with CreateProcess. Configuration of the target process has to be done by the operating system, via an ever-growing list of attributes you can pack into STARTUPINFOEX. https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute https://docs.microsoft.com/en-us/windows/win32/api/processth... UNIX fork/exec is also significantly faster than CreateProcess, but I'm not sure how much of that is necessary rather than contingent, or results of an ever growing list of "security" programs insisting on a veto. https://stackoverflow.com/questions/47845/why-is-creating-a-new-process-more-expensive-on-windows-than-linux https://stackoverflow.com/questions/47845/why-is-creating-a-... Fork+IPC architecture - effectively multithreading but where the processes don't automatically share memory and can crash separately - also requires fork(). However this has very much fallen out of fashion. () I suppose you can emulate fork by calling CreateProcess with an empty executable and CREATE_SUSPENDED, then use various debug APIs to overwrite its memory map with your own, but this is very messy.

R0b0t1 6y ago
I know, but running code in the target's process space isn't necessarily required nor does the API need to take on an amazing slew of options. That the NT API did is merely indicative of its growth, not an indication that fork is the one true way.