[Bug 27349] New: SafeDisc v2.x API entry analyzer flags Wine's user32.dll as "bad" (too many exports with PIC loads in prolog code) (SimCity 4, ...)
http://bugs.winehq.org/show_bug.cgi?id=27349
Summary: SafeDisc v2.x API entry analyzer flags Wine's user32.dll as "bad" (too many exports with PIC loads in prolog code) (SimCity 4, ...) Product: Wine Version: 1.3.21 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs@winehq.org ReportedBy: focht@gmx.net
Hello,
many games (and some apps) have dependency on "meta" bug 219 "Programs refuse to run because of safedisc copy-protection" which just bad (not even targeting specific version).
I bought some games for few bucks just to have a look at some copy protections. Though I will probably never play them ;-)
Collecting/tracking affected games/apps for this _specific_ issue here (applicable appdb entries should have bug 219 dependency removed in favor of this one).
The root cause was already targeted by bug 10273 ("satisfy SafeDisc 2.x heuristic API analyzer by "adjusting" API exports/entry statistics of wine builtins (affects e.g. adobe photoshop)") ... That bug was closed a long time ago because it ought to work for various SD 2.x apps/games (unfortunately also depending on wine build environment/host gcc).
I rejected the idea of reviving that bug and instead created a new one, targeting the affected core dll.
Game: "SimCity 4"
A quick scan with "ProtectionID" reveals:
--- snip --- -=[ ProtectionID v0.6.4.0 JULY]=- (c) 2003-2010 CDKiLLER & TippeX Build 07/08/10-17:57:05 Ready... Scanning -> H:.wine\drive_c\Program Files\Maxis\SimCity 4\Apps\SimCity 4.exe File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 7971630 (079A32Eh) Byte(s) [x] Warning - FileAlignment seems wrong.. no solution calculated (using NULL) -> File has 746286 (0B632Eh) bytes of appended data starting at offset 06E4000h [File Heuristics] -> Flag : 00000000000000000100000100000111 (0x00004107) [!] Safedisc v2/v3/v4 [unknown version] detected ! [i] Appended data contents.... ... [CompilerDetect] -> Visual C++ 6.0 - Scan Took : 0.262 Second(s) --- snip ---
We can do better ... The string "BoG_" is well known for detection of SafeDisc versions.
--- snip --- $:~/.wine/drive_c/Program Files/Maxis/SimCity 4/Apps$ xxd -g 4 SimCity\ 4.exe | grep "BoG_" -A 2 0006fd0: 00000000 426f475f 202a3930 2e302621 ....BoG_ *90.0&! 0006fe0: 21202059 793e0000 00000000 00000000 ! Yy>.......... 0006ff0: 00000000 02000000 50000000 0a000000 ........P....... --- snip ---
0x02000000 -> 2 0x50000000 -> 90 0x0a000000 -> 10
So this is SafeDisc v2.90.10 protection. By debugging this game I came to conclusion there is still a problem with the API entry statistics.
$ wine --version wine-1.3.21-26-ge6ee2c1
$ gcc --version gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
For the meaning of the table just read up some comments in bug 10273
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x43 0x55 0x50 0x5F c2: 0x23 *0x41 0x39 0x3C c3: 0x00 0x00 0x00 0x5A
* = threshold exceeded -> bad
Basically the majority of exported user32 API entries have PIC register load code within range of first 8 opcode bytes of entry which is treated as trampoline (= high c2 value).
--- snip --- ... .text:0001D847 __i686_get_pc_thunk_bx proc near .text:0001D847 mov ebx, [esp+0] .text:0001D84A retn .text:0001D84A __i686_get_pc_thunk_bx endp ... API entry: .text:0003735C push ebp .text:0003735D mov ebp, esp .text:0003735F push ebx .text:00037360 sub esp, 34h .text:00037363 call __i686_get_pc_thunk_bx .text:00037368 add ebx, 0AEC8Ch ... --- snip ---
Kernel32 gets the good looking stats because it forwards various stuff to ntdll, letting compiler produce different function prolog code (= not having PIC register load in first place). As already mentioned in the other bug, unimpl. stubs also help to improve stats because they have 8 NOPs on entry.
I've tweaked user32 again a bit just to pass the threshold - there are various ugly methods one bad as the other ;-|
A method without adding unimpl. stubs or stack protector code (unreliable because cookie code can be inserted _after_ PIC code) and keeping -fPIC is to convince the compiler to use the 6 byte opcode for reserving stack space, e.g. "subl $xxx, %esp" with a 32-bit immediate (0x81,0xEB,<32 bit immediate>). Good targets are stubs and functions that make use of FIXME/TRACE. There are lots of them that can be tweaked this way (= no performance penalty), improving entry stats.
Result: games work out of the box without the need of No-CD patches.
Regards
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2011-06-01 03:38:33 CDT --- There are many more functions that should be DESCLSPEC_HOTPATCH, that would probably help.
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #2 from Anastasius Focht focht@gmx.net 2011-06-01 04:35:05 CDT --- Hello,
well those 2 extra opcode bytes on entry would certainly improve stats for user32. Though it won't help people stuck on distros shipping gcc without hotpatch support.
One could make a script to determine if DECLSPEC_HOTPATCH actually makes sense for a function, e.g. moving the PIC load code (call) beyond the 8 bytes barrier (for certain types of functions it doesn't).
If you plan to decorate a significant amount of user32 exports I'll just wait for patches and gather new statistics thereafter.
Regards
http://bugs.winehq.org/show_bug.cgi?id=27349
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
--- Comment #3 from André H. nerv@dawncrow.de 2011-06-04 11:37:28 CDT --- i like the idea from http://bugs.winehq.org/show_bug.cgi?id=10273#c34
http://bugs.winehq.org/show_bug.cgi?id=27349
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|SafeDisc v2.x API entry |SafeDisc v2.x API entry |analyzer flags Wine's |analyzer flags Wine's |user32.dll as "bad" (too |user32.dll as "bad" (too |many exports with PIC loads |many exports with PIC loads |in prolog code) (SimCity 4, |in prolog code) (SimCity 4, |...) |IL-2 FB)
--- Comment #4 from Anastasius Focht focht@gmx.net 2011-06-07 17:00:51 CDT --- Hello,
adding game "IL-2 Sturmovik Forgotten Battles" (2 CD set, protection on CD2)... Tested/debugged with original media.
--- snip --- ... Scanning -> H:.wine\drive_c\Program Files\Ubi Soft\IL-2 Sturmovik Forgotten Battles\rts.dll File Type : 32-Bit Dll (Subsystem : Win GUI / 2), Size : 880495 (0D6F6Fh) Byte(s) -> File has 741231 (0B4F6Fh) bytes of appended data starting at offset 022000h [File Heuristics] -> Flag : 00000000000000000100000000000111 (0x00004007) [!] Safedisc v2.80.011 detected ! [i] Appended data contents.... [.] o: 0x00022028 / t: <0xA8726B03> <0xEF01996C> <0x00000001> / s: 00180922 byte(s) -> ~de6d0c.tmp [.] o: 0x0004E309 / t: <0xA8726B03> <0xEF01996C> <0x0000044C> / s: 00011920 byte(s) -> clcd32.dll [.] o: 0x000511C0 / t: <0xA8726B03> <0xEF01996C> <0x0000044C> / s: 00004118 byte(s) -> clcd16.dll [.] o: 0x000521FA / t: <0xA8726B03> <0xEF01996C> <0x0000044D> / s: 00037967 byte(s) -> mcp.dll [.] o: 0x0005B670 / t: <0xA8726B03> <0xEF01996C> <0x00000002> / s: 00007096 byte(s) -> SECDRV.SYS [.] o: 0x0005D24F / t: <0xA8726B03> <0xEF01996C> <0x00000002> / s: 00014069 byte(s) -> DrvMgt.dll [.] o: 0x0006096D / t: <0xA8726B03> <0xEF01996C> <0x0000000B> / s: 00005442 byte(s) -> SecDrv04.VxD [.] o: 0x00061ED7 / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00036352 byte(s) -> ~e5d141.tmp [.] o: 0x0006ACFF / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00442908 byte(s) -> ~df394b.tmp [CompilerDetect] -> Visual C++ 6.0 - Scan Took : 0.417 Second(s) --- snip ---
--- snip --- $~/.wine/drive_c/Program Files/Ubi Soft/IL-2 Sturmovik Forgotten Battles$ xxd -g 4 rts.dll | grep "BoG_" -A 2 0000fd0: 00000000 426f475f 202a3930 2e302621 ....BoG_ *90.0&! 0000fe0: 21202059 793e0000 00000000 00000000 ! Yy>.......... 0000ff0: 00000000 02000000 50000000 0b000000 ........P....... --- snip ---
Regards
http://bugs.winehq.org/show_bug.cgi?id=27349
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation Summary|SafeDisc v2.x API entry |SafeDisc v2.x API entry |analyzer flags Wine's |analyzer flags Wine's |user32.dll as "bad" (too |user32.dll as "bad" (too |many exports with PIC loads |many exports with PIC loads |in prolog code) (SimCity 4, |in prolog code) (SimCity 4, |IL-2 FB) |IL-2 FB, NFSU)
--- Comment #5 from Anastasius Focht focht@gmx.net 2011-06-07 17:40:59 CDT --- Hello,
adding game "Need for Speed: Underground (NFSU)" (2 CD set)... Tested/debugged with original media.
--- snip --- ... Scanning -> H:.wine\drive_c\Program Files\EA GAMES\NFS Underground\Speed.exe File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 4000456 (03D0AC8h) Byte(s) -> File has 846536 (0CEAC8h) bytes of appended data starting at offset 0302000h [File Heuristics] -> Flag : 00000000000000000100000000000111 (0x00004007) [!] Safedisc v2.90.040 detected ! [i] Appended data contents.... [.] o: 0x00302028 / t: <0xA8726B03> <0xEF01996C> <0x00000001> / s: 00180413 byte(s) -> ~ded303.tmp [.] o: 0x0032E10C / t: <0xA8726B03> <0xEF01996C> <0x0000044C> / s: 00011924 byte(s) -> clcd32.dll [.] o: 0x00330FC7 / t: <0xA8726B03> <0xEF01996C> <0x0000044C> / s: 00004122 byte(s) -> clcd16.dll [.] o: 0x00332005 / t: <0xA8726B03> <0xEF01996C> <0x0000044D> / s: 00037971 byte(s) -> mcp.dll [.] o: 0x0033B47F / t: <0xA8726B03> <0xEF01996C> <0x00000002> / s: 00007039 byte(s) -> SECDRV.SYS [.] o: 0x0033D025 / t: <0xA8726B03> <0xEF01996C> <0x00000002> / s: 00019048 byte(s) -> DrvMgt.dll [.] o: 0x00341AB6 / t: <0xA8726B03> <0xEF01996C> <0x0000000B> / s: 00005446 byte(s) -> SecDrv04.VxD [.] o: 0x00343024 / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00046080 byte(s) -> ~e5d141.tmp [.] o: 0x0034E44C / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00534056 byte(s) -> ~df394b.tmp [CompilerDetect] -> Visual C++ 7.0 (Visual Studio 2002) - Scan Took : 0.612 Second(s) --- snip ---
--- snip --- $~/.wine/drive_c/Program Files/EA GAMES/NFS Underground$ xxd -g 4 Speed.exe | grep "BoG_" -A 2 0000fd0: 00000000 426f475f 202a3930 2e302621 ....BoG_ *90.0&! 0000fe0: 21202059 793e0000 00000000 00000000 ! Yy>.......... 0000ff0: 00000000 02000000 5a000000 28000000 ........Z...(... --- snip ---
Regards
http://bugs.winehq.org/show_bug.cgi?id=27349
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gabrielbyrnei@gmail.com
--- Comment #6 from Anastasius Focht focht@gmx.net 2011-06-08 15:56:53 CDT --- *** Bug 21052 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #7 from André H. nerv@dawncrow.de 2011-06-10 12:46:18 CDT --- Created an attachment (id=35097) --> (http://bugs.winehq.org/attachment.cgi?id=35097) more DECLSPEC_HOTPATCH
When __ms_hook_prologue__ available, this moves calls to other functions and PIC code behind the first 8 Bytes where needed(only functions which have the opcode 0xE8 in the first 8 bytes). That's done here for 163 functions and i used a little app to find the bad functions.
I already sent that patch and it was rejected more or less. We can't decide on my system and compiler which function to enable hotpatch on, of course. So AJ wants tests for some specific functions to show that they are hotpatchable on windows, too.
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #8 from André H. nerv@dawncrow.de 2011-06-10 14:29:51 CDT --- Anastasius, could you please get me two cx tables from your end: one with my patch and one without my patch, but with a different define for WINAPI in innclude/windef.h: instead of #define WINAPI __stdcall use #define WINAPI __stdcall __attribute__((__ms_hook_prologue__)) that will enable hotpatching for all exported functions and may give us a very clean c2 row :)
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #9 from Anastasius Focht focht@gmx.net 2011-06-10 16:15:48 CDT --- Hello,
well after applying your attached patch and gathering new numbers:
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x43 0x55 0x50 0x5F c2: 0x23 *0x40 0x39 0x3C c3: 0x00 0x00 0x00 0x5A
(instead of 0x41)
I could not believe it hence I debugged the whole thing again and noticed the SafeDisc entry point analyzer was counting decoded/disassembled _instructions_, not bytes - sorry, that was a brain fart on my side (summer heat) :| I should have re-read my own stuff written some years ago more carefully ...
So inserting one hot-patch instruction will have no effect on majority of entry points. The first branch instruction must be 8 instructions away.
Regards
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #10 from André H. nerv@dawncrow.de 2011-06-11 07:10:09 CDT --- Hi, Thank you.
(In reply to comment #9)
(instead of 0x41)
Great :)
I could not believe it hence I debugged the whole thing again and noticed the SafeDisc entry point analyzer was counting decoded/disassembled _instructions_, not bytes - sorry, that was a brain fart on my side (summer heat) :| I should have re-read my own stuff written some years ago more carefully ...
NP, but 8 instructions is much. AFAIK that can be 72 bytes.
So inserting one hot-patch instruction will have no effect on majority of entry points. The first branch instruction must be 8 instructions away.
Still i would be interested in the table with #define WINAPI __stdcall __attribute__((__ms_hook_prologue__))
http://bugs.winehq.org/show_bug.cgi?id=27349
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alessandro_pezzoni@lavabit. | |com
--- Comment #11 from Anastasius Focht focht@gmx.net 2011-07-09 07:23:23 CDT --- *** Bug 27702 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #12 from André H. nerv@dawncrow.de 2011-07-11 12:57:06 CDT --- is just tried #define FIXME_FUNCSTART(args...) __asm__ __volatile__( \ "nop\n\tnop\n\tnop\n\tnop\n\t" ); \ "nop\n\tnop\n\tnop\n\tnop\n\t" ); \ FIXME(args) but the pc_thunk call is still before the NOPs, so i tried something similar to DEFINE_THISCALL_WRAPPER but i didn't managed to make it compile.
@Anastasius: I still would be interested in the table with #define WINAPI __stdcall __attribute__((__ms_hook_prologue__)) ;)
http://bugs.winehq.org/show_bug.cgi?id=27349
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #35097|0 |1 is obsolete| |
--- Comment #13 from André H. nerv@dawncrow.de 2011-07-11 13:31:40 CDT --- Created an attachment (id=35522) --> (http://bugs.winehq.org/attachment.cgi?id=35522) Wrapper with nops
the attached patch might work if used for more functions, the question is if it's clean enough.
btw. you said safedisc checks the first 8 instructions, so i inserted 8 nops, but why do we use 9 nops in winebuild for stubs?
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #14 from Anastasius Focht focht@gmx.net 2011-07-11 16:36:25 CDT --- Hello,
--- quote --- the attached patch might work if used for more functions, the question is if it's clean enough. --- quote ---
well I used the clever hint from Morten Welinder (http://bugs.winehq.org/show_bug.cgi?id=10273#c35) to modify user32 makefile rule, force NOP-padding where needed:
Examples:
--- snip --- user32.WaitForInputIdle: 6878869A 89E5 MOV EBP,ESP 6878869C 53 PUSH EBX 6878869D 81EC E4000000 SUB ESP,0E4 687886A3 90 NOP 687886A4 90 NOP 687886A5 90 NOP 687886A6 90 NOP 687886A7 E8 8B10F9FF CALL 68719737 687886AC 81C3 48590600 ADD EBX,65948 ... --- snip ---
--- snip --- user32.SetKeyboardState: 6875F2E0 55 PUSH EBP 6875F2E1 89E5 MOV EBP,ESP 6875F2E3 56 PUSH ESI 6875F2E4 53 PUSH EBX 6875F2E5 81EC B0000000 SUB ESP,0B0 6875F2EB 90 NOP 6875F2EC 90 NOP 6875F2ED 90 NOP 6875F2EE E8 44A4FBFF CALL 68719737 6875F2F3 81C3 01ED0800 ADD EBX,8ED01 ... --- snip ---
Already hotpatch entry, remainder filled up with NOP:
--- snip --- user32.GetKeyboardState: 6875F176 8BFF MOV EDI,EDI 6875F178 55 PUSH EBP 6875F179 8BEC MOV EBP,ESP 6875F17B 56 PUSH ESI 6875F17C 53 PUSH EBX 6875F17D 81EC C0000000 SUB ESP,0C0 6875F183 90 NOP 6875F184 90 NOP 6875F185 E8 ADA5FBFF CALL 68719737 6875F18A 81C3 6AEE0800 ADD EBX,8EE6A ... --- snip ---
--- quote --- btw. you said safedisc checks the first 8 instructions, so i inserted 8 nops, but why do we use 9 nops in winebuild for stubs? --- quote ---
After having some drinks (I'm still investigating bug 27162 in my spare time) I came up with the following theory:
I already posted a snippet for 8 NOP sequence in bug 10273 - though only for relay thunks (stats gathering). I first intended to use 8 LOLs for illustration but somehow forgot about it. Later I realized my mistake - but it was too late. Now it would be difficult to reuse this ingenious sequence - which took many hours to develop - elsewhere (originating author). You know the rules... Don't talk about the club ... err, that was something different ;-)
AJ gave it a thought and came up with a solution: creating stub entry points with 9 NOPs gives a whole new meaning. More space is used in the resulting binary, the compile time increases, the entropy is different, the shape of the space-time continuum is bent and distorted even more by the mere presence of this additional NOP ... did I forgot something?
Oh well I forgot ... you wanted new user32 stats with the padding ... here you go:
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x44 0x03 0x50 0x5F c2: 0x2B 0x00 0x39 0x3C c3: 0x00 0x00 0x00 0x5A
Lovely, isn't it? ;-)
$ wine --version wine-1.3.24-42-g4ebbd0e
Regards
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #15 from André H. nerv@dawncrow.de 2011-07-11 17:21:34 CDT --- (In reply to comment #14)
AJ gave it a thought and came up with a solution: creating stub entry points with 9 NOPs gives a whole new meaning. More space is used in the resulting binary, the compile time increases, the entropy is different, the shape of the space-time continuum is bent and distorted even more by the mere presence of this additional NOP ... did I forgot something?
:)
Oh well I forgot ... you wanted new user32 stats with the padding ... here you go:
kernel32 user32 gdi32 condition (cx < threshold)
c1: 0x44 0x03 0x50 0x5F c2: 0x2B 0x00 0x39 0x3C c3: 0x00 0x00 0x00 0x5A
Is that with the script from Morten or with #define WINAPI __stdcall __attribute__((__ms_hook_prologue__)) but only compiling user32?
http://bugs.winehq.org/show_bug.cgi?id=27349
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #16 from Anastasius Focht focht@gmx.net 2011-07-12 02:14:14 CDT --- Hello,
--- quote --- Is that with the script from Morten or with #define WINAPI __stdcall __attribute__((__ms_hook_prologue__)) but only compiling user32? --- quote ---
It should be obvious that I used Morten's script to insert as many NOPs needed to move the PIC call beyond the 8 instruction barrier (have a look at the examples I posted).
wine-1.3.24-42-g4ebbd0e unmodified:
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x44 0x55 0x50 0x5F c2: 0x2B 0x41 0x39 0x3C c3: 0x00 0x00 0x00 0x5A
wine-1.3.24-42-g4ebbd0e with every public export hotpatchable (__ms_hook_prologue__) in user32:
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x44 0x54 0x50 0x5F c2: 0x2B 0x3F 0x39 0x3C c3: 0x00 0x00 0x00 0x5A
As already suspected - it doesn't have much effect on overall statistics because for the majority of user32 exports one additional instruction is not enough.
Regards
http://bugs.winehq.org/show_bug.cgi?id=27349
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #17 from Stefan Dösinger stefan@codeweavers.com 2012-03-11 15:30:56 CDT --- What is the user-visible symptom if these checks fail?
I'm trying to get Safedisc 2 games running withour a nocd patch in my Wine setup, and I suspected the API heuristics. However, neither a build with gcc 4.4, removing -fPIC, or one of the nop insertion tricks helped.
I tested Age of Empires 2: The conquerors and Red Alert 2 Yuri's revenge. AoE2 crashes with what looks like a stack overflow after *lots* of CreateFile("\\.\SecDrv"), DeviceIoControl, CloseHandle call sequences. RA2 silently exits after operating on some temporary files.
This is Wine git from friday(94953f165a) fwiw.
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #18 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2012-03-11 16:28:39 CDT --- (In reply to comment #17) AoE2 used to work for sure. Do you have prelink installed?
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #19 from Stefan Dösinger stefan@codeweavers.com 2012-03-11 16:37:52 CDT --- $ /usr/sbin/prelink --version prelink 1.0
configure:6956: checking for prelink configure:6974: found /usr/sbin/prelink configure:6987: result: /usr/sbin/prelink ac_cv_path_PRELINK=/usr/sbin/prelink PRELINK='/usr/sbin/prelink'
The Age of Empires issue is probably unrelated to the heuristic checks. ProtectId claims aoe is using SaveDisc 1.50.020. I'm not sure about RA2, but it uses Safedisc 2.40.010.
And yeah, I tried to set Winver=win2k and Winver=winnt for AoE2(bug 21147).
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #20 from Anastasius Focht focht@gmx.net 2012-03-11 18:35:26 CDT --- Hello Stefan,
--- quote --- What is the user-visible symptom if these checks fail? --- quote ---
the process terminates itself with exit code "0xfeedface" when one of the API entry checks fails.
For quick verification without any WINEDEBUG run your target on terminal like this:
$ wine ./foo.exe || echo $?
If "206" (0xCE) appears, it's the API entry checks that failed.
---
Current statistics (kernel32 and user32 have improved):
$ wine --version wine-1.4-78-g94953f1
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x44 0x50 0x50 0x5F c2: 0x21 0x33 0x39 0x3C c3: 0x00 0x00 0x00 0x5A
Regards
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #21 from Stefan Dösinger stefan@codeweavers.com 2012-03-12 05:55:41 CDT --- Nope, that's not the case here, it either exits with 0 or 1. However, I accidentally created a wineprefix where Yuri's revenge, plain red alert 2 and age of empires 2 all work. I suspect that the AoE2 and RA2 secdrv.sys drivers are somehow bad, and the YURI one works. I'll try to confirm.
I guess we need (a) a separate bug report for this, and (b) systematic documentation of all the things that can go wrong with safedisc.
http://bugs.winehq.org/show_bug.cgi?id=27349
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #22 from Anastasius Focht focht@gmx.net 2012-03-12 19:17:55 CDT --- Hello Stefan,
feel free to create new bug(s).
I retested some SafeDisc v2.x games, they all work with recent Wine:
BF1942 original: Safedisc v2.60.052 BF1942 patched to 1.6.19: Safedisc v2.80.010 IL-2 FB: Safedisc v2.80.011 NFS Underground: Safedisc v2.90.040
---
For completeness I measured the influence of optimization levels, frame pointer omission and visibility of functions.
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)
--- snip --- CFLAGS="-g -gdwarf-2 -O2" (default "-fno-omit-frame-pointer" enforced by Wine)
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x3E 0x47 0x39 0x5F c2: 0x1B 0x2D 0x21 0x3C c3: 0x00 0x00 0x00 0x5A --- snip ---
--- snip --- CFLAGS="-g -gdwarf-2 -O2 -fomit-frame-pointer" (override of Wine's default)
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x41 0x49 0x3C 0x5F c2: 0x20 0x32 0x23 0x3C c3: 0x00 0x00 0x00 0x5A --- snip ---
--- snip --- CFLAGS="-g -gdwarf-2 -O0" (default "-fno-omit-frame-pointer" enforced by Wine)
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x44 0x50 0x50 0x5F c2: 0x21 0x33 0x39 0x3C c3: 0x00 0x00 0x00 0x5A --- snip ---
Disabling "DECLSPEC_HIDDEN" (__attribute__((visibility ("hidden")))):
--- snip --- CFLAGS="-g -gdwarf-2 -O0" (default "-fno-omit-frame-pointer" enforced by Wine)
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x4B 0x55 0x53 0x5F c2: 0x2C 0x3C* 0x43* 0x3C c3: 0x00 0x00 0x00 0x5A
* = threshold exceeded -> bad --- snip ---
I'm a bit surprised about "-O0" being worst, there might be additional metrics involved here (align/padding?).
Summarizing the improvements:
- more API hotpatchable - more functions with hidden visibility - enforcing "-fno-omit-frame-pointer" (http://source.winehq.org/git/wine.git/commit/5cfe7db1854ff1142d598eaf49f6050...)
Current Wine built with default settings keeps a safe distance to threshold so I think it's fine to close this bug.
Regards
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #23 from Stefan Dösinger stefan@codeweavers.com 2012-03-13 04:39:41 CDT --- Yeah, from my point of view this bug can be closed. I'll add my troubleshooting factoids to the SafeDisc wiki page and create bugs for the two safedisc versions I have issues with.
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #24 from Stefan Dösinger stefan@codeweavers.com 2012-03-13 05:23:02 CDT --- Fyi, I filed bug 30155 for the SafeDisc v2.05.030 issue.
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #25 from André H. nerv@dawncrow.de 2012-03-16 13:20:41 CDT --- (In reply to comment #20)
Current statistics (kernel32 and user32 have improved):
$ wine --version wine-1.4-78-g94953f1
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)
kernel32 user32 gdi32 condition (cx < threshold)
c1: 0x44 0x50 0x50 0x5F c2: 0x21 0x33 0x39 0x3C c3: 0x00 0x00 0x00 0x5A
What happened since:
(In reply to comment #16)
wine-1.3.24-42-g4ebbd0e unmodified:
kernel32 user32 gdi32 condition (cx < threshold)
c1: 0x44 0x55 0x50 0x5F c2: 0x2B 0x41 0x39 0x3C c3: 0x00 0x00 0x00 0x5A
? I mean, was it most likely the compiler or changed wine code?
http://bugs.winehq.org/show_bug.cgi?id=27349
--- Comment #26 from Alexandre Julliard julliard@winehq.org 2012-03-16 14:08:19 CDT --- Closing bugs fixed in 1.5.0.
http://bugs.winehq.org/show_bug.cgi?id=27349
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #27 from Alexandre Julliard julliard@winehq.org 2012-03-16 17:10:56 CDT --- Really closing bugs fixed in 1.5.0.
http://bugs.winehq.org/show_bug.cgi?id=27349
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |5cfe7db1854ff1142d598eaf49f | |6050676c8d547 Component|user32 |-unknown
https://bugs.winehq.org/show_bug.cgi?id=27349
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |build-env
-
wine-bugs＠winehq.org