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 30, 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 28, 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 27, 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 26, 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 22, 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 22, 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 22, 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 22, 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 21, 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 20, 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 20, 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 20, 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 19, 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 19, 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 17, 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 16, 2014

Re: vbscript: Parse doubles with bigger precision in parse_numeric_literal

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=7112 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 16, 2014

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

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> writes: > On 16 May 2014, at 12:51, 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? > > Hi Marvin, > > The tests fail because you didn't regenerate wine_test.ttf. It doesn't work here either, and I did regenerate wine_test.ttf: font.c:5076: Test failed: got 00a8 make: *** [font.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

May 16, 2014

Re: Wine Test analysis, report

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-16 15:39, schrieb Henri Verbeet: > For what it's worth, the ddraw1/2/4/7 ones that fail with "Got > unexpected pitch 252, expected 256." are because of 64-bit ddraw > using a different alignment. Fixing the tests to accept the 64-bit > result with a todo_wine shouldn't be hard, although ideally we'd > fix the implementation as well. I don't think it's worth the trouble. As far as I know only the 64 bit build of Internet Explorer uses 64 bit ddraw, and nobody uses the 64 bit IE because there are no plugins for it. We have other known behavior differences in 64 bit ddraw, for example d3d is available in ours, but not in native. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTdh+TAAoJEN0/YqbEcdMwFnQP/jcsVBGgZhd2pCGXSKwwiMuY EwjZJlcCMvnO9IpfXnb24JjYKqH6LBaqmSXmIDCzy9LFqFFjzV6NL4BcHrHnonQD yt/QhlTtSL/kKikcFTPOaazmzhTc9KVfoiN0cgUwmhwfI2fh0Rkf0Gyt57x2ivwz QFbAx8WfSZCw0CsvPtADznGDnZAKytnuNETfbJE26Uv0+bvskG2XLQvjzBv5F6LX hIIkPVEj4lWHsJ7IgDonsJUVLy/tr28fjFs9CcwO4oDR5F7XVquGvAdcdHcxB01I QC06pH4Di+g4psGv+UFLB99rO4WuHUo00m9rGU8/Ff8defG2YY0Ycfup0QoPFLJo y/1DhwWQ7t9YXiKluu0KlT/JkOHrpotDAJv7cUBtfWs+b1fXA8K0raw8d1Dw5XOe yMfYOWBODTealAqQ1TTdDCwpHVBsZYZY5OyaAgUzPvCPtvtapuZ5pt6jDdoZV8k3 xY8AB9iEAl7lQ2Ly3g8dbNgOw65JnpzJp6RTA5aD7ZGtqDgJCj20Yaq5es2YfDmg xgeyxKUnTQTWkhkcgZgVd8oeN/XfxjmjU46Aoy3YQm8VFgVNsRRifromVhFDCWsW cHlPEDwta3voRndQjE134facCpVe6bbE0lvM1aSPeldpT+u30Ifqu/xEHspjxjsZ mjoqUcqeP7kkzTBsGGuQ =PeYz -----END PGP SIGNATURE-----

May 16, 2014

Re: audio reset failed

by Andrew Eikum

On Tue, May 13, 2014 at 10:06:13AM +0200, Pawel Por wrote: > >There is a list of sound-related debug log channels at > ><http://wiki.winehq.org/Sound>. Getting a debug log with those > >channels set could give us a clue as to what's going wrong. > I've upgraded wine to version wine 1.7.18 (Arch Linux). > I still receive the message: "Audio Reset Failed: Access violation at > address 7BC4D272 in module 'ntdll.dll'. Write of address F82A011C" > This time I've run wine with the following debug channels: > +tid,+mmdevapi,+winmm,+driver,+msacm,+midi,+dsound,+dsound3d,+dmusic,+mci,+oss,+alsa,+coreaudio. > > I've attached the log. > Please write me if I can provide anything else. > Great thanks for your help. I took a quick look through the log and nothing stood out as broken. Other debug channels like +seh, +msgbox, or even +relay may help find the error. Like Austin said, you should open a bug. Feel free to CC me on it and we can continue there. Andrew

May 16, 2014

Re: Wine Test analysis, report

by Henri Verbeet

On 16 May 2014 15:31, Jeremy White <jwhite(a)codeweavers.com> wrote: > I'll start picking at these again. There should be at least a few that are > 'easy'. > For what it's worth, the ddraw1/2/4/7 ones that fail with "Got unexpected pitch 252, expected 256." are because of 64-bit ddraw using a different alignment. Fixing the tests to accept the 64-bit result with a todo_wine shouldn't be hard, although ideally we'd fix the implementation as well.

May 16, 2014

Re: mshtml: Added IHTMLLocation::assign method implementation.

by Nikolay Sivov

> HTMLLocation *This = impl_from_IHTMLLocation(iface); > - FIXME("(%p)->(%s)\n", This, debugstr_w(bstr)); > - return E_NOTIMPL; > + TRACE("(%p)->(%s)\n", This, debugstr_w(bstr)); > + return HTMLLocation_put_href(iface, bstr); I don't know if it correct or not, but please use method wrappers when calling from interface pointer instead of calling implementation directly.

May 16, 2014

Re: Wine Test analysis, report

by Jeremy White

Alright, I'm going to consider the test bot stable enough for us to work on it. I'm afraid the situation is pretty horrid - we were well under 20 issues remaining when we made the switch, now we're back up to 40 issues: http://www.winehq.org/~jwhite/54bf34f1e7cd.html Again, my analysis is what non Windows 8 tests are failing on our 'official' VMs. Those tests need to be squashed. I'll start picking at these again. There should be at least a few that are 'easy'. Cheers, Jeremy

May 16, 2014

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 3)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-16 14:34, schrieb Michael Stefaniuc: > riid is the documented name on http://wiki.winehq.org/COMGuideline > Some of the variables are "well established" now even though they > might have had a hungarian notation background. Ok. While I am aware of the COM guide I didn't notice the "riid" naming. Never mind this name then. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIbBAEBAgAGBQJTdgqtAAoJEN0/YqbEcdMwzmIP8wcK622ojMMhZTVhuVLJM0Oh RzZPC1vdWGlo8reXKIPD5yIuh6KJTeFx0W4PHZvv2N88kBNFHsT3daE/LfxSOVx5 mwNvb/QkAnUjNci7OImy1Cw5ZiLsKWGb/dYy+CdwMTTUhfOKaPy7Ac+BB8QHLRCC 7OhswS8+kkgeGqBTB+BBPEKPZ63aALLSkIAfv/hj90TEOCZRv3lyDIeSiJdSDezR sM4IqokJzdUxhRMcv4r99NvdDEKBk6WwlJCRJN47RJWfAZnCQoZ7X0v8tcnnI24S LtMETU8nVWR1nEV9JrLar9+FYyooxrKDZklA0ASfYpqoTSxhyfxc2eH9Uv9qH3A+ 1l4HempfyUishqYfVQm5P1x+QMgAE0ZoYGc+3/xpsla3W+mtfBqMeRjnG25URFeO W2jmFsb6XXwLSh2zC/u0yy6NmIaGW2tGxpQ3ePjHj9sT40ubajKoTPd4uOyJ/Pda o7RYori/mzNKu4tBMrSGdf5fsGA4EMznqjXgL8FRnWeSOksTK8KbwYzkTWf6IvOl h6dvM9bN2xT2dmfumLgJuMDi+XzprFai5IAL7UdNfgf4yUMnqleMnKy4UFrF/L9U nt/g+vW9l1jdpUHnKtaf8QFRRWIzlg/7sB9f2GukvJhr1EcdSnP+bhbmRyVx4GZ8 l710pYn6ng3G/FwDI98= =QF7P -----END PGP SIGNATURE-----

May 16, 2014

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 3)

by Michael Stefaniuc

Hello Stefan, On 05/16/2014 02:22 PM, Stefan Dösinger wrote: > Since you have to resend it anyway, I'll point out some things you > missed: > > Am 2014-05-16 11:55, schrieb Alistair Leslie-Hughes: >> +extern HRESULT DPNET_CreateDirectPlay8LobbyClient(IClassFactory >> *iface, IUnknown *pUnkOuter, REFIID riid, void **ppobj) >> DECLSPEC_HIDDEN; > ppobj, pUnkOuter. I guess "riid" qualifies as hungarian notation as > well, "iid" would be a better name. riid is the documented name on http://wiki.winehq.org/COMGuideline Some of the variables are "well established" now even though they might have had a hungarian notation background. bye michael

May 16, 2014

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 3)

by Henri Verbeet

On 16 May 2014 14:22, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >> + client = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectPlay8LobbyClientImpl)); >> + if (!client) { >> + *obj = NULL; >> + return E_OUTOFMEMORY; >> + } > } placement. > While we're handing out style hints, I think "sizeof(*client)" is generally nicer for this kind of thing.

May 16, 2014

Re: [PATCH 2/5] wined3d: Set palettes on the swapchain.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-15 18:16, schrieb Henri Verbeet: > In ddraw, when you call SetEntries() on a palette with > DDPCAPS_PRIMARYSURFACE set, you can just call > ddraw_surface_update_frontbuffer(). This should work, yeah. I'm not really happy with ddraw controlling such things, but at the moment this seems like the cleanest solution. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTdgNoAAoJEN0/YqbEcdMwN+IP/1fTTLIz2WXvbJzfKyG0gA2a FpdxoN5zoj+NQEYbCYieYjUqU1RdFoOfUoZ5Q0emEmeiZQrPaq8+slXtRg1uNSc4 4SFanBkJmoPhC8qTXfdzV4jWRrfn7oBd5SXMDs04b41QtBSp/IIFdJJbRID0NpoV mlOKi9P5tKmzsqBMzq9HYHBnT3Slo4meV3QEB6+GqSQo6fHnxIFecdY++Gc6UDA8 iS8npM15OgtWgcKSvMRi1lpETrCWZ9PoQnJ+BHOy6J0Cj6fgfUoL5/QxYY52/qD2 4Hojn/Ga1Sx3+KfYhozDcMkeJGIXHStMOhpPgurqAE6owW+ralIT0nCwiRAPGdBy xHxV5VbdrawRRHlpCqJaMaELnWxXI0gabegEKkwUyzVQMmML/UYMlBfVaeIiqzg1 FUod+myxGVbMU8Qq2AMBkDbAmBQHBUVDRS3Um1SETsuYPIwnVPsUBHGmxDDpnrx4 xt1GXDEUWB0Mwae0Xkd7PkpYSHD/yjwpQiQ4ll8tvk1QavPqfapVCDb4OKP5qWgv mo+6lf2ojmhsPIC0cc+9Nx26vjaNlMCPIM3404T2jaG34EEMRXzhDSntrTFYK5bt AKETXlLS/XDh1CkL7foBeTdH2+gqXMyemZvLbmunN0Dxa5yZvZlDfll4cRTgBodq i7iPkE/QQ8AbHuSRgFbZ =mhpt -----END PGP SIGNATURE-----

May 16, 2014

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 3)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alistair, Since you have to resend it anyway, I'll point out some things you missed: Am 2014-05-16 11:55, schrieb Alistair Leslie-Hughes: > +extern HRESULT DPNET_CreateDirectPlay8LobbyClient(IClassFactory *iface, IUnknown *pUnkOuter, REFIID riid, void **ppobj) DECLSPEC_HIDDEN; ppobj, pUnkOuter. I guess "riid" qualifies as hungarian notation as well, "iid" would be a better name. > +static HRESULT WINAPI lobbyclient_GetConnectionSettings(IDirectPlay8LobbyClient *iface, DPNHANDLE connection, DPL_CONNECTION_SETTINGS *sessioninfo, DWORD *infosize, DWORD flags) > +{ > + IDirectPlay8LobbyClientImpl *This = impl_from_IDirectPlay8LobbyClient(iface); > + > + FIXME("(%p)->(%d %p %p %x)\n", This, connection, sessioninfo, infosize, flags); DPNHANDLE is a DWORD, so you should use %u. This affects the other functions as well. You may want to use 0x%0x, or %#x instead of %x to make it obvious that a value in the logs is a hex value. This is purely a matter of taste and I'll leave it up to you - just pointing out the options. > +HRESULT DPNET_CreateDirectPlay8LobbyClient(IClassFactory *iface, IUnknown *pUnkOuter, REFIID riid, void **obj) Same as above. > + client = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectPlay8LobbyClientImpl)); > + if (!client) { > + *obj = NULL; > + return E_OUTOFMEMORY; > + } } placement. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTdgMYAAoJEN0/YqbEcdMwrZQP/RDuje3TEb0hSoBeQslCkopF jCWpT0FgX8k/yV03yrtS1Rs23vk6edeNdUBQw3oFjtw7W+eIm2sF/07w69Xbgwtn 6qmIb2Et+gffC+c95XdAhtEZucEzAbepD1IgIoMo6QBbVKDeVzupb2sJyhRO4fYU BXYj4gh12B6Ldn70gk9eebgYbf1fI00wagtQj8SJI2mD2iyuntylJ6f5wauOSLS0 jGS66furb5xqN73c05knfIsZhfg21b4jCEs3viOPlo5255R9kiH7xW1A7HEXdT+Y RmVBEmfaAR0IBlRi8tQ+33wsPy6rTo4YS9tAPQugXgXU36XCOJ5UHlLRF3KbmmUj BeiXGZa7EYdWaCCECfNapVq+xGBfoFVwGR1HtKNDjGZIBCJIbn7GIEh5iRvTO/VB 1Vd1mDVZeCQS4L5euMLdVxr1q8EO8cFMUVNoZPpkATwOZgUngaOIptsBhsrcTtdp 3qa4Q/Zhou2vf45FnzTxn5+rCV1Ok96Ks6TrqZzrHzv3iJyxigVwni9OguYVvxRF ajj3u2IG3PhcOEmlHKoGmxMuX+aT9X/qECHIYu+B9UMQCMJ0xNQRR1DFatH1egUl cFJOAjlY5xiZl2abl0rzYMxTchL6cYSHRrRR3wH0gayy+MG5or+7zBLnHOp9jQDJ PC42+CyMr1Zxketm8h7y =wB3J -----END PGP SIGNATURE-----

May 16, 2014

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

by Huw Davies

On 16 May 2014, at 12:51, 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? Hi Marvin, The tests fail because you didn't regenerate wine_test.ttf. Huw.

May 16, 2014

Re: 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=7109 Your paranoid android. === w2000pro (32 bit font) === font.c:5076: Test failed: got 00a8 === wxppro (32 bit font) === font.c:5076: Test failed: got 00a8 === wvistau64 (32 bit font) === The test timed out === w2008s64 (32 bit font) === font.c:5076: Test failed: got 00a8 === w7u (32 bit font) === font.c:5076: Test failed: got 00a8 === w8 (32 bit font) === font.c:5076: Test failed: got 00a8 === wvistau64 (64 bit font) === font.c:5076: Test failed: got 00a8 === w2008s64 (64 bit font) === font.c:5076: Test failed: got 00a8

May 16, 2014

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 3)

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > diff --git a/dlls/dpnet/Makefile.in b/dlls/dpnet/Makefile.in > index 541e104..70ccef0 100644 > --- a/dlls/dpnet/Makefile.in > +++ b/dlls/dpnet/Makefile.in > @@ -7,6 +7,7 @@ C_SRCS = \ > client.c \ > dpnet_main.c \ > lobbiedapp.c \ > + lobbyclient.c \ > peer.c \ > server.c \ > threadpool.c Please merge that code into some existing files, we don't need so many new files. -- Alexandre Julliard julliard(a)winehq.org

May 16, 2014

Re: [PATCH 4/5] d2d1: Add the ID2D1RenderTarget interface.

by Jacek Caban

Hi Henri, On 05/16/14 09:59, Henri Verbeet wrote: > diff --git a/dlls/d2d1/d2d1_main.c b/dlls/d2d1/d2d1_main.c > index 9a389a2..d1e5e8f 100644 > --- a/dlls/d2d1/d2d1_main.c > +++ b/dlls/d2d1/d2d1_main.c > @@ -21,6 +21,9 @@ > #include "wine/port.h" > #include "wine/debug.h" > > +#include "winbase.h" > +#include "winuser.h" > +#undef DrawText It's probably better to place such #undef in .idl file itself (inside cpp_quote). That's what we already do in quite a few places and it avoids the need for hacking every .c file using the header. Jacek

May 16, 2014

Re: mshtml: Fixed a few more IE11 test failures.

by Marvin

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

May 15, 2014

Re: audio reset failed

by Austin English

On Thu, May 15, 2014 at 4:07 AM, Pawel Por <porparek(a)gmail.com> wrote: > > An HTML attachment was scrubbed... > > URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20140513/8f5f34ee/at…> > > > I've uploaded the wine log at (37 KB): > http://www.sendspace.pl/en/file/294794be77c2a1703e60d94 > > thanks for your help > > Bugs should be reported at https://bugs.winehq.org -- -Austin

May 15, 2014

Re: [PATCH 7/7] oleacc: Add WindowFromAccessibleObject implementation

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=7083 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

May 15, 2014

Re: oleacc: Add WindowFromAccessibleObject implementation

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=7084 Your paranoid android. === build (build) === Patch failed to apply

May 15, 2014

Re: [PATCH 6/7] oleacc: Add IOleWindow::GetWindow implementation in default client accessible object

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=7082 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

May 15, 2014

Re: [PATCH 2/5] wined3d: Set palettes on the swapchain.

by Henri Verbeet

On 15 May 2014 15:36, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >> I don't think this kind of thing should be needed. You should be able >> to make the palette texture that currently lives in the ARB program >> shader backend a property of the wined3d palette, and then presents >> can just make sure the palette texture is current. Something similar, >> if perhaps slightly more involved, should be possible for the GDI >> swapchain with GDI palettes. > We have to redraw the front buffer when the palette is changed for palette fading to work. We can’t wait for the next present, nor can we initiate a regular present since we want the front buffer redrawn, and not the back buffer. I should perhaps have explicitly mentioned blits to the front buffer instead of presents as such, but the principle is the same of course. In ddraw, when you call SetEntries() on a palette with DDPCAPS_PRIMARYSURFACE set, you can just call ddraw_surface_update_frontbuffer().

May 15, 2014

Re: [PATCH 4/7] oleacc: Add IOleWindow interface stub to default client accessible object

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=7081 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

May 15, 2014

Re: [PATCH 5/5] includes: Fix an in/out annotation in shobjidl.idl.

by Nikolay Sivov

On 5/15/2014 20:02, Vincent Povirk wrote: > http://msdn.microsoft.com/en-us/library/aa367294.aspx > > "The [unique] attribute cannot be applied to [out]-only top-level > pointer parameters (parameters that have only the [out] directional > attribute)." > Interesting, I can't reproduce that with midl 7.00.05. It's possible that newer versions are different which I doubt, most likely my test is incomplete - it only generates a header (I still expected a full syntax check).

May 15, 2014

Re: [PATCH 5/5] includes: Fix an in/out annotation in shobjidl.idl.

by Vincent Povirk

http://msdn.microsoft.com/en-us/library/aa367294.aspx "The [unique] attribute cannot be applied to [out]-only top-level pointer parameters (parameters that have only the [out] directional attribute)."

May 15, 2014

Re: [PATCH 3/7] oleacc: Disable tests on old oleacc

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=7080 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

May 15, 2014

Re: [PATCH 2/7] oleacc: Don't return partial data in GetRoleTextA if buffer is too small

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=7079 Your paranoid android. === wxppro (32 bit main) === main.c:96: Test failed: GetRoleTextA returned not zero-length buffer : (t)

May 15, 2014

Re: [PATCH 4/4] xmllite/writer: Implement Flush() method

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=7075 Your paranoid android. === wvistau64 (32 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>?> === w2008s64 (64 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>ncoding="UT

May 15, 2014

Re: [PATCH 3/4] xmllite/writer: Initial support for starting a document

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=7074 Your paranoid android. === wvistau64 (32 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>?> === w2008s64 (64 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>ncoding="UT

May 15, 2014

Re: [PATCH 2/4] xmllite/writer: Initial support of output buffer creation

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=7073 Your paranoid android. === wvistau64 (32 bit writer) === writer.c:219: Test failed: got <?xml version="1.0"?>?> === w2008s64 (64 bit writer) === writer.c:219: Test failed: got <?xml version="1.0"?>ncoding="UT

May 15, 2014

Re: [PATCH 5/5] includes: Fix an in/out annotation in shobjidl.idl.

by Stefan Dösinger

Am 15.05.2014 um 14:40 schrieb Nikolay Sivov <bunglehead(a)gmail.com>: > On 5/15/2014 16:33, Stefan Dösinger wrote: >> --- >> include/shobjidl.idl | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/include/shobjidl.idl b/include/shobjidl.idl >> index c9297a8..ae42c2e 100644 >> --- a/include/shobjidl.idl >> +++ b/include/shobjidl.idl >> @@ -3350,7 +3350,7 @@ interface ITransferAdviseSink : IUnknown >> HRESULT FileFailure([in] IShellItem *item, >> [in, unique, string] LPCWSTR itemname, >> [in] HRESULT hr, >> - [out, unique, size_is(crename)] LPWSTR rename, >> + [in, out, unique, size_is(crename)] LPWSTR rename, >> [in] ULONG crename); >> HRESULT SubStreamFailure([in] IShellItem *item, >> [in, string] LPCWSTR stream, > According to PSDK existing attributes are correct. Where did you find additional [in] ? It’s in the Windows 8.1 Kit. Without the in midl from Visual Studio 2013 complains. I don’t remember the exact error message.

May 15, 2014

Re: [PATCH 2/5] wined3d: Set palettes on the swapchain.

by Stefan Dösinger

Am 15.05.2014 um 15:27 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > I don't think this kind of thing should be needed. You should be able > to make the palette texture that currently lives in the ARB program > shader backend a property of the wined3d palette, and then presents > can just make sure the palette texture is current. Something similar, > if perhaps slightly more involved, should be possible for the GDI > swapchain with GDI palettes. We have to redraw the front buffer when the palette is changed for palette fading to work. We can’t wait for the next present, nor can we initiate a regular present since we want the front buffer redrawn, and not the back buffer. But yes, the P8 palette should be moved into wined3d_palette. That’s a separate concern IMO.

May 15, 2014

Re: [PATCH 1/5] wined3d: Move get_dc palette updates to ddraw (v2).

by Henri Verbeet

On 15 May 2014 14:33, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +void __cdecl wined3d_palette_apply_to_dc(const struct wined3d_palette *palette, HDC hdc); Can we avoid "Hungarian" in wined3d, please?

May 15, 2014

Re: [PATCH 2/5] wined3d: Set palettes on the swapchain.

by Henri Verbeet

On 15 May 2014 14:33, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/palette.c b/dlls/wined3d/palette.c > index 3f7e2ad..780f068 100644 > --- a/dlls/wined3d/palette.c > +++ b/dlls/wined3d/palette.c > @@ -136,8 +136,8 @@ HRESULT CDECL wined3d_palette_set_entries(struct wined3d_palette *palette, > if (resource->type == WINED3D_RTYPE_SURFACE) > { > struct wined3d_surface *surface = surface_from_resource(resource); > - if (surface->palette == palette) > - surface->surface_ops->surface_realize_palette(surface); > + if (surface->swapchain && surface->swapchain->palette == palette) > + surface->swapchain->swapchain_ops->swapchain_realize_palette(surface->swapchain); > } > } > I don't think this kind of thing should be needed. You should be able to make the palette texture that currently lives in the ARB program shader backend a property of the wined3d palette, and then presents can just make sure the palette texture is current. Something similar, if perhaps slightly more involved, should be possible for the GDI swapchain with GDI palettes.

May 15, 2014

Re: [PATCH 5/5] includes: Fix an in/out annotation in shobjidl.idl.

by Nikolay Sivov

On 5/15/2014 16:33, Stefan Dösinger wrote: > --- > include/shobjidl.idl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/shobjidl.idl b/include/shobjidl.idl > index c9297a8..ae42c2e 100644 > --- a/include/shobjidl.idl > +++ b/include/shobjidl.idl > @@ -3350,7 +3350,7 @@ interface ITransferAdviseSink : IUnknown > HRESULT FileFailure([in] IShellItem *item, > [in, unique, string] LPCWSTR itemname, > [in] HRESULT hr, > - [out, unique, size_is(crename)] LPWSTR rename, > + [in, out, unique, size_is(crename)] LPWSTR rename, > [in] ULONG crename); > HRESULT SubStreamFailure([in] IShellItem *item, > [in, string] LPCWSTR stream, According to PSDK existing attributes are correct. Where did you find additional [in] ?

May 15, 2014

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-14 06:46, schrieb Alistair Leslie-Hughes: > +#define COBJMACROS > +#include "windef.h" > +#include "winbase.h" > +#include "wingdi.h" > +#include "winuser.h" > +#include "objbase.h" > +#include "wine/debug.h" Another thing I did not notice before: Do you need them all? At least wingdi.h seems suspicious, I guess winuser.h shouldn't be needed either - unless dpnet pops up dialogs. > +static HRESULT WINAPI lobbyclient_QueryInterface(IDirectPlay8LobbyClient *iface, REFIID riid, void **ppobj) > ... > + IUnknown_AddRef(iface); > + *ppobj = This; IMO this should be *ppobj = &This->IDirectPlay8LobbyClient_iface. That way it doesn't break if someone uses > +static HRESULT WINAPI lobbyclient_EnumLocalPrograms(IDirectPlay8LobbyClient *iface, GUID* pGuidApplication, BYTE* pEnumData, DWORD* pdwEnumData, DWORD* pdwItems, DWORD flags) You de-hungarified flags, but not the others (pSomePointer, pdwSomePointerToADWord). There are many more cases in the other functions. > +static HRESULT WINAPI lobbyclient_ConnectApplication(IDirectPlay8LobbyClient *iface, DPL_CONNECT_INFO* pdplConnectionInfo, PVOID pvConnectionContext, DPNHANDLE* hApplication, DWORD dwTimeOut, DWORD flags) > +{ > + IDirectPlay8LobbyClientImpl *This = impl_from_IDirectPlay8LobbyClient(iface); > + > + FIXME("(%p)->(%p %p %p %d %x)\n", This, pdplConnectionInfo, pvConnectionContext, hApplication, dwTimeOut, flags); a DWORD is an unsigned value, it should use %u. This applies to dwTimeOut here, but there are other cases in other functions. > +static HRESULT WINAPI lobbyclient_SetConnectionSettings(IDirectPlay8LobbyClient *iface, DPNHANDLE hConnection, const DPL_CONNECTION_SETTINGS* pdplSessionInfo, DWORD flags) > +{ > + IDirectPlay8LobbyClientImpl *This = impl_from_IDirectPlay8LobbyClient(iface); > + > + FIXME("(%p)->(%d %p %x)\n", This, hConnection, pdplSessionInfo, flags); > + > + return E_NOTIMPL; > +} You might want a helper function that prints DPL_CONNECTION_SETTINGS at some point. I'm ok with adding this in a later patch. Don't forget to check for NULL before you print though. > + > + > +static const IDirectPlay8LobbyClientVtbl DirectPlay8LobbiedClient_Vtbl = > +{ Really minor nitpick: There's an extra newline. > +HRESULT DPNET_CreateDirectPlay8LobbyClient(IClassFactory *iface, IUnknown *outer, REFIID riid, void **obj) > +{ > + IDirectPlay8LobbyClientImpl *app; Why is it called "app"? > + HRESULT ret; > + > + TRACE("(%p, %s, %p)\n", outer, debugstr_guid(riid), obj); You forgot to print iface here. Is that intentional? > diff --git a/dlls/dpnet/tests/Makefile.in b/dlls/dpnet/tests/Makefile.in > index f6e45ea..5b97aa1 100644 > +#define WIN32_LEAN_AND_MEAN > +#include <stdio.h> Is this needed? I don't see a function call, but maybe I'm missing something +static HRESULT WINAPI DirectPlayLobbyMessageHandler(PVOID context, DWORD message_id, PVOID buffer) PJUNK There are more PJUNKs in this file. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTdIsTAAoJEN0/YqbEcdMwxkkQAJVt/Y/QT5MIj7VKXsOHwZLJ 2prBQIrzBCPZHxS8EyzEEI008kZ+M2hquPD5Eeinj5L69D4wV5sv6VIFBk2Gz40P SpJaCdE/Srjto+2MQAgRjJ1JMhNCKCWMGg/w+OBRtBs8JM63gHwQNk+ZUQpdl58B OdNpGPbj7Ynlqt+fENUOOxMrbHwToMU1BvgfBogVdWD1P2AnvlFuoRZxSoZuF9Kn 3kloiFs/hv266ZCof1ngrxVuc2uojHWdlev4t2bWYSNoXewIVVRzvtJEvJpveQjq bWzGFe6ZmIhmSJ+2nCnAhXpZjNAv2+o2bdUK1q7EAkUHHv8cb/rTJ+8yX7HiG0UD NxmAtM4EMwLOBRl2yOATR52Q47r195JFv/YOJUHPRW+wL8rIkE/FC6kk4h6zB9/r 5rwLNpWoqagdD9bSJ6LZneRoQzsJ+SMy+8FInnEfDpFZaHRPue4UPFoUNWHQd3f/ ruuIWcWwQwQ7msI8Nr2JgNstGNCO7d6XQfjvJDwqZUZwLihrxEiOa8fVfCRA54Lu hS3esozn+0oQWmSKPm9fw5OA4RIZGY2zLGf3mkFX9BLuBWmKCfxQ5t+1c0nv6Q/f ZSHjUSjem6aLtwq6+48gilS5MsbqsqDQXRE+rEBzFNzcJbQByyd+0yMiYckBajAp H7j+HVl6L6VSGTY9LrMu =S78r -----END PGP SIGNATURE-----

May 15, 2014

Re: audio reset failed

by Pawel Por

> An HTML attachment was scrubbed... > URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20140513/8f5f34ee/at…> I've uploaded the wine log at (37 KB): http://www.sendspace.pl/en/file/294794be77c2a1703e60d94 thanks for your help

May 15, 2014

Support for DirectX 11

by Dyweni - Wine-Devel

Hi, I'd like to know if anyone has an idea on when DirectX 11 would be completed, at least to a point of being able to play DirectX 11 only games? Thanks, Dyweni

May 14, 2014

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 4)

by Matteo Bruni

2014-05-14 17:06 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 14 May 2014 16:12, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> --- >> dlls/d3d9/tests/device.c | 133 ++++++++++++++++++++++++++++++++++++++--------- >> 1 file changed, 107 insertions(+), 26 deletions(-) >> > Unfortunately this still fails for me on Windows. The returned counts > change between runs, which could perhaps be related to the backbuffer > size being larger than the window size. It does seem to reliably pass > when either running the test in fullscreen mode, or changing the > backbuffer size to e.g. 640x480. The former is probably the easier > fix. > Okay, going for fullscreen. >> + ok(data.word[0] == (WORD)expected || broken(!data.word[0]), >> + "Occlusion query returned an unexpected result (0x%.8x).\n", data.dword[0]); >> + if (!data.word[0]) >> + { >> + skip("Occlusion query result looks broken, ignoring returned count.\n"); >> + broken_occlusion = TRUE; >> + } > At 1024x768 for example, "expected" is going to be 0xc0000. Is this > for drivers that always return 0 for occlusion queries, or is this for > the testbot, which IIRC runs at the resolution? If it's really broken, > I think this should also check for "(WORD)expected" being 0, and then > use win_skip() instead of skip(). It's for the testbot, which AFAICS returns 0 regardless of the resolution or fullscreen / windowed mode. I haven't seen other D3D drivers claiming to support occlusion queries and then returning 0 yet. It's a bit unfortunate that 0 is actually the expected result there for 1024x768. I think I'll move the test checking the entire DWORD first and set the broken_occlusion flag based on that. I should definitely use win_skip though.

May 14, 2014

Re: oleaut32: Added debugstr_variant helper for better debug traces.

by Jacek Caban

On 05/14/14 17:09, Michael Stefaniuc wrote: > Hello Jacek, > > On 05/14/2014 04:55 PM, Jacek Caban wrote: >> 0001-oleaut32-Added-debugstr_variant-helper-for-better-deb.diff > wouldn't it be better to make debugstr_variant aka add it to > include/wine/debug.h? VARIANTs are used in a lot more places then just > oleaut32. That's my long term plan for this. I'm not yet sure how to integrate it with debug.h yet, because that would require some sort of dependency on oaidl.h. Anyway, I'd like to have one best copy of debugstr_variant available and oleaut32 seems like the best place to develop and test that since it deals with about all possible VARIANT types. Cheers, Jacek

May 14, 2014

Re: oleaut32: Added debugstr_variant helper for better debug traces.

by Michael Stefaniuc

Hello Jacek, On 05/14/2014 04:55 PM, Jacek Caban wrote: > > 0001-oleaut32-Added-debugstr_variant-helper-for-better-deb.diff wouldn't it be better to make debugstr_variant aka add it to include/wine/debug.h? VARIANTs are used in a lot more places then just oleaut32. > > > diff --git a/dlls/oleaut32/varformat.c b/dlls/oleaut32/varformat.c > index e72a170..0e1c370 100644 > --- a/dlls/oleaut32/varformat.c > +++ b/dlls/oleaut32/varformat.c > @@ -1201,9 +1201,8 @@ static HRESULT VARIANT_FormatNumber(LPVARIANT pVarIn, LPOLESTR lpszFormat, > const BYTE* pToken = NULL; > HRESULT hRes = S_OK; > > - TRACE("(%p->(%s%s),%s,%p,0x%08x,%p,0x%08x)\n", pVarIn, debugstr_VT(pVarIn), > - debugstr_VF(pVarIn), debugstr_w(lpszFormat), rgbTok, dwFlags, pbstrOut, > - lcid); > + TRACE("(%s,%s,%p,0x%08x,%p,0x%08x)\n", debugstr_variant(pVarIn), debugstr_w(lpszFormat), > + rgbTok, dwFlags, pbstrOut, lcid); bye michael

May 14, 2014

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 4)

by Henri Verbeet

On 14 May 2014 16:12, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/d3d9/tests/device.c | 133 ++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 107 insertions(+), 26 deletions(-) > Unfortunately this still fails for me on Windows. The returned counts change between runs, which could perhaps be related to the backbuffer size being larger than the window size. It does seem to reliably pass when either running the test in fullscreen mode, or changing the backbuffer size to e.g. 640x480. The former is probably the easier fix. > + ok(data.word[0] == (WORD)expected || broken(!data.word[0]), > + "Occlusion query returned an unexpected result (0x%.8x).\n", data.dword[0]); > + if (!data.word[0]) > + { > + skip("Occlusion query result looks broken, ignoring returned count.\n"); > + broken_occlusion = TRUE; > + } At 1024x768 for example, "expected" is going to be 0xc0000. Is this for drivers that always return 0 for occlusion queries, or is this for the testbot, which IIRC runs at the resolution? If it's really broken, I think this should also check for "(WORD)expected" being 0, and then use win_skip() instead of skip().

May 14, 2014

Re: [PATCH 3/3] oleacc: Add GetStateText implementation

by Piotr Caban

On 05/14/14 16:13, Nikolay Sivov wrote: >> + ret = GetStateTextW(0, (WCHAR*)&ptr, 0); > Why not use id symbols, instead of magic numbers? It's quite common to use 0 as no-flag (it doesn't change anything now but STATE_SYSTEM_NORMAL is not defined when winuser.h is included). The tests are not really checking any specific flags, they are checking all possible values.

May 14, 2014

Re: [PATCH 3/3] oleacc: Add GetStateText implementation

by Nikolay Sivov

> + ret = GetStateTextW(0, (WCHAR*)&ptr, 0); Why not use id symbols, instead of magic numbers?

May 14, 2014

Re: RFC: "once" FIXME capability

by Michael Stefaniuc

On 05/14/2014 12:05 AM, Erich E. Hoover wrote: > While at LinuxTag Sebastian Lackner, Michael Müller, and I were > chatting with Michael Stefaniuc and Anastasius Focht about the way we > currently implement "one-time FIXME". It was discussed that a more > global approach to this was desired, but that it should have the > following characteristics: Thanks guys for attacking this problem. > 1) It should work with ANSI C compilers (the variadic macro problem) > 2) It should be something that we can disable with a debug channel > (something AF would really appreciate that our current ad-hoc approach > does not support) > 3) It should be expandable to handling a "once per flag" capability > > Toward that end the three of us have put together several proposed > "once" implementations. All three patch-sets are based on variations > of the following trick to allow defining in-place static variables > without any special compiler requirements: > if(1) { \ > static int __wine_debug_once = 0; \ > int __wine_debug_once_temp = __wine_debug_once; \ > if(!__wine_debug_once) __wine_debug_once = 1; \ > if(__wine_debug_once_temp == 0) \ > goto __WINE_LIMIT_LABEL(__LINE__); \ > } else __WINE_LIMIT_LABEL(__LINE__): > > Here are the various approaches: > 1) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_1.tgz > This implementation is a macro (LIMIT_ONCE, LIMIT_FLAG_ONCE) that you > would use to prefix a FIXME/WARN/etc. The feature can be disabled by > enabling the "+nolimit" WINEDEBUG option (patch 3). I do not like this one. While it does look like todo_wine that makes it not look like C. And IMHO the use of TRACE_ONCE / ERR_ONCE and maybe even WARN_ONCE are questionable. > 2) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_2.tgz > This implementation builds onto the existing FIXME to add a FIXME_ONCE > (and FIXME_FLAG_ONCE). The feature can be disabled by enabling the > "+nolimit" WINEDEBUG option (patch 4). > 3) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_3.tgz > This implementation builds onto the existing FIXME to add a FIXME_ONCE > (and FIXME_FLAG_ONCE). The feature can be disabled by enabling the > "nolimit+<channel>" WINEDEBUG option (patch 4). This version benefits > from the ability to turn off limiting on a per-channel basis, which > should make it easier to track down problems when an unrelated debug > channel is also spamming the console. > > We'd love to hear which approach everyone likes the most or any > feedback you might have. I don't mind if 2) or 3) is chosen. I debug too seldom to have an opinion on it. But I'm unsure about the use case for FIXME_FLAG_ONCE. The implementation will need to have anyway code like if (flags & FLAG1) ... if (flags & FLAG2) ... if (flags & FLAG3) ... So that can be done from the start with a FIXME_ONCE for the noisy flags. bye michael

May 14, 2014

Re: [PATCH 4/5] d2d1: Add the ID2D1Bitmap interface.

by Nikolay Sivov

On 5/14/2014 13:09, Henri Verbeet wrote: > On 14 May 2014 10:19, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> Yes, I tested that some time ago, and double-checked just now. Method like >> this: >> >> --- >> HRESULT method([in, optional] float arg, [in] float arg2); >> --- >> >> produces midl error 2090: >> >> .\test_tlb.idl(44) : error MIDL2090 : optional parameters must come after >> required parameters : [ Procedure 'method' ( Interface 'Iiface' ) ] >> > A pointer type would perhaps have been more interesting than float, > but I guess I'll remove the "optional" attributes then. > . > Same happens with pointer types, I just checked.

May 14, 2014

Re: [PATCH 4/5] d2d1: Add the ID2D1Bitmap interface.

by Henri Verbeet

On 14 May 2014 11:03, Jacek Caban <jacek(a)codeweavers.com> wrote: > FWIW, I'm pretty sure it's not. It contains a lot of things that would > be tricky or impossible to do with widl, like C++ default argument > values or overloaded inline functions wrappers around vtbl-based > functions. They even invented a new way of declaring C vtbl structs, > which contain parent's struct in the beginning, instead of duplicating > all functions. > I had noticed those, but assumed it was just something newer midl versions could do, since I don't generally follow what happens with midl very closely.

May 14, 2014

Re: [PATCH 4/5] d2d1: Add the ID2D1Bitmap interface.

by Henri Verbeet

On 14 May 2014 10:19, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Yes, I tested that some time ago, and double-checked just now. Method like > this: > > --- > HRESULT method([in, optional] float arg, [in] float arg2); > --- > > produces midl error 2090: > > .\test_tlb.idl(44) : error MIDL2090 : optional parameters must come after > required parameters : [ Procedure 'method' ( Interface 'Iiface' ) ] > A pointer type would perhaps have been more interesting than float, but I guess I'll remove the "optional" attributes then.

May 14, 2014

Re: [PATCH 4/5] d2d1: Add the ID2D1Bitmap interface.

by Jacek Caban

On 05/14/14 10:05, Henri Verbeet wrote: > The d2d1.h in the PSDK has these annotated with "_In_opt_", and > presumably it's generated with midl. FWIW, I'm pretty sure it's not. It contains a lot of things that would be tricky or impossible to do with widl, like C++ default argument values or overloaded inline functions wrappers around vtbl-based functions. They even invented a new way of declaring C vtbl structs, which contain parent's struct in the beginning, instead of duplicating all functions. I guess that it was decided that having a clean IDL is more important than being compatible with MS in this case. Otherwise mingw-w64 version would be available to port to Wine (some related headers may be still useful): http://repo.or.cz/w/mingw-w64/jacek.git/blob/HEAD:/mingw-w64-headers/includ… Cheers, Jacek

May 14, 2014

Re: [PATCH 4/5] d2d1: Add the ID2D1Bitmap interface.

by Nikolay Sivov

On 5/14/2014 12:05, Henri Verbeet wrote: > On 14 May 2014 08:26, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> I don't think it makes sense to match msdn here regarding [optional] >> attribute, and that's why: >> >> - 'optional' without 'defaultvalue' has no effect on headers, as far as I >> can see; >> - you can't mix 'optional' with required arguments like that, midl will >> refuse to process such idl, >> optional arguments should be at the end of arguments list only; > I didn't try processing this with midl myself, but are you quite sure > about that? Yes, I tested that some time ago, and double-checked just now. Method like this: --- HRESULT method([in, optional] float arg, [in] float arg2); --- produces midl error 2090: .\test_tlb.idl(44) : error MIDL2090 : optional parameters must come after required parameters : [ Procedure 'method' ( Interface 'Iiface' ) ] > The d2d1.h in the PSDK has these annotated with > "_In_opt_", and presumably it's generated with midl. These are manually added I believe, it's a part of so called annotation language or SAL (http://msdn.microsoft.com/en-us/library/ms182032.aspx) It's kind of markers for static analysers, this page says it's available starting VS 2005.

May 14, 2014

Re: [PATCH 4/5] d2d1: Add the ID2D1Bitmap interface.

by Henri Verbeet

On 14 May 2014 08:26, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > I don't think it makes sense to match msdn here regarding [optional] > attribute, and that's why: > > - 'optional' without 'defaultvalue' has no effect on headers, as far as I > can see; > - you can't mix 'optional' with required arguments like that, midl will > refuse to process such idl, > optional arguments should be at the end of arguments list only; I didn't try processing this with midl myself, but are you quite sure about that? The d2d1.h in the PSDK has these annotated with "_In_opt_", and presumably it's generated with midl.

May 14, 2014

Re: [PATCH 4/5] d2d1: Add the ID2D1Bitmap interface.

by Nikolay Sivov

On 5/14/2014 09:56, Henri Verbeet wrote: > +[ > + local, > + object, > + uuid(a2296057-ea42-4099-983b-539fb6505426) > +] > +interface ID2D1Bitmap : ID2D1Image > +{ > + D2D1_SIZE_F GetSize(); > + D2D1_SIZE_U GetPixelSize(); > + D2D1_PIXEL_FORMAT GetPixelFormat(); > + void GetDpi( > + [out] float *dpi_x, > + [out] float *dpi_y > + ); > + HRESULT CopyFromBitmap( > + [in, optional] const D2D1_POINT_2U *dst_point, > + [in] ID2D1Bitmap *bitmap, > + [in, optional] const D2D1_RECT_U *src_rect > + ); > + HRESULT CopyFromRenderTarget( > + [in, optional] const D2D1_POINT_2U *dst_point, > + [in] ID2D1RenderTarget *render_target, > + [in, optional] const D2D1_RECT_U *src_rect > + ); > + HRESULT CopyFromMemory( > + [in, optional] const D2D1_RECT_U *dst_rect, > + [in] const void *src_data, > + [in] UINT32 pitch > + ); > +} > + > I don't think it makes sense to match msdn here regarding [optional] attribute, and that's why: - 'optional' without 'defaultvalue' has no effect on headers, as far as I can see; - you can't mix 'optional' with required arguments like that, midl will refuse to process such idl, optional arguments should be at the end of arguments list only; - msdn says that it only applies to VARIANT and VARIANT* types, not sure about that, probably it's meant to talk about typelib generation only. And we don't need a typelib for d2d1 anyway. It makes sense imo to eventually make widl more midl-compliant adding similar consistency checks, like 'optional' position, also duplicated guids in typelibs come to mind. It's up to you to keep it as it is, just pointing out potential problems.

May 14, 2014

Re: [user32] add a dde test for OEM CP

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=7029 Your paranoid android. === w2000pro (32 bit dde) === dde.c:1797: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 6 dde.c:1820: Test failed: DdeQueryStringA returned wrong string String dde.c:1831: Test failed: DdeQueryStringA returned wrong length 6 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wxppro (32 bit dde) === dde.c:1797: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1820: Test failed: DdeQueryStringA returned wrong string ?" dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wvistau64 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w2008s64 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w7u (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w8 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wvistau64 (64 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w2008s64 (64 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom

May 13, 2014

RFC: "once" FIXME capability

by Erich E. Hoover

While at LinuxTag Sebastian Lackner, Michael Müller, and I were chatting with Michael Stefaniuc and Anastasius Focht about the way we currently implement "one-time FIXME". It was discussed that a more global approach to this was desired, but that it should have the following characteristics: 1) It should work with ANSI C compilers (the variadic macro problem) 2) It should be something that we can disable with a debug channel (something AF would really appreciate that our current ad-hoc approach does not support) 3) It should be expandable to handling a "once per flag" capability Toward that end the three of us have put together several proposed "once" implementations. All three patch-sets are based on variations of the following trick to allow defining in-place static variables without any special compiler requirements: if(1) { \ static int __wine_debug_once = 0; \ int __wine_debug_once_temp = __wine_debug_once; \ if(!__wine_debug_once) __wine_debug_once = 1; \ if(__wine_debug_once_temp == 0) \ goto __WINE_LIMIT_LABEL(__LINE__); \ } else __WINE_LIMIT_LABEL(__LINE__): Here are the various approaches: 1) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_1.tgz This implementation is a macro (LIMIT_ONCE, LIMIT_FLAG_ONCE) that you would use to prefix a FIXME/WARN/etc. The feature can be disabled by enabling the "+nolimit" WINEDEBUG option (patch 3). 2) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_2.tgz This implementation builds onto the existing FIXME to add a FIXME_ONCE (and FIXME_FLAG_ONCE). The feature can be disabled by enabling the "+nolimit" WINEDEBUG option (patch 4). 3) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_3.tgz This implementation builds onto the existing FIXME to add a FIXME_ONCE (and FIXME_FLAG_ONCE). The feature can be disabled by enabling the "nolimit+<channel>" WINEDEBUG option (patch 4). This version benefits from the ability to turn off limiting on a per-channel basis, which should make it easier to track down problems when an unrelated debug channel is also spamming the console. We'd love to hear which approach everyone likes the most or any feedback you might have. Best, Erich

May 13, 2014

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

by John Found

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 13, 2014

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

by Andrew Eikum

On Tue, May 13, 2014 at 09:13:52PM +0300, John Found wrote: > On Tue, 13 May 2014 12:54:26 -0500 > Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > > > > Why? Unless you know what you're doing, only your package manager > > should be touching files in </usr>. > > > > I don't want to use the package manager. From my program I want (on user request) to create or delete .desktop file in "/usr/share/applications" directory. (of course only when running in Linux, in Windows the program will create start menu shortcuts). > 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

May 13, 2014

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

by John Found

On Tue, 13 May 2014 12:54:26 -0500 Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > Why? Unless you know what you're doing, only your package manager > should be touching files in </usr>. > I don't want to use the package manager. From my program I want (on user request) to create or delete .desktop file in "/usr/share/applications" directory. (of course only when running in Linux, in Windows the program will create start menu shortcuts). -- asm32.info <johnfound(a)asm32.info>

May 13, 2014

Re: oleacc: Add GetStateText implementation (try3)

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > +UINT WINAPI GetStateTextW(DWORD state_bit, WCHAR *state_str, UINT state_str_len) > +{ > + DWORD state_id; > + > + TRACE("%x %p %u\n", state_bit, state_str, state_str_len); > + > + state_id = IDS_STATE_MIN; > + while(state_bit) { > + state_id++; > + state_bit /= 2; > + } > + > + if(state_id>=IDS_STATE_MIN && state_id<=IDS_STATE_MAX) { > + UINT ret; > + > + if(state_str) { > + ret = LoadStringW(oleacc_handle, state_id, state_str, state_str_len); > + }else { > + WCHAR tmp; > + ret = LoadStringW(oleacc_handle, state_id, &tmp, 0); > + } > + > + if(!ret && state_str && state_str_len) > + state_str[0] = 0; > + return ret; > + } The id range check doesn't seem very useful. Also it would be worth testing that a 0 length is supposed to return the string pointer the way LoadString does. -- Alexandre Julliard julliard(a)winehq.org

May 13, 2014

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

by Andrew Eikum

On Tue, May 13, 2014 at 07:51:24PM +0300, John Found wrote: > In my program I want to copy some files in the /usr and other system directories. > Why? Unless you know what you're doing, only your package manager should be touching files in </usr>. > Is it possible from WINE program and how? > Sure. You can change the permissions on the directories or run Wine as root. But you have a good chance of destroying your operating system in the process. For example, you could accidentally delete the wrong file. You also open up your system to exploitation by providing more opportunities for an attacker to exploit. > In the FAQ I read: > > >/!\ NEVER run Wine as root! Doing so gives Windows programs (and > >viruses) full access to your computer and every piece of media > >attached to it. Running with sudo also has these same risks but with > >the added bonus of breaking the permissions on your ~/.wine folder > >in the process. If you have run Wine with sudo you need to fix the > >permission errors as described in the next question, and then run > >winecfg to set Wine up again. You should always run Wine as the > >normal user you use to login. > > Is it so important? > Somewhat more information here: http://kb.mediatemple.net/questions/792/An+introduction+to+the+root+user Andrew

May 13, 2014

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

by John Found

In my program I want to copy some files in the /usr and other system directories. Is it possible from WINE program and how? In the FAQ I read: >/!\ NEVER run Wine as root! Doing so gives Windows programs (and >viruses) full access to your computer and every piece of media >attached to it. Running with sudo also has these same risks but with >the added bonus of breaking the permissions on your ~/.wine folder >in the process. If you have run Wine with sudo you need to fix the >permission errors as described in the next question, and then run >winecfg to set Wine up again. You should always run Wine as the >normal user you use to login. Is it so important? -- asm32.info <johnfound(a)asm32.info>

May 13, 2014

Re: [PATCH] ntdll: Pad the FILE_*_DIRECTORY_INFORMATION with zero bytes

by Martin Storsjö

On Tue, 13 May 2014, Alexandre Julliard wrote: > Martin Storsjo <martin(a)martin.st> writes: > >> Instead of memcpying in whatever uninitialized data there was at >> the end of long_nameW, memset the tail of the struct to zero >> instead. >> >> This fixes running cl.exe from MSVC 2013 with native >> msvcr120/msvcp120, fixing bug 35335. >> >> MSVC 2013 (or msvcr120?) seems to use NtQueryDirectoryFile to >> iterate through the headers in directories in the include path, >> and prior to this change, the file names found during iteration >> could get a suffix consisting of an uninitialized WCHAR. > > That doesn't make much sense, given that there may not be space for a > final null, Hmm, that's true > and that your patch doesn't clear the right location > anyway. Oh crap, thanks for noticing > It looks like more investigation is needed. Indeed, I'll try to dig around further // Martin

May 13, 2014

Re: [PATCH] ntdll: Pad the FILE_*_DIRECTORY_INFORMATION with zero bytes

by Alexandre Julliard

Martin Storsjo <martin(a)martin.st> writes: > Instead of memcpying in whatever uninitialized data there was at > the end of long_nameW, memset the tail of the struct to zero > instead. > > This fixes running cl.exe from MSVC 2013 with native > msvcr120/msvcp120, fixing bug 35335. > > MSVC 2013 (or msvcr120?) seems to use NtQueryDirectoryFile to > iterate through the headers in directories in the include path, > and prior to this change, the file names found during iteration > could get a suffix consisting of an uninitialized WCHAR. That doesn't make much sense, given that there may not be space for a final null, and that your patch doesn't clear the right location anyway. It looks like more investigation is needed. -- Alexandre Julliard julliard(a)winehq.org

May 13, 2014

Re: [PATCH 3/5] wined3d: Always store the palette index in the alpha component.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-13 12:28, schrieb Henri Verbeet:> On 13 May 2014 11:14, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >> Not exactly. We load P8 GL textures for the front buffer when >> ARB_fragment_program is unsupported (and thus the format in >> theory is unsupported). So we might end up reading back the >> texture even though the format table doesn't contain data for >> P8. >> > So which internal format would be used to create that texture? internalFormat = GL_RGBA, format = GL_RGBA, type = GL_UNSIGNED_BYTE. This is set in d3dfmt_get_conv. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTcgElAAoJEN0/YqbEcdMwN74P/AmodlWZ+AyfCPSEWmOFM1OY XWuhZC/x250E/NpnaNlMMld/GD1RuhCLENLlklhEqMXtVtC6ppDW1X/5tQaWwkl8 T3p/FGAn0WJ/a/pt2NexxrFZ6KkbLJLDeikyOHgsNOwORxvrQtztZwq5vG0cbxro h/902Ivwq4C5llieu15xFfg8IzrHUaKelD9l7T4rWJTnnom8FbA5iLD6cg+M9x4R 8CeCV7AbJBJ7PblQ5mRRggzNXtwMfBKP4rnv8MFak6IJ3M7WyDmw5ls10GW+2RMH LzUYD6hc245CL+AylXJ7k75W1Fbaf1A463dbccsHvgKZLf8i/9e8QRYnr1/25jm+ k3iMerQmurMKJ6lhH5vBoMKe1iaMhBFFXzI+FWqrTyfFZuNIu3e4lk0ll95CRE/3 ADVQDO1o8ckwi96vdbSniGUw9losejhEaoNEXRoVmxAZMTPZQfR8h27M3Wq90foN sPD7dhaP9WOtsXuYqK0nfnyWhiD4qliWAs3BzByeJF2ypljv4KTHWMixbcJYWMrh /ftMHAdbjhJEORKioYRppXBxMxrj9l39iWOSpyBsfWMaQP5ya2B3Rv0vF3A0WlBB hIJ56ZfMNQJxrXbsoSLatKCiBe+dOTYIhZDd4cZxiI/FEiOnIUzSrfQ7BHv1Jvs9 RglVQMOoRdSjs6TeKZJ0 =dCUx -----END PGP SIGNATURE-----

May 13, 2014

Re: [PATCH 3/5] wined3d: Always store the palette index in the alpha component.

by Henri Verbeet

On 13 May 2014 11:14, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Not exactly. We load P8 GL textures for the front buffer when > ARB_fragment_program is unsupported (and thus the format in theory is > unsupported). So we might end up reading back the texture even though > the format table doesn't contain data for P8. > So which internal format would be used to create that texture?

May 13, 2014

Re: [PATCH 3/5] wined3d: Always store the palette index in the alpha component.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-12 16:44, schrieb Henri Verbeet: > On 12 May 2014 15:12, Stefan Dösinger <stefan(a)codeweavers.com> > wrote: >> @@ -1458,8 +1457,7 @@ static void surface_download_data(struct >> wined3d_surface *surface, const struct int src_pitch = 0; int >> dst_pitch = 0; >> >> - /* In case of P8 the index is stored in the alpha >> component if the primary render target uses P8. */ - if >> (format->id == WINED3DFMT_P8_UINT && >> swapchain_is_p8(surface->resource.device->swapchains[0])) + >> if (format->id == WINED3DFMT_P8_UINT) { gl_format = GL_ALPHA; >> gl_type = GL_UNSIGNED_BYTE; > This branch is pretty pointless, the format / type for > WINED3DFMT_P8_UINT is always GL_ALPHA / GL_UNSIGNED_BYTE. (If > ARB_fragment_program is supported, and the format is supported at > all anyway.) Not exactly. We load P8 GL textures for the front buffer when ARB_fragment_program is unsupported (and thus the format in theory is unsupported). So we might end up reading back the texture even though the format table doesn't contain data for P8. Currently we never read back P8 data due to the ddraw front buffer and because we never load a GL P8 texture for offscreen surfaces (unless this changed at some point and I missed it). This doesn't make testing this easier. (And that's how the goto error thing didn't fail during testing.) I'll see if I can make the P8 line in the GL format table unconditional, that would make things easier. I'd prefer not to detour too much into a P8 GL handling cleanup though. >> + return (BYTE)((color->a * 255.0f) + 0.5f); > So this could just use the table now, right? Right. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTceKHAAoJEN0/YqbEcdMwMLcP/1uDNi+e4e3wenb7mcmxjs3t J7R7w/8ojIT6hLrSghP3d1QaECp+bQxTBVpUfuZ6lSu4sMEPb/kYu50+okFyjlIT dJNkJvNEwyCrSyx7pq6nY8nQRB9YzaqgOExfMEix9X+z1NqzB9JSSInSZu/Cqy3l Wg9oKJwSWSSbfoKzXXKKR/1TAVvE/ReZ2iJaefl+BfH3oSDm1X+s8TYfsqlD4HfM 1IoOB2iuhkyykLUdNmKe8tbzPw5Ql/xVdGeQBc7r4Rgv+O1Rz/qHClTxqapAYbZe n5YKPYSPTiaNjl9yBXAQjm72XlJXwNFMUxO7j+XnWr8EkAmwiLRptiy1sR89vFO4 HGpOX/3U58mRTRKZCAmQIzTiuJFXudLosK2Od+J9ZfzPUhIf0vPAly6evtgDxK/V kV3SGtla/cWS77GVPTWpoiSdY7Vfgzkjn/Ww3QXQ5rg3FBfqCNKbYrPSKU+SG000 Q+u/ul3/ro8lGpFofGRymfTGC4xgyUH5Zl9DM08DNh8JoNcsJCNVyvr06xa6RHV3 IJfjooqdjVGUhCVWbyISNSPnEBWjdRv8U2nge9SHRrNPshBjyRJq6PY8cawbzkAN 4/4JjI4pCcrjh0dKHiiW9iI7PfF6rjZ2k9H611eZJIObzsT1+mnTFdTHa3sfDYGg Ni7LabYC0LThIyZLG4TQ =bPJW -----END PGP SIGNATURE-----

May 13, 2014

Re: dpnet: Stub interface IDirectPlay8LobbyClient

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-13 02:04, schrieb Alistair Leslie-Hughes: > @@ -127,6 +127,7 @@ extern HRESULT DPNET_CreateDirectPlay8Peer(LPCLASSFACTORY iface, LPUNKNOWN punkO > extern HRESULT DPNET_CreateDirectPlay8Address(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > extern HRESULT DPNET_CreateDirectPlay8LobbiedApp(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > extern HRESULT DPNET_CreateDirectPlay8ThreadPool(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > +extern HRESULT DPNET_CreateDirectPlay8LobbyClient(IClassFactory *iface, IUnknown *pUnkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; If you don't use LPJUNK for the iface and UnkOuter (yay :-) ), you might also do it for LPVOID. > +static HRESULT WINAPI lobbyclient_Initialize(IDirectPlay8LobbyClient *iface, PVOID pvUserContext, PFNDPNMESSAGEHANDLER pfn, DWORD dwFlags) No Hungarian notation please (dwFlags, pThisIsAPointer). Also, (L)PJUNK again. > + app = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectPlay8LobbyClientImpl)); > + if (NULL == app) { > + *ppobj = NULL; > + return E_OUTOFMEMORY; > + } Style inconsistency with the rest of the patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTcddPAAoJEN0/YqbEcdMwu2oP/iKSBrRhn/4PoGRTAE6hHQsd 4qwWb7WNS+mczHW+ucVfBogFvPkecpUauHWMpEyND3mYp8kli/2BDqtQrovcvabK h5QRqrP3ToRyIm6VMgaijMx4WlrjsZKHKKzW7/k8TxBTAs25OOaBAUC8ihK1A65s lQVywsqPPHuq4u8LzFjr4xE8s5UyZy5tCPYyDFym0otbiRX9+MQJjztFtC3wd8si Fznv681ZTrpR5m3qvcrMn1Eo2mKFvM1Wbi7W58uO2QTEH6BRiMlfd3A/fqVbhCdZ jiYdcDgUSWugOxIoWtaJNzU/mh3oChyPe+WWFXNoPy5W0/wrJHXUbssAW/s5bX1p wRO6rqmbf27rGCFp57oimJMxb/QJT0o+sU2ZdYHv2hjAX7U1csGU6Z3bUQ/KYLlG AztBJBVkTbe9aoIKhsZx/ISHIQ5GYJyY8KntqBOadrziu/I0kzX0ONtDfTdFzkne RhBSXUFjlKxxm17hXyOEftMsD1tkMn74fChJzFOJUo6v3thkH1IcbMhqwNLvj6++ Om2bO4M5Lw77u/9jR84WpFWUh4wUUqgs+v1/VPpt07QTIhwAERU3CiMt1wlkZFvB cyiWm+a3q/GekR1gyyku31bbkqInDRZENDkRl3FXWS/t1Om38j2JgB45mCMEFKCq HoNMnRF44iY4XWaXwd5M =3BFT -----END PGP SIGNATURE-----

May 13, 2014

Re: audio reset failed

by Pawel Por

>>* I receive periodically the following error popup window: *>>* "Audio Reset Failed: Access violation at address 7BC503AA in module *>>* 'ntdll.dll'. Write of address F818611C" * >What is displaying this message? Wine itself does not contain the >message "Audio Reset Failed." This message is from the application that generates text voice messages using SAPI4 voices. This application works perfectly under wine launched in 32 bit linux. >>* When it occurs the audio hangs up and only the restart of the wine *>>* application helps. * >There is a list of sound-related debug log channels at ><http://wiki.winehq.org/Sound>. Getting a debug log with those >channels set could give us a clue as to what's going wrong. I've upgraded wine to version wine 1.7.18 (Arch Linux). I still receive the message: "Audio Reset Failed: Access violation at address 7BC4D272 in module 'ntdll.dll'. Write of address F82A011C" This time I've run wine with the following debug channels: +tid,+mmdevapi,+winmm,+driver,+msacm,+midi,+dsound,+dsound3d,+dmusic,+mci,+oss,+alsa,+coreaudio. I've attached the log. Please write me if I can provide anything else. Great thanks for your help.

May 13, 2014

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 3)

by Matteo Bruni

2014-05-12 21:28 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 12 May 2014 17:45, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> --- >> dlls/d3d9/tests/device.c | 119 ++++++++++++++++++++++++++++++++++++++--------- >> 1 file changed, 96 insertions(+), 23 deletions(-) >> > This fails here: > > ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p > d3d9_test.exe.so device && touch device.ok > ... > device.c:4609: Test failed: Occlusion query returned an unexpected > result (0x00060300). > device.c:4621: Test failed: Occlusion query returned an unexpected > result (0x00060300). > device.c:4628: Test failed: Occlusion query returned an unexpected > result (0x00060300). > > And on Windows: > > device.c:4609: Test failed: Occlusion query returned an unexpected > result (0xffff052a). > device.c:4621: Test failed: Occlusion query returned an unexpected > result (0x0008052a). > device.c:4628: Test failed: Occlusion query returned an unexpected > result (0x0008052a). > Urgh, sorry, that's really bad... I'll fix and resend.

May 12, 2014

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 3)

by Henri Verbeet

On 12 May 2014 17:45, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/d3d9/tests/device.c | 119 ++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 96 insertions(+), 23 deletions(-) > This fails here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so device && touch device.ok ... device.c:4609: Test failed: Occlusion query returned an unexpected result (0x00060300). device.c:4621: Test failed: Occlusion query returned an unexpected result (0x00060300). device.c:4628: Test failed: Occlusion query returned an unexpected result (0x00060300). And on Windows: device.c:4609: Test failed: Occlusion query returned an unexpected result (0xffff052a). device.c:4621: Test failed: Occlusion query returned an unexpected result (0x0008052a). device.c:4628: Test failed: Occlusion query returned an unexpected result (0x0008052a).

May 12, 2014

Re: testbot/log2revtimes: Add a script to extract the VM revert times from the WineTestBot log and prepare them for analysis.

by Francois Gouget

On Mon, 12 May 2014, Francois Gouget wrote: > --- > > I'm using this script to parse the Engine log and generate a CSV files I > can import in a spreadsheet to generate a graph of the VM revert times. > But having it only on my machine feels wrong. So I propose to put it in > the scripts directory (which feels like a sort of contrib directory) so > it can be used by others. And here is the spreadsheet I import the 'CVS' file into: http://fgouget.free.fr/wtb/vm1-revtime.xls.bz2 And the corresponding graphs: * Since the beginning of times This graph shows all the revert times since the new TestBot was put online. The Y axis is logarithmic so the high revert times don't cause all the low ones to be crunched together. Note that the stratification is caused by the 1 second ganularity of the mesurements. I guess it needs an annotation with the different events. http://fgouget.free.fr/wtb/vm1-revtimes-all.png * Since last April This shows the revert times a bit before the VM1 host crashed and went through reconstruction. This confirms my suspicions: the revert times are not very good :-( http://fgouget.free.fr/wtb/vm1-revtimes-recent.png -- Francois Gouget <fgouget(a)codeweavers.com>

May 12, 2014

Re: [PATCH 5/5] wined3d: Move get_dc palette updates to ddraw.

by Henri Verbeet

On 12 May 2014 15:12, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Note that d3d9 does not support get_dc on D3DFMT_P8. d3d8 and d3d10+ do > not support get_dc at all. That's not strictly true, with d3d10+ you can still get GetDC() / ReleaseDC() through IDXGISurface1. It doesn't give you P8 though. > + if (palette) > + { > + const RGBQUAD *color_table = wined3d_palette_get_rgbquads(palette->wineD3DPalette); > + SetDIBColorTable(*hdc, 0, 256, color_table); > + } ... > +const RGBQUAD * CDECL wined3d_palette_get_rgbquads(const struct wined3d_palette *palette) > +{ > + return palette->colors; > +} That's a pretty terrible interface, it shouldn't be very hard to come up with something better.

May 12, 2014

Re: [PATCH 3/5] wined3d: Always store the palette index in the alpha component.

by Henri Verbeet

On 12 May 2014 15:12, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -1458,8 +1457,7 @@ static void surface_download_data(struct wined3d_surface *surface, const struct > int src_pitch = 0; > int dst_pitch = 0; > > - /* In case of P8 the index is stored in the alpha component if the primary render target uses P8. */ > - if (format->id == WINED3DFMT_P8_UINT && swapchain_is_p8(surface->resource.device->swapchains[0])) > + if (format->id == WINED3DFMT_P8_UINT) > { > gl_format = GL_ALPHA; > gl_type = GL_UNSIGNED_BYTE; This branch is pretty pointless, the format / type for WINED3DFMT_P8_UINT is always GL_ALPHA / GL_UNSIGNED_BYTE. (If ARB_fragment_program is supported, and the format is supported at all anyway.) > @@ -3256,53 +3252,19 @@ static void read_from_framebuffer(struct wined3d_surface *surface, DWORD dst_loc > switch (surface->resource.format->id) > { > case WINED3DFMT_P8_UINT: > - { > - if (swapchain_is_p8(context->swapchain)) > - { > - /* In case of P8 render targets the index is stored in the alpha component */ > - fmt = GL_ALPHA; > - type = GL_UNSIGNED_BYTE; > - mem = data.addr; > - bpp = surface->resource.format->byte_count; > - } > - else > - { > - /* GL can't return palettized data, so read ARGB pixels into a > - * separate block of memory and convert them into palettized format > - * in software. Slow, but if the app means to use palettized render > - * targets and locks it... > - * > - * Use GL_RGB, GL_UNSIGNED_BYTE to read the surface for performance reasons > - * Don't use GL_BGR as in the WINED3DFMT_R8G8B8 case, instead watch out > - * for the color channels when palettizing the colors. > - */ > - fmt = GL_RGB; > - type = GL_UNSIGNED_BYTE; > - pitch *= 3; > - mem = HeapAlloc(GetProcessHeap(), 0, surface->resource.size * 3); > - if (!mem) > - { > - ERR("Out of memory\n"); > - return; > - } > - bpp = surface->resource.format->byte_count * 3; > - } > - } > - break; > + fmt = GL_ALPHA; > + type = GL_UNSIGNED_BYTE; > + break; > > default: > - mem = data.addr; > fmt = surface->resource.format->glFormat; > type = surface->resource.format->glType; > - bpp = surface->resource.format->byte_count; > } Like above. > if (!srcIsUpsideDown) > { > - UINT len; > /* glReadPixels returns the image upside down, and there is no way to prevent this. > - Flip the lines in software */ > - len = surface->resource.width * bpp; > + * Flip the lines in software. > + * TODO: Consider flipping the image in an FBO. */ Possibly, but that would be a decision for surface_load_sysmem(), not read_from_framebuffer(). Note that reading the front buffer isn't particularly fast on Windows either though. > + row = HeapAlloc(GetProcessHeap(), 0, pitch); > + goto error; This looks unintentional. > @@ -3088,38 +3088,7 @@ DWORD wined3d_format_convert_from_float(const struct wined3d_surface *surface, c > } > > if (format->id == WINED3DFMT_P8_UINT) > - { > - const RGBQUAD *e; > - BYTE r, g, b, a; > - > - if (!surface->palette) > - { > - WARN("Surface doesn't have a palette, returning 0.\n"); > - return 0; > - } > - > - r = (BYTE)((color->r * 255.0f) + 0.5f); > - g = (BYTE)((color->g * 255.0f) + 0.5f); > - b = (BYTE)((color->b * 255.0f) + 0.5f); > - a = (BYTE)((color->a * 255.0f) + 0.5f); > - > - e = &surface->palette->colors[a]; > - if (e->rgbRed == r && e->rgbGreen == g && e->rgbBlue == b) > - return a; > - > - WARN("Alpha didn't match index, searching full palette.\n"); > - > - for (i = 0; i < 256; ++i) > - { > - e = &surface->palette->colors[i]; > - if (e->rgbRed == r && e->rgbGreen == g && e->rgbBlue == b) > - return i; > - } > - > - FIXME("Unable to convert color to palette index.\n"); > - > - return 0; > - } > + return (BYTE)((color->a * 255.0f) + 0.5f); So this could just use the table now, right?

May 12, 2014

Re: msvcrt: Don't crash on NULL struct _tm in asctime

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=6983 Your paranoid android. === w2000pro (32 bit time) === time: unhandled exception c0000005 at 78028AD5 === wxppro (32 bit time) === time: unhandled exception c0000005 at 77C4A8B6

May 12, 2014

Re: [PATCH 2/2] oleacc: Add GetStateText implementation (try2)

by Piotr Caban

On 05/12/14 13:53, Nikolay Sivov wrote: > On 5/12/2014 15:40, Piotr Caban wrote: >> On 05/12/14 13:22, Nikolay Sivov wrote: >>>> + state_id = IDS_STATE_MIN; >>>> + while(dwStateBit) { >>>> + state_id++; >>>> + dwStateBit /= 2; >>>> + } >>> >>> It looks like ffs() could be used to do that. >> fss() returns least significant bit. > Yes, why is this a problem? Input state is supposed to have only one bit > set (or none). I've checked how behaves native dll on win7 and implemented it the same way.

May 12, 2014

Re: [PATCH 2/2] oleacc: Add GetStateText implementation (try2)

by Nikolay Sivov

On 5/12/2014 15:40, Piotr Caban wrote: > On 05/12/14 13:22, Nikolay Sivov wrote: >>> + state_id = IDS_STATE_MIN; >>> + while(dwStateBit) { >>> + state_id++; >>> + dwStateBit /= 2; >>> + } >> >> It looks like ffs() could be used to do that. > fss() returns least significant bit. Yes, why is this a problem? Input state is supposed to have only one bit set (or none).

May 12, 2014

Re: [PATCH 2/2] oleacc: Add GetStateText implementation (try2)

by Piotr Caban

On 05/12/14 13:22, Nikolay Sivov wrote: >> + state_id = IDS_STATE_MIN; >> + while(dwStateBit) { >> + state_id++; >> + dwStateBit /= 2; >> + } > > It looks like ffs() could be used to do that. fss() returns least significant bit. Actually it would be > better to find a way to connect those resource ids with actual > STATE_SYSTEM_* symbols, not sure if it's possible to do cleanly. I don't see a clean way of doing it.

May 12, 2014

Re: [PATCH 2/2] oleacc: Add GetStateText implementation (try2)

by Nikolay Sivov

> + state_id = IDS_STATE_MIN; > + while(dwStateBit) { > + state_id++; > + dwStateBit /= 2; > + } It looks like ffs() could be used to do that. Actually it would be better to find a way to connect those resource ids with actual STATE_SYSTEM_* symbols, not sure if it's possible to do cleanly. Also I don't like formatting, especially prefixed names, but that's probably considered to be submitter choice.

May 12, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Henri Verbeet

On 12 May 2014 07:06, Ken Thomases <ken(a)codeweavers.com> wrote: > On May 9, 2014, at 5:34 AM, Alexandre Julliard wrote: >> If multiple users try to set a different format on the window at the >> same time, there's a need to arbitrate that. Your solution is to create >> multiple surfaces, but then this moves the problem to arbitrating which >> surface is the "real" one, i.e. the one that actually puts something on >> the screen. Because in the end there's only one visible window surface. >> >> Obviously under X11 we need to create a new drawable because the format >> is set at creation time, but that doesn't necessarily have to be >> something that wined3d knows about. Conceptually it's still the same >> window surface. > > Actually, I believe it is something that wined3d needs to know about. Commit 4c4552c5a1910a9d5adf8eccff0ac62d89ffe376 introduced a number of regressions. One of them was a performance drop. This drop happens even in the case where nothing else sets a pixel format on the window. The performance problem comes just from wined3d having to check if there _might_ have been contention over the pixel format – if the app might have changed it since the last time wined3d was entered. To avoid that check, each swapchain must know that the OpenGL context it uses is attached to a private drawable that is not shared either with WGL nor with other swapchains. It has to know that once it sets the pixel format on its private drawable, nothing else can change it. (This is the purpose of the hdc_is_private and hdc_has_format flags introduced with commits 27287382 and f3aa4812.) Well, sort of. There can be multiple D3D devices on the same window, and drawing with those should work, although I'm less sure to what extent the output of a such a setup is supposed to be defined. This needs tests. Something similar applies to drawing with WGL and D3D to the same window. The internal wined3d interface is context_acquire()/context_enter() and context_leave(). For the purpose of this discussion, and ignoring the bit about switching a window / drawable to fullscreen mode, a "context" mostly consists of a DC, WGL context, pixel format, and swap interval. What wined3d needs is for context_enter()/context_leave() to be fairly fast, and invisible to anything executing outside of a context_enter()/context_leave() pair. Whether such a set of state is called a "surface", a "context", or something else is perhaps mostly terminology. (Although I should note that "surface" already has a different meaning within wined3d, so in that regard it's perhaps not ideal.) Similarly, wined3d doesn't really care what the driver's implementation of all this looks like.

May 12, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-12 07:06, schrieb Ken Thomases: > Also, it is my understanding – and I hope that Henri, Stefan, or > Matteo will correct me if I'm wrong – that swapchains are > independent sets of backbuffers. An app can have more than one. > Each swapchain has a separate pixel format. The app can issue a > bunch of drawing commands to each and they should be independent. > It can draw a circle in one and a square in the other. It can then > "present" either swapchain and only that swapchain's rendering will > make it to screen. It will show either a circle or a square but > not a circle overlapping a square or the like. Correct. There was a d3d tutorial that demonstrated this, but rendered to two different windows. I cannot find it (many d3d9 tutorials seem to be gone). This is also what happens when multihead d3d is used. > It can then, of course, present the other or not or do it in the > other order. The "can" part is correct, but we don't know exactly what happens because we don't have tests. I'd expect the second Present to overwrite the output of the first. Also note that in d3d the pixelformat is set on the backbuffer, not the window. (present_parameters.BackBufferFormat). There's also the display mode, which specifies a separate pixelformat for the screen (again, not the window). There is a function to check compatibility between screen and backbuffer formats. Usually D3DFMT_A8R8G8B8 is used on backbuffers and compatible with D3DFMT_X8R8G8B8. R5G6B5 is compatible with R5G6B5, and A8R8G8B8 is compatible with A8R8G8B8. > I don't know how wined3d currently deals with the case of multiple > swapchains targeting the same window. That is, how it keeps the > drawing commands and backbuffers of one independent from those of > another. Based on the render target we know where the draw commands go to. For the output see below. > Using separate contexts works to some extent, but only until the > OpenGL command buffer fills, at which point the drawing from one > would be flushed to the backbuffer the contexts share. Wined3d may > ignore this or maybe it uses FBOs or something for the backbuffers > of secondary swapchains. In either case, multiple surfaces offers > an opportunity to improve the status quo. We usually use FBOs to render to backbuffers. This can be disabled by the user (HKCU/Software/Wine/Direct3D/AlwaysOffscreen, or by setting OffScreenRendering = backbuffer), or when FBOs are not available. This legacy mode is still used on some older drivers. If two contexts share a window and we're not rendering to an FBO the draw commands will interfere with each other. Currently we're using this effect for multithreading support (when the application uses one swapchain to render to one window, but renders from different threads.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTcILFAAoJEN0/YqbEcdMwCUIP/28XVdeE1nODKnI3iCqGkdWf 1jcGjOHDUPSeO/vZxSUkVUaCYj+QOsh+pNHZ3B+w+YDeByDjAYEzXiDTQCp8wpFF 2U9Kc3o0BNmSl3Fg44kv+UKa3IUqd0YNw7jvZBPoQGse6Tk/4av0+lbFsx004bst kJLqVJk1ecdcmDp4v0MpSgEB56usiw/Wxarl6I6xMiw3kqqcse+0u/ZZO48ygkqS JRfp/OCBmoGwzch1+KIBAkxnyPBGFCsJigMYFf3Nuu8YgIH6T1E+bCBwj9YkaPIf CKUmTStSZGQQSTWiBsQE5X4QHGFyUoSOjmyMvqY1YnIx9KSLeK6+DbDwbQ4trpSg hfWh6PXUsXTLix1ISD721HkRW8vrKrhAFVi17+q8CTIXu+3C1nyfVZzf46LzTTaC bBob4JgH1tcUJXeagCmNEYcZhPj/ZqQK9Jkg6fypKzN1SMVYpW1Qive2Cbsl1qy2 Uh5hjIj7sA+05ldQhr8HBWKoV+bdlqVzxw0J+tsU8BeZU6CadF4HSq6402L9ytM0 WK/Nes2Nue+S0YBcXj+gUOq1eAWa5WT5n11x0h7yht83YW2ldJl0wfnAPlBQizGL CyqevaKJvPbr9/6TDyzioGHP7GhBsOxS2Y9azwm5+5uDX5N8e845DrkTqRkbpYPd yoCfloLQBaUnz/Pm473H =E60k -----END PGP SIGNATURE-----

May 12, 2014

Re: [PATCH] gdi32: Add MS Shell Dlg tests

by Alex Henrie

2014-05-11 23:54 GMT-06:00 Dmitry Timoshkov <dmitry(a)baikal.ru>: > Please add the tests for other font enumeration APIs (the may behave > differently), and the tests with NULL face name (according to my tests > in that case MS Shell Dlg won't be enumerated). Since that would clutter > existing tests I'd suggest to move the new one into separate body and > name it appropriately. You can if you want. I've hit a dead end trying to fix this bug and I am not currently motivated to put any more effort into it. -Alex

May 12, 2014

Re: [PATCH] gdi32: Add MS Shell Dlg tests

by Dmitry Timoshkov

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > + memset(&efnd, 0, sizeof(efnd)); > + strcpy(lf.lfFaceName, "MS Shell Dlg"); > + ret = EnumFontFamiliesExA(hdc, &lf, enum_fullname_data_proc, (LPARAM)&efnd, 0); > + ok(ret, "font MS Shell Dlg is not enumerated\n"); > + ret = strcmp((char*)efnd.elf[0].elfLogFont.lfFaceName, "MS Shell Dlg"); > + todo_wine ok(!ret, "expected MS Shell Dlg got %s\n", efnd.elf[0].elfLogFont.lfFaceName); > + ret = strcmp((char*)efnd.elf[0].elfFullName, "MS Shell Dlg"); > + ok(ret, "did not expect MS Shell Dlg\n"); Please add the tests for other font enumeration APIs (the may behave differently), and the tests with NULL face name (according to my tests in that case MS Shell Dlg won't be enumerated). Since that would clutter existing tests I'd suggest to move the new one into separate body and name it appropriately. -- Dmitry.

May 12, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Ken Thomases

On May 9, 2014, at 5:34 AM, Alexandre Julliard wrote: > Ken Thomases <ken(a)codeweavers.com> writes: > >> On May 8, 2014, at 3:18 AM, Alexandre Julliard wrote: >>> It can't be using an old surface unless you introduced the concept of >>> multiple surfaces in the first place... >> >> You don't even acknowledge the need for multiple surfaces _serially_? >> That wined3d might create a surface on a virgin window and then >> destroy it, and then later create another one? > > It's probably a question of terminology. To my mind, there is one place > in the window where you can render stuff, using a specific pixel format. > > If multiple users try to set a different format on the window at the > same time, there's a need to arbitrate that. Your solution is to create > multiple surfaces, but then this moves the problem to arbitrating which > surface is the "real" one, i.e. the one that actually puts something on > the screen. Because in the end there's only one visible window surface. > > Obviously under X11 we need to create a new drawable because the format > is set at creation time, but that doesn't necessarily have to be > something that wined3d knows about. Conceptually it's still the same > window surface. Actually, I believe it is something that wined3d needs to know about. Commit 4c4552c5a1910a9d5adf8eccff0ac62d89ffe376 introduced a number of regressions. One of them was a performance drop. This drop happens even in the case where nothing else sets a pixel format on the window. The performance problem comes just from wined3d having to check if there _might_ have been contention over the pixel format – if the app might have changed it since the last time wined3d was entered. To avoid that check, each swapchain must know that the OpenGL context it uses is attached to a private drawable that is not shared either with WGL nor with other swapchains. It has to know that once it sets the pixel format on its private drawable, nothing else can change it. (This is the purpose of the hdc_is_private and hdc_has_format flags introduced with commits 27287382 and f3aa4812.) Also, it is my understanding – and I hope that Henri, Stefan, or Matteo will correct me if I'm wrong – that swapchains are independent sets of backbuffers. An app can have more than one. Each swapchain has a separate pixel format. The app can issue a bunch of drawing commands to each and they should be independent. It can draw a circle in one and a square in the other. It can then "present" either swapchain and only that swapchain's rendering will make it to screen. It will show either a circle or a square but not a circle overlapping a square or the like. It can then, of course, present the other or not or do it in the other order. The point is, multiple surfaces is a natural fit with D3D's model. The swapchain which was most recently presented is the visible one. Which means that the X11 driver would have to order a drawable front during wglSwapBuffers() (not when the context is made current, which is what I said in a previous email). I don't know how wined3d currently deals with the case of multiple swapchains targeting the same window. That is, how it keeps the drawing commands and backbuffers of one independent from those of another. Using separate contexts works to some extent, but only until the OpenGL command buffer fills, at which point the drawing from one would be flushed to the backbuffer the contexts share. Wined3d may ignore this or maybe it uses FBOs or something for the backbuffers of secondary swapchains. In either case, multiple surfaces offers an opportunity to improve the status quo. I also want to say that I already tried to solve the issues entirely within the X11 driver. For example, I tried an approach where the X11 driver puts off realizing a change of the window pixel format until it's absolutely necessary <http://bugs.winehq.org/show_bug.cgi?id=35718#c32>. It didn't really solve the problem because wined3d needs to restore the thread's current WGL context each time it returns from a call, and that requires that the window pixel format be restored for real. I think the fundamental nature of the problem is unavoidable so long as wined3d uses WGL/OpenGL, which relies on implicit thread state. When wined3d issues OpenGL commands, that state needs to be wined3d's but when the app issues its commands, it needs to be the app's. There's no getting around "thrashing" the current context because of that, but the pixel format thrashing can be avoided by using separate surfaces. And because this thread state model extends all the way from the driver through WGL to wined3d, there's no avoiding exposing the existence of those surfaces to wined3d. -Ken

May 12, 2014

Re: comctl32/listview: Fix custom draw stage sequence

by Nikolay Sivov

On 5/11/2014 21:44, 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=6975 > > Your paranoid android. > > > === w2000pro (32 bit listview) === > listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 > listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 > > These are existing failures.

May 11, 2014

Re: [PATCH] gdi32: Add MS Shell Dlg tests

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=6979 Your paranoid android. === wvistau64 (32 bit font) === The test timed out === wvistau64 (64 bit font) === The test timed out

May 11, 2014

Re: Federal circuit reverses ruling on Java APIs

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I recommend to read Bradley Kuhn's comment on the ruling: http://ebb.org/bkuhn/blog/2014/05/10/oracle-google.html . I think his suggestion to read the original ruling in full is a good one too, and since I haven't done so yet I won't opine on it further. Cheers, Stefan Am 2014-05-10 19:11, schrieb Alex M: > https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracle-v-google-fede… > > > > This is very worrying news. What are the implications for WINE if > this manages to go through entirely? > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTb8mFAAoJEN0/YqbEcdMwKkwP/0Ax/cF118//HgkSY75470AD LQiLxMZVAAxsWRNeAwMG4th4fdbDJj9msvJrlWVijM7yThk6yLtgEwNxhX+uEIbc MFzt277qAaJ+Ho+EJcrj37pU7v0a5Md5creCLZ378IzHrbYXk7zENVrl74kNTpuG s4QkINZjGmVZ8d/75k8nJjUSzHxMeEk/eMvGDz34GgCVEBDU+Wdn8O21fQEtjGkA FS40mc3zXnYBQtHilDy1FAqlljfkCsm9ojwG5dVjCQeNZvSMK+cKoLjJ6OdnK6XE CkOkCk/o/wouwJr7sB1S7AsSBcyEYWWerxE2ZwpImURJyhSIxT/xa/EZTnKUQNLS wzfCo1djNh/LDI6YyaRCf0RHx0buvUv8crG+j5x5kYvwzHMM9quHerZfmSsklcCd ZAMXZ3Xg9PYhSjFQhnw7cJd3dQ7+GU4SOdKmCrYGPF/Uo7vmz3+Y2Ncta6VXEsIR xWTmbqwcO33Fc7BX6F6w72e0qyN+HRxw/Yu/PhAXsG7P6A4shEr3DWBXWi0bD9Rb iPzmVBZBPU4RqQ8VHj93b4Q55Odk2d+Sy0MqDjy/zBUjpDFTdeltgco/VkbcM1Vu PZQqjm9UPhCwagddvtMRnD0EjEiw5cjjYH48Y68dnVwBnnqH5oOFNrwCiF0U4T5O 2meN8XVIVbn6wgtLXVuq =zrfI -----END PGP SIGNATURE-----

May 11, 2014

Re: comctl32/listview: Fix custom draw stage sequence

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=6975 Your paranoid android. === w2000pro (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wxppro (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w8 (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (64 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

May 11, 2014

Re: Testbot

by Nikolay Sivov

On 5/11/2014 21:33, Mikael Ståldal wrote: > Usually it make sense to run the test suite anyway, to catch > regressions. Changes in the regular code might break an existing test. This is true however for some parts of Wine, like widl for example. > > > On 2014-05-11 19:20, Nikolay Sivov wrote: >> On 5/11/2014 21:17, Mikael Ståldal wrote: >>> I see in the patch list http://source.winehq.org/patches/ that the >>> testbot run on some patches, but not all. What determine if it run or >>> not? >>> >>> >>> >> If a patch doesn't contain test file changes there's nothing for testbot >> to do, for Windows VMs I mean. >> >> > >

May 11, 2014

Re: Testbot

by Nikolay Sivov

On 5/11/2014 21:33, Mikael Ståldal wrote: > Usually it make sense to run the test suite anyway, to catch > regressions. Changes in the regular code might break an existing test. No, wine code changes are irrelevant when you run a test on Windows. Testbot currently runs on Windows VMs only. > > > On 2014-05-11 19:20, Nikolay Sivov wrote: >> On 5/11/2014 21:17, Mikael Ståldal wrote: >>> I see in the patch list http://source.winehq.org/patches/ that the >>> testbot run on some patches, but not all. What determine if it run or >>> not? >>> >>> >>> >> If a patch doesn't contain test file changes there's nothing for testbot >> to do, for Windows VMs I mean. >> >> > >

May 11, 2014

Re: Testbot

by Mikael Ståldal

Usually it make sense to run the test suite anyway, to catch regressions. Changes in the regular code might break an existing test. On 2014-05-11 19:20, Nikolay Sivov wrote: > On 5/11/2014 21:17, Mikael Ståldal wrote: >> I see in the patch list http://source.winehq.org/patches/ that the >> testbot run on some patches, but not all. What determine if it run or >> not? >> >> >> > If a patch doesn't contain test file changes there's nothing for testbot > to do, for Windows VMs I mean. > >

May 11, 2014

Re: Testbot

by Nikolay Sivov

On 5/11/2014 21:17, Mikael Ståldal wrote: > I see in the patch list http://source.winehq.org/patches/ that the > testbot run on some patches, but not all. What determine if it run or > not? > > > If a patch doesn't contain test file changes there's nothing for testbot to do, for Windows VMs I mean.

May 11, 2014

Testbot

by Mikael Ståldal

I see in the patch list http://source.winehq.org/patches/ that the testbot run on some patches, but not all. What determine if it run or not?

May 11, 2014

Re: Federal circuit reverses ruling on Java APIs

by Michael Stefaniuc

On 05/10/2014 07:11 PM, Alex M wrote: > https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracle-v-google-fede… > > > This is very worrying news. What are the implications for WINE if this > manages to go through entirely? Afair Android has generated them from the Java headers. Wine on the other hand has written them from scratch. Wine headers are a lot cleaner and nicer than the SDK ones. bye michael

May 11, 2014

Re: Federal circuit reverses ruling on Java APIs

by Shachar Shemesh

On 10/05/14 20:11, Alex M wrote: > https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracle-v-google-fede… > > > This is very worrying news. What are the implications for WINE if this > manages to go through entirely? > First of all, it ain't over. The circuit said that the question of inter-operability is a question of fair-use, not copyrightability. In that sense, it's a major set-back to the entire industry for a bunch of reasons, but does not immediately affect wine. The other aspect is that if this goes through the implications for anyone who is trying to interface with GPL software will be as severe. I'm not sure MS will be a great beneficiary. Whether that will affect its stance on Wine is still debatable. Shachar

May 10, 2014

Federal circuit reverses ruling on Java APIs

by Alex M

https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracle-v-google-fede… This is very worrying news. What are the implications for WINE if this manages to go through entirely? -- Malo periculosam libertatem quam quietum servitium.

May 10, 2014

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

by Zhenbo Li

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

May 9, 2014

Re: ced401: add initial support

by André Hentschel

Am 09.05.2014 14:42, schrieb Alois Schlögl: > The attached patch includes the stubs for the ced1401 driver dll. > > This is a starting point to support ced1401/spike2/signal software. > > It's my first patch submission to wine - feedback welcome. > I also doubt that this wrapper get's included as it's too special. But when you finished your work, could you please share a link to github or somewhere with me. (I'm collecting wrappers for Wine on my website: http://dawncrow.de/wine/index.html )

May 9, 2014

Re: gdi32: Report unsubstituted font face names. (try 5)

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > I kept the full name tests, but now they make sure that the full name > is a SUBSTITUTED font name. It breaks the gdiplus tests: ../../../tools/runtest -q -P wine -T ../../.. -M gdiplus.dll -p gdiplus_test.exe.so font && touch font.ok font.c:759: Test failed: wrong face name MS Shell Dlg font.c:770: Test failed: wrong face name MS Shell Dlg make: *** [font.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

May 9, 2014

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

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=6958 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 9, 2014

Re: wininet: Fix InternetGetConnectedStateEx[A|W] (try 2, resend)

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > Hi, thanks for the review =) > I'm not at home so I can't check it more carefully but judging by the > patch I think this is the test: > > + buffer[0] = 0xDE; > + res = pInternetGetConnectedStateExA(&flags, buffer, 1, 0); > ok(res == TRUE, "Expected TRUE, got %d\n", res); > ok(flags, "Expected at least one flag set\n"); > ok(strlen(buffer) == 0, "Expected 0 bytes, got %u\n", lstrlenA(buffer)); > > It sets some content inside the buffer and then ensures the string is > zero sized after returning. As far as I remember if you comment the > line "*lpszConnectionName = '\0'" one or more tests will result in > error. I can do a more careful research at the weekend if you wish. It would need to use a size larger than 1 to confirm that the string is supposed to be cleared instead of simply truncated. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2014

Re: wininet: Fix InternetGetConnectedStateEx[A|W] (try 2, resend)

by Bruno Jesus

On Fri, May 9, 2014 at 11:29 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Bruno Jesus <00cpxxx(a)gmail.com> writes: > >> @@ -1241,8 +1250,9 @@ BOOL WINAPI InternetGetConnectedStateExA(LPDWORD lpdwStatus, LPSTR lpszConnectio >> dwReserved); >> if (rc && lpwszConnectionName) >> { >> - WideCharToMultiByte(CP_ACP,0,lpwszConnectionName,-1,lpszConnectionName, >> - dwNameLen, NULL, NULL); >> + if (WideCharToMultiByte(CP_ACP,0,lpwszConnectionName,-1,lpszConnectionName, >> + dwNameLen, NULL, NULL) == 0) >> + *lpszConnectionName = '\0'; > > That doesn't seem to match what the W function does, and I don't see any > tests for that case. Hi, thanks for the review =) I'm not at home so I can't check it more carefully but judging by the patch I think this is the test: + buffer[0] = 0xDE; + res = pInternetGetConnectedStateExA(&flags, buffer, 1, 0); ok(res == TRUE, "Expected TRUE, got %d\n", res); ok(flags, "Expected at least one flag set\n"); ok(strlen(buffer) == 0, "Expected 0 bytes, got %u\n", lstrlenA(buffer)); It sets some content inside the buffer and then ensures the string is zero sized after returning. As far as I remember if you comment the line "*lpszConnectionName = '\0'" one or more tests will result in error. I can do a more careful research at the weekend if you wish. Best wishes, Bruno

May 9, 2014