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

Re: msi: Fix infinite loop.

by Hans Leidekker

On Mon, 2014-03-31 at 16:48 -0500, Vincent Povirk wrote: > This loop never exits if progid->Parent == progid and there is no > class. There are other checks for that in the file, so I assume that > condition is supposed to be possible. Right, nothing keeps you from defining circular dependencies.

April 1, 2014

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

by Alois Schlögl

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: [PATCH 1/2] ole32: Fix equality check in CommonPrefixWith() for pointer moniker (try2)

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=6093 Your paranoid android. === wvista (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === wvistau64 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w7pro64 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w8 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === wvistau64 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A === w7pro64 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A

April 1, 2014

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

by Zhenbo Li

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. 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 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? (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) 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? > 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? > > Thanks, > Jacek I really appreciate your suggestion. Thank you very much. -- Have a nice day! Zhenbo Li

April 1, 2014

RE: regsvr32: Replace printf calls with WriteConsole function (try 2)

by Hugh McMaster

On 2014-03-31 03:14, Hugh McMaster wrote: >(3) Call DllInstall, passing an optional [cmdline]. When used with [/u], uses DllInstall to uninstall the DLL. On Mon, Mar 31, 2014 at 7:16 AM, Lauri Kenttä wrote: >I'd go with (1) or (3), optionally replacing "uses" with "calls". (3) is probably the easiest to translate. On Tuesday, 1 April 2014 5:50 AM, Austin English wrote: >(3) is the easiest to understand (to me as a native English speaker), FWIW. Ok. Option (3) it is. The final wording is: [/i] Call DllInstall, passing an optional [cmdline]. When used with [/u], calls DllInstall to uninstall the DLL.

April 1, 2014