[Bug 10273] satisfy SafeDisc 2.x heuristic API analyzer by "adjusting" API exports/entry statistics of wine builtins

wine-bugs at winehq.org wine-bugs at winehq.org
Mon Nov 5 03:22:55 CST 2007


http://bugs.winehq.org/show_bug.cgi?id=10273





--- Comment #13 from Anastasius Focht <focht at 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


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list