https://bugs.winehq.org/show_bug.cgi?id=51217
Bug ID: 51217
Summary: RtlWow64IsWowGuestMachineSupported() check fails on
w1064v1607 for the 32-bit ntdll:info
Product: Wine
Version: 6.8
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:info has a failure on w1064v1607 (Windows 10 64-bit version 1607 running
the 32-bit tests):
https://test.winehq.org/data/patterns.html#ntdll:info
info.c:3024: Test failed: wrong result 0
This is a check of the RtlWow64IsWowGuestMachineSupported() result.
The commit that introduced this check is:
commit 4f8ede8e7665328a2a3ccd303875e239bf443512
Author: Alexandre Julliard <julliard(a)winehq.org>
AuthorDate: Thu Apr 29 17:15:15 2021 +0200
ntdll: Implement RtlWow64IsWowGuestMachineSupported().
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=51078
Bug ID: 51078
Summary: mshtml:events hangs on Windows 10 1709
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: mshtml
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Created attachment 69941
--> https://bugs.winehq.org/attachment.cgi?id=69941
Patch to more reliably reproduce the hang
mshtml:events sometimes hangs on Windows 10 1709:
http://winetest.dolphin/data/patterns.html#mshtml:events
For some reason this only happens on Windows 1709 (the reports say this is
mshtml 11.0.16299.309).
The test proceeds all the way to the end but then does not exit because the
mshtml component still has threads running:
VSyncHelper
Internet Explorer_Hidden
MSCTFIME UI
Commenting out the test_focus() run gets rid of the hangs.
Also running the test with WINETEST_INTERACTIVE=1 greatly increases the
probability of getting a hang. I attached a patch that does that and can be
used to reproduce the hang on the TestBot's w1064v1709 VM.
So this is clearly related to focus.
--
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=39659
Bug ID: 39659
Summary: comctl32:button test gets unexpected WM_CANCELMODE on
my Windows 8 laptop
Product: Wine
Version: 1.8-rc1
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: comctl32
Assignee: wine-bugs(a)winehq.org
Reporter: madewokherd(a)gmail.com
Created attachment 52866
--> https://bugs.winehq.org/attachment.cgi?id=52866
log of test failure
Test report:
https://test.winehq.org/data/1d19eb15d4abfdd14dccc5ac05b83c0ee1a1ace1/win8_…
Message tests calling SetFocus() on a button fail on my Windows 8 machine,
because they get a WM_CANCELMODE message they weren't expecting. I have no idea
what's special about my setup. It doesn't matter if I run the test stand-alone
or with the full test suite, or if I run it as a dedicated user with a default
configuration.
--
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=30875
Bug #: 30875
Summary: Unable to deselect character blocks in BMFont
Product: Wine
Version: 1.5.6
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dav75uk(a)yahoo.co.uk
Classification: Unclassified
Run BMFont (http://www.angelcode.com/products/bmfont/) and click on some of the
checkboxes to the right to select characters to be included. It is not possible
to uncheck the checkboxes.
Workaround is to unselect one of the characters (click on a character in that
range) which changes the full checked box to a part check box. The part check
box can be unselected.
--
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=45432
Bug ID: 45432
Summary: Implement Windows Native Firewall Rules for Lightwave
Software Licensing - netfw_rules
Product: Wine
Version: 3.11
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: newel.anderson(a)gmail.com
Distribution: ---
Created attachment 61753
--> https://bugs.winehq.org/attachment.cgi?id=61753
Terminal logs installing and launching Lightwave under WIne 3.11 in Linux
Lightwave requires Windows Native Firewall Inbound/Outbound Rules in order to
register/activate one's license.
For reference, please see:
https://forum.winehq.org/viewtopic.php?f=8&t=30847&p=116945#p116945 (I'm
wineink)
Towards the end of the above thread I posted terminal output as well as
screenshots. Disabling Windows Firewall, as well as deleting the
inbound/outbound rules in Windows, deactivates my license. Re-enabling the
rules and Windows Firewall reactivates my license. Since this functionality
doesn't exist in Wine, Wine hasn't to my knowledge implemented Windows Native
Firewall Rules, it's impossible to register/activate my legally purchased
license in Wine.
Thank you for your time and consideration.
***Please note, the above applies only to a FULL license of Lightwave. The
trial, which is node-locked, works as designed. Unfortunately, the FULL license
is not node-locked.
--
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=33621
Bug #: 33621
Summary: [UWIN] ksh93 from UWIN generates a lot of fixme
warnings
Product: Wine
Version: 1.5.30
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: simon.toedt(a)gmail.com
Classification: Unclassified
Running ksh93 (Korn Shell 93) from the UWIN (Unix emulation on Windows) toolkit
generates a lot of "fixme" warnings and the shell is generally not useable.
The goal is to use WINE for automated testing without having to fire up a full
blown Windows system each time in VMware or real iron.
Steps to test:
1. Install UWIN:
> wget --http-user="I accept www.opensource.org/licenses/eclipse"
--http-passwd="."
'http://www2.research.att.com/~gsf/download/beta/uwin-base.2013-02-08.win32.…'
> wine uwin-base.2013-02-08.win32.i386.exe
2. Run Windows/UWIN version of ksh93:
wine64 'C:\Program Files/UWIN/usr/bin/ksh.exe'
fixme:process:SetProcessShutdownParameters (00000300, 00000001): partial stub.
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:ntdll:NtSetInformationToken unimplemented class 4
fixme:process:SetProcessShutdownParameters (00000300, 00000001): partial stub.
fixme:ntdll:NtSetInformationToken unimplemented class 4
fixme:ntdll:NtSetInformationToken unimplemented class 4
fixme:process:SetProcessShutdownParameters (00000000, 00000001): partial stub.
fixme:ntdll:NtSetInformationToken unimplemented class 4
fixme:ntdll:NtSetInformationToken unimplemented class 4
fixme:advapi:LsaOpenPolicy ((null),0x23f980,0x00000001,0x23f950) stub
fixme:advapi:LsaClose (0xcafe) stub
fixme:netbios:NetServerEnum Stub ((null) 100 0x23f440 -1 0x23fbb8 0x23fbc8 24
(null) (nil))
fixme:netapi32:NetGetDCName ((null), (null), 0x23f448) stub!
fixme:dbghelp_dwarf:dwarf2_parse_subprogram Unhandled Tag type 0x26 at
ctx(0x8834c0,L"libc.so.6"), for debug_info(abbrev:0xf70850,symt:0xfce150)
fixme:dbghelp_dwarf:compute_location Only supporting one breg (r10/338 ->
r8/336)
fixme:dbghelp_dwarf:compute_location Only supporting one breg (r10/338 ->
r8/336)
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:dbghelp_dwarf:dwarf2_parse_subprogram Unhandled Tag type 0x26 at
ctx(0x8834c0,L"libc.so.6"), for debug_info(abbrev:0x20e2370,symt:0x2140480)
fixme:dbghelp_dwarf:dwarf2_parse_subprogram_block Unhandled Tag type 0xf at
ctx(0x8834c0,L"libc.so.6"), for debug_info(abbrev:0x21926b8,symt:(nil))
fixme:dbghelp_dwarf:dwarf2_parse_subprogram_block Unhandled Tag type 0xf at
ctx(0x8834c0,L"libc.so.6"), for debug_info(abbrev:0x21926b8,symt:(nil))
fixme:dbghelp_dwarf:dwarf2_parse_subprogram_block Unhandled Tag type 0xf at
ctx(0x8834c0,L"libc.so.6"), for debug_info(abbrev:0x21926b8,symt:(nil))
fixme:dbghelp_dwarf:dwarf2_parse_subprogram_block Unhandled Tag type 0xf at
ctx(0x8834c0,L"libc.so.6"), for debug_info(abbrev:0x21926b8,symt:(nil))
fixme:dbghelp_dwarf:dwarf2_parse_subprogram Unhandled Tag type 0x26 at
ctx(0x8834c0,L"ld-linux-x86-64.so.2"), for
debug_info(abbrev:0x2914e98,symt:0x2970264)
fixme:dbghelp_dwarf:dwarf2_parse_subprogram_block Unhandled Tag type 0x26 at
ctx(0x8834c0,L"ld-linux-x86-64.so.2"), for
debug_info(abbrev:0x2943cb0,symt:(nil))
fixme:dbghelp_dwarf:dwarf2_parse_subprogram_block Unhandled Tag type 0x26 at
ctx(0x8834c0,L"ld-linux-x86-64.so.2"), for
debug_info(abbrev:0x2914e90,symt:(nil))
fixme:dbghelp_dwarf:compute_location Only supporting one breg (rdx/331 ->
rax/328)
fixme:dbghelp_dwarf:compute_location Only supporting one breg (rdx/331 ->
rax/328)
fixme:dbghelp_dwarf:compute_location Only supporting one breg (rdx/331 ->
rax/328)
fixme:dbghelp_dwarf:compute_location Only supporting one breg (rdx/331 ->
rax/328)
fixme:dbghelp_dwarf:compute_location Only supporting one breg (rdx/331 ->
rax/328)
fixme:dbghelp_dwarf:dwarf2_parse_subprogram Unhandled Tag type 0x26 at
ctx(0x8834c0,L"libgcc_s.so.1"), for debug_info(abbrev:0x36b3448,symt:0x378fa1c)
fixme:dbghelp_dwarf:dwarf2_parse_subprogram Unhandled Tag type 0x26 at
ctx(0x8834c0,L"libgcc_s.so.1"), for debug_info(abbrev:0x3743718,symt:0x37781b4)
fixme:dbghelp_dwarf:dwarf2_parse_subprogram_block Unhandled Tag type 0x26 at
ctx(0x8834c0,L"libgcc_s.so.1"), for debug_info(abbrev:0x3743658,symt:(nil))
fixme:dbghelp_dwarf:dwarf2_parse_subprogram Unhandled Tag type 0x26 at
ctx(0x8834c0,L"libgcc_s.so.1"), for debug_info(abbrev:0x37425a0,symt:0x3754e38)
fixme:dbghelp_dwarf:dwarf2_parse_subprogram_block Unhandled Tag type 0x15 at
ctx(0x8834c0,L"kernel32<elf>"), for debug_info(abbrev:0x3824860,symt:(nil))
fixme:dbghelp_dwarf:dwarf2_parse_subprogram_block Unhandled Tag type 0xf at
ctx(0x8834c0,L"kernel32<elf>"), for debug_info(abbrev:0x3824860,symt:(nil))
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
wine version is wine-1.5.30. Wine versions older than wine-1.5.30 may not work
as described in bug 33619.
IMO the most pressing problems are:
1. fixme:process:SetProcessShutdownParameters (00000300, 00000001): partial
stub.
2. fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
3. fixme:netapi32:NetUserGetInfo Level 3 is not implemented
4. fixme:ntdll:NtSetInformationToken unimplemented class 4
5. fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented
--
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=45098
Bug ID: 45098
Summary: FrostPunk: multiple graphical glitches
Product: Wine
Version: 3.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: winehq(a)embed.me.uk
Distribution: ---
Created attachment 61268
--> https://bugs.winehq.org/attachment.cgi?id=61268
FrostPunk log
With patch posted in https://bugs.winehq.org/show_bug.cgi?id=45080 the game
sucessfully starts however there are severe graphical glitches which render it
unplayable. Log 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=50458
Bug ID: 50458
Summary: Tooltips block input in Foobar2000
Product: Wine
Version: 5.22
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: debilerpc(a)web.de
Distribution: ---
**Context:**
Like with most media players, Foobar2000's playlist view is essentially a
spreadsheet where each line is a track and each column displays a tag or
metadata field.
If the length of the tag exceeds the width of the column, it gets cut off. You
can see the full tag in a tooltip by hovering over it with a mouse in that
case.
**The problem:**
As long as the tooltip is displayed, the app registers neither keyboard nor
mouse input.
I suspect this problem exists in a variety of
[apps](https://bugs.winehq.org/show_bug.cgi?id=16227), not just Foobar2000, but
here it is especially annoying.
**Expected behavior:**
When input is sent, the tooltip should disappear, and Foobar2000 should react
to the input. This is what happens under Windows 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.
https://bugs.winehq.org/show_bug.cgi?id=45388
Bug ID: 45388
Summary: user32:edit fails on Traditional Chinese and Korean
locales
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
user32:edit fails with the following errors on Traditional Chinese and Korean
locales:
edit.c:1489: Test failed: 0: got 1, 1
edit.c:1510: Test failed: 0: got 1, 1
edit.c:1524: Test failed: 0: got 1, 1
edit.c:1538: Test failed: 0: got 1, 1
See:
* Source matching the above
https://source.winehq.org/git/wine.git/?a=blob;f=dlls/user32/tests/edit.c;h…
* user32:edit WineTest failures
https://test.winehq.org/data/tests/user32:edit.html
The errors can be reproduced on the newtb-wvistau64-zh-cn TestBot VM, and also
happen on fg-win7u64-1spie9-ko.
--
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=48045
Bug ID: 48045
Summary: comdlg32:filedlg crashes or times out randomly
Product: Wine
Version: unspecified
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: comdlg32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Created attachment 65586
--> https://bugs.winehq.org/attachment.cgi?id=65586
comdlg32:filedlg: Traces to debug random crash / timeouts.
comdlg32:filedlg crashes randomly on all Windows versions from Vista to Windows
8 while Windows 10 (at least 1507, 1709 and 1809) gets random timeouts.
https://test.winehq.org/data/tests/comdlg32:filedlg.html
When successful comdlg32:filedlg does not print much so the standard reports
are pretty much useless to spot the place where the test gets stuck on Windows
10, assuming it gets stuck in a specific place rather than just being slow.
As for the crashes, they don't trigger the tests exc_filter() so there is no
indication of the last successful ok() call. Turning on 'Report successful
tests' may be preventing the crash (or these runs just got lucky).
It's possible to reproduce the crash while adding the traces in the attached
patch. This is not entirely fruitful as the crashes don't seem to always happen
in the same place. test_extension() is the place where most issues happen
though:
https://testbot.winehq.org/JobDetails.pl?Key=59060
-> wvistau64: Crash in test_extension(). Based on the test_extension_helper()
traces, it happened in the loop with i=1 so for "TestFilter
(*.abc;)\0*.abc;\0".
https://testbot.winehq.org/JobDetails.pl?Key=59086
-> w2008s64+exe: Crash on or after test_extension() return
https://testbot.winehq.org/JobDetails.pl?Key=59088
-> wvistau64+exe: Crash in test_DialogCancel()
https://testbot.winehq.org/JobDetails.pl?Key=59091
-> wvistau64_fr: Spent 39s in test_null_filename() but no timeout
https://testbot.winehq.org/JobDetails.pl?Key=59139
-> wvistau64: Crash in test_null_filename()
-> wvistau64_fr: Timeout in test_extension()
filedlg.c:1048: filter=[TestFilter (*.ab?) lpstrDefExt=NULL]
https://testbot.winehq.org/JobDetails.pl?Key=59151
-> wvistau64: Crash in test_extension()
filedlg.c:1048: filter=[TestFilter (*.abc.def)]
-> wvistau64_fr: Timeout in or after test_mru()
filedlg.c:637: 19 test_ok
filedlg.c:904: 29 test_getfolderpath
filedlg.c:986: 30 test_mru
-> w1064v1809_zh_CN: Two failures in test_extension()
filedlg.c:1053: Test failed: TestFilter (*.pt*;*.abc): expected TRUE
filedlg.c:1059: Test failed: TestFilter (*.pt*;*.abc): Filename is deadbeef,
expected deadbeef.xyz
Memory corruption, maybe happening quite early in the test?
--
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=51181
Bug ID: 51181
Summary: d3d10core:d3d10core fails systematically on AMD GPUs
Product: Wine
Version: 6.8
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
test_instanced_draw() fails systematically in d3d10core:d3d10core on AMD GPUs
(and sometimes there is a crash that follows):
d3d10core.c:9275: Test failed: Got 0xfff0f010, expected 0xff80f010 at (160, 0),
sub-resource 0.
d3d10core.c:9275: Test failed: Got 0xfff0f040, expected 0xff80f040 at (240, 0),
sub-resource 0.
d3d10core.c:9275: Test failed: Got 0xffaaaacc, expected 0xffbbaacc at (480, 0),
sub-resource 0.
d3d10core.c:9275: Test failed: Got 0xffaaaa90, expected 0xffbbaa90 at (560, 0),
sub-resource 0.
Notice how this failure does not happen on the machines that have other GPUs
such as cw-gtx560 or QEmu VMs, and how this does not depend on the Windows
version or Radeon driver version for that matter:
https://test.winehq.org/data/patterns.html#d3d10core:d3d10core
So it looks like the test expects fails to account for the Radeon driver
results for some reason.
The commit that introduced this test is:
commit fcd549345d96109179b125d31baf9e9073ecf643
Author: Józef Kucia <jkucia(a)codeweavers.com>
AuthorDate: Mon Nov 6 10:55:20 2017 +0100
Commit: Alexandre Julliard <julliard(a)winehq.org>
CommitDate: Mon Nov 6 19:37:09 2017 +0100
d3d10core/tests: Add test for SV_InstanceID.
Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>
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=43995
Bug ID: 43995
Summary: Uplay - Assassin's Creed 4 Black Flag won't start
Product: Wine-staging
Version: 2.20
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mi.bar.2001(a)gmail.com
CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de,
sebastian(a)fds-team.de
Distribution: ---
Created attachment 59652
--> https://bugs.winehq.org/attachment.cgi?id=59652
Terminal log from `wine AC4BFSP.exe`
After clicking the "Play" button in Ubisoft Game Launcher (or launching `wine
AC4BFSP.exe`), a window pops up informing, that the game is starting, but it
disappears and the game doesn't launch. I don't have the Steam version, just
the Uplay one.
I've set Windows version to XP, wineprefix is 32-bit.
Wine version will probably be visible when I post this, but I'm going to
mention it just to be safe. Using Wine 2.20 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.
https://bugs.winehq.org/show_bug.cgi?id=52079
Bug ID: 52079
Summary: oleacc:main crashes randomly on Windows 10 1709+
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: oleacc
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
oleacc:main crashes randomly on Windows 10 1709+ in both 32- and 64-bit:
main.c:1041: Test failed: V_VT(&v) = 0
main.c:1048: Test failed: V_VT(&v) = 0
main.c:1049: Test failed: V_DISPATCH(&v) = 0000000000000000
main.c:1049: this is the last test seen before the exception
1050:main: unhandled exception c0000005 at 0000000000401597
oleacc:main:1050 done (-1073741819) in 0s
Test failed: crash (c0000005)
https://test.winehq.org/data/patterns.html#oleacc:main
Unsurprisingly a bisect shows that the tests started failing with the commit
that introduced the test:
commit 1a3db363c6b4065af532a8db1e6309be753b1781
Author: Connor McAdams <cmcadams(a)codeweavers.com>
Date: Mon Sep 20 18:03:31 2021 +0200
oleacc: Add Client_get_accFocus tests.
Signed-off-by: Connor McAdams <cmcadams(a)codeweavers.com>
Signed-off-by: Piotr Caban <piotr(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
At the time the crash happened after line 1037 which points to line 1039 as a
likely culprit:
1032 /* Set focus to each child window. */
1033 SetFocus(btn);
1034 hr = IAccessible_get_accFocus(acc, &v);
1035 ok(hr == S_OK, "hr %#x\n", hr);
1036 ok(V_VT(&v) == VT_DISPATCH, "V_VT(&v) = %d\n", V_VT(&v));
1037 ok(V_DISPATCH(&v) != NULL, "V_DISPATCH(&v) = %p\n", V_DISPATCH(&v));
1038
1039 hr = IDispatch_QueryInterface(V_DISPATCH(&v), &IID_IOleWindow,
(void**)&ow);
1040 ok(hr == S_OK, "got %x\n", hr);
That call has been moved to _check_acc_hwnd() and so the crash now happens in
the first QueryInterface() call in that function:
hr = IUnknown_QueryInterface(unk, &IID_IOleWindow, (void**)&ow);
called from
check_acc_hwnd((IUnknown*)V_DISPATCH(&v), btn);
--
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=51407
Bug ID: 51407
Summary: kernel32:time's test_GetCalendarInfo() fails in Hindi
Product: Wine
Version: 6.10
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Created attachment 70263
--> https://bugs.winehq.org/attachment.cgi?id=70263
Broken fix and traces
Three GetCalendarInfo() checks fail in Hindi:
https://test.winehq.org/data/patterns.html#kernel32:time
time.c:728: Test failed: GetCalendarInfoA failed err 87
time.c:731: Test failed: GetCalendarInfoA failed err 87
time.c:738: Test failed: got 0, expected 7
The immediate cause for the failure is that Hindi is one of the few languages
for which NLS_IsUnicodeOnlyLcid() returns true. In turn this causes the ANSI
GetCalendarInfoA() to return ERROR_INVALID_PARAMETER. The last failure just
reflects the fact that the two calls to GetCalendarInfoA() should not have
failed.
Only Hindi fails and only in Wine. But before declaring this a Wine bug we need
to look at Windows.
* For some reason probably related to SetWinLocale [1] the system locale of
w10pro64_hi is still English.
* This causes both the ANSI and Unicode GetCalendarInfo() to return English
names (Monday).
* Manually setting the system locale to Hindi is possible on Windows 10 2004.
What's interesting is the disabled and checked-by-default checkbox in that
dialog:
[X] Beta: Use Unicode UTF-8 for worldwide language support
* And indeed doing that and running the test again results in
GetCalendarInfoA() returning UTF-8 strings on Windows!
time.c:730: ret=19
sdayname1="\xe0\xa4\xb8\xe0\xa5\x8b\xe0\xa4\xae\xe0\xa4\xb5\xe0\xa4\xbe\xe0\xa4\xb0"
सोमवार
time.c:735: ret2=19
sdayname1="\xe0\xa4\xb8\xe0\xa5\x8b\xe0\xa4\xae\xe0\xa4\xb5\xe0\xa4\xbe\xe0\xa4\xb0"
सोमवार
time.c:742: ret2=19 sdayname1=L"\0938\094b\092e\0935\093e\0930"
* The beta moniker strongly suggests that this is a new option. Indeed
selecting Hindi as the system locale was not possible in Windows 8.1 for
instance.
* This is probably also why SetWinLocale has trouble setting the system locale
to Hindi.
So the Windows behavior can be summarized as such:
* Return localized values for non-Unicode-only locales.
* In older Windows versions setting the system locale to a Unicode-only locale
is impossible.
* In newer Windows versions setting the system locale to a Unicode-only locale
is possible and then it uses UTF-8.
Commenting out the Hindi line in NLS_IsUnicodeOnlyLcid() fixes the failures in
Wine (see attached patch). But this fix is wrong because it causes
GetCalendarInfoA() to return question marks instead of intelligible strings.
(it also impacts many APIs but that's probably ok based on the Windows
behavior)
So Wine should do one of the following:
1. Stick to a 'safe' system locale when $LANG is set to a Unicode-only locale.
Typically this would be English.
2. Or use UTF-8 when the system locale is a Unicode-only locale.
Option 2 would actually make a lot of sense on Unix systems but it is also more
likely to break Windows applications. So option 1 may be the safer (and
simpler?) option (for now).
[1]
https://source.winehq.org/git/tools.git/blob/HEAD:/testbot/bin/SetWinLocale…
--
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=43208
Bug ID: 43208
Summary: Assassin's Creed IV - Black Flag Hangs tightly
Product: Wine-staging
Version: 2.10
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: tall89(a)mail.ru
CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de,
sebastian(a)fds-team.de
Distribution: ---
When you switch to the Big Inagua location, the game hangs tight, you have to
do Cntrl + Atl + Delete to remove the task, then the game closes, then you
receive an error message, the program ACBF.exe has a serious error, the
application will be closed, we apologize for the inconvenience
WINEDEBUG=fixme-all,err+loaddll,err+dll,err+file,err+reg
------ Program AC4BFSP.exe ------
err:winsock:WSAIoctl -> SIO_ADDRESS_LIST_CHANGE request failed with status
0x2733
err:winedevice:async_create_driver failed to create driver L"ps6ajtsb":
c0000135
err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: Received from
192.168.0.102:5353 16 aspire89-P55A-UD4.local. AAAA
FE80:0000:0000:0000:0A12:F0CA:1A84:437A"
err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: ProbeCount 2; will
deregister 4 aspire89-P55A-UD4.local. Addr 192.168.0.102"
err:eventlog:ReportEventW L"Local Hostname aspire89-P55A-UD4.local already in
use; will try aspire89-P55A-UD4-2.local instead"
err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: Received from
192.168.0.102:5353 25 102.0.168.192.in-addr.arpa. PTR
aspire89-P55A-UD4.local."
err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: Unexpected conflict
discarding 27 102.0.168.192.in-addr.arpa. PTR aspire89-P55A-UD4-2.local."
err:ole:CoInitializeEx Attempt to change threading model of this apartment from
multi-threaded to apartment threaded
err:d3d:wined3d_debug_callback 0x721acb8: "GL_INVALID_OPERATION error
generated. <program> has not been linked, or is not a program object.".
err:d3d:wined3d_debug_callback 0x721acb8: "GL_INVALID_OPERATION error
generated. <program> object is not successfully linked, or is not a program
object.".
err:d3d:wined3d_debug_callback 0x721acb8: "GL_INVALID_OPERATION error
generated. <program> has not been linked, or is not a program object.".
err:d3d:wined3d_debug_callback 0x721acb8: "GL_INVALID_OPERATION error
generated. <program> object is not successfully linked, or is not a program
object.".
err:d3d:wined3d_debug_callback 0x721acb8: "GL_INVALID_OPERATION error
generated. <program> has not been linked, or is not a program object.".
err:d3d:wined3d_debug_callback 0x721acb8: "GL_INVALID_OPERATION error
generated. <program> object is not successfully linked, or is not a program
object.".
wine: Unhandled page fault on read access to 0x00000063 at address 0x8cfb7f
(thread 0047), starting debugger...
wine: Unhandled page fault at address 0x7bc5d590 (thread 0012), starting
debugger...
err:seh:start_debugger Couldn't start debugger ("winedbg --auto 14 168") (1115)
Read the Wine Developers Guide on how to set up winedbg or another debugger
--
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=51460
Bug ID: 51460
Summary: oleaut32:vartest has a todo because Wine uses an
outdated currency symbol for Swiss Francs
Product: Wine
Version: 6.10
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: oleaut32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Wine uses uses "SFr." as the currency symbol for Swiss francs instead of "CHF".
According to Wikipedia: "The use of SFr. for Swiss Franc and fr.sv. are
outdated" and are not recognized as correct by the "Secrétariat d'État à
l'économie".
https://en.wikipedia.org/wiki/Swiss_franc
This forces the use of a todo in oleaut32:vartest:
lcid = MAKELCID(MAKELANGID(LANG_FRENCH,SUBLANG_FRENCH_SWISS),SORT_DEFAULT);
WCONVERT(L"3CHF", NUMPRS_CURRENCY|NUMPRS_USE_ALL);
todo_wine EXPECT(1,NUMPRS_CURRENCY|NUMPRS_USE_ALL,NUMPRS_CURRENCY,4,0,0);
And it may cause oleaut32:varformat to fail when run in a Swiss locale.
The "SFr." currency symbol comes from nls/(de|fr|it)s.nls which are generated
from Unicode tables by tools/make_unicode so it's not clear how to fix them.
--
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=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=46694
Bug ID: 46694
Summary: widl crashes in dlls/atl during build on ppc64el
Product: Wine
Version: 4.2
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: tpearson(a)raptorengineering.com
Distribution: ---
Created attachment 63657
--> https://bugs.winehq.org/attachment.cgi?id=63657
Backtrace
Building on ppc64el fails with a segmentation fault in widl while attempting to
build dlls/atl. Backtrace 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=45385
Bug ID: 45385
Summary: Wrong state of virtual keys after cycling windows.
Usually VK_MENU, VK_SHIFT and VK_CONTROL, but every
key can be affected.
Product: Wine
Version: 3.9
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wineserver
Assignee: wine-bugs(a)winehq.org
Reporter: johnfound(a)asm32.info
Distribution: ---
I noticed that the state of the keys sometimes sticks in pressed state.
This happens when cycling windows with some shortcut key combination.
For example if cycling with Alt+Tab, on pressing Alt, the program gets
WM_KEYDOWN and the state of the VK_MENU becomes pressed. But after cycling
windows, the program does not get WM_KEYUP because the window is not focused
and VK_MENU (and the respective VK_LMENU or VK_RMENU) remain in pressed state.
When cycling back to the program window, the window get focused only after
releasing Alt key, so it does not get this event as well.
If cycling windows with another shortcut key combination (for example
Alt+Shift+Tab - for backward cycling) both VK_MENU and VK_SHIFT keys stick.
In the same time, GetAsyncKeyState returns the proper state of the keys.
Note1: The problem is obviously in the wineserver code, because it handles the
key state tables for the different threads.
Note2: The effect happens only sometimes. It seems the code for proper
processing is already there, but some racing conditions have place.
Note3: There is some probability that the effect is in result of my application
code, but it never happens on real Windows, so I considered it a bug.
Note4: I tried to workaround this problem by reading the whole table by
GetAsyncKeyState and setting it then with SetKeyboardState on WM_ACTIVATE
message of the main window. This workaround actually works, but is too ugly
IMO.
The same trick on WM_ACTIVATEAPP does not work.
--
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=33058
Bug #: 33058
Summary: Visual Basic 6 crashes when object browser is clicked
Product: Wine
Version: 1.5.24
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: german_ant_82(a)yahoo.com
Classification: Unclassified
Regression SHA1: Visual Basic 6 crashes when object browser button is
clicked
Created attachment 43703
--> http://bugs.winehq.org/attachment.cgi?id=43703
Backtrace
Visual Basic 6 IDE crashes when object browser is clicked
--
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.