http://bugs.winehq.org/show_bug.cgi?id=13915
--- Comment #56 from Alexandre Julliard julliard@winehq.org 2010-08-24 06:33:42 --- (In reply to comment #55)
Sure, populating remote process PE headers would be completely safe ... Your scenario is more a corner case that applies to executables that are specially crafted by people that make an art of "optimizing" everything in headers (e.g. unusual load bases, section alignments) - unlikely to happen for Wine core libraries (unless someone messed with the build system, explicitly specifying preferred load bases).
No, it applies to all builtin libraries. The ELF header is loaded to 4k alignment by the system loader, but the PE header is 64k aligned, so the entry point offsets from the PE base will in general differ when the load address differs.
Anyway, do you agree this bug is a WONTFIX? Wine can't guarantee that core dlls (ntdll, kernel32, user32) will always get the same load base in all address spaces (with ASLR switched off).
In general it should work as long as prelink is found at compile time to set the base address, and as long as the OS doesn't force randomization despite prelink. But yes, there's nothing more we can do beyond that (though I guess we could print a nasty warning when prelink isn't found).
Though I wonder if certain Windows core dlls still have an "immutable" load address (=preferred base). It was a requirement in various Windows versions to support all these brain damaged software that made certain assumptions about system dlls.
That's certainly still true, and it's one of the reasons we set a fixed base address for kernel32. Some copy protection schemes explicitly check that kernel32 is within a certain range. And of course there are a million apps that assume that core function addresses are identical across processes.