It is not the standard in Windows land to run processes by handing them fifty commandline arguments. Simple as that. Win32 apps have strong support for selecting multiple files to pass to the app from within the file select dialog, as long as you follow the documentation.
It's like complaining that Unix is hard to use because I can't just drop a dll into a folder to hook functionality like I can on Windows. It's a radically different design following different ideologies and you can't magically expect everything to transfer over perfectly. If you want to do that on Linux land, you learn about LD_PRELOAD or hook system calls.
If you want to build powerful, interoperable modules that can pipe into each other and compose on the commandline, Powershell has existed since 2006. IMO, passing well formed objects from module to module is RADICALLY better than passing around text strings that you have to parse or mangle or fuck with if you want actual composibility. Powershell's equivalent of ls doesn't have to go looking at whether it is being called by an actual terminal or by an app Pipe for example in order to support weird quirks. Powershell support for Windows internals and functionality is also just radically better than mucking around in "everything is a file" pseudo folders that are a hacky way to represent important parts of the operating system, or calling IOCntrls.
I also think the way Windows OS handles scheduled tasks and operations is better than cron.
I also think Windows Event logging is better than something like dmesg, but that's preference.
Also EVERYTHING in Windows land is designed around remote administration. Both the scheduled tasks and Event Logging systems are transparently and magically functional from other machines if you have you AD setup right. Is there anything in Linux land like AD?
> Win32 apps have strong support for selecting multiple files to pass to the app from within the file select dialog
The problem is when you want to click a file on your file manager and you want it to open in the associated application. Because the file manager can only hope the associated application parses the escapes the same way it generates them. Otherwise it's file not found :)
I'm not going to bother to reply point by point since you completely missed the point in the first few words.
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?
That's much more complicated and error prone than fork.