wine-bugs February 2020

wine-bugs@winehq.org

1 participants
7384 discussions

[Bug 48427] New: Broken link to http://www.winehq.org/site/docs/wineserver
by WineHQ Bugzilla 22 Aug '20

22 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=48427 Bug ID: 48427 Summary: Broken link to http://www.winehq.org/site/docs/wineserver Product: WineHQ.org Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: carlos(a)superkaos.org Distribution: --- The link: http://www.winehq.org/site/docs/wineserver is broken. It can be found at least here: https://wiki.winehq.org/Wineserver Where it says: "For more information on invoking the wineserver, see the man page" -- 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 47515] New: Wineserver Wiki page contains broken links to Wineserver manpage
by wine-bugs＠winehq.org 22 Aug '20

22 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=47515 Bug ID: 47515 Summary: Wineserver Wiki page contains broken links to Wineserver manpage Product: WineHQ.org Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: newbie13xd(a)gmail.com Distribution: --- This page contains two links to the Wineserver manpage, however both are broken. Aside from this, it contains the text "{{{server/protocol.def}}}", which I assume is meant to be a link. Here is the link: https://wiki.winehq.org/Wineserver -- 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 42436] New: Wine Wiki: Building Wine - Memory & Address Checkers
by wine-bugs＠winehq.org 22 Aug '20

22 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=42436 Bug ID: 42436 Summary: Wine Wiki: Building Wine - Memory & Address Checkers Product: WineHQ.org Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: wylda(a)volny.cz Distribution: --- I don't know, if anyone tried recently follow wiki link: https://wiki.winehq.org/Building_Wine#Memory_.26_Address_Checkers This link mentions "...you only need to pass the -fsanitize=address flag to the compiler when building" ../wine-source/configure CFLAGS="-g -O1 -fsanitize=address -other-flags" But this fails soon in make_xftmpl.o: In function fatal_error': ..../tools/make_xftmpl.c:116: undefined reference to `__asan_option_detect_stack_use_after_return' ..../tools/make_xftmpl.c:116: undefined reference to `__asan_stack_malloc_1' Passing LIBS="-lasan" to configure fixes this, but build fails anyway at cca 63%: ..../dlls/ntdll/loader.c:2979: undefined reference to `pthread_sigmask' Per some gentoo wiki: Some configure scripts test the need of the -lpthread compiler flag by testing whether the function pthread_create() is available without it. The Address Sanitizer library (libasan) provides this function. However it does not have a full pthread implementation, more advanced pthread functions aren't provided. Therefore the compilation fails. A workaround is to add the -lpthread compiler flag manually. Passing LIBS="-lasan -lpthread" to configure fixes this issue, but anyway fails at the end: ../tools/sfnt2fon/sfnt2fon -o coue1255.fon ../../wine_git_src/fonts/courier.ttf -d 128 13,1255,8 Makefile:174: recipe for target 'coue1255.fon' failed ==16755==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. make[1]: *** [coue1255.fon] Error 1 make: *** [fonts] Error 2 Did anyone tried to follow that Wiki? I tried that on Debian Stretch. Gcc (Debian 6.3.0-6) 6.3.0 20170205 -- 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 46446] New: Value for WM_KEYLAST too low in https://wiki.winehq.org/ List_Of_Windows_Messages
by wine-bugs＠winehq.org 22 Aug '20

22 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=46446 Bug ID: 46446 Summary: Value for WM_KEYLAST too low in https://wiki.winehq.org/List_Of_Windows_Messages Product: WineHQ.org Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: jeroen.bugs.winehq.org(a)pluimers.com Distribution: --- Value for WM_KEYLAST is 0x0108 (264) but should be 0x0109 (265) as the range Value for WM_KEYFIRST .. WM_KEYLAST should include WM_UNICHAR which correctly has value 0x0109 (265) as per https://docs.microsoft.com/en-us/windows/desktop/inputdev/wm-unichar -- 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 3

[Bug 39380] New: test.winehq.org: Provide a way to know why a report was rejected
by wine-bugs＠winehq.org 22 Aug '20

22 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=39380 Bug ID: 39380 Summary: test.winehq.org: Provide a way to know why a report was rejected Product: WineHQ.org Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- When WineTest submits a report that report can get thrown away. Either because it's too big, because it has too many failures, because too many tests were skipped or because of other reasons unknown. The WineTest.exe is never notified of this because the report analysis is run asynchronously with respect tot he submission process. But annoyingly there is no way for the submitter to know why the report was rejected even later, levaing him to guess as to what needs fixing. One way to plug this hole would be to send an email with the reason to the address field in the report. But that could probably be abused to send emails to arbitrary persons. A very simple alternative would be to create a per-commit text file containing one line per ignored report with the report's tag, timestamp of when it was analyzed and the reason why it was ignored. -- 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 47805] New: SkyUI mod for Skyrim Special Edition with SKSE64 fails to show HUD active effect icons (other functions of mod work)
by WineHQ Bugzilla 21 Aug '20

21 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=47805 Bug ID: 47805 Summary: SkyUI mod for Skyrim Special Edition with SKSE64 fails to show HUD active effect icons (other functions of mod work) Product: Wine Version: 4.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: cyan255(a)gmail.com Distribution: --- 1. Set up a 64-bit prefix. 2. Install Skyrim Special Edition via Steam. 3. Install SKSE64. 4. Install SkyUI from NexusMods https://www.nexusmods.com/skyrimspecialedition/mods/12604 5. Launch skseloader.exe(via Mod Manager, such as MO, or directly, doesn't matter) 6. create a character and check that SKSE has loaded correctly (skse version shown in MENU>System on bottom left. 7.Make sure that Active Effects HUD is enabled in MENU> Mod Configuration> SkyUI> General. 8. during play consume an item that causes a active effect (like salt pile or something poisonous) 9. Notice that active effect shows the timer bar in the HUD (top right by default) but its icon does not show. This setup works in Windows but not with Wine 4.16 Skyrim SE 1.5.80.08 SkyUI_5_2_SE-12604-5-2SE Skyrim Script Extender 64 v2.0.16 beta https://i.imgur.com/P6NOJBc.png (effect status time in top right) -- 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 30853] New:=?UTF-8?Q?=20Wine=20doesn=E2=80=99t=20always=20handle=20?="right alt" properly
by wine-bugs＠winehq.org 20 Aug '20

20 Aug '20

http://bugs.winehq.org/show_bug.cgi?id=30853 Bug #: 30853 Summary: Wine doesn’t always handle "right alt" properly Product: Wine Version: 1.5.5 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: sloonz(a)gmail.com Classification: Unclassified Created attachment 40410 --> http://bugs.winehq.org/attachment.cgi?id=40410 workaround/quick and dirty fix I’m trying to get World of Warcraft working under Wine. However, I have huge trouble with key bindings (I use unusual key bindings : I use the right half of my keyboard, whereas most players use the left half). After investigation, I found 3 bugs (different behaviors between Wine and my Windows installation). The first one is the management of the right "Alt" key (labeled "Alt-Gr" on my keyboard). When I press AltGr+l under Windows with Spy++, I get the followings events : <03637> 0007045A P WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <03638> 0007045A P WM_KEYDOWN nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:1 fRepeat:0 fUp:0 <03639> 0007045A P WM_KEYDOWN nVirtKey:'L' cRepeat:1 ScanCode:18 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <03640> 0007045A P WM_DEADCHAR chCharCode:'002F' (47) cRepeat:1 ScanCode:18 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <03641> 0007045A P WM_KEYUP nVirtKey:'L' cRepeat:1 ScanCode:18 fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <03642> 0007045A P WM_SYSKEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <03643> 0007045A P WM_KEYUP nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 Under Wine 1.5.5 however (WINEDEBUG=+msg), I get those : trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x6007e wp eb lp 760001 [note: wp = VK_OEM_PA2] trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x6007e wp 4c lp c0260001 [note: wp = 'L'] trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x6007e wp eb lp c0760001 [note: wp = VK_OEM_PA2] With xev, I get : KeyPress event, serial 93, synthetic NO, window 0x4000001, root 0xbc, subw 0x0, time 5086996, (1585,410), root:(2578,425), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 93, synthetic NO, window 0x4000001, root 0xbc, subw 0x0, time 5087052, (1585,410), root:(2578,425), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False After "setxkbmap us", AltGr is bound to Alt_R under X (checked with xev), and I get this under Wine : trace:msg:peek_message got type 7 msg 104 (WM_SYSKEYDOWN) hwnd 0x10046 wp a5 lp 21380001 [wp = VK_RMENU] trace:msg:peek_message got type 7 msg 104 (WM_SYSKEYDOWN) hwnd 0x10046 wp 4c lp 20260001 [wp = 'L'] trace:msg:peek_message got type 6 msg 106 (WM_SYSCHAR) hwnd 0x10046 wp 6c lp 20260001 [wp = 'l'] trace:msg:peek_message got type 7 msg 105 (WM_SYSKEYUP) hwnd 0x10046 wp 4c lp e0260001 [wp = 'L'] trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10046 wp a5 lp c1380001 [wp = VK_RMENU] (yes, I have a KEYUP without KEYDOWN) Wich is still not the same as Windows. So I think there is two problems here : - ISO_Level3_Shift is not properly recognized by Wine - "AltGr" doesn't have the same behavior under Wine and Windows FYI, attached patch is a workaround to have the same behavior than Windows. With it, I get this under Wine : trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10062 wp a2 lp 1d0001 [note: wp = VK_LCONTROL] trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10062 wp a4 lp 20380001 [note: wp = VK_LMENU] trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10062 wp 4c lp 20260001 [note: wp = 'L'] trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10062 wp 4c lp e0260001 trace:msg:peek_message got type 7 msg 105 (WM_SYSKEYUP) hwnd 0x10062 wp a2 lp e01d0001 trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10062 wp a4 lp c0380001 Which is still not the same as Windows : - Windows uses (right) control + menu (with fExtended flag for menu) whereas Wine uses left control + left menu. Not investigated if this is related to TranslateMessage. - AltGr+L is a dead symbol on my keymap. Windows send a DEADCHAR message, wheras Wine send nothing. Note that I had to disable the XFilterEvent test in event.c to have those messages, otherwise nothing is sent to the program (but that’s another story for another bug report) But it suffice for my use case (WoW key bindings with right alt) -- 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 8

[Bug 47604] New: Cannot use the app
by wine-bugs＠winehq.org 19 Aug '20

19 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=47604 Bug ID: 47604 Summary: Cannot use the app Product: Packaging Version: unspecified Hardware: aarch64 OS: Android Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-packages Assignee: wine-bugs(a)winehq.org Reporter: fzh2003(a)yeah.net CC: dimesio(a)earthlink.net, michael(a)fds-team.de, sebastian(a)fds-team.de Created attachment 65029 --> https://bugs.winehq.org/attachment.cgi?id=65029 screenshot Android 9 kernel 4.9.154 model Huawei SEA-AL00 -- 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 41000] New: wineconsole curses backend 64bit: Some uppercase chars broken on Crysis Wars Dedicated Server
by wine-bugs＠winehq.org 19 Aug '20

19 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=41000 Bug ID: 41000 Summary: wineconsole curses backend 64bit: Some uppercase chars broken on Crysis Wars Dedicated Server Product: Wine Version: 1.9.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: programs Assignee: wine-bugs(a)winehq.org Reporter: main.haarp(a)gmail.com Distribution: --- I am running the Crysis Wars Dedicated Server in wineconsole. The server offers both 32bit and 64bit binaries. Using wineconsole's user backend, both 32 and 64bit work fine. Using the curses backend, 32bit works fine. 64bit however experiences a bug. Some uppercase characters cannot be typed or pasted at all. There is no reaction. wineconsole will display them just fine, but simply will not let them be typed. The affected chars are uppercase versions of these: 2 4 6 0 - f h j k ; [] q r t y o p x c v m , . / (assuming US keyboard layout) -- 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 30193] New: Crysis Wars ded server doesn't resize with wineconsole (curses backend)
by wine-bugs＠winehq.org 19 Aug '20

19 Aug '20

http://bugs.winehq.org/show_bug.cgi?id=30193 Bug #: 30193 Summary: Crysis Wars ded server doesn't resize with wineconsole (curses backend) Product: Wine Version: 1.4-rc6 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: liquitsnake(a)gmx.net Classification: Unclassified Created attachment 39410 --> http://bugs.winehq.org/attachment.cgi?id=39410 screen The Crysis Wars dedicated server, when running under wineconsole with the curses backend, does not resize its viewport. It is stuck at the default 80x25, even if the terminal is considerably larger (see attachment). This produces some unexpected output, as some commands expect a larger size but have to be split over 2 lines via \ My terminal and wineconsole interact just fine, as I have verified with cmd. It's just this app that sticks to 80x25 no matter what. On Windows, it would normally spawn a console window with a size of 132x60 (or less if the desktop resolution can't fit that) Could it be that wineconsole first starts at 80x25 and only later resizes to terminal size? In that case, I can imagine that the app polls the size once during startup and sticks to that, thus limiting itself to 80x25. -- 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 11

[Bug 37928] New: Photoshop CS6: Mini-bridge panel does not show directory entries in alphabetical order
by wine-bugs＠winehq.org 19 Aug '20

19 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=37928 Bug ID: 37928 Summary: Photoshop CS6: Mini-bridge panel does not show directory entries in alphabetical order Product: Wine Version: 1.7.34 Hardware: arm OS: Linux Status: UNCONFIRMED Severity: normal Priority: P3 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: robert.munteanu(a)gmail.com Distribution: --- Steps to reproduce: 1. Launch Photoshop 2. Click File -> Open in mini bridge 3. Navigate to a folder with multiple subfolders The subfolders are not ordered alphabetically, but in an apparently random manner. They are definitely not ordered by creation date ( I created the situation in my screenshot using a simple "mkdir a b c d e f g h i j k l" . -- 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 6

[Bug 43924] New: Alice: Madness Returns cannot sign in to EA
by wine-bugs＠winehq.org 18 Aug '20

18 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=43924 Bug ID: 43924 Summary: Alice: Madness Returns cannot sign in to EA Product: Wine Version: 2.19 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexchandel(a)gmail.com Distribution: --- Created attachment 59552 --> https://bugs.winehq.org/attachment.cgi?id=59552 wine-2.19 output Before startup, Alice: Madness Returns requires you to sign into an EA account. However, the EA sign-in never succeeds, always returning a sign-in failure. Wine output 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.

2 5

[Bug 43923] New: Alice: Madness Returns immediately crashes with Page Fault
by wine-bugs＠winehq.org 18 Aug '20

18 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=43923 Bug ID: 43923 Summary: Alice: Madness Returns immediately crashes with Page Fault Product: Wine Version: 2.19 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexchandel(a)gmail.com Distribution: --- Created attachment 59551 --> https://bugs.winehq.org/attachment.cgi?id=59551 backtrace Alice: Madness Returns doesn't run. Installed with Steam, using a serial purchased through Steam. I've played with it a bit trying to get it working, and at best it crashes with a page fault immediately. -- 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 6

[Bug 13624] New: Lineage 2 - The Chaotic Throne - Hellbound
by wine-bugs＠winehq.org 16 Aug '20

16 Aug '20

http://bugs.winehq.org/show_bug.cgi?id=13624 Summary: Lineage 2 - The Chaotic Throne - Hellbound Product: Wine Version: 1.0-rc3 Platform: All OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: eryk-rutkowski(a)o2.pl Created an attachment (id=13604) --> (http://bugs.winehq.org/attachment.cgi?id=13604) Log from Terminal Problem is in Lineage 2 Hellbound and regarding npkycrypt - dll file. This dll is not work fine and don't recognize keyboard and i can't log in. There is communicate: "The keyboard security module has failed to load. please exit the game and try again" Sorry for my bad english but i'm from other country ;p -- 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 9

[Bug 47106] New: Fallout 4 FAudio [wmav2 @ 0x7f9ad0135d80] prev_block_len_bits 4 out of range
by wine-bugs＠winehq.org 16 Aug '20

16 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=47106 Bug ID: 47106 Summary: Fallout 4 FAudio [wmav2 @ 0x7f9ad0135d80] prev_block_len_bits 4 out of range Product: Wine Version: 4.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: xaudio2 Assignee: wine-bugs(a)winehq.org Reporter: timofeevsv1989(a)gmail.com Distribution: --- Fallout 4 freezing (or sound disappearing) with spam of tons console messages: [wmav2 @ 0x7f9ad0135d80] prev_block_len_bits 4 out of range INFO System-wide FAudio, not winetricks one Something wrong in connection XAudio2->FAudio -- 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 10

[Bug 46670] New: Unhandled exception on Blizzard Battle.net
by wine-bugs＠winehq.org 16 Aug '20

16 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=46670 Bug ID: 46670 Summary: Unhandled exception on Blizzard Battle.net Product: Wine-staging Version: 4.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: b1779506(a)trbvn.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- See attachments. -- 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 7

[Bug 48410] New: The "Add syscall thunks for 64 bit" patch partly breaks USVFS
by WineHQ Bugzilla 16 Aug '20

16 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=48410 Bug ID: 48410 Summary: The "Add syscall thunks for 64 bit" patch partly breaks USVFS Product: Wine-staging Version: 5.0-rc3 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: qsniyg(a)mail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- This is the patch that breaks USVFS: https://github.com/wine-staging/wine-staging/blob/d36d63ac848dadbc2c8ffc933… (discussion: https://github.com/ModOrganizer2/modorganizer/issues/372). I've only tested 64-bit, so it's possible https://github.com/wine-staging/wine-staging/blob/master/patches/winebuild-… also affects it. Although USVFS works for the most part, loading DLLs fails, because LdrLoadDll (within ntdll) calls NtOpenFile (through open_dll_file), but for some reason, USVFS doesn't recognize that specific NtOpenFile call (even though it hooks other NtOpenFile calls that aren't called from ntdll without issue). I haven't looked through the patch in much detail, but from what I can tell I believe the reason why this patch breaks USVFS is because the calls to NtOpenFile from within ntdll use the direct function address, whereas with the patch, USVFS now hooks a new "wrapper" around the function, instead of the same address that ntdll calls internally. -- 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 9

[Bug 44571] New: Unable to build cue sheets with IMGBurn
by wine-bugs＠winehq.org 16 Aug '20

16 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=44571 Bug ID: 44571 Summary: Unable to build cue sheets with IMGBurn Product: Wine-staging Version: 3.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: halo117nachos(a)gmail.com CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de, sebastian(a)fds-team.de Distribution: --- Created attachment 60538 --> https://bugs.winehq.org/attachment.cgi?id=60538 stderr and stdout Everytime I try to build a cue sheet out of MP3 files with IMGBurn, the program crashes. Building a cue sheet is the first step in burning MP3 (and other audio files) to standard red book audio discs, so if one can't build a cue sheet, one can't burn music. Of course, I made a new wine prefix to test this, and found that it didn't solve the problem at all. :( Here's what happens: If I click the tools menu, and select "Create Cue File... ", and I start manually adding MP3s, first the program hangs, and then it says the following: "Potential Direct Show Error! - No data has been received for 10 seconds file name: C:\blablabla\file.mp3 Decoding Progress: 9,999,999 bytes" It then gives me three options: "Cancel", "Try Again", and "Continue". BTW, that number (9,999,999) seems to very with each MP3 file. It's possible that whatever number it lands on is the end of the file. I also tend to get a more generic error, although this one is harder to reproduce. IDK if this is the same bug or not. The error is: "An error occured in the application There might be an updated version available that fixes the pr [the rest of this line seems to be cut off by some buttons on the right] Please check the website for updates - http://www.imgburn.co [once again, the message is cut off]" There are three buttons on the bottom, and three on the right (the ones on the right are the ones that cut off the text). The ones on the bottom are "send bug report", "save bug report", and "show bug report". The buttons on the right are "Continue application", "Restart application", and "Close application". If I click "Continue application", the program seems to continue working. PS: I've just run IMGBurn from the terminal, and redirected both stdout and stderr to a file, which I've attached to this report. When the aformentioned "generic" error message appeared. I tried to click "Close application", but the program froze, forcing me to kill it. That error happened on the second file. BTW, I'm running Ubuntu 16.04, and I've installed winehq-devel 3.2 from the official repositories. Also, I didn't modify the prefix at all, except to install IMGBurn, and to change the default version of Windows to XP (otherwise IMGBurn doesn't start). -- 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 9

[Bug 40958] New: Toontown Rewritten has major lag on wine-staging on FreeBSD and GNOME 3
by wine-bugs＠winehq.org 16 Aug '20

16 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=40958 Bug ID: 40958 Summary: Toontown Rewritten has major lag on wine-staging on FreeBSD and GNOME 3 Product: Wine-staging Version: 1.9.13 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: neel(a)neelc.org CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de, sebastian(a)fds-team.de Toontown Rewritten (http://toontownrewritten.com/) has major lag with keystrokes on wine-staging when I use FreeBSD and GNOME 3. TTR is a online game, and using keyboard controls often results in the display lagging by a few seconds. Other desktop environments don't have this lag to as great of an extent (I also tested TTR on Mate and Fluxbox). Is there a reason for this? -- 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 45437] New: Readme' s installation instructions link leads to winehq page with no installation instructions
by wine-bugs＠winehq.org 16 Aug '20

16 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=45437 Bug ID: 45437 Summary: Readme's installation instructions link leads to winehq page with no installation instructions Product: Wine-staging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: root(a)swooshalicio.us CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- The readme in the wine-staging repository links to https://wine-staging.com/installation.html which redirects to https://wiki.winehq.org/Wine-Staging which contains no information for installing wine-staging. -- 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 3

[Bug 48188] New: wine fails to load, "kernelbase.dll" failed to initialize, aborting
by WineHQ Bugzilla 15 Aug '20

15 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=48188 Bug ID: 48188 Summary: wine fails to load, "kernelbase.dll" failed to initialize, aborting Product: Wine Version: 4.20 Hardware: x86 OS: Linux Status: NEW Keywords: download, regression Severity: critical Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com CC: julliard(a)winehq.org Distribution: --- 000b:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, aborting 000b:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\wineboot.exe" failed, status c0000005 0009:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, aborting 0009:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\wineboot.exe" failed, status c0000005 d05c9f12fb9409e2bc65bb59fa596c9872915d40 is the first bad commit commit d05c9f12fb9409e2bc65bb59fa596c9872915d40 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Wed Nov 27 09:54:51 2019 +0100 kernelbase: Initialize codepage data using ntdll functions. Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> :040000 040000 46104b3961726d8c6d83abb04a7619008d88aad1 bedb6cb4be88dc3711d75909d60ca4d89dfb6702 M dlls mingw is enabled: austin@laptop ~/wine-git ((no branch, bisect started on master)) $ i686-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=i686-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-w64-mingw32/9.2.0/lto-wrapper Target: i686-w64-mingw32 Configured with: /var/tmp/portage/cross-i686-w64-mingw32/gcc-9.2.0-r2/work/gcc-9.2.0/configure --host=x86_64-pc-linux-gnu --target=i686-w64-mingw32 --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/i686-w64-mingw32/gcc-bin/9.2.0 --includedir=/usr/lib/gcc/i686-w64-mingw32/9.2.0/include --datadir=/usr/share/gcc-data/i686-w64-mingw32/9.2.0 --mandir=/usr/share/gcc-data/i686-w64-mingw32/9.2.0/man --infodir=/usr/share/gcc-data/i686-w64-mingw32/9.2.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-w64-mingw32/9.2.0/include/g++-v9 --with-python-dir=/share/gcc-data/i686-w64-mingw32/9.2.0/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 9.2.0-r2 p3' --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-poison-system-directories --with-sysroot=/usr/i686-w64-mingw32 --disable-bootstrap --disable-multilib --disable-altivec --disable-fixed-point --with-arch=i686 --enable-targets=all --disable-libgomp --disable-libmudflap --disable-systemtap --disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto --without-isl --disable-libsanitizer --disable-default-pie --enable-default-ssp Thread model: win32 gcc version 9.2.0 (Gentoo 9.2.0-r2 p3) -- 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 4

[Bug 46047] New: Multiple applications want Windows 8+ futex-like operations kernel32.dll.WaitOnAddress , kernel32.dll.WakeByAddress{All,Single} (VLC)
by wine-bugs＠winehq.org 15 Aug '20

15 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=46047 Bug ID: 46047 Summary: Multiple applications want Windows 8+ futex-like operations kernel32.dll.WaitOnAddress, kernel32.dll.WakeByAddress{All,Single} (VLC) Product: Wine Version: 3.18 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, to track: * https://www.winehq.org/pipermail/wine-devel/2018-October/134085.html * https://www.winehq.org/pipermail/wine-devel/2018-October/134086.html There is a series of articles on the background/inner workings of this Windows 8+ futex-like operations by Raymond Chen on Microsoft developer blog "The Old New Thing": (1) https://blogs.msdn.microsoft.com/oldnewthing/20160823-00/?p=94145 ("WaitOnAddress lets you create a synchronization object out of any data variable, even a byte") (2) https://blogs.msdn.microsoft.com/oldnewthing/20160824-00/?p=94155 ("Implementing a synchronization barrier in terms of WaitOnAddress") (3) https://blogs.msdn.microsoft.com/oldnewthing/20160825-00/?p=94165 ("Implementing a critical section in terms of WaitOnAddress") (4) https://blogs.msdn.microsoft.com/oldnewthing/20160826-00/?p=94185 ("Spurious wakes, race conditions, and bogus FIFO claims: A peek behind the curtain of WaitOnAddress") Alternative overview to the blog using Github-based WIKI: https://github.com/mity/mctrl/wiki/Old-New-Win32API (click the sections to get to blog entries) WaitOnAddress() * WaitOnAddress lets you create a synchronization object out of any data variable, even a byte * Implementing a synchronization barrier in terms of WaitOnAddress * Implementing a critical section in terms of WaitOnAddress * Extending our critical section based on WaitOnAddress to support timeouts * Comparing WaitOnAddress with futexes (futexi? futexen?) * Creating a semaphore from WaitOnAddress * Creating a semaphore with a maximum count from WaitOnAddress * Creating a manual-reset event from WaitOnAddress * Creating an automatic-reset event from WaitOnAddress Related: bug 45524 ("Add a futex-based implementation of condition variables") I found multiple applications which make use of this Windows 8+ API. Example: VLC https://github.com/videolan/vlc/blob/master/src/win32/thread.c Most of them have fallback implementations if the API is not available so it's not critical to the functionality. But it's still good to have real world tests :-) 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.

2 10

[Bug 47766] New: PathAllocCanonicalize treats path segments start with dots wrong.
by WineHQ Bugzilla 15 Aug '20

15 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=47766 Bug ID: 47766 Summary: PathAllocCanonicalize treats path segments start with dots wrong. Product: Wine Version: 4.16 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: zzhang(a)codeweavers.com Distribution: --- This bug was reported on wine-devel mail list by Sebastian M. Ernst <ernst(a)pleiszenburg.de> user@comp:/path/other> WINEDEBUG=-all PYTHONHOME="z:\\path\\.to\\target" wine /path/.to/target/python.exe -c "import sys; print(sys.executable)" Z:\pathto\target\python.exe PYTHONHOME="z:\\path\\..to\\target" wine /path/..to/target/python.exe -c "import sys; print(sys.executable)" Z:\to\target\python.exe -- 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 9

[Bug 48542] New: Mono (and probably .NET) needs CreateThreadpoolIo
by WineHQ Bugzilla 15 Aug '20

15 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=48542 Bug ID: 48542 Summary: Mono (and probably .NET) needs CreateThreadpoolIo Product: Wine Version: 5.0 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: madewokherd(a)gmail.com Distribution: --- Found testing LiveSplit 1.7.7 on Wine Mono from the master branch. Mono's implementation of System.Threading.ThreadPoolBoundHandle depends on CreateThreadpoolIo. Wine's stub of this function returns 0 and doesn't set last error, resulting in the confusing message "System.IO.IOException: Success". This can be more easily reproduced by running 'make test' in Wine Mono and running tests/run-tests.exe MonoTests.System.IO.Pipes.PipeSecurityTest:NamedPipePermissionsActuallyWorkAsync -- 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 8

[Bug 48471] New: Mismatching behavior of GetEnvironmentVariableW for empty / long values
by WineHQ Bugzilla 15 Aug '20

15 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=48471 Bug ID: 48471 Summary: Mismatching behavior of GetEnvironmentVariableW for empty / long values Product: Wine Version: 5.0-rc4 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: wine(a)thecybershadow.net Distribution: --- Attempting to build the Windows version of DMD, the reference compiler for the D programming language, fails under Wine. This seems to be caused by the following chain of events: 1. The makefile invokes a build program with a "VERBOSE=" on the command-line: https://github.com/dlang/dmd/blob/49dfbe54f4a0f62a0694aec9fb4184739903a0c2/… (Here "$(VERBOSE)" is not set and expands to the empty string.) 2. The build program registers the command-line arguments into the process environment: https://github.com/dlang/dmd/blob/49dfbe54f4a0f62a0694aec9fb4184739903a0c2/… This sets the environment variable VERBOSE to the empty string. 3. Later, it attempts to check if the "VERBOSE" variable is in the environment: https://github.com/dlang/dmd/blob/49dfbe54f4a0f62a0694aec9fb4184739903a0c2/… 4. This calls the following Windows code in the standard library to read the environment: https://github.com/dlang/phobos/blob/e373b4e77448bc11c6e4ea6c85bcdb8f7ab86f… 5. For empty variables, the code behaves differently in Windows and Wine - Wine's implementation returns 0, while Windows returns 1. As a result, the standard library code throws an exception under Wine. Writing a test program reveals further differences. The program: #include <stdio.h> #include <windows.h> void main() { WCHAR buf[4]; DWORD size; int len, i; for (len = 0; len <= 2; len++) { for (i = 0; i < len; i++) buf[i] = 'a'; buf[len] = 0; SetEnvironmentVariableW(L"TESTVAR", buf); for (i = 0; i <= len + 1; i++) { DWORD err; SetLastError(1); buf[0] = 1; size = GetEnvironmentVariableW(L"TESTVAR", buf, i); err = GetLastError(); printf("%d->%d: size=%d error=%d buf[0]=%d\n", len, i, size, err, buf[0]); } printf("\n"); } } Output on Windows [Version 10.0.17134.648]: 0->0: size=1 error=1 buf[0]=1 0->1: size=0 error=1 buf[0]=0 1->0: size=2 error=1 buf[0]=1 1->1: size=2 error=1 buf[0]=0 1->2: size=1 error=1 buf[0]=97 2->0: size=3 error=1 buf[0]=1 2->1: size=3 error=1 buf[0]=0 2->2: size=3 error=1 buf[0]=0 2->3: size=2 error=1 buf[0]=97 Output on Wine: 0->0: size=0 error=1 buf[0]=1 0->1: size=0 error=1 buf[0]=0 1->0: size=2 error=122 buf[0]=1 1->1: size=2 error=122 buf[0]=1 1->2: size=1 error=1 buf[0]=97 2->0: size=3 error=122 buf[0]=1 2->1: size=3 error=122 buf[0]=1 2->2: size=3 error=122 buf[0]=1 2->3: size=2 error=1 buf[0]=97 We can observe these differences: 1. Wine returns 0 and not 1 when the variable is empty and the function is given a zero-length buffer. 2. Wine sets the last error to ERROR_INSUFFICIENT_BUFFER, while Windows doesn't. 3. Windows zeroes the buffer if the size is non-zero but still insufficient to hold the value. (This is not a bug as the behavior is specified in the documentation to be undefined.) -- 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 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs February 2020