March 2011 - Wine-Devel - list.winehq.org

Re: [PATCH] kernel32: Populate HKLM\HARDWARE\DEVICEMAP\Scsi on Mac OS.

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > All right. > > Do you want me to rip out the old Linux /proc/ide and /proc/scsi parsing > code, or do you want to move that over to mountmgr, too? It needs to be redone the proper way in mountmgr, matching the devices we get from HAL. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2011

Re: [3/3] Changing the day of month BEFORE calculating the day of week this time. (try 3)

by Vincent Povirk

And now I screwed up the title. But I'm sure git-am will fix that. On Thu, Mar 31, 2011 at 3:58 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > EVERY TIME I have to do anything different I forget to attach the patch. >

March 31, 2011

About Wine/Gecko/MSHTML

by Artem S. Tashkinov

Hi, I have no idea to what extent and how Mozilla's Gecko library is being used in Wine (all I know is that it's used in Wine's MSHTML component), but recently a Mozilla developer made a very unsettling announcement: groups dot google dot com/d/topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion I wonder if this announcement has any adverse effects on Wine's future. Best wishes, Artem

March 31, 2011

Re: [PATCH] kernel32: Populate HKLM\HARDWARE\DEVICEMAP\Scsi on Mac OS.

by Charles Davis

On 3/30/11 2:53 AM, Alexandre Julliard wrote: > Charles Davis <cdavis(a)mymail.mines.edu> writes: >> How do you propose to do that? The way this is done on Linux, it's >> probably fine to just build up/tear down an entry for each device that >> HAL/udev detects, but DiskArbitration only handles disks (and not other >> types of SCSI devices) on Mac. > > I don't think we care about other types of devices at this point. All right. Do you want me to rip out the old Linux /proc/ide and /proc/scsi parsing code, or do you want to move that over to mountmgr, too? Chip

March 31, 2011

Re: d3dx9_36 [patch 2/2]: Add tests for D3DXCreateBox

by David Adam

2011/3/31 Matteo Bruni <matteo.mystral(a)gmail.com> > 2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: > > > > > > 2011/3/31 Matteo Bruni <matteo.mystral(a)gmail.com> > >> > >> 2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: > >> > > >> > + /* Check the width */ > >> > + v1 = *((D3DXVECTOR3*)(data+19*num_bytes_per_vertex)); > >> > + v2 = *((D3DXVECTOR3*)(data+18*num_bytes_per_vertex)); > >> > + length = D3DXVec3Length(D3DXVec3Subtract(&v2,&v1,&v2)); > >> > + ok(fabs(length-10.0f)<admitted_error, "Width expected= 10.0, > >> > received %f\n", length); > >> > >> This is not really different from the previous version: you are still > >> making assumptions about the vertex ordering (in this specific case, > >> you're assuming that vertices 18 and 19 have different X coordinate > >> but the same Y and Z coordinate values). > > > > I have an application (Geoprofs) qui use the specific ordering of the > > vertex. So if we implement randomly the vertex, it will not work. > > Really? Well, that makes my original point mostly moot. > Still, I don't think the current tests are very meaningful. Do you > know exactly what that application needs? You could test for that > specific thing, so if, for example, the application requires the left > face to be the first one, you could test just for that. > > The application colors the left face and the right face and applies geometric tranformations, so the student can see where arrives the faces in comparison with the initial box Fetching left and right faces is doing by fetching vertex . > >> > >> What I was proposing was something like this: > >> > >> for (i = 0; i < num_vertices; i++) > >> { > >> float *vertex_data = data + i * num_bytes_per_vertex; > >> if (vertex_data[0] < xmin) xmin = vertex_data[0]; > >> if (vertex_data[0] > xmax) xmax = vertex_data[0]; > >> if (vertex_data[1] < ymin) ymin = vertex_data[1]; > >> if (vertex_data[1] > ymax) ymax = vertex_data[1]; > >> if (vertex_data[2] < zmin) zmin = vertex_data[2]; > >> if (vertex_data[2] > zmax) zmax = vertex_data[2]; > >> } > >> > >> and then proceed to check whether the minimum and maximum values you > >> got match the expected ones. This code snippet can certainly be > >> improved, it is only to show you what I meant. > >> > >> Also, again, please try to fix the whitespaces... > > > > People changed the original style of the file. So, Which one must I keep > ? > > > > Arguably it is better to adopt the style used for most recent code in > wined3d or d3dcompiler_43. But, regardless of that, you should at > least be consistent in the same function. You are mixing 0 or 1 spaces > after commas, spaces or no spaces around operators and stuff like > that. > > That looks reasonnable :D Thanks again. A+ David > > Thanks for your advices ;) > > > > A+ > > > > David > > >

March 31, 2011

Re: d3dx9_36 [patch 2/2]: Add tests for D3DXCreateBox

by Matteo Bruni

2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: > > > 2011/3/31 Matteo Bruni <matteo.mystral(a)gmail.com> >> >> 2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: >> > >> > + /* Check the width */ >> > + v1 = *((D3DXVECTOR3*)(data+19*num_bytes_per_vertex)); >> > + v2 = *((D3DXVECTOR3*)(data+18*num_bytes_per_vertex)); >> > + length = D3DXVec3Length(D3DXVec3Subtract(&v2,&v1,&v2)); >> > + ok(fabs(length-10.0f)<admitted_error, "Width expected= 10.0, >> > received %f\n", length); >> >> This is not really different from the previous version: you are still >> making assumptions about the vertex ordering (in this specific case, >> you're assuming that vertices 18 and 19 have different X coordinate >> but the same Y and Z coordinate values). > > I have an application (Geoprofs) qui use the specific ordering of the > vertex. So if we implement randomly the vertex, it will not work. Really? Well, that makes my original point mostly moot. Still, I don't think the current tests are very meaningful. Do you know exactly what that application needs? You could test for that specific thing, so if, for example, the application requires the left face to be the first one, you could test just for that. >> >> What I was proposing was something like this: >> >> for (i = 0; i < num_vertices; i++) >> { >> float *vertex_data = data + i * num_bytes_per_vertex; >> if (vertex_data[0] < xmin) xmin = vertex_data[0]; >> if (vertex_data[0] > xmax) xmax = vertex_data[0]; >> if (vertex_data[1] < ymin) ymin = vertex_data[1]; >> if (vertex_data[1] > ymax) ymax = vertex_data[1]; >> if (vertex_data[2] < zmin) zmin = vertex_data[2]; >> if (vertex_data[2] > zmax) zmax = vertex_data[2]; >> } >> >> and then proceed to check whether the minimum and maximum values you >> got match the expected ones. This code snippet can certainly be >> improved, it is only to show you what I meant. >> >> Also, again, please try to fix the whitespaces... > > People changed the original style of the file. So, Which one must I keep ? > Arguably it is better to adopt the style used for most recent code in wined3d or d3dcompiler_43. But, regardless of that, you should at least be consistent in the same function. You are mixing 0 or 1 spaces after commas, spaces or no spaces around operators and stuff like that. > Thanks for your advices ;) > > A+ > > David >

March 31, 2011

Re: d3dx9_36 [patch 2/2]: Add tests for D3DXCreateBox

by David Adam

2011/3/31 Matteo Bruni <matteo.mystral(a)gmail.com> > 2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: > > > > + /* Check the width */ > > + v1 = *((D3DXVECTOR3*)(data+19*num_bytes_per_vertex)); > > + v2 = *((D3DXVECTOR3*)(data+18*num_bytes_per_vertex)); > > + length = D3DXVec3Length(D3DXVec3Subtract(&v2,&v1,&v2)); > > + ok(fabs(length-10.0f)<admitted_error, "Width expected= 10.0, > received %f\n", length); > > This is not really different from the previous version: you are still > making assumptions about the vertex ordering (in this specific case, > you're assuming that vertices 18 and 19 have different X coordinate > but the same Y and Z coordinate values). > I have an application (Geoprofs) qui use the specific ordering of the vertex. So if we implement randomly the vertex, it will not work. > > What I was proposing was something like this: > > for (i = 0; i < num_vertices; i++) > { > float *vertex_data = data + i * num_bytes_per_vertex; > if (vertex_data[0] < xmin) xmin = vertex_data[0]; > if (vertex_data[0] > xmax) xmax = vertex_data[0]; > if (vertex_data[1] < ymin) ymin = vertex_data[1]; > if (vertex_data[1] > ymax) ymax = vertex_data[1]; > if (vertex_data[2] < zmin) zmin = vertex_data[2]; > if (vertex_data[2] > zmax) zmax = vertex_data[2]; > } > > and then proceed to check whether the minimum and maximum values you > got match the expected ones. This code snippet can certainly be > improved, it is only to show you what I meant. > > Also, again, please try to fix the whitespaces... > People changed the original style of the file. So, Which one must I keep ? Thanks for your advices ;) A+ David

March 31, 2011

Re: d3dx9_36 [patch 2/2]: Add tests for D3DXCreateBox

by Matteo Bruni

2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: > > + /* Check the width */ > + v1 = *((D3DXVECTOR3*)(data+19*num_bytes_per_vertex)); > + v2 = *((D3DXVECTOR3*)(data+18*num_bytes_per_vertex)); > + length = D3DXVec3Length(D3DXVec3Subtract(&v2,&v1,&v2)); > + ok(fabs(length-10.0f)<admitted_error, "Width expected= 10.0, received %f\n", length); This is not really different from the previous version: you are still making assumptions about the vertex ordering (in this specific case, you're assuming that vertices 18 and 19 have different X coordinate but the same Y and Z coordinate values). What I was proposing was something like this: for (i = 0; i < num_vertices; i++) { float *vertex_data = data + i * num_bytes_per_vertex; if (vertex_data[0] < xmin) xmin = vertex_data[0]; if (vertex_data[0] > xmax) xmax = vertex_data[0]; if (vertex_data[1] < ymin) ymin = vertex_data[1]; if (vertex_data[1] > ymax) ymax = vertex_data[1]; if (vertex_data[2] < zmin) zmin = vertex_data[2]; if (vertex_data[2] > zmax) zmax = vertex_data[2]; } and then proceed to check whether the minimum and maximum values you got match the expected ones. This code snippet can certainly be improved, it is only to show you what I meant. Also, again, please try to fix the whitespaces...

March 31, 2011

Re: msvcrt: Fix locale creation for multibyte encoding

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -787,13 +787,15 @@ MSVCRT__locale_t MSVCRT__create_locale(int category, const char *locale) > loc->locinfo->lc_category[MSVCRT_LC_CTYPE].locale = _strdup("C"); > } > > - for(i=0; i<256; i++) > - buf[i] = i; > - > - LCMapStringA(lcid[MSVCRT_LC_CTYPE], LCMAP_LOWERCASE, buf, 256, > - (char*)loc->locinfo->pclmap, 256); > - LCMapStringA(lcid[MSVCRT_LC_CTYPE], LCMAP_UPPERCASE, buf, 256, > - (char*)loc->locinfo->pcumap, 256); > + for(i=0; i<256; i++) { > + buf[0] = i; > + if(!LCMapStringA(lcid[MSVCRT_LC_CTYPE], LCMAP_LOWERCASE, buf, 1, > + (char*)loc->locinfo->pclmap+i, 1)) > + loc->locinfo->pclmap[i] = ' '; > + if(!LCMapStringA(lcid[MSVCRT_LC_CTYPE], LCMAP_UPPERCASE, buf, 1, > + (char*)loc->locinfo->pcumap+i, 1)) > + loc->locinfo->pcumap[i] = ' '; > + } It would probably be better to replace the DBCS lead chars in the input buffer first and then still do the whole mapping in one step. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2011

Why do the wintab32 tests load the dll at runtime?

by Francois Gouget

The subject says it all. Why do the wintab32 tests load the dll at runtime instead of simply linking with wintab32.dll? Is it to make it easier to compile it with Visual C++ in case the system does not have wintab32.dll? (already the SDKs don't seem to have wintab.h) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

March 31, 2011

Re: State of AMD 3d drivers?

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.03.2011 um 08:55 schrieb Dan Kegel: > How good are AMD's 3d drivers these days? > A few years ago, the word was, if you wanted to run the > wine test suite, you'd better have an nvidia graphics chip. > Is that still true? As far as the testsuite is concerned it is still true. An alternative is r600g, which almost runs the d3d tests successfully according to Henri. Wrt real games fglrx is in a pretty good shape. Performance isn't as good as the Nvidia drivers, and there are a few bugs here and there. However, if a game doesn't work I usually blame Wine first and then the driver. Bleeding edge games are probably still tricky. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNlDSJAAoJEN0/YqbEcdMwr0wP/RXt9MJUr3uePQubmPCP1jn1 VWlfwGevlPV2W7xkAxfp4Jtgd55hFnlyewuaCz58Lu2b6bDQlIzBh8wqWy6k4TRp 2/ixjF0G8Z6SH79gP8b4M4qf7WqeKmPpjpFoRdLbqmPyDA65JvDsvpKdJNLTmSYd l2i0r2MK4KobGZASRN4C2znuoJ8Z6YxXQwLQV6E13zb6dVUOgz6GYHNMfqccA+zU nc7lvgNigVTqdsXXzvYjJBHsMHiCphe5FPsONTH/dGMHQzGB9R8guKxzMj2SJlOv 4gUBYEYvRgCA8SVTfSc7w/G06hMag2mK1XVjjTgUnqhBsuB6yKX+r7kN+ZA0/r4V 3crxDa5NEAE4hJhItsJRuWSXxQs15+b6SqrLg3PotpiW28MJseFbYspGRlxVGGZw xFzVp5A80qBk7dtbi70BxrmzMJY6tRG6sW0EvFcf8R3HAmlyfMg3jX33zM30EMcE YGBZYaNOdGXcTYvFnD6Gkx1u/mISrsG3Xy/dYKO9RlaYNK5O91jtWrU7NmJGnQAH N2OoahTVKv/0qLGs7aJ9wcfX2g5Z7Ijub14Uj5G1yw5VjVCflWiNP2y2nwx2vp5q /I2E9Oc482bdg/yB1oAb2KDUpLLQIJJvJRURzDfOEWpns/Grz/PEPcAuaBma6D2U fAmnPkUaAEHhgWdG0ZEV =l/9v -----END PGP SIGNATURE-----

March 31, 2011

State of AMD 3d drivers?

by Dan Kegel

How good are AMD's 3d drivers these days? A few years ago, the word was, if you wanted to run the wine test suite, you'd better have an nvidia graphics chip. Is that still true?

March 31, 2011

Re: [1/2] winefile: Remove unimplemented menu entries.

by James McKenzie

On Wed, Mar 30, 2011 at 7:46 AM, Francois Gouget <fgouget(a)free.fr> wrote: > They unnecessarily clutter the GUI and are unlikely to ever be implemented. > --- > > As discussed on wine-devel. > I still left Rename and Create Directory because they are basic > functions that should really be there (but I won't implement them). Thank you Francois. These should only be brought back with a full implementation of the underlying code, if it is really needed. James McKenzie

March 30, 2011

Re: semi-obsolete audio drivers

by Andrew Eikum

On 03/30/2011 09:23 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Andrew, > > [good news, esp. the time-line] Let's hope I can stick to it :-P. It's looking good, though. >>OSSv4 (complete) > Do you specifically use OSS *v4* functions not available earlier? > (I'm not familiar with OSS4, even though I consult their docu online > and hope that what they write also applies to my machine with OSS v3 (Ubuntu)). I wrote it following the OSSv4 spec and using an OSSv4 implementation, so I suspect it won't work on OSSv3. I thought about supporting OSSv3, but I think it's not worth the effort -- that's a really old version that, when written, didn't support multiple clients simultaneously, had no mixer, etc. OSSv4 has a lot of features that make the driver much simpler. Further, I think only Linux is still stuck on OSSv3. I looked at a number of other operating systems, mostly BSDs and Solaris, and they all use OSSv4 by default. So I think Linux users should be covered by ALSA or PulseAudio (or perhaps JACK), and the much-more-pleasant OSSv4 is available for BSDs and Solaris. If a Linux user really wants OSS, I think they should probably upgrade to OSSv4 anyway. I could look at making it OSSv3 compatible, but I just think it's not worth the effort of supporting such an old and cantankerous API. Andrew

March 30, 2011

Re: semi-obsolete audio drivers

by Andrew Eikum

Hi Joerg, On 03/30/2011 06:11 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > What do you think? > - Why did people submit patches to one driver only when a short glance > shows that the same bug is in the other cloned drivers too? Well, those people might not know that there are multiple drivers, or might not care about drivers they don't use. Not everyone is as thorough as we'd like them to be :) > - Is WineJack "current" and worth some effort? > - Let the others continue to decay? > - Remove them from git? As for these questions, I can answer them all at once. I am currently re-implementing MMDevAPI to use a similar driver architecture to what WinMM uses. (Yes, this is Alexandre-approved ;-) ) I am at the point where a merge of my work into Wine is probably two or three weeks away. After we are satisfied with the MMDevAPI implementation, we will have to begin work on re-implementing WinMM and DSound on top of MMDevAPI, as Vista+ do. So the old, unmaintained WinMM drivers, as well as the current, maintained WinMM drivers, will be replaced by a single MMDevAPI-based implementation of WinMM. The maintenance burden will then be to keep the MMDevAPI drivers up-to-date, which is really the same problem you're asking about. But the hope is to make their first implementations _good_, and then keep them all correct and current, without letting any bitrot. For the record, I am planning on having ALSA (complete-ish, ALSA sucks), OSSv4 (complete), OSX CoreAudio (in progress), and PulseAudio (not yet started) implementations from the start. I would also like a JACK implementation for the pro-audio crowd (plus, I love JACK), but that's lower priority. In any case, the MMDevAPI drivers are much simpler and better organized than the WinMM drivers. I expect maintaining them and writing tests for them will be a much easier task than maintaining the WinMM drivers. Your continued work on the WinMM family is appreciated. That will help make the re-implementation on top of MMDevAPI higher quality from the start. Thanks, Andrew

March 30, 2011

Re: [PATCH 1/6] winmm: Check callback flags prior to opening a driver.

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 http://testbot.winehq.org/JobDetails.pl?Key=10217 Your paranoid android. === WXPPROSP3 (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W2K3R2SESP2 (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === WVISTAADM (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W2K8SE (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W7PRO (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W7PROX64 (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W7PROX64 (64 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR

March 30, 2011

semi-obsolete audio drivers

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, you may have noticed that I've always sent patches for the 3 audio drivers that I consider current and mostly up to date: + winealsa + wineoss + winecoreaudio and never for one of the other ones which I consider obsolete. - winejack - wineesd - winenas Sometimes I've been wondering whether I should include and take care of winejack too, although I've neither the jack development package nor do I know or use any software that uses Jack. As for the others, I really consider them obsolete and never look at them. This is not entirely satisfactory, as I've been blaming (in thoughts) the one or other developer who in the past fixed a bug in one of the drivers without fixing the same bug in the other ones... Code continues to diverge... What do you think? - Why did people submit patches to one driver only when a short glance shows that the same bug is in the other cloned drivers too? - Is WineJack "current" and worth some effort? - Let the others continue to decay? - Remove them from git? Please don't shout for maintenance by others too early: how much time do *you* invest in making Wine better? Regards, Jörg Höhle

March 30, 2011

Re: [06/10] msi: Accept whitespace-only property values on the command line.

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 http://testbot.winehq.org/JobDetails.pl?Key=10214 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5979: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

March 30, 2011

Re: [02/10] msi/tests: Get rid of workarounds for win9x test failures.

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 http://testbot.winehq.org/JobDetails.pl?Key=10212 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5979: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

March 30, 2011

Fwd: Re: [PATCH 2/5] d3dx9_36: Implemented ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetInt (Try 5)

by Rico Schüller

Forwarding to the list. Am 28.03.2011 20:47, schrieb David Laight: >> Ints and floats are represented differently and so, if we want to put >> an integer array into floating point registers, we need to have casts. >> If you were to simply call SetFloatArray, you would get nonsense >> values in the floating point registers. > Even using casts will fall foul of the C aliasing rules - which > mean that the compiler can assume that a read of type will not be > modified by a write to a different type so can be reorderd (unless > one of the types is 'char'). > > Not only that, but there are systems that will fault is an invalid > FP bit pattern is loaded into an FP register. > > David > My example wasn't very well chosen. So conversation (casts) between the different types is necessary. It was meant the way to reuse some of the code. Because I think ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetFloatArray could share a lot of code. This will probably be the same for ID3DXConstantTable_SetBoolArray. Cheers Rico

March 30, 2011

Re: [01/10] msi: Ignore invalid upgrade codes in the PublishProduct action.

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 http://testbot.winehq.org/JobDetails.pl?Key=10211 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:6052: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

March 30, 2011

Re: [PATCH] kernel32: Populate HKLM\HARDWARE\DEVICEMAP\Scsi on Mac OS.

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > OK. > > How do you propose to do that? The way this is done on Linux, it's > probably fine to just build up/tear down an entry for each device that > HAL/udev detects, but DiskArbitration only handles disks (and not other > types of SCSI devices) on Mac. I don't think we care about other types of devices at this point. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2011

Fwd: [PATCH 2/5] d3dx9_36: Implemented ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetInt (Try 5)

by Travis Athougies

>> Ints and floats are represented differently and so, if we want to put >> an integer array into floating point registers, we need to have casts. >> If you were to simply call SetFloatArray, you would get nonsense >> values in the floating point registers. > > Even using casts will fall foul of the C aliasing rules - which > mean that the compiler can assume that a read of type will not be > modified by a write to a different type so can be reorderd (unless > one of the types is 'char'). > Exactly. Which is why I am not ever casting int pointers to float pointers as Rico suggested. Instead I'm looping through the array and casting each int to a float, which should invoke the machinery necessary to convert from the bit representation of an int to that of a float. > Not only that, but there are systems that will fault is an invalid > FP bit pattern is loaded into an FP register. > If I'm casting ints to floats (and not int pointers to float pointers) I don't see how this could be an issue. Travis -- Travis Athougies

March 30, 2011

Re: [RFC] dinput: Length can actually be 0.

by Daniel Remenak

On Tue, Mar 29, 2011 at 1:57 PM, Vincent Pelletier <plr.vincent(a)gmail.com> wrote: > (Sorry for sending to wine-patches initially, it was intended for wnie-devel.) > > This fixes force feedback devices slamming for 10ms at full strength, as > attack is an absolute value, not a factor of effect level. > > Daniel Remenak told me that 0-length envelopes (attack and/or fade, not sure > which combination) cause the effect to be not played (possibly played with 0- > level) on devices using the Linux iforce driver. This is the reason of the > comment in the code. > > But to other drivers, such as hid-ff, this code causes the device to jump as > full strength, which was reported (to me directly) for example when playing > "Live for Speed"[1] with a steering wheel having strong force feedback > (Logitech G27). > > My question: Is it acceptable to risk some regression for iforce driver (until > bug is identified) to fix other devices ? > I guess iforce devices also suffer from the too-strong attack/fade effect. > > [1] http://www.lfs.net (demo available, I didn't try it) > --- > dlls/dinput/effect_linuxinput.c | 11 +++++------ > 1 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c > index fbc5994..0154f49 100644 > --- a/dlls/dinput/effect_linuxinput.c > +++ b/dlls/dinput/effect_linuxinput.c > @@ -606,13 +606,12 @@ static HRESULT WINAPI > LinuxInputEffectImpl_SetParameters( > else env = NULL; > > if (peff->lpEnvelope == NULL) { > - /* if this type had an envelope, reset it > - * note that length can never be zero, so we set it to something > minuscule */ > + /* if this type had an envelope, reset it */ > if (env) { > - env->attack_length = 0x10; > - env->attack_level = 0x7FFF; > - env->fade_length = 0x10; > - env->fade_level = 0x7FFF; > + env->attack_length = 0; > + env->attack_level = 0; > + env->fade_length = 0; > + env->fade_level = 0; > } > } else { > /* did we get passed an envelope for a type that doesn't even have > one? */ > -- > 1.7.4.1 > My 2 cents: This patch reflects the original intent of the code. The current values are effectively a workaround for poor behavior from the iforce driver (at least in combination with the Wingman Force), which (six years ago) was the only reasonably reliable FF driver on linux. It was not clear to me at the time whether it was a driver problem or a more general evdev issue. This patch correctly fixes one part of bug 9221 (the part about acting "like a pneumatic hammer"). As a side effect, it also disables most FF on devices using the iforce driver. Today, HID FF devices are far more common than iforce devices (which AFAIK have not been manufactured since the very early 2000s). The HID driver works well (has for years), and works as documented (for instance, that patch works, as it should). I think making FF usable for HID devices is worth it; perhaps it will even spur someone to fix envelope support for the iforce driver. Regards, Daniel Remenak

March 30, 2011

Re: today's git failed to build for me

by Francois Gouget

On Tue, 29 Mar 2011, Susan Cragin wrote: > I just downloaded today's git and tried to build it. The following are > the make errors in the terminal output. Below that, separated by a > line, are the installation errors. > > make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' > gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c > audio.c: In function ‘JACK_DriverProc’: > audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) > audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in > audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ > audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) This patch will fix it: http://www.winehq.org/pipermail/wine-patches/2011-March/100389.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

March 30, 2011