January 2015 - wine-devel

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer 22 Nov '20

22 Nov '20

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong 28 Sep '18

28 Sep '18

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

5 6

ODBC Databases: Jet/Access success
by Barry Bird 14 Jun '18

14 Jun '18

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

IMM / IME work
by Aric Stewart 16 Jun '16

16 Jun '16

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

[PATCH] Use asserts for mmap failure modes
by Michael Gilbert 26 Jul '15

26 Jul '15

Hi, Using exit in shared libraries is a discouraged practice, and wine's mmap implementation currently does that. I attach a proposed change using asserts instead. Let me know if you have any feedback. Best wishes, Mike (btw I'm the debian wine maintainer)

2 2

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger 05 Jul '15

05 Jul '15

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

Wine 64 bit
by Kevin Davies 05 Jun '15

05 Jun '15

Hello, Where would you find information on wine64 status for running 64 bit windows software under OSX. These days a lot of Windows programs are going 64bit to make use of the available memory. Its becoming necessary to have this capability. Many thanks Kevin

13 31

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
by Alexandre Julliard 23 Apr '15

23 Apr '15

Qian Hong <qhong(a)codeweavers.com> writes: > --- > dlls/user32/tests/winstation.c | 57 > ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 57 insertions(+) Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html -- Alexandre Julliard julliard(a)winehq.org

3 8

(no subject)
by The Cheese 09 Feb '15

09 Feb '15

Hi, I'm a newbie. I would really like to help with the development of Wine in any capacity I can. The thing is, I looked over the bugzilla and various ways to get the stacktrace, etc. However, finding the cause simply by looking at address calls and returns eludes me. Is there something which might help me get there faster, for eg: reading up on instruction sets on x86 chipsets etc? I've already looked over the winedev-guide. Thanks for any help.

2 1

How WINE implements BitBlt function?
by John Found 06 Feb '15

06 Feb '15

This question arouse when I have made some tests in assembly language. I have wrote a program that to allocate some memory bitmap, fill it with some image and then draw it on a window. The in-memory processing is pretty fast so the main time consuming operation is the drawing of the bitmap on the window. The code is the same for the Windows and Linux version of the program and only the code that draws the bitmap on the window differs. In the Windows version it uses DIB and BitBlt function and in the Linux version it uses XImage bitmap and XPutImage function from XLib. I expected to have some similar performance of both programs, but was surprised, that in WINE, the Windows version performs approximately by 50% faster (150fps) than the Linux version (90..100fps) and the Linux version loads the CPU much higher than the Windows one. So, the question: How in WINE is implemented BitBlt function in order to have so high performance and so low CPU load? -- John Found <johnfound(a)asm32.info>

4 11

Re: ieframe:add app: protocol support to make mshtml trigger BeforeNavigate2 event when handle app: hyperlink
by Jacek Caban 05 Feb '15

05 Feb '15

Hi Changhui, On 01/15/15 02:39, Changhui Liu wrote: > Hi, this verify test need the user click the app: hyperlink in browser, > so it is hard to write a test in dlls/ieframe/tests. > > I upload the test html file and a test exe here: > http://www.imakevideo.com/app.html > http://www.imakevideo.com/mfc_web.zip > > To run the test, extract mfc_web.zip, then run the mfc_web.exe, click > the Go button; > A message "BeforeNavigate2 app:xxx" will popup when click the > app: hyperlink > if the BeforeNavigate2 event was triggered as like IE in windows, or > nothing. It doesn't seem right. There is nothing special about app: protocol handling, BeforeNavigate2 should be called in this case the same way as for any other protocol. You need to find the real reason why it's not called instead of calling it in an error case. The bug is likely to be in mshtml. Jacek

2 4

D3d11 CreateDeviceAndSwapChain
by Martell Malone 01 Feb '15

01 Feb '15

Hi, I hope this is the right place to send this Jacek asked me to send d3d11 patches to wine and not mingw-w64 first. More will come so if this is the wrong place please correct me :) Kind Regards Martell

2 2

Re: [2/3] mciqtz32: "status mode" returns resource strings.
by Marvin 30 Jan '15

30 Jan '15

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 https://testbot.winehq.org/JobDetails.pl?Key=11379 Your paranoid android. === wxppro (32 bit mci) === mci.c:1287: Test failed: mci capability device type returned MCIERR_DEVICE_LOCKED

1 0

Re: League of Legends shop in game fix
by Austin English 30 Jan '15

30 Jan '15

On Thu, Jan 29, 2015 at 9:19 AM, Monster <manuiglesias96(a)yahoo.es> wrote: > @@ -220,7 +220,10 @@ BOOL wined3d_resource_allocate_sysmem(struct > wined3d_resource *resource) > SIZE_T align = RESOURCE_ALIGNMENT - 1 + sizeof(*p); > void *mem; > - if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > resource->size + align))) > + UINT size = resource->size; > + if (resource->width <= 128 && resource->height <= 128) > + size *= 2; > + if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size + > align))) > return FALSE; > p = (void **)(((ULONG_PTR)mem + align) & ~(RESOURCE_ALIGNMENT - 1)) - 1; > > > > Please use your real name when sending patches. -- -Austin

3 2

Re: [PATCH] winemac.drv: Always initialize a closure-captured object pointer.
by Ken Thomases 30 Jan '15

30 Jan '15

On Jan 29, 2015, at 5:23 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > You might argue that we don't need to do this because we only use it on > the control paths where we initialize it. Ah, but it *is* used on one of > the other paths: it is captured by the Block closure whether or not we > actually use it inside the Block. This means that, when we copy the > Block onto the heap in OnMainThreadAsync(), the runtime will attempt to > retain it. For some reason, we got away with this in 32-bit > land--probably because the pointer happened to be NULL anyway--but it > broke and died horribly on 64-bit. > > With this change, 64-bit winemac.drv is actually usable. Nice. I was aware of the warning but assumed that it was benign. I'm not sure it's a coincidence that it worked in 32-bit. I don't think that dispatch objects are actually automatically retained by blocks which reference them in 32-bit. It's not entirely related, but it's relatively recent that ARC started doing that and, of course, that requires the modern Objective-C runtime and thus 64-bit. Anyway, I'm glad the Mac driver crashiness in the 64-bit build stemmed from a single cause. I'm sure it wasn't fun to find it. Thanks for doing so. -Ken

1 0

Re: msvcrt: Bump MSVCRT_MB_LEN_MAX to 6 and use it in MSVCRT__wctomb_l for default buffer length
by Piotr Caban 29 Jan '15

29 Jan '15

On 01/23/15 18:38, Orion Poplawski wrote: > diff --git a/dlls/msvcrt/msvcrt.h b/dlls/msvcrt/msvcrt.h > index 41f31b9..401628a 100644 > --- a/dlls/msvcrt/msvcrt.h > +++ b/dlls/msvcrt/msvcrt.h > @@ -47,7 +47,7 @@ > #define MSVCRT_I64_MAX (((__int64)0x7fffffff << 32) | 0xffffffff) > #define MSVCRT_I64_MIN (-MSVCRT_I64_MAX-1) > #define MSVCRT_UI64_MAX (((unsigned __int64)0xffffffff << 32) | 0xffffffff) > -#define MSVCRT_MB_LEN_MAX 2 > +#define MSVCRT_MB_LEN_MAX 6 MB_LEN_MAX equals 5 on windows. It should probably be set to 5 here as well. Probably include/msvcrt/limits.h should also be changed. Thanks, Piotr

2 2

Re: [PATCH 1/2] kernel32/tests: Make loader tests independent from each other
by Dmitry Timoshkov 28 Jan '15

28 Jan '15

> +const static IMAGE_NT_HEADERS nt_header_template = 'static const' is a commonly accepted order. There are various reasons of the current tests structure, if you are not planning to add new tests please leave the code as it is please. -- Dmitry.

2 4

Re: mshtml: Added support for _self target in IHTMLWindow2::open.
by Marvin 28 Jan '15

28 Jan '15

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 https://testbot.winehq.org/JobDetails.pl?Key=11354 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: msvcrt: Fix inconsistent rounding behaviour for sprintf and add tests.
by Piotr Caban 28 Jan '15

28 Jan '15

On 01/26/15 12:29, YongHao Hu wrote: > + if(flags.Precision >= 0 && toupper(flags.Format)!='G') { > + temp = pow(10, flags.Precision); > + val = round(val * temp) / temp; > + } This is not correct, val may loose to much precision. Also temp can become INF (in your patch temp is int but I guess it's a mistake). I'm afraid that in order to fix this bug you'll need to stop using glibcs sprintf in wine's printf implementation. Your patch to msvcp tests depends on this patch. Please send patches that depend on each other in series. Thanks, Piotr

2 1

Re: [PATCH 3/3] winecfg: add speaker config controls to audio tab
by Andrew Eikum 27 Jan '15

27 Jan '15

I think you can squash the last two patches. No need to add symbols before they're used. Does it make sense to have a "system default" configuration as well? For example if the user changes which device ALSA's "default" points to from a 5.1 setup to a stereo setup, the "system default" setting should report the configurations correctly (or, as correctly as the backend allows, but you get the point). This might require storing the user-selected speaker configuration elsewhere in the registry, and updating the real registry entry on mmdevapi load. Couple notes below. On Mon, Jan 26, 2015 at 10:28:26PM +0000, Mark Harmstone wrote: > + info->speaker_config = 999; > + if(SUCCEEDED(hr) && pv.vt == VT_UI4){ > + i = 0; > + while (speaker_configs[i].text_id != 0 && info->speaker_config == 999) { > + if ((speaker_configs[i].speaker_mask & pv.u.ulVal) == speaker_configs[i].speaker_mask) > + info->speaker_config = i; > + i++; > + } > + } This is kind of awkward. Could be a for-loop and break early. > + > + /* fallback to stereo */ > + if(info->speaker_config == 999) > + info->speaker_config = 2; > + Yeah, I don't like 999 either. The "system default" would provide a reasonable fallback option here, too. > + IPropertyStore_Release(ps); > + > return TRUE; > + for (i = 0; i < num_render_devs; i++) { > + ERR("%s -> %u\n", wine_dbgstr_w(render_devs[i].id), speaker_configs[render_devs[i].speaker_config].speaker_mask); Looks like a debug line that should be removed or switched to TRACE. > + pv.u.ulVal = speaker_configs[render_devs[i].speaker_config].speaker_mask; > + WARN("speaker_config = %u\n", pv.u.ulVal); Another debug line? > + > + hr = IPropertyStore_SetValue(ps, &PKEY_AudioEndpoint_PhysicalSpeakers, &pv); > + > + if (FAILED(hr)) > + WARN("IPropertyStore_SetValue failed for %s: 0x%08x\n", wine_dbgstr_w(render_devs[i].id), hr); > + > + IPropertyStore_Commit(ps); This isn't actually implemented in mmdevapi, so we end up with noisy "stub" messages on the terminal. Best thing to do would be to fix the property store implementation, but in lieu of that, I'd just switch the FIXME in mmdevapi with a TRACE. Andrew

1 0

Re: shell32: Handle TRASH_EnumItems failures correctly
by Marvin 27 Jan '15

27 Jan '15

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 https://testbot.winehq.org/JobDetails.pl?Key=11318 Your paranoid android. === wvistau64 (32 bit recyclebin) === recyclebin.c:98: Test failed: Expected recycle bin to have 0x8 bytes === wvistau64 (64 bit recyclebin) === recyclebin.c:98: Test failed: Expected recycle bin to have 0x8 bytes

1 0

Re: [PATCH 3/3] winecfg: add speaker config controls to audio tab
by André Hentschel 26 Jan '15

26 Jan '15

Hi, first, this should be merged with patch 2. (atomic changes) Am 26.01.2015 um 23:28 schrieb Mark Harmstone: > - IPropertyStore_Release(ps); > if(FAILED(hr)){ > CoTaskMemFree(info->id); > info->id = NULL; > + IPropertyStore_Release(ps); > return FALSE; > } This looks like a independent atomic fix... > + hr = IPropertyStore_GetValue(ps, > + &PKEY_AudioEndpoint_PhysicalSpeakers, &pv); > + > + info->speaker_config = 999; > + if(SUCCEEDED(hr) && pv.vt == VT_UI4){ minor whitespace issue(s) and seen some more whitespace issues, no need to keep consistent with existing code here i'd say > + > + /* fallback to stereo */ > + if(info->speaker_config == 999) my thoughts on this: not sure, maybe -1 is better, or ~0. maybe it should be unsigned... I hope my thoughts help anyway

1 0

Re: [PATCH 2/2] mshtml: Report about protocol as UI resource.
by Alexandre Julliard 26 Jan '15

26 Jan '15

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/nsio.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) This is apparently causing the script.c test to hang here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] d3d/tests: Show that WM_SYSCOMMAND(SC_RESTORE) is delivered only once.
by Marvin 26 Jan '15

26 Jan '15

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 https://testbot.winehq.org/JobDetails.pl?Key=11305 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2557: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2562: Test failed: The focus window is active. device.c:2570: Test failed: Got unexpected hr 0x88760869. device.c:2576: Test failed: Got unexpect screen size 800x600. device.c:2591: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2600: Test failed: Got unexpect screen size 800x600. device.c:2613: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2621: Test failed: Got unexpect width 640. device.c:2622: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 1/2] wined3d: Pass WM_SYSCOMMAND(SC_RESTORE) to DefWindowProc (v2).
by Marvin 26 Jan '15

26 Jan '15

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 https://testbot.winehq.org/JobDetails.pl?Key=11303 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

1 0

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 January 2015