April 2014 - Wine-Devel - list.winehq.org

Re: [1/2] dpnet: Use dxguid for tests (resend)

by Marvin

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=6530 Your paranoid android. === w864 (64 bit peer) === The test timed out

April 24, 2014

Re: [4/4] ole32: Initial storage file locking implementation.

by Marvin

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=6527 Your paranoid android. === w2000pro (32 bit storage32) === storage32.c:3213: Test failed: file with mode 1012 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 11012 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 11022 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 11021 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 12 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 10012 should not be openable with WRITE permission

April 23, 2014

Re: [2/4] ole32: Add tests for sharing storages in transacted mode.

by Marvin

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=6526 Your paranoid android. === w2000pro (32 bit storage32) === storage32.c:3213: Test failed: file with mode 1012 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 11012 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 11022 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 11021 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 12 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 10012 should not be openable with WRITE permission

April 23, 2014

Re: [1/4] ole32: Add tests for storage locking.

by Marvin

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=6524 Your paranoid android. === w2000pro (32 bit storage32) === storage32.c:3213: Test failed: file with mode 1012 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 11012 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 11022 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 11021 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 12 should not be openable with WRITE permission storage32.c:3213: Test failed: file with mode 10012 should not be openable with WRITE permission

April 23, 2014

Re: vbscript: Return proper error on invalid argument in Chr.

by Marvin

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=6517 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found

April 23, 2014

Re: [PATCH 3/5] ddraw: Validate the pitch for user memory surfaces against the unaligned minimum pitch.

by Marvin

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=6514 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2.c:5096: Test failed: Got unexpected refcount 3. ddraw2.c:5115: Test failed: Got unexpected refcount 3. ddraw2.c:5122: Test failed: Got unexpected hr 0. ddraw2.c:5125: Test failed: Got unexpected refcount 3. ddraw2.c:5127: Test failed: Got unexpected refcount 2. ddraw2.c:5133: Test failed: Got unexpected hr 0. ddraw2.c:5136: Test failed: Got unexpected refcount 2. ddraw2.c:5138: Test failed: Got unexpected refcount 1. === w864 (32 bit ddraw1) === ddraw1.c:3991: Test failed: Got unexpected refcount 3. ddraw1.c:4010: Test failed: Got unexpected refcount 3. ddraw1.c:4017: Test failed: Got unexpected hr 0. ddraw1.c:4020: Test failed: Got unexpected refcount 3. ddraw1.c:4022: Test failed: Got unexpected refcount 2. ddraw1.c:4028: Test failed: Got unexpected hr 0. ddraw1.c:4031: Test failed: Got unexpected refcount 2. ddraw1.c:4033: Test failed: Got unexpected refcount 1. === wxppro (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 00247AE8. ddraw7: unhandled exception c0000005 at 0045C03B === wvista (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 00314A78. ddraw7: unhandled exception c0000005 at 0045C03B === w2008s64 (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 005BFE60. ddraw7: unhandled exception c0000005 at 0045C03B === w7u (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 0076BEB8. ddraw7: unhandled exception c0000005 at 0045C03B === w864 (32 bit ddraw7) === ddraw7.c:5629: Test failed: Got unexpected refcount 3. ddraw7.c:5648: Test failed: Got unexpected refcount 3. ddraw7.c:5655: Test failed: Got unexpected hr 0. ddraw7.c:5658: Test failed: Got unexpected refcount 3. ddraw7.c:5660: Test failed: Got unexpected refcount 2. ddraw7.c:5666: Test failed: Got unexpected hr 0. ddraw7.c:5669: Test failed: Got unexpected refcount 2. ddraw7.c:5673: Test failed: Got unexpected refcount 6. ddraw7.c:5790: Test failed: Failed to set cooperative level, hr 0x8876023b. === w2008s64 (64 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 0000000000000000, expected 0000000000762980. ddraw7: unhandled exception c0000005 at 00000000004520D1 === w864 (64 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 0000000000000000, expected 00000000007150E0. ddraw7: unhandled exception c0000005 at 00000000004520D1 === w864 (32 bit ddraw4) === ddraw4.c:5756: Test failed: Got unexpected refcount 3. ddraw4.c:5775: Test failed: Got unexpected refcount 3. ddraw4.c:5782: Test failed: Got unexpected hr 0. ddraw4.c:5785: Test failed: Got unexpected refcount 3. ddraw4.c:5787: Test failed: Got unexpected refcount 2. ddraw4.c:5793: Test failed: Got unexpected hr 0. ddraw4.c:5796: Test failed: Got unexpected refcount 2. ddraw4.c:5798: Test failed: Got unexpected refcount 1. ddraw4.c:5800: Test failed: Got unexpected refcount 6. ddraw4.c:5920: Test failed: Failed to set cooperative level, hr 0x8876023b. ddraw4.c:5959: Test failed: Failed to attach surface, hr 0x887600e1. ddraw4.c:5962: Test failed: Got unexpected hr 0. ddraw4.c:5964: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:5967: Test failed: Failed to attach surface, hr 0x887601c2. ddraw4.c:5970: Test failed: Got unexpected hr 0x887601c2. ddraw4.c:5972: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:5975: Test failed: Failed to attach surface, hr 0x887601c2. ddraw4.c:5977: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:5980: Test failed: Got unexpected hr 0x887600e1. ddraw4.c:5982: Test failed: Got unexpected hr 0x887601c2.

April 23, 2014

GSoC 2014 - accepted proposals announcement

by Austin English

The accepted proposals for Google's Summer of Code 2014 have been announced. We have accepted 4 proposals this year. * Implement missing and improve existing D3DX9 APIs - by Gediminas Jakutis, mentored by: Matteo Bruni and Stefan Dösinger * Implement ITextDocument::Range and ITextRange - by Jactry Zeng, mentored by Huw Davies and André Hentschel * Implement VBScript built-in functions - by Shuai Meng, mentored by Piotr Caban and Detlef Riekenberg * Implemention for mshtml.dll - by Zhenbo Li, mentored by Jacek Caban and Ulrich Czekalla Congratulations! Students, this is the community bonding period ( http://googlesummerofcode.blogspot.com/2007/04/so-what-is-this-community-bo…) which you should use to get up to speed on your project. In other words, discuss your goals/milestones with your mentors, reviewing bugs in those areas, reading the code, etc. Coding begins May 19th, and mid term reviews are June 23-27th. If you have any GSoC questions, please contact your mentors or the administrators (myself and André Hentschel). Technical questions should be discussed with your mentor or on wine-devel/#winehackers on Freenode IRC. Once again, congratulations! Welcome to Wine, and good luck on your project. -- -Austin

April 23, 2014

Re: Fixing conflicts between WineD3D and WGL

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I tested this a little bit sooner than expected, thanks to a regression in Starcraft and Age of Empires 2. (Looks like bugs 35950 and 35655). The good news is that your patches fix the regressions in those games. Am 2014-04-21 17:49, schrieb Ken Thomases: > * Full-screen games are actually full-screen, appearing in front > of other apps, docks, panels, menus, taskbars, etc. Kde 4.11.5 here. The fullscreen apps indeed appear fullscreen. But once Starcraft was shifted down and only showing the top ~50 pixels at the bottom of the screen. Inside a virtual desktop Age of Empires 2 seemed to snap into place after a resolution change. It first rendered at the bottom of the screen and after ~0.5 seconds the rendering was correct. > * But you can switch to another app as well/easily as you could > without these patches. Full-screen games don't take over your > whole display such that you can't escape without drastic measures. Alt-Tab does not work. The game loses focus and stops redrawing, but my other apps don't show up. Switching to a different virtual desktop works. I don't know if this worked in the past with those two games, probably not. I'll retest with plain Wine, as far as the regressions allow. > * After switching away, you can switch back successfully. I have to select the Wine window. If I select the game window, Wine's rendering window does not take over. > * Mouse input works as expected. In particular, clicks are not > offset from where the cursor appears to be, especially after > switching resolutions or between windowed and full-screen modes. No issues noticed there, but both games draw their own mouse cursor. I've also tested Warhammer 40k: Dawn of War, it has the same focus loss / regain behavior as the ddraw games. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTWCzmAAoJEN0/YqbEcdMwl/QQAJYSZZGTq6kB4lTq2BqolkB9 pznB3Q/foP/PHSaVnqm1S/KSFq5VUU1dUZDYe02Y8WGUL1t8yLBBIqs/dDMwB9fN l3plx9acUebagTfInRKbQvGHoSLVa2syttvVByPhxDJ4R0hIb259h2te+nDDTXNr WK+Pk2bmR3OaEN7XyAEyprtNG76XCD2THKccY0jqAGySMEGo3tXAKRfwT7p+K7am bjqM8zsidcfU21oYBpNGcmdeKEMAvvynt1Vk7Nz0q7eckD1mIc5g23rXJ0O1oP2l gdUIV9K0m3nzIPjlS8ejvSkvarOmL8SM7b7w5kKcybVtMNrLwcxyrzDIE/IC2TCN g4LAeC5fLeyLrxillCuyj2nNNnPf532xkypPWEdYf4Zr/c2dvW0ehmA2YXxLFk3a Cf7GO+06Z85zyqJj0M6wgw21pi+/IhAR1aJ/sOdFTEjQxJQZ8liCvGea0wnsHwcd VLorQCM9g97GHpe3di/7/CHvdx8sVeLapIVASvTlV6CYfpPe7FObfOoyOG1tKZAl Ru/d5bcpM7zbE/vAuXbRqQpiu9/El7AoTo//ndkPT+5sBhFjUlrcZIvlmYOcK4qD 6buir7Jh+VgDzKFsnH40h62jOAt1BwXNwxqOACh3rVyCjzuQTkwBCO/Hl7dLz2VB owQzHiQCJ0zbZ6W+yrx9 =A7mH -----END PGP SIGNATURE-----

April 23, 2014

Re: wined3d: Add NVIDIA Geforce GTX 780 Ti to supported device list

by Henri Verbeet

On 23 April 2014 00:17, André Hentschel <nerv(a)dawncrow.de> wrote: > Information gathered at: > http://pci-ids.ucw.cz/read/PC/10de > https://freedesktop.org/nouveau/CodeNames/ > http://www.nvidia.de/object/geforce-gtx-780-ti-de.html#pdpContent=2 > > Should i rather add a whole bunch of cards using these sources of information? > I'd prefer this kind of patch to be verified against the actual Windows and Linux drivers.

April 23, 2014

Re: [PATCH] vbscript: Implemented IsNumeric

by Jacek Caban

On 04/23/14 17:16, Jacek Caban wrote: > On 04/23/14 02:20, Shuai Meng wrote: >> --- a/dlls/vbscript/global.c >> +++ b/dlls/vbscript/global.c >> @@ -557,8 +557,41 @@ static HRESULT Global_IsNull(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VA >> >> static HRESULT Global_IsNumeric(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) >> { >> - FIXME("\n"); >> - return E_NOTIMPL; >> + TRACE("(%s)\n", debugstr_variant(arg)); >> + >> + assert(args_cnt == 1); >> + >> + if(res) { >> + V_VT(res) = VT_BOOL; > > You can't assume that res is non-NULL. Ignore this comment, I misread the code. Cheers, Jacek

April 23, 2014

Re: [PATCH] vbscript: Implemented IsNumeric

by Jacek Caban

On 04/23/14 02:20, Shuai Meng wrote: > --- a/dlls/vbscript/global.c > +++ b/dlls/vbscript/global.c > @@ -557,8 +557,41 @@ static HRESULT Global_IsNull(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VA > > static HRESULT Global_IsNumeric(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > { > - FIXME("\n"); > - return E_NOTIMPL; > + TRACE("(%s)\n", debugstr_variant(arg)); > + > + assert(args_cnt == 1); > + > + if(res) { > + V_VT(res) = VT_BOOL; You can't assume that res is non-NULL. > + switch(V_VT(arg)) { > + case VT_UI1: > + case VT_I2: > + case VT_I4: > + case VT_I8: > + case VT_R4: > + case VT_R8: > + case VT_BOOL: > + case VT_EMPTY: > + case VT_CY: > + V_BOOL(res) = VARIANT_TRUE; > + break; > + case VT_BSTR: { > + HRESULT hRet; > + double d; > + > + hRet = VarR8FromStr(V_BSTR(arg), LOCALE_USER_DEFAULT, 0, &d); > + if(SUCCEEDED(hRet)) > + V_BOOL(res) = VARIANT_TRUE; > + else > + V_BOOL(res) = VARIANT_FALSE; > + break; > + } > + default: > + V_BOOL(res) = VARIANT_FALSE; > + break; That's a risky assumption. There are tons of other VT_* types possible and at least VT_UI2, VT_UI4 and alike should most likely return true. It's much safer to add explicit list of *tested* cases to return false and FIXME(); return E_NOTIMPL for other cases. > + } > + } > + return S_OK; > } > > static HRESULT Global_IsArray(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > diff --git a/dlls/vbscript/tests/api.vbs b/dlls/vbscript/tests/api.vbs > index beee4d4..cf63fb9 100644 > --- a/dlls/vbscript/tests/api.vbs > +++ b/dlls/vbscript/tests/api.vbs > @@ -170,6 +170,25 @@ Call ok(not isNull(4), "isNull(4) is true?") > Call ok(not isNull("x"), "isNull(""x"") is true?") > Call ok(isNull(Null), "isNull(Null) is not true?") > > +Call ok(isNumeric(empty), "isNumeric(empty) is not true?") > +Call ok(not isNumeric(Null), "isNumeric(Null) is not true?") > +Call ok(isNumeric(32767), "isNumeric(32767) is true?") > +Call ok(isNumeric(32768), "isNumeric(32768) is true?") > +Call ok(isNumeric(CSng(3242.4)), "isNumeric(CSng(3242.4)) is true?") > +Call ok(isNumeric(32768.4), "isNumeric(32768.4) is true?") > +Call ok(isNumeric(CCur(32768.4)), "isNumeric(CCur(32768.4)) is true?") > +Call ok(not isNumeric(CDate(32)), "isNumeric(CDate(32)) is true?") > +Call ok(isNumeric("44"), "isNumeric(""44"") is true?") > +Call ok(not isNumeric("rwrf"), "isNumeric(""rwrf"") is not true?") > +Call ok(not isNumeric(Nothing), "isNumeric(Nothing) is not true?") > +Call ok(not isNumeric(New EmptyClass), "isNumeric(New EmptyClass) is not true?") > +Call ok(isNumeric(true), "isNumeric(true) is true?") > +Call ok(isNumeric(CByte(32)), "isNumeric(CByte(32)) is true?") > +Dim arr(2) > +arr(0) = 2 > +arr(1) = 3 > +Call ok(not isNumeric(arr), "isNumeric(arr) is not true?") > + > Call ok(getVT(err) = "VT_DISPATCH", "getVT(err) = " & getVT(err)) > Your tests depend on your previous patches that were not committed and I already commented them. Please concentrate on getting them committed first. Jacek

April 23, 2014

Re: imagehlp: Implement (parts of) BindImageEx (try 4)

by Marvin

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=6512 Your paranoid android. === w2000pro (32 bit image) === image.c:298: Test failed: expected DllName to be KERNEL32.DLL, got C:\WINNT\system32\KERNEL32.DLL === wxppro (32 bit image) === image.c:298: Test failed: expected DllName to be KERNEL32.DLL, got C:\WINDOWS\system32\KERNEL32.DLL === wvista (32 bit image) === image.c:298: Test failed: expected DllName to be KERNEL32.DLL, got C:\Windows\system32\KERNEL32.DLL === w2008s64 (32 bit image) === image.c:298: Test failed: expected DllName to be KERNEL32.DLL, got C:\Windows\system32\KERNEL32.DLL === w7u (32 bit image) === image.c:298: Test failed: expected DllName to be KERNEL32.DLL, got C:\Windows\system32\KERNEL32.DLL === w864 (32 bit image) === image.c:382: Test failed: expected ERROR_FILE_NOT_FOUND, got 87 image.c:298: Test failed: expected DllName to be KERNEL32.DLL, got C:\WINDOWS\SYSTEM32\KERNEL32.DLL === w2008s64 (64 bit image) === image.c:382: Test failed: expected ERROR_FILE_NOT_FOUND, got 87 === w864 (64 bit image) === image.c:382: Test failed: expected ERROR_FILE_NOT_FOUND, got 87 image.c:298: Test failed: expected DllName to be KERNEL32.DLL, got C:\WINDOWS\SYSTEM32\KERNEL32.DLL

April 23, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Stefan Dösinger

Am 23.04.2014 um 09:15 schrieb Christopher Thielen <christopher(a)thielen.co>: > Once the cursor data is loaded from bitmap16.flx to a heap, I never see a reference to that memory again, at least in an API trace. After various initializations, there are a lot of CreateTexture calls followed by LockRect ... UnlockRect. From reading around online, my guess is the game uploads textures using memcpy() while the rect is locked. Can anyone who knows a bit more about D3D confirm that's a probable method of uploading textures? Correct. This is a common way to load textures. There are others, but they all involve LockRect and UnlockRect at some point.

April 23, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Christopher Thielen

Sadly didn't help. I discovered API Monitor for Windows so I've been comparing the two code paths as best I can. They're pretty similar between Windows XP and Wine. My theory about clearing LastError wasn't correct - Windows XP also leaves it with stale error codes. Once the cursor data is loaded from bitmap16.flx to a heap, I never see a reference to that memory again, at least in an API trace. After various initializations, there are a lot of CreateTexture calls followed by LockRect ... UnlockRect. From reading around online, my guess is the game uploads textures using memcpy() while the rect is locked. Can anyone who knows a bit more about D3D confirm that's a probable method of uploading textures? If that's true, I think the next logical step is trying to find when the texture resource is loaded in the Windows code path so I can start to find where Wine differs. I'm not sure how to do that short of API Monitor's "break on call and look at assembly" feature. On 4/22/2014 5:57 PM, Christopher Thielen wrote: > Thanks Ken! > > I don't think a missing library is the problem: the game stores all > its texture resources in a file called bitmap16.flx and the code paths > under Wine for reading those bitmaps and making textures out of them > seems to work just fine given that many of them are visible in the > final running game. > > The offset of the cursor resource within bitmap16.flx is 0x1020eb4 and > the '.flx item' (as files within this proprietary archive are called) > itself is about 400,000 bytes (that's for 121 separate cursors all > read at once). > > Looking through +file,+tid,+relay recommended by Ken, I found: > > 0009:trace:file:CreateFileW L"C:\\GOG Games\\Ultima IX - > Ascension\\static\\bitmap16.flx" GENERIC_READ creation 4 attributes 0x80 > 0009:trace:file:RtlDosPathNameToNtPathName_U (L"C:\\GOG Games\\Ultima > IX - Ascension\\static\\bitmap16.flx",0x32ef74,(nil),(nil)) > 0009:trace:file:RtlGetFullPathName_U (L"C:\\GOG Games\\Ultima IX - > Ascension\\static\\bitmap16.flx" 520 0x32ecc4 (nil)) > 0009:trace:file:wine_nt_to_unix_file_name L"\\??\\C:\\GOG > Games\\Ultima IX - Ascension\\static\\bitmap16.flx" -> > "/home/cthielen/.wine/dosdevices/c:/GOG Games/Ultima IX - > Ascension/static/bitmap16.flx" > 0009:trace:file:CreateFileW returning 0xac > > > > which I believe implies bitmap16.flx is being given the file handle > 0xac. Searching for '0xac' I later find: > > > > 0009:Call KERNEL32.SetFilePointer(000000ac,01020eb4,00000000,00000000) > ret=005de4c9 > 0009:Ret KERNEL32.SetFilePointer() retval=01020eb4 ret=005de4c9 > 0009:Call > KERNEL32.ReadFile(000000ac,02539110,00061b8c,0032edfc,00000000) > ret=005de512 > 0009:trace:file:ReadFile 0xac 0x2539110 400268 0x32edfc (nil) > 0009:Ret KERNEL32.ReadFile() retval=00000001 ret=005de512 > 0009:Call KERNEL32.GetLastError() ret=005de518 > 0009:Ret KERNEL32.GetLastError() retval=00000002 ret=005de518 > 0009:Call ntdll.RtlAllocateHeap(01450000,00000000,00001700) ret=00714f22 > 0009:Ret ntdll.RtlAllocateHeap() retval=0259aca8 ret=00714f22 > 0009:Call ntdll.RtlAllocateHeap(01450000,00000000,00000200) ret=00714f22 > 0009:Ret ntdll.RtlAllocateHeap() retval=0259c3b0 ret=00714f22 > 0009:Call user32.LoadCursorA(00000000,00007f00) ret=005d5743 > 0009:Ret user32.LoadCursorA() retval=00010038 ret=005d5743 > 0009:Call user32.SetCursor(00010038) ret=005dbf5f > 0009:Call winex11.drv.SetCursor(00010038) ret=7eb0f777 > 0009:Ret winex11.drv.SetCursor() retval=00000000 ret=7eb0f777 > 0009:Ret user32.SetCursor() retval=00000000 ret=005dbf5f > 0009:Call user32.CreateWindowExA(00000000,0032f5c0 > "OFCBlackWindowClass",00787774 "Ultima > IX",80030000,80000000,80000000,80000000,80000000,00000000,00000000,00400000,00000000) > ret=005d579c > 0009:Call KERNEL32.LZOpenFileW(0032ee74 L"C:\\GOG Games\\Ultima IX - > Ascension\\u9.exe",0032ed64,00000000) ret=b7788b42 > 0009:trace:file:LZOpenFileA (C:\GOG Games\Ultima IX - > Ascension\u9.exe,0x32ed64,0) > > > which appears to be reading the exact offset I know the cursor to be > in within bitmap16.flx (file handle 0xac presumably). It also seems to > request about 400,000 bytes at that offset, which also lines up with > what I know about the missing cursor resource. > > What it then seems to do is call LoadCursor and SetCursor which may be > curious because I thought we had ruled out user32 cursors as having > been used. Based on cross-compiling d3d7 and running the game on > Windows XP with Wine's d3d7 however, we know the problem is not in > Wine's D3D implementation, so maybe it's logical to suspect cursor > after all. > > However that doesn't make much sense because LoadCursor 7f00 is the > standard system cursor. > > But what about the GetLastError() call returning 2 (which I believe is > ERROR_FILE_NOT_FOUND)? Does that seem normal right after a successful > (non-zero) file read? > > Here's a wild theory knowing little about this stuff: ReadFile is > maybe supposed to clear out that thread's GetLastError value and > u9.exe is calling GetLastError() to see if errors exist, instead of > checking only after a zero return value from ReadFile like it should > (it is considered a poorly written game). If Wine doesn't clear out > GetLastError correctly, it could cause an alternate code path to run > under Wine in which the cursors are believed not to be loaded properly. > > Notably, that same file handle seems to be used correctly later on: > > (0xac is bitmap16.flx) > > 0009:Call KERNEL32.SetFilePointer(000000ac,01e3dcc0,00000000,00000000) > ret=005de4c9 > 0009:Ret KERNEL32.SetFilePointer() retval=01e3dcc0 ret=005de4c9 > 0009:Call > KERNEL32.ReadFile(000000ac,0032f3f4,00000008,0032f3c4,00000000) > ret=005de512 > 0009:trace:file:ReadFile 0xac 0x32f3f4 8 0x32f3c4 (nil) > 0009:Ret KERNEL32.ReadFile() retval=00000001 ret=005de512 > 0009:Call KERNEL32.GetLastError() ret=005de518 > 0009:Ret KERNEL32.GetLastError() retval=00000000 ret=005de518 > > Or is that am incorrect assumption? > > Any ideas? > > On 03/24/2014 06:27 PM, Ken Thomases wrote: >> On Mar 24, 2014, at 7:48 PM, Christopher Thielen wrote: >> >>> Using WINEDEBUG=+all, the resource in question (static/bitmap16.flx) >>> is loaded via kernel32's CreateFile, ReadFile. >>> >>> Is there a way to trace only kernel32 calls dealing with a specific >>> file handle? I'm curious if there are any failed reads. Does that >>> seem like a reasonable next step? >> >> Not really. You'll want to use a +file log and follow the handle as >> it's passed to subsequent calls. It might also be necessary to use >> +tid,+relay to see all uses if Wine isn't logging the handle in all >> relevant functions. >> >> Certainly, look for failed reads, but I wouldn't expect that unless >> you think the file is damaged vs. what's installed on Windows. More >> likely, the game requires external help interpreting the data that is >> has read, like a compression or image library. If that's not present >> or is incomplete in Wine, then that would explain the problem. The >> +tid,+relay log may help to identify what the program does next after >> it has read the data in. >> >> -Ken >> > >

April 23, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Ken Thomases

On Apr 22, 2014, at 7:57 PM, Christopher Thielen wrote: > Here's a wild theory knowing little about this stuff: ReadFile is maybe supposed to clear out that thread's GetLastError value and u9.exe is calling GetLastError() to see if errors exist, instead of checking only after a zero return value from ReadFile like it should (it is considered a poorly written game). If Wine doesn't clear out GetLastError correctly, it could cause an alternate code path to run under Wine in which the cursors are believed not to be loaded properly. That's a reasonable theory given what the relay log shows. Try adding a call to SetLastError(0) near the top of ReadFile() to see if it changes the game's behavior. -Ken

April 22, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Christopher Thielen

Thanks Ken! I don't think a missing library is the problem: the game stores all its texture resources in a file called bitmap16.flx and the code paths under Wine for reading those bitmaps and making textures out of them seems to work just fine given that many of them are visible in the final running game. The offset of the cursor resource within bitmap16.flx is 0x1020eb4 and the '.flx item' (as files within this proprietary archive are called) itself is about 400,000 bytes (that's for 121 separate cursors all read at once). Looking through +file,+tid,+relay recommended by Ken, I found: 0009:trace:file:CreateFileW L"C:\\GOG Games\\Ultima IX - Ascension\\static\\bitmap16.flx" GENERIC_READ creation 4 attributes 0x80 0009:trace:file:RtlDosPathNameToNtPathName_U (L"C:\\GOG Games\\Ultima IX - Ascension\\static\\bitmap16.flx",0x32ef74,(nil),(nil)) 0009:trace:file:RtlGetFullPathName_U (L"C:\\GOG Games\\Ultima IX - Ascension\\static\\bitmap16.flx" 520 0x32ecc4 (nil)) 0009:trace:file:wine_nt_to_unix_file_name L"\\??\\C:\\GOG Games\\Ultima IX - Ascension\\static\\bitmap16.flx" -> "/home/cthielen/.wine/dosdevices/c:/GOG Games/Ultima IX - Ascension/static/bitmap16.flx" 0009:trace:file:CreateFileW returning 0xac which I believe implies bitmap16.flx is being given the file handle 0xac. Searching for '0xac' I later find: 0009:Call KERNEL32.SetFilePointer(000000ac,01020eb4,00000000,00000000) ret=005de4c9 0009:Ret KERNEL32.SetFilePointer() retval=01020eb4 ret=005de4c9 0009:Call KERNEL32.ReadFile(000000ac,02539110,00061b8c,0032edfc,00000000) ret=005de512 0009:trace:file:ReadFile 0xac 0x2539110 400268 0x32edfc (nil) 0009:Ret KERNEL32.ReadFile() retval=00000001 ret=005de512 0009:Call KERNEL32.GetLastError() ret=005de518 0009:Ret KERNEL32.GetLastError() retval=00000002 ret=005de518 0009:Call ntdll.RtlAllocateHeap(01450000,00000000,00001700) ret=00714f22 0009:Ret ntdll.RtlAllocateHeap() retval=0259aca8 ret=00714f22 0009:Call ntdll.RtlAllocateHeap(01450000,00000000,00000200) ret=00714f22 0009:Ret ntdll.RtlAllocateHeap() retval=0259c3b0 ret=00714f22 0009:Call user32.LoadCursorA(00000000,00007f00) ret=005d5743 0009:Ret user32.LoadCursorA() retval=00010038 ret=005d5743 0009:Call user32.SetCursor(00010038) ret=005dbf5f 0009:Call winex11.drv.SetCursor(00010038) ret=7eb0f777 0009:Ret winex11.drv.SetCursor() retval=00000000 ret=7eb0f777 0009:Ret user32.SetCursor() retval=00000000 ret=005dbf5f 0009:Call user32.CreateWindowExA(00000000,0032f5c0 "OFCBlackWindowClass",00787774 "Ultima IX",80030000,80000000,80000000,80000000,80000000,00000000,00000000,00400000,00000000) ret=005d579c 0009:Call KERNEL32.LZOpenFileW(0032ee74 L"C:\\GOG Games\\Ultima IX - Ascension\\u9.exe",0032ed64,00000000) ret=b7788b42 0009:trace:file:LZOpenFileA (C:\GOG Games\Ultima IX - Ascension\u9.exe,0x32ed64,0) which appears to be reading the exact offset I know the cursor to be in within bitmap16.flx (file handle 0xac presumably). It also seems to request about 400,000 bytes at that offset, which also lines up with what I know about the missing cursor resource. What it then seems to do is call LoadCursor and SetCursor which may be curious because I thought we had ruled out user32 cursors as having been used. Based on cross-compiling d3d7 and running the game on Windows XP with Wine's d3d7 however, we know the problem is not in Wine's D3D implementation, so maybe it's logical to suspect cursor after all. However that doesn't make much sense because LoadCursor 7f00 is the standard system cursor. But what about the GetLastError() call returning 2 (which I believe is ERROR_FILE_NOT_FOUND)? Does that seem normal right after a successful (non-zero) file read? Here's a wild theory knowing little about this stuff: ReadFile is maybe supposed to clear out that thread's GetLastError value and u9.exe is calling GetLastError() to see if errors exist, instead of checking only after a zero return value from ReadFile like it should (it is considered a poorly written game). If Wine doesn't clear out GetLastError correctly, it could cause an alternate code path to run under Wine in which the cursors are believed not to be loaded properly. Notably, that same file handle seems to be used correctly later on: (0xac is bitmap16.flx) 0009:Call KERNEL32.SetFilePointer(000000ac,01e3dcc0,00000000,00000000) ret=005de4c9 0009:Ret KERNEL32.SetFilePointer() retval=01e3dcc0 ret=005de4c9 0009:Call KERNEL32.ReadFile(000000ac,0032f3f4,00000008,0032f3c4,00000000) ret=005de512 0009:trace:file:ReadFile 0xac 0x32f3f4 8 0x32f3c4 (nil) 0009:Ret KERNEL32.ReadFile() retval=00000001 ret=005de512 0009:Call KERNEL32.GetLastError() ret=005de518 0009:Ret KERNEL32.GetLastError() retval=00000000 ret=005de518 Or is that am incorrect assumption? Any ideas? On 03/24/2014 06:27 PM, Ken Thomases wrote: > On Mar 24, 2014, at 7:48 PM, Christopher Thielen wrote: > >> Using WINEDEBUG=+all, the resource in question (static/bitmap16.flx) is loaded via kernel32's CreateFile, ReadFile. >> >> Is there a way to trace only kernel32 calls dealing with a specific file handle? I'm curious if there are any failed reads. Does that seem like a reasonable next step? > > Not really. You'll want to use a +file log and follow the handle as it's passed to subsequent calls. It might also be necessary to use +tid,+relay to see all uses if Wine isn't logging the handle in all relevant functions. > > Certainly, look for failed reads, but I wouldn't expect that unless you think the file is damaged vs. what's installed on Windows. More likely, the game requires external help interpreting the data that is has read, like a compression or image library. If that's not present or is incomplete in Wine, then that would explain the problem. The +tid,+relay log may help to identify what the program does next after it has read the data in. > > -Ken >

April 22, 2014

Re: [PATCH] vbscript: Implemented IsNumeric

by Marvin

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=6508 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found

April 22, 2014

Wine Talks at LinuxTag 2014

by Michael Stefaniuc

Hello guys, here are the two Wine related talks that got accepted for LinuxTag 2014: Pipelight: Windows Plugins in Linux Browsers by Michael Müller (Pipelight-Team), Sebastian Lackner (Pipelight-Team), Erich Hoover (Pipelight-Team) Thursday, 8th May, Stage E, 18:30-19:15 CEST (UTC+2) http://www.linuxtag.org/2014/de/programm/vortragsdetails/?eventid=1342 Is Wine Still Relevant? - A Status Update on Wine by Michael Stefaniuc (Wine Project) Friday, 9th May, Stage C, 16:00-16:45 CEST (UTC+2) http://www.linuxtag.org/2014/de/programm/vortragsdetails/?eventid=2532 bye michael

April 22, 2014

Fwd: [draft patch] atl100/tests: Added more tests for AtlAxWin{, Lic} procedure.

by Qian Hong

Hi, A lot of thanks to Nikolay and Jacek for many comments and suggestions :) While working on tests, I found some differences between atl80 and atl100: --- snip --- + ok(wndproc[0] == wndproc[1], "expected same proc!\n"); --- snip --- - On atl80, wndprocs are different for class AtlAxWin80 and class AtlAxWinLic80, however, wndprocs are the same for class AtlAxWin100 and class AtlAxWinLic100. --- snip --- + hwnd = CreateWindowW(cls_names[i], NULL, 0, 100, 100, 100, 100, NULL, N ULL, NULL, NULL); + ok(hwnd != NULL, "CreateWindow failed!\n"); + control = (IUnknown *)0xdeadbeef; + res = AtlAxGetControl(hwnd, &control); + todo_wine ok(res == E_FAIL, "AtlAxGetControl failed with res %08x\n", res); --- snip --- - On atl80, CreateWindow with NULL window name or empty name, then call AtlAxGetControl, result is S_OK. On atl100, the same test show that result is E_FAIL. control is NULL in both situation. We've already shared source between different atl version, so it would be annoying to change the code to match different edge case on different version of atl. As far as now, I can't find any real world app depends on any of the above different edge result, so I guess we'd better follow what atl100 does even in atl80 code, would we? Thanks for any comments. --- dlls/atl100/tests/atl.c | 159 ++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 147 insertions(+), 12 deletions(-)

April 22, 2014

Re: [patch]Japanese Translation for Wine 1.7.17(try 2)

by Akihiro Sagawa

On Mon, 21 Apr 2014 05:56:33 -0400 (EDT), Toshiaki Hirose wrote: > From ce340a6aff2f17d41b35c217692ece6abb17d88e Mon Sep 17 00:00:00 2001 > From: Toshiaki Hirose <t_hirose(a)aol.com> > Date: Sun, 20 Apr 2014 13:34:34 +0900 > Subject: [PATCH] Japanese Translation for Wine 1.7.17 > > --- > po/ja.po | 59 ++++++++++++++++++++++++++++++++++++----------------------- > 1 file changed, 36 insertions(+), 23 deletions(-) Hello Hirose-san, Welcome to Wine development! I'm one of Japanese translation contributors of Wine. About your patch, it looks good at first glance. But, I found some (nit-picking) issues on that. Could you read the comments and give us your feedback? > @@ -1,18 +1,20 @@ > # Japanese translations for Wine > +# Toshiaki Hirose <t_hirose(a)aol.com>, 2014. I'm not sure this change is needed. Please keep it simple. > -"PO-Revision-Date: 2013-12-05 20:08+0900\n" > -"Last-Translator: Akira Nakagawa <matyapiro31(a)yahoo.co.jp>\n" > -"Language-Team: 日本語 <>\n" > +"PO-Revision-Date: 2014-04-20 11:53+0900\n" > +"Last-Translator: Toshiaki Hirose <t_hirose(a)aol.com>\n" > +"Language-Team: 日本語 < kobayashi-ubuntu(a)junkobayashi.jp >\n" The Language Team's e-mail address seems not valid, i.e. Jun Kobayashi is a male Japanese name. Did you get his approval? > "Language: Japanese\n" > "MIME-Version: 1.0\n" > "Content-Type: text/plain; charset=UTF-8\n" > "Content-Transfer-Encoding: 8bit\n" > "Plural-Forms: nplurals=1; plural=0;\n" > +"X-Generator: Gtranslator 2.91.6\n" I'm not sure about this, too. > @@ -11682,54 +11684,65 @@ msgid "" > " [/n] Do not call DllRegisterServer. This option must be used with [/i].\n" > "\n" > msgstr "" > +"用法:\n" > +" regsvr32 [/u] [/s] [/n] [/i[:cmdline]] Dll名\n" > +"\n" > +"オプション:\n" > +" [/u] サーバを登録消去\n" Please use a sentence form here, e.g. 「～消去します。」. Because original text is sentence. > @@ -11682,54 +11684,65 @@ msgid "" > " [/n] Do not call DllRegisterServer. This option must be used with [/i].\n" > "\n" > msgstr "" > +"用法:\n" Please translate `Usage' into 「使い方」 to keep consistency with other translations. For instance, see hostname.rc:30. > +" regsvr32 [/u] [/s] [/n] [/i[:cmdline]] Dll名\n" > +"\n" > +"オプション:\n" > +" [/s] サイレントモード (一切のメッセージが表示されません)。\n" Please insert a space character between adopted compound word, i.e. サイレントモード. This point based on MS's Japanese style guide [1] at the last line in p.19. [1] http://download.microsoft.com/download/B/3/4/B34F7185-AFCA-4846-8FBF-672A1B… > +" [/i] DllInstallを呼び出し、追加の[cmdline]をパスします。\n" I think 「パス」 is not commonly used in this case. > +"\t[/u]を付けて使った場合、DllInstallはアンインストールモードで呼び出されま" > +"す。 \n" Same as 「サイレントモード」 case. (compound word) > #: regsvr32.rc:41 > msgid "" > "regsvr32: Invalid or unrecognized switch [%1]\n" > "\n" > msgstr "" > +"regsvr32: 無効な選択または認識できない選択です[%1]\n" > +"\n" In my opinion, 「選択」 is not widely used in this situation. How about to use 「スイッチ」 instead? > #: regsvr32.rc:43 > msgid "regsvr32: %1 not implemented in DLL '%2'\n" > -msgstr "" > +msgstr "regsvr32: %1はDLL '%2'内で実装されていません。\n" Can you remove the last 「。」? As original text doesn't have full-stop character. > #: regsvr32.rc:44 > #: regsvr32.rc:45 > #: regsvr32.rc:46 > #: regsvr32.rc:47 > #: regsvr32.rc:48 > #: regsvr32.rc:49 > #: regsvr32.rc:50 > #: regsvr32.rc:51 Same as above. If you would like to contact me, please e-mail to me. Of course, I can understand Japanese. However, in wine development, I prefer open discussion on wine-devel mailing list. Regards, Akihiro Sagawa

April 22, 2014

Re: Fixing conflicts between WineD3D and WGL

by Ken Thomases

On Apr 21, 2014, at 12:42 PM, Henri Verbeet wrote: > On 21 April 2014 17:49, Ken Thomases <ken(a)codeweavers.com> wrote: >> While implementing support for full-screen surfaces in the X11 driver, it became clear that I needed a reference to the wined3d device window or, more generally, the window for which the surface is a substitute. This is necessary to manage focus since the full-screen window has to have X focus but the Win32 focus needs to remain with the device window. >> >> Because of that, the function wglCreateSurfaceWINE() now takes a proxy window parameter. This feels like an ugly kludge but I didn't find a cleaner alternative. I'd be happy to discuss the X windowing issues that I feel lead to this requirement with anybody who may have better ideas. >> > I'll admit to only having looked over the implementation very briefly > so far, but are we quite sure we need a separate X window for this? Good question. It's not a slam dunk that we do. We would at least need a separate X window as a child of the device window's whole_window. This much would be just like how it works without my patches or for window surfaces with my patches. We need that separate X window because any given surface may have a different pixel format, and thus X visual, from other surfaces or the Win32 window using normal WGL. Likewise, the swap interval is a property of the drawable, so surfaces and the window should have separate drawables from each other. After that, we'd need to alter the properties of the existing X window to decouple it from the Win32 properties so it can be a full-screen window without the undesirable changes to its Win32 styles, etc. This might require even more invasive hooks into all of the existing window and event functions. Or it might be cleaner. (Certainly, it would be cleaner in terms of focus management.) It's worth investigating. I hadn't considered this approach. I'll take a look. Thanks, Ken

April 21, 2014

Re: Fixing conflicts between WineD3D and WGL

by Henri Verbeet

On 21 April 2014 17:49, Ken Thomases <ken(a)codeweavers.com> wrote: > While implementing support for full-screen surfaces in the X11 driver, it became clear that I needed a reference to the wined3d device window or, more generally, the window for which the surface is a substitute. This is necessary to manage focus since the full-screen window has to have X focus but the Win32 focus needs to remain with the device window. > > Because of that, the function wglCreateSurfaceWINE() now takes a proxy window parameter. This feels like an ugly kludge but I didn't find a cleaner alternative. I'd be happy to discuss the X windowing issues that I feel lead to this requirement with anybody who may have better ideas. > I'll admit to only having looked over the implementation very briefly so far, but are we quite sure we need a separate X window for this?

April 21, 2014

Re: Fixing conflicts between WineD3D and WGL

by Ken Thomases

(Resending with a download link instead of an attachment. The previous attempt got dropped due to its size. Apologies if anybody gets duplicates.) Hi, I now have a nearly complete implementation of the WGL_WINE_surface extension for both the X11 and Mac drivers. A tarball of patches is available from <http://www.codeweavers.com/xfer/ken/wgl_wine_surface/wgl_surface.tar.bz2>. You'll have to enter an access key, "wgl_wine_surface" (without the quotes). While implementing support for full-screen surfaces in the X11 driver, it became clear that I needed a reference to the wined3d device window or, more generally, the window for which the surface is a substitute. This is necessary to manage focus since the full-screen window has to have X focus but the Win32 focus needs to remain with the device window. Because of that, the function wglCreateSurfaceWINE() now takes a proxy window parameter. This feels like an ugly kludge but I didn't find a cleaner alternative. I'd be happy to discuss the X windowing issues that I feel lead to this requirement with anybody who may have better ideas. There are some minor rough edges to the implementation. In particular, in any desktop environment view of all windows (e.g. Exposé or Mission Control on OS X, the Alt-Tab switcher on Linux, etc.) both the device window and the window for the full-screen surface will appear. The device window is likely to be blank because the rendering is happening in the full-screen surface window. On the other hand, the full-screen surface window will not have a title or an icon, while the device window will. There's a bit of split personality there, which may be confusing. If the user attempts to switch to the device window, the full-screen window should take focus, instead. So, the user should get the desired result and the problem should be merely cosmetic. I have not had the opportunity to test this on Linux. It's possible that some window managers will fight my attempt to redirect focus like that. I believe I can hide the device window and also copy its title and icon to the full-screen window, which will resolve this. (The device window will only be hidden on the X or Cocoa side. From a Win32 perspective, it will still be visible.) Other than those rough edges, the main thing holding me back from just submitting these patches is the lack of testing. I would greatly appreciate if folks would give these patches a test and report any issues they introduce. Things to test, specifically: * Of course, that they don't break Direct3D games in general. Things that used to work still work. * They should fix regressions introduced by my commit 4c4552c5, such as bugs 35718, 35975, and 35950. * They shouldn't have much performance impact other than those regressions. There may be a slight performance improvement since they allow wined3d to skip some housekeeping. * Full-screen games are actually full-screen, appearing in front of other apps, docks, panels, menus, taskbars, etc. * But you can switch to another app as well/easily as you could without these patches. Full-screen games don't take over your whole display such that you can't escape without drastic measures. * After switching away, you can switch back successfully. * Switching, especially repeated switching, among full-screen resolutions and between full-screen and windowed modes works. * Mouse input works as expected. In particular, clicks are not offset from where the cursor appears to be, especially after switching resolutions or between windowed and full-screen modes. * Keyboard input works as expected. The use of input methods such as for Chinese, Japanese, or Korean especially needs testing. * With the X11 driver, games behave properly in virtual desktop mode, in both windowed and full-screen modes. * In windowed mode, resizing the window works properly. If you suspect the patches have introduced a bug, please be sure to double-check that the bug doesn't exist in unpatched Wine. Once you're sure, please report it as a reply to this thread or a reply directly to me. Thanks very much, Ken

April 21, 2014

Re: mshtml: Added IHTMLTable::width property implementation.

by Qian Hong

> + nsres = VarR8FromStr(str, 0, 0, &width); > + if (nsres == S_OK){ Also it's not correct or at least not good to use nsresult sres here, HRESULT hres is better, I don't think we want to share the same variable for nsresult and HRESULT type. -- Regards, Qian Hong - http://www.winehq.org

April 21, 2014

Re: [PATCH 1/4] msvcrt: Don't raise exception in _invalid_parameter (try2)

by Piotr Caban

On 04/21/14 14:20, Marvin wrote: > 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=6473 > > Your paranoid android. > > > === wxppro (32 bit misc) === > misc.c:335: Test failed: buf = C:\Documents and Settings\winetest\My Documents\msvcrt_test.exe misc popen > misc.c:338: Test failed: _pclose returned 1, expected 0x37 > > This test failures are unrelated to my patch. I've already sent a fix for it (http://source.winehq.org/patches/data/104092)

April 21, 2014