https://bugs.winehq.org/show_bug.cgi?id=50130
Bug ID: 50130
Summary: Outrun 2006 cannot choose anti aliasing levels more
than 2
Product: Wine
Version: 5.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jogamer1(a)protonmail.com
Distribution: ---
Created attachment 68622
--> https://bugs.winehq.org/attachment.cgi?id=68622
output log of config.exe
Install Outrun 2006 and run the Config.exe, under Video settings you can choose
anti aliasing settings up to 6 but in Wine only up to 2 is shown. If the anti
aliasing level is changed in outrun2006.ini the value will be blank in the anti
aliasing drop-down menu. Happens both on development and staging 5.21 and back
to Wine 5.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=45601
Bug ID: 45601
Summary: Wargaming Game Center doesn't start after installation
Product: Wine
Version: 3.13
Hardware: x86
URL: http://redirect.wargaming.net/WGC/Wargaming_Game_Cente
r_Install_TWA_EU.exe
OS: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Created attachment 62032
--> https://bugs.winehq.org/attachment.cgi?id=62032
wine log
When the program installed, it should start the program - but it does not.
"winetricks -q ie8" works around the issue.
--
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=54749
Bug ID: 54749
Summary: ddraw:dsurface sometimes times out on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
ddraw:dsurface sometimes times out on Windows:
ddraw:dsurface start dlls/ddraw/tests/dsurface.c
ddraw:dsurface:1260 done (258) in 120s 0B
See https://test.winehq.org/data/patterns.html#ddraw:dsurface
There are 5 known instances in the past 8 months:
* 2022-09-01 on w1064-tsign-64
* 2022-12-09 on fgtb-w10pro64-rx550-64
* 2022-12-09 on w1064v21h2-64
* 2023-03-27 on w10pro64-ar-64
* 2023-03-27 on w10pro64-mx-MX-64
Again the dates look similar to the other ddrawmodes and dsurface issues (bug
54746 and bug 54747) but not identical. So while there is probably some common
factor making these failures more likely, it's not a simple trigger.
--
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=54747
Bug ID: 54747
Summary: ddraw:dsurface sometimes gets E_OUTOFMEMORY on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
ddraw:dsurface sometimes gets E_OUTOFMEMORY on Windows. However this does not
always happen in the same place:
* 2022-08-31 in test_ddsd() on w1064-tsign-64:
dsurface.c:2232: Test failed: Got hr 0x8007000e.
* 2022-10-14 in BackBufferAttachmentFlipTest() on w1064-tsign-32:
dsurface.c:1710: Test failed: Got hr 0x8007000e.
dsurface.c:1758: Test failed: Attaching a back buffer to another back buffer
returned 0x80070057
dsurface.c:1776: this is the last test seen before the exception
14a8:dsurface: unhandled exception c0000005 at 00553E4A
* 2022-12-09 in PaletteTest(), BackBufferAttachmentFlipTest() and test_ddsd()
on w1064-tsign-64:
dsurface.c:1372: Test failed: Got hr 0x8007000e.
dsurface.c:1375: Tests skipped: failed to create surface
dsurface.c:1691: Test failed: Got hr 0x8007000e.
dsurface.c:2232: Test failed: Got hr 0x8007000e.
* 2023-01-24 in BackBufferAttachmentFlipTest() and zbufferbitdepth_test() on
w10pro64-fr-64:
dsurface.c:1691: Test failed: Got hr 0x8007000e.
dsurface.c:2130: Test failed: Got hr 0x8007000e.
dsurface.c:2130: this is the last test seen before the exception
1f40:dsurface: unhandled exception c0000005 at 0000000000522CD1
* 2023-03-27 in test_ddsd() on w10pro64-ru-64
dsurface.c:2232: Test failed: Got hr 0x8007000e.
See https://test.winehq.org/data/patterns.html#ddraw:dsurface
Where 0x8007000e == E_OUTOFMEMORY
Notes:
* There are really 5 places where this happens.
* It always happens after a IDirectDraw_CreateSurface() call, except for the
test_ddsd() (line 2232) cases where it follows a IDirectDrawSurface7_Lock()
call.
* The failure dates look somewhat similar to the ddraw:ddrawmodes E_OUTOFMEMORY
failures but not exactly and the VMs mostly don't match. So the ddrawmodes
failures are not the cause of the dsurface ones. But there may be some common
factor making these failures more likely.
--
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=54746
Bug ID: 54746
Summary: ddraw:ddrawmodes - testcooperativelevels_normal()
sometimes gets E_OUTOFMEMORY on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
ddraw:ddrawmodes - testcooperativelevels_normal() sometimes gets E_OUTOFMEMORY
on Windows:
ddrawmodes.c:723: Test failed: Got hr 0x8007000e.
ddrawmodes.c:724: Test failed: Returned NULL surface pointer
See https://test.winehq.org/data/patterns.html#ddraw:ddrawmodes
Where 0x8007000e == E_OUTOFMEMORY
This failure always happens in this call:
716 /* Try creating a double buffered primary in fullscreen + exclusive +
normal mode */
717 rc = IDirectDraw_CreateSurface(lpDD, &surfacedesc, &surface, NULL);
...
723 ok(rc == DD_OK, "Got hr %#lx.\n", rc);
There is one instance on 2022-09-01 but this started happening about twice per
month on 2022-12-09.
--
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=54745
Bug ID: 54745
Summary: ddraw:ddrawmodes - testddraw7() sometimes gets a
0x887600ff error on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
ddraw:ddrawmodes - testddraw7() sometimes gets a 0x887600ff error on Windows:
ddrawmodes.c:978: Test failed: Got hr 0x887600ff.
ddrawmodes.c:997: Test failed: Got hr 0x887600ff.
See https://test.winehq.org/data/patterns.html#ddraw:ddrawmodes
Where 0x887600ff corresponds to MAKE_D3DHRESULT(255) but is an unknown error
code.
This happened regularly on w11pro64-amd when Windows update was not disabled.
Excluding those there are three known instances all hapening on Windows 10 so
this is quite rare:
* 2022-08-10 on w1064-tsign-32
* 2023-01-24 on w10pro64-pt-BR-64
* 2023-03-27 on w10pro64-ar-64
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54743
Bug ID: 54743
Summary: urlmon:url - The ftp test sometimes gets
INET_E_OBJECT_NOT_FOUND on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: urlmon
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
urlmon:url - The ftp test sometimes gets INET_E_OBJECT_NOT_FOUND on Windows:
url.c:1846: Test failed: binding failed: 800c0006, expected 00000000
url.c:1857: Test failed: res = 00002f4f, expected 00000000
url.c:3284: Test failed: expected OnProgress_SENDINGREQUEST
url.c:3292: Test failed: expected OnProgress_MIMETYPEAVAILABLE
url.c:3293: Test failed: expected OnProgress_BEGINDOWNLOADDATA
url.c:3294: Test failed: expected OnProgress_ENDDOWNLOADDATA
url.c:3306: Test failed: expected OnDataAvailable
See https://test.winehq.org/data/patterns.html#urlmon:url
Where 0x800c0006 == INET_E_OBJECT_NOT_FOUND
This happens on Windows 8 to 11 about twice a month on average over all the
VMs.
--
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=54741
Bug ID: 54741
Summary: integer overflow in get_dib_stride / NtGdiCreateBitmap
Product: Wine
Version: 8.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdi32
Assignee: wine-bugs(a)winehq.org
Reporter: felix-wine(a)fefe.de
Distribution: ---
Here's the source code of NtGdiCreateBitmap:
97 HBITMAP WINAPI NtGdiCreateBitmap( INT width, INT height, UINT planes,
98 UINT bpp, const void *bits )
99 {
Having INT for width and height is already bad, but can't be helped because you
are implementing a crappy API.
105 if (width > 0x7ffffff || height > 0x7ffffff)
106 {
107 RtlSetLastWin32Error( ERROR_INVALID_PARAMETER );
108 return 0;
109 }
110
111 if (!width || !height)
112 return 0;
113
114 if (height < 0)
115 height = -height;
116 if (width < 0)
117 width = -width;
After this the value of width and height is 1..0x7ffffff (7 digits, not 8).
bpp is validated to be at most 32.
140 dib_stride = get_dib_stride( width, bpp );
141 size = dib_stride * height;
142 /* Check for overflow (dib_stride itself must be ok because of the
constraint on bm.bmWidth above). */
143 if (dib_stride != size / height)
Here's the code of get_dib_stride:
282 static inline int get_dib_stride( int width, int bpp )
283 {
284 return ((width * bpp + 31) >> 3) & ~3;
285 }
width can be 0x7ffffff, bpp can be 32.
width*bpp is then 0xffffffe0 which looks at first glance like no overflow
happened, but the type is still int, i.e. signed 32-bit, i.e. max value is
0x7fffffff (8 digits), max bpp to trigger that would be 16 not 32.
We are right-shifting afterwards, so we ought to be fine? Nope, because we are
operating on signed ints, so it's an arithmetic right shift, not a logical one.
The & does not remove the sign bit. So what happens here is that get_dib_stride
can return a negative value.
OK but NtGdiCreateBitmap checks for overflow and will notice something is
wrong.
Not really. If width=height=0x7ffffff and bpp=32 then get_dib_stride=-4.
Then size is -4*0x7ffffff promoted to size_t, or 0xe0000004.
The overflow check does this:
143 if (dib_stride != size / height)
size/0x7ffffff is 0xfffffffc.
dib_stride is -4, promoted to size_t for the comparison is also 0xfffffffc.
Also: On the way we had undefined behavior. The compiler would be allowed to do
all kinds of nasty things.
--
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=54732
Bug ID: 54732
Summary: schedsvc:atsvcapi & schedsvc:rpcapi crash on a fresh
wineprefix
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: taskschd
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
schedsvc:atsvcapi & schedsvc:rpcapi crash on a fresh wineprefix.
The issue is the same for both tests so I'll focus on the latter:
$ rm -rf ~/.wine && WINEDEBUG=schedsvc ./wine
dlls/schedsvc/tests/i386-windows/schedsvc_test.exe rpcapi
rpcapi.c:64: Tests skipped: Can't connect to Scheduler service: 0x6d9
0020:rpcapi: 0 tests executed (0 marked as todo, 0 as flaky, 0 failures), 1
skipped.
What really happens is that the call to SchRpcHighestVersion() crashes even
before reaching the TRACE() statement. And schedsvc:rpcapi interprets that as
being unable to connect to the scheduler service.
Running schedsvc:rpcapi multiple times does not help. However if one runs
taskschd:scheduler once in that wineprefix, then there is no problem:
$ rm -rf ~/.wine && ./wine dlls/taskschd/tests/i386-windows/taskschd_test.exe
scheduler
...
# Wait until sure that Wine has fully shut down
$ sleep 10; ./wine dlls/schedsvc/tests/i386-windows/schedsvc_test.exe rpcapi
rpcapi.c:268: L"<!-- Task definition created by Wine -->\n<Task
...
In particular this means that when submitting a TestBot job for these tests,
they systematically skip which prevents detecting failures.
(For merge requests there is one 32-bit only full WineTest run which would
catch at least some regressions.)
--
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=36711
Bug ID: 36711
Summary: Civ 4 Colonization cannot load Save games, Crashes
Product: Wine
Version: 1.6.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: typoofcem(a)gmail.com
Created attachment 48756
--> http://bugs.winehq.org/attachment.cgi?id=48756
Error output from when app crashes
Sid Meier's Civilization 4 Colonization (from the complete edition, not the
standalone) crashes when user attempts to load a saved game in Wine. Issue does
not effect Civ 4 nor its expansions, from the complete edition.
Note: game is being played from a complete install, without DVD-ROM (if that
makes any difference)
--
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.