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

Re: ntdll: Use lockfree implementation for get_cached_fd.

by Sebastian Lackner

Hi Ken, thanks for taking a look at it and for the detailed answer. [...] > > Thanks for working on this. Interesting stuff. > > I think there are still some issues. > > In order to ensure a consistent view of the ordering of memory operations, memory barriers have to be used in both the writer and the reader. The writer issues a write barrier after it has written and the reader issues a read barrier before it reads. > > The appropriate barriers are implicit in interlocked_xchg_add() for incrementing fd_cache_epoch, but the first read of it in get_cached_fd() has no read barrier before it. I think this is benign, though, because I think this can only result in the code thinking the epoch changed when it hasn't. It may retry unnecessarily. get_cached_fd() will only have to run multiple iterations if a second thread updated the cache in the meantime. As it is more likely to have a cache hit I would assume that its okay, when fd_cache_epoch returns a cached value - but of course this depends on the exact program you're running. > More problematic is the writing of the fd and its attributes. There are barriers implicit in the interlocked_xchg() which clears the fd, but there's no write barrier after the final write to it. There's no read barrier before the first read of them. > > You mention the order of writing, attributes first then fd, as being important. But there's no barrier in between the two operations, so either the compiler or the CPU could reorder either the writes or the reads, thwarting your design. The compiler can also reorder the reading of the fd_cache_epoch with respect to the reading of the fd or attributes. I think you can get this as the effective sequence: > > thread1 / get_cached_fd / read fd, get old fd > thread2 / add_fd_to_cache / clear fd > thread2 / add_fd_to_cache / increment epoch > thread2 / add_fd_to_cache / set fd > thread1 / get_cached_fd / read epoch > thread1 / get_cached_fd / check if epoch has changed, conclude it hasn't > thread1 / get_cached_fd / return old fd > > I think it's sufficient to have a write barrier after writing the fd and then a read barrier just before reading it. I _think_ that this obviates the need for the barrier at the bottom of the do-while loop. That is, you can just move that barrier up a line. I'm not 100% confident of my analysis of that. (Well, frankly, I'm never 100% certain of my analysis of this sort of code.) I have to agree that this is a bit tricky - but I don't think that moving the line one up would completely solve it. The compiler could still reorder (read epoch) and (read attributes), which could result in using wrong attributes. Moreover it there is no barrier at the original place it could still reorder (read epoch 2) and (read fd). To be completely sure it would be necessary to add compiler memory barriers everywhere inbetween ... which would make the code look very ugly... xD Nevertheless, the example above couldn't happen that way: As add_fd_to_cache() is only used to set the file descriptor, not to replace it, the old fd would be (-1) in this case. ;) > > In the email thread regarding Daniel Horn's patch, I suggested an approach using interlocked_cmpxchg() to check if the fd had changed after reading the attributes. Was there a reason you rejected that approach? You mentioned an approach you experimented with using interlocked_cmpxchg64(). What was that about? Were you treating the fd and attributes combined as a single 64-bit value and then checking them both? Was that safer than my suggestion for some reason? > > If the only advantage is a slight performance improvement (especially in light of the huge difference that either approach has to the status quo, judging by your chart), then I'd argue for the simpler approach that's more easily analyzed for correctness. > My approach was indeed treating both the fd and the attributes as a single 64-bit number. This way we can read/write both fd and attributes at the same time, which definitely solves all multithreading issues. I still think that this is probably the best way to do it - with the only disadvantage that it doesn't work on PowerPC. :/ I have attached a patch showing this approach to the mail. Using interlocked_cmpxchg() to verify only the fd doesn't seem to be safe to me: thread1 / get_cached_fd / read fd and attributes thread2 / release old handle thread2 / allocate new object with the same handle (unlikely, but ...) thread1 / get_cached_fd / compares fd one more time -> looks like everything okay This basically means that applications could assume that wrong attributes are associated with a specific file handle. I know that this is very unlikely (especially because the handles contain the generation in the upper 16bit), but it is still possible... Or is there any reason why we can be sure that this doesn't happen? > > If the above issue is addressed, that leaves one remaining problem: get_cached_fd() can encounter a false negative: > > thread1 / add_fd_to_cache / set fd to -1 > thread1 / add_fd_to_cache / increment epoch > thread2 / get_cached_fd / read epoch > thread2 / get_cached_fd / read attributes > thread2 / get_cached_fd / read fd, gets -1 > thread2 / get_cached_fd / check if epoch has changed, conclude it hasn't > thread1 / add_fd_to_cache / set attributes > thread1 / add_fd_to_cache / set fd > thread2 / get_cached_fd / return -1 > thread2 / server_get_unix_fd / see get_cached_fd as having failed since it returns -1 > thread2 / server_get_unix_fd / do get_handle_fd server request > thread2 / server_get_unix_fd / call add_fd_to_cache to cache the new fd > > I think you want to try get_cached_fd() again, inside the critical section, if the first call fails. This should be fixed in try 2. >> > * Replace interlocked_xchg() with an assert(). The original code looks >> > like its valid that the fd is nonzero at this point, but in fact this >> > would cause releasing a file descriptor which is still in use. > I'll leave it to others to comment on that. > >> > Replacing with an assert() also saves a couple of CPU cycles. > I understand that this is an attempt to improve performance, but I don't think it's necessary to squeeze every last CPU cycle out of this code. This was not done to improve the performance, but instead to detect errors more easily. If the fd is already set it always means that something is going wrong. The current code hides these kind of errors by just closing the file handle and replacing it - that was also the reason why I assumed one call to get_cached_fd() is sufficient, as it looks like the code handles already the case if fd is set - but in fact it will close a handle which is still in use... > > -Ken > What do you think about the alternative (slightly slower, but much easier to verify) solution attached to this mail? Regards, Sebastian

May 31, 2014

Re: ntdll: Use lockfree implementation for get_cached_fd. (try 2)

by Ken Thomases

On May 31, 2014, at 12:05 PM, Sebastian Lackner wrote: > Changes in try 2: > > * Always try to access the fd cache two times - this ensures that we > don't release a file descriptor when its still in use by a second thread. Heh. Well, you can ignore that part of my reply to your previous try. :) > * Replace interlocked_xchg() with an assert(). The original code looks > like its valid that the fd is nonzero at this point, but in fact this > would cause releasing a file descriptor which is still in use. I'll leave it to others to comment on that. > Replacing with an assert() also saves a couple of CPU cycles. I understand that this is an attempt to improve performance, but I don't think it's necessary to squeeze every last CPU cycle out of this code. -Ken

May 31, 2014

Re: ntdll: Use lockfree implementation for get_cached_fd.

by Ken Thomases

On May 31, 2014, at 10:28 AM, Sebastian Lackner wrote: > Explanation: The basic idea of this patch is that we have a global > counter 'fd_cache_epoch' which is incremented, whenever the file > descriptor cache is updated. get_cached_fd() first reads the counter, > then the fd entry, and afterwards the counter again - if the counter has > changed we know that a second thread has maybe modified the content, and > have to read it again. The memory barrier is there to ensure that > compilers don't optimize away the two reads of 'fd_cache_epoch'. Please > note that: > > * the order of the write instructions when updating the content is > important - this way we ensure that threads only see either (0, *) = not > set, or a valid entry. > > * I assume that reading/writing up to the pointer size can be done as an > atomic operation (threads either see the old or new value, but no > partial updates). This assumption is also used in a lot other parts of > wine, for example here: > http://source.winehq.org/source/dlls/ntdll/sync.c#L1295 > [ It would probably be more safe to introduce special > interlocked_get/interlocked_set macros/functions for that, but not sure > what other people think about that... ] Thanks for working on this. Interesting stuff. I think there are still some issues. In order to ensure a consistent view of the ordering of memory operations, memory barriers have to be used in both the writer and the reader. The writer issues a write barrier after it has written and the reader issues a read barrier before it reads. The appropriate barriers are implicit in interlocked_xchg_add() for incrementing fd_cache_epoch, but the first read of it in get_cached_fd() has no read barrier before it. I think this is benign, though, because I think this can only result in the code thinking the epoch changed when it hasn't. It may retry unnecessarily. More problematic is the writing of the fd and its attributes. There are barriers implicit in the interlocked_xchg() which clears the fd, but there's no write barrier after the final write to it. There's no read barrier before the first read of them. You mention the order of writing, attributes first then fd, as being important. But there's no barrier in between the two operations, so either the compiler or the CPU could reorder either the writes or the reads, thwarting your design. The compiler can also reorder the reading of the fd_cache_epoch with respect to the reading of the fd or attributes. I think you can get this as the effective sequence: thread1 / get_cached_fd / read fd, get old fd thread2 / add_fd_to_cache / clear fd thread2 / add_fd_to_cache / increment epoch thread2 / add_fd_to_cache / set fd thread1 / get_cached_fd / read epoch thread1 / get_cached_fd / check if epoch has changed, conclude it hasn't thread1 / get_cached_fd / return old fd I think it's sufficient to have a write barrier after writing the fd and then a read barrier just before reading it. I _think_ that this obviates the need for the barrier at the bottom of the do-while loop. That is, you can just move that barrier up a line. I'm not 100% confident of my analysis of that. (Well, frankly, I'm never 100% certain of my analysis of this sort of code.) In the email thread regarding Daniel Horn's patch, I suggested an approach using interlocked_cmpxchg() to check if the fd had changed after reading the attributes. Was there a reason you rejected that approach? You mentioned an approach you experimented with using interlocked_cmpxchg64(). What was that about? Were you treating the fd and attributes combined as a single 64-bit value and then checking them both? Was that safer than my suggestion for some reason? If the only advantage is a slight performance improvement (especially in light of the huge difference that either approach has to the status quo, judging by your chart), then I'd argue for the simpler approach that's more easily analyzed for correctness. If the above issue is addressed, that leaves one remaining problem: get_cached_fd() can encounter a false negative: thread1 / add_fd_to_cache / set fd to -1 thread1 / add_fd_to_cache / increment epoch thread2 / get_cached_fd / read epoch thread2 / get_cached_fd / read attributes thread2 / get_cached_fd / read fd, gets -1 thread2 / get_cached_fd / check if epoch has changed, conclude it hasn't thread1 / add_fd_to_cache / set attributes thread1 / add_fd_to_cache / set fd thread2 / get_cached_fd / return -1 thread2 / server_get_unix_fd / see get_cached_fd as having failed since it returns -1 thread2 / server_get_unix_fd / do get_handle_fd server request thread2 / server_get_unix_fd / call add_fd_to_cache to cache the new fd I think you want to try get_cached_fd() again, inside the critical section, if the first call fails. -Ken

May 31, 2014

Re: ntdll/tests: Fix exception test failures on x86_64.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7354 Your paranoid android. === w2000pro (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00950000/00950001 exception: unhandled exception 80000004 at 00950000 exception.c:406: Test failed: 42: Wrong exception address 7C5C20B0/00950001 === wxppro (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00A30000/00A30001 exception: unhandled exception 80000004 at 00A30000 exception.c:406: Test failed: 42: Wrong exception address 7C80DF3C/00A30001 === wvistau64 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003D0000/003D0001 exception: unhandled exception 80000004 at 003D0000 exception.c:406: Test failed: 42: Wrong exception address 7751ED97/003D0001 === w2008s64 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:406: Test failed: 42: Wrong exception address 77E5ED97/003C0001 === w7u (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:406: Test failed: 42: Wrong exception address 77CDE34F/003C0001 === w8 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00290000/00290001 exception: unhandled exception 80000004 at 00290000 exception.c:406: Test failed: 42: Wrong exception address 77174D17/00290001

May 31, 2014

Re: dmscript/tests: Test some IPersistStream methods of DMScriptTrack.

by Michael Stefaniuc

On 05/30/2014 11:37 PM, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://testbot.winehq.org/JobDetails.pl?Key=7339 > > Your paranoid android. > > > === build (build) === > Patch failed to apply Correct as it depends on a previously sent patch that is not committed yet. Here are the "all green" results from the cumulative patch: https://testbot.winehq.org/JobDetails.pl?Key=7334 bye michael

May 31, 2014

Re: dmscript/tests: Test some IPersistStream methods of DMScriptTrack.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7339 Your paranoid android. === build (build) === Patch failed to apply

May 30, 2014

Re: wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-30 19:51, schrieb Andrei Slăvoiu: > I find it strange that there are 2 completely different code paths > for determining card capabilities. So I was thinking to share the > code between d3d_level_from_gl_info and shader_glsl_get_caps. Yes, the double implementation of those similar functionalities is unfortunate and fixing this is a good idea. I'd say migrating to MESA_query_renderer supersedes this work and is the better long-term goal. > Since such shared code needs to be able to differentiate between > d3d 9 with SM 2 and d3d 9 with SM 3 I was wondering if it would be > a good idea to expose SM info to the current callers of > d3d_level_from_gl_info to pick Radeon 9500 for SM2 or Radeon X1600 > for SM3. I think just looking at the vertex shader version should work, as I suggested in an earlier mail. I don't think this needs a DirectX version at all. Also, don't call shader_glsl_get_caps directly - call the get_caps method exported by the selected shader backend. There are two caveats: To separate version 7 from version 6 you'll need information from the fixed function fragment pipeline. This shouldn't be hard to do. The other thing to keep in mind is that by calling the shader backend, the card may present itself with a different PCI ID when switching between ARB and GLSL shaders. Arguably this is even the correct thing to do, as the ARB shader backend supports only Shader Model 2 on most cards. Reporting a Radeon 9500 instead of Radeon HD 8000 when the user selects ARB shaders sounds like a good idea in general. It may make debugging shader backend differences harder though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTiMfCAAoJEN0/YqbEcdMwcnMP/iWFXx0L/765OI73ZrNtOGfK V7eeo1e/NwcNrqjmyux2AiaGAEpeDIqIPr3hUlvJtOSe7Vm6LnY0XNUtGGV0Hdlh XEIKm/Obl6GrUbjPWCOnWIRmvPRj/SS3r48pG/shYy81dEUBMLhRrXmVNqvacMdR 7xP5NNEBhJI8uI8EYgTlcgmyZ6Iv8an+uu5afJTsnrvBZBNJzM1Kh6RhHjb5r7Qq REB6HzO3ryu3zMv3wSN6iNMJo+Tod8edO+IEpDfblPD+GiBSQScXX7UWPdPpnpUw QVdxA4crGBlu1/+a3sbI1M4Q66EGnlATWT7NwKI3ubj6VEjMqFkSC3QZzY3wLnX3 MxR8MJWww5IgwCSS5VTyhLqsmuFSl5ch0P1Iq2P35M3Tq85g1i1av/B8x5PuxufT J6lmX1ohcyMsEAR6qtb84OCpofeddUQgxVlAjpVuv3i4lzLZjc5WgW46t3pYxM3f /lgxMF8iA7D+TwuUZ2RC+wJM4qAcB7jpwMucFgWuIk4AEBlDEgJR5q7k71HaCpFK wp2fIX9jLU9UJb4d9wxcULhiA6rg+SgS2eFM7pSrKsvyhqQMcGhQDV1xvKRt71SW r3tY6Ov/7VSAdfT5MLfYoGmHqMuK9tSaekmqGRKw/yeMUECfL52DfFPbQl/7uQik OsKveCiQsOtsSN5QUiao =lXuc -----END PGP SIGNATURE-----

May 30, 2014

Re: wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)

by Andrei Slăvoiu

În ziua de Vin 30 Mai 2014, la 09:36:01, Stefan Dösinger a scris: > Am 2014-05-29 20:53, schrieb Andrei Slăvoiu: > > After reading the message again I think I finally understood what > > you meant. I'll send a try 4 that adds back glsl_version check (try > > 2 was missing a brace). Do you think returning 93 (meaning d3d > > level 9_3 or d3d 9 with SM 3) would be too ugly? So wine can choose > > X1300 as card if ARB_shader_texture_lod is exposed but not GLSL > > 1.30. > > What's wrong with 9 in that case? I find it strange that there are 2 completely different code paths for determining card capabilities. So I was thinking to share the code between d3d_level_from_gl_info and shader_glsl_get_caps. Since such shared code needs to be able to differentiate between d3d 9 with SM 2 and d3d 9 with SM 3 I was wondering if it would be a good idea to expose SM info to the current callers of d3d_level_from_gl_info to pick Radeon 9500 for SM2 or Radeon X1600 for SM3. Alternatively I could leave it return 9 as it does now and add an extra parameter that will return the shader model. Probably that would be cleaner.

May 30, 2014

Re: Video memory size detection in D3D

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-30 15:25, schrieb Ruslan Kabatsayev: > Hmm, this is an interesting point. But, for > GLX_MESA_query_renderer, which appeared relatively recently, one > can't say it's experimental or cannot return the total memory. Can > its use be accepted by Wine? Maybe at some point Nvidia/AMD will > implement it too (looks unlikely though), but at least for > Mesa-powered drivers it would work. Yes, I see no reason why we can't use GLX_MESA_query_renderer. We still need the fallback path for drivers that do not support it though. It's important to note that wined3d itself cannot use it. Wined3d uses WGL, not GLX. winex11.drv has to use GLX_MESA_query_renderer, and it can export its functionality to wined3d in the form of a WGL extension that is similar or equal to GLX_MESA_query_renderer. winemac.drv can export the same extension. There are OSX functions to query the PCI IDs and video memory size. (I forgot the name though). As far as I know the NV-CONTROL X11 (not GLX) extension exposes the same information, but doesn't have the issue that it's specification isn't finalized. Winex11.drv could in theory use it if GLX_MESA_query_renderer is not available. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTiIk6AAoJEN0/YqbEcdMw+GwP/2ia45TTEJPLthGMoReA13iX 8M2NplPwR+SHaPSSR6U9jUre80Q5p8amFh8gM896Rw8uoq0qB6Y5c8VtMlkPdYgp WzfKqjxJJC4Jt8csTT/m245f82lf78qLsWRfZTMYwiX5921NmCqC4SEbs7FnYGp9 FpIdDEmTQ1NLS9C5bdCBUtQbY9jBMekyM9x8+5acLyhDgjw+GwDIRHPgbKokNix3 c0RdYoXFcRl3aUKGTR7zM7CHjS9e56Oi6HApfaxBr0ElMh7uM40pjug/pHMz6hqE dBWUuViOwnt6vJqUBGcSTc6nmEAFVvW+Gnpxo3wKxjsByUQ9BiviGGOkf1QOm7HI /RCRAD2UL888ujFOglRyA7/Ss72qFKXTEy6utuX1qne2gJrjbnfSLD/Hb2UZV7f7 WrDJ9Mmma3xh+xMtuqL/3HHRUyEc3z+4TamOwFwlYeNMoUH8DJ2dWPRcjD5VfuG8 sb+MTtkONNnWjH5R28TVhJFKqNjN9CL2rwfShw15CbG2I/HJ+OWxK1lSREbne2Er WNjtPOh03e7I+KTm6bB5H6xr+aLO+DjLvKmmaqek+Ap+8ebqfLBGh9EtoHBxRfAs wtl8ImBXxo/M0O6sIo9N2OG6CefQ5bcpsHABjj0noKEF2Zqv8L+2kPwadr2DasLf 9rLNpWS58G3lN3BjtxXQ =ifL5 -----END PGP SIGNATURE-----

May 30, 2014

Re: Video memory size detection in D3D

by Ruslan Kabatsayev

On Fri, May 30, 2014 at 5:06 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > On Fri, May 30, 2014 at 5:36 AM, Stefan Dösinger > <stefandoesinger(a)gmail.com> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 2014-05-30 08:01, schrieb Ruslan Kabatsayev: >>> It'd be good if Wine could utilize these. Is there any work >>> towards this already? >> See the discussion between Andrei Slăvoiu and myself on this list. I >> don't know if Andrei will decide to have a look at the extension, it's >> his choice. Other than that I don't know of any efforts in this area. >> You're welcome to chime in :-) . > > Reminds me of some old discussions like: > http://www.winehq.org/pipermail/wine-devel/2012-April/094994.html > (last question/answer). Hmm, this is an interesting point. But, for GLX_MESA_query_renderer, which appeared relatively recently, one can't say it's experimental or cannot return the total memory. Can its use be accepted by Wine? Maybe at some point Nvidia/AMD will implement it too (looks unlikely though), but at least for Mesa-powered drivers it would work.

May 30, 2014

Re: Video memory size detection in D3D

by Bruno Jesus

On Fri, May 30, 2014 at 5:36 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-05-30 08:01, schrieb Ruslan Kabatsayev: >> It'd be good if Wine could utilize these. Is there any work >> towards this already? > See the discussion between Andrei Slăvoiu and myself on this list. I > don't know if Andrei will decide to have a look at the extension, it's > his choice. Other than that I don't know of any efforts in this area. > You're welcome to chime in :-) . Reminds me of some old discussions like: http://www.winehq.org/pipermail/wine-devel/2012-April/094994.html (last question/answer).

May 30, 2014

Re: New Wine patches

by Bruno Jesus

On Mon, May 26, 2014 at 10:36 AM, Chakke, Neha (GE Oil & Gas) <Neha.Chakke(a)ge.com> wrote: > > Hello , > > I am trying to run a GE software and hardware on Debian (Linux platform) using WineHQ. In order to run the hardware we need to install device drivers for USB (Cypress) . > > http://wiki.winehq.org/USB > > I have been trying to look for some solutions online since a week. Could you kindly send me the new wine patches and please guide me with the procedure. > > Thanks and regards, > > Miss Neha Chakke Hi, Wine is not an operating system and doesn't implement the "Windows kernel" infrastructure needed to support various kind of hardware driver classes. Depending on what kind of device it is you can make it work with the Linux kernel and then use it inside wine, Cypress is known to make USB->serial devices, if that is the case there is a chance it will work in wine. See: http://www.winehq.org/docs/wineusr-guide/misc-things-to-configure#AEN715 Best wishes, Bruno

May 30, 2014

Re: Video memory size detection in D3D

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-30 08:01, schrieb Ruslan Kabatsayev: > It'd be good if Wine could utilize these. Is there any work > towards this already? See the discussion between Andrei Slăvoiu and myself on this list. I don't know if Andrei will decide to have a look at the extension, it's his choice. Other than that I don't know of any efforts in this area. You're welcome to chime in :-) . -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTiEMWAAoJEN0/YqbEcdMwUjUQAI2pHgX1xxkgFk3PYPHKKKrd PSyjvMs52IXECXYn2/Ka9hIZuFX43hkAgU+SIOrWQIQtmFqV4NgM+wd9kSX4UJAE 47D1dZtaEdGNLIjhQZFXqv/UeMdcF+yczPKVrQEtFV9+4a44v8kOZ9WoTIvljXG4 dx3k5eat5s00p93Jzq2VFfgpo+upL2xyYZ4C3mba4LRzoWdpLWd5m0nCXvT2OTtR JDa/cm7YCE9EUVvj9ig3vGQEEQRB6K8yrALw78/sO9CJMxBzgwNZ7NWqf+mOPkMP HQSBWk2VobnNgl5GdBZoBbsWmUktAu7v4nxRueK4rxae+UoONDf69xq+UknAMMZQ TdYaE4qYhWosbL3c6z+yfr/B0HqdMHDhRLINNVi5k4W5U6ZnFGkDoAunL3iDuwj/ jqvZTmcLUaLN91Qt1jeqC4lDB3JogUg8RAxfWtPOCczt6Kwi3lyuERGVD5LcI033 haTzl/UawOi301kqdpU/i2JECG/awEnHOJf9VavNMlIHISMrztX/ycoR9XzQbSvC tWq1BvBlgh9RRAUhyVUTN+wDjcD1PVqOcUCKyq7YX5epldRLvz9cVTaU7fsR/LQx Rik792h/yZfQ0jGrbZjxp6PjQW8pP/kyLSy68yiGQcCe33flF4qS1SrEnq6hKxsY gZ+s5KZhERNVcqJvBLp8 =X1PL -----END PGP SIGNATURE-----

May 30, 2014

Re: wined3d: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4 (try 4)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-30 00:45, schrieb Andrei Slăvoiu: > Add back glsl check to make sure the card is capable of DX10. > > --- dlls/wined3d/directx.c | 4 +++- 1 file changed, 3 > insertions(+), 1 deletion(-) Looks good to me. Note that Alexandre and Henri are on holidays right now, so it might take a while before it is committed or you receive further comments. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTiD0QAAoJEN0/YqbEcdMwcjcP/jAOsNo8MoM8sSlc2RVtU7Y5 tHVmUyMZ0xPSa7DaA13GFT7/hPnRXimRY39epjJ3subulmprkXV+HNtaHWBVkEvR lB+YSJJDFGJ9V81o7aVSUfXydeY81C3TB6TbztO9WtVPSVaE9/ZXJ1ZO3edufoXT XhXMJwce9HmL8nU+SRFo+mAc/FLimCuTwMMf6OF61KlAMTkzGSQoh8sUSwO0hndL /+yARXxgYhBAtepVb2vuL7411/VWlbzrD8S8h4sZhEnCgLNuyGjXFyggjTZn+MWd zYf5MgBWmY/YJu1VES3lkM8VM5FpgJgEcM3DG8BEQ3yI5eyBLReMiKQe3uuyhlnJ KdE9tSPP3Ts2gHYeZ90kGImebtjy5sxA0gsekY5J4oNsbDUfO01OoHde+54GG6WD 25aogs1+edJNZMGI6pxScDl6EoPgbTlBjL5dJ2xDYc1P/ACezNqPBe+tCDoqoVon WBlqNSNntcfCUBEoiXpOcRFK0PeJDIMHRKpZEBM63V3gFW6w0KuI+Sj0JcwFxy+u saLOwXDpaGerhar2njWiCEKwM1NfW2Wj7wcY0/eiy56bi9UvhDCAUqqZ98xlFZuP m8Js4Bwzlp7NHQjaqXo/h3uK36B0OngHZkjRm/hXMEFuQHfCSbKtUMZLn27JI+3a chXJiqk95eUes6GLKzGo =tusS -----END PGP SIGNATURE-----

May 30, 2014

Re: wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-29 20:34, schrieb Andrei Slăvoiu: > So use the string provided by EnumDisplayDevices and the PCI ID and > memory size from the WGL extension? Something like that, yes. It needs a few separate pieces of work though - right now EnumDisplayDevicesW is a stub (see dlls/user32/misc.c). I suggest to start with only the WGL extension part and keep the PCI ID -> device name table in wined3d for now. Once this is in place we can worry about EnumDisplayDevices. All this is related to dual GPU support as well. Support for this is virtually nonexistent in winex11, user32 and wined3d, and Linux as a whole doesn't really support a dual-head configuration where one monitor is driven by an AMD GPU and the other is driven by an Nvidia GPU. This puts you in the unfortunate position of having to think about multi-GPU support (to avoid making things worse) but not really being able to test things and/or adding lots of infrastructure. OSX and Windows 7 support such multi-gpu configurations. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTiDp9AAoJEN0/YqbEcdMwMywP/RT0fxOeoBYHoJ7G5Tim2Ge/ OL5sq2lQx2DDMIUlJZsp7HRQ7kuaIL86wp0xikOcADa2Lx9mGjr0n4wHSmZi0tse 3RSVJDn1mWPLC6A2YJORLCFX4XZgmkTmcgzm01OozKCNRSJZxxkmCUAEIh4m2WS5 PbBbjHDFs+Y9MmPMl9ThxEV3FjQo4az/lITYqmMRVJFL5wjYT7CvlmfQaNtfmfWa RU+BjexqOjwX0E2RyOobXvGhEOGMDRk+RmqJ0zlV9+W6aSPnC2OHVLmKjM36Bq6V R5rs9ry7IorXpCrXFJ/7c6E5ST0SJPL9QiI5+I9qSOooLgCT10dSXiuvYItXfIrH 9KdiW3abQ2JzVbVD3nE1Y6T4y/GdrPgutYxiFx6IP5brfcoKJWqwpNNu8/ad+ydI d7UmHfkz7naG/uK7bE7zULCSqaT0laFcjiV8wNxi7g8Jsv5uj4LaxvsfhV28xI4r UTp/KNoXibn+a00MuAwJcRm767rnNdnb8qCetSv4i6b2QWUZFHNVsAz8GVrVJmRM eiPvqRsxl+752YjUB5oTv29zLVGudfmKbV691mKIxKv9kqYCxfywnn9C2l2JLrIf kUbvHIokcZ2bB2C03P3E+IarONa+4IMuRbE3FGCfKkhRSi252MooBwlxQKa3S6P6 wzW7P/NLfG9Lk5Gx49Tf =PbT+ -----END PGP SIGNATURE-----

May 30, 2014

Re: wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-29 20:53, schrieb Andrei Slăvoiu: > After reading the message again I think I finally understood what > you meant. I'll send a try 4 that adds back glsl_version check (try > 2 was missing a brace). Do you think returning 93 (meaning d3d > level 9_3 or d3d 9 with SM 3) would be too ugly? So wine can choose > X1300 as card if ARB_shader_texture_lod is exposed but not GLSL > 1.30. What's wrong with 9 in that case? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTiDThAAoJEN0/YqbEcdMwKk0P/2MOncKu93p9IKhv+taJ4ZT2 n4OFBY/ENwNXQUG2sfj36siNc27uFelcJAl6PV5hvTVnVpPZBgjXLIiwXyNlPjIE ZefKNIxclPd/n+fozQlO88VO+dLfde8qCHc3Ywk4uK2gthDgLx3WVrzoolhBb1Bd eNim6OcFn6oL8R9Mq9bWZqDMYemSV/OiR1gWREBzbjFTZcA3ZyCph7houv/fxSbh XE4dpRW4EorW0uzI2i8S5Ti75r3EJIfaRqnJerxyn3PrIaQB2ffkk0eE2VEX8I4n rfg2AVqC3M4RHup5N+6hIvJBKxwXcT03zWNfIUXhzqtFnZhDVY040/Vx9iDaupGG qnzRjTcsfyQjXhTYd+J5NHSTk4LPPhpJaGjm6urj8R34JhUbu9P8tt4Dms11cuCp s6lRujJtL6AuuSl78HS1RjnKZhoKbB9g3/UP6v81xpbfy2lh3Kk2hmpq0NK28tRa QtENO6jr+7qGriwghn6ja5mpV2UdkSWEFCPUi+qj4/6RFPpUwtd0nPNna1z2UgqY N/OedGNYz5eKlox1HRuHQpIO0BFEJfqzvL8Mq323QTCXEQLkzDu1BAR6FiXV48RX RjQH52Eggg940zOFUt67VOQ2k2IunyOGSPfL/SenfxJ21MziAtyL1ok7Fsmtigpf iYndngkbnAkRFpPV7BDe =vrik -----END PGP SIGNATURE-----

May 30, 2014

Video memory size detection in D3D

by Ruslan Kabatsayev

Hello all, It seems Wine doesn't use any way to reliably detect video memory size, and for many video cards needs it to be specified as HKCU\Software\Wine\Direct3D\VideoMemorySize key in registry. But there exist at least three (vendor-specific) GL/GLX extensions which seem to address exactly this. Namely, for Mesa it's GLX_MESA_query_renderer [1], for nVidia it's GL_NVX_gpu_memory_info [2], and for ATI/AMD it's GL_ATI_meminfo [3]. Mesa extension is shipping starting from Mesa 10.0, nVidia ships their extension in 195.XX drivers (said in specification; I have it exposed with my 313.09 driver), don't know status of ATI extension though (marked as "???" in spec). It'd be good if Wine could utilize these. Is there any work towards this already? Regards, Ruslan [1]: http://www.opengl.org/registry/specs/MESA/glx_query_renderer.txt [2]: https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt [3]: http://www.opengl.org/registry/specs/ATI/meminfo.txt

May 30, 2014

vs2013 support

by Daniel Lehman

Is anyone already working on VS2013 support (msvcp120.dll)? or have plans to? Thanks daniel

May 29, 2014

Re: wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)

by Andrei Slăvoiu

În ziua de Joi 29 Mai 2014, la 10:56:57, Stefan Dösinger a scris: > Am 2014-05-29 01:33, schrieb Andrei Slăvoiu: > > Drop the check for glsl_version. All wine shaders use #version 120 > > so it doesn't matter. > > GL_ARB_shader_texture_lod doesn't imply shader model 4 support. My > Radeon X1600 supports this extension on OSX, and this is a shader > model 3 card. The X1600 doesn't support EXT_gpu_shader4 or GLSL 130. After reading the message again I think I finally understood what you meant. I'll send a try 4 that adds back glsl_version check (try 2 was missing a brace). Do you think returning 93 (meaning d3d level 9_3 or d3d 9 with SM 3) would be too ugly? So wine can choose X1300 as card if ARB_shader_texture_lod is exposed but not GLSL 1.30.

May 29, 2014

Re: wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)

by Andrei Slăvoiu

În ziua de Joi 29 Mai 2014, la 10:56:57, ați scris: > Am 2014-05-29 01:33, schrieb Andrei Slăvoiu: > > Drop the check for glsl_version. All wine shaders use #version 120 > > so it doesn't matter. > > The point of this code is to check the capabilities of the card, not > the capabilities of our d3d implementation. Thus to prevent SM 3 cards > from being reported with PCI IDs that suggest SM 4 capabilities you > need to check for all the other functionality that's supported by > EXT_gpu_shader4 / GLSL 130. > > Even if we have a SM 4 capable card our d3d9 implementation does not > expose SM 4 support. But neither does Microsoft's d3d9 implementation. Correct me if I'm wrong, but the code that decides what shader model d3d9 exposes is shader_glsl_get_caps which looks like this: if (gl_info->supported[EXT_GPU_SHADER4] && gl_info- >supported[ARB_SHADER_BIT_ENCODING] && gl_info->supported[ARB_GEOMETRY_SHADER4] && gl_info- >glsl_version >= MAKEDWORD_VERSION(1, 50) && gl_info->supported[ARB_DRAW_ELEMENTS_BASE_VERTEX] && gl_info- >supported[ARB_DRAW_INSTANCED]) shader_model = 4; /* ARB_shader_texture_lod or EXT_gpu_shader4 is required for the SM3 * texldd and texldl instructions. */ else if (gl_info->supported[ARB_SHADER_TEXTURE_LOD] || gl_info- >supported[EXT_GPU_SHADER4]) shader_model = 3; else shader_model = 2; So wine's d3d9 will expose SM 3 with just glsl 1.20 and GL_ARB_shader_texture_lod. Or am I missing something? > There's also GLX_MESA_query_renderer. It gives us the PCI IDs and > video memory size directly, without all the string parsing guesswork. > We cannot use it wined3d directly. A possible approach would be to > expose a similar WGL_WINE/MESA_query_renderer extension from > winex11.drv and winemac.drv and use that in wined3d. The current > wined3d guesswork code could be moved to winex11.drv and used in cases > where GLX_MESA_query_renderer is not supported. (OSX has similar > functionality that's always available) I was wondering what it would take to get rid of all this guessing and get the PCI ID directly, thanks for the pointers. I'll look into it after I get a better understanding of the existing code. > User32 also has a function (EnumDisplayDevices) to query the GPU > identification string, and some applications (Company of Heroes demo) > fail if the user32 GPU name differs from the d3d9 GPU name. So maybe a > WGL extension isn't quite the right interface, and it should be > something that does not require a GL context so user32.dll can use it > as well. EnumDisplayDevices does not export all the information > wined3d needs though - the PCI IDs and video memory size are missing I > think. So use the string provided by EnumDisplayDevices and the PCI ID and memory size from the WGL extension?

May 29, 2014

Re: wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-29 01:33, schrieb Andrei Slăvoiu: > Drop the check for glsl_version. All wine shaders use #version 120 > so it doesn't matter. That's not quite right. Yes, it is true that we never use GLSL 130, so the version check isn't representative for what wined3d actually supports. For shader model 4 support we need much more than just GLSL 130, half of the d3d10 infrastructure is still missing. GL_ARB_shader_texture_lod doesn't imply shader model 4 support. My Radeon X1600 supports this extension on OSX, and this is a shader model 3 card. The X1600 doesn't support EXT_gpu_shader4 or GLSL 130. The point of this code is to check the capabilities of the card, not the capabilities of our d3d implementation. Thus to prevent SM 3 cards from being reported with PCI IDs that suggest SM 4 capabilities you need to check for all the other functionality that's supported by EXT_gpu_shader4 / GLSL 130. Even if we have a SM 4 capable card our d3d9 implementation does not expose SM 4 support. But neither does Microsoft's d3d9 implementation. There's also GLX_MESA_query_renderer. It gives us the PCI IDs and video memory size directly, without all the string parsing guesswork. We cannot use it wined3d directly. A possible approach would be to expose a similar WGL_WINE/MESA_query_renderer extension from winex11.drv and winemac.drv and use that in wined3d. The current wined3d guesswork code could be moved to winex11.drv and used in cases where GLX_MESA_query_renderer is not supported. (OSX has similar functionality that's always available) User32 also has a function (EnumDisplayDevices) to query the GPU identification string, and some applications (Company of Heroes demo) fail if the user32 GPU name differs from the d3d9 GPU name. So maybe a WGL extension isn't quite the right interface, and it should be something that does not require a GL context so user32.dll can use it as well. EnumDisplayDevices does not export all the information wined3d needs though - the PCI IDs and video memory size are missing I think. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThvZZAAoJEN0/YqbEcdMwsY8QAJG1NQVMSqjwaguVR0cwwNXq IMYCRWL+5cJPxK4Eodt4bF+zZDObqCz9r3hAJVlkA6bJIcflNHJwedT0ddeOAfpe 0Xc8g+NvspN715yNt51PpzcnlSqh2vS18qp1JLb4l00pZuPt8PMNqC0gaePkv+tY 1wY3B/kgbl0TfcIRpxWbwZBcIAM2h4g+FGCHFPFeznhMYWqFaJ67OKW1KAdfpBTT lPZsaNDXtU8hSaVQYVk7ITulUl0C8tW/MExnh4zclz6b/wQuG+/M0WRg5v/YDlNq 0ZAsVqT60+MbepR87ehYDnLB7RMjZMjZhEZ4/drafFbOQBmqL7YJjgbFsbBBXLTt COf/1mjiz7TptUvSUyDRc27o1K+YP1UoswsVdXT37sWkP9gtHtQFeLLNx8ZuR4pa 2yQ7xNIBi7KPNBjz9Q0RKYvc11oGVUvFSuD0gLgNuHZxdOmBWwZyHeSce9adHHGU 5t4Oz0FsTZuEiiuJXPTDatp06KQQpUZ/c7FgcO7bxIpn/NNUCZGKZdKT/ZYM1waf BEtBL2Ov+DzRnvRM3/lVPdaiMD1IY54bqTeU7NOiKCEFhBl0elCAblj155tVaKdR 5WekiCEsvB8S4FE6stDa+GewpBWUZiVLGSL49S0MViPqAbkbgcjcNlRVg6IEH2Zo tyQIl6/9DwdY1TCllA9W =Z1W8 -----END PGP SIGNATURE-----

May 29, 2014

Re: [2/2] ws2_32: Properly implement SO_CONNECT_TIME (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7316 Your paranoid android. === wvistau64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === w2008s64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000

May 29, 2014

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Andrei Slăvoiu

În ziua de Mar 27 Mai 2014, la 21:13:44, Stefan Dösinger a scris: > Am 2014-05-27 17:35, schrieb Stefan Dösinger: > > Am 2014-05-27 16:56, schrieb Andrei Slavoiu:> Yes, > > > >> GL_ARB_shader_texture_lod is exposed by mesa for all drivers in > >> both core and compatibility contexts. So should I check for > >> GL_ARB_shader_texture_lod instead of glsl version? > > > > No, I'd say use something like if (EXT_gpu_shader4 || ( > > ARB_shader_texture_lod && glsl_version >= 1.30). > > An even nicer solution would be to use the capabilities reported by > the shader backend. See select_shader_backend() and and > shader_backend->shader_get_caps. Unsupported vertex shaders would > match a dx 7 card, VS 1.x dx 8, VS 2/3 dx9 and 4 dx10. For separating > dx6 and and 7 the fixed function fragment pipeline info is needed > (number of supported texture units). > > Note that we currently do not support pixel shaders on dx8 cards, and > probably never will. That's because those cards use separate GL > extensions (ATI_fragment_shader and GL_NV_register_combiners + > GL_NV_texture_shader). Thus it's better to look only at vertex shaders > for now to prevent dx8 cards from being reported as dx7. Actually, d3d_level_from_gl_info is misleading (broken even), as it will check for SM3 capability and then return that the card is capable of directx 10 (which requires SM4). I'll look into a better way to report the capabilities to the callers (maybe use d3d feature levels?) and also for a way to share the code that identifies the capabilities with shader_glsl_get_caps. But that in a future patch, after the second version of this one gets submitted.

May 28, 2014

Re: [2/2] ws2_32: Properly implement SO_CONNECT_TIME

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7301 Your paranoid android. === w2000pro (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === wvistau64 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w2008s64 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w7u (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w8 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === wvistau64 (64 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w2008s64 (64 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0

May 28, 2014

Re: Fix for PlgBlt, the XFORM matrix was calculated incorrectly

by Alexander Almaleh

Ok. Btw, I have some other things on my head now, so it might be a week or two before I come back to this. On Fri, May 23, 2014 at 1:35 AM, Michael Mc Donnell <michael(a)mcdonnell.dk>wrote: > Hi Alexander > > On Thu, May 22, 2014 at 2:25 AM, Alexander Almaleh <sashoalm(a)gmail.com>wrote: >> >> OK, I'll try to write a unit test. I found this tutorial - >> https://www.winehq.org/docs/winedev-guide/testing, is it the correct >> thing to read? >> > > Yes that is the correct thing to read. > > >> You might be able to get your patch in without the automated test, but >>> I think you need to explain clearly what was wrong with the old code and >>> what you are doing instead. A few more simplified examples that test other >>> cases in your bug report might also help. >>> >> >> The trouble is I don't quite remember the exact steps I took 5 years ago >> to come up with the new formula. However, I do remember I came up to it by >> solving a system of linear equations. Since XFORM matrix is applied to each >> point, I took 3-4 measurements of how points are transformed by PlgBlt, and >> then used that to make equations of the type applyXFORM(xSrc) = xDest. By >> solving the equations for the XFORM matrix, I came up with the correct >> formula I need to get the XFORM matrix from the input variables. I used an >> online linear equation solver, so there's no human error. >> >> I'll try to recreate the steps, maybe it'll be easier to just explain >> them. I'll look into making automated tests, too. >> > > Sounds good. Like you are saying, figuring out the formulas again would be > a good idea. The current code does not explain where the formulas are > coming from. Adding that as comments in your patch would make it easier to > verify than the current code. > > Michael > >

May 27, 2014

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-27 17:35, schrieb Stefan Dösinger: > Am 2014-05-27 16:56, schrieb Andrei Slavoiu:> Yes, >> GL_ARB_shader_texture_lod is exposed by mesa for all drivers in >> both core and compatibility contexts. So should I check for >> GL_ARB_shader_texture_lod instead of glsl version? > No, I'd say use something like if (EXT_gpu_shader4 || ( > ARB_shader_texture_lod && glsl_version >= 1.30). An even nicer solution would be to use the capabilities reported by the shader backend. See select_shader_backend() and and shader_backend->shader_get_caps. Unsupported vertex shaders would match a dx 7 card, VS 1.x dx 8, VS 2/3 dx9 and 4 dx10. For separating dx6 and and 7 the fixed function fragment pipeline info is needed (number of supported texture units). Note that we currently do not support pixel shaders on dx8 cards, and probably never will. That's because those cards use separate GL extensions (ATI_fragment_shader and GL_NV_register_combiners + GL_NV_texture_shader). Thus it's better to look only at vertex shaders for now to prevent dx8 cards from being reported as dx7. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThOPoAAoJEN0/YqbEcdMwvvcP/jVwAxed6lqHNdMy9qrfwJ25 sfK2Npf0tiuvdWT5t/pGMhiAF/abWoS9w5qhD8OMEXo4TpYOS4IkLxWSJcJ/adAD w0cyduvRu0nONy5apHPaR4py6EIYrZB2n4WZmoj/QHJJjWzFSKGeQweuohcr8NvJ ddc/di9hjyquGuiTUNRU+hHiW3HPYVe4CJNZEH3jXyG6q0e6GgztxS6p10x2RcZY SlSKnOcSgEZAQvFPlZ50QWz6oElKFGzrkODcQZhuh8OHxfOntqzJyXg8PB5Ft2L0 6cHtVE5eTuXT6thcOds1759aQ1qLO7zOC59wP3N72Wp5L8TU/rN+Gg4ooHnV2ctw gkBZ0SkgsK7tR2aQ+gc9zU4CUEcX4HRuO3vMgSElUGl4Df6yuSKLteVy/eyKXlrX pHDcOdO899978tk+NibwQZOHyKo8l5jpzdVpkiOkd72lk3xLicIGlN3zKHZL0Cfw Esq3bI60boPbOVdYP+yI6X8a/UoBtpIvWxe5dfFQJqzm+gOnkvcEY5QEEx8P9IPd 895BrPcUOIxMCpPlZ26Op7eIGgtKPpRi2TJ7BwYgwWAdgeBNuQnlUcdkCn9FFvSQ jYvKze39X+q5vYxSAlKVAszhMOOXQM/NC9Vol1WfiL1T6+CFWhrR+cPd0x0So6uD 9u1plWqMoP7rf2QtxAPR =fZmC -----END PGP SIGNATURE-----

May 27, 2014

Re: About wineserver and winsock

by Erich E. Hoover

On Mon, May 26, 2014 at 3:23 PM, Chris Robinson <chris.kcat(a)gmail.com> wrote: > On 05/26/2014 09:31 AM, Damjan Jovanovic wrote: >> >> That wouldn't always work: in theory, DuplicateHandle() could transmit >> the socket to another process, which wouldn't have the same ws2_32 >> thread. > > > I don't know much about winsock and wineserver and such, but would it be > possible for a handle to track whether it's been duplicated from/to another > process and only involve wineserver when it has been? You actually need to use WSADuplicateSocket[A|W] on sockets, so it's conceivable that we could keep a record of which handles have been duplicated for other processes. Best, Erich

May 27, 2014

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-27 16:56, schrieb Andrei Slavoiu:> Yes, > GL_ARB_shader_texture_lod is exposed by mesa for all drivers in > both core and compatibility contexts. So should I check for > GL_ARB_shader_texture_lod instead of glsl version? No, I'd say use something like if (EXT_gpu_shader4 || ( ARB_shader_texture_lod && glsl_version >= 1.30). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThLDBAAoJEN0/YqbEcdMwkD4P/jSQ8W3qJ36kMNmuJ8XbA8nx zM3DH4KMOIY3Zgt1Mf/j8ycP/zhqy+GPkXDnWctaCAkrvrqeRoItMEbeIcgMI+yH vGBJLIBMuF7NyQ9K4jIxpdHnO81YOkklZPbLV62Fxv5zgrQCrIidm4kY/1EnvOr3 pXUbT1E596fxnZTvxD1/Y5MASrTrmfE5sDlsI49k0xzXQRBbc+gosJHVryUWSf3x 4vv29NiYW0CL0MVhbd0GUoY9HlMZnzeshhWO4689BFKYYTCi3BSBilfcr9qiAsx0 ud7EjehnD11NUnQmb1ail/XZRT+FpUEqSWkYO/GYw4wqthJcrnPVXa+AiSajEAjC b4ODtZUegjTZJ+bEEwEAW797tpo3KA9JIAl/c+zktE23PK3APSgmm3hD0Pr7PSNk rd9kKplvsXvvk/eqii6uJ8lx0ZnuoDkRgDkSbTzdy7eEfOGJTQ+1Mr78rPT2Lgpw AVzIUtqfbcT1fBOib0Cl6D38mI56hNb9oCMt4P2T8JxJXhnAAFK53e8SdVymE7zx 1vj4sEouFs0xw2CChhAPIkiWH4iFuSZWVGnudEy94cp/1iGO9m+zQk2unsqrzENs VmpAEvLcA63gtzchqZmyMibWbj+OhuM6NkicCObGuddZ1PXRkbbSV5hADSM8ZHnb b0Adkmlm5rdNfTS5p6Ys =ehtk -----END PGP SIGNATURE-----

May 27, 2014

Re: Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Andrei Slavoiu

On Tuesday 27 May 2014 15:56:57 Stefan DÃ¶singer wrote: > Am 23.05.2014 um 00:23 schrieb Andrei SlÄvoiu <andrei.slavoiu(a)gmail.com>: > > Mesa drivers do not expose EXT_GPU_SHADER4 as all functionality it offers > > is already part of OpenGL 3.0. This causes all cards that are not > > explicitly recognized by wine (for example all GCN cards) to be treated > > as DX9 cards and presented to Windows apps as Radeon 9500. > > The problem is that without GL_EXT_gpu_shader4 or GL_ARB_shader_texture_lod > we cannot handle the texldd instruction. Right now we cannot use core > contexts, so unless the driver exposes one of those extensions in > compatibility contexts we are stuck on a shader model 2 feature level :-( . > > The level detection your patch changes isn't directly related to this, as > the shader model version support is controlled differently. But a Radeon > 9500 matches a card with shader model 2 support much better than a Radeon > R9. > > Does this driver / gpu combination support GL_ARB_shader_texture_lod? Yes, GL_ARB_shader_texture_lod is exposed by mesa for all drivers in both core and compatibility contexts. So should I check for GL_ARB_shader_texture_lod instead of glsl version?

May 27, 2014

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Stefan Dösinger

Am 23.05.2014 um 00:23 schrieb Andrei Slăvoiu <andrei.slavoiu(a)gmail.com>: > Mesa drivers do not expose EXT_GPU_SHADER4 as all functionality it offers is > already part of OpenGL 3.0. This causes all cards that are not explicitly > recognized by wine (for example all GCN cards) to be treated as DX9 cards and > presented to Windows apps as Radeon 9500. The problem is that without GL_EXT_gpu_shader4 or GL_ARB_shader_texture_lod we cannot handle the texldd instruction. Right now we cannot use core contexts, so unless the driver exposes one of those extensions in compatibility contexts we are stuck on a shader model 2 feature level :-( . The level detection your patch changes isn't directly related to this, as the shader model version support is controlled differently. But a Radeon 9500 matches a card with shader model 2 support much better than a Radeon R9. Does this driver / gpu combination support GL_ARB_shader_texture_lod?

May 27, 2014

Re: [PATCH 2/2] propsys: Forward exported calls to corresponding methods

by Jacek Caban

Hi Nikolay, On 05/27/14 11:09, Nikolay Sivov wrote: > From 386a536f9ae75505cd95601e4a8ca936b826658c Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <nsivov(a)codeweavers.com> > Date: Mon, 26 May 2014 22:38:35 +0400 > Subject: [PATCH 2/2] propsys: Forward exported calls to corresponding methods It seems to me that forwarding the other way be more logical. Jacek

May 27, 2014

Re: [PATCH 2/2] shell32: Improve checking for folder index validity in NameSpace()

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7279 Your paranoid android. === w2000pro (32 bit shelldispatch) === shelldispatch.c:94: Test failed: got 00000001 shelldispatch: unhandled exception c0000005 at 0040EB1D

May 27, 2014

Re: About wineserver and winsock

by jordan

> We could speed up calls to the wineserver, which involve at least 4 > system calls, 2 context switches, and 4 memory copies (in and out of > the UNIX socket's buffers), by porting the wineserver to be a kernel > module on the underlying *nix kernel, so that it only needs a single > system call, zero context switches, and zero memory copies. I know > Transgaming was considering this years ago - don't know how far they > got - but I imagine it to be extremely difficult. Maybe it's possible > to port only a small part of it that deals with performance critical > areas, like sockets and synchronization, while the rest stays running > as a user space application? This conversation reminds me of this blog; http://www.linuxtoday.com/developer/2010060303135OSKNDV ...from a few years ago, comparing 'longene' or Linux Unified kernel vs Wine. The project doesn't appear to be active, but there is some source code here; https://sourceforge.net/projects/longene/files/longene/longene-0.3.2/source/ ... I've never used it, but did take a look at one point. [back when]. cheerz Jordan > Damjan > > On Mon, May 26, 2014 at 5:10 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: >> Hi all, after studying the ws2_32 dll code for some time while looking >> for ways to optimize it I started wondering why is the wineserver >> required (please don't stop reading yet). >> >> make test takes 45 seconds in my machine while it takes 25 seconds in >> a XP VM running on the same machine. The culprit is test_send() [1] >> which takes 24 seconds in wine and 1.8 seconds in windows. >> >> This long time is related to the 1 million recv() calls in >> test_send(). Each call to recv() has to call wineserver to do a >> enable_event(FD_READ) operation, if you comment that line out [2] wine >> magically takes 1.7 seconds, just like windows does (obviously >> commenting that line generaters other errors related to event >> sequences). >> >> So, in simple words: what if we move all wineserver socket code to a >> thread that is started in the ws2_32 DLL. I know this may sound very >> silly for the experienced wine developers, maybe some operations are >> impossible without the wineserver, maybe there is much more things >> affected, but I think it's better to ask and get crushed with >> (hopefully) constructive criticism than forget about the idea. >> >> My main objective with this is to speedup the whole implementation and >> properly implement the select call (different socket states result in >> different checks required) and WSACleanup call (which needs to close >> every open socket on last cleanup) and some other get/setsockopt >> stuff. >> >> [1] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ws2_32/tests/sock.c#l… >> [2] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ws2_32/socket.c#l6684 >> >> Best wishes, >> Bruno >> >> > >

May 27, 2014

Re: [PATCH] vbscript: Implemented CDbl(try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7277 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

May 27, 2014

Re: About wineserver and winsock

by Chris Robinson

On 05/26/2014 09:31 AM, Damjan Jovanovic wrote: > That wouldn't always work: in theory, DuplicateHandle() could transmit > the socket to another process, which wouldn't have the same ws2_32 > thread. I don't know much about winsock and wineserver and such, but would it be possible for a handle to track whether it's been duplicated from/to another process and only involve wineserver when it has been?

May 26, 2014

Re: About wineserver and winsock

by Damjan Jovanovic

That wouldn't always work: in theory, DuplicateHandle() could transmit the socket to another process, which wouldn't have the same ws2_32 thread. We could speed up calls to the wineserver, which involve at least 4 system calls, 2 context switches, and 4 memory copies (in and out of the UNIX socket's buffers), by porting the wineserver to be a kernel module on the underlying *nix kernel, so that it only needs a single system call, zero context switches, and zero memory copies. I know Transgaming was considering this years ago - don't know how far they got - but I imagine it to be extremely difficult. Maybe it's possible to port only a small part of it that deals with performance critical areas, like sockets and synchronization, while the rest stays running as a user space application? Damjan On Mon, May 26, 2014 at 5:10 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Hi all, after studying the ws2_32 dll code for some time while looking > for ways to optimize it I started wondering why is the wineserver > required (please don't stop reading yet). > > make test takes 45 seconds in my machine while it takes 25 seconds in > a XP VM running on the same machine. The culprit is test_send() [1] > which takes 24 seconds in wine and 1.8 seconds in windows. > > This long time is related to the 1 million recv() calls in > test_send(). Each call to recv() has to call wineserver to do a > enable_event(FD_READ) operation, if you comment that line out [2] wine > magically takes 1.7 seconds, just like windows does (obviously > commenting that line generaters other errors related to event > sequences). > > So, in simple words: what if we move all wineserver socket code to a > thread that is started in the ws2_32 DLL. I know this may sound very > silly for the experienced wine developers, maybe some operations are > impossible without the wineserver, maybe there is much more things > affected, but I think it's better to ask and get crushed with > (hopefully) constructive criticism than forget about the idea. > > My main objective with this is to speedup the whole implementation and > properly implement the select call (different socket states result in > different checks required) and WSACleanup call (which needs to close > every open socket on last cleanup) and some other get/setsockopt > stuff. > > [1] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ws2_32/tests/sock.c#l… > [2] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ws2_32/socket.c#l6684 > > Best wishes, > Bruno > >

May 26, 2014

About wineserver and winsock

by Bruno Jesus

Hi all, after studying the ws2_32 dll code for some time while looking for ways to optimize it I started wondering why is the wineserver required (please don't stop reading yet). make test takes 45 seconds in my machine while it takes 25 seconds in a XP VM running on the same machine. The culprit is test_send() [1] which takes 24 seconds in wine and 1.8 seconds in windows. This long time is related to the 1 million recv() calls in test_send(). Each call to recv() has to call wineserver to do a enable_event(FD_READ) operation, if you comment that line out [2] wine magically takes 1.7 seconds, just like windows does (obviously commenting that line generaters other errors related to event sequences). So, in simple words: what if we move all wineserver socket code to a thread that is started in the ws2_32 DLL. I know this may sound very silly for the experienced wine developers, maybe some operations are impossible without the wineserver, maybe there is much more things affected, but I think it's better to ask and get crushed with (hopefully) constructive criticism than forget about the idea. My main objective with this is to speedup the whole implementation and properly implement the select call (different socket states result in different checks required) and WSACleanup call (which needs to close every open socket on last cleanup) and some other get/setsockopt stuff. [1] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ws2_32/tests/sock.c#l… [2] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ws2_32/socket.c#l6684 Best wishes, Bruno

May 26, 2014

New Wine patches

by Chakke, Neha (GE Oil & Gas)

Hello , I am trying to run a GE software and hardware on Debian (Linux platform) using WineHQ. In order to run the hardware we need to install device drivers for USB (Cypress) . http://wiki.winehq.org/USB I have been trying to look for some solutions online since a week. Could you kindly send me the new wine patches and please guide me with the procedure. Thanks and regards, Miss Neha Chakke Engineering/Technology GE Oil & Gas Measurement & Control T: +49 (0) 2233 601 123 neha.chakke(a)ge.com<mailto:neha.chakke(a)ge.com> www.ge-mcs.com<http://www.ge-mcs.com/> [NewMeatball] GE Sensing & Inspection Technologies GmbH Robert-Bosch-Str. 3 50354 Hürth Germany

May 26, 2014

Re: mshtml: Added IHTMLTableRow::insertCell method implementation. (try 3)

by Jacek Caban

Hi Zhenbo, This version looks good except: On 05/24/14 11:56, Zhenbo Li wrote: > + *row = (IDispatch *)&elem->IHTMLElement_iface; > + IDispatch_AddRef(*row); > + IHTMLElement_Release(&elem->IHTMLElement_iface); You don't need to add such AddRef()/Release() calls. Reference count doesn't change anyway. Cheers, Jacek

May 26, 2014

Re: Japanese translation updates (try 4) for 1.7.19.

by Toshiaki Hirose

Thank you. Sent from AOL Mobile Mail -----Original Message----- From: Akihiro Sagawa <sagawa.aki(a)gmail.com> To: wine-devel <wine-devel(a)winehq.org> Cc: t_hirose <t_hirose(a)aol.com> Sent: Thu, May 22, 2014 11:53 PM Subject: Re: Japanese translation updates (try 4) for 1.7.19. On Wed, 21 May 2014 12:09:30 -0400 (EDT), Toshiaki Hirose wrote: > From 16832fa3d12785db591144f2005f953dd8937b9f Mon Sep 17 00:00:00 2001 > Message-Id: <16832fa3d12785db591144f2005f953dd8937b9f.1400688520.git.t_hirose(a)aol.com> > From: Toshiaki Hirose <t_hirose(a)aol.com> > Date: Thu, 22 May 2014 01:08:29 +0900 > Subject: [PATCH] Japanese translation updates(try4) for 1.7.19 > > --- > po/ja.po | 159 ++++++++++++++++++++++++++------------------------------------- > 1 file changed, 65 insertions(+), 94 deletions(-) Looks good to me. Akihiro Sagawa

May 25, 2014

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory. (try 2)

by Zhenbo Li

Excuse me, could someone have a look with this patch? Thank you. 2014-05-21 9:23 GMT+08:00 Zhenbo Li <litimetal(a)gmail.com>: > Thanks Alexandre > > try 2: > 1. Let SHELL_DeleteDirectoryW return DWORD > 2. Get the right return value by > ret = SHNotifyRemoveDirectoryW(pszDir) > origin: > Thanks Bruno Jesus > This patch would fix bug 34324, by returning correct > error value of SHFileOperation. > > --- > dlls/shell32/shlfileop.c | 55 > +++++++++++++++++++++--------------------- > dlls/shell32/tests/shlfileop.c | 4 --- > 2 files changed, 27 insertions(+), 32 deletions(-) > > -- Have a nice day! Zhenbo Li

May 24, 2014

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 4)

by Stefan Dösinger

Am 21.05.2014 um 08:23 schrieb Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > Moved to be client.c. > Flags are printed as 0x%08x. You may want to move the test to tests/client.c as well. Otherwise this looks good to me.

May 23, 2014

Re: mshtml: Added IHTMLTableRow::insertCell method implementation. (try 2)

by Jacek Caban

Hi Zhenbo, On 05/23/14 14:20, Zhenbo Li wrote: > iff --git a/dlls/mshtml/htmltablerow.c b/dlls/mshtml/htmltablerow.c > index 731b403..f1b672b 100644 > --- a/dlls/mshtml/htmltablerow.c > +++ b/dlls/mshtml/htmltablerow.c > @@ -308,8 +308,27 @@ static HRESULT WINAPI HTMLTableRow_get_cells(IHTMLTableRow *iface, IHTMLElementC > static HRESULT WINAPI HTMLTableRow_insertCell(IHTMLTableRow *iface, LONG index, IDispatch **row) > { > HTMLTableRow *This = impl_from_IHTMLTableRow(iface); > - FIXME("(%p)->(%d %p)\n", This, index, row); > - return E_NOTIMPL; > + nsIDOMHTMLElement *nselem; > + HTMLElement *elem = NULL; You shouldn't need to initialize it here. > + nsresult nsres; > + HRESULT hres; > + > + TRACE("(%p)->(%d %p)\n", This, index, row); > + nsres = nsIDOMHTMLTableRowElement_InsertCell(This->nsrow, index, &nselem); > + if(NS_FAILED(nsres)) { > + ERR("Insert Cell at %d failed: %08x\n", index, nsres); > + return E_FAIL; > + } > + > + hres = HTMLTableCell_Create(This->element.node.doc, nselem, &elem); > + if (FAILED(hres)) { > + ERR("Create TableCell failed: %08x\n", hres); > + return hres; > + } > + nsIDOMHTMLElement_Release(nselem); There it a leak in error case. Move Release call before if statement. > + > + hres = IHTMLElement_QueryInterface(&elem->IHTMLElement_iface, &IID_IDispatch, (void **)row); > + return hres; You don't need QueryInterface here. Cast is fine as long as it's done on an interface inheriting from IDispatch (but not on object, as you did in previous version of the patch). Cheers, Jacek

May 23, 2014

Re: (try 2) gdi32/tests: tmLastChar is solely governed by the last entry before 0xffff in the cmap.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7224 Your paranoid android. === w2000pro (32 bit font) === font.c:5077: Test failed: got 00a8 === wxppro (32 bit font) === font.c:5077: Test failed: got 00a8 === wvistau64 (32 bit font) === The test timed out === w2008s64 (32 bit font) === font.c:5077: Test failed: got 00a8 === w7u (32 bit font) === font.c:5077: Test failed: got 00a8 === w8 (32 bit font) === font.c:5077: Test failed: got 00a8 === wvistau64 (64 bit font) === font.c:5077: Test failed: got 00a8 === w2008s64 (64 bit font) === font.c:5077: Test failed: got 00a8

May 23, 2014

Re: [PATCH 3/3] vbscript: Fixed CInt

by Piotr Caban

On 5/23/14 6:36 AM, Nikolay Sivov wrote: > >> - hres = to_int(arg, &val); >> + V_VT(&v) = VT_EMPTY; >> + hres = VariantChangeType(&v, arg, 0, VT_I2); >> if(FAILED(hres)) >> return hres; >> - return return_int(res, val); >> + if(!res) { >> + VariantClear(&v); >> + return DISP_E_BADVARTYPE; >> + } >> + >> + *res = v; >> + return S_OK; > I can't comment on removing to_int() here, I don't know this code > well. But is it really possible to get a NULL 'res'? It looks like you > can just use 'res' without intermediate 'v'. In any case you don't > need VariantClear() on VT_I2 variant. VariantChangeType is handling more variant types then to_int. There are tests that show that e.g. VT_DISPATCH and VT_BSTR needs to be handled. It's possible that res is NULL, there are tests for it (it happens when result of CInt is not used, e.g. Call CInt(0)). He can't use 'res' without intermediate 'v'. It's needed to return the same error code as native does. There are also tests for it. I don't have strong opinion about calling VariantClear but I think it's good to call it.

May 23, 2014

Re: [PATCH 3/3] vbscript: Fixed CInt

by Nikolay Sivov

> - hres = to_int(arg, &val); > + V_VT(&v) = VT_EMPTY; > + hres = VariantChangeType(&v, arg, 0, VT_I2); > if(FAILED(hres)) > return hres; > > - return return_int(res, val); > + if(!res) { > + VariantClear(&v); > + return DISP_E_BADVARTYPE; > + } > + > + *res = v; > + return S_OK; I can't comment on removing to_int() here, I don't know this code well. But is it really possible to get a NULL 'res'? It looks like you can just use 'res' without intermediate 'v'. In any case you don't need VariantClear() on VT_I2 variant.

May 23, 2014

Re: [PATCH 3/3] vbscript: Fixed CInt

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7223 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

May 23, 2014

Re: [PATCH 2/3] vbscript: Implemented CLng

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7222 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

May 23, 2014

Re: [PATCH 1/3] vbscript: Implemented CDbl

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7221 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

May 23, 2014

Re: Fix for PlgBlt, the XFORM matrix was calculated incorrectly

by Michael Mc Donnell

Hi Alexander On Thu, May 22, 2014 at 2:25 AM, Alexander Almaleh <sashoalm(a)gmail.com>wrote: > > OK, I'll try to write a unit test. I found this tutorial - > https://www.winehq.org/docs/winedev-guide/testing, is it the correct > thing to read? > Yes that is the correct thing to read. > You might be able to get your patch in without the automated test, but I >> think you need to explain clearly what was wrong with the old code and what >> you are doing instead. A few more simplified examples that test other cases >> in your bug report might also help. >> > > The trouble is I don't quite remember the exact steps I took 5 years ago > to come up with the new formula. However, I do remember I came up to it by > solving a system of linear equations. Since XFORM matrix is applied to each > point, I took 3-4 measurements of how points are transformed by PlgBlt, and > then used that to make equations of the type applyXFORM(xSrc) = xDest. By > solving the equations for the XFORM matrix, I came up with the correct > formula I need to get the XFORM matrix from the input variables. I used an > online linear equation solver, so there's no human error. > > I'll try to recreate the steps, maybe it'll be easier to just explain > them. I'll look into making automated tests, too. > Sounds good. Like you are saying, figuring out the formulas again would be a good idea. The current code does not explain where the formulas are coming from. Adding that as comments in your patch would make it easier to verify than the current code. Michael

May 22, 2014

Re: Japanese translation updates (try 4) for 1.7.19.

by Akihiro Sagawa

On Wed, 21 May 2014 12:09:30 -0400 (EDT), Toshiaki Hirose wrote: > From 16832fa3d12785db591144f2005f953dd8937b9f Mon Sep 17 00:00:00 2001 > Message-Id: <16832fa3d12785db591144f2005f953dd8937b9f.1400688520.git.t_hirose(a)aol.com> > From: Toshiaki Hirose <t_hirose(a)aol.com> > Date: Thu, 22 May 2014 01:08:29 +0900 > Subject: [PATCH] Japanese translation updates(try4) for 1.7.19 > > --- > po/ja.po | 159 ++++++++++++++++++++++++++------------------------------------- > 1 file changed, 65 insertions(+), 94 deletions(-) Looks good to me. Akihiro Sagawa

May 22, 2014

Re: Fix for PlgBlt, the XFORM matrix was calculated incorrectly

by Alexander Almaleh

Hi, Michael On Thu, May 22, 2014 at 4:56 AM, Michael Mc Donnell <michael(a)mcdonnell.dk>wrote: > The easiest way to get your patches accepted, in my experience, is to > write an automated test. That way it is easier for everyone to verify that > your patch is doing the right thing. We will be able to run it on the Wine > Testbot and see it working. > OK, I'll try to write a unit test. I found this tutorial - https://www.winehq.org/docs/winedev-guide/testing, is it the correct thing to read? > You might be able to get your patch in without the automated test, but I > think you need to explain clearly what was wrong with the old code and what > you are doing instead. A few more simplified examples that test other cases > in your bug report might also help. > The trouble is I don't quite remember the exact steps I took 5 years ago to come up with the new formula. However, I do remember I came up to it by solving a system of linear equations. Since XFORM matrix is applied to each point, I took 3-4 measurements of how points are transformed by PlgBlt, and then used that to make equations of the type applyXFORM(xSrc) = xDest. By solving the equations for the XFORM matrix, I came up with the correct formula I need to get the XFORM matrix from the input variables. I used an online linear equation solver, so there's no human error. I'll try to recreate the steps, maybe it'll be easier to just explain them. I'll look into making automated tests, too.

May 22, 2014

Re: Fix for PlgBlt, the XFORM matrix was calculated incorrectly

by Michael Mc Donnell

Hi Alexander On Tue, May 20, 2014 at 1:39 PM, Alexander Almaleh <sashoalm(a)gmail.com> wrote: > I had tried to submit a patch for that 5 years ago, but couldn't figure out > how to make a patch/test it, and eventually gave up and forgot about it. But > recently I remembered about it, and now I want to try again. The easiest way to get your patches accepted, in my experience, is to write an automated test. That way it is easier for everyone to verify that your patch is doing the right thing. We will be able to run it on the Wine Testbot and see it working. It might be difficult in your case though. Wine does usually not include big test files so you would probably have to write some code that draws a test image. The test image needs to be easy to verify in code if it has been transformed correctly. You might be able to draw a filled rectangle in one hdc and a filled parallelogram in another. Transform the filled rectangle using PlgBlt and then compare it to the parallelogram. I have not thought it all the way through so it might not work :-) It seems like there are no automated bitblt tests in the wine source tree. The first step would be to add a file bitblt.c in /dlls/gdi32/tests/ and then add it to the Makefile.in file in that directory. My first commit to Wine [1] added a new test file brsfolder.c to shell32. You might be able to get your patch in without the automated test, but I think you need to explain clearly what was wrong with the old code and what you are doing instead. A few more simplified examples that test other cases in your bug report might also help. Best of luck, Michael Mc Donnell [1] http://source.winehq.org/git/wine.git/?a=commit;h=5c715b46f4312a2e76aa14499…

May 22, 2014

Re: Debugging wine with winedbg

by Alexander Almaleh

Hm, I just tried setting a breakpoint at RegOpenKeyExW, and it worked, the list command showed the correct code when the breakpoint was hit. Also, I noticed that it shows the file/line number when I set a breakpoint on RegOpenKeyExW, but not for BitBlt. Why would that be? Wine-dbg>break RegOpenKeyExW Breakpoint 2 at 0x7eb73920 RegOpenKeyExW [/home/sashoalm/Workspace/wine/wine-git/dlls/advapi32/registry.c:461] in advapi32 Wine-dbg>break BitBlt fixme:dbghelp_dwarf:dwarf2_parse_subprogram Unhandled Tag type 0x1 at ctx(0x32bfec,L"gdi32<elf>"), for debug_info(abbrev:0x15f2148,symt:0x175a660) Breakpoint 1 at 0x7ebcac00 BitBlt in gdi32

May 21, 2014

Vacations

by Alexandre Julliard

Folks, I'll be away for the next two weeks, though I may still push some commits if I can get decent Internet. I'm also going to skip next week's release, so 1.7.20 should happen on June 13. -- Alexandre Julliard julliard(a)winehq.org

May 21, 2014

Debugging wine with winedbg

by Alexander Almaleh

I'm trying to debug Wine, and I want to step into the BitBlt function using winedbg. I've set a breakpoint at BitBlt, and it is being hit, however, when I list the source code, it points somewhere completely differently in the source. I have no idea why that is. Does it mean that Wine is not setup correctly for debugging? I cloned Wine from Git a few days ago, and I've used "./tools/wineinstall" to compile and install it. This is an excerpt of the debugging session. sashoalm(a)aspire:~$ winedbg /tmp/xformtest.exe WineDbg starting on pid 0022 start_process () at /home/sashoalm/Workspace/wine/wine-git/dlls/kernel32/process.c:1097 0x7b86235f start_process+0x5f [/home/sashoalm/Workspace/wine/wine-git/dlls/kernel32/process.c:1097] in kernel32: movl %edi,0x4(%esp) 1097 return call_process_entry( peb, entry ); Wine-dbg>break BitBlt fixme:dbghelp_dwarf:dwarf2_parse_subprogram Unhandled Tag type 0x1 at ctx(0x32bfec,L"gdi32<elf>"), for debug_info(abbrev:0x15f2148,symt:0x175a660) Breakpoint 1 at 0x7ebcac00 BitBlt in gdi32 Wine-dbg>cont Stopped on breakpoint 1 at 0x7ebcac00 BitBlt in gdi32 Wine-dbg>list 1097 return call_process_entry( peb, entry ); 1098 } 1099 1100 1101 /*********************************************************************** 1102 * set_process_name 1103 * 1104 * Change the process name in the ps output. 1105 */ 1106 static void set_process_name( int argc, char *argv[] ) 1107 { Wine-dbg>n copy_bitmap () at /home/sashoalm/Workspace/wine/wine-git/dlls/user32/cursoricon.c:382 382 DeleteDC( dst );

May 21, 2014

Re: Fix for PlgBlt, the XFORM matrix was calculated incorrectly

by Alexander Almaleh

Done! Bug submitted at http://bugs.winehq.org/show_bug.cgi?id=36504. On Wed, May 21, 2014 at 4:12 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > On Tue, May 20, 2014 at 1:39 PM, Alexander Almaleh <sashoalm(a)gmail.com> > wrote: > > I had tried to submit a patch for that 5 years ago, but couldn't figure > out > > how to make a patch/test it, and eventually gave up and forgot about it. > But > > recently I remembered about it, and now I want to try again. > > > > So, this time I've prepared a test that can prove that the previous > > implementation does not calculate the XFORM matrix correctly, and that my > > patch will fix it. > > > > The test is a VC6 project, you can find it at > > > https://drive.google.com/file/d/0B9PGUhmmnsm1S2VvZzc3WmhBY3c/edit?usp=shari… > . > > The test is a demo of PlgBlt that I found on CodeProject. You can compare > > how it works on XP and on Wine. For testing, I directly inserted the > > original Wine implementation of PlgBlt, as well as my patched version, > into > > the VC6 project, and tested on that. This is because there seems to be an > > additional problem with MaskBlt, which I'll try tackling next. > > > > I can confirm your code works in XP. I think the first thing to do is > to create a bug to take care of the issue. >

May 21, 2014

Re: [PATCH] add function iphlpapi/CreateSortedAddressPairs, FreeMibTable

by Akira Nakagawa

Thank you. (2014年05月21日 21:07), Bruno Jesus wrote: > This patch is just a hack, I'll send a correct stub later. > > On Wed, May 21, 2014 at 8:10 AM, Akira Nakagawa <matyapiro31(a)gmail.com> wrote: > >

May 21, 2014

Re: [patch]japanese translation updates for 1.7.19.

by Akihiro Sagawa

On Tue, 20 May 2014 13:38:12 -0400 (EDT), Toshiaki Hirose wrote: > po/ja.po | 159 ++++++++++++++++++++++++++------------------------------------- > 1 file changed, 65 insertions(+), 94 deletions(-) Hi, Hirose-san, I just figure out two points. Following msgid line introduces unnecessary changes. > #: oleacc.rc:97 > -#, fuzzy > -#| msgid "Normal" > msgctxt "object state" > -msgid "normal" > -msgstr "標準" > +msgid "normal" > +msgstr "normal" This change might be unintentional because other oleacc resources aren't translated yet. If you adopt this translation, please remove redundant "(&R)". > #: oleacc.rc:104 > -#, fuzzy > -#| msgid "&Read Only" > msgctxt "object state" > msgid "read only" > msgstr "読み取り専用(&R)" Otherwise looks fairly good. Regards, Akihiro Sagawa

May 21, 2014

Re: Fix for PlgBlt, the XFORM matrix was calculated incorrectly

by Bruno Jesus

On Tue, May 20, 2014 at 1:39 PM, Alexander Almaleh <sashoalm(a)gmail.com> wrote: > I had tried to submit a patch for that 5 years ago, but couldn't figure out > how to make a patch/test it, and eventually gave up and forgot about it. But > recently I remembered about it, and now I want to try again. > > So, this time I've prepared a test that can prove that the previous > implementation does not calculate the XFORM matrix correctly, and that my > patch will fix it. > > The test is a VC6 project, you can find it at > https://drive.google.com/file/d/0B9PGUhmmnsm1S2VvZzc3WmhBY3c/edit?usp=shari…. > The test is a demo of PlgBlt that I found on CodeProject. You can compare > how it works on XP and on Wine. For testing, I directly inserted the > original Wine implementation of PlgBlt, as well as my patched version, into > the VC6 project, and tested on that. This is because there seems to be an > additional problem with MaskBlt, which I'll try tackling next. > I can confirm your code works in XP. I think the first thing to do is to create a bug to take care of the issue.

May 21, 2014

Re: [PATCH] add function iphlpapi/CreateSortedAddressPairs, FreeMibTable

by Bruno Jesus

This patch is just a hack, I'll send a correct stub later. On Wed, May 21, 2014 at 8:10 AM, Akira Nakagawa <matyapiro31(a)gmail.com> wrote: > -- universe* god::bigbang (void); //and then it all began...

May 21, 2014

Re: [1/2] ws2_32: Avoid memory allocation for simple sends

by Bruno Jesus

On Wed, May 21, 2014 at 12:34 AM, Austin English <austinenglish(a)gmail.com> wrote: > In (very non-scientific) timing runs, these two patches reduced valgrind > test time by ~20% (5 vs 4 minutes), thanks! Great to hear that, I was hoping it would help bug http://bugs.winehq.org/show_bug.cgi?id=28269 but it didn't =/

May 21, 2014

Re: [PATCH 1/2] riched20: Implement ITextSelection::GetText.

by Jactry Zeng

2014-05-21 16:26 GMT+08:00 Nikolay Sivov <bunglehead(a)gmail.com>: > > But ITextSelection is a ITextRange too, so you need to implement it for ITextRange only. Yes, ITextSelection interface is inherits from ITextRange. But I think functions of ITextRange and functions of ITextSelection are independent of each other. And there are some different between them: range of an ITextRange is given by ITextDocument::Range and immovable but range of ITextSelection of is depend on *pCursor in ME_TextEditor. So I think implementing ITextSelection independently and just share some functions like ME_ITextGetText between ITextRange and ITextSelection is a more convenient way. -- Regards, Jactry Zeng

May 21, 2014

Re: [PATCH 1/2] riched20: Implement ITextSelection::GetText.

by Nikolay Sivov

On 5/21/2014 12:20, Jactry Zeng wrote: > Hi Nikolay, > 2014-05-21 14:56 GMT+08:00 Nikolay Sivov <bunglehead(a)gmail.com > <mailto:bunglehead(a)gmail.com>>: > >> > >> +HRESULT ME_ITextGetText(ME_TextEditor *editor, ME_Cursor *start, > ME_Cursor *end, BSTR *pb) DECLSPEC_HIDDEN; > > > > Is this really needed? > > I would like to share ME_ITextGetText between ITextSelection::GetText > and ITextRange::GetText. But ITextSelection is a ITextRange too, so you need to implement it for ITextRange only. > > Thanks for your review! > -- > Regards, > Jactry Zeng >

May 21, 2014

Re: [PATCH 1/2] riched20: Implement ITextSelection::GetText.

by Jactry Zeng

Hi Nikolay, 2014-05-21 14:56 GMT+08:00 Nikolay Sivov <bunglehead(a)gmail.com>: >> >> +HRESULT ME_ITextGetText(ME_TextEditor *editor, ME_Cursor *start, ME_Cursor *end, BSTR *pb) DECLSPEC_HIDDEN; > > Is this really needed? I would like to share ME_ITextGetText between ITextSelection::GetText and ITextRange::GetText. Thanks for your review! -- Regards, Jactry Zeng

May 21, 2014

BitBlt doesn't honor the rotation specified by SetWorldTransform

by Alexander Almaleh

I have a test program that shows how BitBlt does not support rotation, when the rotation is specified by SetWorldTransform. Interestinly, the Rectangle() function works correctly and the rectangle is rotated. Here's a screenshot of the program in VirtualBox and in Wine<http://imgur.com/TIYx7XU> . Here is the code of the program. I'm setting a rotation XFORM, and then calling BitBlt. I load a bitmap file from the current directory for the BitBlt. hdc = BeginPaint(hWnd, &ps); double angle = 0.385398163; XFORM xf; xf.eDx = 0; xf.eDy = 0; xf.eM11 = cos(angle); xf.eM12 = sin(angle); xf.eM21 = -sin(angle); xf.eM22 = cos(angle); SetGraphicsMode(hdc, GM_ADVANCED); SetWorldTransform(hdc, &xf); HBITMAP hbmp = (HBITMAP) LoadImage( NULL, L"a.bmp", IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE); HDC hmemdc = CreateCompatibleDC(hdc); SelectObject(hmemdc, hbmp); BitBlt(hdc, 100, 0, 150, 50, hmemdc, 0, 0, SRCCOPY); EndPaint(hWnd, &ps);

May 21, 2014

Re: [PATCH 1/2] riched20: Implement ITextSelection::GetText.

by Nikolay Sivov

> +HRESULT ME_ITextGetText(ME_TextEditor *editor, ME_Cursor *start, ME_Cursor *end, BSTR *pb) DECLSPEC_HIDDEN; Is this really needed? > + buffer = heap_alloc((nChars + 1) * sizeof(WCHAR)); > + if (!buffer) > + return E_OUTOFMEMORY; > + ME_GetTextW(editor, buffer, nChars, start, nChars, 0); > + buffer[nChars] = 0; > + /* FIXME: a '\r' should be appended at the end of a story */ > + *pb = SysAllocString(buffer); > + heap_free(buffer); This could be simplified with SysAllocStringLen().

May 21, 2014

Re: [PATCH 2/2] riched20: Implement ITextSelection::GetChar.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7197 Your paranoid android. === wvistau64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF57FACFA === w2008s64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF745ACFA

May 21, 2014

Re: [PATCH 1/2] riched20: Implement ITextSelection::GetText.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7196 Your paranoid android. === wvistau64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF57FACFA === w2008s64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF745ACFA

May 21, 2014

Re: [1/2] ws2_32: Avoid memory allocation for simple sends

by Austin English

On Mon, May 19, 2014 at 2:16 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > send() will ever use a single wsabuffer structure and most common > applications use of WSASend() will also send a single buffer. Saves > over 6 thousand calls to HeapAlloc in make test. > In (very non-scientific) timing runs, these two patches reduced valgrind test time by ~20% (5 vs 4 minutes), thanks! -- -Austin

May 21, 2014

Re: mshtml: Added IHTMLTableRow::insertCell method implementation.

by Zhenbo Li

Sorry, I've found that this patch may have some problems. Please ignore that, and I'll send a fixed one later. 2014-05-21 9:45 GMT+08:00 Zhenbo Li <litimetal(a)gmail.com>: > --- > dlls/mshtml/htmltablerow.c | 26 ++++++++++++++++++++++++-- > dlls/mshtml/tests/dom.c | 7 +++++++ > 2 files changed, 31 insertions(+), 2 deletions(-) > > -- Have a nice day! Zhenbo Li

May 21, 2014

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory. (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7194 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

May 21, 2014

Re: [PATCH 1/2] wined3d: Set palettes on the swapchain (v2).

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-20 17:17, schrieb Henri Verbeet: > I don't think we need that since afaik we should never do RGBA -> > P8 blits / presents. But even then, does this even work for > swapchain surfaces? I'd expect the alpha channel to just be lost. I'm not sure what you mean with RGBA -> P8 blits. Those never worked, and I don't expect them to do anything reasonable on Windows. But still I think you're right and it is safe to remove this code. What we needed this for is reading back P8 drawables that were converted to RGBA, and since 7b049245 that's only the front buffer. If the conversion is done with the shader we have the unmodified ALPHA8 texture. Otherwise we set SFLAG_CONVERTED and never free sysmem and don't do GL-side blits. (Ddraw will never read back the front buffer, but wined3d doesn't know that.) Re GDI presents: A HPALETTE attached to the device context doesn't do anything, as expected. If I understand GDI palette handling correctly, the attached palette only matters when drawing to a device context that has a palette-indexed bitmap / window attached, but not when reading from it. The DIB color table determines the color values produced when reading from a palette-indexed DIB section. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTe7S4AAoJEN0/YqbEcdMw8NYP/RKLq9SeHO3wBZJ2QFR0T0KC ImlURVQRiRVgtZyuBDSLolnSy3OMVODFis8fc1M+12jMV9pLsXCvEr/RSZtfLCJP xuYSIK4Ih5OmJcWWYgW3fYzNVHdSb5JLTvTVNpGpMFGXSKVDBXcXO8+J6Pb5oGHi Yg1wDiZk/4256V3OMA50Hm2Joby2U0e3YcmU4RbnhKkasOaok1qi5h8pgfzz0HlJ R9oS1ylOWjVBkqyXxsCnj8Gth1IuLtd+I3OkLHDZwNKpS8wS9crFwB4bfsVg8r6I TM6Eh1iBXGAg/hOc4v3bgJedWVODSNOq6P7NYSe2joWRhz8rtGRtHxXQmKeok0ee i7P/hCoxiRCKPhKbPVxyLBoWOphFT1eduHq+FOXDPoiiT5X+yIzm/mqrTntOqP3w HhV5oPeTvHFAp6cStygC1Ae5dD8TNN2JVidy/cfnO9Wbfbf0HdUut6c48a5T6mnH MAf0mhELZviAp8m1qpRKi1HhJrAzekc8vJNuEvYVIWejlSICzGzCIGrbpBKPQcu1 I24vzMwtVhd9YLtDxVxAEvRMA1ysQz11AqiIhc2aLpmtYuneP0g3H3LnPdgWk6OX 3aA0d3Z0tNwQuqblPex3KfH6JIoKqGjG0w8vd0hyI4gxeq8W2egUG6IMSiRKk8H1 oOPGdc57O4CAEym7FGRz =VaAq -----END PGP SIGNATURE-----

May 20, 2014

Re: Can my WINE program write to files in /usr directory?

by Julius Schwartzenberg

John Found wrote: > So, I want to natively integrate it in Linux desktop, not in the "programs" submenu of Wine. In that case, I would suggest looking into creating packages (RPM, DEB) for the Linux based desktop systems you're targeting. Then you can just include desktop files in the package. Two examples of packaged Wine-applications are pptview (on Debian & Ubuntu using the system provided Wine) and Picasa (which included its own Wine if I remember correctly).

May 20, 2014

Fix for PlgBlt, the XFORM matrix was calculated incorrectly

by Alexander Almaleh

I had tried to submit a patch for that 5 years ago<http://www.winehq.org/pipermail/wine-devel/2009-December/080391.html>, but couldn't figure out how to make a patch/test it, and eventually gave up and forgot about it. But recently I remembered about it, and now I want to try again. So, this time I've prepared a test that can prove that the previous implementation does not calculate the XFORM matrix correctly, and that my patch will fix it. The test is a VC6 project, you can find it at https://drive.google.com/file/d/0B9PGUhmmnsm1S2VvZzc3WmhBY3c/edit?usp=shari…. The test is a demo of PlgBlt that I found on CodeProject<http://www.codeproject.com/Articles/17712/The-GDI-magic-Rendering-reflectio…>. You can compare how it works on XP and on Wine. For testing, I directly inserted the original Wine implementation of PlgBlt, as well as my patched version, into the VC6 project, and tested on that. This is because there seems to be an additional problem with MaskBlt, which I'll try tackling next. I have screenshots of what the demo looks using Windows's PlgBlt<http://imgur.com/q8qKGd7>, and Wine's PlgBlt <http://imgur.com/smYEV6z>. To test it, simply look at this function in the VC6 project: BOOL MyPlgBlt( HDC hdcDest, const POINT *lpPoint, HDC hdcSrc, INT nXSrc, INT nYSrc, INT nWidth, INT nHeight, HBITMAP hbmMask, INT xMask, INT yMask) { // return MyPlgBltWinePatched(hdcDest, lpPoint, hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hbmMask, xMask, yMask); return MyPlgBltWineUnpatched(hdcDest, lpPoint, hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hbmMask, xMask, yMask); // return PlgBlt(hdcDest, lpPoint, hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hbmMask, xMask, yMask); } Uncomment the function you want to test. If you need something else (like binaries), just write. And this is the patch itself. I've tried to keep the changes minimal, with respect to white-space, etc. I've removed a "return FALSE", because I don't calculate a determinant explicitly. commit c9ca2cab58fa0cba3d6b24cfb2af507fd1c07227 Author: Alexander Almaleh <sashoalm(a)gmail.com> Date: Tue May 20 18:33:55 2014 +0300 Fix for the calculation of the XFORM matrix in PlgBlt. diff --git a/dlls/gdi32/bitblt.c b/dlls/gdi32/bitblt.c index 4750d1b..1de25b9 100644 --- a/dlls/gdi32/bitblt.c +++ b/dlls/gdi32/bitblt.c @@ -992,22 +992,32 @@ BOOL WINAPI PlgBlt( HDC hdcDest, const POINT *lpPoint, HDC hdcSrc, INT nXSrc, INT nYSrc, INT nWidth, INT nHeight, HBITMAP hbmMask, INT xMask, INT yMask) { + /* we need to use floating-point precision when calculating the + * XFORM matrix to avoid loss of precision due to rounding */ + typedef struct tagPOINTLF + { + double x, y; + } POINTLF; + int oldgMode; /* parallelogram coords */ - POINT plg[3]; + POINTLF plg[3]; /* rect coords */ - POINT rect[3]; + POINTLF rect[3]; XFORM xf; XFORM SrcXf; XFORM oldDestXf; - double det; + int ii; /* save actual mode, set GM_ADVANCED */ oldgMode = SetGraphicsMode(hdcDest,GM_ADVANCED); if (oldgMode == 0) return FALSE; - memcpy(plg,lpPoint,sizeof(POINT)*3); + for (ii = 0; ii < 3; ii++) { + plg[ii].x = lpPoint[ii].x; + plg[ii].y = lpPoint[ii].y; + } rect[0].x = nXSrc; rect[0].y = nYSrc; rect[1].x = nXSrc + nWidth; @@ -1015,33 +1025,39 @@ BOOL WINAPI PlgBlt( HDC hdcDest, const POINT *lpPoint, rect[2].x = nXSrc; rect[2].y = nYSrc + nHeight; /* calc XFORM matrix to transform hdcDest -> hdcSrc (parallelogram to rectangle) */ - /* determinant */ - det = rect[1].x*(rect[2].y - rect[0].y) - rect[2].x*(rect[1].y - rect[0].y) - rect[0].x*(rect[2].y - rect[1].y); - - if (fabs(det) < 1e-5) - { - SetGraphicsMode(hdcDest,oldgMode); - return FALSE; - } TRACE("hdcSrc=%p %d,%d,%dx%d -> hdcDest=%p %d,%d,%d,%d,%d,%d\n", hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hdcDest, plg[0].x, plg[0].y, plg[1].x, plg[1].y, plg[2].x, plg[2].y); /* X components */ - xf.eM11 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y - rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det; - xf.eM21 = (rect[1].x*(plg[2].x - plg[0].x) - rect[2].x*(plg[1].x - plg[0].x) - rect[0].x*(plg[2].x - plg[1].x)) / det; - xf.eDx = (rect[0].x*(rect[1].y*plg[2].x - rect[2].y*plg[1].x) - - rect[1].x*(rect[0].y*plg[2].x - rect[2].y*plg[0].x) + - rect[2].x*(rect[0].y*plg[1].x - rect[1].y*plg[0].x) - ) / det; + xf.eM11 = -(rect[1].y*plg[2].x+rect[0].y*(plg[1].x-plg[2].x) + -rect[2].y*plg[1].x+plg[0].x*(rect[2].y-rect[1].y)) + /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+ + rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x); + xf.eM21 = (plg[0].x*(rect[2].x-rect[1].x)-plg[1].x*rect[2].x + +plg[2].x*rect[1].x+(plg[1].x-plg[2].x)*rect[0].x) + /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x + +rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x); + xf.eDx = -(rect[0].y*(plg[2].x*rect[1].x-plg[1].x*rect[2].x) + +plg[0].x*(rect[1].y*rect[2].x-rect[2].y*rect[1].x) + +(rect[2].y*plg[1].x-rect[1].y*plg[2].x)*rect[0].x) + /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y + *rect[1].x+(rect[1].y-rect[2].y)*rect[0].x); /* Y components */ - xf.eM12 = (plg[1].y*(rect[2].y - rect[0].y) - plg[2].y*(rect[1].y - rect[0].y) - plg[0].y*(rect[2].y - rect[1].y)) / det; - xf.eM22 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y - rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det; - xf.eDy = (rect[0].x*(rect[1].y*plg[2].y - rect[2].y*plg[1].y) - - rect[1].x*(rect[0].y*plg[2].y - rect[2].y*plg[0].y) + - rect[2].x*(rect[0].y*plg[1].y - rect[1].y*plg[0].y) - ) / det; + xf.eM12 = -(rect[1].y*(plg[2].y-plg[0].y)+rect[0].y*(plg[1].y + -plg[2].y)+rect[2].y*(plg[0].y-plg[1].y))/(rect[0].y*(rect[2].x + -rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y + -rect[2].y)*rect[0].x); + xf.eM22 = ((plg[0].y-plg[1].y)*rect[2].x+(plg[2].y-plg[0].y)*rect[1].x + +(plg[1].y-plg[2].y)*rect[0].x) /(rect[0].y*(rect[2].x-rect[1].x) + -rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y-rect[2].y) + *rect[0].x); + xf.eDy = (rect[0].y*(plg[1].y*rect[2].x-plg[2].y*rect[1].x) + -rect[1].y*plg[0].y*rect[2].x+rect[2].y*plg[0].y*rect[1].x + +(rect[1].y*plg[2].y-rect[2].y*plg[1].y)*rect[0].x)/(rect[0].y + *(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x + +(rect[1].y-rect[2].y)*rect[0].x); GetWorldTransform(hdcSrc,&SrcXf); CombineTransform(&xf,&xf,&SrcXf);

May 20, 2014

Re: [PATCH 1/2] wined3d: Set palettes on the swapchain (v2).

by Henri Verbeet

On 20 May 2014 16:35, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Yes, except for setting color[i].alpha = i. This should eventually be handled by the caller, and in the case of the ARB blitter, the shader. That’s a topic for a different patch though. > I don't think we need that since afaik we should never do RGBA -> P8 blits / presents. But even then, does this even work for swapchain surfaces? I'd expect the alpha channel to just be lost.

May 20, 2014

Re: [PATCH 1/2] wined3d: Set palettes on the swapchain (v2).

by Stefan Dösinger

Am 20.05.2014 um 14:27 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > On 20 May 2014 13:09, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> @@ -3372,7 +3301,7 @@ static BOOL color_in_range(const struct wined3d_color_key *color_key, DWORD colo >> >> void d3dfmt_p8_init_palette(const struct wined3d_surface *surface, BYTE table[256][4]) >> { >> - const struct wined3d_palette *pal = surface->palette; >> + const struct wined3d_palette *pal = surface->swapchain ? surface->swapchain->palette : NULL; >> unsigned int i; >> >> if (!pal) > This function is a bit silly. I think all callers should be able to > just use palette->colors[], and avoid the extra copy. Yes, except for setting color[i].alpha = i. This should eventually be handled by the caller, and in the case of the ARB blitter, the shader. That’s a topic for a different patch though. > I'd guess that > if no palette is set on the swapchain it should use the system > palette, but perhaps it's ok to leave that undefined for now. Yes, but it’s not as easy as as calling GetSytemPaletteEntries because we’re not actually in P8 mode. I think the best we can do is create a wined3d default palette that contains the fixed entries of the Windows system palette and sets the other colors to black / white / pink whatever. If there's an application that modifies the system palette via gdi and then uses ddraw with an undefined palette we'll need a more elaborate paletteindexed mode emulation scheme that probably involves winex11.drv/winemac.drv. > This is problematic in wined3d, because you can have multiple > swapchains using the same palette. In practice that never happens, but > that depends on knowing about everything that calls wined3d. If you > really need this kind of scheme you'd have to make "palette->changed" > a counter, and then iterate over all swapchains on wrap, A previous (unsent) version kept the flag in the swapchain and iterated over all attached swapchains similar to what swapchain_realize_palette was doing. That would handle multiple swapchains, but I'd prefer to keep it in the palette because eventually the palette should maintain the P8 blit texture and will need the dirty flag for this purpose. > but couldn't > you just create a GDI palette for the wined3d palette, and then select > that into the DC for the blit? I'm not entirely sure what the relation between the DIB color table and the device context's palette is. I read plenty of documentation and experimented with this on Windows when I wrote the getdc palette tests. I couldn't make the HPALETTE attached to a DC from a surface do anything on Windows. I'll see if it magically does something in x11_copy_to_screen. > Or just always update the palette, > which is pretty much what we do now in the GL case. Sure, that's always a fallback option, but I'd prefer to avoid it.

May 20, 2014

Re: [PATCH 1/2] wined3d: Set palettes on the swapchain (v2).

by Henri Verbeet

On 20 May 2014 13:09, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -3372,7 +3301,7 @@ static BOOL color_in_range(const struct wined3d_color_key *color_key, DWORD colo > > void d3dfmt_p8_init_palette(const struct wined3d_surface *surface, BYTE table[256][4]) > { > - const struct wined3d_palette *pal = surface->palette; > + const struct wined3d_palette *pal = surface->swapchain ? surface->swapchain->palette : NULL; > unsigned int i; > > if (!pal) This function is a bit silly. I think all callers should be able to just use palette->colors[], and avoid the extra copy. I'd guess that if no palette is set on the swapchain it should use the system palette, but perhaps it's ok to leave that undefined for now. > @@ -619,6 +625,14 @@ void x11_copy_to_screen(const struct wined3d_swapchain *swapchain, const RECT *r > > TRACE("swapchain %p, rect %s.\n", swapchain, wine_dbgstr_rect(rect)); > > + if (swapchain->palette && (swapchain->palette != swapchain->last_gdi_blt_palette > + || swapchain->palette->changed)) > + { > + wined3d_palette_apply_to_dc(swapchain->palette, swapchain->front_buffer->hDC); > + swapchain->last_gdi_blt_palette = swapchain->palette; > + swapchain->palette->changed = FALSE; > + } > + > front = swapchain->front_buffer; > if (front->resource.map_count) > ERR("Trying to blit a mapped surface.\n"); This is problematic in wined3d, because you can have multiple swapchains using the same palette. In practice that never happens, but that depends on knowing about everything that calls wined3d. If you really need this kind of scheme you'd have to make "palette->changed" a counter, and then iterate over all swapchains on wrap, but couldn't you just create a GDI palette for the wined3d palette, and then select that into the DC for the blit? Or just always update the palette, which is pretty much what we do now in the GL case.

May 20, 2014

Re: [PATCH] msxml3: removed unused allocation (Coverity)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7177 Your paranoid android. === w2008s64 (32 bit domdoc) === Unable to set the VM system time: the "nc -q0 '10.42.42.136' '4242'" command returned 1

May 20, 2014

Re: Can my WINE program write to files in /usr directory?

by John Found

> What are you writing, out of curiosity? > http://fresh.flatassembler.net It is assembly language RAD IDE, that can compile and run Linux and Windows applications both on Windows and Linux OS. This way, it is actually hybrid - uses some native Linux system calls in Linux. So, I want to natively integrate it in Linux desktop, not in the "programs" submenu of Wine.

May 20, 2014

Re: Can my WINE program write to files in /usr directory?

by Scott Ritchie

What are you writing, out of curiosity? On Tue, May 13, 2014 at 11:31 AM, John Found <johnfound(a)asm32.info> wrote: > Thanks. Your hint is really helpful. I will have to read more. :) > > Thanks again. > > On Tue, 13 May 2014 13:20:22 -0500 > Andrew Eikum <aeikum(a)codeweavers.com> wrote: >> >> If it's on a single user's request, <~/.local/share/applications/> >> might be a better location, and wouldn't require special permissions. >> >> If you want the desktop file accessible for all users, you could use >> $XDG_DATA_DIRS to tell programs that use desktop files to access a >> location where all users have permission to read and possibly write. >> Those programs should hopefully use that variable correctly to locate >> your desktop files. >> >> Some more info here: >> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html >> >> Andrew > > > -- > asm32.info <johnfound(a)asm32.info> > >

May 20, 2014

Re: [2/2] server: Clear the queue's QS_SMRESULT bit when sending a new message.

by Vincent Povirk

> I believe you'll also need to set it again when the result is removed. AFAICT the get_message_reply handler assumes that QS_SMRESULT is already set when it's called, and just resets it when removing a result if it should be clear. It shouldn't be possible for get_message_reply to be called when QS_SMRESULT isn't set, because wait_message_reply always checks for that bit first. But now that you mention it, get_message_reply does have that 'cancel' argument, and if for some reason we did cancel a sendmessage before it has a reply, that bit wouldn't be set when it should be. I'll send a follow-up.

May 19, 2014

Re: [2/2] server: Clear the queue's QS_SMRESULT bit when sending a new message.

by Alexandre Julliard

Vincent Povirk <madewokherd(a)gmail.com> writes: > This keeps the QS_SMRESULT bit in sync with the reply status of the > most recent sent message, if it happens that the > previously-most-recent sent message already has a reply. > wait_message_reply depends on this to work correctly. I believe you'll also need to set it again when the result is removed. -- Alexandre Julliard julliard(a)winehq.org

May 19, 2014

Re: [PATCH 3/3] user32: Don't rely on HMENU for showing popups

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > The idea here is to push the conversions from HMENU to struct pointer > up the call stack until eventually we are only converting to/from > HMENUs near the client code border, so we don't depend on HMENU > internally at all. To do this right, you'd want to increase the refcount every time you get a pointer. Otherwise the pointer could become invalid as soon as control is transferred to the app through SendMessage (not that the current code always gets it right, but when using handles the problem is much reduced). -- Alexandre Julliard julliard(a)winehq.org

May 19, 2014

Re: vbscript: Support multibyte characters in Global_Chr

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7147 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

May 19, 2014

Re: [PATCH 2/2] mmdevapi: Clock rate should be in bytes for shared mode

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7145 Your paranoid android. === w7u (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.501088 render.c:2005: Test failed: Got wrong volume: 0.501088 === w8 (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.671337 render.c:2005: Test failed: Got wrong volume: 0.671337

May 19, 2014

Re: [PATCH 1/2] mmdevapi: Make buffer size divisible by number of periods

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7144 Your paranoid android. === w7u (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.501088 render.c:2005: Test failed: Got wrong volume: 0.501088 === w8 (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.671337 render.c:2005: Test failed: Got wrong volume: 0.671337

May 19, 2014

Re: [PATCH] vbscript: Implemented CCur

by Piotr Caban

On 05/19/14 16:30, Shuai Meng wrote: > There are two identical tests on MyObject. MyObject.myval is set to > 0 in first test (it's set this way in earlier tests). > > The first test is different from the third: in the first test I didn't > set MyObject.myval to 0 explicitly, the goal is to > test object's default value; while the third test set MyObject.myval to > 0 explicitly, this changes the default value of a object, though the > value is still 0. You've set it to 0 in earlier test (it's set to 0 in last CByte test).

May 19, 2014

Re: [PATCH] vbscript: Implemented CCur

by Shuai Meng

2014-05-19 17:06 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 05/19/14 08:47, Shuai Meng wrote: > >> +Call ok(CCur(0.000149) = 0.0001, "CCur(0.000149) = " & CCur(0.000149)) >> +Call ok(getVT(CCur(0.000149)) = "VT_CY", "getVT(CCur(0.000149)) = " & >> getVT(CCur(0.000149))) >> +Call ok(CCur(2147483647.99) = 2147483647.99, "CCur(2147483647.99) = " & >> CCur(2147483647.99)) >> +Call ok(getVT(CCur(2147483647.99)) = "VT_CY", "getVT(CCur(2147483647.99)) >> = " & getVT(CCur(2147483647.99))) >> > This tests are failing on polish locale. > > Sorry, I forget this again. > +Call ok(CCur(MyObject) = 0, "CCur(MyObject) = " & CCur(MyObject)) >> +Call ok(getVT(CCur(MyObject)) = "VT_CY", "getVT(CCur(MyObject)) = " & >> getVT(CCur(MyObject))) >> +MyObject.myval = 1 >> +Call ok(CCur(MyObject) = 1, "CCur(MyObject) = " & CCur(MyObject)) >> +Call ok(getVT(CCur(MyObject)) = "VT_CY", "getVT(CCur(MyObject)) = " & >> getVT(CCur(MyObject))) >> +MyObject.myval = 0 >> +Call ok(CCur(MyObject) = 0, "CCur(MyObject) = " & CCur(MyObject)) >> +Call ok(getVT(CCur(MyObject)) = "VT_CY", "getVT(CCur(MyObject)) = " & >> getVT(CCur(MyObject))) >> > There are two identical tests on MyObject. MyObject.myval is set to 0 in > first test (it's set this way in earlier tests). > > The first test is different from the third: in the first test I didn't set MyObject.myval to 0 explicitly, the goal is to test object's default value; while the third test set MyObject.myval to 0 explicitly, this changes the default value of a object, though the value is still 0. > Thanks, > Piotr >

May 19, 2014

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory.

by Alexandre Julliard

Zhenbo Li <litimetal(a)gmail.com> writes: > @@ -353,8 +353,13 @@ static BOOL SHELL_DeleteDirectoryW(HWND hwnd, LPCWSTR pszDir, BOOL bShowUI) > HANDLE hFind; > WIN32_FIND_DATAW wfd; > WCHAR szTemp[MAX_PATH]; > + DWORD attrib; > > /* Make sure the directory exists before eventually prompting the user */ > + attrib = GetFileAttributesW(pszDir); > + if (attrib == INVALID_FILE_ATTRIBUTES || !(attrib & FILE_ATTRIBUTE_DIRECTORY)) > + return FALSE; It would be better to avoid a redundant file lookup, particularly since it's only to set last error (which BTW you are not setting at all in the non-directory case). -- Alexandre Julliard julliard(a)winehq.org

May 19, 2014

Re: [PATCH] vbscript: Implemented CCur

by Piotr Caban

On 05/19/14 08:47, Shuai Meng wrote: > +Call ok(CCur(0.000149) = 0.0001, "CCur(0.000149) = " & CCur(0.000149)) > +Call ok(getVT(CCur(0.000149)) = "VT_CY", "getVT(CCur(0.000149)) = " & getVT(CCur(0.000149))) > +Call ok(CCur(2147483647.99) = 2147483647.99, "CCur(2147483647.99) = " & CCur(2147483647.99)) > +Call ok(getVT(CCur(2147483647.99)) = "VT_CY", "getVT(CCur(2147483647.99)) = " & getVT(CCur(2147483647.99))) This tests are failing on polish locale. > +Call ok(CCur(MyObject) = 0, "CCur(MyObject) = " & CCur(MyObject)) > +Call ok(getVT(CCur(MyObject)) = "VT_CY", "getVT(CCur(MyObject)) = " & getVT(CCur(MyObject))) > +MyObject.myval = 1 > +Call ok(CCur(MyObject) = 1, "CCur(MyObject) = " & CCur(MyObject)) > +Call ok(getVT(CCur(MyObject)) = "VT_CY", "getVT(CCur(MyObject)) = " & getVT(CCur(MyObject))) > +MyObject.myval = 0 > +Call ok(CCur(MyObject) = 0, "CCur(MyObject) = " & CCur(MyObject)) > +Call ok(getVT(CCur(MyObject)) = "VT_CY", "getVT(CCur(MyObject)) = " & getVT(CCur(MyObject))) There are two identical tests on MyObject. MyObject.myval is set to 0 in first test (it's set this way in earlier tests). Thanks, Piotr

May 19, 2014

Re: [website] German translation for release 1.7.19

by Michael Stefaniuc

On 05/18/2014 09:37 PM, Frédéric Delanoy wrote: > On Sun, May 18, 2014 at 5:40 PM, Julian Rüger <jr98(a)gmx.net> wrote: >> Hi Frédéric, >> >>> "writer" should probably be translated as well... >> >> I don't think there is a useful translation that is not clunky or sounds >> awkward. Plus, "writer" is probably a familiar term to most users >> because of i.e. LibreOffice Writer. > > LibreOffice Writer is an English product name, and maybe not known to > non-techies (it's just a word processing application to them) IMHO. > In German, it should probably be something like Redaktor, but you know > German better than me ;-) Ze Germans love their Denglish. Unlike in French not everything needs to be translated. Bonus points for English words and phrases that mean something totally different in English than what the politicians/marketing/mass media want you to believe. bye michael

May 19, 2014

Re: msi: Prevent call to memset with a nullptr in get_tablecolumns function

by Hans Leidekker

On Sun, 2014-05-18 at 13:27 -0400, Daniel Beitler wrote: > This is a fix for bug #36139. > > It looks like calling memset with a nullptr is undefined behavior. Gcc > 4.9 will actually optimize out the "if(colinfo)" condition if memset was > called on colinfo before. > > > --- > dlls/msi/table.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) Looks good, thanks.

May 19, 2014

Re: [website] German translation for release 1.7.19

by Frédéric Delanoy

On Sun, May 18, 2014 at 5:40 PM, Julian Rüger <jr98(a)gmx.net> wrote: > Hi Frédéric, > >> "writer" should probably be translated as well... > > I don't think there is a useful translation that is not clunky or sounds > awkward. Plus, "writer" is probably a familiar term to most users > because of i.e. LibreOffice Writer. LibreOffice Writer is an English product name, and maybe not known to non-techies (it's just a word processing application to them) IMHO. In German, it should probably be something like Redaktor, but you know German better than me ;-) Frédéric Delanoy

May 18, 2014

Re: [patch]Japanese Translation update

by Akihiro Sagawa

On Fri, 16 May 2014 10:08:47 -0400 (EDT), Toshiaki Hirose wrote: > From 67e0fca928a2f2de03adaf96f7a1f8f55e2cf85d Mon Sep 17 00:00:00 2001 > Message-Id: <67e0fca928a2f2de03adaf96f7a1f8f55e2cf85d.1400248197.git.t_hirose(a)aol.com> > From: Toshiaki Hirose <t_hirose(a)aol.com> > Date: Fri, 16 May 2014 22:49:46 +0900 > Subject: [PATCH] Japanese Translation Update for 1.7.18 > > --- > po/ja.po | 172 ++++++++++++++++++++++++--------------------------------------- > 1 file changed, 65 insertions(+), 107 deletions(-) Hello Hirose-san, Your translation is getting better, but it needs some more work. Could you read my comments and submit again? I also welcome your feedback. > #: oleacc.rc:97 > -#, fuzzy > #| msgid "Normal" > -msgctxt "object state" > msgid "normal" > -msgstr "標準" > +msgstr "normal" Msgctxt line can't be removed. The line indicates message context, and is used with msgid to specify translation. > #: oleacc.rc:98 > #: oleacc.rc:99 : : > #: oleacc.rc:128 Same as above. > #: regsvr32.rc:41 > msgid "" > "regsvr32: Invalid or unrecognized switch [%1]\n" > "\n" > msgstr "" > +"regsvr32: 無効または認識できない切り替えです[%1]\n" > +"\n" I'm not sure about this translation. This `switch' means `command-line switch'. In that case, we usually translate into `スイッチ'. For instance, see http://support.microsoft.com/kb/227091/ja vs http://support.microsoft.com/kb/227091/en-us . > #: regsvr32.rc:46 > msgid "regsvr32: Failed to unregister DLL '%1'\n" > -msgstr "" > +msgstr "regsvr32: DLL '%1'の登録消去に失敗しました。\n" You removed some full-stops, but didn't about this line. > #: regsvr32.rc:49 > msgid "regsvr32: Successfully installed DLL '%1'\n" > -msgstr "" > +msgstr "regsvr32: DLL '%1'のインストールに成功しました。\n" Ditto. Otherwise looks fine. Regards, Akihiro Sagawa

May 18, 2014

Re: [website] German translation for release 1.7.19

by Julian Rüger

Hi Frédéric, > "writer" should probably be translated as well... I don't think there is a useful translation that is not clunky or sounds awkward. Plus, "writer" is probably a familiar term to most users because of i.e. LibreOffice Writer. PS: Sorry for double post, forgot to CC wine-devel...

May 18, 2014

Re: msvcp90/msvcp90.h: right-hand operand of comma expression has no effect

by Gerald Pfeifer

On Wed, 16 Apr 2014, Paul Chitescu wrote: >> Digging into this in more detail I see >> >> ../msvcp90/ios.c: In function 'basic_streambuf_char__Xsgetn_s': >> ../msvcp90/msvcp90.h:529:75: warning: right-hand operand of comma >> expression has no effect [-Wunused-value] >> #define memcpy_s( dst, size, src, count ) (memcpy( (dst), (src), (count) >> ), 0) ^ ../msvcp90/ios.c:1218:13: note: in expansion of macro 'memcpy_s' >> memcpy_s(ptr+copied, size, *this->prpos, chunk); >> ^ > memcpy_s() returns an errno_t so the author tried to force returning > zero (no error). > > A simple replacement (still without any checks memcpy_s does) would be: > > #define memcpy_s( dst, size, src, count ) (!memcpy( (dst), (src), (count) )) I tried to make this change, but that now gets: ../msvcp90/msvcp90.h:529:44: warning: value computed is not used [-Wunused-value] #define memcpy_s( dst, size, src, count ) (!memcpy( (dst), (src), (count) )) ^ Since, clearly, the result is never intended to be used, we can as well simply cast the result away instead of using ", 0". This is what the patch below does. Tested successfully with GCC 4.9.0. Gerald diff --git a/dlls/msvcp90/msvcp90.h b/dlls/msvcp90/msvcp90.h index 0d5e124..0691141 100644 --- a/dlls/msvcp90/msvcp90.h +++ b/dlls/msvcp90/msvcp90.h @@ -526,7 +526,7 @@ typedef struct { } complex_double; #if _MSVCP_VER < 80 -#define memcpy_s( dst, size, src, count ) (memcpy( (dst), (src), (count) ), 0) +#define memcpy_s( dst, size, src, count ) ((void)memcpy( (dst), (src), (count) )) #define memmove_s( dst, size, src, count ) (memmove( (dst), (src), (count) ), 0) #define mbstowcs_s( ret, wcs, size, mbs, count ) (mbstowcs( (wcs), (mbs), (count) ), 0) #define hypotf( x, y ) ((float)hypot( (double)(x), (double)(y) ))

May 18, 2014

Re: [website] German translation for release 1.7.19

by Frédéric Delanoy

On Sat, May 17, 2014 at 4:00 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > Am 17.05.2014 02:10, schrieb Julian Rüger: >> +<date>16. Main 2014</date> > > -n, everything else is fine ;) "writer" should probably be translated as well... -- Frédéric Delanoy

May 17, 2014

Re: [website] German translation for release 1.7.19

by André Hentschel

Am 17.05.2014 02:10, schrieb Julian Rüger: > +<date>16. Main 2014</date> -n, everything else is fine ;)

May 17, 2014

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory.

by Zhenbo Li

Excuse me, is there anything to to to improve this patch? Thank you. 2014-05-10 8:28 GMT+08:00 Zhenbo Li <litimetal(a)gmail.com>: > 2014-05-09 23:09 GMT+08:00 Marvin <testbot(a)winehq.org>: >> >> >> === wvistau64 (32 bit shlfileop) === >> shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR >> >> === wvistau64 (64 bit shlfileop) === >> shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR > > > As http://testbot.winehq.org/JobDetails.pl?Key=6956 showes, they are not > caused by my patch. > > -- > Have a nice day! > Zhenbo Li -- Have a nice day! Zhenbo Li

May 17, 2014