wine-devel August 2010

wine-devel@winehq.org

110 participants
338 discussions

Re: gdi32: Properly set ERROR_NOACCESS when GetObject receives invalid arguments
by Octavian Voicu 19 Aug '10

19 Aug '10

On Thu, Aug 19, 2010 at 4:56 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > Broken programs will crash on wine if they, for example, pass > arguments to GetObject in the wrong order. > This fixes bug #18864. > + if (buffer && ((ULONG_PTR)buffer >> 16) == 0) Wouldn't a __TRY ... __EXCEPT_PAGE_FAULT be better / safer? Octavian

2 1

PDB files generated by Intel C++ Compiler
by Peter Urbanec 19 Aug '10

19 Aug '10

I have some x64 binaries and associated PDBs that have been generated using Intel C++ Compiler 11.1. These PDBs cause issues such as this: 1 0x00000000781cc1ba in msvcr80 (+0x9c1b9) (0x00007ff047a4c840) fixme:dbghelp_msc:codeview_fetch_type Cannot locate type 670 err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 2 0x000000006189a00d in lua5.1 (+0xa00c) (0x00007ff047a4c840) Now, from a quick look at mscvpdb.h, it looks like these PDBs contain datatypes with 64-bit near pointers, however wine does not seem to understand this mode. How would one go about adding support for this type of PDB? I actually don't have access to the Intel C++ Compiler to do much testing. :-(

2 1

winepath bug without arguments?
by Jerome Leclanche 19 Aug '10

19 Aug '10

Hi After fixing a bug in MPQEdit related to opening directories, I noticed winepath returns a different result with and without quotes: adys@azura:~/.wine/drive_c$ winepath -w adys@azura:~/.wine/drive_c$ winepath -w "" C:\ With quotes it returns the current directory. Is that intended? If not I'll open a bug... J. Leclanche

3 2

Re: [01/11] d3dx10: Add stub for d3dx10_43
by Henri Verbeet 19 Aug '10

19 Aug '10

On 18 August 2010 23:01, Owen Rudge <orudge(a)codeweavers.com> wrote: > +BOOL WINAPI D3DX10CheckVersion(UINT d3dsdkvers, UINT d3dxsdkvers) > +{ > + if ((d3dsdkvers == D3D10_SDK_VERSION) && (d3dxsdkvers == 43)) > + return TRUE; > + > + return FALSE; > +} Is it really safe to assume D3D10_SDK_VERSION will always keep the same value? (I know d3dx9 does it as well.) For d3d9 the SDK version changed between d3d9b and d3d9c, for example.

2 2

Re: [PATCH 3/5] ddraw/tests: New CreateSurface for 3D DDSCAPS_BACKBUFFER tests. (try 5, resend)
by Stefan Dösinger 19 Aug '10

19 Aug '10

Hi, Can you try to create a d3d device with this surface? In the first d3d version this works by querying the d3d device ID from the surface. Patch 4 looks OK. Thank you for your persistence with the patches by the way! Cheers, Stefan Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/d3d.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 82 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c > index 53ef04b..a83b0d5 100644 > --- a/dlls/ddraw/tests/d3d.c > +++ b/dlls/ddraw/tests/d3d.c > @@ -3536,6 +3536,87 @@ static void FindDevice(void) > "Expected IDirect3D1::FindDevice to return D3D_OK, got 0x%08x\n", hr); > } > > +static void BackBuffer3DCreateSurfaceTest(void) > +{ > + DDSURFACEDESC ddsd; > + DDSURFACEDESC created_ddsd; > + DDSURFACEDESC2 ddsd2; > + IDirectDrawSurface *surf; > + IDirectDrawSurface4 *surf4; > + IDirectDrawSurface7 *surf7; > + HRESULT hr; > + IDirectDraw2 *dd2; > + IDirectDraw4 *dd4; > + IDirectDraw7 *dd7; > + DDCAPS ddcaps; > + > + const DWORD caps = DDSCAPS_BACKBUFFER | DDSCAPS_3DDEVICE; > + const DWORD expected_caps = DDSCAPS_BACKBUFFER | DDSCAPS_3DDEVICE | DDSCAPS_VIDEOMEMORY | DDSCAPS_LOCALVIDMEM; > + > + memset(&ddcaps, 0, sizeof(ddcaps)); > + ddcaps.dwSize = sizeof(DDCAPS); > + hr = IDirectDraw_GetCaps(DirectDraw1, &ddcaps, NULL); > + if (!(ddcaps.ddsCaps.dwCaps & DDSCAPS_VIDEOMEMORY)) > + { > + skip("DDraw reported no VIDEOMEMORY cap. Broken video driver? Skipping surface caps tests.\n"); > + return ; > + } > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd.dwWidth = 64; > + ddsd.dwHeight = 64; > + ddsd.ddsCaps.dwCaps = caps; > + memset(&ddsd2, 0, sizeof(ddsd2)); > + ddsd2.dwSize = sizeof(ddsd2); > + ddsd2.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd2.dwWidth = 64; > + ddsd2.dwHeight = 64; > + ddsd2.ddsCaps.dwCaps = caps; > + memset(&created_ddsd, 0, sizeof(created_ddsd)); > + created_ddsd.dwSize = sizeof(DDSURFACEDESC); > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &surf, NULL); > + todo_wine ok(SUCCEEDED(hr), "IDirectDraw_CreateSurface failed: 0x%08x\n", hr); > + if (surf != NULL) > + { > + hr = IDirectDrawSurface_GetSurfaceDesc(surf, &created_ddsd); > + ok(SUCCEEDED(hr), "IDirectDraw_GetSurfaceDesc failed: 0x%08x\n", hr); > + todo_wine ok(created_ddsd.ddsCaps.dwCaps == expected_caps, > + "GetSurfaceDesc returned caps %x, expected %x\n", created_ddsd.ddsCaps.dwCaps, > + expected_caps); > + IDirectDrawSurface_Release(surf); > + } > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw2, (void **) &dd2); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd, &surf, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw2_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw2_Release(dd2); > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw4, (void **) &dd4); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2, &surf4, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw4_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw4_Release(dd4); > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw7, (void **) &dd7); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2, &surf7, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw7_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw7_Release(dd7); > +} > + > START_TEST(d3d) > { > init_function_pointers(); > @@ -3571,6 +3652,7 @@ START_TEST(d3d) > TextureLoadTest(); > ViewportTest(); > FindDevice(); > + BackBuffer3DCreateSurfaceTest(); > D3D1_releaseObjects(); > } > > -- > 1.7.2 > > >

1 0

Re: user32/dialog.c: GetNextDlgTabItem returns hwndDlg if it does not contain controls.
by Alexandre Julliard 19 Aug '10

19 Aug '10

"Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > @@ -1695,7 +1696,19 @@ HWND WINAPI GetNextDlgTabItem( HWND hwndDlg, HWND hwndCtrl, > */ > if (!hwndCtrl && fPrevious) return 0; > > - return DIALOG_GetNextTabItem(hwndDlg,hwndDlg,hwndCtrl,fPrevious); > + nextItem = DIALOG_GetNextTabItem(hwndDlg,hwndDlg,hwndCtrl,fPrevious); > + > + /* if next tab item not found return the first child even if it does not have TABSTOP > + Checked on XP > + */ > + if (!nextItem && !fPrevious) nextItem = GetWindow(hwndDlg,GW_CHILD); > + > + /* if there is no controls on hwndDlg return hwndDlg > + Checked on XP > + */ > + if (!nextItem && !fPrevious) nextItem = hwndDlg; > + > + return nextItem; You should test the fPrevious case too, it's probably similar. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oleau32: Use correct sysking in QueryPathOfRegTypeLib.
by Alexandre Julliard 19 Aug '10

19 Aug '10

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/oleaut32/typelib.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) It breaks the 64-bit tests: ../../../../wine/tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so ../../../../wine/dlls/oleaut32/tests/typelib.c && touch typelib.ok typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.0) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.1) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.22) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.37) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.40) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(65535.65535) returned 8002801d make: *** [typelib.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5, resend)
by Stefan Dösinger 19 Aug '10

19 Aug '10

Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > + if(DDSD->ddsCaps.dwCaps & DDSCAPS_FRONTBUFFER) { > + WARN("Application tried to create an explicit front buffer\n"); > LeaveCriticalSection(&ddraw_cs); > return DDERR_INVALIDCAPS; > } This test seems redundant now. The ddraw1 thunk removes the flag, and all other thunks check for the frontbuffer flag on their own.

1 0

have all MCI tests in winmm/tests/ or distributed across mci*/tests/?
by Joerg-Cyril.Hoehle＠t-systems.com 19 Aug '10

19 Aug '10

Hi, although my patch creates mcicda/tests/ I'd like to query whether it would make more sense to have all mci tests grouped in winmm/tests/. Pro: + Future fixes to winmm/mci.c would affect winmm/tests/*.c only. E.g. when I'll make "stop all" work I'd have to touch mcicda/tests/mcicda.c as well to eliminate the todo_wine there. Same when I'll patch mciparse to accept [TT:]MM:SS:FF format. + When Maarten will write mciqtz tests, perhaps resources could be reused to execute mciavi tests as well (the file creation code need not be duplicated). Similar tests could be written for: "open foo.avi" (mciavi) and "open foo.avi type mpegvideo" (mciqtz) or "open foo.wav" (micwave) and "open foo.wav type mpegvideo" although there's some difference in behaviour. + The functions test_notification could be in one file only, not repeated. I can rewrite my current mcicda/tests/mcicda.c patch to live in winmm/tests/. What do you think? Jörg Höhle

2 1

Re: [1/2] user32: add a way to poll for messages on extra handles
by Alexandre Julliard 19 Aug '10

19 Aug '10

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > diff --git a/dlls/user32/driver.c b/dlls/user32/driver.c > index f2f9892..05c83d4 100644 > --- a/dlls/user32/driver.c > +++ b/dlls/user32/driver.c > @@ -126,6 +126,7 @@ static const USER_DRIVER *load_driver(void) > GET_USER_FUNC(WindowMessage); > GET_USER_FUNC(WindowPosChanging); > GET_USER_FUNC(WindowPosChanged); > + GET_USER_FUNC(GetExtraMessageHandles); That's ugly, it doesn't correspond to anything in the Windows API. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] ntdll/tests: Add tests for RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 4]
by Alexandre Julliard 19 Aug '10

19 Aug '10

Detlef Riekenberg <wine.dev(a)web.de> writes: > + ok( (res == (void *)~0) || > + broken(res == (NULL + len)), /* XP and w2003 */ You can't do that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.
by Nikolay Sivov 19 Aug '10

19 Aug '10

On Thu, Aug 19, 2010 at 9:50 AM, Austin Lund <austin.lund(a)gmail.com> wrote: > http://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx Hi, Austin. This information is outdated probably. There's a message to set a calendar for MonthCal at least, see: http://msdn.microsoft.com/en-us/library/bb760995%28VS.85%29.aspx Not sure about DateTimePicker, it uses Monthcal internally so a calendar could still be switched. Anyway this won't work on pre-Vista and without a manifest for v6, but you could enable tests using V6 loading helpers that we have already and MCM_SETCALID message, so tests will run on Arabic or some Asian boxes.

2 1

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5, resend)
by testbot＠testbot.winehq.org 19 Aug '10

19 Aug '10

1 0

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5, resend)
by testbot＠testbot.winehq.org 19 Aug '10

19 Aug '10

1 0

Re: [PATCH 2/2] gameux/tests: verifying registry values created by GameExplorer (try 2)
by testbot＠testbot.winehq.org 19 Aug '10

19 Aug '10

1 0

Re: ntdll: IMAGE_REL_BASED_HIGH, IMAGE_REL_BASED_HIGH and IMAGE_REL_BASED_HIGHLOW are supported on win64.
by testbot＠testbot.winehq.org 19 Aug '10

19 Aug '10

1 0

Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file
by Vincent Povirk 18 Aug '10

18 Aug '10

> @@ -32,7 +33,6 @@ > > #include "wine/test.h" > > - > static void test_create(BOOL* gameExplorerAvailable, BOOL* gameExplorer2Available) > { > HRESULT hr; Don't put formatting changes in functional patches, please. I think it would be helpful if you passed a string description to your _validate functions so that in case of failure, you can tell where the original call to _validateGameRegistryKey was, instead of just the line containing the ok() call.

3 3

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

4 5

Re: [PATCH 5/6] gameux: Add initial implementation of IGameExplorer2::CheckAccess method
by Mariusz Pluciński 18 Aug '10

18 Aug '10

Hello W dniu 16.08.2010 10:00, Mariusz Pluciński pisze: > --- > dlls/gameux/gameexplorer.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > This is patch I sent to wine-patches yesterday. It was marked as "Pending". I know that what I sent is not proper solution. But as I wrote in FIXME, it's in my opinion impossible to implement it properly, cause from what I know Wine does not support parental control. So, instead of doing real check, my function simply always grants access. My question is: what should I do with it? It cannot be left stub, as there's already bug caused by this (bug #23850). And probably every game which uses Game Explorer will behave that same. Should I write test case to demonstrate that native works that same in most cases?

1 0

Re: [PATCH 1/1] d3dx9: Add tests for FVF <-> declaration conversion.
by Alexandre Julliard 18 Aug '10

18 Aug '10

Misha Koshelev <misha680(a)gmail.com> writes: > +#define VDECL_CHECK(fcall) \ > + if(fcall != S_OK) \ > + trace(" Test failed on line #%d\n", __LINE__); > + > +#define VDECL_CHECK_FAIL(fcall) \ > + if(fcall != E_FAIL) \ > + trace(" Test failed on line #%d\n", __LINE__); That's ugly. If the goal is to print the line number, you should pass it to the test function. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] ntdll: Implement RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 3]
by Alexandre Julliard 18 Aug '10

18 Aug '10

Detlef Riekenberg <wine.dev(a)web.de> writes: > + in = *pin; What is this for? -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine64 debugger
by Peter Urbanec 18 Aug '10

18 Aug '10

Hi, I'm trying to get a fairly complex Win64 application to work with wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. I thought that I would employ winedbg to help me, but I can't get very far. I don't have any luck with winedbg even on a simple x64 Win32 app. For my simplified test, I used MSVC2005 to generate an x64 executable created from the standard MSVC2005 template Win32 application. This is a simple app that just creates an empty window. As simple as one could get for a Win32 test and it executes correctly when run as "./wine Test1.exe". When I try to execute this test app under winedbg, I get an assert failure: ./wine winedbg Test1.exe WineDbg starting on pid 001a ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr->Mode == AddrModeFlat' failed. wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting debugger... Unhandled exception: assertion failed in 64-bit code (0x00007fec2fa657c5). Any ideas about why I can not use winedbg to run Win32 x64 code? Thanks, Peter Urbanec

4 4

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.
by Hans Leidekker 18 Aug '10

18 Aug '10

On Wed, 2010-08-18 at 10:14 +1000, Austin Lund wrote: > #define MAGIC_CRYPTPROV 0xA39E741F > +#define MAGIC_CRYPTKEY 0xA39E741F > +#define MAGIC_CRYPTHASH 0xA39E741F The app might pass a crypto handle of the wrong type, so it would be better to use different magic values.

3 4

Re: wldap32: Fix handling of zero timeout value in ldap_search_extW. (try 2)
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

2 1

Re: [4/5] msi: Handle signature filenames in short|long notation.
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4528 Your paranoid android. === W7PROX64 (32 bit package) === package.c:8348: Test failed: Expected "C:\Program Files\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", got "C:\Program Files (x86)\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\" === W7PROX64 (64 bit package) === package.c:8385: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8396: Test failed: Expected "C:\winetest\", got "" package.c:8407: Test failed: Expected "C:\winetest\", got "" package.c:8457: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8468: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8477: Test failed: Expected "C:\", got "" package.c:8483: Test failed: Expected "C:\winetest\", got "" package.c:8504: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8513: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
14
Older →

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-devel August 2010