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

Re: mshtml: Added IHTMLTable::width property implementation.
by Jacek Caban April 2, 2014

April 2, 2014

Hi Zhenbo, On 03/31/14 16:26, Zhenbo Li wrote: > As my test case shows, windows would truncate float numbers. > I considered VarInt() in oleaut32.dll, but I think to declare > var2str_length() is more clear. +static HRESULT var2str_length(nsAString *nsstr, const VARIANT *p) +{ + static WCHAR buf[64]; + static const WCHAR formatW[] = {'%','d',0}; + LONG width; + + switch(V_VT(p)) { + case VT_BSTR: + return nsAString_Init(nsstr, V_BSTR(p)); + case VT_R8: + width = (LONG)(V_R8(p)); + break; + case VT_R4: + width = (LONG)(V_R4(p)); + break; + case VT_I4: + width = V_I4(p); + break; + default: + FIXME("unsupported arg %s\n", debugstr_variant(p)); + return E_NOTIMPL; + } + sprintfW(buf, formatW, width); + return nsAString_Init(nsstr, buf); +} I would like to see this more generic. How about having var_to_nsstr? It seems to me that we don't really have to convert floats here. Gecko and/or getter may do that instead. If we really have to it here, then some sort of flags controlling helper behaviour on floats may be cleaner. + nsAString val; + HRESULT nsres; nsresult and HRESULT, although are very similar, are two different things and should not be mixed. + DOUBLE width; + + TRACE("(%p)->(%p)\n", This, p); + nsAString_Init(&val, NULL); + nsres = nsIDOMHTMLTableElement_GetWidth(This->nstable, &val); + + V_VT(p) = VT_BSTR; + nsres = return_nsstr(nsres, &val, &V_BSTR(p)); Please don't use return_nsstr this way. It's a strange helper with unusual behaviour in terms of freeing input parameters to make common Gecko wrapping functions cleaner. Using this for string conversion looks bad. Esp in this case, where it adds unneeded BSTR allocation in cases where the string is converted to int later. However, see bellow first. + if (nsres != S_OK) + return nsres; + + nsres = VarR8FromStr(V_BSTR(p), 0, 0, &width); + if (nsres == S_OK){ + VariantClear(p); + V_VT(p) = VT_I4; + V_I4(p) = (LONG)width; + } + return S_OK; +#define cmp_length(a,b) _cmp_length(__LINE__,a,b) +static void _cmp_length(unsigned line, VARIANT got, const char * exstr) +{ + static char buf[64]; + ok_(__FILE__,line) (V_VT(&got)==VT_BSTR || V_VT(&got)==VT_I4, + "V_VT is %hu, expected VT_BSTR(%hu) or VT_I4(%hu)\n", + V_VT(&got), VT_BSTR, VT_I4); + + if (V_VT(&got) == VT_BSTR){ + ok_(__FILE__,line) (!strcmp_wa(V_BSTR(&got), exstr), + "Expected %s, got %s\n", exstr, wine_dbgstr_w(V_BSTR(&got))); + } + else { + sprintf(buf, "%d", V_I4(&got)); + ok_(__FILE__,line) (!strcmp(buf, exstr), + "Expected %s, got %d\n", exstr, V_I4(&got)); + } +} This test should be stricter. You decide on the way to compare based on the value you received. This means that if the implementation always returns VT_BSTR, this will success as well. In fact, my quick testing suggests that native IE always returns string in this case. Also, please consider using more targeted helper so that test would look like: test_table_width(table, "11"); Thanks, Jacek

2 2

Re: [PATCH 3/3] winex11: Remove unused X11DRV_GET_DRAWABLE and struct x11drv_escape_get_drawable.
by Ken Thomases April 2, 2014

April 2, 2014

On Mar 31, 2014, at 9:47 PM, Ken Thomases wrote: > --- > dlls/winex11.drv/init.c | 8 -------- > dlls/winex11.drv/x11drv.h | 9 --------- > 2 files changed, 17 deletions(-) > > <0003-winex11-Remove-unused-X11DRV_GET_DRAWABLE-and-struct.patch> Was there something wrong with this? Is it anticipated that the GET_DRAWABLE escape will be needed in the future? -Ken

2 2

Re: [PATCH] po: Update Russian translation
by Dmitry Timoshkov April 2, 2014

April 2, 2014

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +" [/u] Разрегистрировать сервер.\n" This sounds very unusual, original Windows translation provides a much better wording: "/u - Отменяет регистрацию DLL". > +" [/s] Тихий режим (сообщения не выводятся).\n" Windows translation adds the quotes around "Тихий" in order to emphasize that this has nothing to do with sound. -- Dmitry.

2 4

how to use ced1401 linux driver from wine application ?
by Alois Schlögl April 1, 2014

April 1, 2014

Hi, I'm trying to connect through wine the CED1401 device which is connected through USB. There is a driver in the linux staging tree, (linux-source-3.10/drivers/staging/ced1401/), which I've already compiled into my kernel. The module loads fine and becomes available when connecting to the device. The are several application software for Windows (e.g. ced1401 [1], Spike [2], Signal5, and we have also one running in Igor Pro). The software runs also on Wine, but fails to identify the connected hardware device. I've tried to find relevant information in the wiki; and especially, http://wiki.winehq.org/USB as well as wine developer guide, Chapter 8 Kernel modules. I've a rough idea what is missing, but would like asking what you think is missing, and how much effort it would take to get this working ? --Alois [1] http://appdb.winehq.org/objectManager.php?sClass=application&iId=15958 [2] http://appdb.winehq.org/objectManager.php?sClass=application&iId=9146

2 4

Re: [PATCH] mshtml: Implemented numeral parsing in get_frame_by_name.
by Austin English April 1, 2014

April 1, 2014

On Tue, Apr 1, 2014 at 12:45 PM, Qian Hong <qhong(a)codeweavers.com> wrote: > Hi all, > > When passing a numeral like string as array index to the window object, > native IE correctly parses the string into an integer value while Wine > doesn't. This patch fix the problem. Here is one simply test case: > > Testcase: > 1 <html> > 2 <body> > 3 </body> > 4 <script type="text/javascript"> > 5 var iframeEl = document.createElement('iframe'); > 6 document.body.appendChild(iframeEl); > 7 document.write(window["0"]); //buggy in Wine builtin iexplore > 8 </script> > 9 </html> > > In theory this patch need some more tests, because the above test case is > far from perfect, fortunately we have the open source ECMAScript 3 > Conformance Test Suite ver. 0.2: > http://kangax.github.io/sputniktests-webrunner/ > > Before this patch, Wine builtin iexplore hangs on the first test case of > the ECMAScript 3 Conformance Test Suite, after the patch, the Conformance > Test Suite begin to run. Guess how far does it gone? To everyone's > surprise, now Wine builtin iexplore passes all 5228 tests in the test case: > > Current test: > 15_Native_ECMA_Script_Objects/15.11_Error_Objects/15.11.4_Properties_of_the_Error_Prototype_Object/S15.11.4_A4 > Tests completed: 5228 > Total errors: 0 > Total failures: 0 > Elapsed time: 7:40 > Status: Completed. Final score (errors + failures; less is better): 0 > > > This is definitely a great step of our Wine buitin iexplore, now our > version beats Microsoft IE7 a lot. > > Since now all ECMAScript 3 conformance tests passed, it is safe to assume > that this patch is absolutely correct and no extra test cases needed, so > I'm not going to contribute any C test case for it into our test framework > because it is just duplicate work and waste of time - What can you worry if > even the whole test suite passed? > Hi Qian, The tests are partially there to prove the implementation is correct, yes, but they are also there to prevent regressions. Someone in the future changing dlls/mshtml may not run those same tests and things will break, if there is a unit test in dlls/mshtml/tests, that is not the case. Cheers, Austin

1 0

Re: [2/2] shell32/tests: Mark some test results as broken.
by Marvin April 1, 2014

April 1, 2014

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=6106 Your paranoid android. === w2000pro (32 bit shlexec) === shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 === wxppro (32 bit shlexec) === shlexec.c:1220: Test failed: expected 1 args, got 4 === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtE989.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtE989.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1541: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtE989.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1573: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtE989.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtE989.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtE989.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1541: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtE989.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1573: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtE989.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtE989.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtE989.tmp\wtE99A.tmp" Exec") WaitForSingleObject returned 258

1 0

Re: [1/2] shell32/tests: Remove todo handling from DDE tests.
by Marvin April 1, 2014

April 1, 2014

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=6105 Your paranoid android. === w2000pro (32 bit shlexec) === shlexec.c:2430: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2430: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2430: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2430: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2430: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2430: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 === wxppro (32 bit shlexec) === shlexec.c:1211: Test failed: expected 1 args, got 4 shlexec.c:2272: Test failed: argcA expected 5, but got 4 === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtC8C2.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtC8C2.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1532: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtC8C2.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1564: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtC8C2.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtC8C2.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtC8C2.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1532: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtC8C2.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1564: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtC8C2.tmp\test file.shlexec.noassoc', but key not found or empty

1 0

Wine GPU decoding
by Michael Müller April 1, 2014

April 1, 2014

Hi, it is probably still a bit early, but nevertheless I would like to announce a feature I am currently working on and present you the first results. As some of you have already noticed (http://bugs.winehq.org/show_bug.cgi?id=35868) I've recently submitted some simple stub patches to add the dxva2 dll. The original purposes was to get a browser plugin working, which expects that this library is available, and otherwise refuses to run. The library exports some functions which are used by several applications (like VLC, Flash, Silverlight, ...) for GPU decoding. I started to work to on these functions and I want to present you a first result which you can see here: https://dl.dropboxusercontent.com/u/61413222/dxva2.png This is actually the windows version of VLC playing a MPEG2 movie with GPU acceleration using DXVA2. My implementation of dxva2 uses the VAAPI on Linux to do the actual gpu decoding and should support AMD, Intel and NVIDIA cards. Currently only MPEG2 decoding is supported as it is one of the easier codecs and other ones like H264 needs a lot more of buffers, which need be translated from the DXVA format to VAAPI. The second easiest codec to implement would be mpeg4 but as none of my graphic cards support mpeg4, I will most probably continue with VC-1. Anyway, I need to clean up the patches a bit as they add about 3000 new lines of code and test it with some other graphic cards before I can provide them, but there are also some problems, mostly d3d9 related, for which I would like to get your opinion. The most difficult part is that DXVA2 is completely based on Direct3D9Device and Direct3DSurface9. The DXVA2 places the output images into a Surface and the applications locks the surface to get the output data or simply presents it to the screen. Although it would be much more efficient to directly blit the data in the graphic card at least VLC reads it back into system memory as the decoding and output pipeline are separated. The problem is that I actually need to allocate twice the amount of memory for decoding. since I need to provide the Direct3D Surfaces to the application and I also need to provide buffers to VAAPI. This is not a big problem for mpeg2 since it only uses 3 output images as a B Frame can only reference the last and the next frame. Anyway, for H264 this is getting insane as it requires to store up to 16 output images so that i would need to allocate 16 VAAPI buffers and 16 Direct3D surfaces. Currently i lock both kind of buffers after rendering a frame and do the synchronization in system memory, which is kind of inefficient depending on the surface type. My original idea was to do the copy in the graphic card as I can copy the image to a texture after decoding, but after Sebastian implemented this part we found out that the VAAPI implies a format conversion to RGB when copying data to a texture. This is actually a no go since VLC will refuse to use hardware acceleration when the output format is RGB. I also think it is kind of stupid to convert the RGB data back to YUV so that we end up with 3 color coder conversion (YUV->RGB->YUV->RGB). Some Intel developer wrote (see vaCopySurfaceGLX() at http://markmail.org/message/a3sav6q3dm5qvmat) that it would be possible to implement a copy in NV12 format for NVIDIA and Intel but not AMD. We could try to ask them to implement it, so that we can at least do it efficient for these two vendors. Anyway, if other applications continue to copy the data back to system memory it might be better to instead wrap the VAAPI buffers as Direct3D9 surfaces so that we can directly map the VAAPI buffers when LockRect() is called instead of copying the data. Though this would imply problems when the applications tries to pass this interface to Present(). So what do the wined3d guys think? Is it better to convince the Intel developers to allow a copy in YUV format and copy the data directly into the texture of an Direct3D9 surface or wrap the VAAPI buffers as Direct3D9Surface and add some glue code when an applications tries to render it? Or do you have any better ideas? Regards, Michael

4 8

RE: [PATCH] regsvr32: Fix some usage message issues
by Hugh McMaster April 1, 2014

April 1, 2014

On Tuesday, 1 April 2014 4:34 PM, Nikolay Sivov wrote: > - regsvr32 itself is not a server or service > - it doesn't unregister a module from a server, module IS a server in this context The actual executable in XP and W7 describes itself a "registration server". But I'm happy to go with this change if you believe it is appropriate. There is also the RC define to consider: #define WINE_FILEDESCRIPTION_STR "Wine Register Server" >When used with [/u], regsvr32 also calls DllInstall in uninstall mode.\n > - there's no such thing as 'DLL Uninstall', same DllInstall call is used in both cases This is true; Lauri Kenttä raised that point in this post: http://www.winehq.org/pipermail/wine-devel/2014-March/103671.html In the following discussion, Lauri and Austin English chose to remove the additional reference to 'regsvr32' and 'also'. The preferred option was this text: [/i] Call DllInstall, passing an optional [cmdline]. When used with [/u], calls DllInstall to uninstall the DLL. Of course, your change reflects the original dialog: When used with [/u], regsvr32 also calls DllInstall in uninstall mode. Perhaps you could change it to: When used with [/u], calls DllInstall in uninstall mode. I'm not sure which option would be preferred. Free free to patch using the dialog from the linked thread.

2 2

Re: [1/6] widl: Pass type attributes from write_array_tfs to write_pointer_description. Resend.
by Alexandre Julliard April 1, 2014

April 1, 2014

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This allows to differentiate strings and write appropriate rpc type > (FC_C_C[W]STRING instead of FC_[W]CHAR). > > This version of the patch limits write_array_tfs() to pass attributes > to write_pointer_description() only for strings and avoids unwanted > changes to other pointer types. > > In order to test changes in the widl generated code under Windows > and make sure that widl generates the correctly working code I had > to compile widl with PSDK tools. This way I was able to test both > 32-bit and 64-bit generated code. All the patches in this sequence > have been tested under Windows as well as under Wine in both 32-bit > and 64-bit builds of the rpcrt4 Wine tests. It's also failing in 32-bit now (with the whole series applied): ../../../tools/runtest -q -P wine -T ../../.. -M ieframe.dll -p ieframe_test.exe.so ie && touch ie.ok ie.c:154: Test failed: FindConnectionPoint failed: 800706ba ie.c:177: Test failed: get_Visible failed: 800706ba ie.c:181: Test failed: put_Visible failed: 800706ba ie.c:185: Test failed: get_Visible failed: 800706ba ie.c:186: Test failed: Visible = 800706ba ie.c:189: Test failed: put_Visible failed: 800706ba ie.c:199: Test failed: Could not get IServiceProvider iface: 80004002 wine: Unhandled page fault on read access to 0x00000000 at address 0x6862ae92 (thread 0009), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

1 0