[Bug 37358] New: FEAR 1: Installer says "wrong serial" even if entered correctly
https://bugs.winehq.org/show_bug.cgi?id=37358 Bug ID: 37358 Summary: FEAR 1: Installer says "wrong serial" even if entered correctly Product: Wine Version: 1.7.7 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: msvcp Assignee: wine-bugs(a)winehq.org Reporter: wylda(a)volny.cz I cant' install F.E.A.R. 1, because installer asks for serial like 1111-2222-3333-4444-5555 and complains that serial is wrong even if entered it correctly. This is a regression caused by commit wine-1.7.6-48-g949a8af: commit 949a8afdaf394a588209c3ee7692630c90b32e22 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Tue Nov 12 12:51:51 2013 +0100 msvcp71: Share part of the implementation with msvcp90. Revert of this patch makes that problem go away. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 Wylda <wylda(a)volny.cz> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |julliard(a)winehq.org, | |piotr(a)codeweavers.com Regression SHA1| |949a8afdaf394a588209c3ee769 | |2630c90b32e22 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 Piotr Caban <piotr.caban(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban(a)gmail.com --- Comment #1 from Piotr Caban <piotr.caban(a)gmail.com> --- This patch causes builtin msvcp71 dll to be preferred over native one. It probably never worked with builtin dll. Please attach a tid,seh,msvcp,relay log. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 --- Comment #2 from Wylda <wylda(a)volny.cz> --- I sent you a link for download of the log as it has 4megs and also shows my legal serial number. Thank you. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 --- Comment #3 from Piotr Caban <piotr.caban(a)gmail.com> --- Created attachment 49704 --> https://bugs.winehq.org/attachment.cgi?id=49704 Return NULL in basic_string_char dtor Could you please give this patch a try? The application is using only few functions from msvcp71, namely: basic_string_char_ctor basic_string_char_ctor_cstr basic_string_char_assign_ch basic_string_char_dtor The only difference I can see is that native returns NULL in basic_string_char_dtor (or uses EAX internally and lives it set to 0). I couldn't find anything about value returned by destructors in abi descriptions. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 --- Comment #4 from Piotr Caban <piotr.caban(a)gmail.com> --- I've checked that destructor is not supposed to change EAX register value on return. In this case it's some kind of side effect. I'm not sure what's the correct way of fixing it if fear1 depends on this behavior. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 --- Comment #5 from Wylda <wylda(a)volny.cz> ---
Could you please give this patch a try?
The patch fixes to problem. Thank you. By the comment 4 you mean, that the patch isn't correct solution? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 Michael Müller <michael(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michael(a)fds-team.de --- Comment #6 from Michael Müller <michael(a)fds-team.de> --- Hi, I wrote a test which proves that Windows always returns 0. The test including a patch (which basically does the same as the one by Piotr) is available at: https://github.com/wine-compholio/wine-staging/tree/master/patches/msvcp60-b... @Piotr: Did you maybe forget to alter the Wine's assembler wrapper, which is used to call fastcall functions, in your tests? It uses eax as temporary storage for the return address. Regards, Michael -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de --- Comment #7 from Sebastian Lackner <sebastian(a)fds-team.de> --- @Michael: The return value doesn't really seem to be consistent, and is different for many Windows versions. See: http://newtestbot.winehq.org/JobDetails.pl?Key=9387 I doubt that the app really relies on that. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 --- Comment #8 from Piotr Caban <piotr.caban(a)gmail.com> --- (In reply to Wylda from comment #5)
By the comment 4 you mean, that the patch isn't correct solution? The application ships msvcp71.dll, so it can depend on very version specific behavior. The fact that it sets EAX to 0 is only a side effect that may be not preserved between different version of msvcp71, it can probably even change if it's compiled with different optimization level.
(In reply to Michael Müller from comment #6)
@Piotr: Did you maybe forget to alter the Wine's assembler wrapper, which is used to call fastcall functions, in your tests? It uses eax as temporary storage for the return address. It's not a problem, the assembler just sets EAX to non-zero value. Comparing it later to 0 is OK. You don't need to change it in this case.
You're also changing different version of dll. I'm changing msvcp71/.../msvcp90 and testing it on msvcp90, you're doing it for msvcp60. Here are the tests results for msvcp90: https://testbot.winehq.org/JobDetails.pl?Key=9389 According to them EAX is always set to 0 when 32-bit tests are run. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 --- Comment #9 from Wylda <wylda(a)volny.cz> --- (In reply to Piotr Caban from comment #8)
The application ships msvcp71.dll, so it can depend on very version specific behavior.
I did the oposite to ?proove? that it is independent on that specific version. I took the fear installation, removed its msvcp71.dll & msvcr71.dll and tried to install it on win8.1 64bit with win8.1's default msvcp71.dll. It worked without any problem. c:\Windows\SysWOW64\msvcp71.dll v7.10.3077.0 SHA1: c8ccb04eedac821a13fae314a2435192860c72b8 *msvcp71.dll FEAR's msvcp71.dll v7.10.2292.0 SHA1: d910576c6d62ad16de06aa4df96ab1e89260b7a5 *msvcp71.dll Maybe such mystery bug could attract Focht's attention ;) for deeper look. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 --- Comment #10 from Michael Müller <michael(a)fds-team.de> --- Hi, seems like I was a bit to tired yesterday and altered msvcp60 instead of msvcp90. The updated patch and test is available at https://github.com/wine-compholio/wine-staging/tree/master/patches/msvcp90-b... Running it on the test server proofs Piotr's theory that the function should always return null. Although these patches seem to be correct, I think it is still mysterious that the FEAR 1 installer depends on a return value of a void function. This error might happen if you write plain assembler code, but a C compiler should not do this. It might also be possible that these patches only work around a different bug in Wine. Maybe some other Wine function should alter the value of eax but fails to do so. Regards, Michael -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.gamershell.com/d | |ownload_15886.shtml CC| |gyebro69(a)gmail.com --- Comment #11 from Béla Gyebrószki <gyebro69(a)gmail.com> --- This bug (regression) affects Medieval II: Total War. You can reproduce the problem with the demo version: http://www.gamershell.com/download_15886.shtml The demo starts fine to the menu but you'll receive an error message when you start one of the battles available in the demo: "Medieval 2: Total War encountered an unspecified error and will now exit." The game comes with it's own msvcp71,msvcr71. If I set msvcp71=native then the crash doesn't occur. Note: the game hits bug #35718 so you'll likely get very low fps in the menus. wine-1.7.35-24-g3873c93 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 Piotr Caban <piotr.caban(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|download | URL|http://www.gamershell.com/d | |ownload_15886.shtml | --- Comment #12 from Piotr Caban <piotr.caban(a)gmail.com> --- (In reply to Béla Gyebrószki from comment #11)
This bug (regression) affects Medieval II: Total War. This is a different bug. Please report a separate bug for this issue (it should be fixed by http://source.winehq.org/patches/data/108871).
-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 --- Comment #13 from Béla Gyebrószki <gyebro69(a)gmail.com> --- (In reply to Piotr Caban from comment #12)
(In reply to Béla Gyebrószki from comment #11)
This bug (regression) affects Medieval II: Total War. This is a different bug. Please report a separate bug for this issue (it should be fixed by http://source.winehq.org/patches/data/108871).
Bug #37987 was opened for the issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 --- Comment #14 from Wylda <wylda(a)volny.cz> --- (In reply to Sebastian Lackner from comment #7)
@Michael: The return value doesn't really seem to be consistent, and is different for many Windows versions. See: http://newtestbot.winehq.org/JobDetails.pl?Key=9387
I doubt that the app really relies on that.
@Sebastian: I guess that this link is no longer showing ID 9387. I got an idea to test this installer on real windows, which are not "consistent". Thus we will see, if this is some other kind of wine's insufficiency or the installer _really_ depends on returning the zero. Do you remember, which Windows version behaved inconsistently? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 Paul Bredbury <brebs(a)sent.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brebs(a)sent.com --- Comment #15 from Paul Bredbury <brebs(a)sent.com> --- Wine 1.7.42 still has this bug in FEAR 1, where the serial code is treated as invalid. The patch in comment #3 fixes the serial code entry :) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 Michael Müller <michael(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/msvcp90-basic_ | |string_dtor -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |27b5c93609ee3dad24d4fa7aeaa | |f1d4ba2d2ae4b Status|STAGED |RESOLVED Resolution|--- |FIXED --- Comment #16 from Sebastian Lackner <sebastian(a)fds-team.de> --- The patch was accepted in http://source.winehq.org/git/wine.git/commit/27b5c93609ee3dad24d4fa7aeaaf1d4..., marking fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37358 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #17 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 1.8-rc2. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org