January 2011 - Wine-devel - list.winehq.org

Re: Wine: Downgrade lack of libxslt from configure warning to notice.
by Marcus Meissner 23 Jan '11

23 Jan '11

On Wed, Jan 19, 2011 at 11:37:17PM +0100, Gerald Pfeifer wrote: > On Sat, 28 Jun 2008, Gerald Pfeifer wrote: > > [ Still running into this, and compared to the others where we only > > use WINE_NOTICE_WITH, like CUPS or HAL this really seems very low > > importance. ] > > > > On a test system of mine which does not feature too many packages I am > > getting the following: > > > > configure: libsane development files not found, scanners won't be supported. > > configure: libgphoto2 development files not found, digital cameras won't be supported. > > configure: libldap (OpenLDAP) development files not found, LDAP won't be supported. > > configure: libcapi20 development files not found, ISDN won't be supported. > > configure: WARNING: libxslt development files not found, xslt won't be supported. > > > > Looking that libxslt only seems to be used by msxml3, I am wondering > > whether this really is worth a warning? > > > > How about the patch below? > > So I found this older patch of mine in a TODO folder and am wondering > whether it can be considered. It not, that's fine too and I'll remove > it over here; an explicit NACK would be nice in that case. As libxslt missing reduces the msxml3 functionality it is definitely worth a warning. Ciao, Marcus

1 0

USB architecture: driver loading question
by Damjan Jovanovic 23 Jan '11

23 Jan '11

Hi There's essentially 2 ways USB could work in Wine[1]: 1. Process per driver, but special-case loading and initializing USBD.SYS Like my previous patchset: http://www.winehq.org/pipermail/wine-patches/2010-November/095883.html http://www.winehq.org/pipermail/wine-patches/2010-November/095884.html 2. Dedicated process for USB, in which USBD.SYS loads first, and it loads USB device drivers (possibly > 1) into the same process as the need arises. What's the right way? Which approach is going to get my patches accepted? Thank you Damjan [1] Because the steps are as follows: 1. USB device is plugged in 2. USB hub driver looks up the driver based on the device class/vendor/product IDs 3. The device driver gets loaded and DriverEntry() gets called on it 4. AddDevice() gets called on the driver, specifying the device 5. Only then, the driver calls things lower in the stack, to do USB I/O The driver needn't load any other driver in its DLL import table, and even if it did, drivers loaded through the import table don't have their DriverEntry() called, so they cannot do anything on load. Even if we rely on most USB drivers loading USBD.SYS, USBD.SYS needs to do steps 1-4 first, but it wouldn't have control passed to it until step 5, hence it can't ever do anything. The only way out is one of the following: 1. Process-per-driver, but when a driver loads USBD.SYS, USBD.SYS is special-cased by winedevice, ie. it has a special export called on it at load which specifies the other driver and gives it a chance to create a separate thread for steps 1-4. 2. Dedicated process for USB, in which USBD.SYS loads first, and it loads USB device drivers (possibly > 1) into the same process as the need arises.

1 0

ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 2)
by Loïc Maury 23 Jan '11

23 Jan '11

Hello, I have add comment in the code for the patch. Thank you Loïc --- dlls/ntdll/cdrom.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/dlls/ntdll/cdrom.c b/dlls/ntdll/cdrom.c index 59f85a0..d65850d 100644 --- a/dlls/ntdll/cdrom.c +++ b/dlls/ntdll/cdrom.c @@ -1121,6 +1121,10 @@ static NTSTATUS CDROM_Verify(int dev, int fd) return STATUS_SUCCESS; else return STATUS_NO_MEDIA_IN_DEVICE; +/* At this point, we know that we have media, because in Mac OS X, the + * device file is only created when media is present. */ +#elif defined(__APPLE__) + return STATUS_SUCCESS; #else FIXME("not supported on this O/S\n"); return STATUS_NOT_SUPPORTED; -- 1.7.3.2

2 1

winscard
by vince 22 Jan '11

22 Jan '11

Hi all, I'm back with a smaller and reworked winscard patch. In respond to Vitaly Margolen (http://www.winehq.org/pipermail/wine-devel/2010-September/087017.html) 1. I used configure to get the so name of the library. 2. I removed trailing spaces. 3. When this patch is approved, I will make a new patch for SCardListReadersA. Is this patch ready for wine-patch ? Thanks for your help. Vincent.

2 1

Re: [PATCH 5/5] d3dx9_36/tests: Added tests for ID3DXConstantTable_Set* functions
by Matteo Bruni 22 Jan '11

22 Jan '11

2011/1/20 Travis Athougies <iammisc(a)gmail.com>: > +static void test_setting_basic_table(IDirect3DDevice9 *device) > +{ > + static const D3DXMATRIX mvp = { > + 0.514f, 0.626f, 0.804f, 0.786f, > + 0.238f, 0.956f, 0.374f, 0.483f, > + 0.109f, 0.586f, 0.900f, 0.255f, > + 0.898f, 0.411f, 0.932f, 0.275f}; This throws some warnings here. Apparently you have to put some additional braces around that initializer. + ok(out[0] == (float)iarray[0] && out[4] == (float)iarray[1] && out[8] == (float)iarray[2] && + out[12] == (float)iarray[3], "SetIntArray did not properly set a float array: out={%f, %f, %f, %f}, should" + " be {%d, %d, %d, %d}\n", out[0], out[4], out[8], out[12], iarray[0], iarray[1], iarray[2], iarray[3]); The float casts are unneeded. The tests look generally OK to me otherwise, albeit they are somewhat wordy. Oh, please notice that some tests fail on Windows. The testbot can't create a d3d device so it skips these tests, but on my Win7 box I get this: shader.c:462: Test failed: The first row of mvp was not set correctly, got {0.51 4000, 0.238000, 0.109000, 0.898000}, should be {0.514000, 0.626000, 0.804000, 0. 786000} shader.c:465: Test failed: The second row of mvp was not set correctly, got {0.6 26000, 0.956000, 0.586000, 0.411000}, should be {0.238000, 0.956000, 0.374000, 0 .483000} shader.c:468: Test failed: The third row of mvp was not set correctly, got {0.80 4000, 0.374000, 0.900000, 0.932000}, should be {0.109000, 0.586000, 0.900000, 0. 255000} shader.c:471: Test failed: The fourth row of mvp was not set correctly, got {0.7 86000, 0.483000, 0.255000, 0.275000}, should be {0.898000, 0.411000, 0.932000, 0 .275000} shader.c:530: Test failed: The excess elements of the array were not set correct ly, out={0.000000, 0.000000, 0.000000, 0.000000}, should be {0.010000, 0.020000, 0.030000, 0.040000} shader: 248 tests executed (0 marked as todo, 5 failures), 0 skipped. The matrix seems to have its rows and columns switched (probably this has to do with row-major vs column-major matrix storage - http://msdn.microsoft.com/en-us/library/bb509706%28v=VS.85%29.aspx) So you have to fix your SetMatrixArray implementation to account for that (and update the tests accordingly). The other failing test shows that actually the excess elements are not set, apparently. A last thing. I noticed that you never set the vertex shader in the d3d9 device. I'd say: don't change that. This shows that ID3DXConstantTable doesn't pay attention to the vertex shader currently set and it is responsibility of the application programmer to call these functions with the correct shader program.

3 3

Re: windowscodecs: Disable ICNS support when building for Mac OS X 10.4 Tiger.
by Damjan Jovanovic 22 Jan '11

22 Jan '11

Should we reconsider libicns? Apple's APIs obviously can't be relied upon. On Fri, Jan 21, 2011 at 2:58 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > > For http://bugs.winehq.org/show_bug.cgi?id=25778 > --- > dlls/windowscodecs/icnsformat.c | 6 ++++-- > 1 files changed, 4 insertions(+), 2 deletions(-) > > > > >

4 4

Re: [PATCH 4/5] d3dx9_36: Implemented ID3DXConstantTable_SetMatrix and ID3DXConstantTable_SetMatrixArray
by Matteo Bruni 21 Jan '11

21 Jan '11

2011/1/20 Travis Athougies <iammisc(a)gmail.com>: > + /* D3DXMATRIX is a union, one of whose elements is an array, so it can be cast to a float pointer */ > + if (is_vertex_shader(This->desc.Version)) > + IDirect3DDevice9_SetVertexShaderConstantF(device, desc.RegisterIndex + i, (float *)(matrix + i), > + desc.RegisterCount); > + else > + IDirect3DDevice9_SetPixelShaderConstantF(device, desc.RegisterIndex + i, (float *)(matrix + i), > + desc.RegisterCount); Can't you just pass matrix->m[i] as parameter, instead of that cast?

3 6

Translating a same message used in different contexts
by Akihiro Sagawa 21 Jan '11

21 Jan '11

Hi, I'm one of Japanese translators of Wine. A few weeks ago, Wine's string resources were moved to one po format file. So I started translation about it. And now I face to a problem which is a same msgid text used in different contexts, like "Desktop" used in shell32.rc. One of its contexts is a real path name of a desktop (IDS_DESKTOPDIRECTORY). That is "C:\Users\foo\Desktop"'s Desktop. In other contexts, it makes a localized name (IDS_DESKTOP). That is shown in a common dialog box. In the previous Japanese resource, the former was "Desktop" and the latter was localized. However, in the po file, they merged into one! Therefore we need to distinguish above contexts somehow. But I'm afraid I don't familiar with gettext and wrc. Could someone please resolve this issue? Akihiro Sagawa

3 5

RE: shell32/tests: Add tests for IShellDispatch::NameSpace.
by Greg Geldorp 21 Jan '11

21 Jan '11

> === W7PROX64 (32 bit shelldispatch) === > shelldispatch.c:80: Test failed: bad title I suppose the title here was "Program Files (x86)", it would be good to print the title that you got (using wine_dbgstr_w()). This test will probably fail when running as 32-bit executable on any Windows 64-bit version. I also expect it to fail on some non-English Windows versions (e.g. I think German uses "Programme" instead of "Program Files"). Greg.

1 0

Re: shell32/tests: Add tests for IShellDispatch::NameSpace.
by Marvin 21 Jan '11

21 Jan '11

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 http://testbot.winehq.org/JobDetails.pl?Key=8506 Your paranoid android. === W7PROX64 (32 bit shelldispatch) === shelldispatch.c:80: Test failed: bad title

1 0