Hacker News new | past | comments | ask | show | jobs | submit login

i have written a fair bit of code using the windows and posix APIs, and they are OK - what features of these, often written by talented programmers, do you despise so much?



To pick the same example from both, I hate both fork() and CreateProcess().

Microsoft wrote "A fork() in the Road" [1] describing the problems with fork(), and they are right: fork() is too simple, it doesn't scale, it is inefficient, and error handling becomes next to impossible.

(In my code, I have the child process return exit codes from 255 on down for error handling. It assumes, probably wrongly but right enough, that most programs won't use those exit codes.)

But CreateProcess() has the exact opposite problem: it's too complex and limited because it takes a large, fixed set of arguments. It takes many lines of code to set up for it, and once you actually start the process, you have no control over it, which sucks if you need to do something with the new process that CreateProcess() cannot do on creation.

Windows does have ways of modifying running processes, which is great and sort of makes up for the limits, but heaven help you if you need to use one of those functions on the new process because you have no control. The only thing you can do is to suspend the start thread of the new process right away, do your thing to it, and resume the thread, praying that the new process hadn't created a new runaway thread before it was suspended.

(And all of that is not even mentioning that the Windows way of passing a command-line is to pass a string to be parsed, not a list of strings. My code has a function literally to take a list of strings and turn it into a Windows-compatible command-line string with all of the juicy backslashing that implies.)

The right API is in the middle: a zero-argument function to create a new, blank process (not a copy of the current process), but to create it in a suspended state, so you know it's not going to run away from you.

Then, you use Windows-style functions to change the process, before it even starts, to set it up. Once you're done, unsuspend it.

That end result gives you as much power as fork(), with the better scalability of CreateProcess(), and better ease-of-use than both. You could even have functions to map in a copy of the current process if you so wish, to implement fork() for process checkpointing!

In other words, talented programmers can implement things and make them work, yes, but it doesn't imply that they are good at design.

[1]: https://www.microsoft.com/en-us/research/uploads/prod/2019/0...


The irony is that what you describe is pretty much the traditional OO way of doing things. In C#:

   var process = new Process();
   process.StartInfo.FileName = "foo.exe"
   ...
   process.Start();


Oh, that's cool! I didn't know that.


and does your library support threads? in my opinion, MS made the better design decision - first-class support of threads over forking new processes.

but this is why we have different software architectures :-)


My library does support threads. In fact, it has structured concurrency as a theme through the whole codebase, based on OS threads.

I do agree that first-class thread support is better.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: