So, basically yesterday, and not default like how it is with execve, and you can never know if the command you're trying to call implements it the same way or does a different escaping.
Care to explain how fork "breaks" threaded apps? You can't mix them for doing multiprocessing, but it's fine if you use one model or the other.
Win10 has been around for literally a decade now. So much so that it's going out of support.
fork() breaks threaded apps by forking the state of all threads, including any locks (such as e.g. the global heap lock!) that any given thread might hold at that moment. In practice this means that you have to choose either fork or threads for your process. And this extends to libraries - if the library that you need happens to spawn a background thread for any reason, no more fork for you. On macOS this means that many system APIs are unusable. Nor is any of this hypothetical - it's a footgun that people run into regularly (just google for "fork deadlock") even in higher level languages such as Python.
How long has fork() existed? Is it less than 10 year? Is it much much more?
> just google for "fork deadlock"
I did, results were completely unrelated to what you're talking about.
Anyway libraries spawning hidden threads… I bet they don't even bother to use reentrant functions? I mean… ok they are written by clueless developers. There's lots and lots of them, they exist on windows too. What's your point?
But also, no, it's not worse than fork. Fork literally breaks every threaded app.