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