[Bug 58963] New: Stratego (1997) fails to start
http://bugs.winehq.org/show_bug.cgi?id=58963 Bug ID: 58963 Summary: Stratego (1997) fails to start Product: Wine Version: 10.18 Hardware: x86-64 URL: https://archive.org/details/STRATEGO OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: tobbi.bugs(a)googlemail.com CC: jeremielapuree(a)yahoo.fr, z.figura12(a)gmail.com Created attachment 79665 --> http://bugs.winehq.org/attachment.cgi?id=79665 log with bidi and font channels enabled +++ This bug was initially created as a clone of Bug #58942 +++ ** NOTE: ** I created this bug because I was asked to create a separate bug for the issue that occurs while starting the game. See https://bugs.winehq.org/show_bug.cgi?id=58942#c8 % wine --version wine-10.18 % openssl sha256 STRATEGO.iso SHA2-256(STRATEGO.iso)= e82340b5e23554618dfe406c102ca2a793b34e49723e921e5cc6a5911a9867e1 I'm trying to install Stratego from here: https://archive.org/details/STRATEGO Steps to reproduce: 1. Download the ISO and mount it on your system. 2. Change the configuration options of Wine to map E: to the path where the ISO image was mounted, as well as the Operating System to Windows XP (or Windows 98 - shouldn't matter) 3. Install Stratego by running the SETUP.EXE file with wine. 4. Start Stratego by running the Stratego.exe in C:/Program Files (x86)/Hasbro Interactive/Stratego/Stratego.exe Expected Result: Stratego starts Actual result: Error message "Unable to 'CreateScalableFontResource()'" === joaopa 2025-11-10 16:55:21 CET Created attachment 79644 [details] log with bidi and font channels enabled In the log on can read : 0128:trace:bidi:CreateScalableFontResourceW (1, L"C:\\Program Files (x86)\\Hasbro Interactive\\Stratego\\Ly2.for", L"C:\\windows\\system32\\Ly2.ttr", (null)) === joaopa 2025-11-10 21:35:08 CET in relay one can read 00b4:Call KERNEL32.HeapFree(7ffffe320000,00000000,00000000) ret=6ffffea85eba 00f4:Call KERNEL32.GetFullPathNameA(015c873c "Grfx\\Ly2.enc",00000104,0022f900,0022f8d0) ret=00469a34 0034:Call ucrtbase.strchr(7ffffe3bec40 "application/x-kourse:*.course\n",0000000a) ret=14000338b 00b4:Ret KERNEL32.HeapFree() retval=00000001 ret=6ffffea85eba 00f4:Call ntdll.RtlInitAnsiString(0022f4f0,015c873c "Grfx\\Ly2.enc") ret=7b613a62 0034:Ret ucrtbase.strchr() retval=7ffffe3bec5d ret=14000338b 00b4:Call KERNEL32.HeapFree(7ffffe320000,00000000,00000000) ret=6ffffea85ec7 00f4:Ret ntdll.RtlInitAnsiString() retval=0000000d ret=7b613a62 0034:Call ucrtbase.strchr(7ffffe3bec40 "application/x-kourse:*.course",0000003a) ret=140003417 00b4:Ret KERNEL32.HeapFree() retval=00000001 ret=6ffffea85ec7 00f4:Call ntdll.RtlAnsiStringToUnicodeString(7ffc2bf8,0022f4f0,00000000) ret=7b613aae 0034:Ret ucrtbase.strchr() retval=7ffffe3bec54 ret=140003417 00b4:Ret ucrtbase._wcsicmp() retval=00000003 ret=6ffffb9e64d2 00f4:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=7b613aae 0034:Call ucrtbase.malloc(00000020) ret=14000342f 00b4:Call ucrtbase._wcsicmp(7fffff2fe080 L"Strings",7ffffe3ce62a L"DestinationDirs") ret=6ffffb9e64d2 00f4:Call ntdll.RtlGetFullPathName_U(7ffc2c00 L"Grfx\\Ly2.enc",00000208,0022f528,0022f524) ret=7b5c5dc3 but I do not know what it means. but Ly2.for and Ly2.ttr don't exist. That is surely the culprit === Tobias (:Tobbi) Markus 2025-11-10 22:02:59 CET I just got myself a complete WINEDEBUG=+all log. I noticed the following line there: 678335.510:00d4:00d8:trace:file:NtCreateFile handle=0x1001ff3f8 access=80100080 name=L"\\??\\C:\\Program Files (x86)\\Hasbro Interactive\\Stratego\\Ly2.for" objattr=00000040 root=0x0 sec=0x0 io=0x1001ff400 alloc_size=0x0 attr=00000080 sharing=00000000 disp=1 options=00000060 ea=0x0.0x00000000 It looks like the application is creating the file itself, but failing. I'll upload the log in a few. === Tobias (:Tobbi) Markus 2025-11-11 00:53:32 CET I have tried Stratego on an old Windows XP VM, where it works. === Tobias (:Tobbi) Markus 2025-11-11 17:44:49 CET I just created a batch file that continuously prints the contents of the "C:/Program Files/Hasbro Interactive/Stratego" directory and I noticed that, indeed, the Ly2.for file is created after the application started and removed again on exit: ``` :loop dir "C:/Programme/Hasbro Interactive/Stratego" ping -n 6 127.0.0.1 > nul goto loop ``` (In case you're wondering, the ping command is to imitate a "sleep for 5 seconds, so you don't get overwhelmed with messages"). -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 Tobias (:Tobbi) Markus <tobbi.bugs(a)googlemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Stratego (1997) fails to |Stratego (1997) fails to |start |start with error message | |"Unable to | |'CreateScalableFontResource | |()'" -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #1 from Tobias (:Tobbi) Markus <tobbi.bugs(a)googlemail.com> --- Created attachment 79666 --> http://bugs.winehq.org/attachment.cgi?id=79666 WINEDEBUG=+all 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #2 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- From the log I can see that it alternates between `C:\\windows\\syswow64\\Ly2.ttr`, but is looking for the file in `C:\\windows\\system32\\Ly2.ttr`. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #3 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- I added the following changes: diff --git a/dlls/wow64/file.c b/dlls/wow64/file.c index 09a455e0ae1..2b8701d399a 100644 --- a/dlls/wow64/file.c +++ b/dlls/wow64/file.c @@ -132,7 +132,8 @@ BOOL get_file_redirect( OBJECT_ATTRIBUTES *attr ) static const WCHAR * const no_redirect[] = { L"system32\\catroot", L"system32\\catroot2", L"system32\\driversstore", - L"system32\\drivers\\etc", L"system32\\logfiles", L"system32\\spool" + L"system32\\drivers\\etc", L"system32\\logfiles", L"system32\\spool", + L"system32\\Sw.ttr", L"system32\\Ly2.ttr" }; static const WCHAR windirW[] = L"\\??\\C:\\windows\\"; const WCHAR *name = attr->ObjectName->Buffer; And with those changes recompiled, the error message is different, so my suspicion that it looks for the files in the wrong location was correct. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #4 from Zeb Figura <z.figura12@gmail.com> --- Created attachment 80154 --> http://bugs.winehq.org/attachment.cgi?id=80154 patch I don't know why it fails on my Windows 7 machine, but this patch makes it work (both on 32-bit and 64-bit prefixes). It appears that AddFontResource() is also supposed to look in C:\windows\system32\. I also needed a quick patch to ddrawex to prevent a crash. I'll add tests and send it upstream soon. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #5 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- (In reply to Zeb Figura from comment #4)
Created attachment 80154 [details] patch
I don't know why it fails on my Windows 7 machine, but this patch makes it work (both on 32-bit and 64-bit prefixes). It appears that AddFontResource() is also supposed to look in C:\windows\system32\. I also needed a quick patch to ddrawex to prevent a crash.
I'll add tests and send it upstream soon.
I tested the patch on top of Wine 11 without the changes outlined in https://bugs.winehq.org/show_bug.cgi?id=58963#c3 and unfortunately, I'm still getting the same error. I tried setting the OS to Windows XP and still the same. Am I doing something wrong? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #6 from Zeb Figura <z.figura12@gmail.com> --- (In reply to Tobias (:Tobbi) Markus from comment #5)
I tested the patch on top of Wine 11 without the changes outlined in https://bugs.winehq.org/show_bug.cgi?id=58963#c3 and unfortunately, I'm still getting the same error. I tried setting the OS to Windows XP and still the same. Am I doing something wrong?
Not sure; it works for me, at least with a fresh prefix. Can you attach a log with WINEDEBUG=+font,+bidi,+file,+server please? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #7 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- Created attachment 80164 --> http://bugs.winehq.org/attachment.cgi?id=80164 WINEDEBUG=+font,+bidi,+file,+server log for clean wineprefix with patch applied -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #8 from Alexandre Julliard <julliard@winehq.org> --- Note that with new wow64 it will need to handle system32 redirection. This would also need test cases. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #9 from Zeb Figura <z.figura12@gmail.com> --- (In reply to Alexandre Julliard from comment #8)
Note that with new wow64 it will need to handle system32 redirection. This would also need test cases.
I don't think there's actually redirection going on here. I'm not sure why comment 3 would have made a difference. According to my testing, AddFontResource() in a 32-bit program checks C:\windows\syswow64 and not C:\windows\system32. As mentioned I will write tests. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #10 from Zeb Figura <z.figura12@gmail.com> --- Oh I see the problem, these ntgdi calls just don't do path conversion in wow64win at all. So it manually creates C:\windows\system32\ly2.ttr, which is redirected, but then CreateScalableFontResource ends up trying to open C:\windows\system32\ly2.ttr and nothing redirects it. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #11 from Zeb Figura <z.figura12@gmail.com> --- Okay, it's worse. CreateScalableFontResource() doesn't handle redirection on Windows. At all. If you put a font in syswow64, CreateScalableFontResource() fails unless you explicitly pass syswow64 to it. This is almost certainly why the program just doesn't work on Windows 7 or newer. It probably does work fine if you run it in on a 32-bit machine. If we're deprecating 32-bit prefixes, what should we do here? Fix Microsoft's bug for them, or declare this WONTFIX? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #12 from Alexandre Julliard <julliard@winehq.org> --- Well, if we wanted to do a better job than Microsoft, we could do some ad-hoc redirection like we do for MOVEFILE_DELAY_UNTIL_REBOOT, cf. redirect_path() in dlls/kernelbase/file.c. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #13 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- (In reply to Alexandre Julliard from comment #12)
Well, if we wanted to do a better job than Microsoft, we could do some ad-hoc redirection like we do for MOVEFILE_DELAY_UNTIL_REBOOT, cf. redirect_path() in dlls/kernelbase/file.c.
Just saying that I would of course appreciate a fix. :) Unfortunately, my skills and knowledge of the Wine source code is fairly limited. One thing I'm wondering: If you set the wine version to Windows 98 in `winecfg`, wouldn't that mean that the behaviour of Windows 98 should be emulated, so the issue has to get "fixed", no matter what? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #14 from Zeb Figura <z.figura12@gmail.com> --- (In reply to Tobias (:Tobbi) Markus from comment #13)
One thing I'm wondering: If you set the wine version to Windows 98 in `winecfg`, wouldn't that mean that the behaviour of Windows 98 should be emulated, so the issue has to get "fixed", no matter what?
The problem is that this isn't really a version behaviour; it's more about the machine type. A 32-bit Windows 10 machine should also work well. We've decided to deprecate support for 32-bit prefixes in the hopes that all applications work in wow64. I'm personally concerned that's not the case; some applications are simply buggy (and, in other cases, apparently Microsoft is the one that's buggy.) But I don't think we've found any insurmountable problems yet, at least if you take cases like this as being possible to just fix Microsoft's bug for them and hope nothing else depends on it. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58963 --- Comment #15 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- (In reply to Zeb Figura from comment #4)
Created attachment 80154 [details] patch
I don't know why it fails on my Windows 7 machine, but this patch makes it work (both on 32-bit and 64-bit prefixes). It appears that AddFontResource() is also supposed to look in C:\windows\system32\. I also needed a quick patch to ddrawex to prevent a crash.
I'll add tests and send it upstream soon.
Thank you so much for the patch, by the way. Could you add the tests and push it upstream? -- 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 (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla