https://bugs.winehq.org/show_bug.cgi?id=43567
Bug ID: 43567 Summary: Vietcong - game crashes during radiocalls Product: Wine Version: 2.14 Hardware: x86-64 URL: http://www.moddb.com/games/vietcong/downloads/vietcong -singleplayer-demo OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: havran.jan@email.cz Distribution: ArchLinux
Created attachment 58977 --> https://bugs.winehq.org/attachment.cgi?id=58977 Vietcong - terminal log
Vietcong crashes when radiocall icon is shown. This bug is also reproduciable on Windows > Vista, but it works on Windows XP. There exists community tool: VCStarter, which fixes this for newer Windows and also for Wine. I have spoke with VCStarter creator and he told me that the game uses some dirty assembler in that part (maybe part of anticheat protection or no-cd crack?). I have doubts if it is really Wine bug, but since this game works on Windows <= XP, it should also work on Wine (with Win XP compatibility).
PS: You will not be able tu run this game probably because of bug #9337. As a workaround, you can use VCStarter (version 1.7 only, older versions did not fix the bug) or patch from bug #39057 - all this is described in bug #9337 PPS: While patch from bug #39057 fixes bug #9337 crashing for all Vietcong versions, VCStarter works only with Vietcong 1.60 (so it does not work with Vietcong demo version).
https://bugs.winehq.org/show_bug.cgi?id=43567
--- Comment #1 from Jan Havran havran.jan@email.cz --- Created attachment 58978 --> https://bugs.winehq.org/attachment.cgi?id=58978 Vietcong - winedbg log
Log for game running with WineDbg
https://bugs.winehq.org/show_bug.cgi?id=43567
Jan Havran havran.jan@email.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |havran.jan@email.cz
https://bugs.winehq.org/show_bug.cgi?id=43567
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #2 from Paul Gofman gofmanp@gmail.com --- Created attachment 63119 --> https://bugs.winehq.org/attachment.cgi?id=63119 Preserve ecx in GetTickCount
I tested this on demo version. The game goes for some obscure system call trickery at certain moment. Below are two fragments of relevant disassembly from winedbg with my comments starting with ';'.
-------- ; the following trickery in game.dll should effectively result into kernel32.GetTickCount() call
0x0060b8ca in game: xorl %edi,%edi 0x0060b8cc in game: movl $0x60b8e4,%ecx ; return address in ecx 0x0060b8d1 in game: movl $0x4,%eax 0x0060b8d6 in game: addl $12705608,%eax 0x0060b8db in game: movl 0x0(%eax),%eax 0x0060b8dd in game: subl $1480757628,%eax ; eax is 0x0040522c here 0x0060b8e2 in game: jmp *%eax ; ecx holds this address 0x0060b8e4 in game: movl %eax,0xfffffffc(%ebp) 0x0060b8e7 in game: movl 0xfffffffc(%ebp),%eax
....
; Here we get through 'jmp *%eax' above 0x0040522c in vietcong: pushl %edx 0x0040522d in vietcong: call *0x410110 -> 0x7b44b700 GetTickCount in kernel32 ; application expects ecx to stay unchanged 0x00405233 in vietcong: popl %edx 0x00405234 in vietcong: subl $0x17c34111,%edx 0x0040523a in vietcong: jnz 0x0040524e in vietcong 0x0040523c in vietcong: subl $0x7af7327,%esi 0x00405242 in vietcong: jnz 0x0040524e in vietcong 0x00405244 in vietcong: subl $0x3af4623f,%edi 0x0040524a in vietcong: jnz 0x0040524e in vietcong 0x0040524c in vietcong: xorl %eax,%eax 0x0040524e in vietcong: jmp *%ecx ; if ecx changed in GetTickCount, jumps to the garbage address --------------
So this works on Windows versions where GetTickCount does not change ecx, and fails otherwise. I have attached an ugly patch which fixes the crash during radio call (at least the first one in the beginning of the mission in demo which I used).
https://bugs.winehq.org/show_bug.cgi?id=43567
--- Comment #3 from Jan Havran havran.jan@email.cz --- Created attachment 63120 --> https://bugs.winehq.org/attachment.cgi?id=63120 WINEDEBUG=+tid,+seh,+timestamp,+snoop
I was digging in assembler and tried to trace calls until the crash. I chose mission "Swamped" for reproducing the bug, because it is one of few missions which do not crash because of bug #9337, and because the radio call in this mission is not raised by game event, but by the user.
At the beginning of the mission simply follow the pointman. When he stops for the first time (stops made just to wait for the team are not counted), he see VietCong guard at the water. Continue until he stops for second time - this time he sees hut in the water. Now it is good time to save the game for better reproducibility in the future.
From now, when you talk to the pointman (the USE button), the radio sound is
played ant the game crashes.
I noticed that there is a function INP_UC_GetStatusJustPressed (at address 0x101375E0) in log called periodically, which has most of the time return value 0: logs.?INP_UC_GetStatusJustPressed@@YAKPAUs_INP_UniControl@@@Z() retval=00000000 but sometimes (rarely) 1: logs.?INP_UC_GetStatusJustPressed@@YAKPAUs_INP_UniControl@@@Z() retval=00000001 The experiments showed up that value 1 is returned only when the user press the button (does not matter if it will raise any action or not).
The attached log begins from this part - player is in the situation described above and talks to pointman.
A quick look into the log shows us that this causes the call of SCR_ExecScript (logs.dll) and SNDS_GetSpeechInfo (logs.dll), which does a lot of ogg stuff (probably playing the radio sound).
https://bugs.winehq.org/show_bug.cgi?id=43567
--- Comment #4 from Jan Havran havran.jan@email.cz --- Created attachment 63121 --> https://bugs.winehq.org/attachment.cgi?id=63121 Bugfix - variant #2
Ok, this is really bad joke to me, but point for you. I was digging into this bug since yesterday and finally found the fix...but you wrote it faster (I wanted do more tests, but I will just post what I have so far). My patch is little bit different, since I used whole function as assembler. I basically agree what you wrote.
What is probability of such a situation, when two people fix same issue same day after more than year after report?
https://bugs.winehq.org/show_bug.cgi?id=43567
--- Comment #5 from Jan Havran havran.jan@email.cz --- Created attachment 63122 --> https://bugs.winehq.org/attachment.cgi?id=63122 test case
I also prepared primitive test case, where I tested behavior of ECX in GetTickCount() function.
Here are the outputs for Win 7, XP and Wine before and after patch.
Windows 7 asm: 3545699, C: 3545699 before 42, after 0
Windows XP asm: 3622368, C: 3622368 before 42, after 42
wine-4.0-rc2 asm: 1734890, C: 1734890 before 42, after 61fe40
wine-4.0-rc2 + workaround asm: 2620090, C: 2620090 before 42, after 42
My patch (and probably yours too) fixes the issue for both Demo and full version (I used full version for debugging).
OT: It took me a whole day to find a hard drive where I could install Windows 7 and Windows XP, install both systems and test it. And wait two more days would be enough. Sigh :(
https://bugs.winehq.org/show_bug.cgi?id=43567
--- Comment #6 from Jan Havran havran.jan@email.cz --- To make it complete, one last post. Here is disassembled code of full version which I prepared yesterday:
0x008058cc EntryPoint+0xffffffff in game: movl $0x8058e4,%ecx ; < here store the address 0x008058d1 EntryPoint+0xffffffff in game: movl $0x4,%eax 0x008058d6 EntryPoint+0xffffffff in game: addl $15103168,%eax 0x008058db EntryPoint+0xffffffff in game: movl 0x0(%eax),%eax 0x008058dd EntryPoint+0xffffffff in game: subl $1480757628,%eax 0x008058e2 EntryPoint+0xffffffff in game: jmp *%eax
Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:008058e2 ESP:0033f5a0 EBP:0033f764 EFLAGS:00000212( - -- I -A- - ) EAX:004068ec EBX:00000000 ECX:008058e4 EDX:3e800000 ESI:1013c280 EDI:00000000
the code where eax points is: 0x004068ec EntryPoint+0xffffffff in vietcong: call *0x4e4000 -> 0x00427960 EntryPoint+0xffffffff in vietcong ; < here are made some other calls, like GetCurrentThreadId() and GetTickCount() 0x004068f2 EntryPoint+0xffffffff in vietcong: jmp *%ecx ; < ecx has to be untouched
After the return from call, the registers are (ECX has been changed): Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:004068f2 ESP:0033f5a0 EBP:0033f764 EFLAGS:00000246( - -- I Z- -P- ) EAX:0b5b30b7 EBX:00000000 ECX:0033f590 EDX:00000000 ESI:1013c280 EDI:00000000
So except the GetTickCount(), my guess is that also the GetCurrentThreadId() can not touch the ECX register. I wanted to make some tests for it but now it looks like it would be useless to do.
https://bugs.winehq.org/show_bug.cgi?id=43567
Jan Havran havran.jan@email.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |kernel32
https://bugs.winehq.org/show_bug.cgi?id=43567
--- Comment #7 from Paul Gofman gofmanp@gmail.com --- (In reply to Jan Havran from comment #4)
What is probability of such a situation, when two people fix same issue same day after more than year after report?
I am sorry if I interfered into your work but I had no clue this could happen. I got here after looking into some recent activity on bug info list. I actually was curious about different issues but was hitting this bug in the demo and wanted to track what is up there and sort out somehow (even if only to workaround).
Regarding fixing it, in my understanding it is hardly a bug and both our patches are not a fix but rather application specific workaround.
BTW, you can make it work without any fixes by turning WINEDEBUG=+relay. Relay thunks which are added in this case save some registers (including ecx) and do it for every function in DLL. For this game it can probably be even made acceptable performance wise if disable most of +relay trace output like described here: https://wiki.winehq.org/Debug_Channels#Making_.2Brelay_less_verbose. In my understanding if there is a proper fix for such bugs it lies somewhere around tuning existing relay approach.
https://bugs.winehq.org/show_bug.cgi?id=43567
--- Comment #8 from Jan Havran havran.jan@email.cz --- (In reply to Paul Gofman from comment #7)
I am sorry if I interfered into your work but I had no clue this could happen. I got here after looking into some recent activity on bug info list. I actually was curious about different issues but was hitting this bug in the demo and wanted to track what is up there and sort out somehow (even if only to workaround).
No worries, it just surprised me yesterday little bit...
BTW, you can make it work without any fixes by turning WINEDEBUG=+relay. Relay thunks which are added in this case save some registers (including ecx) and do it for every function in DLL.
I see, now I know why I could not reproduce it with +relay channel. This is interesting information.
I have never sent any patch into Wine, but I agree that our patches wont be simply accepted as they are (the assembler etc.). On the other hand, Wine says "bug for bug", so at least for Windows XP compatibility we should keep the ECX register too, since this application requires it.
This bug is reproducible on Windows >= Vista, but Wine could keep ECX register for all compatibility versions in my opinion.
BTW: this game is broken in many ways as you can see from other bugs and on newer Windows systems it also requires use of VC Starter.
https://bugs.winehq.org/show_bug.cgi?id=43567
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Vietcong - game crashes |Vietcong - game crashes |during radiocalls |during radiocalls | |('kernel32.GetTickCount' | |clobbers ECX) Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Keywords| |download, obfuscation Fixed by SHA1| |cd215bb49bc240cdce5415c8026 | |4f8daa557636a CC| |focht@gmx.net
--- Comment #9 from Anastasius Focht focht@gmx.net --- Hello folks,
this has been fixed some time ago.
I made some effort to document 'kernel32.GetTickCount' API entry point "history" for the sake of those interested (foremost myself).
First the commit that influenced the code generation (via build system/compiler settings, code changes, ...), followed by disassembly to show where/when ECX gets clobbered. NOTE: '(func-1)' is used to work around symbol processing problem for hotpatch entries.
Starting with Wine l33t release (old enough)
--- snip --- $ gdb mainline-install-1.3.37-x86_64/lib/wine/kernel32.dll.so -batch -ex 'disassemble GetTickCount' Dump of assembler code for function GetTickCount: 0x0003f870 <+0>: push %ebp 0x0003f871 <+1>: mov %esp,%ebp 0x0003f873 <+3>: push %ebx 0x0003f874 <+4>: call 0x1f760 <__x86.get_pc_thunk.bx> 0x0003f879 <+9>: add $0x5b787,%ebx 0x0003f87f <+15>: sub $0x4,%esp 0x0003f882 <+18>: call 0x3f820 <GetTickCount64> 0x0003f887 <+23>: mov -0x4(%ebp),%ebx 0x0003f88a <+26>: leave 0x0003f88b <+27>: ret
--- snip ---
https://source.winehq.org/git/wine.git/commitdiff/1005f3a6fa9d1aeb3e0e912815... ("kernel32: Make GetTickCount and GetTickCount64 hotpatchable.")
--- snip --- gdb mainline-install-1.7.33-x86_64/lib/wine/kernel32.dll.so -batch -ex 'disassemble GetTickCount-1'
Dump of assembler code for function GetTickCount: 0x7b843820 <+0>: mov %edi,%edi 0x7b843822 <+2>: push %ebp 0x7b843823 <+3>: mov %esp,%ebp 0x7b843825 <+0>: push %ebx 0x7b843826 <+1>: call 0x7b820770 <__x86.get_pc_thunk.bx> 0x7b84382b <+6>: add $0x707d5,%ebx 0x7b843831 <+12>: and $0xfffffff0,%esp 0x7b843834 <+15>: call 0x7b8437b0 <GetTickCount64> 0x7b843839 <+20>: mov -0x4(%ebp),%ebx 0x7b84383c <+23>: leave 0x7b84383d <+24>: ret
$ gdb mainline-install-1.7.33-x86_64/lib/wine/kernel32.dll.so -batch -ex 'disassemble GetTickCount64-1'
Dump of assembler code for function GetTickCount64: 0x7b8437b0 <+0>: mov %edi,%edi 0x7b8437b2 <+2>: push %ebp 0x7b8437b3 <+3>: mov %esp,%ebp 0x7b8437b5 <+0>: pop %ebp 0x7b8437b6 <+1>: lea 0x4(%esp),%ecx 0x7b8437ba <+5>: and $0xfffffff0,%esp 0x7b8437bd <+8>: pushl -0x4(%ecx) 0x7b8437c0 <+11>: push %ebp 0x7b8437c1 <+12>: mov %esp,%ebp 0x7b8437c3 <+14>: push %ebx 0x7b8437c4 <+15>: call 0x7b820770 <__x86.get_pc_thunk.bx> 0x7b8437c9 <+20>: add $0x70837,%ebx 0x7b8437cf <+26>: push %ecx 0x7b8437d0 <+27>: lea -0x10(%ebp),%eax 0x7b8437d3 <+30>: sub $0x18,%esp 0x7b8437d6 <+33>: push %eax 0x7b8437d7 <+34>: lea -0x18(%ebp),%eax 0x7b8437da <+37>: push %eax 0x7b8437db <+38>: call 0x7b827854 <NtQueryPerformanceCounter> 0x7b8437e0 <+43>: imul $0x3e8,-0x14(%ebp),%ecx 0x7b8437e7 <+50>: mov $0x3e8,%eax 0x7b8437ec <+55>: mull -0x18(%ebp) 0x7b8437ef <+58>: sub $0x8,%esp 0x7b8437f2 <+61>: pushl -0xc(%ebp) 0x7b8437f5 <+64>: pushl -0x10(%ebp) 0x7b8437f8 <+67>: add %ecx,%edx 0x7b8437fa <+69>: push %edx 0x7b8437fb <+70>: push %eax 0x7b8437fc <+71>: call 0x7b87c180 <__divdi3> 0x7b843801 <+76>: add $0x18,%esp 0x7b843804 <+79>: lea -0x8(%ebp),%esp 0x7b843807 <+82>: pop %ecx 0x7b843808 <+83>: pop %ebx 0x7b843809 <+84>: pop %ebp 0x7b84380a <+85>: lea -0x4(%ecx),%esp 0x7b84380d <+88>: ret --- snip ---
https://source.winehq.org/git/wine.git/commitdiff/8f732c66ab37b54c30d63c74f7... ("makefiles: Build with -fno-PIC on i386.")
--- snip --- $ gdb mainline-install-4.8-x86_64/lib/wine/kernel32.dll.so -batch -ex 'disassemble GetTickCount-1'
Dump of assembler code for function GetTickCount: 0x7b45cff0 <+0>: mov %edi,%edi 0x7b45cff2 <+2>: push %ebp 0x7b45cff3 <+3>: mov %esp,%ebp 0x7b45cff5 <+0>: pop %ebp 0x7b45cff6 <+1>: lea 0x4(%esp),%ecx 0x7b45cffa <+5>: and $0xfffffff0,%esp 0x7b45cffd <+8>: pushl -0x4(%ecx) 0x7b45d000 <+11>: push %ebp 0x7b45d001 <+12>: mov %esp,%ebp 0x7b45d003 <+14>: push %ecx 0x7b45d004 <+15>: lea -0x10(%ebp),%eax 0x7b45d007 <+18>: sub $0x1c,%esp 0x7b45d00a <+21>: push %eax 0x7b45d00b <+22>: lea -0x18(%ebp),%eax 0x7b45d00e <+25>: push %eax 0x7b45d00f <+26>: call 0x7b43c298 <NtQueryPerformanceCounter> 0x7b45d014 <+31>: imul $0x3e8,-0x14(%ebp),%ecx 0x7b45d01b <+38>: mov $0x3e8,%eax 0x7b45d020 <+43>: mull -0x18(%ebp) 0x7b45d023 <+46>: sub $0x8,%esp 0x7b45d026 <+49>: pushl -0xc(%ebp) 0x7b45d029 <+52>: pushl -0x10(%ebp) 0x7b45d02c <+55>: add %ecx,%edx 0x7b45d02e <+57>: push %edx 0x7b45d02f <+58>: push %eax 0x7b45d030 <+59>: call 0x7b4a85c0 <__divdi3> 0x7b45d035 <+64>: mov -0x4(%ebp),%ecx 0x7b45d038 <+67>: add $0x18,%esp 0x7b45d03b <+70>: leave 0x7b45d03c <+71>: lea -0x4(%ecx),%esp 0x7b45d03f <+74>: ret --- snip ---
https://source.winehq.org/git/wine.git/commitdiff/3e927c4aec9dbeef930b83f62e... ("ntdll: Extend NtGetTickCount() to return 64-bits. Forward kernel32 functions to it.")
--- snip --- $ gdb mainline-install-4.9-x86_64/lib/wine/kernel32.dll.so -batch -ex 'disassemble GetTickCount-1'
No symbol "GetTickCount" in current context. --- snip ---
https://source.winehq.org/git/wine.git/commitdiff/13e11d3fcbcf8790e031c4bc52... ("kernel32: Move the implementation of GetTickCount() to kernel32.")
--- snip --- $ gdb mainline-install-4.10-x86_64/lib/wine/kernel32.dll.so -batch -ex 'disassemble GetTickCount-1'
Dump of assembler code for function GetTickCount: 0x7b49a3c0 <+0>: mov %edi,%edi 0x7b49a3c2 <+2>: push %ebp 0x7b49a3c3 <+3>: mov %esp,%ebp 0x7b49a3c5 <+0>: pop %ebp 0x7b49a3c6 <+1>: lea 0x4(%esp),%ecx 0x7b49a3ca <+5>: and $0xfffffff0,%esp 0x7b49a3cd <+8>: pushl -0x4(%ecx) 0x7b49a3d0 <+11>: push %ebp 0x7b49a3d1 <+12>: mov %esp,%ebp 0x7b49a3d3 <+14>: push %esi 0x7b49a3d4 <+15>: push %ebx 0x7b49a3d5 <+16>: lea -0x20(%ebp),%ebx 0x7b49a3d8 <+19>: push %ecx 0x7b49a3d9 <+20>: sub $0x24,%esp 0x7b49a3dc <+23>: push %ebx 0x7b49a3dd <+24>: push $0x4 0x7b49a3df <+26>: call 0x7b49a3e0 <GetTickCount+27> 0x7b49a3e4 <+31>: add $0x10,%esp 0x7b49a3e7 <+34>: test %eax,%eax 0x7b49a3e9 <+36>: jne 0x7b49a430 <GetTickCount+107> 0x7b49a3eb <+38>: mov $0x989680,%ecx 0x7b49a3f0 <+43>: mov %ecx,%eax 0x7b49a3f2 <+45>: imull -0x20(%ebp) 0x7b49a3f5 <+48>: mov -0x1c(%ebp),%esi 0x7b49a3f8 <+51>: mov %eax,%ecx 0x7b49a3fa <+53>: mov %edx,%ebx 0x7b49a3fc <+55>: mov %esi,%eax 0x7b49a3fe <+57>: mov $0x51eb851f,%edx 0x7b49a403 <+62>: imul %edx 0x7b49a405 <+64>: sar $0x1f,%esi 0x7b49a408 <+67>: mov %edx,%eax 0x7b49a40a <+69>: sar $0x5,%eax 0x7b49a40d <+72>: sub %esi,%eax 0x7b49a40f <+74>: cltd 0x7b49a410 <+75>: add %ecx,%eax 0x7b49a412 <+77>: adc %ebx,%edx 0x7b49a414 <+79>: push $0x0 0x7b49a416 <+81>: push $0x2710 0x7b49a41b <+86>: push %edx 0x7b49a41c <+87>: push %eax 0x7b49a41d <+88>: call 0x7b4a8c70 <__udivdi3> 0x7b49a422 <+93>: add $0x10,%esp 0x7b49a425 <+96>: lea -0xc(%ebp),%esp 0x7b49a428 <+99>: pop %ecx 0x7b49a429 <+100>: pop %ebx 0x7b49a42a <+101>: pop %esi 0x7b49a42b <+102>: pop %ebp 0x7b49a42c <+103>: lea -0x4(%ecx),%esp 0x7b49a42f <+106>: ret 0x7b49a430 <+107>: sub $0x8,%esp 0x7b49a433 <+110>: push %ebx 0x7b49a434 <+111>: push $0x1 0x7b49a436 <+113>: call 0x7b49a437 <GetTickCount+114> 0x7b49a43b <+118>: add $0x10,%esp 0x7b49a43e <+121>: test %eax,%eax 0x7b49a440 <+123>: jne 0x7b49a450 <GetTickCount+139> 0x7b49a442 <+125>: mov $0x989680,%ebx 0x7b49a447 <+130>: mov %ebx,%eax 0x7b49a449 <+132>: jmp 0x7b49a3f2 <GetTickCount+45> 0x7b49a44b <+134>: lea 0x0(%esi,%eiz,1),%esi 0x7b49a44f <+138>: nop 0x7b49a450 <+139>: sub $0x8,%esp 0x7b49a453 <+142>: lea -0x28(%ebp),%eax 0x7b49a456 <+145>: push $0x0 0x7b49a458 <+147>: push %eax 0x7b49a459 <+148>: call 0x7b43c360 <NtQueryPerformanceCounter> 0x7b49a45e <+153>: mov -0x28(%ebp),%eax 0x7b49a461 <+156>: mov -0x24(%ebp),%edx 0x7b49a464 <+159>: pop %ecx 0x7b49a465 <+160>: pop %ebx 0x7b49a466 <+161>: jmp 0x7b49a414 <GetTickCount+79> --- snip ---
https://source.winehq.org/git/wine.git/commitdiff/cd215bb49bc240cdce5415c802... ("kernel32: Use the user shared data to implement GetTickCount().")
--- snip --- $ gdb mainline-install-5.9-x86_64/lib/wine/kernel32.dll.so -batch -ex 'disassemble GetTickCount-1'
Dump of assembler code for function GetTickCount: 0x7b4551c0 <+0>: mov %edi,%edi 0x7b4551c2 <+2>: push %ebp 0x7b4551c3 <+3>: mov %esp,%ebp 0x7b4551c5 <+0>: mov 0x7ffe0320,%eax 0x7b4551ca <+5>: pop %ebp 0x7b4551cb <+6>: ret --- snip ---
https://source.winehq.org/git/wine.git/commitdiff/0c631ebb2354334eaf309bc076... ("kernel32: Build with msvcrt.")
--- snip --- $ gdb mainline-install-5.19-x86_64/lib/wine/kernel32.dll -batch -ex 'disassemble GetTickCount'
Dump of assembler code for function KERNEL32!GetTickCount: 0x7b6257c0 <+0>: push %ebp 0x7b6257c1 <+1>: mov %esp,%ebp 0x7b6257c3 <+3>: mov 0x7ffe0320,%eax 0x7b6257c8 <+8>: pop %ebp 0x7b6257c9 <+9>: ret --- snip ---
HEAD: wine-5.22-328-g447924a6d68 -> will be included in wine-5.23
https://source.winehq.org/git/wine.git/commitdiff/5a0c9270b1225da86782bffd9e... ("include: Force aligning stack pointer also for Mingw builds.")
--- snip --- $ gdb mainline-install-x86_64/lib/wine/kernel32.dll -batch -ex 'disassemble GetTickCount'
Dump of assembler code for function KERNEL32!GetTickCount: 0x7b622970 <+0>: push %ebp 0x7b622971 <+1>: mov %esp,%ebp 0x7b622973 <+3>: and $0xfffffffc,%esp 0x7b622976 <+6>: mov 0x7ffe0320,%eax 0x7b62297b <+11>: mov %ebp,%esp 0x7b62297d <+13>: pop %ebp 0x7b62297e <+14>: ret --- snip ---
Regards
https://bugs.winehq.org/show_bug.cgi?id=43567
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.0-rc1.
https://bugs.winehq.org/show_bug.cgi?id=43567
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.moddb.com/games/ |https://web.archive.org/web |vietcong/downloads/vietcong |/20201204222821/http://down |-singleplayer-demo |load.fileplanet.com/ftp1/05 | |2003/2010-11-01-vietcong-si | |ngle-player-demo.exe?st=vna | |wqpnoywiF8Aymgqz1wg&e=16071 | |31575
--- Comment #11 from Anastasius Focht focht@gmx.net --- Hello folks,
adding stable link from Internet Archive for documentation:
https://web.archive.org/web/20201204222821/http://download.fileplanet.com/ft...
$ sha1sum 2010-11-01-vietcong-single-player-demo.exe 69b8667adef8fda0f2f0cda572b1b4fe0b1bdb31 2010-11-01-vietcong-single-player-demo.exe
$ du -sh 2010-11-01-vietcong-single-player-demo.exe 100M 2010-11-01-vietcong-single-player-demo.exe
Regards
-
wine-bugs＠winehq.org -
WineHQ Bugzilla