Andy Koppe wrote:
Remember, the semantics of fork is that BOTH processes (the parent and
child) must see the SAME memory, and that includes all shared libraries
being mapped at the SAME location. But since Windows doesn't provide a
native fork, the child must remap everything that the parent had, and
hope
that it lands at the same place. Rebasing improves the chance that the
child will remap, because there are fewer dlls to be remapped in an
arbitrary order.
Shudder. I wonder whether MS's own POSIX layer, the snappily named
"Services for Unix Applications", has to go through the same
contortions or whether there isn't some hidden fork support somewhere.
They don't use the Win32 subsystem so they aren't subject to its
restrictions but are instead locked in there own little subsystem....