http://bugs.winehq.org/show_bug.cgi?id=35336
Bug ID: 35336
Summary: HoMM 3: Horn of the Abyss launcher freezes on the game
update (Mono issue)
Product: Wine
Version: 1.7.10
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: winebugs140(a)gmail.com
Classification: Unclassified
How to reproduce: open HotA_launcher.exe and then click on Update HotA. If you
try to cancel the update or there will be no updates available, the application
freezes.
With 'winetricks dotnet30' the launcher works fine, so it looks like a problem
with Mono.
You DON'T NEED Heroes of Might & Magic 3 to test this, you can open the
launcher of this unofficial expansion without downloading the original game.
There is nothing in the logs.
TESTED ON:
Ubuntu 13.04 and Mac OS X 10.9 Mavericks
--
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=54143
Bug ID: 54143
Summary: Chessbase 11 arrows draw too large
Product: Wine
Version: 8.0-rc1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdiplus
Assignee: wine-bugs(a)winehq.org
Reporter: dav75uk(a)yahoo.co.uk
Distribution: ---
Created attachment 73675
--> https://bugs.winehq.org/attachment.cgi?id=73675
Picture of arrow on wine8.0-rc1
When arrows are drawn using Chessbase 11, they are too big. See attached
screenshot and log.
Compare with:
https://www.youtube.com/watch?v=xvJd97ZnHAk
At 4:58 an arrow is showing from g8 to f6 pointing to a knight that has just
moved. I've also set up this arrow on chessbase 11 with wine 8.0-rc1. Note
later chessbase draws arrows slightly different, so software like CBReader14
doesn't appear to be affecting by this issue.
On wine 8.0-rc1 in CB 11 the stem of the arrow looks approx in the right place.
It crosses f7/g7 (the squares occupied by pawns) at the right point. The tip of
the arrow is in the right place on the knight between the white on the mane and
the chin. On wine 7.22 the endcap square (some default catch in a switch
statement maybe) is being drawn which is not on native chessbase (thus the
arrow isn't meant to hide it). Finally the back of the arrow head is in the
wrong place (some scaling maybe?) which is making it too large. On wine 7.22
the back of the arrow is drawn from the right shoulder of the pawn on f7 (the
one nearest the king) to near (left of) the base of the one on g7. In the video
the arrow appears from under the base of the f7 pawn (almost but not quite
lined up horizontally the bishop on f8's cross right hand edge) to just inside
the corner of the square the knight is on.
--
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=51890
Bug ID: 51890
Summary: A lot more old games would be so much more usable if
wine's virtual desktop had proper resizing
Product: Wine-staging
Version: 6.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: el(a)horse64.org
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
I have a really significant amount of older games around, none of which will
launch on this machine without wine's virtual desktop feature because on a
widescreen monitor, they determine there is no "expected" fullscreen resolution
available and crash.
Now I'd just use the virtual desktop, except it feels archaic and not very
usable: why is it that for a 800x600 game on a 800x600 virtual desktop, I can't
just maximize the virtual desktop window and get the virtual desktop SCALED UP
with proper letterboxing so I can play in some other way than a tiny window
with zero immersion and everything so small I can barely see it? Funnily enough
I can even resize the virtual desktop window except the resizing is fully
ignored and I just get black void with no scaling up all around with the game
stuck in the top-left, and the maximizing is blocked.
Scaling up (with automatic letterboxing), maximizing would seem like such
obvious features to make virtual desktop gaming infinitely less clumsy and
weird that I am a bit surprised it's not in there yet. Can it please be added??
--
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=55006
Bug ID: 55006
Summary: vbscript single line if else without else body fails
compilation
Product: Wine
Version: unspecified
Hardware: aarch64
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: vbscript
Assignee: wine-bugs(a)winehq.org
Reporter: francisdb(a)gmail.com
This is valid vbs when run with `cscript`
```
If x = 1 Then DoSomething() Else
```
wine vbscript fails with: "Compile error: Line: #, Character: #, Description
unavailable"
Workaround is changing the code to
```
If x = 1 Then DoSomething() Else:
```
or
```
If x = 1 Then DoSomething()
```
--
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=53371
Bug ID: 53371
Summary: 0024:fixme:ntdll:create_logical_proc_info stub
Product: Wine
Version: 7.12
Hardware: x86-64
OS: FreeBSD
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: yklaxds(a)gmail.com
Created attachment 72755
--> https://bugs.winehq.org/attachment.cgi?id=72755
log
FreeBSD 13.1 release amd64
KDE plasma 5
emulators/wine-devel 7.12 not work 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.
https://bugs.winehq.org/show_bug.cgi?id=52235
Bug ID: 52235
Summary: Many surfaces in the game Obduction look black
Product: Wine
Version: 7.0-rc2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: zerooneo(a)01101001.net
Distribution: ---
Created attachment 71338
--> https://bugs.winehq.org/attachment.cgi?id=71338
Screenshot
When running the game Obduction in wine, an interesting effect occurs where
most surfaces are pure black, yet with some lighting etc. applied, leaving the
game looking extremely dark.
This effect does not occur when running the game with DXVK, meaning there's a
very specific difference the two implementations that has a large effect on
this game.
The log shows a few DirectX and Direct3D-messages initially (counts on the
left):
1 03d8:fixme:dxgi:DXGID3D10CreateDevice Ignoring flags 0x1.
1 03d8:fixme:dxgi:DXGID3D10CreateDevice Ignoring flags 0x20.
1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0x12d2cad0, format
DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8d30, modes 0x7fe90cc3ac00
partial stub!
1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0x12d2cad0, format
DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8d30, modes (nil) partial
stub!
1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0xed354e0, format
DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8ad0, modes 0x18fa4d80
partial stub!
1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0xed354e0, format
DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8ad0, modes (nil) partial
stub!
1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0xed39050, format
DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8ab0, modes 0x1aece780
partial stub!
1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0xed39050, format
DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8ab0, modes (nil) partial
stub!
1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0xf0f51c0, format
DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8d50, modes 0x1af84680
partial stub!
1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0xf0f51c0, format
DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8d50, modes (nil) partial
stub!
2 04a8:fixme:d3d:create_texture_view Depth slice (0-1) not supported.
10 04a8:fixme:d3d_shader:shader_glsl_handle_instruction Backend can't handle
opcode dcl_stream.
46 03d8:fixme:d3d11:d3d11_device_CheckFeatureSupport Unhandled feature 0x3.
432 04a8:fixme:d3d_shader:shader_glsl_interpolation_qualifiers Unhandled
interpolation mode 0x3.
And then thousands of these:
1080 04a8:err:d3d:wined3d_debug_callback 0x578c00: "GL_INVALID_ENUM in
glTexBufferRange(internalFormat GL_RGBA16_SNORM)".
4632 04a8:err:d3d:wined3d_debug_callback 0x578c00: "GL_INVALID_ENUM in
glTexBufferRange(internalFormat GL_RGBA8_SNORM
Might it be that certain textures or shaders aren't supported, and that that
leads to them being rendered as black?
This game also requires some other features in order to work fully, but it
might be worth it to fix this issue either for the sake of other games, or in
case further support for this game is added in the future.
--
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=51678
Bug ID: 51678
Summary: Avogadro crashes when adding atoms
Product: Wine
Version: 6.15
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Just install, open the program (avogadro.exe) and click two times into the
black 3D part of the window.
Wine crashes with something like "Unhandled page fault on read access to
8010C497 at address 72A562D3"
--
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=55204
Bug ID: 55204
Summary: ws2_32:sock - test_close_events() sometimes misses the
close event on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: winsock
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
ws2_32:sock - test_close_events() sometimes misses the close event on Windows:
sock.c:6845: Test failed: got events 0
sock.c:6858: Test failed: got -1
sock.c:6872: Test failed: got events 0
sock.c:6890: Test failed: expected timeout
See https://test.winehq.org/data/patterns.html#ws2_32:sock
This happened 9 times in the past 8 months, mostly on Windows 7 but it did
happen once on Windows 10:
* 2022-12-14 win7_newtb-w7u-adm
* 2023-02-08 win22H2_fgtb-w10pro64-64
* 2023-02-22 win7_newtb-w7u-de
* 2023-03-17 win7_newtb-w7u-de
* 2023-03-27 win7_newtb-w7u-2qxl
* 2023-03-27 win7_newtb-w7u
* 2023-05-04 win7_newtb-w7u
* 2023-05-10 win7_newtb-w7u-es
* 2023-06-29 win7_newtb-w7u
There are also two cases where the second events check does get an FD_CLOSE
event:
sock.c:6697: Test failed: got events 0
sock.c:6710: Test failed: got -1
sock.c:6712: Test failed: expected timeout
sock.c:6712: Test failed: got events 0x20
* 2022-11-28 win21H1_newtb-w10pro64-he-64
* 2023-02-27 win22H2_fgtb-w10pro64-rx550-64
--
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=53939
Bug ID: 53939
Summary: TextOut will output ASCII control character(0~31) as
tofu cause crash
Product: Wine
Version: 7.12
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: gdi32
Assignee: wine-bugs(a)winehq.org
Reporter: 399989567(a)qq.com
Distribution: ---
TextOut will output ASCII control character(0~31) as tofu cause crash
build a string on windows
> static WCHAR str[] = {0x1c,0x30,0x31,0x32,0}
use TextOut(hdc,x,y,str,wcslen(str)) to output this str
on windows: output is "012"
on wine : output is "?012"
The reason is that this API does not filter ASCII control characters, and
treats the control characters as an ordinary character to output.
by the way if we fillter the control character we alse need fix the API
:GetTextExtentExPointW
Because my program uses control characters, there will be problems when
calculating the length, resulting in a crash. If I filter out the control
characters in the code myself, it will not crash. And in principle, the focus
should be on whether control characters should be output
--
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=45329
Bug ID: 45329
Summary: Fresh steam install will not install games -- error:
"content servers unreachable"
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: alasky(a)codeweavers.com
Distribution: ---
Created attachment 61617
--> https://bugs.winehq.org/attachment.cgi?id=61617
Steam error dialogue box
Ubuntu 18.04
Wine tip (most recent commit is
83f845dfa1bb4a6ec6e8b7f65e9469dc9a8a7787)
When attempting to install a game on a fresh Steam install, an error comes up
that says "content servers unreachable." The servers are not down and I am
able to install games correctly on my steam account not using wine. This issue
seems to be caused by an update on Steam's side.
--
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=54761
Bug ID: 54761
Summary: D3D12CreateDevice no longer in ABI of
libvkd3d-utils.so.1
Product: vkd3d
Version: 1.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: vkd3d
Assignee: wine-bugs(a)winehq.org
Reporter: smcv(a)collabora.com
Distribution: ---
While looking at updating Debian's vkd3d package from 1.2 to 1.7, I noticed
that `D3D12CreateDevice@VKD3D_1_0` disappeared from the ABI of
libvkd3d-utils.so.1. Was this intentional?
(D3D12CreateDeviceVKD3D@VKD3D_1_0 is still there, but if I'm understanding the
intention of this library correctly, D3D12CreateDevice@VKD3D_1_0 should have
continued to be present for backwards compat with older library binaries.)
--
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=54784
Bug ID: 54784
Summary: mIRC 7.72 crashes after restoring from application
tray
Product: Wine
Version: 8.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dragone2(a)risposteinformatiche.it
Distribution: ---
Created attachment 74279
--> https://bugs.winehq.org/attachment.cgi?id=74279
Unhandled exception: page fault on read access - mIRC - Wine-staging 8.5
mIRC was running for about 4-5 hours before the crash.
It was reduced on the tray and its icon was blinking to notify that there were
new messages / activities in channels or private messages.
I clicked on it to restore the window and see the messages and wine gave me
this backtrace (see the attachment).
I was forced to quit mIRC and restart it again.
This rarely happens, so it's not a real problem for me, but I don't know if it
could help you fix this.
Other infos:
- Executable path: D:\mIRC\mirc.exe
- mIRC Version: 7.72 (the latest one).
- mIRC running in portable mode from a specific drive (on Wine, D:\) formatted
in NTFS.
- mIRC was running using some custom scripts. But this crash never happen on
Windows.
- Distro: Linux Mint 21.1 with latest updates.
- Kernel: 5.15.0-69-generic
- Wine infos:
Wine build: wine-8.5 (Staging)
Platform: i386 (WOW64)
Version: Windows 10
- Drive Z: is a drive formatted in BTRFS.
- CPU: Intel Core i7-6700
- RAM: 32 GB, when the crash occurred I was using less than 8 GB.
--
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=52676
Bug ID: 52676
Summary: enigma protected software fails to work properly
Product: Wine
Version: 7.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: galtgendo(a)o2.pl
CC: dark.shadow4(a)web.de
Distribution: ---
Created attachment 72003
--> https://bugs.winehq.org/attachment.cgi?id=72003
backtrace of the crash (note the garbage)
As I've said in bug 49052, the trial that's supposed to work just crashes
without displaying anything.
Attaching console output.
I've got one other trial that's also enigma protected - that one starts, but
enters an infinite loop without displaying anything. That one is using an
engine that's known to work here, so I suspect enigma being the reason of the
failure.
--
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=54450
Bug ID: 54450
Summary: SINE Player fails to load "My Licenses" tab
Product: Wine
Version: 8.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jonathan(a)luxaritas.com
Distribution: ---
Created attachment 74001
--> https://bugs.winehq.org/attachment.cgi?id=74001
Wine output from application start through license tab load
Download link:
https://orchtools-sine.s3.us-west-1.amazonaws.com/SINE_Player_1.1.2.519.exe
(via https://www.orchestraltools.com/store/get-sine), sha1
9f698ada2162aa13d8e5f52d1a072464c87fd17d
After installing and signing in with an Orchestral Tools account (free), the
"My Licenses" tab is loaded. However, the tab contents remains blank. This
prevents downloading application content necessary to use the application.
It appears this page is implemented via an MS Edge based embedded
browser/webview, which seems to be relevant here - all pages that appear to be
web views fail similarly, but other pages work fine.
--
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=52569
Bug ID: 52569
Summary: Zothero Error Launch XUL
Product: Wine
Version: 7.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: blbenyamin9(a)gmail.com
Distribution: ---
Created attachment 71889
--> https://bugs.winehq.org/attachment.cgi?id=71889
Zothero Error
Launch Zothero, and imidietly got this error
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code
(0x0258904c).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:0258904c ESP:0051cb84 EBP:0051dcec EFLAGS:00010206( R- -- I - -P- )
EAX:00000000 EBX:00000000 ECX:0051cb44 EDX:00990094
ESI:009d13e8 EDI:0bc9d478
--
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=55344
Bug ID: 55344
Summary: Yuzu fails to start (needs MSVCP140_CODECVT_IDS.dll)
Product: Wine
Version: 8.12
Hardware: x86-64
URL: https://web.archive.org/web/20230727051938/https://github.com/yuzu-emu/yuzu-mainline/releases/download/mainl
ine-0-1503/yuzu-windows-msvc-20230722-3dfaf1ff2.tar.xz
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msvcp
Assignee: wine-bugs(a)winehq.org
Reporter: lingm+winebz(a)posteo.org
Distribution: ---
1. Download and extract the Windows version of Yuzu 1503.
https://github.com/yuzu-emu/yuzu-mainline/releases/tag/mainline-0-1503 (see
the URL field for a direct archived link)
2. Run `wine yuzu.exe`
3. No window even shows up. The full output is:
```
$ wine yuzu.exe
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
00d8:err:module:import_dll Library MSVCP140_CODECVT_IDS.dll (which is needed
by L"$snip_path$\\yuzu.exe") not found
00d8:err:module:LdrInitializeThunk Importing dlls for
L"$snip_path$\\yuzu.exe" failed, status c0000135
```
`winetricks vcrun2019` works around this problem and allows Yuzu to start
properly.
--
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=55331
Bug ID: 55331
Summary: ntdll:file - The 64-bit
test_file_disposition_information() gets unsupported
error on Windows 10 1607 and 1709
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
ntdll:file - The 64-bit test_file_disposition_information() gets unsupported
error on Windows 10 1607 and 1709:
file.c:3141: Test failed: unexpected FileDispositionInformationEx result
(expected STATUS_SUCCESS or SSTATUS_INVALID_INFO_CLASS, got c00000bb)
See https://test.winehq.org/data/patterns.html#ntdll:file
Where c00000bb == STATUS_NOT_SUPPORTED
c0000003 == STATUS_INVALID_INFO_CLASS
This is a case where early Windows 10 versions don't fully support
FileDispositionInformationEx(). Further tests show that:
* On Windows 10 1507 we get STATUS_INVALID_INFO_CLASS as expected by the test.
* On Windows 10 1607 the 32-bit case gets STATUS_INVALID_INFO_CLASS too but the
64-bit one gets STATUS_NOT_SUPPORTED.
* On Windows 10 1709 gets STATUS_NOT_SUPPORTED in both 32 and 64-bit.
* And Windows 10 1809 gets STATUS_SUCCESS in both cases.
The failures started on 2023-06-27 and a quick test confirms they are caused by
the commit that added the test:
commit cbc1e4423e6d40221734544d081c718cb2a2a778
Author: Joel Holdsworth <joel(a)airwebreathe.org.uk>
AuthorDate: Mon May 1 15:27:57 2023 +0100
ntdll/tests: Add tests for FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE.
Signed-off-by: Joel Holdsworth <joel(a)airwebreathe.org.uk>
--
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=54676
Bug ID: 54676
Summary: winetricks --verify dotnet20 (AutoHotKey) fails in a
wow64 build
Product: Wine
Version: 8.3
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: dotnet, download, wow64
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: austinenglish(a)gmail.com
Distribution: Debian
Created attachment 74190
--> https://bugs.winehq.org/attachment.cgi?id=74190
terminal output
The install itself seems to go okay (at least, it exits successfully in quiet
mode).
Running --verify (which should run the .Net verifier tool) instead just hangs
on:
/opt/oldwownew/wine-8.3/bin/wine y:\ahk\AutoHotkeyU32.exe
C:\windows\Temp\dotnet20.ahk
--
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=55127
Bug ID: 55127
Summary: httpapi:httpapi - test_v2_bound_port() sometimes
succeeds in connecting on Windows 10
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: httpapi
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
httpapi:httpapi - test_v2_bound_port() sometimes succeeds in connecting on
Windows 10:
httpapi.c:1426: Test failed: Connecting to socket succeeded, 0.
httpapi.c:1427: Test failed: Unexpected error connecting to socket, 0.
See https://test.winehq.org/data/patterns.html#httpapi:httpapi
This failure first happened on 2023-02-09 and has happened 4 times since then:
* 2023-02-09 win22H2_fgtb-w10pro64-32
* 2023-03-30 win22H2_fgtb-w10pro64-32
* 2023-05-30 win2009_newtb-w1064v2009-64
* 2023-06-15 win2009_newtb-w1064v2009-64
--
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=54866
Bug ID: 54866
Summary: ieframe:webbrowser - test_SetQueryNetSessionCount()
sometimes gets an unexpected session count on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: ieframe
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
ieframe:webbrowser - test_SetQueryNetSessionCount() sometimes gets an
unexpected session count on Windows:
webbrowser.c:4440: init_count 1
webbrowser.c:4443: Test failed: count = 3
webbrowser.c:4446: Test failed: count = 3
webbrowser.c:4449: Test failed: count = 2
webbrowser.c:4452: Test failed: count = 2
See https://test.winehq.org/data/patterns.html#ieframe:webbrowser
These failures only happen on Windows 10 21H1 to 22H2.
On Windows 10 init_count is either 1 or 2 (on w8adm is can be 0 too), but all
the failures so far happened with an init_count of 1. That said there are also
a lot of successful runs with init_count == 1.
This looks a lot like the browser creates a net session for its own purposes:
* Either init_count is 1 and the extra net session is never created or gets
created after test_SetQueryNetSessionCount() is done so all is fine.
* Or the extra net session is created it before test_SetQueryNetSessionCount()
starts and outlives it so our tests pass.
* Or the extra net session gets created after we get init_count but before the
next test so that all our tests are off by one.
* But it seems the extra net session never gets created after the first
SESSION_INCREMENT test.
Note that on my Windows 10 VM when I start iexplorer.exe by hand and then run
the test I always get init_count == 2. But if IE is not already running I get
init_count == 0.
In any case if it's a race condition I could send a patch to retry a couple of
times.
--
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=54073
Bug ID: 54073
Summary: ws2_32:sock - test_close_events() sometimes fails in
Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: winsock
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
ws2_32:sock - test_close_events() sometimes fails in Wine:
sock.c:6775: Test succeeded inside todo block: event series matches
sock.c:6785: Test failed: got unexpected event 0x20
sock.c:6785: Test failed: event series matches
See https://test.winehq.org/data/patterns.html#ws2_32:sock
This happens in the nightly WineTest runs about twice per month but also
impacts merge requests (for instance MR!1524 and MR!1525 where it happened on
the GitLab CI).
--
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=48621
Bug ID: 48621
Summary: Civilization 6 crashes on startup.
Product: Wine
Version: 5.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: charles2000wang(a)gmail.com
Distribution: ---
Created attachment 66468
--> https://bugs.winehq.org/attachment.cgi?id=66468
Game Log file
Launching the game opens a black window before promptly crashes with the
Firaxis Crash Reporter asking to submit a report. Digging around the game
files, I found a log file (GameOverlayRenderer.log) with messages about
"Aborting HookFunc because pRealFunctionAddr is null" and other errors.
--
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=36564
Bug ID: 36564
Summary: 'Candytron' demo: certain objects are black with GLSL
enabled
Product: Wine
Version: 1.6-rc1
Hardware: x86
URL: http://www.pouet.net/prod.php?which=9424
OS: Linux
Status: NEW
Keywords: download, regression
Severity: trivial
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: hverbeet(a)gmail.com
Regression SHA1: 2014141a253a791fc9c79aae3c8ef3c35b73e658
Created attachment 48657
--> http://bugs.winehq.org/attachment.cgi?id=48657
screenshot (comparison)
Some of the rectangles that appear in the demo nearly at 00:30 and at 01:10 are
black. They should appear as glowing green rectangles as can be seen in the
attached screenshot.
Terminal output doesn't reveal anything interesting.
Disabling GLSL is a workaround.
This is a regression from Wine 1.6-rc1:
2014141a253a791fc9c79aae3c8ef3c35b73e658 is the first bad commit
commit 2014141a253a791fc9c79aae3c8ef3c35b73e658
Author: Henri Verbeet <hverbeet(a)codeweavers.com>
Date: Wed May 29 09:45:35 2013 +0200
wined3d: Add support for GLSL based fixed function vertex shaders.
:040000 040000 d1b4b75f643d4851d4f51454aa47740261f7857f
c46794f61b1952b1e78746272d838574c0948010 M dlls
Fedora 20
Nvidia 250 gfx card / Nvidia binary drivers 337.19
wine-1.7.19-70-gd6a59f7
--
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=55367
Bug ID: 55367
Summary: Trying to run WatchFaceStudio with wine 8.0 and Ubuntu
23 (lunar)
Product: Wine
Version: 8.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: tda.bkp(a)gmail.com
Distribution: ---
Created attachment 74949
--> https://bugs.winehq.org/attachment.cgi?id=74949
WatchFaceStudio.exe crash trace
Installed WatchFaceStudio successfully, but won't run. Trace attached.
--
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=54831
Bug ID: 54831
Summary: GStreamer gst_init_check() crashes when called from
winegstreamer on recent macOS
Product: Wine
Version: 8.5
Hardware: x86-64
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: loader
Assignee: wine-bugs(a)winehq.org
Reporter: bshanks(a)codeweavers.com
On macOS Ventura (and I suspect Monterey), gst_init_check() crashes (trying to
jump to 0x0) when called by winegstreamer. This is caused by the macOS
preloader, here's how:
* gst_init_check() calls init_static_plugins()
<https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/1.22/subprojects/…>,
which through some GModule abstractions does a dlopen(NULL) and dlsym() for a
symbol that doesn't exist. dlsym() returns NULL, but GModule also calls
dlerror() which returns NULL (signaling no error).
* init_static_plugins() therefore thinks that the dlsym() was successful,
doesn't do a NULL pointer check, and jumps to the NULL pointer.
The issue here is dlerror() returning NULL despite there being an error to
report. Looking at the macOS dyld source code
(<https://github.com/apple-oss-distributions/dyld/blob/dyld-1042.1/dyld/DyldA…>),
dlerror() always returns NULL if libSystem was not initialized in the process.
And sure enough, when running vmmap on a Wine process, the message "Process
exists but has not fully started -- dyld has initialized but libSystem has not"
is printed.
After more searching in dyld, it turns out that dyld initializes libSystem for
binaries targeting 10.5 and newer. The Wine preloader targets 10.7 (since
that's the newest target that will generate an LC_UNIXTHREAD binary, critical
to how the preloader works). But dyld determines the target OS based on where
the program vars (argc, argv, environ, etc) are stored, and a 10.6/10.7 binary
should contain a __program_vars section for those. The preloader is missing
that, and so (I believe) it falls down to being considered a 10.4 binary. A
10.4 binary should init libSystem in its own _start, but the preloader also
doesn't do this, and libSystem stays uninitialized.
(See
<https://github.com/apple-oss-distributions/dyld/blob/dyld-1042.1/common/Mac…>
for where this is determined)
I see several possible solutions:
* The most obvious one: add a __program_vars section to the preloader, to make
it a correct 10.7 binary. In fact, the code can basically be copied out of
Apple's C startup code
(<https://github.com/apple-opensource/Csu/blob/88/crt.c#L47>). This does work,
and libSystem gets initialized. However, libSystem is initialized before any
preloader code runs, and malloc zones are already in the middle of areas we
want to reserve. That's bad; by itself this approach won't work, but it might
if we also:
- add linker zerofill sections to block off the entire low 4GB. This is
desirable to reserve as much address space as possible for 32-bit EXEs in wow64
mode.
- and if zerofill sections are also added to reserve the area where 64-bit
EXEs generally load (0x14000000), it might even be possible to stop using the
preloader altogether on 64-bit.
* Alternately, go the other way, and lean in to being a 10.4 binary. In that
case, _start in the preloader needs to call back into dyld to initialize things
(like this: <https://github.com/apple-opensource/Csu/blob/88/crt.c#L219>). We
could do this after reserving our areas.
I'm leery of this approach, mainly because x86_64/10.4 was not a popular target
(GUI apps were not supported, they could only link against libSystem). If
possible, I'd rather not target such an obscure combination. The preloader has
been a source of problems with new OS versions, and I'd like to decrease the
amount of black magic it's doing, not increase it.
(Running 10.4 x86_64 binaries on modern macOS is still supported though, and
Xcode can even still build them.)
I'd like to make the __program_vars+zerofill approach work if possible.
--
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.