October 2021 - Wine-bugs - list.winehq.org

[Bug 51199] New: Mass Effect Legendary missing api-ms-win-core-psapi-l1-1-0 and api-ms-win-core-psapi-ansi-l1-1-0 function forwards
by WineHQ Bugzilla 08 Oct '21

08 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=51199 Bug ID: 51199 Summary: Mass Effect Legendary missing api-ms-win-core-psapi-l1-1-0 and api-ms-win-core-psapi-ansi-l1-1-0 function forwards Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: api-ms-win-* Assignee: wine-bugs(a)winehq.org Reporter: GloriousEggroll(a)gmail.com Distribution: --- Created attachment 70073 --> https://bugs.winehq.org/attachment.cgi?id=70073 psapi patch for me-le Mass Effect Legendary Edition requires K32GetModuleBaseNameW and K32GetModuleInformation for api-ms-win-core-psapi-l1-1-0 and K32GetModuleBaseNameA for api-ms-win-core-psapi-ansi-l1-1-0, otherwise it fails to launch. The game's log: ProgramData/ProgramData/Origin/Logs/MassEffectLauncher_OnlineActivation_Log.html Reports the following: First I hit: Error | | | Missing DLL: api-ms-win-core-psapi-ansi-l1-1-0.dll Function: K32GetModuleBaseNameA Then I hit: Error | | | Missing DLL: api-ms-win-core-psapi-l1-1-0.dll Function: K32GetModuleBaseNameW Then I hit: Error | | | Missing DLL: api-ms-win-core-psapi-l1-1-0.dll Function: K32GetModuleInformation The following patch adds forwarders for these to the corresponding kernel32 functions, allowing it to 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.

1 6

[Bug 51789] New: Applications fails to start due to gdi32 initialization failure
by WineHQ Bugzilla 08 Oct '21

08 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=51789 Bug ID: 51789 Summary: Applications fails to start due to gdi32 initialization failure Product: Wine Version: 6.17 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: bunglehead(a)gmail.com Regression SHA1: 3eeb37f86a4d0a8c826fa72d8f657e13b8d159e4 Distribution: --- Bisect points to this one: 3eeb37f86a4d0a8c826fa72d8f657e13b8d159e4 is the first bad commit commit 3eeb37f86a4d0a8c826fa72d8f657e13b8d159e4 Author: Jacek Caban <jacek(a)codeweavers.com> Date: Thu Sep 23 13:44:05 2021 +0100 gdi32: Directly use ntdll in add_face_to_cache. Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> Signed-off-by: Huw Davies <huw(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> dlls/gdi32/font.c | 46 ++++++++++++++++++++++++++++++++++++---------- 1 file changed, 36 insertions(+), 10 deletions(-) Default output shows loader error for gdi32. I'll attach some logs. -- 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 49433] New: MikuMikuMoving v1275 hangs on startup
by WineHQ Bugzilla 08 Oct '21

08 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=49433 Bug ID: 49433 Summary: MikuMikuMoving v1275 hangs on startup Product: Wine Version: 5.8 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- This is a regression, introduced by commit 42ed9797b1929fc5917bd967f7062cab953fab55 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Sat Nov 16 21:00:08 2019 +0100 kernel32: Move EnumCalendarInfo functions to kernelbase. Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> Reverting fixes the issue and makes the program start up. -- 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 3

[Bug 32783] New: STEP7_Lite_V30_incl_SP4 Setup Failed to start the service, Error:1053, Service request timeout.
by wine-bugs＠winehq.org 08 Oct '21

08 Oct '21

http://bugs.winehq.org/show_bug.cgi?id=32783 Bug #: 32783 Summary: STEP7_Lite_V30_incl_SP4 Setup Failed to start the service, Error:1053, Service request timeout. Product: Wine Version: 1.5.22 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fangendoucg(a)gmail.com Classification: Unclassified Created attachment 43286 --> http://bugs.winehq.org/attachment.cgi?id=43286 Terminal Output env: ubuntu12.04 & wine 1.5.22 with the patch of the bug 32764 The software can be freely downloaded from: https://a248.e.akamai.net/cache.automation.siemens.com/dnl/DQ/DQzMjkzAAAA_3… extract it, cd to folder STEP7_Lite_V30_incl_SP4 , then run: $wine Setup.exe While installing Automation License Manager V4.0 SP3, a dialog box showed like the attachment "dialog_box_1", click *R* showed another one like the attachment "dialog_box_2". The Chinese words in dialog_box_2 means insufficient buffer. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 24

[Bug 48567] New: Wine returns the loopback IP as first item in GetIpAddrTable and a MAC of 0
by WineHQ Bugzilla 08 Oct '21

08 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=48567 Bug ID: 48567 Summary: Wine returns the loopback IP as first item in GetIpAddrTable and a MAC of 0 Product: Wine Version: 5.0-rc3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: iphlpapi Assignee: wine-bugs(a)winehq.org Reporter: ez(a)vajn.icu Distribution: --- Created attachment 66389 --> https://bugs.winehq.org/attachment.cgi?id=66389 C source This is the same bug as 40247 which was marked as "CLOSED FIXED" All flexnet based licensing fails to work under wine because it receives a hardware MAC of 0 returned by the "lo" interface: $ lmutil.exe lmhostid lmutil - Copyright (c) 1989-2017 Flexera Software LLC. All Rights Reserved. The FlexNet host ID of this machine is "ffffffff" If you compile the attached C program and run it in wine you get: $ mingw32-gcc -DMINGW -o get_mac get_mac.c -lnetapi32 $ ./get_mac.exe MAC: 000000000000 In Linux the eth0 MAC is: $ gcc -o get_mac get_mac.c $ ./get_mac Grabbing MAC address for interface eth0 MAC: e03619b3b50e -- 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 3

[Bug 46365] New: Proteus 8.7 SP3 - Cannot open network adapter: en0: BIOCSRTIMEOUT: Invalid argument [U2]
by wine-bugs＠winehq.org 08 Oct '21

08 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=46365 Bug ID: 46365 Summary: Proteus 8.7 SP3 - Cannot open network adapter: en0: BIOCSRTIMEOUT: Invalid argument [U2] Product: Wine Version: 4.0-rc3 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: wpcap Assignee: wine-bugs(a)winehq.org Reporter: rajhlinux(a)yahoo.com Created attachment 63098 --> https://bugs.winehq.org/attachment.cgi?id=63098 proteus simulation error without wpcap.dll override. Everything is working fine in proteus 8.7 SP3 but when running a simulation with an ENC28J60 ethernet controller on the schematic, proteus stops and gives an error: Cannot open network adapter: en0: BIOCSRTIMEOUT: Invalid argument [U2] Proteus requires WinPcap drivers for networking simulations. I attempted to use wpcap.ddl override from winecfg as native and did the simulation again and got the error: Failed to initialize WinPcap Drivers [U2] I also tried installing proteus 8.7 SP3 on crossover, playonmac and wineskin all give the same errors when running the same simulation above. I tried using proteus in both 32 and 64bit installations with same errors. After launching proteus from wine, proteus has a working internet connection because I can see the news updates from the main home page of proteus. I know the simulation works because I have installed windows 10 x64 using vmware fusion on the same computer installing the same proteus 8.7 sp3 installer which I used for wine and runs perfectly using Win10Pcap drivers. I'm sure the WincPcap drivers that comes with proteus installation which you have to manually install from the programs folder will work without Win10Pcap drivers. I have attached the error log. macOS Mojave: 10.14.2 Wine Dev 4.0 rc3 -- 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 4

[Bug 40173] New: traffic watcher complians "This program works only on Ethernet networks." on wine with wpcap
by wine-bugs＠winehq.org 08 Oct '21

08 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=40173 Bug ID: 40173 Summary: traffic watcher complians "This program works only on Ethernet networks." on wine with wpcap Product: Wine Version: 1.9.3 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wpcap Assignee: wine-bugs(a)winehq.org Reporter: zhangjianqiu_133(a)yeah.net Distribution: --- Created attachment 53674 --> https://bugs.winehq.org/attachment.cgi?id=53674 Log for wine relay trace When running traffic watcher on wine (with pcap supported), An err Msgbox pops out shows "This program works only on Ethernet networks." and when use WINEDEBUG=+relay,+wpcap,+tid wine xxx.exe it shows this, which I think is wrong 0009:trace:wpcap:wine_pcap_datalink (0x7d8c1b08) 0009:Ret wpcap.pcap_datalink() retval=00000071 ret=004078a7 The retval here seems to make no sense\ The app can be get via sourceforge: https://sourceforge.net/projects/trafficwatcher/files/ The bug above is tested with ver 2.0.1 The attachment is the result of cutting full log with cat log | grep wpcap -- 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 51768] New: Controller Random Disconnection v6.17
by WineHQ Bugzilla 08 Oct '21

08 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=51768 Bug ID: 51768 Summary: Controller Random Disconnection v6.17 Product: Wine-staging Version: 6.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: spanky_12inch(a)hotmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- With version 6.17 controller did not function. However deleting a registry key fixed the controller. ( That bug is already mentioned here ) But controller randomly disconnects now instead. Doesn't happen with version 6.16 -- 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 2

[Bug 8332] Multiple applications fail to send ICMP requests on Linux (failure to open IPPROTO_ICMP sockets)
by WineHQ Bugzilla 07 Oct '21

07 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #39 from Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- (In reply to oiaohm from comment #38) > (In reply to Zebediah Figura from comment #37) > > I'm adjusting the title, since it's misleading. As far as I understand > > SOCK_DGRAM + IPPROTO_ICMP actually does sufficiently work on Linux (Damjan > > claims it is "completely broken", which seems odd seeing as `wine ping` > > works fine.) The problem is, as far as I'm aware, this is *also* forbidden > > by default on some distributions, including Debian, via the > > "net.ipv4.ping_group_range" sysctl. > > > > Should we just require that sysctl to be set for Wine? Is it reasonable to > > try to fall back to ping(1)? I don't see any other way to achieve what we > > want... > > > > The linked download no longer works on Windows (i.e. it gives the same "no > > internet detected" message; probably the service died), so I'm removing that. > > https://serverfault.com/questions/1002225/how-do-i-limit-ping-icmp-response… > on-a-debian-10-server > > There are a lot of different changeable values > > net.ipv4.ping_group_range is is straight up forbid. There is also the > problem that a icmp send or receive rate limit can be set like mentioned > above and other setting. > > https://social.msdn.microsoft.com/Forums/en-US/74fd0d8e-b75a-4aa5-bb50- > 140e606950b6/icmp-error-processing-on-udp-socket?forum=wsk > > Also I am sorry but Damjan Jovanovic is wrong in a fatal way. Windows ICMP > error handling changes with windows version and configuration as well. > --Windows doesn't seem to provide any ICMP error data anyway:-- is right and > wrong as the same time. > > Mac OS and Linux both don't match what different versions of Windows will > provide applications with at times. > > The Linux should provide enough data to reconstruct all the different wacky > ways windows can respond to applications in case of ICMP error. > > Also to be really horrible windows ICMP error response altered based on > Windows firewalls as well. These differences can be why a program works > under XP then fails under Windows 7 and newer. Or only works with Windows 7 > and newer when particular firewall settings are set. > I think you missed the point. The failure happens when either creating the socket (because no permissions), or when sending it AFAIK, not the error received, although that's also another one of the issues between implementations. Anyway, Huw has done a rewrite of icmp on top of nsi. Damjan, can you test with latest wine git and see if it's still broken? -- 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] Multiple applications fail to send ICMP requests on Linux (failure to open IPPROTO_ICMP sockets)
by WineHQ Bugzilla 07 Oct '21

07 Oct '21

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #38 from oiaohm <oiaohm(a)gmail.com> --- (In reply to Zebediah Figura from comment #37) > I'm adjusting the title, since it's misleading. As far as I understand > SOCK_DGRAM + IPPROTO_ICMP actually does sufficiently work on Linux (Damjan > claims it is "completely broken", which seems odd seeing as `wine ping` > works fine.) The problem is, as far as I'm aware, this is *also* forbidden > by default on some distributions, including Debian, via the > "net.ipv4.ping_group_range" sysctl. > > Should we just require that sysctl to be set for Wine? Is it reasonable to > try to fall back to ping(1)? I don't see any other way to achieve what we > want... > > The linked download no longer works on Windows (i.e. it gives the same "no > internet detected" message; probably the service died), so I'm removing that. https://serverfault.com/questions/1002225/how-do-i-limit-ping-icmp-response… There are a lot of different changeable values net.ipv4.ping_group_range is is straight up forbid. There is also the problem that a icmp send or receive rate limit can be set like mentioned above and other setting. https://social.msdn.microsoft.com/Forums/en-US/74fd0d8e-b75a-4aa5-bb50-140e… Also I am sorry but Damjan Jovanovic is wrong in a fatal way. Windows ICMP error handling changes with windows version and configuration as well. --Windows doesn't seem to provide any ICMP error data anyway:-- is right and wrong as the same time. Mac OS and Linux both don't match what different versions of Windows will provide applications with at times. The Linux should provide enough data to reconstruct all the different wacky ways windows can respond to applications in case of ICMP error. Also to be really horrible windows ICMP error response altered based on Windows firewalls as well. These differences can be why a program works under XP then fails under Windows 7 and newer. Or only works with Windows 7 and newer when particular firewall settings are set. ICMP error handling I can see this needing Linux particular code. I also see that Mac OS is kind screwed because for some cases the need data to replicate what windows does Mac OS ICMP handling does not provide that information. --On error: | reply's IP | reply's ICMP-- This is not windows. With windows 7 and newer reply's IP address could be 0.0.0.0 instead of valid address with Windows 7 and newer. reply's ICMP can also be also be cleared on Windows 7 and before. Windows Xp and before you have a different set of rules. Yes the fun one that Windows can be tell you the outgoing port with ICMP instead of the port its going to at the designation as well. Yes ping group range under windows can fail due to firewall settings under windows. Reality is Linux is not completely broken. But error handling with ICMP is very platform dependant and platform configuration dependant. ICMP successful is fairly much the same everywhere. When you need to handle ICMP failure its fairly much Linux, BSD(covering OS X) and about 5 different windows implementations(for different windows setups and version) so it least works without doing something totally stupid. Yes a lot of cases with windows with ICMP failures you are horrible short of information and the information can be massively mangled. So windows would be completely broken ICMP error handling design that Microsoft has been not keeping constant between versions of windows or configurations of windows. I would say this is one of these horrible areas. I would suspect some applications are not working with wine at the moment because wine under Linux and Mac OS don't match how windows miss behaves. Yes some windows applications will refuse to install if Microsoft firewall settings and other settings are not set particular was to get particular ICMP error handling. So this is more cursed than one would wish for. -- 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