Thanks for doing that. I looks good to me, with just one exception.
+<listitem>Address space layout randomization (ASLR). Starting with
+Vista, Windows implements ASLR, which means that thread stacks,
+heap, memory-mapped files, and statically-linked dlls are placed
+at different (random) locations in each process. This behaviour
+interferes with a proper<literal>fork</literal>, and if an
+unmovable object (process heap or system dll) ends up at the wrong
+location, Cygwin can do nothing to compensate (though it will
+retry a few times automatically). In a 64-bit system, marking
+executables as large address-ware and rebasing dlls to high
+addresses has been reported to help, as ASLR affects only the
+lower 2GB of address space.</listitem>
Starting with "In a 64-bit system" it's getting a bit weird:
- Starting with 4.5.3, gcc marks executables as large address aware
automatically, so this is going to be a lesser problem over time. Is
it worth to mention this at all? I suppose so, but the user should be
pointed to peflags to tests for this property first for the given
reason.
- Starting with Cygwin 1.7.10, the high address area will be used for
the application heap on 64 bit systems and large address aware
executables. Mmaps are located there, too. This in turn leaves more
room for DLLs in the normal 2 Gigs memory area. Therefore I would not
like to suggest rebasing DLLs into the high address area at all. This
should only be done by people who know what they are doing. Usually
there should be enough space in the lower 2 Gigs, especially when heap
and mmaps are out of the way, and given that the more recent rebaseall
will not create an arbitrary 64K hole between DLLs anymore when
rebasing.