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

Re: libwine-print missing when compiling from source

by Alois Schlögl

On 2014-04-02 18:28, Austin English wrote: > On Wed, Apr 2, 2014 at 5:05 AM, Alois Schlögl <alois.schloegl(a)gmail.com>wrote: > >> When compiling wine from source according to instructions on >> http://wiki.winehq.org/Wine64 "Building a shared WoW64 setup (most >> likely what you want)" >> starting Igor Pro fails in the same way, as if libwine-print is not >> installed. >> >> I'm using debian7:x86_64, and IgorPro is working fine when the debian >> version of wine (v1.4.1) with libwine-print is installed. >> >> What do I need to do in order the have libwine-print when compiling wine >> from source ? >> >> >> -- Alois >> > Make sure you have cups (i386 libraries and headers) installed. Also see > http://wiki.winehq.org/WineOn64bit > Yes, I've followed http://wiki.winehq.org/WineOn64bit. Unfortunately cups:amd64 and cups:i386 conflict on debian/wheezy. So I can install one or the other, but not both. The same holds for libcups2-dev (header files). Although libcups2:amd64 and libcups2:i386 are both installed. Alois

April 2, 2014

Re: apphelp: add a stub for SdbInitDatabase (try 2)

by Austin English

On Wed, Apr 2, 2014 at 12:25 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Austin English <austinenglish(a)gmail.com> wrote: > > > + if (path) > > + FIXME("stub: flags: %08x, path: \"%s\". Unexpected, please > report!\n", flags, debugstr_w(path)); > > + else > > + FIXME("stub: %08x %s\n", flags, debugstr_w(path)); > > What's the reason for this if/else? What exactly is not expected and why > this matters for a stub? > > -- > Dmitry. > It's expected to be NULL in practice, I thought it would be helpful for Focht to easily spot future applications that are using this API. It's not necessary for the stub, of course. I can remove and resend if necessary, but I don't think that it is. -- -Austin

April 2, 2014

Re: libwine-print missing when compiling from source

by Austin English

On Wed, Apr 2, 2014 at 5:05 AM, Alois Schlögl <alois.schloegl(a)gmail.com>wrote: > > When compiling wine from source according to instructions on > http://wiki.winehq.org/Wine64 "Building a shared WoW64 setup (most > likely what you want)" > starting Igor Pro fails in the same way, as if libwine-print is not > installed. > > I'm using debian7:x86_64, and IgorPro is working fine when the debian > version of wine (v1.4.1) with libwine-print is installed. > > What do I need to do in order the have libwine-print when compiling wine > from source ? > > > -- Alois > Make sure you have cups (i386 libraries and headers) installed. Also see http://wiki.winehq.org/WineOn64bit -- -Austin

April 2, 2014

libwine-print missing when compiling from source

by Alois Schlögl

When compiling wine from source according to instructions on http://wiki.winehq.org/Wine64 "Building a shared WoW64 setup (most likely what you want)" starting Igor Pro fails in the same way, as if libwine-print is not installed. I'm using debian7:x86_64, and IgorPro is working fine when the debian version of wine (v1.4.1) with libwine-print is installed. What do I need to do in order the have libwine-print when compiling wine from source ? -- Alois

April 2, 2014

Re: [3/6] widl: Avoid generating negative offsets for conformant arrays of strings. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > This version of the patch limits the changes to conformant arrays of > > strings in order to avoid unwanted changes to other pointer types. > > Didn't you say that midl is doing this for all arrays? Why doesn't this > work in our case? No, midl doesn't do that for all types of arrays, I said that before I had compared more carefully what widl and midl generate for the whole dlls/rpcrt4/testss/server.idl. I tried to investigate more deeply what midl does for all kinds of arrays, but that's enourmous amount of work (conformant and varying arrays, strings, pointers of different types, etc.) and I decided to make widl generate working code just for arrays of strings, that's what I need at this point. -- Dmitry.

April 2, 2014

Re: [3/6] widl: Avoid generating negative offsets for conformant arrays of strings. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This version of the patch limits the changes to conformant arrays of > strings in order to avoid unwanted changes to other pointer types. Didn't you say that midl is doing this for all arrays? Why doesn't this work in our case? -- Alexandre Julliard julliard(a)winehq.org

April 2, 2014

Re: [6/6] rpcrt4/tests: Add a couple of tests for marshalling an array of strings. 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=6118 Your paranoid android. === build (build) === Make failed

April 2, 2014

Re: [PATCH] mshtml: Implemented numeral parsing in get_frame_by_name (try 2).

by Qian Hong

Hi Jacek, Thanks for comment, this patch is just a gift for April Day to make you laugh... Actually there are two bugs in Wine's builtin iexplore, I work around one of them and leave the other intentionally, and now every test cases passes - actually passed without running at all :) Unfortunately this joke looks too serious and so far nobody understand it is a joke, it seems like the author of the bad joke should be blamed... I appreciate for any advice to make a better joke in 2015 :) We miss your improvement of HTML5 driver... lol BTW, I don't have time to work on these two bugs right now, hopefully they are interesting enough for you <grin>

April 2, 2014

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

by Jacek Caban

On 04/01/14 05:40, Zhenbo Li wrote: > hank you very much. > > As MSDN says[1], "VARIANT of type VT_I4 or VT_BSTR that > specifies one of the values listed in Possible Values." VT_I4 is easy > to solve, but VT_BSTR is too flexible. >From my (and most Wine developers') experience: don't take MSDN too seriously. It may be treated more like guidelines than a real documentation (or specification). You've just found another example of MSDN being wrong. There are even more obvious mistakes on the page that you quoted like percentage being "Not applicable to C++". > All these usages are legal: > > document.getElementById('table1').width=20.6; //Win IE treats as 20 > document.getElementById('table1').width="20.6"; //Win IE treats as 20 > document.getElementById('table1').width="50.9%"; //Win IE treats as "50.9%" > (You may check my sample HTML code[2]) > > [1]: http://msdn.microsoft.com/en-us/library/aa768621%28v=vs.85%29.aspx > [2]: http://paste.opensuse.org/87682041 You may change appropriate lines to: txt += document.getElementById('table1').width + " of type " + typeof(document.getElementById('table1').width); in your tests to see how those attributes are truly exposed. > 2014-03-31 23:23 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: >> 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) >> >> 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. > I think to make it more generic is a good idea, and it is necessary to define > *how generic* it is. How about this solution? Or to make it more generic, that > what to return is decided by parameters? Error handling needs more thoughts here. Also, we probably don't want to convert floats to ints by default at all. In fact, I would suggest to ignore rounding floats here. Passing float to Gecko will not change much (I'd expect layout engine to behave exactly the same way as if int was passed) and it doesn't guarantee that value exposed by getter will always be int (since there are other, not controlled by us, ways to set the value). If you really want to guarantee that, getter would be a better place (but I'd suggest ignoring this detail for now; I don't expect this to cause problems for real world pages). > (To make this mail shorter, I removed some traces) > > static HRESULT var_to_nsstr(nsAString *nsstr, const VARIANT *p, BOOL truncate) > { > static WCHAR buf[64]; > static const WCHAR formatW[] = {'%','d',0}; > LONG width; > DOUBLE width_r8; > VARIANT var; > HRESULT hres; > > switch(V_VT(p)) { > case VT_BSTR: > hres = VarR8FromStr(V_BSTR(p), 0, 0, &width_r8); > if (hres == DISP_E_TYPEMISMATCH) /* Symbols are in this string */ > return nsAString_Init(nsstr, V_BSTR(p)); > V_VT(&var) = VT_R8; > V_R8(&var) = width_r8; > break; > case VT_I4: case VT_R8: > var = *p; > break; > case VT_R4: > V_VT(&var) = VT_R8; > V_R8(&var) = V_R4(&var); > break; > default: > FIXME("unsupported arg %s\n", debugstr_variant(p)); > return E_NOTIMPL; > } > if (V_VT(&var) == VT_R8) { > if (truncate) width = (LONG)V_R8(&var); > else VarI4FromR8(V_R8(&var), &width); > } > else width = V_I4(&var); > VariantClear(&var); > sprintfW(buf, formatW, width); > return nsAString_Init(nsstr, buf); > } > > >> + nsAString val; >> + HRESULT nsres; >> >> nsresult and HRESULT, although are very similar, are two different things >> and should not be mixed. > Sorry, this is my fault. > >> + 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. > Thank you for mentioning it. Could my new solution be checked? > (I'll add code to check if the pointers are legal before sending my new patch to > wine-patches) No, this should returns a strings as shown by tests. > static HRESULT WINAPI HTMLTable_get_width(IHTMLTable *iface, VARIANT *p) > { > HTMLTable *This = impl_from_IHTMLTable(iface); > nsAString val; > nsresult nsres; > DOUBLE width; > const PRUnichar *str; > > TRACE("(%p)->(%p)\n", This, p); > nsAString_Init(&val, NULL); > nsres = nsIDOMHTMLTableElement_GetWidth(This->nstable, &val); > nsAString_GetData(&val, &str); > nsres = VarR8FromStr(str, 0, 0, &width); > if (nsres == S_OK){ > V_VT(p) = VT_I4; > V_I4(p) = (LONG)width; > } else { > V_VT(p) = VT_BSTR; > V_BSTR(p) = SysAllocString(str); > } > 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. > My test results are the same. But they are not guaranteed in MSDN. > Should I depend on them? Yes, tests are definitely more trustful than MSDN. >> Also, please consider using >> more targeted helper so that test would look like: >> test_table_width(table, "11"); >> > I was not sure about the helper's name. I guess(not tested yet) height > property would > use the same helper. So to call it test_table_width is a good idea? Since this will have to be changed to always assume strings, there won't be much to share with height property (just a check of one string VARIANT). Both solutions are good then. Still, the nice thing about such helpers is that it makes obvious what you mean to test here. Cheers, Jacek

April 2, 2014

Re: [PATCH 3/3] winex11: Remove unused X11DRV_GET_DRAWABLE and struct x11drv_escape_get_drawable.

by Ken Thomases

On Apr 2, 2014, at 2:36 AM, Alexandre Julliard wrote: > Ken Thomases <ken(a)codeweavers.com> writes: > >> 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? > > Not really, but it can be useful for third party code. Why do you want > to remove it? I don't have any strong urge to remove it. I just thought it was dead code and I was cleaning up. I hadn't considered third-party code using it. Thanks for satisfying my curiosity. -Ken

April 2, 2014

Re: [PATCH] po: Update Russian translation

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >>>> +" [/u] Разрегистрировать сервер.\n" > >>> This sounds very unusual, original Windows translation provides a much > >>> better wording: "/u - Отменяет регистрацию DLL". > >> I disagree, there's no such thing as cancelling registration (and that > >> was this translation means). And we already use such wording. I get that > >> it sounds a bit awkward, it mirrors "unregister", and not something > >> that's never used like "cancelling registration". > > Then you need to find another word since "Разрегистрировать" is clearly > > not acceptable as a russian translation. > I'm open to suggestions. One of the possible variants is mentioned above. -- Dmitry.

April 2, 2014

Re: [PATCH] mshtml: Implemented numeral parsing in get_frame_by_name (try 2).

by Jacek Caban

Hi Qian, On 04/01/14 22:08, Qian Hong wrote: > diff --git a/dlls/mshtml/htmlwindow.c b/dlls/mshtml/htmlwindow.c > index a57dfba..3d6323c 100644 > --- a/dlls/mshtml/htmlwindow.c > +++ b/dlls/mshtml/htmlwindow.c > @@ -379,6 +379,20 @@ HRESULT get_frame_by_name(HTMLOuterWindow *This, const WCHAR *name, BOOL deep, H This is not the right place to do it. See callers of the function. I don't think we want that behaviour in, for example, get_target_window. > UINT32 length, i; > nsresult nsres; > HRESULT hres = S_OK; > + VARIANT v, idx; > + > + V_VT(&v) = VT_BSTR; > + V_BSTR(&v) = SysAllocString(name); > + VariantInit(&idx); > + hres = VariantChangeType(&idx, &v, VARIANT_LOCALBOOL, VT_I4); There are better ways to do that conversion, like strtolW. > + VariantClear(&v); > + if (SUCCEEDED(hres)) > + { > + hres = get_frame_by_index(This, V_I4(&idx), ret); > + VariantClear(&idx); > + return hres; > + } > + VariantClear(&idx); Clearing VARIANT of VT_I4 type is not really useful. Also, as Austin said, this definitely needs a test case. You may write that in JavaScript, if you prefer. See existing tests in *.html files. Cheers, Jacek

April 2, 2014

Re: [PATCH] po: Update Russian translation

by Nikolay Sivov

On 4/2/2014 11:02, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >>>> +" [/u] Разрегистрировать сервер.\n" >>> This sounds very unusual, original Windows translation provides a much >>> better wording: "/u - Отменяет регистрацию DLL". >> I disagree, there's no such thing as cancelling registration (and that >> was this translation means). And we already use such wording. I get that >> it sounds a bit awkward, it mirrors "unregister", and not something >> that's never used like "cancelling registration". > Then you need to find another word since "Разрегистрировать" is clearly > not acceptable as a russian translation. I'm open to suggestions. > >>>> +" [/s] Тихий режим (сообщения не выводятся).\n" >>> Windows translation adds the quotes around "Тихий" in order to emphasize >>> that this has nothing to do with sound. >> That would be redundant, first of all a comment in parentheses clarifies >> if. A user of this tool should be able to distinguish between two, if he >> went that far to manually run it. Personally I'm not afraid of double >> meanings like that, you don't use "silent" in quotes too, which is about >> sound too. > "Silent mode" is a widely used term in english (for a program output), > while in russian it sounds funny and not appropriate, that why it needs > the quotes. I don't think it's true. The only difference is that you got used to English variant. > >> I don't think it's important to match exactly what Windows provides in >> case of translations. > This is not about the need to exactly match Windows translation, this is > about avoiding problematic wording and confusion for the end users. Always > considering how others have already solved some kind of a problem and just > following already established standards doesn't violate any copyrights, I'm not talking about copyrights, because I don't know enough about it. I only care about making it better, and Windows translation are not a best example. > of > course if that's not a "not invented here" disease. yeah, yeah.

April 2, 2014

Re: [PATCH 3/3] winex11: Remove unused X11DRV_GET_DRAWABLE and struct x11drv_escape_get_drawable.

by Alexandre Julliard

Ken Thomases <ken(a)codeweavers.com> writes: > 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? Not really, but it can be useful for third party code. Why do you want to remove it? -- Alexandre Julliard julliard(a)winehq.org

April 2, 2014

Re: apphelp: add a stub for SdbInitDatabase (try 2)

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > + if (path) > + FIXME("stub: flags: %08x, path: \"%s\". Unexpected, please report!\n", flags, debugstr_w(path)); > + else > + FIXME("stub: %08x %s\n", flags, debugstr_w(path)); What's the reason for this if/else? What exactly is not expected and why this matters for a stub? -- Dmitry.

April 2, 2014

Re: [PATCH] po: Update Russian translation

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> +" [/u] Разрегистрировать сервер.\n" > > This sounds very unusual, original Windows translation provides a much > > better wording: "/u - Отменяет регистрацию DLL". > I disagree, there's no such thing as cancelling registration (and that > was this translation means). And we already use such wording. I get that > it sounds a bit awkward, it mirrors "unregister", and not something > that's never used like "cancelling registration". Then you need to find another word since "Разрегистрировать" is clearly not acceptable as a russian translation. > >> +" [/s] Тихий режим (сообщения не выводятся).\n" > > Windows translation adds the quotes around "Тихий" in order to emphasize > > that this has nothing to do with sound. > That would be redundant, first of all a comment in parentheses clarifies > if. A user of this tool should be able to distinguish between two, if he > went that far to manually run it. Personally I'm not afraid of double > meanings like that, you don't use "silent" in quotes too, which is about > sound too. "Silent mode" is a widely used term in english (for a program output), while in russian it sounds funny and not appropriate, that why it needs the quotes. > I don't think it's important to match exactly what Windows provides in > case of translations. This is not about the need to exactly match Windows translation, this is about avoiding problematic wording and confusion for the end users. Always considering how others have already solved some kind of a problem and just following already established standards doesn't violate any copyrights, of course if that's not a "not invented here" disease. -- Dmitry.

April 2, 2014

Re: [PATCH 3/3] winex11: Remove unused X11DRV_GET_DRAWABLE and struct x11drv_escape_get_drawable.

by Ken Thomases

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

April 2, 2014

Re: [PATCH] po: Update Russian translation

by Nikolay Sivov

On 4/2/2014 09:37, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> +" [/u] Разрегистрировать сервер.\n" > This sounds very unusual, original Windows translation provides a much > better wording: "/u - Отменяет регистрацию DLL". I disagree, there's no such thing as cancelling registration (and that was this translation means). And we already use such wording. I get that it sounds a bit awkward, it mirrors "unregister", and not something that's never used like "cancelling registration". > >> +" [/s] Тихий режим (сообщения не выводятся).\n" > Windows translation adds the quotes around "Тихий" in order to emphasize > that this has nothing to do with sound. That would be redundant, first of all a comment in parentheses clarifies if. A user of this tool should be able to distinguish between two, if he went that far to manually run it. Personally I'm not afraid of double meanings like that, you don't use "silent" in quotes too, which is about sound too. I don't think it's important to match exactly what Windows provides in case of translations.

April 2, 2014

Re: [PATCH] po: Update Russian translation

by Dmitry Timoshkov

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.

April 2, 2014

Re: how to use ced1401 linux driver from wine application ?

by Vincent Povirk

> Yes, there is documentation and as far as I know there is no secrecy. > > You will find it on this webpage [4]. > Look for "1401 Programming Support". After installation (works fine in wine, > too), you can find these interfaces: > > ~/.wine/drive_c/1401Lang/WinSupp/Use1401.h > ~/.wine/drive_c/1401Lang/WinSupp/Use1432.dll Seems to me your best bet would be to ignore the drivers completely and work on a winelib replacement for Use1432.dll. There shouldn't be any need to run or replace the device driver, as long as the applications you need go through that dll rather than accessing it directly (and both of those options are likely more difficult than replacing a dll). You can use the winedump command to generate a .spec file which you can then use to build a stub dll. See http://www.winehq.org/docs/winelib-guide/bindlls for some information on that. In this case, your interface is dictated to you by the header and dll file, and the corresponding Linux api probably consists of opening a Linux device file and doing ioctl() calls on it. Note that you don't need to implement all or even any functions to use the dll. If a program calls an unimplemented function, the function name will be sent to stderr, and the program will crash. Which is a good way to check whether your programs are using the dll, and which functions you'll need. As you implement them, remember to replace the "stub" lines in your spec file with stdcall lines so they are actually used. Also, if you want to distribute your code, keep in mind there's no license on their header, and you may need to replace it if you don't want a dependency on it. BTW, try1432.exe doesn't appear to use use1432.dll and instead attempts to directly access the device file at \\.\CED1. I tested this by running with WINEDEBUG=+loaddll.

April 1, 2014

Re: [PATCH] mshtml: Implemented numeral parsing in get_frame_by_name.

by Austin English

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

April 1, 2014

Re: how to use ced1401 linux driver from wine application ?

by Alois Schlögl

Forgot to add the link to reference [4]. Here it is: [4] http://ced.co.uk/upu.shtml On 2014-03-31 18:18, Vincent Povirk wrote: > http://wiki.winehq.org/USB is about running Windows USB drivers in > Wine. If you were able to make this work, it would mean that the > native Linux driver isn't involved at all, similar to what would > happen if you connected a USB device to a virtual machine. I've tried this with 1.5.7, 1.4.1, as well as a recent version from the repository (1.7.14+). I tried 1.4.1 with patches from [1]; althought there are a number of steps involved, I'm pretty sure that I've applied them all as described. Especially, exporting and importing the registry entries is not trivial and one could get something wrong. Same with 1.5.7 (but I was not that careful in applying steps). For 1.7.14, there are no patches in [1] that apply in clean way, and I did not apply any. In all cases, result was the same. The application software was running but did not find the connected USB device. [1] ftp://ftp.etersoft.ru/pub/people/amorozov/usb/ [2] http://wiki.winehq.org/Wine64 > > Devices with Linux native drivers can work in Wine without needing to > run a Windows driver, as long as the device is accessed through a > standard and generic Windows API that Wine provides, such as > DirectInput for joysticks. No, that's not applicable here. The application comes with a dll. > > If you have a specialized device for which no generic API exists, > there's no way for Wine to provide access to that device to Windows > programs in a generic way. It can, however, be done in a > device-specific way based on the respective API's for accessing that > device on Linux and Windows. > > How would a Windows software developer access the device you're trying > to use? Is there a specific API (it doesn't have to be included in > Windows) that would allow a Windows developer to target a range of > similar devices? Yes, there is an API, implemented as DLL. See below. > If so, providing an implementation of that API in > Wine is probably the best approach. If not, you'll need to either run > the Windows driver somehow (very difficult, I would guess) or create a > replacement for it (may be much easier, depending on how similar the > Linux and Windows API's are, and how complex they are). My guess is that they are quite similar. > > If you can find some documentation for those interfaces, then we can > talk more specifically about how to provide them in Wine. Yes, there is documentation and as far as I know there is no secrecy. You will find it on this webpage [4]. Look for "1401 Programming Support". After installation (works fine in wine, too), you can find these interfaces: ~/.wine/drive_c/1401Lang/WinSupp/Use1401.h ~/.wine/drive_c/1401Lang/WinSupp/Use1432.dll Another interesting part on page [4] is the link "Windows installation" leading to a download called "winsupp.exe". After installation, you can find several *.sys and *.dll files in .wine/drive_c/1401/WinDrv/ ced_usb.sys and ced_us64.sys are the driver listed in the registry (on 32 and 64 bit windows, resp) after installation. It contains also the program try1432.exe, which is used for testing the connection to the device. -- Alois

April 1, 2014

Re: [2/2] shell32/tests: Mark some test results as broken.

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=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

April 1, 2014

Re: [1/2] shell32/tests: Remove todo handling from DDE tests.

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=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

April 1, 2014

Re: Wine GPU decoding

by Henri Verbeet

On 1 April 2014 16:45, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > to Wine. Some more testing may be needed. If worst came to worst, maybe > allow multiple APIs to be used, though less than ideal, but we have multiple > backends for other features (xrandr / xvidmode). > I expect that at some point CodeWeavers may be interested in having this work on MacOS as well, so in that regard it seems likely that we'll end up with multiple backends.

April 1, 2014