October 2022 - Wine-Bugs - list.winehq.org

[Bug 48668] rFactor2 - Physics thread slower on multiplayer mode

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48668 madbad82(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madbad82(a)gmail.com --- Comment #19 from madbad82(a)gmail.com --- Similar to what was reported on comment2, the game itself run fine now but the dedicated server seems to still be plagued by connection issues/latency, maybe related to this bug report. I've tried to host a race with the dedicated server on wine (7.12-staging), everything was fine up to 6 drivers, above that everyone ping started to rise each time a new driver entered the server and we reached 500/600 ping with 13 driver on the server. I could still ping google from the server with low numbers, so I think the issue was not the server connection itself. The ping issue seemed to be strictly related to the number of drivers, since when drivers started to leave the ping decreased up to nomal numbers (30-50ms). I know I was able to host with this same machine on windows races for up to 13/14 drivers without issues in the past. I'm not completely sure yet if the ping issue may be related to the fact that the server was running on wine or due to the recent updates to rF2 that may have increased the connection requirements. Some data about the test: Speed test report from the server: - 50 Mbps download speed and - 17 Mbps upload speed 8ms ping During the test band usage was lower than 2 Mbps upload (download is probably irilevant but just a little smaller). For reference: 4 Gb used out of 12 of RAM CPU at 40% (none of threads were maxed) Any idea? -- 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.

Oct. 11, 2022

[Bug 53594] GOG Galaxy crashes in GetExtendedTcpTable()

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53594 marc_aurel(a)me.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marc_aurel(a)me.com -- 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.

Oct. 11, 2022

[Bug 53773] winetricks dotnet35 fails to install

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53773 shivam r <melparesky(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |melparesky(a)gmail.com -- 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.

Oct. 11, 2022

[Bug 50281] fsync patch for wine 6.0-rc1 (without staging)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=50281 roidal(a)googlemail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |roidal(a)googlemail.com --- Comment #17 from roidal(a)googlemail.com --- (In reply to Zeb Figura from comment #10) > I am doubtful that it will be accepted into wine-staging either. > Furthermore esync is already a very significant > maintenance burden; it has been easily the worst patch set in wine-staging > since its induction. What are the future plans for esync then? Will it stay in staging or might be remove at some point? -- 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.

Oct. 11, 2022

[Bug 53774] WinZip 7 crashes when extracting a zip archive

by WineHQ Bugzilla

Oct. 11, 2022

[Bug 53731] Wineconsole lacks preferences and menubar like most consoles

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53731 --- Comment #2 from Hamish McIntyre-Bhatty <winehq(a)regd.hamishmb.com> --- Thanks, that does help :) Now that I know for sure that there are options to set, there should definitely be a menubar, and it should be enabled by default, in order to make the options discoverable - I'm a power user and I didn't find the options any of the usual ways, and I didn't find a wiki page or other documentation either. I'm a member of the wiki, so if someone can point me at the page (if it exists), I'll add some cross-links to and from 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.

Oct. 11, 2022

[Bug 34631] 163music / WeChat: shadow of windows is always on the top of desktop

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #34 from 399989567(a)qq.com --- (In reply to 399989567 from comment #33) > (In reply to Zeb Figura from comment #31) > > *** Bug 53772 has been marked as a duplicate of this bug. *** > > I would like to ask what is the reason for judging whether a window is added > to the window manager in wine. For example, in the is_window_manger function > of winex11.drv, I see that the child window in wine does not need to be > added to the window manager, and the full-screen window needs to be added to > the window manager. > > ==================== > > I would like to ask what is the basis for judging whether a window is added > to the window manager? I'm not asking the code logic for the judging in > wine, I'm asking why the code be coding like that? If we judging a window > need to be add to the window manager,What is the basis we follow？ > > such as : We know that the child window is managed by its parent window, > so there is no need to join the window management. > > ==================== > > Because I think a visible POPUP window (WS_VISIBLE) in the screen should be > added to the window pipe, but I want to know "the basis for judging whether > a window is added to the window pipe", and then judge whether my logic is > correct. > > If my logic is correct then this bug will be fixed. I refuted myself, adding the shadow window to the window manager can indeed solve the problem, and the shadow window will not be displayed on the top layer, but such modification will cause new problems, so there should be a corresponding reason that wine did not do this in the design. consideration (although I still don't know what kind of consideration) I will still be here for getting the basis for judging whether a window is added to the window manager. -- 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.

Oct. 11, 2022

[Bug 53776] Troubleshooting

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53776 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |o.dierick(a)piezo-forte.be Status|UNCONFIRMED |NEEDINFO --- Comment #1 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, There is nothing to work with here. Description of the issue? Name of application? Demo/free legal download? Wine version? Terminal output? 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.

Oct. 11, 2022

[Bug 34631] 163music / WeChat: shadow of windows is always on the top of desktop

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #33 from 399989567(a)qq.com --- (In reply to Zeb Figura from comment #31) > *** Bug 53772 has been marked as a duplicate of this bug. *** I would like to ask what is the reason for judging whether a window is added to the window manager in wine. For example, in the is_window_manger function of winex11.drv, I see that the child window in wine does not need to be added to the window manager, and the full-screen window needs to be added to the window manager. ==================== I would like to ask what is the basis for judging whether a window is added to the window manager? I'm not asking the code logic for the judging in wine, I'm asking why the code be coding like that? If we judging a window need to be add to the window manager,What is the basis we follow？ such as : We know that the child window is managed by its parent window, so there is no need to join the window management. ==================== Because I think a visible POPUP window (WS_VISIBLE) in the screen should be added to the window pipe, but I want to know "the basis for judging whether a window is added to the window pipe", and then judge whether my logic is correct. If my logic is correct then this bug will be 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.

Oct. 11, 2022

[Bug 53776] New: Troubleshooting

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53776 Bug ID: 53776 Summary: Troubleshooting Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: blueguitar1978(a)gmail.com Distribution: --- cd ~/.wine/drive_c/Games/Tron wine tron.exe &> log.txt -- 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.

Oct. 11, 2022