https://bugs.winehq.org/show_bug.cgi?id=52866
Bug ID: 52866
Summary: vbscript:run fails in Wine in Arabic and Hebrew
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: vbscript
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
vbscript:run fails in Wine in Arabic and Hebrew:
run.c:1888: Test failed: unexpected call OnScriptError
run.c:2933: Test failed: expected global_success_d
run.c:2934: Test failed: expected global_success_i
run.c:2936: Test failed: parse_script failed: 800a000d
run.c:1204: Test failed: api.vbs: L"Err.number = 13"
run.c:1204: Test failed: api.vbs: L"Err.number = 13"
run.c:1874: Error in line 1162: 0 L"Type mismatch"
run.c:1888: Test failed: unexpected call OnScriptError
run.c:2933: Test failed: expected global_success_d
run.c:2934: Test failed: expected global_success_i
run.c:2936: Test failed: parse_script failed: 800a000d
https://test.winehq.org/data/patterns.html#vbscript:run
Incidentally these are our two right-to-left test locales so this may be
related.
A bisect shows that the failures started with this commit:
commit ba43e4cfca97a9bba3e6575af82acbf011685862
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Tue Mar 29 22:11:32 2022 +0200
kernelbase: Reimplement number formatting values in GetLocaleInfoW/Ex using
the locale.nls data.
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
--
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=52857
Bug ID: 52857
Summary: msvcp140:msvcp140 fails in Windows 8.1 on the cw-rx460
machine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: msvcp
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
msvcp140:msvcp140 fails in Windows 8.1 on the cw-rx460 machine
msvcp140.c:1617: Test failed: Got unexpected err 87.
msvcp140.c:1622: Test failed: Got unexpected err 87.
https://test.winehq.org/data/patterns.html#msvcp140:msvcp140
These are new tests so unsurprisingly the failures are caused by the commit
that introduced them:
commit d72d596070eb28fd5f747fb6120d36f66ff93bec
Author: Paul Gofman <pgofman(a)codeweavers.com>
Date: Mon Apr 11 21:44:35 2022 +0300
msvcp140: Implement _Copy_file().
Signed-off-by: Paul Gofman <pgofman(a)codeweavers.com>
Signed-off-by: Piotr Caban <piotr(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
The fact that only this specific Windows 8.1 configuration fails makes sense
because it is the only one to have msvcp140 and it is a relatively old version:
it is installed by the Radeon driver.
However:
* The w7u VM does have (a much newer) msvcp140 and has no failure.
* The w1064v1607 VM has the same msvcp140 version and has no failure either.
Furthermore kernel32:file also fails in the same way in the same configuration
and shouldn't depend on msvcp140. So it's possible the issue is not related to
msvcp140 at all.
Here is a summary of the msvcp140 versions on the Windows 7, 8.1 and older
Windows 10 machines:
Win Machine msvcp140
win7 w7u 14.29.30037.0
win7 w7pro64 missing (at least for 64-bit)
win81 cw-gtx560 missing
win81 cw-rx460 14.0.23026.0
win81 w8 missing
win81 w864 missing
win1507 cw-gtx560 missing
win1507 cw-rx460 missing
win1507 w1064v1507 missing
win1607 w1064v1607 14.0.23026.0
--
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=52828
Bug ID: 52828
Summary: Incorrect instruments in MIDI playback over ALSA
Product: Wine
Version: 7.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dark(a)darkok.xyz
Distribution: ---
Created attachment 72216
--> https://bugs.winehq.org/attachment.cgi?id=72216
MIDI file that is played noticably wrong
Starting from Wine 7.5, some MIDIs aren't played back properly as they have the
incorrect instruments, at least when I've tried playing them using aplaymidi on
a VST using SAVIHost.
Downloads:
https://www.hermannseib.com/programs/savihostx64.ziphttps://cdn.roland.com/assets/media/zip/scva_win_trial.zip
Steps to reproduce:
1. Execute "winetricks mfc90" to get a required DLL
2. Extract scva_win_trial.zip and install the Roland Sound Canvas VA VST
3. Extract savihostx64.zip, and move savihost.exe to "C:\Program
Files\Roland\Sound Canvas VA"
4. Rename savihost.exe to "Sound Canvas VA.exe"
5. Run the renamed executable
6. Go to Devices>MIDI, and set Input Port 1 to "Midi Through Port-0"
7. Run "aplaymidi -p 14:0 smr_101.mid" to start playing the MIDI
8. In the VST, click "PART", and the correct instruments should be Vibraphone
for the first three, and "KICK&SNARE" for the 11th.
However, starting from Wine 7.5, these instruments are incorrectly set to
"Piano 1" for the first three, and "Syn. Strings 1" for the 11th.
--
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=48048
Bug ID: 48048
Summary: urlmon:protocol - The ftp test fail on Vista to
Windows 8
Product: Wine
Version: unspecified
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: urlmon
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
The ftp protocol test in urlmon:protocol fails frequently on Windows from Vista
to Windows 8:
protocol.c:1188: Test failed: hrResult = 800c0006, expected E_PENDING or S_OK
protocol.c:1193: Test failed: dwError = 12111, expected ERROR_SUCCESS
protocol.c:3656: Test failed: wait timed out
urlmon:protocol:0700 done (258) in 120s
Test failed: timed out
Note: 800c0006 is INET_E_OBJECT_NOT_FOUND
See https://test.winehq.org/data/tests/urlmon:protocol.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.
http://bugs.winehq.org/show_bug.cgi?id=18635
Summary: Menu bar is hidden in Adobe Lightroom 2.3
Product: Wine
Version: 1.1.22
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: thomas+wine(a)stromberg.org
With the Adobe Lightroom 2.3 demo, the menu bar titles (File, etc.) do not
display. If you click on the area that they should be, the menu does appear
however. Lightroom 2.3 can be downloaded from
https://www.adobe.com/cfusion/tdrc/index.cfm?product=photoshop_lightroom (free
Adobe login required)
I'm not sure where to go about tracing the issue down to, but I did notice the
following calls that show that it is calling DrawMenuBar().
0009:Call user32.GetMenu(0002003c) ret=60030cbe
0009:Ret user32.GetMenu() retval=000000f0 ret=60030cbe
0009:Call user32.GetMenuBarInfo(0002003c,fffffffd,00000000,0032e1a4)
ret=60030cec
fixme:menu:GetMenuBarInfo (0x2003c,0xfffffffd,0x00000000,0x32e1a4)
0009:Ret user32.GetMenuBarInfo() retval=00000000 ret=60030cec
0009:Call user32.GetSystemMenu(0002003c,00000000) ret=60030beb
0009:Ret user32.GetSystemMenu() retval=00000280 ret=60030beb
0009:Call user32.GetSystemMenu(0002003c,00000000) ret=60030c06
0009:Ret user32.GetSystemMenu() retval=00000280 ret=60030c06
0009:Call user32.GetMenuItemInfoW(00000280,0000f060,00000000,0032e08c)
ret=60030c22
0009:Ret user32.GetMenuItemInfoW() retval=00000001 ret=60030c22
0009:Call user32.DrawMenuBar(0002003c) ret=6008d171
--
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=52902
Bug ID: 52902
Summary: gdi32:font has specific failures on Windows 10 with
the UTF-8 codepage
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: gdi32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
The following gdi32:font failures are specific to UTF-8 on Windows 10:
--- test_RealizationInfo():
font.c:4356: Test failed: info[0] = 103 for the system font
--- test_GetCharacterPlacement():
font.c:4998: Test failed: Unexpected first glyph L":"
font.c:5012: Test failed: GetCharacterPlacementA returned different result:
1048638 vs 1048637
font.c:5016: Test failed: GetCharacterPlacementA returned different result:
1048638 vs 1048637
font.c:5023: Test failed: GetCharacterPlacementA returned different result:
1048638 vs 1048637
font.c:5025: Test failed: Unexpected first glyph L":"
--- test_GetCharWidthInfo():
font.c:7396: Test failed: expected 0, got -8
font.c:7397: Test failed: expected 0, got -9
font.c:7398: Test failed: expected 0, got 1
https://test.winehq.org/data/patterns.html#gdi32:font
They can be reproduced on w10pro64-hi-u8.
Note that w10pro64-hi which uses the Hindi locale too but not UTF-8 (so the
system locale is English) has its own set of totally unrelated failures.
--
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=51365
Bug ID: 51365
Summary: wininet:http causes urlmon:protocol to time out
Product: Wine
Version: 6.10
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: urlmon
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
If wininet:http is run before urlmon:url the latter will time out as follows:
protocol.c:348: Test failed: unexpected call OnResponse
protocol.c:839: Test failed: unexpected call ReportProgress_MIMETYPEAVAILABLE
protocol.c:1101: Test failed: unexpected call ReportData
protocol.c:3437: Test failed: wait timed out
protocol.c:3439: Test failed: expected Switch
protocol.c:3560: Testing http protocol (redirected, disable auto redirect)...
protocol.c:469: QueryService(IID_IGetBindHandle)
protocol.c:475: QueryService(IID_IWindowForBindingUI)
protocol.c:1178: Test failed: unexpected call ReportResult
protocol.c:1186: Test failed: hrResult = 800c0014, expected: 00000000
urlmon:protocol:0bd0 done (258) in 120s
(0x800c0014 = INET_E_REDIRECT_FAILED)
The timeout actually happens in test_http_protocol_url() on line 3437:
ok( WaitForSingleObject(event_complete, 90000) == WAIT_OBJECT_0, "wait timed
out\n" );
This actually happens on machines that use the wt-daily.bat script [1] because
that script first runs the 32-bit tests (including wininet:http) and then the
64-bit tests and, obviously, no configuration 'reset' happens in between.
Specifically this causes failures in the 64-bit urlmon:protocol results on
cw-gtx560 and cw-rx460:
https://test.winehq.org/data/patterns.html#urlmon:protocol
[1] https://github.com/fgouget/wt-daily/blob/master/wt-daily.bat.template#L138
--
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=50348
Bug ID: 50348
Summary: MFMEv20 Emulator crashes on start
Product: Wine
Version: 6.0-rc2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: adec2011.ac(a)gmail.com
Distribution: ---
Created attachment 68935
--> https://bugs.winehq.org/attachment.cgi?id=68935
Log file for crash
MFMEv20 crashes on start. Log file 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=46330
Bug ID: 46330
Summary: [Feature Request] Enable winelib on ppc64el
Product: Wine
Version: unspecified
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: winelib
Assignee: wine-bugs(a)winehq.org
Reporter: tpearson(a)raptorengineering.com
Distribution: ---
With the resurgence in POWER hardware support and interest centering around the
POWER8/POWER9 chips, it would be great to get winelib support for the ppc64el
architecture. This would allow Windows open source applications to be used on
these powerful machines (e.g. FEMM, SQLYog, etc.).
--
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=52430
Bug ID: 52430
Summary: Ubi Connect Launcher forever shows a black window
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: blue-t(a)web.de
Distribution: ---
Created attachment 71690
--> https://bugs.winehq.org/attachment.cgi?id=71690
Console Log
When you try to run the Ubi Connect Launcher, it never finishes the start
sequence. Instead of showing the "Ubisoft Connect" Text alongside a logo inside
a frame with small status updates in the lower left corner before displaying
news and installed games, it just shows an empty black window that never
vanishes and never gets content.
On the console variuous notes about shaders are repeated.
The AppDB says using corefonts via winetricks should make it boot, but it
doesn't.
The Card is an amd rtx480 on a Kubuntu 21.10.
--
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.