February 2024 - Wine-bugs - list.winehq.org

[Bug 6254] riched32: Various Programms need EM_FORMATRANGE (Installer infinite loop from richtext error / wordpad: Printed Page is only white / Also affected: Half-Life, Endnote X5 Demo, ZMud, MukClient )
by WineHQ Bugzilla 26 Feb '24

26 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=6254 Alban Browaeys <prahal(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |prahal(a)yahoo.com --- Comment #93 from Alban Browaeys <prahal(a)yahoo.com> --- > James McKenzie 2011-05-07 23:15:14 UTC > > This bug has not been forgotten, but AJ wanted this function implemented in a different way that is correct. First EM_DISPLAYBAND must be implemented and then EM_FORMATRANGE. This is being investigated. Could we have the plan AJ envisioned? I doubt he will implement it himself nowadays. So at least someone else could implement it. Right now, we know AJ will not accept anything out of his plan, but we do not know what is the plan. Or is the plan only that EM_DISPLAYBAND must be implemented first then EM_FORMATRANGE? I have been paying for crossover since 2003 to contribute financially. There were a lot of improvements in a lot of domains. But 1 in the 10 Windows apps I use on Linux is broken by this missing feature: (endless loop of: 01b0:fixme:richedit:editor_handle_message EM_FORMATRANGE: stub 01b0:fixme:richedit:editor_handle_message EM_FORMATRANGE: stub). I would like to get rid of this riched20 native dll. I have been looking at this bug for more than 15 years... I know AJ is great but he is not eternal. If at least we could know what he wants for riched20 to implement this function. -- 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.

1 0

[Bug 47152] New: SIMATIC WinCC V15.1 Runtime installer needs 'Schtasks.exe ' to support '/SC <schedule>' option
by wine-bugs＠winehq.org 25 Feb '24

25 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=47152 Bug ID: 47152 Summary: SIMATIC WinCC V15.1 Runtime installer needs 'Schtasks.exe' to support '/SC <schedule>' option Product: Wine Version: 4.7 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: taskschd Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, as it says. Resuming the installation after a simulated reboot doesn't happen due to that (running installer again will mitigate this). --- snip --- $ pwd /home/focht/Downloads/SIMATIC WinCC Runtime Advanced V15.1 $ WINEDEBUG=+loaddll,+process,+seh wine ./Start.exe >>log.txt 2>&1 ... 0150:trace:process:CreateProcessInternalW app (null) cmdline L"\"schtasks.exe\" /create /RU SYSTEM /sc onlogon /tn \"ContinueAfterReboot_WinCC_Runtime_Advanced_V15.1_15.1.0\" /f /rl highest /tr \"\\\"C:\\Program Files (x86)\\Common Files\\Siemens\\Automation\\Siemens Installer Assistant\\406\\Start.bat\\\" \"" ... 0150:trace:process:CreateProcessInternalW starting L"C:\\windows\\system32\\schtasks.exe" as Win32 binary (400000-42c000, x86) ... 0150:trace:process:CreateProcessInternalW started process pid 0127 tid 017c ... 017c:fixme:schtasks:create_command Unsupported /ru option L"SYSTEM" 017c:fixme:schtasks:create_command Unsupported argument L"/sc" ... --- snip --- App installer log: --- snip --- ... 11:43:39|.. |ExecutionEngine::StartNextStepAsync() |(01) Getting next step of execution: ImmediateReboot (), BeforeStart 11:43:39|.. |ExecutionEngine::StartNextStepAsync() |(01) Creating execution worker for the step... 11:43:39| |ExecutionEngine::StartNextStepAsync() | 11:43:39| |ExecutionEngine::StartNextStepAsync() |(01) START executing step ImmediateReboot (), Executing 11:43:39|... |ExecutionTime::OnStepStart() |(01) OnStepStart: non existing stepImmediateReboot (), Executing 11:43:39| |nstallation::CreateRestartEntryStartup()| 11:43:39| |nstallation::CreateRestartEntryStartup()|(16) START creating restart entry 11:43:39|.. |nstallation::CreateRestartEntryStartup()|(16) Executable to use after restart: C:\Program Files (x86)\Common Files\Siemens\Automation\Siemens Installer Assistant\406\Start.exe 11:43:39|.. |nstallation::CreateRestartEntryStartup()|(16) Using Task Scheduler 2.0 approach: 6.1.7601.65536 11:43:39|.. |nstallation::CreateRestartEntryStartup()|(16) Start creating task in the task scheduler. Name: ContinueAfterReboot_WinCC_Runtime_Advanced_V15.1_15.1.0; EXE: C:\Program Files (x86)\Common Files\Siemens\Automation\Siemens Installer Assistant\406\Start.exe; ARGS: /afterreboot /bundlepath=\"Z:\HOME\FOCHT\DOWNLOADS\SIMATIC WINCC RUNTIME ADVANCED V15.1\InstData\" 11:43:39|INFO1 |TaskScheduler::CreateTask() |(16) Logged user name mistatches impersonalized user name: SYSTEM and focht 11:43:39|INFO1 |TaskScheduler::CreateTask() |(16) Impersonalized process detected - create batch file for restart 11:43:39|.. |TaskScheduler::RunSchtasksSilent() |(16) Starting... schtasks.exe /create /RU SYSTEM /sc onlogon /tn "ContinueAfterReboot_WinCC_Runtime_Advanced_V15.1_15.1.0" /f /rl highest /tr "\"C:\Program Files (x86)\Common Files\Siemens\Automation\Siemens Installer Assistant\406\Start.bat\" " 11:43:39|.. |TaskScheduler::RunSchtasksSilent() |(16) Finished schtasks.exe. Return code: 1 11:43:39|INFO1 |TaskScheduler::CreateTask() |(16) Task creation failed. Details: Error: 1; Details: 11:43:39|INFO1 |nstallation::CreateRestartEntryStartup()|(16) Task creation failed. 11:43:39|. |nstallation::CreateRestartEntryStartup()|(16) END creating restart entry 11:43:39|. |nstallation::CreateRestartEntryStartup()| 11:43:39|.. |ExecutionEngine::WorkerCompleted() |(01) Result of step execution: Result of 'InstallResultClass', Setup Succeeded: True; Reboot Required: NoReboot; Child Results Count: 0; Details: Return Value = 0; Recogrinzed as: Success 11:43:39|. |ExecutionEngine::WorkerCompleted() |(01) END executing step ImmediateReboot (), Complete 11:43:39|. |ExecutionEngine::WorkerCompleted() | 11:43:39|... |ExecutionTime::OnStepCompleted() |(01) OnStepCompleted: ImmediateReboot (), Complete ... --- snip --- Microsoft docs: https://docs.microsoft.com/en-us/windows/desktop/taskschd/schtasks --- quote --- ... /SC schedule A value that specifies the schedule frequency. Valid values are: MINUTE, HOURLY, DAILY, WEEKLY, MONTHLY, ONCE, ONLOGON, ONIDLE, and ONEVENT. ... /MO modifier A value that refines the schedule type to allow for finer control over the schedule recurrence. Valid values are: MINUTE: 1 - 1439 minutes. HOURLY: 1 - 23 hours. DAILY: 1 - 365 days. WEEKLY: weeks 1 - 52. ONCE: No modifiers. ONSTART: No modifiers. ONLOGON: No modifiers. ONIDLE: No modifiers. MONTHLY: 1 - 12, or FIRST, SECOND, THIRD, FOURTH, LAST, and LASTDAY. ONEVENT: XPath event query string. --- quote --- Wine source: https://source.winehq.org/git/wine.git/blob/HEAD:/programs/schtasks/schtask… $ sha1sum SIMATIC_WinCC_Runtime_Advanced_V15_1.exe db1f97bb648b62fa1c5d974d7f2bcb6b4a9fd786 SIMATIC_WinCC_Runtime_Advanced_V15_1.exe $ du -sh SIMATIC_WinCC_Runtime_Advanced_V15_1.exe 1.3G SIMATIC_WinCC_Runtime_Advanced_V15_1.exe $ wine --version wine-4.7-305-g9bcaf9769c Regards -- 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.

2 3

[Bug 56364] New: Crazy Factory: Hang when starting new game
by WineHQ Bugzilla 25 Feb '24

25 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=56364 Bug ID: 56364 Summary: Crazy Factory: Hang when starting new game Product: Wine Version: 9.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: winebugzilla(a)tasossah.com Distribution: --- Created attachment 76101 --> https://bugs.winehq.org/attachment.cgi?id=76101 Minimal reproducible example: client Crazy Factory (AppID 13494, also known as Gadget Tycoon) hangs when starting a new game (Main Menu -> Offline game -> Freeplay). This is not a regression, but has last been tested under wine-staging 9.2. The game (client) spawns the server (CrazyFactoryServer.exe), waits for it to finish initialising by calling WaitForSingleObject() and WaitForInputIdle(), and then looks for its HWND so that it can communicate with it using window messages. I have written a standalone test case which reproduces this issue in Wine without requiring access to the original software. To reproduce: 1. Download client.c and server.c 2. Compile them as follows: - i686-w64-mingw32-gcc server.c -l ole32 -mwindows -o server.exe - i686-w64-mingw32-gcc client.c -o client.exe 3. Run client.exe Under Windows XP: client.exe reports "HWND Found" and exits. Under Wine: client.exe hangs on WaitForInputIdle(). The only way in Wine to get WaitForInputIdle() to return is by running everything in a virtual desktop, clicking on the start menu (which makes the server show up in the taskbar), clicking on the server in the taskbar, and then clicking on the server's window decoration and moving it around. Unfortunately, since the game itself runs in fullscreen, one can not click and drag the server window. Instead, to get the game working as-is, one can patch the binary (556b01b1afa97f39d361fe692bc3477a2577a25abf91f4a92e88a561bd5bd561 GadgetTycoon.exe) by setting the byte at offset 0x241ED from 0xFF to 0x01. This sets the dwMilliseconds parameter on WaitForInputIdle() to 0x01 (instead of INFINITE), which makes it time out, thus avoiding the hang and getting the game running. -- 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.

1 5

[Bug 56366] New: Worms Blast characters become grey/untextured
by WineHQ Bugzilla 24 Feb '24

24 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=56366 Bug ID: 56366 Summary: Worms Blast characters become grey/untextured Product: Wine Version: 9.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: iodreamify(a)gmail.com Distribution: --- Created attachment 76106 --> https://bugs.winehq.org/attachment.cgi?id=76106 wine log If you play a game vs cpu, when 2 characters are on screen, one or both of them will become grey as if they're untextured. Sometimes it's the whole character and sometime only their weapon or boat. It doesn't seem to be tied to any action or event, they'll become grey and then rendered correctly again with color. Tested this with Wine 9.3 inside Wine Steam. Also, in puzzle mode, when there's a single player, it doesn't seem to happen as fast or at all. Steps to reproduce: 1. open game 2. choose game vs cpu 3. select deathmatch 4. swim around in game a bit Kernel Version: 6.7.5-arch1-1 (64-bit) mesa 24.0.1-1 Graphics Platform: X11 Graphics Processor: Mesa Intel® HD Graphics 3000 -- 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.

1 1

[Bug 54346] New: (Multithreaded) Applications sometimes get heap corruption on exit due to ignoring critical sections in Wine
by WineHQ Bugzilla 24 Feb '24

24 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=54346 Bug ID: 54346 Summary: (Multithreaded) Applications sometimes get heap corruption on exit due to ignoring critical sections in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: dmusic Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- (Multithreaded) Applications sometimes get heap corruption on exit due to ignoring critical sections in Wine. For instance dmloader:loader: 0118:warn:sync:RtlpWaitForCriticalSection process L"Z:\\home\\fgouget\\wine\\wine-gitlab\\dlls\\dmloader\\tests\\i386-windows\\dmloader_test.exe" is shutting down, returning STATUS_SUCCESS ... 0118:warn:sync:RtlpWaitForCriticalSection process L"Z:\\home\\fgouget\\wine\\wine-gitlab\\dlls\\dmloader\\tests\\i386-windows\\dmloader_test.exe" is shutting down, returning STATUS_SUCCESS 0118:err:sync:RtlLeaveCriticalSection section 00140074 "dlls/ntdll/heap.c: main process heap section" is not acquired Normally this does not cause the test to fail. But when running with WINEDEBUG=heap this frequently leads to heap corruption because: * Each call to the heap API triggers a heap validation. * Each heap_validate() call is requires taking the main process heap lock. * More contention makes the "not acquired" events more likely. * Leading to multiple threads manipulating the heap at the same time, thus causing corruption. Also, be aware that when heap corruption is detected due to WINEDEBUG=heap, Wine raises an exception which kills the process. Also note that although dmloader:loader looks like it is not multithreaded (no CreateThread() call), it loads dlls that create their own thread: * winealsa.drv/midi.c -> notify_thread * winealsa.drv/mmdevdrv.c -> alsa_timer_thread * winepulse.drv/mmdevdrv.c -> pulse_mainloop_thread, pulse_timer_cb ...etc. So this issue probably impacts most audio / multimedia applications and Wine tests. The "main process heap section is not acquired" errors most often look like they are caused by the following functions which are all called on DLL_PROCESS_DETACH: * msacm32.MSACM_WriteCache() calling RegSetValueExA() * ucrtbase.msvcrt_free_io() calling DeleteCriticalSection() when WINEDEBUG=heap Ignoring the critical sections during shutdown is intentional and was introduced by the 7def0f200f11 commit to fix bug 42470. See RtlpWaitForCriticalSection(): /* Don't allow blocking on a critical section during process termination */ if (RtlDllShutdownInProgress()) { WARN( "process %s is shutting down, returning STATUS_SUCCESS\n", debugstr_w(NtCurrentTeb()->Peb->ProcessParameters->ImagePathName.Buffer) ); return STATUS_SUCCESS; } However that commit also had to add todo_wine statements to kernel32:loader so it's not clear that is is 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.

1 4

[Bug 56340] New: Update to 9.0.0-1.3 wine-mono from 8.1.0-1.2 wipes out Quicken 2011 (which needs .net) in Tumbleweed
by WineHQ Bugzilla 24 Feb '24

24 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=56340 Bug ID: 56340 Summary: Update to 9.0.0-1.3 wine-mono from 8.1.0-1.2 wipes out Quicken 2011 (which needs .net) in Tumbleweed Product: Wine Version: 9.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: timothyadams(a)ymail.com Distribution: --- A recent openSUSE Tumbleweed (rolling distro) snapshot pulled in a new version of wine-mono: 9.0.0-1.3, replacing 8.1.0-1.2. After I updated my system to this snapshot via "zypper dup," I discovered that I could no longer load Quicken 2011 in wine. The program would start to load, then crash. I have locked wine-mono and restored to an earlier snapshot with wine-mono 8.1.0-1.2. Quicken now loads properly again, with no other packages locked. Still, I thought I should file a bug to let you know. I have installed wine 9.1-1.1, wine-32bit 9.1-1.1, wine-gecko 2.47.4-1.2, and winetricks 20240105-1.2. -- 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.

1 7

[Bug 9221] Force Feedback doesn't work but does after little source modification
by WineHQ Bugzilla 24 Feb '24

24 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=9221 --- Comment #59 from groybe(a)gmail.com --- (In reply to Rémi Bernon from comment #51) > Sure, it's okay. I don't have the device so it's going to be hard to fix it > unless someone with it and a bit of technical knowledge can debug it > directly. > > Anyway thanks for the log, but would you mind adding the +hid channel too? > Not that it will make it magically fixable but I can have a look and see if > there's anything obvious. > > For instance something like running > `WINEDEBUG=+pid,+tid,+timestamp,+joycpl,+dinput,+hid wine control joy.cpl` > and then try running a couple of force feedback effects. The patch here fixes force feedback in Richard Burns Rally. https://bugs.winehq.org/show_bug.cgi?id=52714 GP Legends still has no ffb though. -- 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.

1 0

[Bug 55800] New: Fallout 3: on the experimental wow64 mode the terminal gets spammed with d3dx errors
by WineHQ Bugzilla 23 Feb '24

23 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=55800 Bug ID: 55800 Summary: Fallout 3: on the experimental wow64 mode the terminal gets spammed with d3dx errors Product: Wine Version: 8.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: m1m1k4tz(a)protonmail.com Distribution: --- While playing almost everything works good like the old wow64 mode but the terminal gets spammed with 0234:fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5. -- 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.

1 4

[Bug 46263] New: Final Fantasy XI crashes after accepting EULA when using Ashita
by wine-bugs＠winehq.org 23 Feb '24

23 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=46263 Bug ID: 46263 Summary: Final Fantasy XI crashes after accepting EULA when using Ashita Product: Wine-staging Version: 3.21 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: winehq(a)foreversmall.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 62965 --> https://bugs.winehq.org/attachment.cgi?id=62965 Terminal Output with backtrace of crash. When using Ashita with FFXI the game crashes shortly after accepting the EULA. I've confirmed this with all the versions of wine starting from version 3.0 stable, all the way up to 3.21 staging. The only way I've been able to get the game to launch is to compile wine myself with the following patch: https://gitlab.com/farmboy0/wine/commit/54aea128e91a6b03bff05e79d9a09bea572… Its very easy to recreate, use all the standard AppDB info to get FFXI setup. Download ashita from the website: https://git.ashitaxi.com/Ashita/Ashitav3-Launcher/raw/master/Ashita.exe >From here you need all the ashita pre-reqs: http://docs.ashitaxi.com/requirements/ Setup a config file with the settings ../Ashita/Config/Boot/ You can launch the game via this command: wine %path_to_Ashita%/injector.exe "%CONFIGFILE%.xml" If it properly loads then once you accept the EULA it will crash. -- 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.

2 17

[Bug 56343] New: A regression since commit de492f9a342f398087f9f635fd5d9b5ae78b45eb (err:virtual:virtual_setup_exception stack overflow)
by WineHQ Bugzilla 23 Feb '24

23 Feb '24

https://bugs.winehq.org/show_bug.cgi?id=56343 Bug ID: 56343 Summary: A regression since commit de492f9a342f398087f9f635fd5d9b5ae78b45eb (err:virtual:virtual_setup_exception stack overflow) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: zefkerrigan(a)gmail.com Distribution: --- Since Wine commit https://gitlab.winehq.org/wine/wine/-/commit/de492f9a342f398087f9f635fd5d9b… my games have completely stopped launching. Wine just hangs at the very beginning anytime I try to run the games. I get this error message every single time: 0100:fixme:file:NtLockFile I/O completion on lock not implemented yet 0108:err:virtual:virtual_setup_exception stack overflow 2368 bytes addr 0x6fffffca7082 stack 0x7fffff6706c0 (0x7fffff670000-0x7fffff671000-0x7fffff770000) 010c:err:virtual:virtual_setup_exception stack overflow 2112 bytes addr 0x6fffffc810d0 stack 0x7401f00f07c0 (0x7401f00f0000-0x7401f00f1000-0x7401f01f0000) 0110:err:virtual:virtual_setup_exception stack overflow 2112 bytes addr 0x6fffffc810d0 stack 0x7401e7ef07c0 (0x7401e7ef0000-0x7401e7ef1000-0x7401e7ff0000) 0100:err:virtual:virtual_setup_exception stack overflow 896 bytes addr 0x6fffffc74c2b stack 0x7ffffe100c80 (0x7ffffe100000-0x7ffffe101000-0x7ffffe200000) This is completely the entire terminal output when running BG3 when this problem is present. I've tried running Baldur's Gate 3 and Mass Effect Legendary Edition, but the result is always the same. Everything launches fine if I use the previous commit https://gitlab.winehq.org/wine/wine/-/commit/165830c317b63999ee7e32b58c7359…. I don't know if you'll find this information useful, but I'm using Arch Linux, Radeon GPU with Mesa drivers. -- 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.

1 4