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

Re: today's git failed to build for me

by Austin English

On Wed, Mar 30, 2011 at 01:16, Susan Cragin <susancragin(a)earthlink.net> 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) > make[1]: *** [audio.o] Error 1 > make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' > make: *** [dlls/winejack.drv] Error 2 > > ------------------------------------------ > > 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) > make[1]: *** [audio.o] Error 1 > make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' > make: *** [install] Error 2 Use http://www.winehq.org/pipermail/wine-patches/2011-March/100389.html or run configure --without-jack. -- -Austin

March 30, 2011

today's git failed to build for me

by Susan Cragin

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) make[1]: *** [audio.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' make: *** [dlls/winejack.drv] Error 2 ------------------------------------------ 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) make[1]: *** [audio.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' make: *** [install] Error 2

March 30, 2011

Re: [PATCH 6/6] d3dx9: Use init function for ID3DXBuffer.

by David Adam

You mix S_OK with D3D_OK. Though they are equivalent, I think it would be better to keep the only D3D_OK notation. A+ David 2011/3/29 Rico Schüller <kgbricola(a)web.de> > --- > dlls/d3dx9_36/core.c | 36 +++++++++++++++++++++++++++--------- > 1 files changed, 27 insertions(+), 9 deletions(-) > > > > > >

March 29, 2011

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

by Charles Davis

On 3/29/11 4:34 AM, Alexandre Julliard wrote: > Charles Davis <cdavis(a)mymail.mines.edu> writes: > >> From: Charles Davis <cdavis(a)mines.edu> >> >> --- >> dlls/kernel32/Makefile.in | 2 +- >> dlls/kernel32/oldconfig.c | 157 +++++++++++++++++++++++++++++++++++++++++++- >> 2 files changed, 154 insertions(+), 5 deletions(-) > > This code needs to be moved to the mountmgr first. 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. Chip

March 29, 2011

[RFC] dinput: Length can actually be 0.

by Vincent Pelletier

(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

March 29, 2011

Re: [2/3] winex11.drv: Don't modify current state if glXMakeCurrent fails.

by Roderick Colenbrander

The first part of the patch was fine, the only concern is the error code. Since there is no WGL standard, the error codes thrown by different drivers can be inconsistent :( I'm not sure if it is better to set an error code at all or not. I'm not sure what I would prefer... Roderick On Tue, Mar 29, 2011 at 5:55 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2011/3/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>: >> I'm not sure if the only value error wglMakeCurrent should return is >> INVALID_HANDLE. What if glXMakeCurrent fails because of an invalid >> context? The return value may be similar, but don't remember for sure. >> >> Roderick > > Practically speaking it seems to be very dependent on the specific GL > driver used. For example, current Nvidia Windows drivers just accept a > wglMakeCurrent call with a destroyed context (no errors at all), while > I think AMD drivers crash in the same case. I'm not sure I > specifically tested that on glX too, but in general, failing on a > destroyed drawable was the only consistent "edge case" behavior I > found. > >> >> On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >>> >>> >>> >>> >>> >> >

March 29, 2011

Re: [3/3] winex11.drv: Make wglMakeCurrent return the correct error when the drawable is invalid.

by Roderick Colenbrander

On Tue, Mar 29, 2011 at 5:58 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2011/3/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>: >> The fact that a pixel format is not set on the physDev doesn't >> necessarily mean it is invalid, it just means SetPixelFormat wasn't >> called on it. Though slightly earlier in wglMakeCurrent we already >> catch that situation when compare the pixel format of the context and >> the hdc. > > True, but as you say the check I'm adding doesn't really change the > behavior outside of a different SetLastError() call. Maybe the WARN > message I'm adding could be improved. > >> >> Is there not something better for which we could check? Is the >> drawable of the physDev perhaps something to check for? (I have no >> idea in what state the physDev is after a destroy window; should we be >> able to enter x11drv at all? perhaps this should be handled inside the >> gdi32 code, just a thought) >> > > Checking for the drawable or any other field in the physDev doesn't > seem to be really better. I'm not sure about the feasibility of > handling that on the gdi32 side, I think I gave it a try at some point > but then I resorted to this other approach. But, of course, I may be > failing to see a better solution ;) > >> Roderick >> >> On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >>> > I would vote for a more correct way of checking whether we are dealing with an invalid drawable. Perhaps Alexandre has a good suggestion. Roderick

March 29, 2011

Re: [3/3] winex11.drv: Make wglMakeCurrent return the correct error when the drawable is invalid.

by Matteo Bruni

2011/3/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > The fact that a pixel format is not set on the physDev doesn't > necessarily mean it is invalid, it just means SetPixelFormat wasn't > called on it. Though slightly earlier in wglMakeCurrent we already > catch that situation when compare the pixel format of the context and > the hdc. True, but as you say the check I'm adding doesn't really change the behavior outside of a different SetLastError() call. Maybe the WARN message I'm adding could be improved. > > Is there not something better for which we could check? Is the > drawable of the physDev perhaps something to check for? (I have no > idea in what state the physDev is after a destroy window; should we be > able to enter x11drv at all? perhaps this should be handled inside the > gdi32 code, just a thought) > Checking for the drawable or any other field in the physDev doesn't seem to be really better. I'm not sure about the feasibility of handling that on the gdi32 side, I think I gave it a try at some point but then I resorted to this other approach. But, of course, I may be failing to see a better solution ;) > Roderick > > On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >>

March 29, 2011

Re: [2/3] winex11.drv: Don't modify current state if glXMakeCurrent fails.

by Matteo Bruni

2011/3/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > I'm not sure if the only value error wglMakeCurrent should return is > INVALID_HANDLE. What if glXMakeCurrent fails because of an invalid > context? The return value may be similar, but don't remember for sure. > > Roderick Practically speaking it seems to be very dependent on the specific GL driver used. For example, current Nvidia Windows drivers just accept a wglMakeCurrent call with a destroyed context (no errors at all), while I think AMD drivers crash in the same case. I'm not sure I specifically tested that on glX too, but in general, failing on a destroyed drawable was the only consistent "edge case" behavior I found. > > On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> >> >> >> >> >

March 29, 2011

Re: [3/3] winex11.drv: Make wglMakeCurrent return the correct error when the drawable is invalid.

by Roderick Colenbrander

The fact that a pixel format is not set on the physDev doesn't necessarily mean it is invalid, it just means SetPixelFormat wasn't called on it. Though slightly earlier in wglMakeCurrent we already catch that situation when compare the pixel format of the context and the hdc. Is there not something better for which we could check? Is the drawable of the physDev perhaps something to check for? (I have no idea in what state the physDev is after a destroy window; should we be able to enter x11drv at all? perhaps this should be handled inside the gdi32 code, just a thought) Roderick On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > > > >

March 29, 2011

Re: [2/3] winex11.drv: Don't modify current state if glXMakeCurrent fails.

by Roderick Colenbrander

I'm not sure if the only value error wglMakeCurrent should return is INVALID_HANDLE. What if glXMakeCurrent fails because of an invalid context? The return value may be similar, but don't remember for sure. Roderick On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > > > >

March 29, 2011

Re: wldap32: Accept a NULL value in ldap_set_option.

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=10187 Your paranoid android. === WNT4WSSP6 (32 bit parse) === parse.c:120: Test failed: ldap_set_optionW failed 0x00000059 === W2KPROSP4 (32 bit parse) === parse.c:120: Test failed: ldap_set_optionW failed 0x00000059

March 29, 2011

Re: mshtml: Fixed node leak in HTMLEventObj

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/htmlevent.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) This causes the mshtml:events test to hang for me. -- Alexandre Julliard julliard(a)winehq.org

March 29, 2011

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

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > From: Charles Davis <cdavis(a)mines.edu> > > --- > dlls/kernel32/Makefile.in | 2 +- > dlls/kernel32/oldconfig.c | 157 +++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 154 insertions(+), 5 deletions(-) This code needs to be moved to the mountmgr first. -- Alexandre Julliard julliard(a)winehq.org

March 29, 2011

Re: [PATCH 3/4] comdlg32: Add implementation of DllRegisterServer/DllUnregisterServer. (resend)

by Alexandre Julliard

David Hedberg <david.hedberg(a)gmail.com> writes: > @@ -274,3 +277,82 @@ HRESULT WINAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, void **ppv) > > return CLASS_E_CLASSNOTAVAILABLE; > } > + > +/*********************************************************************** > + * Register/Unregister DLL, based on shdocvw/factory.c > + */ You should use the new IRegistrar mechanism instead. -- Alexandre Julliard julliard(a)winehq.org

March 29, 2011

Re: RFC: Remove unimplemented application menus?

by James McKenzie

On 3/28/11 7:23 PM, Austin English wrote: > On Tue, Mar 29, 2011 at 03:20, James McKenzie<jjmckenzie51(a)gmail.com> wrote: >> On 3/28/11 7:19 PM, Austin English wrote: >>> On Tue, Mar 29, 2011 at 03:17, James McKenzie<jjmckenzie51(a)gmail.com> >>> wrote: >>>> On 3/28/11 7:15 PM, Austin English wrote: >>>>> 2011/3/29 James McKenzie<jjmckenzie51(a)gmail.com>: >>>>>> On 3/28/11 9:28 AM, André Hentschel wrote: >>>>>>> Am 28.03.2011 17:27, schrieb James McKenzie: >>>>>>>> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>>>>>>>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>>>>>>>> Some Wine programs, winefile in particular, have a lot of >>>>>>>>>> unimplemented >>>>>>>>>> menus. That is you can see the menu entry but clicking on it only >>>>>>>>>> gives >>>>>>>>>> you a 'Not yet implemented' error dialog (or does nothing in the >>>>>>>>>> case >>>>>>>>>> of iexplore). For instance just for the first two winefile menus >>>>>>>>>> none >>>>>>>>>> of the following are implemented: >>>>>>>>>> >>>>>>>>>> File -> Print... >>>>>>>>>> File -> Associate... >>>>>>>>>> File -> Search... >>>>>>>>>> File -> Select Files... >>>>>>>>>> Disk -> Share as... >>>>>>>>>> Disk -> Remove Share... >>>>>>>>>> Disk -> Select Drive... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think such a situation is bad: >>>>>>>>>> * Having tons of unimplemented menus looks amateurish. >>>>>>>>>> * It's very confusing. You see tons of menus except over 50% of >>>>>>>>>> them >>>>>>>>>> don't work. So it makes the GUI more complex with no benefit. >>>>>>>>>> * I suspect most of these menus have been unimplemented for years >>>>>>>>>> so there is little hope of seeing them improve any time soon. >>>>>>>>>> * For a number of them it's questionable whether it makes sense to >>>>>>>>>> implement them in Wine at all as they correspond to tasks that >>>>>>>>>> better belong to the native system facilities (Share as for >>>>>>>>>> instance). >>>>>>>>>> * I doubt they serve any significant compatibility purpose. >>>>>>>>>> * In the mean time they generate more work for translators and >>>>>>>>>> translation reviewers. >>>>>>>>>> * It generates more work for anyone checking whether the GUI is >>>>>>>>>> consistent / follows human interface guidelines (wrt. ellipses >>>>>>>>>> for >>>>>>>>>> instance). >>>>>>>>>> >>>>>>>>>> So I propose to simply remove unimplemented menus. When / if >>>>>>>>>> someone >>>>>>>>>> ever decides to implement some of the corresponding functionality, >>>>>>>>>> adding the corresponding code and GUI bits back should not be too >>>>>>>>>> hard. >>>>>>>>>> >>>>>>>>>> Objections? >>>>>>>>>> >>>>>>>>> Good Idea, at least for the year old stub menus (like winefile). >>>>>>>>> For recently added, with hope to see them implemented in the next >>>>>>>>> time >>>>>>>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>>>>>>>> >>>>>>>> I agree. This was proposed as a GOSC project by one of the people. >>>>>>>> There is a thread on Wine Users about these menus being >>>>>>>> 'unimplemented' and how they should be. Would this be a good item >>>>>>>> for >>>>>>>> a bug report for an Request for Enhancement? >>>>>>> IMHO no, there is no point i think. >>>>>>> PS: is this meant to be also sent to wine-devel? >>>>>>> >>>>>>> >>>>>> Are these features the program should possess or not? These tend to be >>>>>> 'standard' menu items for most Windows programs and the underlying code >>>>>> does >>>>>> lie in Windows, not the individual programs and has since the Windows >>>>>> 3.x >>>>>> days. >>>>> Theoretically they should be there, yes, but it's not really worth the >>>>> effort. >>>>> >>>> At least we could implement some sort of stub to popup a dialog to say >>>> the >>>> function is not implemented in Wine? Does Excel have a Open... and >>>> Save... >>>> menu item (these are also implemented in Windows or is it the program?) >>> Yes, Excel has the dialog, along with most other programs. Winefile >>> itself does not have it implemented. If you want to take the time to >>> stub out the dialogs, be my guest, but few people use winefile as is, >>> and fewer use the full dialogs (I bet most that notice it is broken >>> are just curious if it does work). The effort spent stubbing it would >>> be better spent fixing bugs that break actual applications. >>> >> Austin: >> >> However, this just might be something that AJ will approve. > Sure, that's his call, but I don't see the point in discussing it > without someone volunteering to write the code. > > It's a moot point, I don't use winefile, and I'd rather see it cleaned > up than have tons of stubs that make it look incomplete. However, I'm > not going to take the time to fix it, and am happy to see Francois do > so. Either way is fine with me, and it's not my decision. > > That's all I've got to say here, back to bugzilla for me. > I agree with this statement. Cleaning up poorly written code is always a noble task. James McKenzie

March 29, 2011

Re: RFC: Remove unimplemented application menus?

by Austin English

On Tue, Mar 29, 2011 at 03:20, James McKenzie <jjmckenzie51(a)gmail.com> wrote: > On 3/28/11 7:19 PM, Austin English wrote: >> >> On Tue, Mar 29, 2011 at 03:17, James McKenzie<jjmckenzie51(a)gmail.com> >> wrote: >>> >>> On 3/28/11 7:15 PM, Austin English wrote: >>>> >>>> 2011/3/29 James McKenzie<jjmckenzie51(a)gmail.com>: >>>>> >>>>> On 3/28/11 9:28 AM, André Hentschel wrote: >>>>>> >>>>>> Am 28.03.2011 17:27, schrieb James McKenzie: >>>>>>> >>>>>>> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>>>>>>> >>>>>>>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>>>>>>> >>>>>>>>> Some Wine programs, winefile in particular, have a lot of >>>>>>>>> unimplemented >>>>>>>>> menus. That is you can see the menu entry but clicking on it only >>>>>>>>> gives >>>>>>>>> you a 'Not yet implemented' error dialog (or does nothing in the >>>>>>>>> case >>>>>>>>> of iexplore). For instance just for the first two winefile menus >>>>>>>>> none >>>>>>>>> of the following are implemented: >>>>>>>>> >>>>>>>>> File -> Print... >>>>>>>>> File -> Associate... >>>>>>>>> File -> Search... >>>>>>>>> File -> Select Files... >>>>>>>>> Disk -> Share as... >>>>>>>>> Disk -> Remove Share... >>>>>>>>> Disk -> Select Drive... >>>>>>>>> >>>>>>>>> >>>>>>>>> I think such a situation is bad: >>>>>>>>> * Having tons of unimplemented menus looks amateurish. >>>>>>>>> * It's very confusing. You see tons of menus except over 50% of >>>>>>>>> them >>>>>>>>> don't work. So it makes the GUI more complex with no benefit. >>>>>>>>> * I suspect most of these menus have been unimplemented for years >>>>>>>>> so there is little hope of seeing them improve any time soon. >>>>>>>>> * For a number of them it's questionable whether it makes sense to >>>>>>>>> implement them in Wine at all as they correspond to tasks that >>>>>>>>> better belong to the native system facilities (Share as for >>>>>>>>> instance). >>>>>>>>> * I doubt they serve any significant compatibility purpose. >>>>>>>>> * In the mean time they generate more work for translators and >>>>>>>>> translation reviewers. >>>>>>>>> * It generates more work for anyone checking whether the GUI is >>>>>>>>> consistent / follows human interface guidelines (wrt. ellipses >>>>>>>>> for >>>>>>>>> instance). >>>>>>>>> >>>>>>>>> So I propose to simply remove unimplemented menus. When / if >>>>>>>>> someone >>>>>>>>> ever decides to implement some of the corresponding functionality, >>>>>>>>> adding the corresponding code and GUI bits back should not be too >>>>>>>>> hard. >>>>>>>>> >>>>>>>>> Objections? >>>>>>>>> >>>>>>>> Good Idea, at least for the year old stub menus (like winefile). >>>>>>>> For recently added, with hope to see them implemented in the next >>>>>>>> time >>>>>>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>>>>>>> >>>>>>> I agree. This was proposed as a GOSC project by one of the people. >>>>>>> There is a thread on Wine Users about these menus being >>>>>>> 'unimplemented' and how they should be. Would this be a good item >>>>>>> for >>>>>>> a bug report for an Request for Enhancement? >>>>>> >>>>>> IMHO no, there is no point i think. >>>>>> PS: is this meant to be also sent to wine-devel? >>>>>> >>>>>> >>>>> Are these features the program should possess or not? These tend to be >>>>> 'standard' menu items for most Windows programs and the underlying code >>>>> does >>>>> lie in Windows, not the individual programs and has since the Windows >>>>> 3.x >>>>> days. >>>> >>>> Theoretically they should be there, yes, but it's not really worth the >>>> effort. >>>> >>> At least we could implement some sort of stub to popup a dialog to say >>> the >>> function is not implemented in Wine? Does Excel have a Open... and >>> Save... >>> menu item (these are also implemented in Windows or is it the program?) >> >> Yes, Excel has the dialog, along with most other programs. Winefile >> itself does not have it implemented. If you want to take the time to >> stub out the dialogs, be my guest, but few people use winefile as is, >> and fewer use the full dialogs (I bet most that notice it is broken >> are just curious if it does work). The effort spent stubbing it would >> be better spent fixing bugs that break actual applications. >> > Austin: > > However, this just might be something that AJ will approve. Sure, that's his call, but I don't see the point in discussing it without someone volunteering to write the code. It's a moot point, I don't use winefile, and I'd rather see it cleaned up than have tons of stubs that make it look incomplete. However, I'm not going to take the time to fix it, and am happy to see Francois do so. Either way is fine with me, and it's not my decision. That's all I've got to say here, back to bugzilla for me. -- -Austin

March 29, 2011

Re: RFC: Remove unimplemented application menus?

by James McKenzie

On 3/28/11 7:19 PM, Austin English wrote: > On Tue, Mar 29, 2011 at 03:17, James McKenzie<jjmckenzie51(a)gmail.com> wrote: >> On 3/28/11 7:15 PM, Austin English wrote: >>> 2011/3/29 James McKenzie<jjmckenzie51(a)gmail.com>: >>>> On 3/28/11 9:28 AM, André Hentschel wrote: >>>>> Am 28.03.2011 17:27, schrieb James McKenzie: >>>>>> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>>>>>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>>>>>> Some Wine programs, winefile in particular, have a lot of >>>>>>>> unimplemented >>>>>>>> menus. That is you can see the menu entry but clicking on it only >>>>>>>> gives >>>>>>>> you a 'Not yet implemented' error dialog (or does nothing in the case >>>>>>>> of iexplore). For instance just for the first two winefile menus none >>>>>>>> of the following are implemented: >>>>>>>> >>>>>>>> File -> Print... >>>>>>>> File -> Associate... >>>>>>>> File -> Search... >>>>>>>> File -> Select Files... >>>>>>>> Disk -> Share as... >>>>>>>> Disk -> Remove Share... >>>>>>>> Disk -> Select Drive... >>>>>>>> >>>>>>>> >>>>>>>> I think such a situation is bad: >>>>>>>> * Having tons of unimplemented menus looks amateurish. >>>>>>>> * It's very confusing. You see tons of menus except over 50% of them >>>>>>>> don't work. So it makes the GUI more complex with no benefit. >>>>>>>> * I suspect most of these menus have been unimplemented for years >>>>>>>> so there is little hope of seeing them improve any time soon. >>>>>>>> * For a number of them it's questionable whether it makes sense to >>>>>>>> implement them in Wine at all as they correspond to tasks that >>>>>>>> better belong to the native system facilities (Share as for >>>>>>>> instance). >>>>>>>> * I doubt they serve any significant compatibility purpose. >>>>>>>> * In the mean time they generate more work for translators and >>>>>>>> translation reviewers. >>>>>>>> * It generates more work for anyone checking whether the GUI is >>>>>>>> consistent / follows human interface guidelines (wrt. ellipses for >>>>>>>> instance). >>>>>>>> >>>>>>>> So I propose to simply remove unimplemented menus. When / if someone >>>>>>>> ever decides to implement some of the corresponding functionality, >>>>>>>> adding the corresponding code and GUI bits back should not be too >>>>>>>> hard. >>>>>>>> >>>>>>>> Objections? >>>>>>>> >>>>>>> Good Idea, at least for the year old stub menus (like winefile). >>>>>>> For recently added, with hope to see them implemented in the next time >>>>>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>>>>>> >>>>>> I agree. This was proposed as a GOSC project by one of the people. >>>>>> There is a thread on Wine Users about these menus being >>>>>> 'unimplemented' and how they should be. Would this be a good item for >>>>>> a bug report for an Request for Enhancement? >>>>> IMHO no, there is no point i think. >>>>> PS: is this meant to be also sent to wine-devel? >>>>> >>>>> >>>> Are these features the program should possess or not? These tend to be >>>> 'standard' menu items for most Windows programs and the underlying code >>>> does >>>> lie in Windows, not the individual programs and has since the Windows 3.x >>>> days. >>> Theoretically they should be there, yes, but it's not really worth the >>> effort. >>> >> At least we could implement some sort of stub to popup a dialog to say the >> function is not implemented in Wine? Does Excel have a Open... and Save... >> menu item (these are also implemented in Windows or is it the program?) > Yes, Excel has the dialog, along with most other programs. Winefile > itself does not have it implemented. If you want to take the time to > stub out the dialogs, be my guest, but few people use winefile as is, > and fewer use the full dialogs (I bet most that notice it is broken > are just curious if it does work). The effort spent stubbing it would > be better spent fixing bugs that break actual applications. > Austin: However, this just might be something that AJ will approve. James McKenzie

March 29, 2011

Re: RFC: Remove unimplemented application menus?

by Austin English

On Tue, Mar 29, 2011 at 03:17, James McKenzie <jjmckenzie51(a)gmail.com> wrote: > On 3/28/11 7:15 PM, Austin English wrote: >> >> 2011/3/29 James McKenzie<jjmckenzie51(a)gmail.com>: >>> >>> On 3/28/11 9:28 AM, André Hentschel wrote: >>>> >>>> Am 28.03.2011 17:27, schrieb James McKenzie: >>>>> >>>>> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>>>>> >>>>>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>>>>> >>>>>>> Some Wine programs, winefile in particular, have a lot of >>>>>>> unimplemented >>>>>>> menus. That is you can see the menu entry but clicking on it only >>>>>>> gives >>>>>>> you a 'Not yet implemented' error dialog (or does nothing in the case >>>>>>> of iexplore). For instance just for the first two winefile menus none >>>>>>> of the following are implemented: >>>>>>> >>>>>>> File -> Print... >>>>>>> File -> Associate... >>>>>>> File -> Search... >>>>>>> File -> Select Files... >>>>>>> Disk -> Share as... >>>>>>> Disk -> Remove Share... >>>>>>> Disk -> Select Drive... >>>>>>> >>>>>>> >>>>>>> I think such a situation is bad: >>>>>>> * Having tons of unimplemented menus looks amateurish. >>>>>>> * It's very confusing. You see tons of menus except over 50% of them >>>>>>> don't work. So it makes the GUI more complex with no benefit. >>>>>>> * I suspect most of these menus have been unimplemented for years >>>>>>> so there is little hope of seeing them improve any time soon. >>>>>>> * For a number of them it's questionable whether it makes sense to >>>>>>> implement them in Wine at all as they correspond to tasks that >>>>>>> better belong to the native system facilities (Share as for >>>>>>> instance). >>>>>>> * I doubt they serve any significant compatibility purpose. >>>>>>> * In the mean time they generate more work for translators and >>>>>>> translation reviewers. >>>>>>> * It generates more work for anyone checking whether the GUI is >>>>>>> consistent / follows human interface guidelines (wrt. ellipses for >>>>>>> instance). >>>>>>> >>>>>>> So I propose to simply remove unimplemented menus. When / if someone >>>>>>> ever decides to implement some of the corresponding functionality, >>>>>>> adding the corresponding code and GUI bits back should not be too >>>>>>> hard. >>>>>>> >>>>>>> Objections? >>>>>>> >>>>>> Good Idea, at least for the year old stub menus (like winefile). >>>>>> For recently added, with hope to see them implemented in the next time >>>>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>>>>> >>>>> I agree. This was proposed as a GOSC project by one of the people. >>>>> There is a thread on Wine Users about these menus being >>>>> 'unimplemented' and how they should be. Would this be a good item for >>>>> a bug report for an Request for Enhancement? >>>> >>>> IMHO no, there is no point i think. >>>> PS: is this meant to be also sent to wine-devel? >>>> >>>> >>> Are these features the program should possess or not? These tend to be >>> 'standard' menu items for most Windows programs and the underlying code >>> does >>> lie in Windows, not the individual programs and has since the Windows 3.x >>> days. >> >> Theoretically they should be there, yes, but it's not really worth the >> effort. >> > At least we could implement some sort of stub to popup a dialog to say the > function is not implemented in Wine? Does Excel have a Open... and Save... > menu item (these are also implemented in Windows or is it the program?) Yes, Excel has the dialog, along with most other programs. Winefile itself does not have it implemented. If you want to take the time to stub out the dialogs, be my guest, but few people use winefile as is, and fewer use the full dialogs (I bet most that notice it is broken are just curious if it does work). The effort spent stubbing it would be better spent fixing bugs that break actual applications. -- -Austin

March 29, 2011

Re: RFC: Remove unimplemented application menus?

by James McKenzie

On 3/28/11 7:15 PM, Austin English wrote: > 2011/3/29 James McKenzie<jjmckenzie51(a)gmail.com>: >> On 3/28/11 9:28 AM, André Hentschel wrote: >>> Am 28.03.2011 17:27, schrieb James McKenzie: >>>> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>>>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>>>> Some Wine programs, winefile in particular, have a lot of unimplemented >>>>>> menus. That is you can see the menu entry but clicking on it only gives >>>>>> you a 'Not yet implemented' error dialog (or does nothing in the case >>>>>> of iexplore). For instance just for the first two winefile menus none >>>>>> of the following are implemented: >>>>>> >>>>>> File -> Print... >>>>>> File -> Associate... >>>>>> File -> Search... >>>>>> File -> Select Files... >>>>>> Disk -> Share as... >>>>>> Disk -> Remove Share... >>>>>> Disk -> Select Drive... >>>>>> >>>>>> >>>>>> I think such a situation is bad: >>>>>> * Having tons of unimplemented menus looks amateurish. >>>>>> * It's very confusing. You see tons of menus except over 50% of them >>>>>> don't work. So it makes the GUI more complex with no benefit. >>>>>> * I suspect most of these menus have been unimplemented for years >>>>>> so there is little hope of seeing them improve any time soon. >>>>>> * For a number of them it's questionable whether it makes sense to >>>>>> implement them in Wine at all as they correspond to tasks that >>>>>> better belong to the native system facilities (Share as for >>>>>> instance). >>>>>> * I doubt they serve any significant compatibility purpose. >>>>>> * In the mean time they generate more work for translators and >>>>>> translation reviewers. >>>>>> * It generates more work for anyone checking whether the GUI is >>>>>> consistent / follows human interface guidelines (wrt. ellipses for >>>>>> instance). >>>>>> >>>>>> So I propose to simply remove unimplemented menus. When / if someone >>>>>> ever decides to implement some of the corresponding functionality, >>>>>> adding the corresponding code and GUI bits back should not be too hard. >>>>>> >>>>>> Objections? >>>>>> >>>>> Good Idea, at least for the year old stub menus (like winefile). >>>>> For recently added, with hope to see them implemented in the next time >>>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>>>> >>>> I agree. This was proposed as a GOSC project by one of the people. >>>> There is a thread on Wine Users about these menus being >>>> 'unimplemented' and how they should be. Would this be a good item for >>>> a bug report for an Request for Enhancement? >>> IMHO no, there is no point i think. >>> PS: is this meant to be also sent to wine-devel? >>> >>> >> Are these features the program should possess or not? These tend to be >> 'standard' menu items for most Windows programs and the underlying code does >> lie in Windows, not the individual programs and has since the Windows 3.x >> days. > Theoretically they should be there, yes, but it's not really worth the effort. > At least we could implement some sort of stub to popup a dialog to say the function is not implemented in Wine? Does Excel have a Open... and Save... menu item (these are also implemented in Windows or is it the program?) James McKenzie

March 29, 2011

Re: RFC: Remove unimplemented application menus?

by Austin English

2011/3/29 James McKenzie <jjmckenzie51(a)gmail.com>: > On 3/28/11 9:28 AM, André Hentschel wrote: >> >> Am 28.03.2011 17:27, schrieb James McKenzie: >>> >>> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>>> >>>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>>> >>>>> Some Wine programs, winefile in particular, have a lot of unimplemented >>>>> menus. That is you can see the menu entry but clicking on it only gives >>>>> you a 'Not yet implemented' error dialog (or does nothing in the case >>>>> of iexplore). For instance just for the first two winefile menus none >>>>> of the following are implemented: >>>>> >>>>> File -> Print... >>>>> File -> Associate... >>>>> File -> Search... >>>>> File -> Select Files... >>>>> Disk -> Share as... >>>>> Disk -> Remove Share... >>>>> Disk -> Select Drive... >>>>> >>>>> >>>>> I think such a situation is bad: >>>>> * Having tons of unimplemented menus looks amateurish. >>>>> * It's very confusing. You see tons of menus except over 50% of them >>>>> don't work. So it makes the GUI more complex with no benefit. >>>>> * I suspect most of these menus have been unimplemented for years >>>>> so there is little hope of seeing them improve any time soon. >>>>> * For a number of them it's questionable whether it makes sense to >>>>> implement them in Wine at all as they correspond to tasks that >>>>> better belong to the native system facilities (Share as for >>>>> instance). >>>>> * I doubt they serve any significant compatibility purpose. >>>>> * In the mean time they generate more work for translators and >>>>> translation reviewers. >>>>> * It generates more work for anyone checking whether the GUI is >>>>> consistent / follows human interface guidelines (wrt. ellipses for >>>>> instance). >>>>> >>>>> So I propose to simply remove unimplemented menus. When / if someone >>>>> ever decides to implement some of the corresponding functionality, >>>>> adding the corresponding code and GUI bits back should not be too hard. >>>>> >>>>> Objections? >>>>> >>>> Good Idea, at least for the year old stub menus (like winefile). >>>> For recently added, with hope to see them implemented in the next time >>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>>> >>> I agree. This was proposed as a GOSC project by one of the people. >>> There is a thread on Wine Users about these menus being >>> 'unimplemented' and how they should be. Would this be a good item for >>> a bug report for an Request for Enhancement? >> >> IMHO no, there is no point i think. >> PS: is this meant to be also sent to wine-devel? >> >> > Are these features the program should possess or not? These tend to be > 'standard' menu items for most Windows programs and the underlying code does > lie in Windows, not the individual programs and has since the Windows 3.x > days. Theoretically they should be there, yes, but it's not really worth the effort. -- -Austin

March 29, 2011

Re: RFC: Remove unimplemented application menus?

by James McKenzie

On 3/28/11 9:28 AM, André Hentschel wrote: > Am 28.03.2011 17:27, schrieb James McKenzie: >> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>> Some Wine programs, winefile in particular, have a lot of unimplemented >>>> menus. That is you can see the menu entry but clicking on it only gives >>>> you a 'Not yet implemented' error dialog (or does nothing in the case >>>> of iexplore). For instance just for the first two winefile menus none >>>> of the following are implemented: >>>> >>>> File -> Print... >>>> File -> Associate... >>>> File -> Search... >>>> File -> Select Files... >>>> Disk -> Share as... >>>> Disk -> Remove Share... >>>> Disk -> Select Drive... >>>> >>>> >>>> I think such a situation is bad: >>>> * Having tons of unimplemented menus looks amateurish. >>>> * It's very confusing. You see tons of menus except over 50% of them >>>> don't work. So it makes the GUI more complex with no benefit. >>>> * I suspect most of these menus have been unimplemented for years >>>> so there is little hope of seeing them improve any time soon. >>>> * For a number of them it's questionable whether it makes sense to >>>> implement them in Wine at all as they correspond to tasks that >>>> better belong to the native system facilities (Share as for >>>> instance). >>>> * I doubt they serve any significant compatibility purpose. >>>> * In the mean time they generate more work for translators and >>>> translation reviewers. >>>> * It generates more work for anyone checking whether the GUI is >>>> consistent / follows human interface guidelines (wrt. ellipses for >>>> instance). >>>> >>>> So I propose to simply remove unimplemented menus. When / if someone >>>> ever decides to implement some of the corresponding functionality, >>>> adding the corresponding code and GUI bits back should not be too hard. >>>> >>>> Objections? >>>> >>> Good Idea, at least for the year old stub menus (like winefile). >>> For recently added, with hope to see them implemented in the next time (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>> >> I agree. This was proposed as a GOSC project by one of the people. >> There is a thread on Wine Users about these menus being >> 'unimplemented' and how they should be. Would this be a good item for >> a bug report for an Request for Enhancement? > IMHO no, there is no point i think. > PS: is this meant to be also sent to wine-devel? > > Are these features the program should possess or not? These tend to be 'standard' menu items for most Windows programs and the underlying code does lie in Windows, not the individual programs and has since the Windows 3.x days. Sorry, but I hit the reply button and not reply to all when I responded to you. My apologies. James McKenzie

March 29, 2011

[GSoC] Message mode pipes proposal

by Bryan Donlan

Hi, all, >From the GSoC project ideas page, I became interested in the proposal for implementing message-based pipes (see bug: http://bugs.winehq.org/show_bug.cgi?id=17195) The most recent patches to the bug cited above appear to use a separate socketpair for each message sent down the pipe, and must make potentially multiple wineserver calls for each interaction with the pipe. This will clearly begin to have problems once a large number of file descriptors are in the air. While a discussion on #winehackers suggested that implementing message-based pipes efficiently and safely entirely in userspace would be quite difficult, I feel that implementing a _correct_ implementation (regardless of efficiency) would be a practical goal. After creating a correct implementation, work could then be done to improve performance. First, a bit about me: I am a computer science student at the University of Massachusetts, heading into my senior year. I have had a lot of experience with Linux development, somewhat less on the Windows side. I am fluent in English and Japanese, although I doubt Japanese language experience would be helpful for this project :) In previous summer internships I have developed code for interprocess communication; in one instance, I wrote a ring buffer synchronization protocol to transfer data from a Windows user-space program to a real-time process running in kernel-mode (hosted via a third-party Windows real-time HAL). I propose the following overall plan: * First, I will prepare a comprehensive test suite for message-based pipes. Benchmarks would also be prepared to help determine whether optimization is necessary. This will likely borrow from the tests already posted to the bug I linked above. * I will write a wineserver-internal implementation of message-based pipes. That is, all NtReadFile/NtWriteFile() requests would be completely redirected to wineserver; there would be no attempt to expose a file descriptor for the client process to access directly. Wineserver in turn would simply manage a simple, in-memory queue of messages. Although this is unscalable and has a lot of context switch and copying overhead, it is simple, and would allow programs making light usage of message-based pipes to work. It also provides a clear place to hook on a new, faster protocol that requires a custom NtReadFile/NtWriteFile. After this point, I will begin work on optimizing the implementation. Some ideas on how to do this might include: * Implement the pipe using a ring buffer in shared memory. Client processes can then directly access the pipe buffer to pass data without wineserver's involvement. This has the downside that a user-mode process can inadvertently corrupt the pipe's state; this may be acceptable if the effects can be limited to a trashed pipe buffer, instead of crashing unrelated processes. * Implement the pipe using a ring buffer in shared memory, but expose only a read-only file descriptor to client processes. This avoids the corruption issues, but writes must be managed by the server and will incur overhead. * Implement the pipe as a single server-managed socketpair over which shared memory backing files are passed with SCM_RIGHTS, plus a lock (possibly implemented in shared memory using futexes, or by flock on a /dev/shm file). Clients acquire the lock, then MSG_PEEK the socketpair to retrieve an anonymous (unlinked immediately after creation) shared memory file descriptor. The shared memory buffer holds a count of remaining bytes, plus the actual message data. Clients then perform a normal recvmsg() to dequeue the message if they successfully retrieved the entire message. This approach is complex, and it is unclear what the performance impacts of having so many files being thrown around would be. However, it does avoid the context-switch costs and wineserver load that are a problem in the implementations currently on the bug tracker. * Implement a Linux kernel module to implement message-based pipe semantics natively. Although quite efficient, this will only apply to Linux, and may introduce difficulty keeping up with Linux kernel changes in the future. It is also unclear whether distributions and/or upstream Linux maintainers will welcome this approach. I will likely end up trying out several of these approaches and comparing actual performance results. Finally, if time allows, I will also investigate integration with samba, in order to support connecting to named pipes on remote servers. I would appreciate any comments on this proposal prior to actual submission. Thanks, Bryan Donlan

March 28, 2011

Re: [PATCH 4/6] mshtml/tests: Added IDocObjectService interface

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=10180 Your paranoid android. === WXPPROSP3 (32 bit htmldoc) === TestLauncher.c:89: Test failed: Can't open test executable C:\winetest\mshtml_test.exe, error 32

March 28, 2011

Re: wininet: Port numbers are unsigned (more)

by André Hentschel

Am 28.03.2011 22:37, schrieb Dan McDonald: > On 03/28/2011 01:40 PM, André Hentschel wrote: >> - static const WCHAR percentD[] = {'%','d',0}; >> + static const WCHAR percentD[] = {'%','u',0}; > > Variable name change may be in order here. > > Dan > > true, thx. -- Best Regards, André Hentschel

March 28, 2011

Re: wininet: Port numbers are unsigned (more)

by Dan McDonald

On 03/28/2011 01:40 PM, André Hentschel wrote: > - static const WCHAR percentD[] = {'%','d',0}; > + static const WCHAR percentD[] = {'%','u',0}; Variable name change may be in order here. Dan

March 28, 2011

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

by 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 -- David Laight: david(a)l8s.co.uk

March 28, 2011

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

by Travis Athougies

2011/3/28 Rico Schüller <kgbricola(a)web.de>: > Hi, > > this and the previous patch (1/5) are doing the same thing? Is there a > reason why they could not use the same code base? > > e.g. > ID3DXConstantTable_SetIntArray(iface, device, constant, n, count) > { > return ID3DXConstantTable_SetFloatArray(iface, device, constant, n, > count); > } 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. > > Also I'd prefer if there would be TRACEs in each function. > > It might be useful to add the RegisterSet in the FIXME for the default case, > to see which one is missing in the special case. Okay. Travis. > > Cheers > Rico > > Am 27.03.2011 22:22, schrieb Travis Athougies: >> >> --- >> dlls/d3dx9_36/shader.c | 37 ++++++++++++++++++++++++++++++------- >> 1 files changed, 30 insertions(+), 7 deletions(-) >> >> diff --git a/dlls/d3dx9_36/shader.c b/dlls/d3dx9_36/shader.c >> index 4a3caab..874d916 100644 >> --- a/dlls/d3dx9_36/shader.c >> +++ b/dlls/d3dx9_36/shader.c >> @@ -847,11 +847,7 @@ static HRESULT WINAPI >> ID3DXConstantTableImpl_SetBoolArray(ID3DXConstantTable* if >> >> static HRESULT WINAPI ID3DXConstantTableImpl_SetInt(ID3DXConstantTable* >> iface, LPDIRECT3DDEVICE9 device, D3DXHANDLE constant, INT n) >> { >> - ID3DXConstantTableImpl *This = impl_from_ID3DXConstantTable(iface); >> - >> - FIXME("(%p)->(%p, %p, %d): stub\n", This, device, constant, n); >> - >> - return E_NOTIMPL; >> + return ID3DXConstantTable_SetIntArray(iface, device, constant,&n, 1); >> } >> >> static HRESULT WINAPI >> ID3DXConstantTableImpl_SetIntArray(ID3DXConstantTable* iface, >> LPDIRECT3DDEVICE9 device, >> @@ -859,9 +855,36 @@ static HRESULT WINAPI >> ID3DXConstantTableImpl_SetIntArray(ID3DXConstantTable* ifa >> { >> ID3DXConstantTableImpl *This = impl_from_ID3DXConstantTable(iface); >> >> - FIXME("(%p)->(%p, %p, %p, %d): stub\n", This, device, constant, n, >> count); >> + D3DXCONSTANT_DESC desc; >> + HRESULT hr; >> + UINT i, desc_count = 1; >> + float row[4] = {0.0f, 0.0f, 0.0f, 0.0f}; >> + >> + hr = ID3DXConstantTable_GetConstantDesc(iface, >> constant,&desc,&desc_count); >> + if (FAILED(hr)) >> + { >> + TRACE("ID3DXConstantTable_GetConstantDesc failed: %08x", hr); >> + return D3DERR_INVALIDCALL; >> + } >> >> - return E_NOTIMPL; >> + switch (desc.RegisterSet) >> + { >> + case D3DXRS_FLOAT4: >> + for (i = 0; i< count&& i< desc.RegisterCount; i++) >> + { >> + row[0] = n[i]; >> + if (is_vertex_shader(This->desc.Version)) >> + IDirect3DDevice9_SetVertexShaderConstantF(device, >> desc.RegisterIndex + i, row, 1); >> + else >> + IDirect3DDevice9_SetPixelShaderConstantF(device, >> desc.RegisterIndex + i, row, 1); >> + } >> + break; >> + default: >> + FIXME("Can't handle RegisterSets other than D3DXRS_FlOAT4\n"); >> + return E_NOTIMPL; >> + } >> + >> + return D3D_OK; >> } >> >> static HRESULT WINAPI ID3DXConstantTableImpl_SetFloat(ID3DXConstantTable* >> iface, LPDIRECT3DDEVICE9 device, > > -- Travis Athougies

March 28, 2011

Re: [4/4] d3d9: Test depth stencil size mismatches

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Interesting. I can't remember if I tested my test on my ATI card, but I'll give it a try. It looks like ATI happily accepts the size mismatch. If it does we could just make the test accept the result and keep our implementation the same or extend the test to see how the depth test behaves outside the DS surface and see if we can implement it. Am 28.03.2011 um 14:26 schrieb Henri Verbeet: > This fails for me on native (Windows 7, Radeon HD 6950): > > visual.c:11813: Test failed: DS size test: Pixel (2, 2) after clear is > 0xff0000, expected 0x000000FF > visual.c:11815: Test failed: DS size test: Pixel (31, 31) after clear > is 0xff0000, expected 0x000000FF > visual.c:11817: Test failed: DS size test: Pixel (32, 32) after clear > is 0xff0000, expected 0x000000FF > visual.c:11819: Test failed: DS size test: Pixel (63, 63) after clear > is 0xff0000, expected 0x000000FF > visual.c:11825: Test failed: IDirect3DDevice9_ValidateDevice returned > 0, expected D3DERR_CONFLICTINGRENDERSTATE. > visual.c:11832: Test failed: IDirect3DDevice9_ValidateDevice returned > 0, expected D3DERR_CONFLICTINGRENDERSTATE. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNkMKzAAoJEN0/YqbEcdMw+70QAJaQ+h2K6vYdDe2r8O/5T0sP o4gbd8E/2bvjbtJXVt0hIVIffdvWgdYkS9XAAKHfd5MyfdQsj39YpsqEx20qhXNQ xqfdN9oOsf9URzP86pve0iwpw2wlciXGknfIOKgKhTCXMbCO3sPZHXkOTqySPytr Qy/3BryHOWECSCQqNTBeAESbFn7VBI52ryPzWFdgXznA5Usaiox88LWreK7i9qjU /x3OTk1ToXyvZRUAWj3lWJZbWCzICcbHD4s8LamU7Vr2OLmdSAMbeU/+MDK73X0h rCJ9ZmN2wMiGb4Ji4ttg21gPYPP7469xt3mP9SEKRWldFxGRLii9RUGRq7zfKm5a GkdFBwH6QbzW7voDcPwScxkiIX76QZukDomuMPPk9B6OxM/1LQzO+JZQGSKh81jK sXEzryJP3Byl5OZBZ+w6dNuZWdN+4j1bxJaZKMAT/J3+HipjAwQBlIHAerbmCuBw Q1E1TfSVmcnAaNeqCdt4BaKNwcvtaImt6KqfXGr5MkVCJvHGNKH6domO995DOFHQ OWoUq7cLM7HJOiyOxHKJyW8mhUsWCxbAAefegylXaKcoFtpnO3w5ZhDNXuuKXacX DmuQbVSvX+YbsKlPclpeoGodXtBVsac8mZ8B/ZPSOeNVWVKuatiFGsEcM3Jo14F5 wK54PFSve5yJ8pQU2NJ2 =Zub5 -----END PGP SIGNATURE-----

March 28, 2011

Re: [1/7] urlmon: Removed str_last_of in favor of strnrchrW

by Alexandre Julliard

Thomas Mullaly <thomas.mullaly(a)gmail.com> writes: > --- > dlls/urlmon/uri.c | 27 ++++++--------------------- > dlls/urlmon/urlmon_main.h | 14 ++++++++++++++ > 2 files changed, 20 insertions(+), 21 deletions(-) > From 7528b6b58256cba3ef53937e0ff7dbc3593f684a Mon Sep 17 00:00:00 2001 > From: Thomas Mullaly <tmullaly(a)codeweavers.com> > Date: Sun, 20 Mar 2011 16:28:59 -0400 > Subject: urlmon: Removed str_last_of in favor of strnrchrW It's called memrchrW. -- Alexandre Julliard julliard(a)winehq.org

March 28, 2011

winmm & concurrency

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

Hi, I've had a hard time finding information about what kind of guarantees MS makes for concurrency in the winmm function set. The best I've found so far is a 2005 blog entry written by Larry Osterman. Concurrency, part way too many2 - Concurrency and the Win32 API set http://blogs.msdn.com/b/larryosterman/archive/2005/03.aspx "I implicated the concurrency issues when I mentioned that all DLLs need to be multi-thread safe [...]" "The Windows MME APIs (waveOutXxx, waveInXxx, mixerXxx, etc) also protect their internal data structures. But they also support callback functions [...]" That's short. If you find anything else, please tell me. The irritating thing about Wine bug #9026 (waveOutReset during waveOutClose) and bug #22978 (MCI_CLOSE) is that they involve no concurrency from the app's POV. In both cases, the app issues a sequence of PlaySound resp. mciSendCommand from a single thread. Concurrency appears as Wine internally makes use of player threads. Regards, Jörg Höhle

March 28, 2011

Re: [PATCH2/2] winmm: PlaySound concurrency cleanup.

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

Eric, >sharing a global variable between threads without proper >sync protection or atomic operation is the wrong thing to do Which one? bPlaySoundStop is set and reset within the scope of WINMM_cs. Actually, there's one error: I should have put it at the exact same location of the Re/SetEvent(psStopEvent) it replaces, not outside the loop. This became apparent as I rethought of the scenario where 2 concurrent invocations of PlaySound need to interrupt an already running third one. I'll resubmit ASAP. >moreover you're doing several unrelated changes >in the same patch, please split up I initially had that as 4-5 patches, then merged them for not being of significant value individually. Regards, Jörg Höhle

March 28, 2011

w9x/ME users, please test (mciGet/SetYieldProc)

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

Hi, Testbot job #10124 contains a test that works perfectly on machines since w2k, but much to my surprise, mciGetYieldProc returns NULL,0 on testbot's win9x machines. If you have a w9x or a WinME machine, I'd appreciate if you could run the test too. Download & invoke winmm_test.exe midi http://testbot.winehq.org/GetFile.pl?JobKey=10124&StepKey=2 test & patch code: http://testbot.winehq.org/GetFile.pl?JobKey=10124&StepKey=1 If you happen to know why mciGet/SetYieldProc yield NULL/FALSE, please let me hear. NULL looks like an error status than a valid "old value is truly NULL" result. mciSetYieldProc returns FALSE as an error indicator, whereas I'd expect mciSetYieldProc(id,NULL,<any>) to be a valid call. Testbot's w9x machines return: mci.c:639: Test failed: original yieldproc 00000000 mci.c:640: Test failed: Break key is vkey 0 mci.c:643: Test failed: mciSetYieldProc NULL mci.c:648: Test failed: Break key changed to vkey 0 mci.c:664: Test failed: Break key changed to vkey 0 mci.c:674: Test failed: mciSetYieldProc restore Thank you, Jörg Höhle

March 28, 2011

Re: Wine compatibility

by Scott Ritchie

On 03/23/2011 11:02 AM, Juan Lang wrote: >> What I meant as 'clean start' is that they could drop all hacks in 64bit >> environment. I wonder if that happened. > > Speculating whether MS would have done this is probably not a very > useful exercise. Still, I'd say it's exceedingly improbable: > 1. The cost of reviewing all the code for what might be a hack is > high, and what's the benefit? Less code to maintain can't be an > answer, because the 32-bit versions of Windows still need the hacks. > 2. Apps written for 64-bit Windows aren't created in a vacuum: > they're probably ported from a 32-bit codebase first, or 32-bit and > 64-bit versions are co-developed. The same, possibly erroneous > assumptions that a 32-bit application might make would therefore need > to be maintained in a 64-bit version. > > A better place to ask questions like these might be > http://blogs.msdn.com/b/oldnewthing/ > --Juan > > Still, we're probably not going to encounter the 64-bit equivalent of "If program is simcity, do this with the memory instead of that" Though there are probably many newer hacks to worry about instead. --Scott Ritchie

March 28, 2011

Re: [4/4] d3d9: Test depth stencil size mismatches

by Henri Verbeet

This fails for me on native (Windows 7, Radeon HD 6950): visual.c:11813: Test failed: DS size test: Pixel (2, 2) after clear is 0xff0000, expected 0x000000FF visual.c:11815: Test failed: DS size test: Pixel (31, 31) after clear is 0xff0000, expected 0x000000FF visual.c:11817: Test failed: DS size test: Pixel (32, 32) after clear is 0xff0000, expected 0x000000FF visual.c:11819: Test failed: DS size test: Pixel (63, 63) after clear is 0xff0000, expected 0x000000FF visual.c:11825: Test failed: IDirect3DDevice9_ValidateDevice returned 0, expected D3DERR_CONFLICTINGRENDERSTATE. visual.c:11832: Test failed: IDirect3DDevice9_ValidateDevice returned 0, expected D3DERR_CONFLICTINGRENDERSTATE.

March 28, 2011

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

by Rico Schüller

Hi, this and the previous patch (1/5) are doing the same thing? Is there a reason why they could not use the same code base? e.g. ID3DXConstantTable_SetIntArray(iface, device, constant, n, count) { return ID3DXConstantTable_SetFloatArray(iface, device, constant, n, count); } Also I'd prefer if there would be TRACEs in each function. It might be useful to add the RegisterSet in the FIXME for the default case, to see which one is missing in the special case. Cheers Rico Am 27.03.2011 22:22, schrieb Travis Athougies: > --- > dlls/d3dx9_36/shader.c | 37 ++++++++++++++++++++++++++++++------- > 1 files changed, 30 insertions(+), 7 deletions(-) > > diff --git a/dlls/d3dx9_36/shader.c b/dlls/d3dx9_36/shader.c > index 4a3caab..874d916 100644 > --- a/dlls/d3dx9_36/shader.c > +++ b/dlls/d3dx9_36/shader.c > @@ -847,11 +847,7 @@ static HRESULT WINAPI ID3DXConstantTableImpl_SetBoolArray(ID3DXConstantTable* if > > static HRESULT WINAPI ID3DXConstantTableImpl_SetInt(ID3DXConstantTable* iface, LPDIRECT3DDEVICE9 device, D3DXHANDLE constant, INT n) > { > - ID3DXConstantTableImpl *This = impl_from_ID3DXConstantTable(iface); > - > - FIXME("(%p)->(%p, %p, %d): stub\n", This, device, constant, n); > - > - return E_NOTIMPL; > + return ID3DXConstantTable_SetIntArray(iface, device, constant,&n, 1); > } > > static HRESULT WINAPI ID3DXConstantTableImpl_SetIntArray(ID3DXConstantTable* iface, LPDIRECT3DDEVICE9 device, > @@ -859,9 +855,36 @@ static HRESULT WINAPI ID3DXConstantTableImpl_SetIntArray(ID3DXConstantTable* ifa > { > ID3DXConstantTableImpl *This = impl_from_ID3DXConstantTable(iface); > > - FIXME("(%p)->(%p, %p, %p, %d): stub\n", This, device, constant, n, count); > + D3DXCONSTANT_DESC desc; > + HRESULT hr; > + UINT i, desc_count = 1; > + float row[4] = {0.0f, 0.0f, 0.0f, 0.0f}; > + > + hr = ID3DXConstantTable_GetConstantDesc(iface, constant,&desc,&desc_count); > + if (FAILED(hr)) > + { > + TRACE("ID3DXConstantTable_GetConstantDesc failed: %08x", hr); > + return D3DERR_INVALIDCALL; > + } > > - return E_NOTIMPL; > + switch (desc.RegisterSet) > + { > + case D3DXRS_FLOAT4: > + for (i = 0; i< count&& i< desc.RegisterCount; i++) > + { > + row[0] = n[i]; > + if (is_vertex_shader(This->desc.Version)) > + IDirect3DDevice9_SetVertexShaderConstantF(device, desc.RegisterIndex + i, row, 1); > + else > + IDirect3DDevice9_SetPixelShaderConstantF(device, desc.RegisterIndex + i, row, 1); > + } > + break; > + default: > + FIXME("Can't handle RegisterSets other than D3DXRS_FlOAT4\n"); > + return E_NOTIMPL; > + } > + > + return D3D_OK; > } > > static HRESULT WINAPI ID3DXConstantTableImpl_SetFloat(ID3DXConstantTable* iface, LPDIRECT3DDEVICE9 device,

March 28, 2011

Re: [PATCH2/2] winmm: PlaySound concurrency cleanup.

by Eric Pouech

sharing a global variable between threads without proper sync protection or atomic operation is the wrong thing to do moreover you're doing several unrelated changes in the same patch, please split up A+ 2011/3/28 <Joerg-Cyril.Hoehle(a)t-systems.com> > Hi, > > - PlaySound_Alloc does not call _Free anymore, so it does not use WINMM_cs > anymore, which makes it easier to reason about use of critical sections. > - psStopEvent was never used like an event rather than a boolean. > - No need to muck with WHDR_DONE. > - No need to keep the unused thread handle object around. > - Abort the playloop in case of error, like I did for mciwave. The error > may not be transient. > > - Free waveHdr and hEvent after closing hWave. Either you believe that > WAVERR_STILLPLAYING can happen, then obviously waveHdr is in use and must > not yet be freed, or you believe checking for STILLPLAYING is a waste of > code because waveOutReset must have done its job. > > I should have added an ERR() message. > > One should think again about what to do in such a case. Why/when would > sleep help? User-friendlier might be not to wait, not to free WaveHdr > and accept to leak resources in such a case. > > Actually, waveOutClose can fail with STILLPLAYING because waveOutReset > can fail. If you look at winealsa, you'll see it uses CreateEvent to > synchronously wait for acknowledge of the message. Now guess what > happens if CreateEvent fails because memory is tight? > What happens in the app when waveOutClose's CreateEvent fails? > It's always tough to reason about the many error paths. > > Regards, > Jörg Höhle > > > > -- -- Eric Pouech

March 28, 2011

Re: Summer of Code 2011 ideas

by Jerome Leclanche

On Mon, Mar 28, 2011 at 9:33 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Am 28.03.2011 um 02:26 schrieb Jerome Leclanche: >> If you want another app to work with, the World of Warcraft trial can >> be an excellent start. The game works almost flawlessly in d3d9 now, >> and pretty much all of the d3d10 usage is identical. > I'm not sure if d3d10 is used by WoW. WoW doesn't allow you to set high liquid detail level(and others), but that's not because it needs d3d10, it is needed because the Windows driver version we report is outdated and needs updating. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > > iQIcBAEBAgAGBQJNkEfQAAoJEN0/YqbEcdMwDKgP+wR/4PD2ztd265GlvAvIRYW8 > +W31081u4/FSU8/LOJkBob6Kno0z7/1wEiNSREvyBRHER2xaGPenZJIDVt/Yq+46 > 3XuIc29y1DtCYo4W86vVm5CHZgP5B6Wp6bvcdwEws8sqmqOwyYHetlrwo7Cjp14r > fMjpXUnoQS1EtRTR1EHKOjFcXgbuiHeBUSBD2+qYpHS2hfsFHpkSQUQg6/KOlvhp > vr8ykiFUejQSxJ3pjhghvIE004Hmf6DoXKHZg79luPHTH70ax6Bef9YBV5IUylr0 > ilwNHYCAkVzD12KPxEsznlMVtqSh8L/StXz+ePCMOwMM7QHhXvOP2ATwXwhkWFvr > kw4dvbKYAwQcC/i0I9aWFYbOEOOJc6/GUYj2xk4OkfoiMHMxsxGxecd3nFh6Njh1 > SifsEoI3WJ+0BWbhhh88JxeTr+quy7FIJH1QtyTwU17q7FRwBdBeZF2YycV9irKq > E6FpIihsTJqlsWy0TVLhZK6spdN316/ZF2jZhm2HqDOXCLgekNPuExCInvYKpXIQ > /EVdf9z+/zHhsYHfKqw7WktHnVIqbYZiyFZAji3QggG7TAkqw2lw7IYjG8IPNcSF > zMH7A94hcqXRO8wmTXkk8FCshMb7u/MfIJOKLw8x2BeIugt3sQnJjWkNML2GWR5V > aTtUT6JR3iDPyJYMOdCK > =XuFJ > -----END PGP SIGNATURE----- > Actually that seems to have been fixed recently (see bugs http://bugs.winehq.org/show_bug.cgi?id=26571, http://bugs.winehq.org/show_bug.cgi?id=24928) WoW has had semi-experimental D3D10 support for a few months now, disabled by default. It uses the new APIs but offers no additional features. To enable it, you can use /console gxapi D3D10. J. Leclanche

March 28, 2011

Re: Summer of Code 2011 ideas

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 28.03.2011 um 02:26 schrieb Jerome Leclanche: > If you want another app to work with, the World of Warcraft trial can > be an excellent start. The game works almost flawlessly in d3d9 now, > and pretty much all of the d3d10 usage is identical. I'm not sure if d3d10 is used by WoW. WoW doesn't allow you to set high liquid detail level(and others), but that's not because it needs d3d10, it is needed because the Windows driver version we report is outdated and needs updating. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNkEfQAAoJEN0/YqbEcdMwDKgP+wR/4PD2ztd265GlvAvIRYW8 +W31081u4/FSU8/LOJkBob6Kno0z7/1wEiNSREvyBRHER2xaGPenZJIDVt/Yq+46 3XuIc29y1DtCYo4W86vVm5CHZgP5B6Wp6bvcdwEws8sqmqOwyYHetlrwo7Cjp14r fMjpXUnoQS1EtRTR1EHKOjFcXgbuiHeBUSBD2+qYpHS2hfsFHpkSQUQg6/KOlvhp vr8ykiFUejQSxJ3pjhghvIE004Hmf6DoXKHZg79luPHTH70ax6Bef9YBV5IUylr0 ilwNHYCAkVzD12KPxEsznlMVtqSh8L/StXz+ePCMOwMM7QHhXvOP2ATwXwhkWFvr kw4dvbKYAwQcC/i0I9aWFYbOEOOJc6/GUYj2xk4OkfoiMHMxsxGxecd3nFh6Njh1 SifsEoI3WJ+0BWbhhh88JxeTr+quy7FIJH1QtyTwU17q7FRwBdBeZF2YycV9irKq E6FpIihsTJqlsWy0TVLhZK6spdN316/ZF2jZhm2HqDOXCLgekNPuExCInvYKpXIQ /EVdf9z+/zHhsYHfKqw7WktHnVIqbYZiyFZAji3QggG7TAkqw2lw7IYjG8IPNcSF zMH7A94hcqXRO8wmTXkk8FCshMb7u/MfIJOKLw8x2BeIugt3sQnJjWkNML2GWR5V aTtUT6JR3iDPyJYMOdCK =XuFJ -----END PGP SIGNATURE-----

March 28, 2011

Re: d3dx9_36: Implement D3DXCreateBox

by Andrew Nguyen

On 03/27/2011 04:52 PM, Joshua Beck wrote: > On a side note, you could rearrange this loop to use less multiplications: > + for(i = 0; i< 24; i++) > + { > + int sixi = 6 * i; > + vertices[sixi ] *= width; > + vertices[sixi + 1] *= height; > + vertices[sixi + 2] *= depth; > + } > > Or even better: > + for(i = 0; i< 144; i+=4) > + { > + vertices[i ] *= width; > + vertices[++i] *= height; > + vertices[++i] *= depth; > + } > > I find that the second variant you proposed hinders comprehension of the loop, as Dmitry's responses imply. While the first variant is perfectly fine, I wanted to point out that in terms of code generation with optimization enabled, the original and your variants are identical, so your suggestions don't have any impact on runtime performance of the loop.

March 28, 2011

Re: ws2_32: return an error in SO_CONNECT_TIME stub

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > @@ -2554,7 +2554,7 @@ INT WINAPI WS_getsockopt(SOCKET s, INT level, > } > *(DWORD*)optval = pretendtime++; > *optlen = sizeof(DWORD); > - return ret; > + return SOCKET_ERROR; > } Filling out optval and optlen but returning SOCKET_ERROR doesn't make sense. Probably Eye-Fi doesn't change the return value. What kind of socket both of the applications do pass? -- Dmitry.

March 28, 2011

Re: d3dx9_36: Implement D3DXCreateBox

by Dmitry Timoshkov

Joshua Beck <jxb091000(a)utdallas.edu> wrote: > >> Or even better: > >> + for(i = 0; i< 144; i+=4) > >> + { > >> + vertices[i ] *= width; > >> + vertices[++i] *= height; > >> + vertices[++i] *= depth; > >> + } > >> > > There shouild be i + 1 and i + 2 instead of two ++i otherwise > > the loop index gets corrupted. > > > You mean like this? > > + for(i = 0; i< 144; i+=6) > + { > + vertices[i ] *= width; > + vertices[i + 1] *= height; > + vertices[i + 2] *= depth; > + } Looks like I misread the original loop condition. Both your variants are fine. -- Dmitry.

March 28, 2011

Re: d3dx9_36: Implement D3DXCreateBox

by Joshua Beck

On 03/27/2011 10:58 PM, Dmitry Timoshkov wrote: > Joshua Beck<jxb091000(a)utdallas.edu> wrote: > > >> Or even better: >> + for(i = 0; i< 144; i+=4) >> + { >> + vertices[i ] *= width; >> + vertices[++i] *= height; >> + vertices[++i] *= depth; >> + } >> > There shouild be i + 1 and i + 2 instead of two ++i otherwise > the loop index gets corrupted. > You mean like this? + for(i = 0; i< 144; i+=6) + { + vertices[i ] *= width; + vertices[i + 1] *= height; + vertices[i + 2] *= depth; + }

March 28, 2011

Re: d3dx9_36: Implement D3DXCreateBox

by Dmitry Timoshkov

Joshua Beck <jxb091000(a)utdallas.edu> wrote: > Or even better: > + for(i = 0; i< 144; i+=4) > + { > + vertices[i ] *= width; > + vertices[++i] *= height; > + vertices[++i] *= depth; > + } There shouild be i + 1 and i + 2 instead of two ++i otherwise the loop index gets corrupted. -- Dmitry.

March 28, 2011

Re: Summer of Code 2011 ideas

by Jerome Leclanche

On Mon, Mar 28, 2011 at 12:53 AM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > 2. D3D10 support. Here's an idea that isn't tied to Mac OS X. In Wine, > D3D10 support is still in the embryonic stage (i.e. lots of stubs, > anything interesting doesn't work quite right). It looks like Henri > wants to wait until he finishes exorcising COM from WineD3D to finish > implementing D3D10 (probably because COM was too much of a burden for > what D3D10 needed from WineD3D, judging from which methods are stubs), > so if you want to wait, that's fine. If I do take this on, my goal will > probably be to get the game "Civilization V" working (at least, > partially) in D3D10 mode, because that's the only D3D10 game I happen to > own! (If it already works, and I don't know if it does because I haven't > gotten around to installing and testing it, then I'll try to make it > work better.) > If you want another app to work with, the World of Warcraft trial can be an excellent start. The game works almost flawlessly in d3d9 now, and pretty much all of the d3d10 usage is identical. Best of luck! J. Leclanche

March 28, 2011

Summer of Code 2011 ideas

by Charles Davis

Hi, I intend to participate in the Google Summer of Code (again), so I'd like to bounce some ideas off of you guys again. (I don't know why; I'll probably end up doing an extension of last year's project that I did for LLVM. But just in case...) I know that students are supposed to start submitting their proposals tomorrow, but better late than never, I guess. Anyway, here are my ideas (in no particular order): 1. Quartz Driver. I know you guys rejected this last year, but it looks like AJ's been doing some work refactoring the driver interface (at least, the GDI driver interface) lately. I also have some patches to isolate the rest of Wine from winex11. Since the driver itself is so huge, I'll probably end up only doing a piece of it (just enough to run some simple programs like Notepad or Minesweeper). This still depends on my (as yet, unfinished) Deobjectivizer tool so I don't have to code the driver in Objective-C (or resort to Carbon, which Apple seems intent on exorcising from Mac OS X). 2. D3D10 support. Here's an idea that isn't tied to Mac OS X. In Wine, D3D10 support is still in the embryonic stage (i.e. lots of stubs, anything interesting doesn't work quite right). It looks like Henri wants to wait until he finishes exorcising COM from WineD3D to finish implementing D3D10 (probably because COM was too much of a burden for what D3D10 needed from WineD3D, judging from which methods are stubs), so if you want to wait, that's fine. If I do take this on, my goal will probably be to get the game "Civilization V" working (at least, partially) in D3D10 mode, because that's the only D3D10 game I happen to own! (If it already works, and I don't know if it does because I haven't gotten around to installing and testing it, then I'll try to make it work better.) 3. Message-mode pipes. I think we can use the sendmsg(2) and recvmsg(2) syscalls to implement this on top of Unix-domain sockets. Then again, I suspect that this was one of the first things AJ thought of--and he hasn't been able to figure out how to do it yet! I have some experience writing Mac OS X kernel extensions (I wrote the SCSI kexts that Wine on Mac uses), and even a little experience writing Linux modules, so that might help with that. I would like to avoid a kernel module, if possible, though. (It's just one more thing that users have to install to make the system work...) What do you think? Chip

March 27, 2011

Re: d3dx9_36: Implement D3DXCreateBox

by Joshua Beck

On 3/27/2011 11:08 AM, Joris Huizer wrote: > But you are changing the values during the function: > > + > + for(i = 0; i< 24; i++) > + { > + vertices[6 * i ] *= width; > + vertices[6 * i + 1] *= height; > + vertices[6 * i + 2] *= depth; > + } > + On a side note, you could rearrange this loop to use less multiplications: + for(i = 0; i< 24; i++) + { + int sixi = 6 * i; + vertices[sixi ] *= width; + vertices[sixi + 1] *= height; + vertices[sixi + 2] *= depth; + } Or even better: + for(i = 0; i< 144; i+=4) + { + vertices[i ] *= width; + vertices[++i] *= height; + vertices[++i] *= depth; + }

March 27, 2011

Re: d3dx9_36: Implement D3DXCreateBox

by Joris Huizer

Hello, In this patch, one part seemed strange to me: You are declaring vertices as static memory: + static FLOAT vertices[144] But you are changing the values during the function: + + for(i = 0; i< 24; i++) + { + vertices[6 * i ] *= width; + vertices[6 * i + 1] *= height; + vertices[6 * i + 2] *= depth; + } + Given that original values are never restored, I think you can not mark the array as static, otherwise incorrect values are used after the first call. The other arrays are not adapted, so they are fine as static memory (And you may in fact mark those static const) HTH, Joris

March 27, 2011

Re: RFC: Remove unimplemented application menus?

by André Hentschel

Am 27.03.2011 13:50, schrieb Francois Gouget: > > Some Wine programs, winefile in particular, have a lot of unimplemented > menus. That is you can see the menu entry but clicking on it only gives > you a 'Not yet implemented' error dialog (or does nothing in the case > of iexplore). For instance just for the first two winefile menus none > of the following are implemented: > > File -> Print... > File -> Associate... > File -> Search... > File -> Select Files... > Disk -> Share as... > Disk -> Remove Share... > Disk -> Select Drive... > > > I think such a situation is bad: > * Having tons of unimplemented menus looks amateurish. > * It's very confusing. You see tons of menus except over 50% of them > don't work. So it makes the GUI more complex with no benefit. > * I suspect most of these menus have been unimplemented for years > so there is little hope of seeing them improve any time soon. > * For a number of them it's questionable whether it makes sense to > implement them in Wine at all as they correspond to tasks that > better belong to the native system facilities (Share as for > instance). > * I doubt they serve any significant compatibility purpose. > * In the mean time they generate more work for translators and > translation reviewers. > * It generates more work for anyone checking whether the GUI is > consistent / follows human interface guidelines (wrt. ellipses for > instance). > > So I propose to simply remove unimplemented menus. When / if someone > ever decides to implement some of the corresponding functionality, > adding the corresponding code and GUI bits back should not be too hard. > > Objections? > Good Idea, at least for the year old stub menus (like winefile). For recently added, with hope to see them implemented in the next time (maybe gsoc), we should wait some month (e.g. iexplore) IMO. -- Best Regards, André Hentschel

March 27, 2011

Re: RFC: wined3d: Check for and use FBO blits early in BltOverride

by Henri Verbeet

On 27 March 2011 10:57, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > BltOverride is a horrible mess, and I'm afraid the patch doesn't make it any > better. Yeah, I'm not so convinced this is really an improvement either.

March 27, 2011

RFC: Remove unimplemented application menus?

by Francois Gouget

Some Wine programs, winefile in particular, have a lot of unimplemented menus. That is you can see the menu entry but clicking on it only gives you a 'Not yet implemented' error dialog (or does nothing in the case of iexplore). For instance just for the first two winefile menus none of the following are implemented: File -> Print... File -> Associate... File -> Search... File -> Select Files... Disk -> Share as... Disk -> Remove Share... Disk -> Select Drive... I think such a situation is bad: * Having tons of unimplemented menus looks amateurish. * It's very confusing. You see tons of menus except over 50% of them don't work. So it makes the GUI more complex with no benefit. * I suspect most of these menus have been unimplemented for years so there is little hope of seeing them improve any time soon. * For a number of them it's questionable whether it makes sense to implement them in Wine at all as they correspond to tasks that better belong to the native system facilities (Share as for instance). * I doubt they serve any significant compatibility purpose. * In the mean time they generate more work for translators and translation reviewers. * It generates more work for anyone checking whether the GUI is consistent / follows human interface guidelines (wrt. ellipses for instance). So I propose to simply remove unimplemented menus. When / if someone ever decides to implement some of the corresponding functionality, adding the corresponding code and GUI bits back should not be too hard. Objections? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ In a world without fences who needs Gates?

March 27, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Henri Verbeet

On 23 March 2011 23:50, Adam Martinson <amartinson(a)codeweavers.com> wrote: > On 03/22/2011 01:33 PM, Henri Verbeet wrote: >> >> How much of a real difference does this patch make, after you >> avoid the redundant lookups? (I.e., after the second patch in this >> series.) > > In that case the additional reduction in context_apply_fbo_state() CPU time > from the 1st patch is only about 10%. > That sounds more realistic. I think it makes sense to just focus on your 2/4 patch for the moment, and worry about the other patches later.

March 27, 2011

Re: [2/4] wined3d: Track when the FBO is dirty.

by Henri Verbeet

On 21 March 2011 21:57, Adam Martinson <amartinson(a)codeweavers.com> wrote: > @@ -2102,6 +2121,7 @@ BOOL context_apply_clear_state(struct wined3d_context *context, IWineD3DDeviceIm > if (rt_count < context->gl_info->limits.buffers) > memset(context->blit_targets + rt_count, 0, (context->gl_info->limits.buffers - rt_count) * sizeof(*rts)); > context_apply_fbo_state(context, GL_FRAMEBUFFER, rt_count, context->blit_targets, depth_stencil, SFLAG_INTEXTURE); > + context->device_fbo = context->current_fbo; You can't do that. > @@ -4801,6 +4801,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_Clear(IWineD3DDevice *iface, DWORD rect > } > > device_get_draw_rect(device, &draw_rect); > + IWineD3DDeviceImpl_MarkFBODirty(device); What is this for? > +static inline void IWineD3DDeviceImpl_MarkFBODirty(IWineD3DDeviceImpl *This) This doesn't need to be in wined3d_private.h, it's only used from device.c. > + int i; > + for (i = 0; i < This->numContexts; ++i) numContexts is unsigned. What would happen when the current draw fbo entry would get evicted from the cache? Also, while the patch avoids redundant lookups for draws, it doesn't do a lot for clears. Is that intentional because it's not worth it, or is there a different reason for that?

March 27, 2011

Re: RFC: wined3d: Check for and use FBO blits early in BltOverride

by Chris Robinson

On Sunday, March 27, 2011 1:57:17 AM Stefan Dösinger wrote: > BltOverride is a horrible mess, and I'm afraid the patch doesn't make it > any better. A long time ago Roderick started a cleanup to give the blit > selection routine a more structured approach, but he never finished the > work. Unfortunately a proper fix is not a weekend task :-( Ultimately, I think the best approach would be to properly split up the blitters. Currently, WineD3D uses a catch-all Blt method that handles almost all blitting possibilities (including color-keying), with a fallback to do manual conversions and blits if an "accelerated" path is missed or not available, and also handling color-fill (and patterned drawing?). The way D3D9 does it, there's different methods to handle blitting to and from various types of surfaces (eg, StretchRect for vidmem->vidmem only, no color- keying, and acts as a resolver for multisampled surfaces). If I could, I'd add methods to IWineD3DDevice to handle it that way. Different methods for different purposes, and making the d3d/ddraw dlls select the appropriate blitter. Although it'd result in a bit of duplication until the monolithic Blt method can be removed, and I'm not all too familiar with wined3d's resource handling, nor do I know how to properly add new methods to wined3d interfaces. Given how daunting a proper cleanup is, I figured it'd still be a good idea to handle more cases for accelerated blits with a "simple" patch, instead of letting it go vidmem->sysmem[->conversion->sysmem]->stretch->sysmem->vidmem, in addition to necessitating more converters that aren't otherwise needed (without this patch, it needs to use argb8->xrgb8 and rgba16f->xrgb8 converters, the latter of which doesn't exist and adding it would be just as much of a hack as playing with BltOverride, IMO, not to mention being left with really crappy performance).

March 27, 2011

Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)

by Stefan Dösinger

On Friday 25 March 2011 08:40:04 Joshua Beck wrote: > Is there any documentation I can read on how to program for these DLLs? > I've been looking through MSDN and I can't find anything specifically > about those DLLs. However I did find Windows Imaging Component (which I > think is what windowscodecs.dll implements) and that seems like it would > be helpful for the D3DXSaveSurfaceTo* functions. gdi32 is the classic Windows graphics API used by pretty much every application for drawing text, bitmaps, lines etc. It has some functions to load bitmaps from files. windowscodecs handles the newer formats I think, so it is probably what you want. You can make use of both dlls too.

March 27, 2011

Re: RFC: wined3d: Check for and use FBO blits early in BltOverride

by Stefan Dösinger

On Sunday 27 March 2011 06:26:47 Chris Robinson wrote: > After some testing and talking with Henri, it seems a number of checks > aren't needed if FBO blits are available, particularly the > swapchain/active render target checks. The attached patch makes > BltOverride check for FBO blits earlier, which helps it catch more cases > where blits can be accelerated. It provides a significant improvement with > the aforementioned programs. BltOverride is a horrible mess, and I'm afraid the patch doesn't make it any better. A long time ago Roderick started a cleanup to give the blit selection routine a more structured approach, but he never finished the work. Unfortunately a proper fix is not a weekend task :-( Besides simple unconverted blits we should also be able to do converted blits via FBOs + shader draws, e.g. to blit a YUV surface to an offscreen render target. This is needed for HW accelerated video playback with quicktime. And I am sure there are many other things that need to be considered.

March 27, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Vitaliy Margolen

On 03/23/2011 12:05 PM, Dan Kegel wrote: > Winetricks is a simple script that adds a few mssing things to wine, e.g. > it's how most people install ms dlls or .net on wine. It also provides a > simple commandline way to change a few settings. For instance, winetricks > vd=1024x768 sets a 1024x768 virtual desktop... it'd be nice if one could > instead do winecfg vd=1024x768 or something like that. Except you don't need winecfg for that you can run: wine explorer /desktop,program,1024x768 program.exe But all that aside, all changes that winecfg is doing are registry only changes. IMHO Wine doesn't need yet another program to writes something into registry. There are already two: regedit and reg. Vitaliy

March 27, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Vitaliy Margolen

On 03/25/2011 11:12 AM, Tony Zhang wrote: > If I can just build one cpl, how should I build (compile) it and let the > existing wine recognize it? Yes, you can build only one dll/cpl/program: # Assuming you are in wine source directory: $ make -C dlls/inetcpl.cpl If you trying to use "existing Wine" [presumably an installed Wine] - it won't be that easy. It's recommended to not install Wine on a development system and run it directly from the compile directory instead.. Vitaliy.

March 27, 2011

RFC: wined3d: Check for and use FBO blits early in BltOverride

by Chris Robinson

IDirect3DDevice9::StretchRect is used to stretch-blit between video memory surfaces. It's implemented by calling IWineD3DSurfaceImpl_Blt, which itself will attempt IWineD3DSurfaceImpl_BltOverride to accelerate it. However, BltOverride will not accelerate the blit if neither surface is a swapchain or active render target 0, and will fall back to a sysmem->sysmem blit with possible conversions. This seems to happen in between every post-processing (screen-space shader) pass with Oblivion Graphics Extender and Morrowind Graphics Extender, which causes a severe loss in performance. After some testing and talking with Henri, it seems a number of checks aren't needed if FBO blits are available, particularly the swapchain/active render target checks. The attached patch makes BltOverride check for FBO blits earlier, which helps it catch more cases where blits can be accelerated. It provides a significant improvement with the aforementioned programs. I'm not sure of the full consequences of this move, however, particularly with earlier DX versions. Hence a request for comments.

March 27, 2011

Re: wined3d: check for ARB_fragment_program in arbfp_blit_supported

by Stefan Dösinger

On Saturday 26 March 2011 16:25:00 Roderick Colenbrander wrote: > For some more background see the thread 'wined3d: Prevent crash when > blit_priv is NULL' started by Konrad Rzepecki . Essentially because > the blitter refactoring is not finished, BltOverride can enter this > code. Inside BltOverride there is a 'arb_blit_supported' which at this > point returned TRUE, which allowed calling of arb_blit_surface. Ok

March 26, 2011

Re: [2/2] comctl32/listview: Fix edit box text limit

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=10152 Your paranoid android. === WNT4WSSP6 (32 bit listview) === listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259

March 26, 2011

Re: [1/2] comctl32/listview: Adjust dispinfo text buffer length

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=10151 Your paranoid android. === WNT4WSSP6 (32 bit listview) === listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259

March 26, 2011

Re: GSoC: Implement the Explorer

by David Hedberg

Hi Jay, On Fri, Mar 25, 2011 at 21:51, Jay Yang <jkelleyy(a)gmail.com> wrote: >> The code for creating new explorer windows should probably reside in >> explorerframe.dll, somewhat analogous to how this works for the >> Internet Explorer and shdocvw.dll. > > So would implementing explorerframe.dll be a good summer project or is it > too large or too small? I haven't been able to find any good documentation > on what exactly is implemented by explorerframe.dll, is there any? > Yeah, lack of documentation might be a problem here. I haven't dug very deep into these parts. In fact it might be the case that it would not be worth the time to attempt to implement this exactly like in Windows at the moment, given both the lack of documentation and - presumably - a lack of applications relying on it. The obvious parts missing is code for the creation of a frame with navigation controls and an embedded ExplorerBrowser, and then some changes to our explorer to use this code instead of spawning winefile. As you have probably seen though, neither the wine Explorer Browser control nor the things it relies on are quite full featured, so there's no real lack of things one could work on if the above were to be insufficient for an entire project. Many of the new interfaces introduced in Vista+ are also poorly (or not at all) supported. There's also the issue of supporting shell extensions like you mentioned. I guess it boils down to what you want to accomplish and how much time you think that will take you. :-) Disclaimer: While I am trying to give a picture of where we're currently at, I might not have much of any actual say in wine's gsoc administration. -- David

March 26, 2011

Re: wined3d: check for ARB_fragment_program in arbfp_blit_supported

by Roderick Colenbrander

On Sat, Mar 26, 2011 at 2:18 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > <0001-wined3d-check-for-ARB_fragment_program-in-arbfp_blit.patch> > > Considering this statement in select_blit_implementation, directx.c: > if ((ps_selected_mode == SHADER_ARB || ps_selected_mode == SHADER_GLSL) > && gl_info->supported[ARB_FRAGMENT_PROGRAM]) return &arbfp_blit; > else return &ffp_blit; > How does wined3d end up using arbfp_blit? > > For some more background see the thread 'wined3d: Prevent crash when blit_priv is NULL' started by Konrad Rzepecki . Essentially because the blitter refactoring is not finished, BltOverride can enter this code. Inside BltOverride there is a 'arb_blit_supported' which at this point returned TRUE, which allowed calling of arb_blit_surface. Roderick

March 26, 2011

Re: wined3d: check for ARB_fragment_program in arbfp_blit_supported

by Stefan Dösinger

> <0001-wined3d-check-for-ARB_fragment_program-in-arbfp_blit.patch> Considering this statement in select_blit_implementation, directx.c: if ((ps_selected_mode == SHADER_ARB || ps_selected_mode == SHADER_GLSL) && gl_info->supported[ARB_FRAGMENT_PROGRAM]) return &arbfp_blit; else return &ffp_blit; How does wined3d end up using arbfp_blit?

March 26, 2011

Re: ole32/tests: Test for correct storage creation.

by Vincent Povirk

> What is this supposed to show? Presumably that those parts of the header are actively reset by StgCreateDocfileOnILockBytes. In fact, it probably makes sense to throw out the initial data in the ILockBytes. I guess it'd help if there were comments explaining what those fields are, so people didn't have to look them up.

March 26, 2011

Re: ole32/tests: Test for correct storage creation.

by Dmitry Timoshkov

Roman Dadkov <romand(a)etersoft.ru> wrote: > + IStorage_Commit(stg, STGC_DEFAULT); > + IStorage_Release(stg); > + GetHGlobalFromILockBytes(ilb, &hMem); It would be helpful to test the results of the above calls too. > + todo_wine > + ok(!memcmp((BYTE*)hMem, StandardMagic, 8), "Incorrect storage creation\n"); > + todo_wine > + ok(!memcmp(((BYTE*)hMem+8), NullableField, 16), "Incorrect storage creation. Field is not reset\n"); > + todo_wine > + ok(!memcmp(((BYTE*)hMem+34), NullableField, 10), "Incorrect storage creation. Field is not reset\n"); What is this supposed to show? -- Dmitry.

March 26, 2011

Re: Ubuntu's next release and raising hard ulimit on ubuntu

by Dan Kegel

Scott wrote: > So it turns out it's not a kernel config issue per se: > >On 03/25/2011 06:05 PM, Tim Gardner wrote: >> The initial hard limit value is not a CONFIG option... >> What is the issue with having upstart set this limit early in the boot >> cycle? Won't all new processes inherit the modified limit? > > If that's a good idea then we need to retarget the bug dank(a)eniac:~$ dpkg-query -S /etc/security/limits.conf libpam-modules: /etc/security/limits.conf That's where the change should go. No need to modify the kernel.

March 26, 2011

Re: Ubuntu's next release and raising hard ulimit on ubuntu

by Scott Ritchie

On 03/25/2011 06:26 AM, Dan Kegel wrote: > Scott, correct me if I'm wrong, but does Natty still have the > hard limit of 1024 files open per process? > If so, should be ask people to go vote for > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663090 > ? > > Getting that limit raised might avoid increasing numbers of > support requests from users who can't figure out why Wine can't run their > p2p downloader ( http://bugs.winehq.org/show_bug.cgi?id=25015 ). > > So it turns out it's not a kernel config issue per se: On 03/25/2011 06:05 PM, Tim Gardner wrote: > The initial hard limit value is not a CONFIG option, so the only way it > can be changed is by carrying a patch in the kernel, something I would > prefer not to do. This is the macro that initializes the hard limit: > > include/linux/fs.h:#define INR_OPEN 1024 /* Initial > setting for nfile rlimits */ > > What is the issue with having upstart set this limit early in the boot > cycle? Won't all new processes inherit the modified limit? > If that's a good idea then we need to retarget the bug -Scott Ritchie

March 26, 2011

Re: urlmon: Use unescaped Urls for FTP actions (try 3)

by Nikolay Sivov

On 3/26/2011 01:22, André Hentschel wrote: > Jacek gave me some advice and we made sure we have no other option to unescape the url. > --- > dlls/urlmon/ftp.c | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/dlls/urlmon/ftp.c b/dlls/urlmon/ftp.c > index c9d43b8..5857818 100644 > --- a/dlls/urlmon/ftp.c > +++ b/dlls/urlmon/ftp.c > @@ -60,12 +60,18 @@ static HRESULT FtpProtocol_open_request(Protocol *prot, IUri *uri, DWORD request > { > FtpProtocol *This = impl_from_Protocol(prot); > BSTR url; > + DWORD len; > HRESULT hres; > > hres = IUri_GetAbsoluteUri(uri,&url); > if(FAILED(hres)) > return hres; > > + len = strlenW(url); No need to slow down with strlenW, it's a BSTR. > + hres = UrlUnescapeW((LPWSTR)url, NULL,&len, URL_UNESCAPE_INPLACE); > + if(FAILED(hres)) > + return hres; > + Leak! And why a cast by the way?

March 25, 2011

[GSoC] Continue work on Games Explorer

by Mariusz Pluciński

Hello, wine-devel In the last year's GSoC, I was working on implementation of Games Explorer features under Wine. I have successfully created it's own interfaces and made them working. However, the task proved harder than I thought before, so I did not create a user-interface part of the library. My idea for this summer is to finish the implementation of gameux.dll - writing the Shell Extension for GE. It would behave almost exact as the Windows equivalent - it should be able to display registered games as shell items, with possibility to run them, see the statistics etc. Having this should give user-experience a great deal. However, in my opinion it would be also a good way to check and extend the existing implementation of shell32. As far as I know, there is currently no real shell extension being part of Wine, so the working one would increase compatibility a much. There will be probably a problem with making my extension usable for user, as there's no working explorer currently in Wine. However, as I see, the implementation of explorer is one of popular proposal this year. In my opinion, it would be good idea to cooperate my work on GE Shell Extension with the person who will implement explorer.exe (if both ideas will be selected for realization). This would probably improve the quality of both projects. Summarizing, my project assumes following things to do: - write testing set to run under Windows. Tests will read the data from GE using it's shell interfaces. - creating stubs for shell interfaces. This will include following interfaces IShellFolder(2/3?), IShellView, IPersistFolder, IEnumIDList, IContextMenu, and probably a few other. I have created some stubs at the end of last GSoC, but never committed them, as they were requiring a few improvements. - implementing interfaces using the existing infrastructure inside of gameux.dll. Routines giving access to list of installed games were written by me last year, but there are still some missing parts which must be filled to let shell interfaces return proper data. - extending and fixing parts of shell32 (or other libraries) if required. This is mostly undefined part of task, but I've listed it here, cause I suppose this could take significant part of project's time. If there will be still time after finishing the points above, I would like to add one feature from my last-year proposal: a legacy games support. When Microsoft introduced the Games Explorer in Vista, they provided a big set of definitions of currently existing games to make them visible in GE, without requirement of modifications in games. My idea is to extend Wine's Application Database to allow it serve as legacy games database for our GE. This would increment an user experience from using the tool. My name is Mariusz Pluciński. I'm 20 years old student of Information Technology in Gdańsk University of Technology in Poland. Last year I was successfully participating in GSoC in Wine project (project name was "Implementation of Windows Game Explorer equivalent "), so my knowledge seems to be enough to continue work with even better results. Comments are welcome -- Best regards Mariusz Pluciński

March 25, 2011

Re: [GSoC] Implementing missing DirectInput8 features

by Lucas Zawacki

The part about semantics is getting clearer to me. Apparently, like Vitality pointed, it's more about relating the joysticks (or "directinput devices") to the various game genres and actions constants defined in the microsoft's dinput.h and then Action Mapping will simply consist of polling all the connect devices and informing the application when a keypress triggers an action. This page http://msdn.microsoft.com/en-us/library/bb172238%28v=vs.85%29.aspx is the best documentation about the subject that I have found until now. Does anyone have another source of info to suggest? -- http://www.twitter.com/lfzawacki http://www.linesocode.wordpress.com

March 25, 2011

Re: GSoC: Implement the Explorer

by Jay Yang

Hi David, Thank you for your reply, I was quite busy yesterday so I didn't get around to responding. Thank you for helping clarify the situation with the explorer. On 03/24/2011 10:51 AM, David Hedberg wrote: > I also just now > quickly fixed up the proof-of-concept "explorer" I hacked up last year > so that it at least compiles on my system (see [2]). It's not > beautiful (neither the code nor the interface), but it might give you > an idea of what the current state of affairs are. It runs on at least > wine and Windows 7, and should also run on Vista. > Yep, I got it to work after some fiddling with include paths, thanks. > The code for creating new explorer windows should probably reside in > explorerframe.dll, somewhat analogous to how this works for the > Internet Explorer and shdocvw.dll. So would implementing explorerframe.dll be a good summer project or is it too large or too small? I haven't been able to find any good documentation on what exactly is implemented by explorerframe.dll, is there any? Thanks -- Jay Yang

March 25, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Tony Zhang

> > When you add a new cpl, the wine build system does this for you. > > So my question is: can I just build one cpl? Or do I need to re-build the entire wine every time I want to test a particular cpl? If I can just build one cpl, how should I build (compile) it and let the existing wine recognize it? > git has a web interface with a history and the first commit for inetcpl.cpl > is a minimalistic control applet. > ( http://source.winehq.org/git/wine.git/history/HEAD:/dlls/inetcpl.cpl ) > > Thanks, that helps a lot. -- Tony (Chi Zhang)

March 25, 2011

Re: Ubuntu's next release and raising hard ulimit on ubuntu

by Dan Kegel

Nope, this isn't about the select() limit. The soft limit on file handles should stay at 1024 so apps that use select() don't break. Apps like wine that have already switched away from select should be able to raise their soft limit if they want more file desciptors. Wine already does this. But ubuntu is misconfigured by default with a hard limit identical to the soft limit. It's time for ubuntu to fix this by raising the default hard limit on file desciptors in /etc/security/limits.conf. Users who need this can edit that file to make their games work, but they shouldn't have to. (Topposted from my cellphone) On Mar 25, 2011 8:03 AM, "Paul Chitescu" <paulc(a)voip.null.ro> wrote: On Friday 25 March 2011 03:26:25 pm Dan Kegel wrote: > Scott, correct me if I'm wrong, but does Natt... This is not an Ubuntu limitation but rather of the (g)libc API implementation. At least on glibc it is possible to increase the FD_SETSIZE at build time. Been there, done that, got the T-shirt. No need for header patching. http://yate.null.ro/websvn/filedetails.php?repname=yate&path=%2Ftrunk%2Feng… Caveat: FD_... operations take longer if FD_SETSIZE is increased. On all relevant platforms it is possible to check if a fd is above the limit. The application code must do so. Best is to internally replace select() with poll() on platforms that support it.

March 25, 2011

Re: Ubuntu's next release and raising hard ulimit on ubuntu

by Paul Chitescu

On Friday 25 March 2011 03:26:25 pm Dan Kegel wrote: > Scott, correct me if I'm wrong, but does Natty still have the > hard limit of 1024 files open per process? > If so, should be ask people to go vote for > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663090 > ? > > Getting that limit raised might avoid increasing numbers of > support requests from users who can't figure out why Wine can't run their > p2p downloader ( http://bugs.winehq.org/show_bug.cgi?id=25015 ). This is not an Ubuntu limitation but rather of the (g)libc API implementation. At least on glibc it is possible to increase the FD_SETSIZE at build time. Been there, done that, got the T-shirt. No need for header patching. http://yate.null.ro/websvn/filedetails.php?repname=yate&path=%2Ftrunk%2Feng… Caveat: FD_... operations take longer if FD_SETSIZE is increased. On all relevant platforms it is possible to check if a fd is above the limit. The application code must do so. Best is to internally replace select() with poll() on platforms that support it.

March 25, 2011

Ubuntu's next release and raising hard ulimit on ubuntu

by Dan Kegel

Scott, correct me if I'm wrong, but does Natty still have the hard limit of 1024 files open per process? If so, should be ask people to go vote for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663090 ? Getting that limit raised might avoid increasing numbers of support requests from users who can't figure out why Wine can't run their p2p downloader ( http://bugs.winehq.org/show_bug.cgi?id=25015 ).

March 25, 2011

Re: [PATCH 07/15] d3dx9: Add ID3DXBaseEffect interface.

by Rico Schüller

Am 24.03.2011 12:12, schrieb Henri Verbeet: > 2011/3/23 Rico Schüller<kgbricola(a)web.de>: >> + FIXME("íface %p, desc %p stub\n", This, desc); > Typo? > Yes, that's a typo. I'll improve the patch and I'll fix all occurrences. Thanks Rico

March 25, 2011

Re: [PATCH 03/15] d3dx9: Use size of variable instead of type.

by Rico Schüller

Am 23.03.2011 12:00, schrieb Nikolay Sivov: > On 3/23/2011 13:49, Rico Schüller wrote: >> --- >> dlls/d3dx9_36/effect.c | 4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> len = MultiByteToWideChar(CP_ACP, 0, srcfile, -1, NULL, 0); >> - srcfileW = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len * >> sizeof(WCHAR)); >> + srcfileW = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len * >> sizeof(*srcfileW)); >> MultiByteToWideChar(CP_ACP, 0, srcfile, -1, srcfileW, len); > No need to zero, if it will be filled with next call. This could a > subject of next patch of course. > > Yeah, I'll send a patch for that one. Thanks for the hint. Cheers Rico

March 25, 2011

Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)

by Joshua Beck

On 03/20/2011 05:42 PM, Stefan Dösinger wrote: > Wrt this specific function we already have some related infrastructure for > D3DXLoadSurfaceFrom* . Also other parts of Wine(gdi32.dll, windowscodecs.dll) > have functions for handling various on-disk file formats which can(and should) > be used. (That's just some generic implementation hint, it doesn't mean that > it makes the idea good or bad) > Is there any documentation I can read on how to program for these DLLs? I've been looking through MSDN and I can't find anything specifically about those DLLs. However I did find Windows Imaging Component (which I think is what windowscodecs.dll implements) and that seems like it would be helpful for the D3DXSaveSurfaceTo* functions.

March 25, 2011

Re: [GSoC] Merge winecfg and Control Panel

by wine.dev＠web.de

Dear Tony Welcome to Wine. > > After all the searches, I still do not have an overall idea of how to > create an control panel applet. From my current understanding, if I put the > cpl (dll) file in "~/.wine/drive_c/windows/system32/", wine control will > recognize it automatically, right? When you add a new cpl, the wine build system does this for you. > If so, is there any instructions on how to build a simple applet under wine > (even one that does nothing could work for me). I'd really like to try > create and build some test applet in order to understand it better. As always: Read the source. What you try to do (test applet) is how i started with inetcpl.cpl a while ago. git has a web interface with a history and the first commit for inetcpl.cpl is a minimalistic control applet. ( http://source.winehq.org/git/wine.git/history/HEAD:/dlls/inetcpl.cpl ) -- by by ... Detlef

March 25, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Vincent Povirk

You can pretty much ignore everything in the actual C source files of appwiz.c except the CPlApplet function. CPL_STARTWPARMSW is unimportant, and all CPL_DBLCLK does is create a window. The only difference from the layout of a normal Windows program is that a control panel applet does not include its own message loop. The caller takes care of that. See also http://msdn.microsoft.com/en-us/library/bb776392%28VS.85%29.aspx

March 25, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Tony Zhang

Dear Owen, > Actually creating a new control panel applet is a fairly straightforward > task. You can look at the existing control panels (appwiz.cpl, inetcpl.cpl) > to get an idea of what's involved > > After all the searches, I still do not have an overall idea of how to create an control panel applet. From my current understanding, if I put the cpl (dll) file in "~/.wine/drive_c/windows/system32/", wine control will recognize it automatically, right? If so, is there any instructions on how to build a simple applet under wine (even one that does nothing could work for me). I'd really like to try create and build some test applet in order to understand it better. Sorry for taking your time. Thanks in advance. Best, -- Tony (Chi Zhang)

March 25, 2011

Re: GSoC: Implement the Explorer

by John Klehm

On Thu, Mar 24, 2011 at 9:51 AM, David Hedberg <david.hedberg(a)gmail.com> wrote: > Hi Jay, > > On Thu, Mar 24, 2011 at 05:16, Jay Yang <jkelleyy(a)gmail.com> wrote: > As for TortoiseSVN I don't dare speak for what others might find > useful or how far we are from having that working, but in general Pretty much a drop in linux replacement for tortoise is RabbitVCS: http://www.rabbitvcs.org/

March 25, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Tony Zhang

Dear Owen, > Actually creating a new control panel applet is a fairly straightforward > task. You can look at the existing control panels (appwiz.cpl, inetcpl.cpl) > to get an idea of what's involved > > I have looked at the two existing applets, but got a little confused by the variable names and the organization of the files (the call chain). I'm able to find some documents talking about how to create control panel applet in Windows CE (haven't got time to read them through). Is that similar to creating cpl in wine? -- Tony (Chi Zhang)

March 25, 2011

Re: wine 1.3.16: wrc compiler and LANGUAGE

by Austin English

On Thu, Mar 24, 2011 at 14:25, Gilles Depeyrot <gsd(a)dolphin.fr> wrote: > On 24/03/2011 08:06, Dmitry Timoshkov wrote: >> >> Gilles Depeyrot<gsd(a)dolphin.fr> wrote: >>> >>> Has there been a change between wine 1.2.2 and wine 1.3.x that would >>> require adding an include file that was previously not needed? >> >> I don't think so. Including windef.h and winuser.h should be enough. >> If you could provide a small .rc file and command line you are using >> that would help in figuring out the problem. > > With the attached files and the following command line the resource file is > compiled using wine 1.2.2 and fails using wine 1.3.16. > > wrc -I$WINEHOME/include/wine/msvcrt -I$WINEHOME/include/windows -fofoo.res > foo.rc Using git bisect run ./wrc.sh: #!/bin/bash ./configure --disable-tests || exit 125 make -j15 || exit 125 ./tools/wrc/wrc -I$WINEHOME/include/wine/msvcrt -I$WINEHOME/include/windows -fofoo.res foo.rc revealed the bad commit to be: e6340f1652e0328bbfeeae58462f41400b09b38a is the first bad commit commit e6340f1652e0328bbfeeae58462f41400b09b38a Author: Alexandre Julliard <julliard(a)winehq.org> Date: Wed Sep 29 20:13:28 2010 +0200 wrc: Add support for target options, and define _WIN64 for 64-bit builds. :040000 040000 af53e5447fca71246cd4f4ec1cd91887f6c3eee2 19d82ada48a0b03253cf7a315cfd656f7c6c4be3 M tools though this belongs in bugzilla, not wine-devel. -- -Austin

March 24, 2011

Re: GSoC: Implement the Explorer

by David Hedberg

Hi Jay, On Thu, Mar 24, 2011 at 05:16, Jay Yang <jkelleyy(a)gmail.com> wrote: > Hello, > > Since my first proposal got no response at all, I thought I'd offer > another possible project I'm interested in. I looked a little into the > "Implement the Explorer" project idea listed on the Summer of Code page on > the wine wiki. I have a few questions as to what parts need to be > implemented. Clearly, as stated by the description on the Summer of Code > page, we have winefile, which does some of the things expected of explorer, > but how far is winefile from a correct explorer implementation? Also would > implementing Shell Extensions be a good Summer of Code project? In > particular, I think it would be nice to have things like TortiseSVN working > in wine. > I think winefile is pretty much a dead end as far as "correct" Explorer implementations go. Assuming that we want something as close to the native architecture as possible, the main functionality of the windows explorer lies in libraries ( shell32.dll, explorerframe.dll, ..), used through COM. I did some work in this area last year, which resulted in an implementation of the ExplorerBrowser control (see the documentation for IExplorerBrowser on msdn [1]). I also just now quickly fixed up the proof-of-concept "explorer" I hacked up last year so that it at least compiles on my system (see [2]). It's not beautiful (neither the code nor the interface), but it might give you an idea of what the current state of affairs are. It runs on at least wine and Windows 7, and should also run on Vista. The code for creating new explorer windows should probably reside in explorerframe.dll, somewhat analogous to how this works for the Internet Explorer and shdocvw.dll. As for TortoiseSVN I don't dare speak for what others might find useful or how far we are from having that working, but in general there's no lack of things in the shell subsystem that could use some attention. Having explorer implemented and somewhat working would undoubtedly also lead to more of these shortcomings surfacing and hopefully getting some attention. [1] http://msdn.microsoft.com/en-us/library/bb761909%28v=vs.85%29.aspx [2] http://inget.dyndns.org:9999/wine_explorer/ -- David

March 24, 2011

Re: wine 1.3.16: wrc compiler and LANGUAGE

by Gilles Depeyrot

On 24/03/2011 08:06, Dmitry Timoshkov wrote: > Gilles Depeyrot<gsd(a)dolphin.fr> wrote: >> Has there been a change between wine 1.2.2 and wine 1.3.x that would >> require adding an include file that was previously not needed? > I don't think so. Including windef.h and winuser.h should be enough. > If you could provide a small .rc file and command line you are using > that would help in figuring out the problem. With the attached files and the following command line the resource file is compiled using wine 1.2.2 and fails using wine 1.3.16. wrc -I$WINEHOME/include/wine/msvcrt -I$WINEHOME/include/windows -fofoo.res foo.rc Best regards, Gilles

March 24, 2011

Re: [GSoC] Implementing missing DirectInput8 features

by Vitaliy Margolen

On 03/23/2011 02:52 PM, Lucas Zawacki wrote: > Hello, I'm Lucas Fialho Zawacki a Computer Science undergrad at UFRGS > university in Brazil. I'm very interested in working with Wine for the > Google Summer of Code and have decided to approach the implementation > of DirectInput8 missing features. Welcome to Wine development! > At the moment, I don't have a clear understanding of how the > implementation should be done There are number of things that are missing in Wine's dinput8. Two that are mentioned on ideas page - Action Mapping and Enumeration by Semantics are more of data gathering then much coding. Of course there are number of stubs that could be implemented as well. Vitaliy.

March 24, 2011

Re: browseui/tests: COM cleanup in autocomplete.c.

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=10131 Your paranoid android. === WNT4WSSP6 (32 bit autocomplete) === autocomplete.c:250: Test failed: CoCreateInstance(&CLSID_ACLMulti, NULL, CLSCTX_INPROC, &IID_IEnumString, (LPVOID *)&obj) failed: 80040154

March 24, 2011

Re: [PATCH 07/15] d3dx9: Add ID3DXBaseEffect interface.

by Henri Verbeet

2011/3/23 Rico Schüller <kgbricola(a)web.de>: > + FIXME("íface %p, desc %p stub\n", This, desc); Typo?

March 24, 2011

Re: wine 1.3.16: wrc compiler and LANGUAGE

by Dmitry Timoshkov

[please bottom post] Gilles Depeyrot <gsd(a)dolphin.fr> wrote: > Has there been a change between wine 1.2.2 and wine 1.3.x that would > require adding an include file that was previously not needed? I don't think so. Including windef.h and winuser.h should be enough. If you could provide a small .rc file and command line you are using that would help in figuring out the problem. -- Dmitry.

March 24, 2011

Re: wine 1.3.16: wrc compiler and LANGUAGE

by Gilles Depeyrot

Hi, Has there been a change between wine 1.2.2 and wine 1.3.x that would require adding an include file that was previously not needed? Thanks, Gilles On 24/03/2011 06:29, Dmitry Timoshkov wrote: > Jerome Leclanche<adys.wh(a)gmail.com> wrote: > >> I don't think SUBLANG_FRENCH is valid in rc files. Have you tried >> SUBLANG_NEUTRAL? > SUBLANG_FRENCH is valid, probably he is missing some include files. > -- Gilles Depeyrot - MEDAL Development Manager DOLPHIN Integration "The Enabler of mixed signal Systems-on-Chip" BP 65 Inovallée F-38240 Meylan FRANCE Tel: +33 (0)476 41 74 01 Fax: +33 (0)476 90 29 65 mailto:gsd(a)dolphin-integration.com http://www.dolphin-integration.com

March 24, 2011

Re: wine 1.3.16: wrc compiler and LANGUAGE

by Gilles Depeyrot

Hi, It is valid for the Microsoft resource compiler and also for wine 1.2.2. Gilles On 23/03/2011 23:54, Jerome Leclanche wrote: > I don't think SUBLANG_FRENCH is valid in rc files. Have you tried > SUBLANG_NEUTRAL? > > > J. Leclanche > > > > On Wed, Mar 23, 2011 at 9:54 AM, Gilles Depeyrot<gsd(a)dolphin.fr> wrote: >> Hi, >> >> I am testing compiling an application that uses winelib with 1.3.16 >> (currently compiled with 1.2.2). >> >> I have an issue with the resource compiler (wrc) which doesn't understand >> the LANGUAGE line. When I compile resource files, I get errors resembling: >> >> file.rc:22:21: Error: syntax error >> >> The corresponding line in the file is: >> >> LANGUAGE LANG_FRENCH, SUBLANG_FRENCH >> >> If I comment the line, the compilation succeeds. >> >> Best regards, >> Gilles >> >> >> -- Gilles Depeyrot - MEDAL Development Manager DOLPHIN Integration "The Enabler of mixed signal Systems-on-Chip" BP 65 Inovallée F-38240 Meylan FRANCE Tel: +33 (0)476 41 74 01 Fax: +33 (0)476 90 29 65 mailto:gsd(a)dolphin-integration.com http://www.dolphin-integration.com

March 24, 2011

Re: wine 1.3.16: wrc compiler and LANGUAGE

by Dmitry Timoshkov

Jerome Leclanche <adys.wh(a)gmail.com> wrote: > I don't think SUBLANG_FRENCH is valid in rc files. Have you tried > SUBLANG_NEUTRAL? SUBLANG_FRENCH is valid, probably he is missing some include files. -- Dmitry.

March 24, 2011

GSoC: Implement the Explorer

by Jay Yang

Hello, Since my first proposal got no response at all, I thought I'd offer another possible project I'm interested in. I looked a little into the "Implement the Explorer" project idea listed on the Summer of Code page on the wine wiki. I have a few questions as to what parts need to be implemented. Clearly, as stated by the description on the Summer of Code page, we have winefile, which does some of the things expected of explorer, but how far is winefile from a correct explorer implementation? Also would implementing Shell Extensions be a good Summer of Code project? In particular, I think it would be nice to have things like TortiseSVN working in wine. Thanks -- Jay Yang

March 24, 2011

Re: winex11.drv/opengl.c: add improved error handling to pglXMakeCurrent() call

by Chris Robinson

On Wednesday, March 23, 2011 9:00:25 PM Joshua Beck wrote: > This patch was made against the origin, so if you've applied my previous > patch, remove that one before applying this one. > This patch makes the error message use ERR_(winediag) instead of just > ERR and is closer in style to the other error messages in opengl.c. There's some trailing whitespace in the patch.

March 24, 2011

Re: winex11.drv/opengl.c: add error handling to pglXMakeCurrent() call

by Roderick Colenbrander

Hi Joshua, Was about to submit a similar patch (had a few tiny fixes in my tree left), but this patch is mostly fine with me. Except I would print to 'winediag' like some of the other errors for software / indirect rendering are doing. So do something like 'Unable to active OpenGL context, like something your drivers have not been configured properly' (look what the other messages are like). Roderick On Thu, Mar 24, 2011 at 2:34 AM, Joshua Beck <jxb091000(a)utdallas.edu> wrote: > This patch should make it easier for those with driver problems to find the > problem when running Wine. > --Josh > > > >

March 24, 2011

Re: Duplicate AppDB Entry

by Rosanne DiMesio

On Wed, 23 Mar 2011 17:57:01 -0700 Jeremy Nowka <jnowka(a)gmail.com> wrote: > "Barnes And Noble EReader" v2.5 and "Nook for PC" are the same program. I > feel that the two AppDB entries should be combined for easier access by the > general public. I feel that the information should be merged to "Nook for > PC" because this is the common name for version 2.5. The version number for > "Nook for PC" should be changed to reflect the actual version, 2.5. Done. -- Rosanne DiMesio <dimesio(a)earthlink.net>

March 24, 2011

Duplicate AppDB Entry

by Jeremy Nowka

"Barnes And Noble EReader" v2.5 and "Nook for PC" are the same program. I feel that the two AppDB entries should be combined for easier access by the general public. I feel that the information should be merged to "Nook for PC" because this is the common name for version 2.5. The version number for "Nook for PC" should be changed to reflect the actual version, 2.5.

March 24, 2011

Re: wine 1.3.16: wrc compiler and LANGUAGE

by Jerome Leclanche

I don't think SUBLANG_FRENCH is valid in rc files. Have you tried SUBLANG_NEUTRAL? J. Leclanche On Wed, Mar 23, 2011 at 9:54 AM, Gilles Depeyrot <gsd(a)dolphin.fr> wrote: > Hi, > > I am testing compiling an application that uses winelib with 1.3.16 > (currently compiled with 1.2.2). > > I have an issue with the resource compiler (wrc) which doesn't understand > the LANGUAGE line. When I compile resource files, I get errors resembling: > > file.rc:22:21: Error: syntax error > > The corresponding line in the file is: > > LANGUAGE LANG_FRENCH, SUBLANG_FRENCH > > If I comment the line, the compilation succeeds. > > Best regards, > Gilles > > >

March 23, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Adam Martinson

On 03/22/2011 01:33 PM, Henri Verbeet wrote: > How much of a real difference does this patch make, after you > avoid the redundant lookups? (I.e., after the second patch in this > series.) In that case the additional reduction in context_apply_fbo_state() CPU time from the 1st patch is only about 10%.

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by David Laight

On Wed, Mar 23, 2011 at 01:31:09PM -0700, Scott Ritchie wrote: > On 03/23/2011 07:15 AM, Dan Kegel wrote: > > Also... it would be nice if there were a central commandline > > way of changing wine settings, kind of like 'net' is a central > > way of manipulating networking. > > > > I've been thinking that winecfg should have a commandline > > interface, too, and making it accept winetricks settings > > directly. Something like that would also make a good soc project. > > > > > > I remember proposing this idea long ago as I would have found it useful > for front end user interfaces. It is worth remembering that an elf program's 'main' can be in a shared object! This mightmake it easier to write a stub binary that effectively make a .so executable. Sort of depends on what the guy way tring to do... David -- David Laight: david(a)l8s.co.uk

March 23, 2011

[GSoC] Implementing missing DirectInput8 features

by Lucas Zawacki

Hello, I'm Lucas Fialho Zawacki a Computer Science undergrad at UFRGS university in Brazil. I'm very interested in working with Wine for the Google Summer of Code and have decided to approach the implementation of DirectInput8 missing features. I'm a long time Wine user, but I'd never looked at it from a developer point of view, so for the past few days I have been reading Wine's developer documentation and familiarizing myself with it's architecture and with the parts I intend to work on. At the moment, I don't have a clear understanding of how the implementation should be done so I'm reading a lot of material about dinput and dinput8 and building some documentation to help me. After some polishing I hope to be able to contribute it to Wine too. A little word about me. I've been using the C programming language for almost three years, so I'm very familiar with it. For the last two years I've worked on a research project as a C/C++ programmer, implementing a decision system for a F180 Small Size League Robot Soccer Team (see http://small-size.informatik.uni-bremen.de/) and http://code.google.com/p/robopet/ . I'm a heavy Linux user and I'm very comfortable with it's tools used for programming. That's it. I'm eager to get your feedback about this. My proposal will be ready in a few days. -- http://www.twitter.com/lfzawacki http://www.linesocode.wordpress.com

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Scott Ritchie

On 03/23/2011 07:15 AM, Dan Kegel wrote: > Also... it would be nice if there were a central commandline > way of changing wine settings, kind of like 'net' is a central > way of manipulating networking. > > I've been thinking that winecfg should have a commandline > interface, too, and making it accept winetricks settings > directly. Something like that would also make a good soc project. > > I remember proposing this idea long ago as I would have found it useful for front end user interfaces. It's what lead to the creation of the python-wine library by Christian Dannie Stroggard, which is a part of the vineyard project now. I suggest anyone having this need/considering implementing this give that a look. -Scott Ritchie

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Jerome Leclanche

Winetricks uses the registry. It creates temporary .reg files and feeds them to regedit. J. Leclanche On Wed, Mar 23, 2011 at 6:15 PM, Tony Zhang <niu.tony.c.zhang(a)gmail.com> wrote: > Now I see what you meant. That really is a nice feature to do something like > "winecfg vd=1024x768". > I'll see if I can understand how winetricks accomplish that. > > > On Wed, Mar 23, 2011 at 1:05 PM, Dan Kegel <dank(a)kegel.com> wrote: >> >> Winetricks is a simple script that adds a few mssing things to wine, e.g. >> it's how most people install ms dlls or .net on wine. It also provides a >> simple commandline way to change a few settings. For instance, winetricks >> vd=1024x768 sets a 1024x768 virtual desktop... it'd be nice if one could >> instead do winecfg vd=1024x768 or something like that. >> >> See also http://winetricks.org. > > > >

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Tony Zhang

Now I see what you meant. That really is a nice feature to do something like "winecfg vd=1024x768". I'll see if I can understand how winetricks accomplish that. On Wed, Mar 23, 2011 at 1:05 PM, Dan Kegel <dank(a)kegel.com> wrote: > Winetricks is a simple script that adds a few mssing things to wine, e.g. > it's how most people install ms dlls or .net on wine. It also provides a > simple commandline way to change a few settings. For instance, winetricks > vd=1024x768 sets a 1024x768 virtual desktop... it'd be nice if one could > instead do winecfg vd=1024x768 or something like that. > > See also http://winetricks.org. >

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Dan Kegel

Winetricks is a simple script that adds a few mssing things to wine, e.g. it's how most people install ms dlls or .net on wine. It also provides a simple commandline way to change a few settings. For instance, winetricks vd=1024x768 sets a 1024x768 virtual desktop... it'd be nice if one could instead do winecfg vd=1024x768 or something like that. See also http://winetricks.org. On Mar 23, 2011 10:36 AM, "Tony Zhang" <niu.tony.c.zhang(a)gmail.com> wrote: Dear Dan, I agree that it would be nice to have a command-line interface for wine settings cause I have run into situations that I have to configure wine before going into X. So is it possible to first group/rearrange winecfg functions into certain libraries and then let the GUI (control panel) and the CLI all interact with the corresponding libraries? About winetricks, I do not know much about it. What exactly do you mean by "winetricks settings"? -- Tony (Chi Zhang) On Wed, Mar 23, 2011 at 9:15 AM, Dan Kegel <dank(a)kegel.com> wrote: > > Also... it would be nice i...

March 23, 2011

Re: Wine compatibility

by Juan Lang

> What I meant as 'clean start' is that they could drop all hacks in 64bit > environment. I wonder if that happened. Speculating whether MS would have done this is probably not a very useful exercise. Still, I'd say it's exceedingly improbable: 1. The cost of reviewing all the code for what might be a hack is high, and what's the benefit? Less code to maintain can't be an answer, because the 32-bit versions of Windows still need the hacks. 2. Apps written for 64-bit Windows aren't created in a vacuum: they're probably ported from a 32-bit codebase first, or 32-bit and 64-bit versions are co-developed. The same, possibly erroneous assumptions that a 32-bit application might make would therefore need to be maintained in a 64-bit version. A better place to ask questions like these might be http://blogs.msdn.com/b/oldnewthing/ --Juan

March 23, 2011

Re: Wine compatibility

by Austin English

2011/3/23 Adam Kłobukowski <adamklobukowski(a)gmail.com>: > On 23.03.2011 16:01, James McKenzie wrote: >> >> On 3/23/11, Adam Kłobukowski<adamklobukowski(a)gmail.com> wrote: >>> >>> Hello >>> >>> I have a question for Wine developers, not 100% related to development, >>> so: please excuse me for wasting your time. >>> >>> Officially sated, Wine wants to be 'bug-by-bug' implementation of >>> Windows APIs. On the other hand, it is known that all (?) version of >>> Windows contain 'hacks' to make important and not well behaving >>> applications work (mostly workarounds for application bugs). This >>> 'hacks' work by detecting that a faulty app is running, and turning >>> special 'hack' mode for such app. Because of this, black box testing >>> often used by Wine developers will not detect such workarounds, and >>> applications that (seem to) work perfectly well under Windows, will not >>> work under Wine. >>> >> And some programs that worked 'just fine' under WindowsXP will not in >> any other version due to the internal hacks. >> >>> Is there a solution for this? What is Wine devs position on this matter? >> >> Sure. We look at the interaction between the program and the Windows >> API (this is how true Black Box testing is done), implement a test >> case and then build code to the test case. >> >>> >>> Side question: Windows could make a 'clean start' with 64 bit >>> environment, did they? >> >> If that happened, there would have not been any version of Windows >> with 64 bitness for about twenty years. Microsoft 'extended' their >> code to work in a 64 bit environment. This is common with existing 32 >> bit code to extend it to 64 bits. > > What I meant as 'clean start' is that they could drop all hacks in 64bit > environment. I wonder if that happened. Looking at the results from the wine test suite on 64-bit, I'd say no. -- -Austin

March 23, 2011

Re: Wine compatibility

by Adam Kłobukowski

On 23.03.2011 16:01, James McKenzie wrote: > On 3/23/11, Adam Kłobukowski<adamklobukowski(a)gmail.com> wrote: >> Hello >> >> I have a question for Wine developers, not 100% related to development, >> so: please excuse me for wasting your time. >> >> Officially sated, Wine wants to be 'bug-by-bug' implementation of >> Windows APIs. On the other hand, it is known that all (?) version of >> Windows contain 'hacks' to make important and not well behaving >> applications work (mostly workarounds for application bugs). This >> 'hacks' work by detecting that a faulty app is running, and turning >> special 'hack' mode for such app. Because of this, black box testing >> often used by Wine developers will not detect such workarounds, and >> applications that (seem to) work perfectly well under Windows, will not >> work under Wine. >> > And some programs that worked 'just fine' under WindowsXP will not in > any other version due to the internal hacks. > >> Is there a solution for this? What is Wine devs position on this matter? > > Sure. We look at the interaction between the program and the Windows > API (this is how true Black Box testing is done), implement a test > case and then build code to the test case. > >> >> Side question: Windows could make a 'clean start' with 64 bit >> environment, did they? > > If that happened, there would have not been any version of Windows > with 64 bitness for about twenty years. Microsoft 'extended' their > code to work in a 64 bit environment. This is common with existing 32 > bit code to extend it to 64 bits. What I meant as 'clean start' is that they could drop all hacks in 64bit environment. I wonder if that happened. Adam Klobukowski

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Tony Zhang

Dear Dan, I agree that it would be nice to have a command-line interface for wine settings cause I have run into situations that I have to configure wine before going into X. So is it possible to first group/rearrange winecfg functions into certain libraries and then let the GUI (control panel) and the CLI all interact with the corresponding libraries? About winetricks, I do not know much about it. What exactly do you mean by "winetricks settings"? -- Tony (Chi Zhang) On Wed, Mar 23, 2011 at 9:15 AM, Dan Kegel <dank(a)kegel.com> wrote: > Also... it would be nice if there were a central commandline > way of changing wine settings, kind of like 'net' is a central > way of manipulating networking. > > I've been thinking that winecfg should have a commandline > interface, too, and making it accept winetricks settings > directly. Something like that would also make a good soc project. >

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Tony Zhang

Dear Owen, Thank you for pointing me to those information. I'll take a look at those and try to figure out the process of making control panel applets. Unfortunately, I have no background in Windows programming, but I do want to get some through this project. -- Tony (Chi Zhang) On Wed, Mar 23, 2011 at 6:34 AM, Owen Rudge <owen(a)owenrudge.net> wrote: > Hi Tony, > > > I have briefly walked through Owen Rudge's code of splitting out the >> Desktop Integration tab into its own control panel, but have no luck in >> getting a decent understanding of it. So I'm hoping some of you can >> point me to some documents that related to this task so I can have an >> overall understanding of the challenges of this task. >> > > Actually creating a new control panel applet is a fairly straightforward > task. You can look at the existing control panels (appwiz.cpl, inetcpl.cpl) > to get an idea of what's involved, or consult MSDN for more information ( > http://tinyurl.com/6yu7cw4) If you've not got a background in Windows > programming already, it may of course take a little longer to figure > everything out. > > More complicated is actually working out how to split up winecfg > effectively, and how to do so in a way that doesn't result in unnecessary > code duplication, otherwise you'll likely find it difficult to actually get > your code into the project. > > I would say that there's certainly potential for a project here, if you can > flesh it out - I do think a unified control panel containing all of Wine's > configuration options would be a good thing, rather than the current > situation where options are scattered between the control panel, winecfg, > etc. The key will be figuring out what you want to do, how you're going to > achieve it, and making sure it will be acceptable to the wider Wine > community. > > Regards, > > -- > Owen Rudge > http://www.owenrudge.net/ >

March 23, 2011

Re: [1/2] uxtheme: Add OpenThemeDataEx (try 2)

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > Applied Dmitry's suggestions > -HTHEME WINAPI OpenThemeData(HWND hwnd, LPCWSTR pszClassList) > +HTHEME WINAPI OpenThemeDataEx(HWND hwnd, LPCWSTR classlist, DWORD flags) > { > - WCHAR szAppBuff[256]; > - WCHAR szClassBuff[256]; > - LPCWSTR pszAppName; > - LPCWSTR pszUseClassList; > + WCHAR appbuff[256]; > + WCHAR classbuff[256]; > + LPCWSTR appname; > + LPCWSTR useclasslist; > HTHEME hTheme = NULL; You are changing too much. Just use lowercase named variables for new code, not touching existing ones. > - TRACE("(%p,%s)\n", hwnd, debugstr_w(pszClassList)); > + TRACE("(%p,%s, %u)\n", hwnd, debugstr_w(classlist), flags); flags above is still printed in decimal. > + > + if(flags) > + FIXME("unhandled Flags: %x\n", flags); -- Dmitry.

March 23, 2011

Re: Wine compatibility

by James McKenzie

On 3/23/11, Adam Kłobukowski <adamklobukowski(a)gmail.com> wrote: > Hello > > I have a question for Wine developers, not 100% related to development, > so: please excuse me for wasting your time. > > Officially sated, Wine wants to be 'bug-by-bug' implementation of > Windows APIs. On the other hand, it is known that all (?) version of > Windows contain 'hacks' to make important and not well behaving > applications work (mostly workarounds for application bugs). This > 'hacks' work by detecting that a faulty app is running, and turning > special 'hack' mode for such app. Because of this, black box testing > often used by Wine developers will not detect such workarounds, and > applications that (seem to) work perfectly well under Windows, will not > work under Wine. > And some programs that worked 'just fine' under WindowsXP will not in any other version due to the internal hacks. > Is there a solution for this? What is Wine devs position on this matter? Sure. We look at the interaction between the program and the Windows API (this is how true Black Box testing is done), implement a test case and then build code to the test case. > > Side question: Windows could make a 'clean start' with 64 bit > environment, did they? If that happened, there would have not been any version of Windows with 64 bitness for about twenty years. Microsoft 'extended' their code to work in a 64 bit environment. This is common with existing 32 bit code to extend it to 64 bits. James McKenzie

March 23, 2011

Re: Wine compatibility

by Juan Lang

> Is there a solution for this? Sure: black-box reverse engineer how MS is detecting the apps and enabling the hacks, create test cases showing that they exist, and implement them ourselves. --Juan

March 23, 2011

re: [GSoC] Merge winecfg and Control Panel

by Dan Kegel

Also... it would be nice if there were a central commandline way of changing wine settings, kind of like 'net' is a central way of manipulating networking. I've been thinking that winecfg should have a commandline interface, too, and making it accept winetricks settings directly. Something like that would also make a good soc project.

March 23, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Owen Rudge

Hi Tony, > I have briefly walked through Owen Rudge's code of splitting out the > Desktop Integration tab into its own control panel, but have no luck in > getting a decent understanding of it. So I'm hoping some of you can > point me to some documents that related to this task so I can have an > overall understanding of the challenges of this task. Actually creating a new control panel applet is a fairly straightforward task. You can look at the existing control panels (appwiz.cpl, inetcpl.cpl) to get an idea of what's involved, or consult MSDN for more information (http://tinyurl.com/6yu7cw4) If you've not got a background in Windows programming already, it may of course take a little longer to figure everything out. More complicated is actually working out how to split up winecfg effectively, and how to do so in a way that doesn't result in unnecessary code duplication, otherwise you'll likely find it difficult to actually get your code into the project. I would say that there's certainly potential for a project here, if you can flesh it out - I do think a unified control panel containing all of Wine's configuration options would be a good thing, rather than the current situation where options are scattered between the control panel, winecfg, etc. The key will be figuring out what you want to do, how you're going to achieve it, and making sure it will be acceptable to the wider Wine community. Regards, -- Owen Rudge http://www.owenrudge.net/

March 23, 2011

Re: [PATCH 03/15] d3dx9: Use size of variable instead of type.

by Nikolay Sivov

On 3/23/2011 13:49, Rico Schüller wrote: > --- > dlls/d3dx9_36/effect.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > len = MultiByteToWideChar(CP_ACP, 0, srcfile, -1, NULL, 0); > - srcfileW = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len * sizeof(WCHAR)); > + srcfileW = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len * sizeof(*srcfileW)); > MultiByteToWideChar(CP_ACP, 0, srcfile, -1, srcfileW, len); No need to zero, if it will be filled with next call. This could a subject of next patch of course.

March 23, 2011

Re: [PATCH 2/4] comdlg32: Add stub implementation of the Common Item dialogs.

by Nikolay Sivov

On 3/23/2011 00:43, David Hedberg wrote: > >> By the way, IFileSaveDialog is based on IFileDialog, and you add >> IFileDialog2 too. It's a bit messy, >> does target class object that will use FileDialogImpl really respond to >> IFileDialog2? >> > I'm not completely sure I understand the question, but the same thing > goes for the IFileOpenDialog. Yeah, I didn't mean to distinguish them, IFileSaveDialog was as an example. > I just rechecked on Windows 7, and both > the IFileSaveDialog and the IFileOpenDialog can be successfully > queried for the IFileDialog2 interface. There are tests for that in > the test patch I sent, sort of, although the E_NOINTERFACE case is > merely marked as broken for the sake of Vista. Ok, fine then. It's also better to get rid of casts like: > +static HRESULT WINAPI IFileOpenDialog_fnSetFileTypeIndex(IFileOpenDialog *iface, UINT iFileType) > +{ > + FileDialogImpl *This = impl_from_IFileOpenDialog(iface); > + return IFileDialog2_SetFileTypeIndex((IFileDialog2*)This, iFileType); > +} > + and use &This->IFileDialog2_iface.

March 23, 2011

wine 1.3.16: wrc compiler and LANGUAGE

by Gilles Depeyrot

Hi, I am testing compiling an application that uses winelib with 1.3.16 (currently compiled with 1.2.2). I have an issue with the resource compiler (wrc) which doesn't understand the LANGUAGE line. When I compile resource files, I get errors resembling: file.rc:22:21: Error: syntax error The corresponding line in the file is: LANGUAGE LANG_FRENCH, SUBLANG_FRENCH If I comment the line, the compilation succeeds. Best regards, Gilles

March 23, 2011

Wine compatibility

by Adam Kłobukowski

Hello I have a question for Wine developers, not 100% related to development, so: please excuse me for wasting your time. Officially sated, Wine wants to be 'bug-by-bug' implementation of Windows APIs. On the other hand, it is known that all (?) version of Windows contain 'hacks' to make important and not well behaving applications work (mostly workarounds for application bugs). This 'hacks' work by detecting that a faulty app is running, and turning special 'hack' mode for such app. Because of this, black box testing often used by Wine developers will not detect such workarounds, and applications that (seem to) work perfectly well under Windows, will not work under Wine. Is there a solution for this? What is Wine devs position on this matter? Side question: Windows could make a 'clean start' with 64 bit environment, did they? Thank you for your time. Adam Klobukowski

March 23, 2011

[GSoC] Merge winecfg and Control Panel

by Tony Zhang

Hi everyone, I am a senior student double majoring in Computer Science and Math at Northern Illinois University (currently applying the CS Master Program at NIU) and I would like to participate in merging winecfg and control panel through the Google Summer of Code program. I have used wine since wine 0.9 and 'm now using wine 1.3. I like the idea that all config tools should be grouped and managed at one place, and it would be nice to have them similar to the classical windows control panel (like the control panel in wine 1.3). About my programming background, I believe I know (and love) C the best. I have not had any internships before, but I'm currently working as an undergraduate Research Assistant at NIU. It is a Proton Computed Tomography (Proton CT) project and the main language in use is C, so I do have some experience of using C in a large-scale project. I have briefly walked through Owen Rudge's code of splitting out the Desktop Integration tab into its own control panel, but have no luck in getting a decent understanding of it. So I'm hoping some of you can point me to some documents that related to this task so I can have an overall understanding of the challenges of this task. Sincerely, -- Tony (Chi Zhang)

March 23, 2011

Re: Question

by Andrew Green

There are no teams in gsoc. Each person has to work individually on the project they choose. How it works is that the organisation pick projects it approves of. Then these projects are sent to google. Google takes into account various factors to decide how many projects get selected. On Mar 23, 2011 12:24 AM, "Sanket Patel" <sanketpatel.com(a)gmail.com> wrote: > > How Teams Are Formed in Google Summer Of Code For Any Project. > Is It Formed By Organization Or Google ? > > -- > " Live 2 Love and Love 2 Live " > > >

March 22, 2011

Re: [PATCH 2/4] comdlg32: Add stub implementation of the Common Item dialogs.

by David Hedberg

>> On Mon, Mar 21, 2011 at 14:55, Nikolay Sivov<bunglehead(a)gmail.com> wrote: > > I think it is, it makes it clear that dialogue instance is about save or > open, not both. > Ok, I'll change that. > By the way, IFileSaveDialog is based on IFileDialog, and you add > IFileDialog2 too. It's a bit messy, > does target class object that will use FileDialogImpl really respond to > IFileDialog2? > I'm not completely sure I understand the question, but the same thing goes for the IFileOpenDialog. I just rechecked on Windows 7, and both the IFileSaveDialog and the IFileOpenDialog can be successfully queried for the IFileDialog2 interface. There are tests for that in the test patch I sent, sort of, although the E_NOINTERFACE case is merely marked as broken for the sake of Vista.

March 22, 2011

Re: [PATCH 2/4] comdlg32: Add stub implementation of the Common Item dialogs.

by Nikolay Sivov

On 3/22/2011 23:24, David Hedberg wrote: > On Mon, Mar 21, 2011 at 14:55, Nikolay Sivov<bunglehead(a)gmail.com> wrote: > >>> +typedef struct FileDialogImpl { >>> + IFileDialog2 IFileDialog2_iface; >>> + IFileOpenDialog IFileOpenDialog_iface; >>> + IFileSaveDialog IFileSaveDialog_iface; >>> + LONG ref; >>> +} FileDialogImpl; >> Maybe it's better to use a union and enum type field here, if it can't be >> open and save at the same time. > At the moment I'm checking the vtbl pointers to determine which type > of dialog it is in QueryInterface, although this looked better using > the old COM coding style (no explicit check necessary). > > Is using a union and an explicit type field preferred? I think it is, it makes it clear that dialogue instance is about save or open, not both. By the way, IFileSaveDialog is based on IFileDialog, and you add IFileDialog2 too. It's a bit messy, does target class object that will use FileDialogImpl really respond to IFileDialog2? >>> + >>> + fdimpl = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, >>> sizeof(FileDialogImpl)); >>> + if(!fdimpl) >>> + return E_OUTOFMEMORY; >> Zero initialization is useless here. > As mentioned above it's not completely useless currently, but I can > initialize them explicitly. Sure, that's what I meant. No need to initialize whole struct if you need only 'ref' to be 0 before QueryInterface. > Thanks for the review.

March 22, 2011

Re: [PATCH 2/4] comdlg32: Add stub implementation of the Common Item dialogs.

by David Hedberg

On Mon, Mar 21, 2011 at 14:55, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> +typedef struct FileDialogImpl { >> + IFileDialog2 IFileDialog2_iface; >> + IFileOpenDialog IFileOpenDialog_iface; >> + IFileSaveDialog IFileSaveDialog_iface; >> + LONG ref; >> +} FileDialogImpl; > > Maybe it's better to use a union and enum type field here, if it can't be > open and save at the same time. At the moment I'm checking the vtbl pointers to determine which type of dialog it is in QueryInterface, although this looked better using the old COM coding style (no explicit check necessary). Is using a union and an explicit type field preferred? >> + >> + fdimpl = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, >> sizeof(FileDialogImpl)); >> + if(!fdimpl) >> + return E_OUTOFMEMORY; > > Zero initialization is useless here. As mentioned above it's not completely useless currently, but I can initialize them explicitly. Thanks for the review.

March 22, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Henri Verbeet

On 22 March 2011 18:12, Adam Martinson <amartinson(a)codeweavers.com> wrote: > On 03/22/2011 05:02 AM, Henri Verbeet wrote: >> This is meaningless. Which applications, and how much time of the >> total is spent in context_apply_fbo_state()? > > In the 3DMark06 batch size 8 test, as of Friday's tip, it was 5.5% of > wined3d; 1.2% of total wine CPU time. Searching the FBO list is almost all > of that. It's called every time drawPrimitive() is (assuming ORM_FBO), so > that shouldn't be much of a shock. I would hope that significant changes to fundamental parts of wined3d would be backed up by a somewhat wider range of benchmark results. >> How does this translate into concrete thing like frame time? > > It's an improvement, but I can't give you very meaningful FPS numbers there > for individual patches. In my testing raw FPS is less reliable than profile > results; it's dependent on GPU time as well, which I can't profile. The > range of normal FPS variability is larger than the effect of most individual > patches, including this one. GPU time matters. Freeing up CPU time just so you can spend more time waiting for the GPU to finish isn't all that useful. >> More importantly, why does this change come before the one for >> tracking FBO dirty state? > > Really? I sent both at the same time, and the order bothers you? Really?? Really. And I did even explain why. Note that while displays of disbelief rarely help with getting patches committed, solid arguments tend to do just fine. >> Avoiding redundant FBO entry comparisons completely is likely to >> have a much more significant effect than making the comparisons >> themselves slightly cheaper in very specific applications. > > Actually, it would take a much more specific FBO configuration for this to > make no difference. The whole list would have to have the same number of > render targets, and almost all of them full. memcmp() is expensive. > Avoiding unnecessary comparisons is cheap. This makes both successful and > unsuccessful FBO entry comparisons cheaper. The other patch helps too, > that's why I submitted both. > I'm quite aware of the costs of memory accesses, thanks. So, to be more explicit this time: - I understand just fine what the patch actually does. - I'm not opposed to this change in principle, but you will have to justify changes like these. - How much of a real difference does this patch make, after you avoid the redundant lookups? (I.e., after the second patch in this series.)

March 22, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Adam Martinson

On 03/22/2011 05:02 AM, Henri Verbeet wrote: > On 21 March 2011 21:56, Adam Martinson<amartinson(a)codeweavers.com> wrote: >> Cuts CPU time in context_apply_fbo_state() in half. > This is meaningless. Which applications, and how much time of the > total is spent in context_apply_fbo_state()? In the 3DMark06 batch size 8 test, as of Friday's tip, it was 5.5% of wined3d; 1.2% of total wine CPU time. Searching the FBO list is almost all of that. It's called every time drawPrimitive() is (assuming ORM_FBO), so that shouldn't be much of a shock. > How does this translate into concrete thing like frame time? It's an improvement, but I can't give you very meaningful FPS numbers there for individual patches. In my testing raw FPS is less reliable than profile results; it's dependent on GPU time as well, which I can't profile. The range of normal FPS variability is larger than the effect of most individual patches, including this one. > More importantly, why does this change come before the one for > tracking FBO dirty state? Really? I sent both at the same time, and the order bothers you? Really?? > Avoiding redundant FBO entry comparisons completely is likely to > have a much more significant effect than making the comparisons > themselves slightly cheaper in very specific applications. Actually, it would take a much more specific FBO configuration for this to make no difference. The whole list would have to have the same number of render targets, and almost all of them full. memcmp() is expensive. Avoiding unnecessary comparisons is cheap. This makes both successful and unsuccessful FBO entry comparisons cheaper. The other patch helps too, that's why I submitted both.

March 22, 2011

Re: Must multimedia players check the message queue and invoke DispatchMessage?

by Juan Lang

> None of Wine's MCI drivers do. (snip) > Who could shed some light? Have you looked at any open source MCI drivers? They may or may not be of the best quality, but at least one exists in my brief perusal: the MediaXW package, http://sourceforge.net/projects/mediaxw/ > What do you mean exactly by "message pumping"? There are a few places in Wine > that call PeekMessage e.g. MCI_DefYieldProc, MMSYSTEM_MidiStream_MessageHandler, > but to me it looks like an error when that is not accompanied by DispatchMessageA/W > of all the messages that the local handler does not understand. > I'd expect DispatchMessage, not PeekMessage to invoke all the callbacks. > Isn't it an error for all loops executing on the app's thread? It's a broad topic, but yes, basically you want to call DispatchMessage on some messages periodically. See e.g. MsgWaitForMultipleHandles. --Juan

March 22, 2011

Re: winex11.drv/opengl.c: Unhandled null pointer

by Joshua Beck

On 03/22/2011 05:55 AM, Henri Verbeet wrote: > On 22 March 2011 08:59, Joshua Beck<jxb091000(a)utdallas.edu> wrote: > >> What do you think? >> >> > Does the pglXMakeCurrent() call a few lines above succeed? We should > probably check the result of that call. It doesn't succeed. I added some FIXMEs to the code to get output for debugging and this is what it printed before it crashed: >fixme:wgl:X11DRV_WineGL_InitOpenglInfo pglXMakeCurrent returned 0 >fixme:wgl:X11DRV_WineGL_InitOpenglInfo pglGetString pointer is equal to 0 > Nevertheless, this means > something is broken with your GL setup, so while the error handling > could be improved, it's not going to make the application work. With > the NVIDIA drivers this kind of thing typically happens when you have > a version mismatch between libGL and the kernel module. > I know it's not going to make it work, but it's still a good idea to have descriptive error messages. It helps less technically skilled people figure out what's wrong. Also wine-devel isn't really the place to ask for help setting up 32-bit drivers, so I didn't ask for that help here. If you want to help me we should email each other outside of the mailing list.

March 22, 2011

GSoC questions (Re: Question)

by Hin-Tak Leung

Sanket Patel wrote: > How Teams Are Formed in Google Summer Of Code For Any Project. > Is It Formed By Organization Or Google ? First, it would be good etiquette to post to mailing lists with sensible and specific subject fields, rather than generic like your past few posts. Many people only read posts from mailing lists of subjects which interest them; so a generic subject fields like yours is almost a guarantee to be ignored. You might have the naive idea that people read *all* e-mails with ambiguous subjects so to get attention it is best to make the subject as ambiguous as possible - that's quite misguided. Again, your questions are ambiguous. There is no "teams" at the student's level, and there is no "teams" at the mentor level, nor there is "teams" in the organization (either wine or google) level. *A* student needs to file *a* proposal, against an organization (e.g. wine) under the GSoC web site. *A* mentor needs to take official responsibility of *a* student, and *a* organization admin (often self-appointed, but usually a well-known person in a community) needs to approve of the mentor taking on the student, against all the other student+mentor combinations. Then the sets of student+mentor combination per organization is ranked and approved by Google on a quota system against all the other organizations'. Any suggestion of a "team" only generally happens AFAIK in the mentor level: i.e. while *a* mentor is officially responsible to check up on the progress of *a* student, the community as a whole, or some individuals in particular, can take on informal responsibility for guiding the student's progress. It is relatively rare for two students to work on the same project (but different aspect of it) although not unheard of; Google asks towards the end of the selection process for *a* student which has been accepted by more than one organizations, for one of the organizations to drop one of the applications so the other application can proceed.

March 22, 2011

AW: Must multimedia players check the message queue and invoke DispatchMessage?

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

Hi, Juan Lang wrote: >Are you concerned about the applications introducing deadlocks by not >servicing messages quickly enough, or about MCI introducing deadlocks >by not processing messages in the current thread? I was concerned both about the MCI and the rest of winmm (midi*, wave*) API. We've a few bug reports about apps that hang but work with a native msvfw32.dll. I'm wondering if that could be related (erk, another dll that I'm not familiar with). >If the latter, this probably requires that MCI pump the message loop >while it's processing. The MCI API explcitly acknowledges some need for message pumping in the MCI_WAIT case via the mciSetYieldProc function. MSDN says that the MCI drivers must periodically call it. None of Wine's MCI drivers do. It's unclear to me why it should be called. Once I read that it's used to be able to react to the Break key to abort an animation (few people care). Maybe it's also needed to continuously dispatch messages (refresh, resize, buttons etc.)? I found no similar information about the wave* and midi* functions. Yet testing indicates that they also hijack the application's thread since w2k, possibly for as long as there's audio to play. Perhaps there's no documentation precisely because that changed since w2k, all winmm documentation predates that and in w9x another thread was used so there was no analogue to MCI_WAIT design issues. Who could shed some light? >It's common to require that applications continue to "pump" the message >loop when calling some blocking function. Modal dialog boxes continue >to do so, for example. Indeed, one of my colleagues has written a mono-threading multi-windowing application. It rarely seems to hang, except when reading from CTAPI. It must be full of nested callbacks and calls to DispatchMessage. What do you mean exactly by "message pumping"? There are a few places in Wine that call PeekMessage e.g. MCI_DefYieldProc, MMSYSTEM_MidiStream_MessageHandler, but to me it looks like an error when that is not accompanied by DispatchMessageA/W of all the messages that the local handler does not understand. I'd expect DispatchMessage, not PeekMessage to invoke all the callbacks. Isn't it an error for all loops executing on the app's thread? >I wouldn't be surprised if some app expects that it can post messages >from its callbacks. MSDN on waveOutProc explicitly allows Post[Thread]Message. wave* are forbidden (no waveOutWrite from within a WOM_DONE callback, no midiOutClose, but there are logs in Bugzilla that show otherwise). MSDN documents MMSYSERR_HANDLEBUSY "The handle is being used simultaneously by another thread (for example, a callback thread)." I've never seen that error. Yet it means that they are considering detecting possible dead-locks and contentions. Thank you, Jörg Höhle

March 22, 2011

Question

by Sanket Patel

How Teams Are Formed in Google Summer Of Code For Any Project. Is It Formed By Organization Or Google ? -- " Live 2 Love and Love 2 Live "

March 22, 2011

Re: kernel32: avoid shadowing a parameter (try 2)

by Henri Verbeet

On 22 March 2011 02:27, Austin English <austinenglish(a)gmail.com> wrote: > defval_tmp = HeapAlloc(GetProcessHeap(), 0, (len + 1) * sizeof(WCHAR)); > - memcpy(defval_tmp, def_val, len * sizeof(WCHAR)); > - defval_tmp[len] = '\0'; > + memcpy(defval_tmp, def_val, defval_len * sizeof(WCHAR)); > + defval_tmp[defval_len] = '\0'; I think you're allocating the wrong amount of memory now.

March 22, 2011

Re: winex11.drv/opengl.c: Unhandled null pointer

by Henri Verbeet

On 22 March 2011 08:59, Joshua Beck <jxb091000(a)utdallas.edu> wrote: > What do you think? > Does the pglXMakeCurrent() call a few lines above succeed? We should probably check the result of that call. Nevertheless, this means something is broken with your GL setup, so while the error handling could be improved, it's not going to make the application work. With the NVIDIA drivers this kind of thing typically happens when you have a version mismatch between libGL and the kernel module.

March 22, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Henri Verbeet

On 21 March 2011 21:56, Adam Martinson <amartinson(a)codeweavers.com> wrote: > > Cuts CPU time in context_apply_fbo_state() in half. This is meaningless. Which applications, and how much time of the total is spent in context_apply_fbo_state()? How does this translate into concrete thing like frame time? More importantly, why does this change come before the one for tracking FBO dirty state? Avoiding redundant FBO entry comparisons completely is likely to have a much more significant effect than making the comparisons themselves slightly cheaper in very specific applications.

March 22, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 21.03.2011 um 21:56 schrieb Adam Martinson: > > Cuts CPU time in context_apply_fbo_state() in half. What is the performance impact on real apps? -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNiHM5AAoJEN0/YqbEcdMwi28P/1iN598GQgE9ttILayjW6f1h E8DKkF30dJyXa506XoPKWeE+319mpLOevUca2hjBaaKoL+H69TzCproGGgdw7/W3 roWyg2Q42hibFnTb5ORwgjbsQbqYlRaMj7nlCJguyDjnK81oNIpLWjdiVWpe4H+b naQf+p9NWRR6x2tOx4i71MgvWnbPRiawJO14DxwwyTxelYWu05XgWvFaRYuyKevt 67q8yGGVx+4SXmSC1D5rzRAjY2OHIvGbznlrC3VV3TmpQg5YsrWS7b8XWr/Ii3DJ DQsOLbv/KMFTOTcQ6wjI+dJPX/lM/3z7QcOVVsAGZyOvH+8fIMAwtDcgU+EAwyWY CaM7NH6JM8Jlal4r8Hfhw/9IfLr+K6WVzYKPdjxO+PUxhV1GV4GC74vQn8wMHK4U LANQ5Kw9s+dThqM6gyBTcdyD8r37ktULlOyAFfx4a63Wg8JRBiqPyEyRufoCK7Kf lfsOGcadkAy9eKh4tIlaEfOMwewOap7Mq4veyQLO6JrnWVKIPg/vCufT4SD5VgPG AMtvbG0lqX5+egdH0IM6j4e9CiescSwqHqywphvxGwzQlPpbejvnIysFLH351lBQ cqIjVmcXLDTRigO8cpg+r7yyntVSCGZ8HduZlgwCLroOHJvK1vR0LkUHPIC1M5yE CYKj0gOxXQ7k8pT0uHJb =UrlD -----END PGP SIGNATURE-----

March 22, 2011

Re: Idea

by Hin-Tak Leung

(Please keep the wine-devel CC:) Sanket Patel wrote: > User File Location > > On Tue, Mar 22, 2011 at 8:25 AM, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk > <mailto:hintak_leung(a)yahoo.co.uk>> wrote: > > Sanket Patel wrote: > > > hi there, > I talk about to make wine portable. > How I am Gonna Do That is , > There is a files that are related to system and integrated in to > system while install. > We gonna change that system files places . > How ? that is still question but we can do By community Support. > > If you talk about takiinng 1/2 of system files into package , i > think there is not really a case to happen > > > Hmm, I think you are confusing 'relocatable' vs 'portable' - in any > case, wine is already both portable (runs on many x86/x86_64-based > unix systems, include linux, *bsd, solaris, Mac OS X), and wine is > also relocatable to a good extent - > you can either run wine without installing, from within the > source(build) directory with the script provided, or you can choose > an install location with "./configure --prefix=..." > > Or may be you mean the user file location (${HOME}/.wine > (WINEPREFIX)) vs the wine binary locations (the ./configure > --prefix=<where>)? You need to clarify what you propose. Perhaps you did not notice, I already wrote that user file location, while defaults to ${HOME}/.wine, is controllable by setting the WINEPREFIX environment variable before launching wine. This machanism of allowing for parallel and separate user files are quite actively used and maintained. WineInBottle (or something of a similar name?) and possibly a few other "wine add-ons" does that, actually.

March 22, 2011

Re: winex11.drv/opengl.c: Unhandled null pointer

by Dmitry Timoshkov

[Please do not omit wine-devel(a)winehq.org when replying] Joshua Beck <jxb091000(a)utdallas.edu> wrote: > > What OpenGL driver are you using? glGetString(GL_EXTENSIONS) returning NULL > > might be a driver bug. > > > I'm using an nvidia binary driver (260.36.19 I think). Thing is I'm > running Debian amd64 and I compiled wine with -m32. I checked and there > are nvidia libraries in /usr/lib32. However I don't know if all of them > are in there or if they work correctly. See http://wiki.winehq.org/3DDriverIssues how to diagnose GL driver problems. > >> It would be better to do something like this instead: > >> > >> str = (const char *) pglGetString(GL_EXTENSIONS); > >> if(str == 0) > >> { > >> ERR( "Couldn't find GL_EXTENSIONS string, disabling OpenGL.\n" ); > >> goto done; > >> } > >> WineGLInfo.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str)+1); > >> > >> > >> What do you think? > >> > > WineGLInfo.glExtensions is used in other places in the code, it must be > > initialized. > > > > > If str == 0 then the program is going to crash before anything else can > get to WineGLInfo.glExtensions. Better to say what the error is than to > crash with an "Unhandled page fault" error. If it's that important to > have WineGLInfo.glExtensions initialized to something then initialize > it to an error code. If pglGetString(GL_EXTENSIONS) returns NULL for whatever reason allocating an 1 byte WineGLInfo.glExtensions buffer and setting it to 0 should work just fine. -- Dmitry.

March 22, 2011

Re: winex11.drv/opengl.c: Unhandled null pointer

by Dmitry Timoshkov

Joshua Beck <jxb091000(a)utdallas.edu> wrote: > 350: str = (const char *) pglGetString(GL_EXTENSIONS); > 351: WineGLInfo.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str)+1); > > > From this it's obvious that pglGetString is returning a null pointer. What OpenGL driver are you using? glGetString(GL_EXTENSIONS) returning NULL might be a driver bug. > It would be better to do something like this instead: > > str = (const char *) pglGetString(GL_EXTENSIONS); > if(str == 0) > { > ERR( "Couldn't find GL_EXTENSIONS string, disabling OpenGL.\n" ); > goto done; > } > WineGLInfo.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str)+1); > > > What do you think? WineGLInfo.glExtensions is used in other places in the code, it must be initialized. -- Dmitry.

March 22, 2011

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.

by Dmitry Timoshkov

Adam Martinson <amartinson(a)codeweavers.com> wrote: > Cuts CPU time in context_apply_fbo_state() in half. > --- > dlls/wined3d/context.c | 65 > +++++++++++++++++++++------------------ > dlls/wined3d/wined3d_private.h | 1 + > 2 files changed, 36 insertions(+), 30 deletions(-) It looks like you are not subscribed to wine-patches mailing list and your patches are delayed awaiting the moderator action. -- Dmitry.

March 22, 2011

winex11.drv/opengl.c: Unhandled null pointer

by Joshua Beck

I've been trying to run wine with a few games, and I've been getting a similar error and backtrace with all of them. Here's the relevant info: wine: Unhandled page fault on read access to 0x00000000 at address 0xf748c110 (thread 0043), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0xf748c110). ... Backtrace: =>0 0xf748c110 in libc.so.6 (+0x74110) (0x0032e670) 1 0x7e59fae9 X11DRV_WineGL_InitOpenglInfo+0x353() [/home/jb/programs/wine-git/dlls/winex11.drv/opengl.c:351] in winex11 (0x0032e670) ... (goes on for a dozen or so more, not relevant to this bug) So my first thought was "What's wrong with libc?" Then I looked at the source of the file at level 1 of the stack and found this: 350: str = (const char *) pglGetString(GL_EXTENSIONS); 351: WineGLInfo.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str)+1); From this it's obvious that pglGetString is returning a null pointer. It would be better to do something like this instead: str = (const char *) pglGetString(GL_EXTENSIONS); if(str == 0) { ERR( "Couldn't find GL_EXTENSIONS string, disabling OpenGL.\n" ); goto done; } WineGLInfo.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str)+1); What do you think?

March 22, 2011

Re: [1/2] uxtheme: Add OpenThemeDataEx

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > - TRACE("(%p,%s)\n", hwnd, debugstr_w(pszClassList)); > + TRACE("(%p,%s, %u)\n", hwnd, debugstr_w(pszClassList), Flags); > + > + if(Flags) > + FIXME("unhandled Flags: %u\n", Flags); ... > +#define OTD_FORCE_RECT_SIZING 0x0001 > +#define OTD_NONCLIENT 0x0002 > +#define OTD_VALIDBITS (OTD_FORCE_RECT_SIZING | OTD_NONCLIENT) Flags should be printed as hex in the traces. Also using names without capitalizaion and hungarian notation is always preferred for new code in Wine. -- Dmitry.

March 22, 2011

Re: Idea

by Damjan Jovanovic

On Tue, Mar 22, 2011 at 4:40 AM, Sanket Patel <sanketpatel.com(a)gmail.com> wrote: > > hi there, > I talk about to make wine portable. > How I am Gonna Do That is , > There is a files that are related to system and integrated in to system > while install. > We gonna change that system files places . > How ? that is still question but we can do By community Support. > > If you talk about takiinng 1/2 of system files into package , i think there > is not really a case to happen > -- If you want to make a "Portable App" of Wine (ie. a directory containing the Wine installation which can be moved anywhere in the filesystem or run from a USB flash disk) I think Wine supports that already; the "wine" executable finds the path to other files it needs using its own location, not the --prefix option to configure. The only thing I found that doesn't work is winegcc, which hardcodes search paths at compile time, but end users almost never need it anyway. Damjan

March 22, 2011

Idea

by Sanket Patel

hi there, I talk about to make wine portable. How I am Gonna Do That is , There is a files that are related to system and integrated in to system while install. We gonna change that system files places . How ? that is still question but we can do By community Support. If you talk about takiinng 1/2 of system files into package , i think there is not really a case to happen -- " Live 2 Love and Love 2 Live "

March 22, 2011

Re: Xbox 360 controller compatibility

by Vitaliy Margolen

On 03/21/2011 01:36 AM, Alesh Slovak wrote: > I've also found a set of patches by Michael Gruber from 2009 that appear to > actually implement xinput: > http://marc.info/?l=wine-patches&m=124710119700598&w=4 > <http://marc.info/?l=wine-patches&m=124710119700598&w=4> > http://marc.info/?l=wine-patches&m=124710124200662&w=4 > <http://marc.info/?l=wine-patches&m=124710124200662&w=4> > http://marc.info/?l=wine-patches&m=124710129100718&w=4 > <http://marc.info/?l=wine-patches&m=124710129100718&w=4> > http://marc.info/?l=wine-patches&m=124710132300760&w=4 > <http://marc.info/?l=wine-patches&m=124710132300760&w=4> > > What do people think of these? Looks more-less complete. Needs some cleanup. The main hurdle would be convincing AJ that this the best and only way to talk to x360 controller. Of course will need some extra infrastructure to add drivers for other O/Ses. Vitaliy.

March 22, 2011

Re: Xbox 360 controller compatibility

by Vitaliy Margolen

On 03/20/2011 02:46 PM, Austin English wrote: > http://www.winehq.org/pipermail/wine-patches/2008-November/064302.html > http://www.winehq.org/pipermail/wine-patches/2008-November/064304.html > http://www.winehq.org/pipermail/wine-patches/2008-November/064305.html > These are stubs more-less. No actual implementation of the interface. This part already in Wine. Vitaliy

March 22, 2011

Re: mshtml: avoid shadowing a parameter (2/2)

by Austin English

On Wed, Mar 9, 2011 at 06:30, Jacek Caban <jacek(a)codeweavers.com> wrote: > Hi Austin, > > On 3/9/11 10:07 AM, Austin English wrote: >> >> diff --git a/dlls/mshtml/htmlwindow.c b/dlls/mshtml/htmlwindow.c >> index d0d378f..9948a02 100644 >> --- a/dlls/mshtml/htmlwindow.c >> +++ b/dlls/mshtml/htmlwindow.c >> @@ -2141,22 +2141,22 @@ static HRESULT HTMLWindow_invoke(DispatchEx >> *dispex, DISPID id, LCID lcid, WORD >> >> switch(prop->type) { >> case GLOBAL_SCRIPTVAR: { >> - IDispatchEx *dispex; >> + IDispatchEx *dpex; > > How about renaming argument name to 'iface'? It's not really an interface, > but its purpose in this context is like iface arguments in regular COM > objects. Sure, resent. Thanks for reviewing! -- -Austin

March 22, 2011

Re: wined3d: Prevent crash when blit_priv is NULL.

by Henri Verbeet

2011/3/21 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > Good :) I guess I should submit the patch as it is now, I hope Henri > would be fine with doing it this way for the time being (the FBO code > is doing something equivalent). Should be ok for the time being.

March 21, 2011

Re: wined3d: Prevent crash when blit_priv is NULL.

by Roderick Colenbrander

On Mon, Mar 21, 2011 at 5:12 PM, Konrad Rzepecki <hannibal(a)astral.lodz.pl> wrote: > Dnia poniedziałek, 21 marca 2011, Roderick Colenbrander napisał(a): >> Okay, as I expected no ARB_fragment_program support. Give the attached >> patch a try. For the time being (hope to get a little bit of time to >> finish what I started..) this patch may be acceptable. > > No crash with your patch, so probably it is OK. Good :) I guess I should submit the patch as it is now, I hope Henri would be fine with doing it this way for the time being (the FBO code is doing something equivalent). > > > So what now? I'm new here, and I don't know should I in any way cancel my > patch? Or it is enough you to send yours? I'm not fully sure how Alexandre works. I think typically when he sees a patch being discussed, he may already drop it. Roderick

March 21, 2011

Re: Must multimedia players check the message queue and invoke DispatchMessage?

by Juan Lang

Hi Joerg, > 2. Consequently, the players must implement a message loop and > dispatch regular window messages using DispatchMessageA/W > Currently, Wine does not. This IMHO has potential for dead locks. > Music and animations can play for a long time and messages ought to be serviced. > > I'm not familiar with windows messages at all. > What do you think about the consequence? Are you concerned about the applications introducing deadlocks by not servicing messages quickly enough, or about MCI introducing deadlocks by not processing messages in the current thread? If the former, I'd say that it's possible that Microsoft would consider this to be a buggy app, and not an issue for us. It's common to require that applications continue to "pump" the message loop when calling some blocking function. Modal dialog boxes continue to do so, for example. If the latter, this probably requires that MCI pump the message loop while it's processing. > Point 2 should be testable by playing a long piece of video or music > and prequeuing or injecting (how?) some windows events. How to test > this in a convincing manner? Perhaps call SetTimer with a period shorter than the duration of something you're about to play, and show that the thread receives a WM_TIMER before playing is complete? > Would the obligation to service messages disappear if the players ran > in their own thread (like w9x seems to do)? The obligation to process messages within MCI? Possibly. Since nothing since Win9x seems to use threads, however, I wouldn't be surprised if some app expects that it can post messages from its callbacks. In other words, don't expect all applications to be "Win9x safe." Hope that helps, --Juan

March 21, 2011

Must multimedia players check the message queue and invoke DispatchMessage?

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

Hi, In Bug #3930 http://bugs.winehq.org/show_bug.cgi?id=3930#c41 I conjectured that: 1. Since w2k, winmm hijacks the application's thread to play multimedia content. Wine does this as well with MCI_WAIT, but it should as well affect winmm:playSound, winmm:midi* and winmm:wave*. 2. Consequently, the players must implement a message loop and dispatch regular window messages using DispatchMessageA/W Currently, Wine does not. This IMHO has potential for dead locks. Music and animations can play for a long time and messages ought to be serviced. I'm not familiar with windows messages at all. What do you think about the consequence? Point 1 explains why tests reveal the current thread as the one executing all callbacks but one since w2k. Point 2 should be testable by playing a long piece of video or music and prequeuing or injecting (how?) some windows events. How to test this in a convincing manner? Would the obligation to service messages disappear if the players ran in their own thread (like w9x seems to do)? Thanks for your help, Jörg Höhle

March 21, 2011

Re: wined3d: Prevent crash when blit_priv is NULL.

by Konrad Rzepecki

Dnia poniedziałek, 21 marca 2011, Roderick Colenbrander napisał(a): > Okay, as I expected no ARB_fragment_program support. Give the attached > patch a try. For the time being (hope to get a little bit of time to > finish what I started..) this patch may be acceptable. No crash with your patch, so probably it is OK. So what now? I'm new here, and I don't know should I in any way cancel my patch? Or it is enough you to send yours? -- Konrad Rzepecki (Hannibal)

March 21, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

Thanks for the reply Stefan! It sounds like it is possible to do this project. I'll send my application to Google on the 28th. On Sun, Mar 20, 2011 at 11:32 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > Thanks for your proposal! > > I don't know the functions you suggest well enough personally to judge the > amount of work that is needed. Potential mentors are Roderick, Matteo, Henri > and me. I don't know who has time and is willing to mentor, but I think it is > safe to say that we'll find somebody :-) > > We had two d3dx9-centered gsoc projects in the past, namely Matteo's shader > assembler work and Tony Wasserka's texture loading work. Matteo's project > succeeded and the code is in Wine now. Tony's code didn't make it in during > the project, but at least parts(everything?) of it got committed later. > > As you can see we have another developer who's interested in d3dx9. Two > projects on the same library are doable if they target independent parts. > Luckily d3dx9 is a big collection of mostly independent helper functions. > > I don't want to jump to conclusions just yet, the formal application process > will decide which proposals are accepted. > > Best regards > Stefan > > On Sunday 20 March 2011 18:09:24 Michael Mc Donnell wrote: >> Dear Wine developers, >> >> I would like implement some of the missing mesh functions in Wine's >> D3DX9 for Google Summer of Code 2011. I would like to implement the >> following functions: >> - CloneMesh >> - CloneMeshFVF >> - ConvertPointRepsToAdjacency >> - ConvertAdjacencyToPointReps >> - GenerateAdjacency >> >> They seem to be suitable in size to implement during a summer, and I >> have a good idea of how to implement them. I expect to first implement >> tests and then implement the functions. >> >> I am a masters student at the Technical University of Denmark nearing >> the end of my studies, and I have specialized in 3D computer graphics, >> studying both real-time and physically based techniques, as well as >> how to use existing 3D modeling tools to create animations. The mesh >> functions should be fairly straight forward for me to implement as I >> have recently taken an advanced course on geometry processing which >> involved a lot of mesh manipulation. I have, furthermore, already >> tests (for a shell32 function) in the wine test suite so I have some >> knowledge of Wine development. >> >> Roderick Coldenbrander is listed as a possible mentor for "Direct3D - >> Implement missing D3D9_xx DLLs" on the wiki. Are you still interested, >> or would someone else like to be a mentor? >> >> Regards, >> Michael Mc Donnell >

March 21, 2011

Re: wined3d: Prevent crash when blit_priv is NULL.

by Roderick Colenbrander

Okay, as I expected no ARB_fragment_program support. Give the attached patch a try. For the time being (hope to get a little bit of time to finish what I started..) this patch may be acceptable. Roderick On Mon, Mar 21, 2011 at 8:36 AM, Konrad Rzepecki <hannibal(a)astral.lodz.pl> wrote: > Dnia poniedziałek, 21 marca 2011, napisałeś(aś): > >> You should try to figure out why blit_priv is NULL. That's the real >> issue. > > I wish to know, where to search. But my patch prevent crash if blit_priv > is NULL form some reason. This is best place I found to fallback to software. > >> What drivers are you using? > > Binary NVIDIA on GF Ti4200 > >> Do they support arb fragment program? > > Im not sure, it is OGL 1.5.8 but with these extensions available (only > revelant part): > GL_ARB_shader_objects, GL_ARB_shading_language_100, > GL_ARB_vertex_program, GL_ARB_vertex_shader, > GL_NV_register_combiners, GL_NV_register_combiners2, > GL_NV_texture_env_combine4, GL_NV_texture_shader, > GL_NV_texture_shader2, GL_NV_texture_shader3, > GL_NV_vertex_program, GL_NV_vertex_program1_1 > > For sure hardware support vertex and fragment 1.X. > >> Right now we may still call arbfp_blit_surface when the >> extension isn't around (was working on this a year ago, haven't had >> time since then :( ), this could explain why there is no priv_data >> since in ffp_blit_alloc we don't do any allocation. > > I can't help with that, for now we can print FIXME when blit_priv is NULL so > this situation is not forget. > > -- > Konrad Rzepecki (Hannibal) > > >

March 21, 2011

Re: Failing kernel32:change and ntdll:change tests on Mac OS

by Ken Thomases

On Mar 21, 2011, at 8:52 AM, Charles Davis wrote: > On 3/10/11 3:27 PM, Ken Thomases wrote: >> On Mar 10, 2011, at 4:20 PM, Ken Thomases wrote: >> >>> I doubt Alexandre would accept reworking wineserver around CFRunLoop, > > I know. Then again, I've often wondered if doing this might be > beneficial. I seem to remember kqueue(2) being broken until Mac OS 10.5. I have a vague recollection of that, too, but we seem to have worked around it. kqueue is working well enough. The problem with CFRunLoop is that it's implemented really stupidly for sources which are not Mach ports, file descriptors in particular, at least on older versions of Mac OS X. >>> 1) Have the wineserver spin off a secondary thread to run the CFRunLoop and then communicate to the main thread via a file descriptor. I think, though, that keeping the wineserver single-threaded is important, too. > > Yeah. That makes me think AJ might not accept this, either. Then again, > it's not like this thread will actually be servicing requests from Wine > processes. Personally, I like it the best (or rather, hate it the least) > of all the options you mentioned. > >>> 2) Do this in Wine's userland, like in a service. > > But then we'd suffer the overhead of (even more) IPC. It's bad enough > that we have to talk to the server, but this way the app has to talk to > wineserver to talk to a service, and the service has to talk to > wineserver so it can talk back to the app. That's a lot of IPC, and > that's something I'd rather avoid if possible. Is the overhead material, though? I don't know that file change notification is such a high-frequency API that the calls back and forth will be a significant portion of total program time. After all, it's all ultimately gated by disk I/O. > Plus, it seems to me that > the inotify/dnotify support would have to be reworked in terms of this; > otherwise, we'd have to have ugly #ifdef blocks in ntdll's change > functions (in addition to the ones already in the server). > > Alternatively, we could just have the change functions run the run loop > themselves, in a special mode (see CFRunLoopRunInMode()) dedicated to > waiting for directory changes. I'm not sure how you or AJ feel about > that, though. We'd still have to have #ifdef blocks in ntdll, though, if > we do it this way. I have to confess I haven't read the current inotify/dnotify-based implementation. >>> 3) Do this in a non-Wine process spun off from the wineserver for the sole purpose of bridging the notifications from a CFRunLoop/Mach port-based mechanism to a file descriptor. > > If we do it this way, we may as well just spin off a new thread > (suggestion 1). The point of using a separate process is that it minimizes the exposure of wineserver to bugs, either in our new code or in the Mac frameworks. Currently, for example, the wineserver is only linked against libgcc and libSystem. That's another desirable quality, like its single-threaded nature. > It's cheaper to spawn threads rather than processes. We're talking about one process, right? >> 4) Use kqueue directly, with its vnode filter. It would entail opening every directory in a hierarchy, which might be deemed prohibitive. > > We could run out of Unix handles pretty quickly if we do it that way. As > I recall, the limit on the number of open FDs a process can have is > pretty low by default (only 2560 on my system). Of course, the user > could raise this limit (the hard limit is unlimited), but still I don't > feel comfortable painstakingly opening tens, hundreds, possibly even > thousands of file descriptors at once just to watch for changes to them. Hence, "deemed prohibitive". ;) Regards, Ken

March 21, 2011

Re: msi: Add an offset to sequence numbers belonging to files added by a patch. (try 2)

by Hans Leidekker

On Mon, 2011-03-21 at 14:14 +0100, David Hedberg wrote: > +static void msi_patch_offset_list_init(struct msi_patch_offset_list **pos) > +{ > + *pos = msi_alloc(sizeof(struct msi_patch_offset_list)); > + list_init( &(*pos)->files ); > + (*pos)->count = (*pos)->max = 0; > + (*pos)->min = 999999; > +} It would be nicer to have a _create function that returns an initialized structure.

March 21, 2011

Re: [PATCH 2/4] comdlg32: Add stub implementation of the Common Item dialogs.

by Nikolay Sivov

On 3/21/2011 16:37, David Hedberg wrote > + */ > + > +#include<stdarg.h> > + > +#define COBJMACROS > +#define NONAMELESSUNION > +#define NONAMELESSSTRUCT > + > +#include "windef.h" > +#include "winbase.h" > +#include "winuser.h" > +#include "wingdi.h" > + > +#include "commdlg.h" > +#include "cdlg.h" > + > +#include "wine/debug.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(commdlg); > + > +typedef struct FileDialogImpl { > + IFileDialog2 IFileDialog2_iface; > + IFileOpenDialog IFileOpenDialog_iface; > + IFileSaveDialog IFileSaveDialog_iface; > + LONG ref; > +} FileDialogImpl; Maybe it's better to use a union and enum type field here, if it can't be open and save at the same time. > + > +/************************************************************************** > + * IFileDialog implementation > + */ > +static inline FileDialogImpl *impl_from_IFileDialog2(IFileDialog2 *iface) > +{ > + return (FileDialogImpl *)((char*)iface - FIELD_OFFSET(FileDialogImpl, IFileDialog2_iface)); > +} > + Use CONTAINING_RECORD macro please. > +static HRESULT WINAPI IFileDialog2_fnQueryInterface(IFileDialog2 *iface, > + REFIID riid, > + void **ppvObject) > +{ > > + } > + else > + FIXME("Unknown interface requested.\n"); It's better to dump guid here. > +} > + > +static ULONG WINAPI IFileDialog2_fnRelease(IFileDialog2 *iface) > +{ > + FileDialogImpl *This = impl_from_IFileDialog2(iface); > + LONG ref = InterlockedDecrement(&This->ref); > + TRACE("%p - ref %d\n", This, ref); > + > + if(!ref) > + { > + TRACE("Freeing object.\n"); > + HeapFree(GetProcessHeap(), 0, This); > + } > + > + return ref; > +} No need for additional trace I think, ref == 0 is enough to indicated that. > +static HRESULT FileDialog_constructor(IUnknown *pUnkOuter, REFIID riid, void **ppv, REFCLSID type) > +{ > + FileDialogImpl *fdimpl; > + HRESULT hr; > + TRACE("%p, %s, %p\n", pUnkOuter, debugstr_guid(riid), ppv); > + > + if(!ppv) > + return E_POINTER; > + if(pUnkOuter) > + return CLASS_E_NOAGGREGATION; > + > + fdimpl = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(FileDialogImpl)); > + if(!fdimpl) > + return E_OUTOFMEMORY; Zero initialization is useless here. > + > + fdimpl->IFileDialog2_iface.lpVtbl =&vt_IFileDialog2; > + > + if(IsEqualCLSID(type,&CLSID_FileOpenDialog)) > + fdimpl->IFileOpenDialog_iface.lpVtbl =&vt_IFileOpenDialog; > + else > + fdimpl->IFileSaveDialog_iface.lpVtbl =&vt_IFileSaveDialog; > + > + IUnknown_AddRef((IUnknown*)fdimpl); > + hr = IUnknown_QueryInterface((IUnknown*)fdimpl, riid, ppv); > + IUnknown_Release((IUnknown*)fdimpl); > + That looks strange, you only need one QueryInterface here.

March 21, 2011

Re: Failing kernel32:change and ntdll:change tests on Mac OS

by Charles Davis

Sorry I waited so long to get back to you. On 3/10/11 3:27 PM, Ken Thomases wrote: > On Mar 10, 2011, at 4:20 PM, Ken Thomases wrote: > >> I doubt Alexandre would accept reworking wineserver around CFRunLoop, I know. Then again, I've often wondered if doing this might be beneficial. I seem to remember kqueue(2) being broken until Mac OS 10.5. >> but I can think of several alternatives: Unfortunately, each of them has a disadvantage. Quite frankly, I'm not liking our options at this point. >> >> 1) Have the wineserver spin off a secondary thread to run the CFRunLoop and then communicate to the main thread via a file descriptor. I think, though, that keeping the wineserver single-threaded is important, too. Yeah. That makes me think AJ might not accept this, either. Then again, it's not like this thread will actually be servicing requests from Wine processes. Personally, I like it the best (or rather, hate it the least) of all the options you mentioned. >> >> 2) Do this in Wine's userland, like in a service. But then we'd suffer the overhead of (even more) IPC. It's bad enough that we have to talk to the server, but this way the app has to talk to wineserver to talk to a service, and the service has to talk to wineserver so it can talk back to the app. That's a lot of IPC, and that's something I'd rather avoid if possible. Plus, it seems to me that the inotify/dnotify support would have to be reworked in terms of this; otherwise, we'd have to have ugly #ifdef blocks in ntdll's change functions (in addition to the ones already in the server). Alternatively, we could just have the change functions run the run loop themselves, in a special mode (see CFRunLoopRunInMode()) dedicated to waiting for directory changes. I'm not sure how you or AJ feel about that, though. We'd still have to have #ifdef blocks in ntdll, though, if we do it this way. >> >> 3) Do this in a non-Wine process spun off from the wineserver for the sole purpose of bridging the notifications from a CFRunLoop/Mach port-based mechanism to a file descriptor. If we do it this way, we may as well just spin off a new thread (suggestion 1). It's cheaper to spawn threads rather than processes. There's an argument to be made for saving Unix handles in the server, but I don't think saving one handle (the write end of a pipe) just for this is worth it. There's also the whole "wineserver should be single-threaded" argument, but I already wrote about that under 1). > > 4) Use kqueue directly, with its vnode filter. It would entail opening every directory in a hierarchy, which might be deemed prohibitive. We could run out of Unix handles pretty quickly if we do it that way. As I recall, the limit on the number of open FDs a process can have is pretty low by default (only 2560 on my system). Of course, the user could raise this limit (the hard limit is unlimited), but still I don't feel comfortable painstakingly opening tens, hundreds, possibly even thousands of file descriptors at once just to watch for changes to them. Chip

March 21, 2011

Re: user32: Fix return value when passing a non-sibling preceding window to SetWindowPos.

by Dmitry Timoshkov

David Hedberg <dhedberg(a)codeweavers.com> wrote: > +#define ERROR_ABORT_WITH_TRUE 30000 ... > /* Fix redundant flags */ > - if (!fixup_flags( winpos )) return FALSE; > + ret = fixup_flags( winpos ); > + if(ret == ERROR_FUNCTION_FAILED) > + return FALSE; > + else if(ret == ERROR_ABORT_WITH_TRUE) > + return TRUE; Please try to avoid made up names and internal conditions. I'd suggest to add a test case which shows the problem first with todo_wine around the failing test, and only then send a fix, so it's clear what actually your patch is doing. Tiny nitpick, in the code below: if (condition1) return something1; else if (contition2) return something2; 'else' statement is redundant. -- Dmitry.

March 21, 2011

Re: [1/4] wined3d: don't create VBOs in buffer::preload

by Henri Verbeet

On 20 March 2011 20:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I'm not so sure about this patch. I think preload() should conceptually be "wined3d_resource_load_location(resource, WINED3D_RESOURCE_LOCATION_GPU, NULL);", and this patch seems to move away from that rather than towards it. I'm also not sure about how the bug you're describing would actually happen. Although device_stream_info_from_declaration() seems to assume preload() can only drop buffer objects, it does correctly call buffer_get_sysmem(), so the resulting stream info should be consistent, even though perhaps somewhat sub-optimal. Shouldn't this just be a matter of fixing device_stream_info_from_declaration() to not assume preload() can only drop buffer objects?

March 21, 2011

Re: wined3d: Prevent crash when blit_priv is NULL.

by Konrad Rzepecki

Dnia poniedziałek, 21 marca 2011, napisałeś(aś): > You should try to figure out why blit_priv is NULL. That's the real > issue. I wish to know, where to search. But my patch prevent crash if blit_priv is NULL form some reason. This is best place I found to fallback to software. > What drivers are you using? Binary NVIDIA on GF Ti4200 > Do they support arb fragment program? Im not sure, it is OGL 1.5.8 but with these extensions available (only revelant part): GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_NV_register_combiners, GL_NV_register_combiners2, GL_NV_texture_env_combine4, GL_NV_texture_shader, GL_NV_texture_shader2, GL_NV_texture_shader3, GL_NV_vertex_program, GL_NV_vertex_program1_1 For sure hardware support vertex and fragment 1.X. > Right now we may still call arbfp_blit_surface when the > extension isn't around (was working on this a year ago, haven't had > time since then :( ), this could explain why there is no priv_data > since in ffp_blit_alloc we don't do any allocation. I can't help with that, for now we can print FIXME when blit_priv is NULL so this situation is not forget. -- Konrad Rzepecki (Hannibal)

March 21, 2011

Re: Xbox 360 controller compatibility

by Alesh Slovak

On 21 March 2011 05:46, Austin English <austinenglish(a)gmail.com> wrote: > http://www.winehq.org/pipermail/wine-patches/2008-November/064302.html > http://www.winehq.org/pipermail/wine-patches/2008-November/064304.html > http://www.winehq.org/pipermail/wine-patches/2008-November/064305.html > These patches appear to only add a stub and implement test cases. As far as I can tell, it seems the stub and test cases in current git are based on these patches. I've also found a set of patches by Michael Gruber from 2009 that appear to actually implement xinput: http://marc.info/?l=wine-patches&m=124710119700598&w=4 http://marc.info/?l=wine-patches&m=124710124200662&w=4 http://marc.info/?l=wine-patches&m=124710129100718&w=4 http://marc.info/?l=wine-patches&m=124710132300760&w=4 What do people think of these?

March 21, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Ben Klein

On 21 March 2011 15:47, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > On 3/20/11 10:28 PM, Ben Klein wrote: >> On 21 March 2011 15:10, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>> On 3/20/11 9:31 PM, Ben Klein wrote: >>>> On 21 March 2011 12:26, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>>>> Also, as near as I can tell, this will only work on x86 Linux. It won't >>>>> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >>>>> because the 'start' code invokes execve(2) using the interrupt 80h >>>>> interface. Even if other systems use int 80h for their syscall vector >>>>> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >>>>> aren't the same across different platforms. >>>> >>>> Does this also mean it will fail to work on amd64/ia64 systems? >>> For 32-bit (x86) code running on an x86-64/IA64 system, it will work. >>> For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels >>> keep the old int 80h interface around solely for the benefit of old >>> 32-bit programs (like old versions of Wine, before Maarten Lankhorst and >>> AJ fixed it) that expect it to be there. >>> >>> In fact, even if 64-bit code supported the int 80h interface, it still >>> wouldn't work, because even across different architectures on Linux, the >>> syscall numbers are different. >> >> Thanks for explaining it. >> >> Something else I noticed in this patch though; what happens to the >> environment variables handled by the loader script? > Nothing. He even hard-coded the path to the 'wine' binary (as a series > of DWORDs, no less!). I suspected that's what was going on. Basically, this patch makes absolutely no logical sense at all.

March 21, 2011

Re: Xbox 360 controller compatibility

by Roderick Colenbrander

On Sun, Mar 20, 2011 at 3:48 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Sunday 20 March 2011 21:46:34 Austin English wrote: >> > There are some patches still around (would have to look them up) and >> > they work. > <warn reason="clueless"> > I think the main problem with implementing xinput.dll isn't xinput itself, it > is the lack of a proper joystick infrastructure in wine. Currently dinput.dll > reads the /dev/js* devices directly, but preferably joystick input should be > done over the X server and winex11.drv. This needs some tricky adjustments, > winex11.drv isn't a place where you can just add some hacky code and hope > Alexandre doesn't notice. > </warn> > Yeah, that was indeed part of the discussion we had last year when this came up. With the direction X11 is taking, I doubt there will ever be proper joystick support in X11. I fear the only way is /dev/evdev (not that portable)... which was what the patches were using. Roderick

March 21, 2011

Re: wined3d: Prevent crash when blit_priv is NULL.

by Roderick Colenbrander

Hi Konrad, You should try to figure out why blit_priv is NULL. That's the real issue. What drivers are you using? Do they support arb fragment program? Right now we may still call arbfp_blit_surface when the extension isn't around (was working on this a year ago, haven't had time since then :( ), this could explain why there is no priv_data since in ffp_blit_alloc we don't do any allocation. Roderick On Sun, Mar 20, 2011 at 3:58 AM, Konrad Rzepecki <hannibal(a)astral.lodz.pl> wrote: > Might&Magic VII from gog.com crash in bink movie plaing: > > Backtrace: > =>0 0x7e70c4b9 arbfp_blit_set+0x28b(blit_priv=0x0(nil), gl_info=0x135b08, surface=0x1dc788) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/arb_program_shader.c:7058] in wined3d (0x0033f98c) > 1 0x7e70d3db arbfp_blit_surface+0xa2(device=0x16cdc0, src_surface=0x1dc788, src_rect=0x33fa74, dst_surface=0x168140, dst_rect_in=0x33fa84, blit_op=BLIT_OP_BLIT, Filter=0x2) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/arb_program_shader.c:7192] in wined3d (0x0033f9dc) > 2 0x7e7d28f7 IWineD3DSurfaceImpl_BltOverride+0xf1b(dst_surface=0x168140, DestRect=0x33fcf8, src_surface=0x1dc788, SrcRect=0x33fce8, flags=0x1000000, DDBltFx=(nil), Filter=WINED3DTEXF_LINEAR) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/surface.c:3787] in wined3d (0x0033fbac) > 3 0x7e7d3013 IWineD3DSurfaceImpl_Blt+0x29e(iface=0x168140, DestRect=0x33fcf8, src_surface=0x1dc788, SrcRect=0x33fce8, flags=0x1000000, DDBltFx=(nil), Filter=WINED3DTEXF_LINEAR) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/surface.c:3930] in wined3d (0x0033fc2c) > 4 0x7e8687f2 ddraw_surface7_Blt+0x380(iface=0x135308, DestRect=0x33fcf8, SrcSurface=0x1dc560, SrcRect=0x33fce8, Flags=0x1000000, DDBltFx=(nil)) [/mnt/skopia/devel/winegit/wine/dlls/ddraw/surface.c:908] in ddraw (0x0033fc9c) > 5 0x004a18cd in mm7-rel (+0xa18cc) (0x0033fcc8) > 6 0x004beda4 in mm7-rel (+0xbeda3) (0x0033fd08) > 7 0x004be721 in mm7-rel (+0xbe720) (0x00000000) > --- > dlls/wined3d/surface.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 745bd77..baa032b 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -3924,8 +3924,8 @@ static HRESULT WINAPI IWineD3DSurfaceImpl_Blt(IWineD3DSurface *iface, const RECT > } > > /* Special cases for RenderTargets */ > - if ((This->resource.usage & WINED3DUSAGE_RENDERTARGET) > - || (src && (src->resource.usage & WINED3DUSAGE_RENDERTARGET))) > + if (This->resource.device->blit_priv && ((This->resource.usage & WINED3DUSAGE_RENDERTARGET) > + || (src && (src->resource.usage & WINED3DUSAGE_RENDERTARGET)))) > { > if (SUCCEEDED(IWineD3DSurfaceImpl_BltOverride(This, DestRect, src, SrcRect, flags, DDBltFx, Filter))) > return WINED3D_OK; > -- > 1.7.4.1 > > >

March 21, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Charles Davis

On 3/20/11 10:28 PM, Ben Klein wrote: > On 21 March 2011 15:10, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> On 3/20/11 9:31 PM, Ben Klein wrote: >>> On 21 March 2011 12:26, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>>> Also, as near as I can tell, this will only work on x86 Linux. It won't >>>> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >>>> because the 'start' code invokes execve(2) using the interrupt 80h >>>> interface. Even if other systems use int 80h for their syscall vector >>>> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >>>> aren't the same across different platforms. >>> >>> Does this also mean it will fail to work on amd64/ia64 systems? >> For 32-bit (x86) code running on an x86-64/IA64 system, it will work. >> For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels >> keep the old int 80h interface around solely for the benefit of old >> 32-bit programs (like old versions of Wine, before Maarten Lankhorst and >> AJ fixed it) that expect it to be there. >> >> In fact, even if 64-bit code supported the int 80h interface, it still >> wouldn't work, because even across different architectures on Linux, the >> syscall numbers are different. > > Thanks for explaining it. > > Something else I noticed in this patch though; what happens to the > environment variables handled by the loader script? Nothing. He even hard-coded the path to the 'wine' binary (as a series of DWORDs, no less!). Chip

March 21, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Ben Klein

On 21 March 2011 15:10, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > On 3/20/11 9:31 PM, Ben Klein wrote: >> On 21 March 2011 12:26, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>> Also, as near as I can tell, this will only work on x86 Linux. It won't >>> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >>> because the 'start' code invokes execve(2) using the interrupt 80h >>> interface. Even if other systems use int 80h for their syscall vector >>> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >>> aren't the same across different platforms. >> >> Does this also mean it will fail to work on amd64/ia64 systems? > For 32-bit (x86) code running on an x86-64/IA64 system, it will work. > For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels > keep the old int 80h interface around solely for the benefit of old > 32-bit programs (like old versions of Wine, before Maarten Lankhorst and > AJ fixed it) that expect it to be there. > > In fact, even if 64-bit code supported the int 80h interface, it still > wouldn't work, because even across different architectures on Linux, the > syscall numbers are different. Thanks for explaining it. Something else I noticed in this patch though; what happens to the environment variables handled by the loader script?

March 21, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Charles Davis

On 3/20/11 9:31 PM, Ben Klein wrote: > On 21 March 2011 12:26, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> Also, as near as I can tell, this will only work on x86 Linux. It won't >> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >> because the 'start' code invokes execve(2) using the interrupt 80h >> interface. Even if other systems use int 80h for their syscall vector >> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >> aren't the same across different platforms. > > Does this also mean it will fail to work on amd64/ia64 systems? For 32-bit (x86) code running on an x86-64/IA64 system, it will work. For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels keep the old int 80h interface around solely for the benefit of old 32-bit programs (like old versions of Wine, before Maarten Lankhorst and AJ fixed it) that expect it to be there. In fact, even if 64-bit code supported the int 80h interface, it still wouldn't work, because even across different architectures on Linux, the syscall numbers are different. Chip

March 21, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Ben Klein

On 21 March 2011 12:26, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > Also, as near as I can tell, this will only work on x86 Linux. It won't > work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is > because the 'start' code invokes execve(2) using the interrupt 80h > interface. Even if other systems use int 80h for their syscall vector > (Mac OS does, at least for Unix syscalls), the syscall numbers usually > aren't the same across different platforms. Does this also mean it will fail to work on amd64/ia64 systems?

March 21, 2011

Re: Xbox 360 controller compatibility

by Alesh Slovak

Thanks all for the info and insight. On 21 March 2011 07:48, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Sunday 20 March 2011 21:46:34 Austin English wrote: > > > There are some patches still around (would have to look them up) and > > > they work. > <warn reason="clueless"> > I think the main problem with implementing xinput.dll isn't xinput itself, > it > is the lack of a proper joystick infrastructure in wine. Currently > dinput.dll > reads the /dev/js* devices directly, but preferably joystick input should > be > done over the X server and winex11.drv. This needs some tricky adjustments, > winex11.drv isn't a place where you can just add some hacky code and hope > Alexandre doesn't notice. > </warn> > If dinput is currently implemented this way, what's the problem with implementing xinput in the same way, at least for now? It can always be refactored later if needed. Is this the only reason why the patches didn't make it in before?

March 21, 2011

Re: [PATCH] winegcc - do not create .exe.so

by James McKenzie

On 3/20/11 4:14 AM, Pali Rohár wrote: > 2011/2/19 Pali Rohár<pali.rohar(a)gmail.com>: >> 2011/2/4 Pali Rohár<pali.rohar(a)gmail.com>: >>> Hello, >>> >>> I created patch which implement correct _start section in ELF shared >>> libraries/binaries which generate winegcc. >>> Into _start section this patch add calling execve syscall which start >>> wine with all arguments. So it is not needed to generate shell wrapper >>> and .exe.so binary. >>> >>> This replace code on: >>> http://wiki.winehq.org/Winelib_binaries_as_ELF_executables_not_.exe.so >>> >>> $ winegcc app.c --> generate only a.exe (shared object ELF binary), no >>> aditional a.exe.so >>> $ ./a.exe --> start binary correctly without shell wrapper >>> >>> -- >>> Pali Rohár >>> pali.rohar(a)gmail.com >>> >> I rewrited my patch. Now set up correctly enviromental variables too. >> Assembler code is only for x86. >> >> -- >> Pali Rohár >> pali.rohar(a)gmail.com >> > Can anybody review my patch? > Reviews are sent to wine-development list. If you want to submit a patch for comment only, please submit it to wine-development. Thank you. James McKenzie

March 21, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Charles Davis

On 3/20/11 6:54 PM, Chris Robinson wrote: > On Sunday, March 20, 2011 4:37:07 PM Vitaliy Margolen wrote: >> On 03/20/2011 05:14 AM, Pali Rohár wrote: >>> Can anybody review my patch? >> >> Not sure what you trying to do exactly. Wine already has wrapper that makes >> all wine binaries executable after they are being installed into system. > > Wine installs wrapper scripts which call wine with the appropriate .exe.so > DSO. The .exe.so file can't be run directly. > > As far as I can tell, the patch makes it so the .exe.so file can be run > directly, by adding a _start section that automatically execs wine with all > the same arguments passed on the command line. As a result, it removes the .so > extension so you can, for example, just run the 'winecfg.exe' executable > itself, with no 'winecfg' wrapper script needed. It's not enough to have a 'start' symbol. The binary has to be of the right type, too. On Mac OS, for example, the binary has to be of the MH_EXECUTE type (instead of MH_BUNDLE, which it would be right now), or you won't be able to execve(2) it. With ELF, the binary type has to be ET_EXEC (instead of ET_DYN). Also, I don't know if Mac OS, Linux, or any other platform allows you to dlopen(3) something that isn't a DSO (MH_DYLIB and MH_BUNDLE on Mac OS, ET_DYN on ELF platforms). In that case, the right answer might just be to leave this alone. Another solution might be to re-implement the Wine loader logic in the executable itself, but I'm not sure if that's a good idea. Also, as near as I can tell, this will only work on x86 Linux. It won't work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is because the 'start' code invokes execve(2) using the interrupt 80h interface. Even if other systems use int 80h for their syscall vector (Mac OS does, at least for Unix syscalls), the syscall numbers usually aren't the same across different platforms. Chip

March 21, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Vitaliy Margolen

On 03/20/2011 06:54 PM, Chris Robinson wrote: > As far as I can tell, the patch makes it so the .exe.so file can be run > directly, by adding a _start section that automatically execs wine with all > the same arguments passed on the command line. As a result, it removes the .so > extension so you can, for example, just run the 'winecfg.exe' executable > itself, with no 'winecfg' wrapper script needed. This is what I understood as well. My problems with the patch are: - This should be platform independent and working everywhere Wine works - It should be optional at very minimum. It's not possible to run shared libraries for a reason. - Calling something .exe doesn't magically make it a PE-executable. You can't call ELF shared library a windows executable. File can stay .exe.so and still be executable as they are now Vitaliy.

March 21, 2011