http://bugs.winehq.org/show_bug.cgi?id=10273
--- Comment #13 from Anastasius Focht focht@gmx.net 2007-11-05 03:22:53 --- Hello,
--- quote --- The game was Stronghold patched to V1.2 which reported SafeDisc 2.60.something. And it definitely didn't work with wine-0.9.48(and dropping -fPIC). But after updating to the latest git today it suddenly works :). Maybe it was that ioctl problem that got fixed.(forgot the bug number). --- quote ---
You probably ran into this one: http://bugs.winehq.org/show_bug.cgi?id=10225 ... That took me some time because I first blamed the SafeDisc security driver. In the end I verified the security driver returned errors on purpose which triggered a wine server bug ;-)
--- quote --- I rather hoped it would be possible to relocate the PE header somehow so that it sits right before the ELF .text section. For example by putting the PE header in an extra section and then with a custom linker script put that section in front of the text section.(which I think should work at least theoretically ;) --- quote ---
Yes, a custom linker script would be needed to place a section directly before all other init/startup code. Probably wine tools need to be modified too... I played a bit with linker flags and it seems -shared always pulls in startup object files first (despite the argument placement) ... the wine object file with PE section header follows as first visible argument, usually <dllname>-<tempname>.spec.o
--- quote --- Also http://support.microsoft.com/kb/935448 suggests that Windows doesn't allow to relocate some core DLLs. If all of kernel32, gdi32 and user32 are such then maybe dropping -fPIC is a valid solution (of course on x86)? --- quote ---
Well if micro$oft claims that for their core dlls that would be a welcome incident for dropping -fPIC at least for wine "core" libraries. AFAIK at least builtin kernel32.dll is automagically mapped by loader on process init, so relocation incident is very unlikely...
Regards