10 ms·

I understand the need for each process to be in a separate process, but would've all this special code (to separate processes) would've been needed if Windows h

by malkia 17y ago

I understand the need for each process to be in a separate process, but would've all this special code (to separate processes) would've been needed if Windows had implemented fork()?

jfoutz 17y ago
I'm not sure if you're kidding :) No, you still need all of the parent/child communication. if a child tab dies, who cleans up the mess? If the user changes rendering preferences, how do you update all the client process? At the very least there's some infrastructure to coordinate parent and children. It's likely they do clever things so each visible window can be rendered by multiple processes, without the ui getting fubared.
Hoff 17y ago
If you're not kidding about that... fork() is a long-standing thorn when porting code onto some platforms; it's seldom used for what it was originally intended for, and (when it is) the copy-on-write memory semantics and the file descriptors and network contexts and such aren't widely adopted. About 95% of the cases reviewed during the ports were using fork() as a way to start a process; as a way to do a vfork()/exec() and to create a separate process. The remaining 5% of those applications were using the memory address spaces and the I/O channels and the rest of the process context. Which makes those really difficult to port to a platform that lacked a full-on fork().
xpaulbettsx 17y ago
Trivia time, the Windows kernel actually does implement fork, it just doesn't expose it to the Win32 subsystem. I keep trying to convince the kernel devs to expose it, because it'd be extremely handy for UAC if you had a ForkAndElevate() function that would create a forked child with elevated Admin privileges.
- mlinsey 17y ago
  Someone once told me that the NT kernel is designed so that with a couple config changes you can make it behave like Unix or OS/2, with Windows being just one "personality" on top the device, supposedly because MS was contracted to build several different OS in the early 90s. Is this what you are referring to by "the Win32 subsystem"? Does that still work? Or have there been so many changes over the years that something crazy would happen if you tried to run NT OS/2?
  - thristian 17y ago
    I don't know about OS/2, but the POSIX subsystem for the NT kernel is alive and well: http://en.wikipedia.org/wiki/Interix http://en.wikipedia.org/wiki/Interix (note that this is not POSIX implemented on top of Win32, like Cygwin, this is POSIX implemented next to Win32)
    - nailer 17y ago
      Doesn't the POSIX subsystem have no network access (I was an NT guy a decade ago and I seem to remember this being true back in the day)?

by malkia 17y ago

I understand the need for each process to be in a separate process, but would've all this special code (to separate processes) would've been needed if Windows had implemented fork()?

jfoutz 17y ago

I'm not sure if you're kidding :) No, you still need all of the parent/child communication. if a child tab dies, who cleans up the mess? If the user changes rendering preferences, how do you update all the client process? At the very least there's some infrastructure to coordinate parent and children. It's likely they do clever things so each visible window can be rendered by multiple processes, without the ui getting fubared.

Hoff 17y ago

If you're not kidding about that... fork() is a long-standing thorn when porting code onto some platforms; it's seldom used for what it was originally intended for, and (when it is) the copy-on-write memory semantics and the file descriptors and network contexts and such aren't widely adopted. About 95% of the cases reviewed during the ports were using fork() as a way to start a process; as a way to do a vfork()/exec() and to create a separate process. The remaining 5% of those applications were using the memory address spaces and the I/O channels and the rest of the process context. Which makes those really difficult to port to a platform that lacked a full-on fork().

xpaulbettsx 17y ago

Trivia time, the Windows kernel actually does implement fork, it just doesn't expose it to the Win32 subsystem. I keep trying to convince the kernel devs to expose it, because it'd be extremely handy for UAC if you had a ForkAndElevate() function that would create a forked child with elevated Admin privileges.

mlinsey 17y ago
Someone once told me that the NT kernel is designed so that with a couple config changes you can make it behave like Unix or OS/2, with Windows being just one "personality" on top the device, supposedly because MS was contracted to build several different OS in the early 90s. Is this what you are referring to by "the Win32 subsystem"? Does that still work? Or have there been so many changes over the years that something crazy would happen if you tried to run NT OS/2?
- thristian 17y ago
  I don't know about OS/2, but the POSIX subsystem for the NT kernel is alive and well: http://en.wikipedia.org/wiki/Interix http://en.wikipedia.org/wiki/Interix (note that this is not POSIX implemented on top of Win32, like Cygwin, this is POSIX implemented next to Win32)
  - nailer 17y ago
    Doesn't the POSIX subsystem have no network access (I was an NT guy a decade ago and I seem to remember this being true back in the day)?