June 2021 - Wine-Bugs - list.winehq.org

[Bug 50832] New: That wine looks like windos 10 instead of windows 9x
by WineHQ Bugzilla June 15, 2021

June 15, 2021

https://bugs.winehq.org/show_bug.cgi?id=50832 Bug ID: 50832 Summary: That wine looks like windos 10 instead of windows 9x Product: Wine Version: 5.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: toadfield(a)tutanota.com Distribution: --- I like the looks of windows 10 more than 9x. It would make all the programs look much better. -- 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 6

[Bug 51272] New: Silent Hunter 4: Lag when the radar is activated
by WineHQ Bugzilla June 15, 2021

June 15, 2021

https://bugs.winehq.org/show_bug.cgi?id=51272 Bug ID: 51272 Summary: Silent Hunter 4: Lag when the radar is activated Product: Wine-staging Version: 6.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: for.ad(a)free.fr CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: Debian Created attachment 70153 --> https://bugs.winehq.org/attachment.cgi?id=70153 Terminal output Hello, I'm having lags in the conning tower or in the control room with S-class when the radar is activated. This happens with mega mods such as TMO or FotRSU. I'm using Wine 6.10 staging, versions prior to 3.1 are better but lag is still there. -- 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 6

[Bug 43763] New: Warlords Battlecry II crashes on load map
by wine-bugs＠winehq.org June 15, 2021

June 15, 2021

https://bugs.winehq.org/show_bug.cgi?id=43763 Bug ID: 43763 Summary: Warlords Battlecry II crashes on load map Product: Wine Version: 2.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: 9xzsnuwq9h(a)snkmail.com Distribution: --- Created attachment 59263 --> https://bugs.winehq.org/attachment.cgi?id=59263 wine log with back trace Fresh install of dev-Version, deleted previous .wine directory. Did not install Mono or Gecko. Installed wb2. Started program. Chose Skirmish. Created new Hero. Configured an AI opponent (and small retinue points for testing, optional) and started. Selected retinue (optional). Next step is loading the map -> Crash (see attached log). First line logged line after loading starts is: err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1600x1200x16 @0! (XRandR 1.2) ... 0 FPS is at least a weird setting. But this has probably not much to do with the following: wine: Unhandled page fault on read access to 0x00000000 at address 0x7bc50f90 (thread 0038), starting debugger... Tested on different system and wine configurations. Same on 32Bit, 1.6.2-0ubuntu4 and winehq-stable. -- 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 12

[Bug 51270] New: Asus Armoury Crate crashes when opening it with Wine.
by WineHQ Bugzilla June 14, 2021

June 14, 2021

https://bugs.winehq.org/show_bug.cgi?id=51270 Bug ID: 51270 Summary: Asus Armoury Crate crashes when opening it with Wine. Product: Wine Version: 6.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: 4lon3ly0(a)protonmail.com Distribution: --- Created attachment 70149 --> https://bugs.winehq.org/attachment.cgi?id=70149 Asus Armoury Crate Backtrace When I open the Asus Armoury Crate 3.0.11.0 under Wine 6.9, it crashes saying that the program had encountered a serious problem and that it needed to close. Sha1sum: fd6a0db01793eee7ff081e3afbd0f00133e213d4 Download: https://dlcdnets.asus.com/pub/ASUS/mb/14Utilities/ArmouryCrateInstallTool.z… Sysinfo: X64 Artix Linux Linux 5.12.7-hardened -- 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 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by WineHQ Bugzilla June 14, 2021

June 14, 2021

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #35 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- (In reply to Gabriel Ivăncescu from comment #34) > Yeah, speaking of that, I had some patches to implement the asynchronous > ICMP pings with Events and APCs, but they fell off the list. I should > probably resend them, thanks for the reminder. Great :). > Do you plan to work on fixing this? It shouldn't conflict with my async > patches much anyway, worst case a simple rebase would be sufficient. I could > probably take a look if you can't, but you seem to know a lot more about it > than I do, so am just asking to not duplicate the effort. Sure. Some of the code is already written. -- 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 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by WineHQ Bugzilla June 14, 2021

June 14, 2021

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #34 from Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- (In reply to Damjan Jovanovic from comment #33) > (In reply to Gabriel Ivăncescu from comment #32) > > I don't remember the exact details, there was a game pinging multiple time > > every 5 seconds and it had a nasty stutter when that happened with the > > wine-staging patch, since it invoked external commands and was very slow. > > That's not good. If the game stuttered merely because of the latency of a > fork(), when we fix this and it waits for a network round-trip instead, it > will be much worse. Are you sure there isn't another problem, eg. game wants > asynchronous ping but we do it synchronously? > Yeah, speaking of that, I had some patches to implement the asynchronous ICMP pings with Events and APCs, but they fell off the list. I should probably resend them, thanks for the reminder. > > I'm not that familiar with it, so I admit I haven't tested it at all other > > than creating the raw socket itself, but it did fix the slowdown; now that > > you mention it, though, it probably failed to ping. > > Ok thank you. Do you plan to work on fixing this? It shouldn't conflict with my async patches much anyway, worst case a simple rebase would be sufficient. I could probably take a look if you can't, but you seem to know a lot more about it than I do, so am just asking to not duplicate the effort. -- 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 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by WineHQ Bugzilla June 14, 2021

June 14, 2021

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #33 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- (In reply to Gabriel Ivăncescu from comment #32) > I don't remember the exact details, there was a game pinging multiple time > every 5 seconds and it had a nasty stutter when that happened with the > wine-staging patch, since it invoked external commands and was very slow. That's not good. If the game stuttered merely because of the latency of a fork(), when we fix this and it waits for a network round-trip instead, it will be much worse. Are you sure there isn't another problem, eg. game wants asynchronous ping but we do it synchronously? > I'm not that familiar with it, so I admit I haven't tested it at all other > than creating the raw socket itself, but it did fix the slowdown; now that > you mention it, though, it probably failed to ping. Ok 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.

1 0

[Bug 42945] New: FFXIV Loop opening
by wine-bugs＠winehq.org June 14, 2021

June 14, 2021

https://bugs.winehq.org/show_bug.cgi?id=42945 Bug ID: 42945 Summary: FFXIV Loop opening Product: Wine Version: 2.7 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ssbkm(a)icloud.com Distribution: --- FFXIV gets stuck in a loop for opening movie requires work around by entering config and disabling the movie to play game at all. -- 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 5

[Bug 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by WineHQ Bugzilla June 14, 2021

June 14, 2021

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #32 from Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- (In reply to Damjan Jovanovic from comment #31) > Falling back to calling the "ping" command line tool shouldn't ever be > necessary on MacOS and Linux. > > When creating a raw socket fails, Wine tries to fall back to using an > unprivileged ICMP socket, which is a non-standard socket type present on > MacOS and Linux: > > ---snip--- > int sid=socket(AF_INET,SOCK_RAW,IPPROTO_ICMP); > if (sid < 0) > { > /* Some systems (e.g. Linux 3.0+ and Mac OS X) support > non-privileged ICMP via SOCK_DGRAM type. */ > sid=socket(AF_INET,SOCK_DGRAM,IPPROTO_ICMP); > } > ---snip--- > > Documentation: > Linux: https://lwn.net/Articles/420800/ > MacOS: http://www.manpagez.com/man/4/icmp/ > > > On MacOS, I think that work fine. > > Linux however is currently completely broken, and pinging always fail, > because: > > 1. This socket type does not return the IP header as expected from the > recvfrom() system call in the icmp_get_reply() function, causing the reply > to be parsed incorrectly in that function. On Linux, the reply immediately > begins with the ICMP header instead. > > 2. Even when that is somewhat fixed (it's long and painful to fix fully), it > still breaks, because Linux overwrites the ICMP header field "icmp_id" with > its own value, ie. this value is later overwritten by the kernel: > > ---snip--- > icmp_header->icmp_id=id; > ---snip--- > > causing this check in icmp_get_reply() to always fail: > > ---snip--- > if ((icmp_header->icmp_id==id) && > (icmp_header->icmp_seq==seq)) > ---snip--- > > and the reply thus falsely never matches the request, so pinging still fails. > > The "icmp_id" is overwritten by the socket's port number, which can be set > through bind(). It cannot be queried by getsockname() which always returns > port 0, even after bind(). However it seems best not to set it, let the > kernel pick a free port, and then skip the icmp_id check above instead, as > the kernel already filters replies by their icmp_id. > > Fixing (2) is easy, but (1) really needs to use recvmsg() instead, with > IP_RECVTTL, IP_RECVTOS, IP_RETOPTS, IP_RECVERR and other ancillary data, > only on Linux and only for these unprivileged ICMP sockets. Then this > alternative source of IP header data needs to be integrated into > icmp_get_reply(). > > I don't know how Gabriel ever said that this works on Linux. Either he never > tested, only tested pinging an invalid address, or Linux changed how > unprivileged ICMP sockets work between then and now: > > ---snip--- > commit e6d9aaeb67172dd0ba1e73f34c7f0cad36ed43ff > Author: Gabriel Iv��ncescu <gabrielopcode(a)gmail.com> > Date: Mon Aug 3 16:15:52 2020 +0300 > > iphlpapi: Update comment for SOCK_DGRAM since Linux also supports it > from 3.0. > > Linux does require the user to be in the range specified by > /proc/sys/net/ipv4/ping_group_range though, but otherwise works fine. > > Signed-off-by: Gabriel Iv��ncescu <gabrielopcode(a)gmail.com> > Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> > ---snip--- I don't remember the exact details, there was a game pinging multiple time every 5 seconds and it had a nasty stutter when that happened with the wine-staging patch, since it invoked external commands and was very slow. I'm not that familiar with it, so I admit I haven't tested it at all other than creating the raw socket itself, but it did fix the slowdown; now that you mention it, though, it probably failed to ping. Note that the commit you referenced doesn't actually do anything, it just changes a comment, which is true, because Linux does allow creating raw sockets with the aforementioned requirements specified. So the code was already broken. The "broken" functionality you mention was already there. -- 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 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by WineHQ Bugzilla June 13, 2021

June 13, 2021

https://bugs.winehq.org/show_bug.cgi?id=8332 Damjan Jovanovic <damjan.jov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov(a)gmail.com, | |gabrielopcode(a)gmail.com --- Comment #31 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- Falling back to calling the "ping" command line tool shouldn't ever be necessary on MacOS and Linux. When creating a raw socket fails, Wine tries to fall back to using an unprivileged ICMP socket, which is a non-standard socket type present on MacOS and Linux: ---snip--- int sid=socket(AF_INET,SOCK_RAW,IPPROTO_ICMP); if (sid < 0) { /* Some systems (e.g. Linux 3.0+ and Mac OS X) support non-privileged ICMP via SOCK_DGRAM type. */ sid=socket(AF_INET,SOCK_DGRAM,IPPROTO_ICMP); } ---snip--- Documentation: Linux: https://lwn.net/Articles/420800/ MacOS: http://www.manpagez.com/man/4/icmp/ On MacOS, I think that work fine. Linux however is currently completely broken, and pinging always fail, because: 1. This socket type does not return the IP header as expected from the recvfrom() system call in the icmp_get_reply() function, causing the reply to be parsed incorrectly in that function. On Linux, the reply immediately begins with the ICMP header instead. 2. Even when that is somewhat fixed (it's long and painful to fix fully), it still breaks, because Linux overwrites the ICMP header field "icmp_id" with its own value, ie. this value is later overwritten by the kernel: ---snip--- icmp_header->icmp_id=id; ---snip--- causing this check in icmp_get_reply() to always fail: ---snip--- if ((icmp_header->icmp_id==id) && (icmp_header->icmp_seq==seq)) ---snip--- and the reply thus falsely never matches the request, so pinging still fails. The "icmp_id" is overwritten by the socket's port number, which can be set through bind(). It cannot be queried by getsockname() which always returns port 0, even after bind(). However it seems best not to set it, let the kernel pick a free port, and then skip the icmp_id check above instead, as the kernel already filters replies by their icmp_id. Fixing (2) is easy, but (1) really needs to use recvmsg() instead, with IP_RECVTTL, IP_RECVTOS, IP_RETOPTS, IP_RECVERR and other ancillary data, only on Linux and only for these unprivileged ICMP sockets. Then this alternative source of IP header data needs to be integrated into icmp_get_reply(). I don't know how Gabriel ever said that this works on Linux. Either he never tested, only tested pinging an invalid address, or Linux changed how unprivileged ICMP sockets work between then and now: ---snip--- commit e6d9aaeb67172dd0ba1e73f34c7f0cad36ed43ff Author: Gabriel Iv��ncescu <gabrielopcode(a)gmail.com> Date: Mon Aug 3 16:15:52 2020 +0300 iphlpapi: Update comment for SOCK_DGRAM since Linux also supports it from 3.0. Linux does require the user to be in the range specified by /proc/sys/net/ipv4/ping_group_range though, but otherwise works fine. Signed-off-by: Gabriel Iv��ncescu <gabrielopcode(a)gmail.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> ---snip--- -- 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