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.
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.
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.
https://bugs.winehq.org/show_bug.cgi?id=44336
Bug ID: 44336
Summary: PureBasic x64 IDE crashes when launching online help
("F1" key)
Product: Wine
Version: 2.22
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: niffo(a)free.fr
Distribution: ---
Launching the online help of PureBasic with "F1" crashes the IDE (seen at least
on Wine64 1.8.7 and 2.22).
The same bug was fixed for PureBasic x86 on wine x86 1.7.x but now (or still?)
it crashes with PureBasic x64 on wine64.
(tested With PureBasic 5.61 x64)
To reproduce, you just have to download the demo version of PureBasic x64 here
: http://www.purebasic.com/download/PureBasic_Demo_x64.zip
Install it and launch the IDE then press "F1" keyboard key.
--
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=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.
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.
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.
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.
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.
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.