- Wine-Bugs - list.winehq.org

[Bug 53940] New: I have an app that launches an app, but when that app launches the second app, the second app opens with a black screen.
by WineHQ Bugzilla Nov. 27, 2022

Nov. 27, 2022

https://bugs.winehq.org/show_bug.cgi?id=53940 Bug ID: 53940 Summary: I have an app that launches an app, but when that app launches the second app, the second app opens with a black screen. Product: Wine Version: 7.0-rc1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hsehnt(a)q.com Distribution: --- Created attachment 73498 --> https://bugs.winehq.org/attachment.cgi?id=73498 standard out of wine RMS\ Express.exe I have an app that launches an app, but when that app launches the second app, the second app opens with a black window. It doesn't do that in windows. I've recorded the screencast and piped the standard out to blackscreen.txt $ wine RMS\ Express.exe |& tee blackscreen.txt I updated the screencast and blackscreen.txt file. At about 10 seconds into the video I click on the open session (upper right of screen) to launch a VARA HF winlink session. This is still part of the first app (RMS Express). The VARA HF winlink session request spawns a new app called VARA. It is the VARA app that opens with a black window. If I open VARA manually, it opens with a good usable window. It's only a black window when automatically spawned by RMS Express. I don't know how to troubleshoot this. I'm hoping there is enough information in the blackscreen.txt file that can be correlated with the screen capture. -- 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 29

[Bug 53989] New: wininet:http - test_http_cache() opening the backing file sometimes fails due to a sharing violation on Windows
by WineHQ Bugzilla Nov. 26, 2022

Nov. 26, 2022

https://bugs.winehq.org/show_bug.cgi?id=53989 Bug ID: 53989 Summary: wininet:http - test_http_cache() opening the backing file sometimes fails due to a sharing violation on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: wininet Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com wininet:http - test_http_cache() opening the backing file sometimes fails due to a sharing violation on Windows: http.c:1603: Test failed: Could not create file: 32 http.c:1605: Test failed: file size = 4294967295 http.c:1613: Test failed: file size = 4294967295 http.c:1617: Test failed: Deleting file returned 1(6) http.c:1623: Test failed: Could not create file: 2 http.c:1625: Test failed: WriteFile failed: 0, 0 http.c:1627: Test failed: CommitUrlCacheEntry failed: 2 http.c:1634: Test failed: HttpSendRequest failed http.c:1639: Test failed: size = 0 http.c:1641: Test failed: incorrect page data: <html><body> <h1>Hello world!</h1> This is a test page for the Wine regression test suite. </body>< See https://test.winehq.org/data/patterns.html#wininet:http Where the first failure causes all the other ones and 32 == ERROR_SHARING_VIOLATION. This failure mode has only happened on w1064v1809, w1064-tsign (21H2) and w1064v21h2 for a total of 8 occurrences between 2022-06-13 and 2022-11-23. This seems like broken Windows behavior so maybe we should retry after a delay and a 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 1

[Bug 53988] New: wininet:http sometimes unexpectedly gets INTERNET_STATUS_RESOLVING_NAME status
by WineHQ Bugzilla Nov. 26, 2022

Nov. 26, 2022

https://bugs.winehq.org/show_bug.cgi?id=53988 Bug ID: 53988 Summary: wininet:http sometimes unexpectedly gets INTERNET_STATUS_RESOLVING_NAME status Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: wininet Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com wininet:http sometimes unexpectedly gets INTERNET_STATUS_RESOLVING_NAME status. For instance on 2022-11-23 on w1064v1507-32: http.c:5694: Testing InternetReadFileExW with IRF_NO_WAIT flag... http.c:5781: Testing InternetQueryDataAvailable... http.c:376: Test failed: unexpected status 10 (INTERNET_STATUS_RESOLVING_NAME) http.c:376: Test failed: unexpected status 11 (INTERNET_STATUS_NAME_RESOLVED) http.c:376: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) http.c:5353: Test failed: expected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) 1 times, received 2 times ... http.c:596: Starting InternetReadFile test with flags 0x10000000 on url http://test.winehq.org/tests/post.php http.c:644: Test failed: expected status 10 (INTERNET_STATUS_RESOLVING_NAME) 0 times, received 1 times http.c:645: Test failed: expected status 11 (INTERNET_STATUS_NAME_RESOLVED) 0 times, received 1 times Or in a slightly different location on 2022-08-19 on w1064v1507-64: http.c:5694: Testing InternetReadFileExW with IRF_NO_WAIT flag... http.c:376: Test failed: unexpected status 10 (INTERNET_STATUS_RESOLVING_NAME) http.c:376: Test failed: unexpected status 11 (INTERNET_STATUS_NAME_RESOLVED) http.c:376: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) http.c:5353: Test failed: expected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) 1 times, received 2 times ... http.c:596: Starting InternetReadFile test with flags 0x10000000 on url http://test.winehq.org/tests/post.php http.c:644: Test failed: expected status 10 (INTERNET_STATUS_RESOLVING_NAME) 0 times, received 1 times http.c:645: Test failed: expected status 11 (INTERNET_STATUS_NAME_RESOLVED) 0 times, received 1 times See https://test.winehq.org/data/patterns.html#wininet:http This has only been seen on w1064v1507 and the new w11pro64 VM. So it's not just a quirk of Windows 10 1507 but I don't know what sets these two test configurations apart from the others (if anything). My understanding is that we expect to get these statuses only on the first connection to the server. After that we expect the DNS information and/or server connection to be cached so that these steps are skipped. However: 1. I don't think we should make assumptions on when Windows is allowed to clear its DNS cache or reset its connections. 2. Maybe the connection was actually closed by the server? For instance my understanding is that Apache can be configured to start a new worker process after a number of requests have been served. If that limit is reached while our test runs I believe we may get disconnected and have to reconnect to the new worker process. 3. Or the winehq.org administrator restarted the (web) server on these dates? 3. Or sometimes there are just network glitches. So I think we should allow these statuses as optional pretty much everywhere. -- 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 1

[Bug 53982] New: letsvpn
by WineHQ Bugzilla Nov. 26, 2022

Nov. 26, 2022

https://bugs.winehq.org/show_bug.cgi?id=53982 Bug ID: 53982 Summary: letsvpn Product: Wine Version: 7.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: kalistochina(a)yahoo.com Distribution: --- Created attachment 73564 --> https://bugs.winehq.org/attachment.cgi?id=73564 lets vpn wont start Hi, using latest stable wine, letsvpn installed wont boot screen, new to linux, dont know how to get terminal output,screenshot included -- 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 3548] .lnk file is created on the desktop together with the program icon...
by WineHQ Bugzilla Nov. 26, 2022

Nov. 26, 2022

https://bugs.winehq.org/show_bug.cgi?id=3548 Fabian Köster <koesterreich(a)fastmail.fm> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|koesterreich(a)fastmail.fm | -- 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 11595] New: wine application crashes if linux application changes a file it has open ( Notepad++)
by wine-bugs＠winehq.org Nov. 26, 2022

Nov. 26, 2022

http://bugs.winehq.org/show_bug.cgi?id=11595 Summary: wine application crashes if linux application changes a file it has open (Notepad++) Product: Wine Version: 0.9.54. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: tycho_lamerigts(a)yahoo.com - install notepad++ - start notepad++ - create new file - save file - modify saved file with a linux application (e.g. gedit) - switch focus back to notepad++, it sees the change, then freezes. -- 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 62

[Bug 53969] New: lets vpn
by WineHQ Bugzilla Nov. 26, 2022

Nov. 26, 2022

https://bugs.winehq.org/show_bug.cgi?id=53969 Bug ID: 53969 Summary: lets vpn Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: kalistochina(a)yahoo.com Distribution: --- Created attachment 73559 --> https://bugs.winehq.org/attachment.cgi?id=73559 crash report Lets vpn installed, cannot be launched, only minimized icon shows in a tray -- 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 39221] New: msi:install fails if privileges not high enough
by wine-bugs＠winehq.org Nov. 26, 2022

Nov. 26, 2022

https://bugs.winehq.org/show_bug.cgi?id=39221 Bug ID: 39221 Summary: msi:install fails if privileges not high enough Product: Wine Version: unspecified Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: msi Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com The following failures only happen if the test is run in a user account with too few privileges. install.c:3162: Test failed: Expected ERROR_SUCCESS, got 1603 install.c:3184: Test failed: Expected ERROR_SUCCESS, got 1603 In particular one can notice this bug on the following WineTest boxes: fg-win2000-rusr: Windows 2000 in a Restricted user account fg-win7u64-1spie9usr: Windows 7 in a regular user account. fg-win7u64-1spie9adm: Windows 7 in the administrator user account but without elevated privileges. Note however that it succeeds on the following boxes: fg-win2000-susr: Windows 2000 in a Standard (Power) user account. fg-winxp-lusr: Windows XP with a Limited user account. That it succeeds in a Standard (Power) user account on Windows 2000 is probably normal, I believe those can install applications even though they are not administrators. It's a bit more surprising seeing it work in XP's Limited user account. See: https://test.winehq.org/data/tests/msi:install.html -- 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 53139] New: d3dx9_36:mesh - test_weld_vertices() has 11 rare failures on Windows 8
by WineHQ Bugzilla Nov. 26, 2022

Nov. 26, 2022

https://bugs.winehq.org/show_bug.cgi?id=53139 Bug ID: 53139 Summary: d3dx9_36:mesh - test_weld_vertices() has 11 rare failures on Windows 8 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: directx-d3d-util Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com d3dx9_36:mesh - test_weld_vertices() has 11 rare failures on Windows: mesh.c:8414: Test failed: Mesh 26: new_num_vertices == 4, expected 6. mesh.c:8428: Test failed: Mesh 26: indices[3] == 1, expected 3 mesh.c:8428: Test failed: Mesh 26: indices[4] == 3, expected 4 mesh.c:8428: Test failed: Mesh 26: indices[5] == 2, expected 5 mesh.c:8469: Test failed: Mesh 26: vertex_remap_ptr[3] == 4, expected 3 mesh.c:8469: Test failed: Mesh 26: vertex_remap_ptr[4] == -1, expected 4 mesh.c:8469: Test failed: Mesh 26: vertex_remap_ptr[5] == -1, expected 5 mesh.c:8484: Test failed: Mesh 26: Got (3.000000, 0.000000, 0.000000) for vertex 3 position, expected (2.000000, 3.000000, 0.000000). mesh.c:8484: Test failed: Mesh 26: Got (255, 255, 255, 255) for vertex 3 undefined color, expected (0, 0, 0, 0). mesh.c:8484: Test failed: Mesh 26: Got (2.000000, 3.000000, 0.000000) for vertex 4 position, expected (3.000000, 0.000000, 0.000000). mesh.c:8484: Test failed: Mesh 26: Got (255, 255, 255, 255) for vertex 5 undefined color, expected (1, 1, 1, 1). https://test.winehq.org/data/patterns.html#d3dx9_36:mesh These failures seem to only happen on Windows 8 but they are rare enough (~3.7%) that there is probably not enough evidence to definitively exclude the other Windows versions. -- 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 39235] New: wintrust:crypt fails on Windows 2000 if privileges not high enough
by wine-bugs＠winehq.org Nov. 26, 2022

Nov. 26, 2022

https://bugs.winehq.org/show_bug.cgi?id=39235 Bug ID: 39235 Summary: wintrust:crypt fails on Windows 2000 if privileges not high enough Product: Wine Version: unspecified Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: setupapi Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com The following failures only happen if the test is run in a restricted user account. crypt.c:207: Test failed: Expected success, got FALSE with 4313 crypt.c:208: Test failed: Expected a context handle, got NULL crypt.c:220: Test failed: Expected success, got FALSE with 87 crypt.c:247: Test failed: CryptCATAdminAcquireContext failed 4313 crypt.c:253: Test failed: Expected a context handle, got NULL crypt.c:262: Test failed: Expected CatRoot\{DEADBEEF-DEAD-BEEF-DEAD-BEEFDEADBEEF} directory to exist crypt.c:277: Test failed: Expected success, got FALSE with 87 crypt.c:281: Test failed: Expected success, got FALSE with 4313 crypt.c:282: Test failed: Expected a context handle, got NULL crypt.c:285: Test failed: Expected success, got FALSE with 87 crypt.c:291: Test failed: Expected FALSE and ERROR_INVALID_PARAMETER with untouched handle, got 0 and 4313 with 00000000 In particular one can notice this bug on the following WineTest box: fg-win2000-rusr: Windows 2000 with a Restricted user account Note however that it succeeds in non-Restricted user accounts on the following boxes for instance: fg-win2000-susr: Windows 2000 with a Standard (Power) user account. fg-winxp-lusr: Windows XP with a Limited user account. fg-win7u64-1spie9usr: Windows 7 with a regular user account. See: https://test.winehq.org/data/tests/wintrust:crypt.html -- 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