January 2015 - Wine-devel - list.winehq.org

Re: [PATCH 2/5] wined3d: Handle the SM4 SV_POSITION pixel shader input semantic in the GLSL shader backend.
by Stefan Dösinger 19 Jan '15

19 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-01-19 um 13:44 schrieb Henri Verbeet: > This is (mostly) equivalent to the vPos register in SM3. > ... > + if (!strcmp(semantic_name, "SV_POSITION")) > + shader_addline(buffer, "ps_in[%u]%s = vpos%s;\n", > + shader->u.ps.input_reg_map[i], reg_mask, reg_mask); The vpos variable has the d3d9 0.5 pixel offset applied, which to my knowledge is not correct for d3d10. Is this intentional? (I guess yes, either for simplicity to make patch 3 work and / or because we're still adding the offset on the vertex side even in d3d10.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUvQcWAAoJEN0/YqbEcdMwutkP/irVdyJWjIwnAnwgltjehO9A Vp4CZneYnbnAP/SJjhvsY7RwhHdUelzhv8wX8m9q0Y92jPMtvTt6OMAdppxATSOY Bo70j7fpaMJbRG/GCrDSCp3geyzN/1p6CQu5JfahVuSBOGg7EIDdR0OA4hA9aDEE R/pzerlOuvIY8vMOejYk99wBWEOLWJUcWNfrRq30ASnyIK6wcBhr3QLdcRI8/57m +MtFG53+R6wGdRQih1PfmDP4CJnfhr33TQgKod9ezYGyNcS8X/rRTq3mE0uqq3TJ 7+S4A21o7j2nEBlEWlwt6op7Yg2xhMan5znQU/MwREFaGGPWdapNpl1NxpWM/wp0 zm992j3TgpCqHLCW0u8Z5t2fClWuyU8IcZWsLql2FVZa3DvG6QOeXS3oEVlw5jxu fU9iMiJeh7Aywt8tvro4kG5opA2CCUFUJu1Cf7FBQpAUtHYqY5B1vm67fzeMfLt5 C2XC6L79dK0L0YenFqrGWQOU5/u4skW5Cgi5Yt5AKx0Ifk4gTrPq1/pSCeEFUS+T H2ZjZCqCYYp7NCWSXQSpBSFcVE7bURfJNBC3j9TTBCoT/pCOTKr8vv6Dqn0pjxku 6hdmAEaW7vUKr6ucUopgDNQ6E+aCdaofUMqJuhlOAOL8arthwIPZbO2hb8lLTSBq Smb3+zJL2d2YBZZelE4f =0cAR -----END PGP SIGNATURE-----

2 1

ole32:fix CoWaitForMultipleHandles cause RPC hang (try 2)
by Changhui Liu 19 Jan '15

19 Jan '15

Dear Sebastian: I commit a new ole32 path last month at here: http://source.winehq.org/patches/data/108302. Could you help me review it again when you are free? Thank you. ------------------ Regards, Changhui.

1 0

Re: [PATCH (try 3) 2/2] dpvoice: Turn GetCompressionTypes into a semi-stub.
by Stefan Dösinger 18 Jan '15

18 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-01-16 um 08:44 schrieb Alex Henrie: > Star Trek Armada II needs GetCompressionTypes to return at least > one value, see https://bugs.winehq.org/show_bug.cgi?id=29238 Is the game happy if you return DV_OK and set *pdwNumElements = 0? > MS-PCM is guaranteed to be present on Windows XP, and it's already > implemented in Wine, so advertising this codec shouldn't cause any > trouble. Even though we have the codec we probably don't have the dpvoice infrastructure to hook up a dpvoice client to the codec, right? That's not necessarily a reason to reject the semi-stub though. > +extern HRESULT DPVOICE_GetCompressionTypes(DVCOMPRESSIONINFO > *pData, DWORD *pdwDataSize, DWORD *pdwNumElements, DWORD dwFlags) > DECLSPEC_HIDDEN; Please avoid hungarian notation names (dwThisIsAdWord, *pThisIsAPointer). > + string_loc = (LPWSTR)((char*)pData + sizeof(pcm_type)); + > memcpy(pData, &pcm_type, sizeof(pcm_type)); + memcpy(string_loc, > pcm_name, sizeof(pcm_name)); + pData->lpszName = string_loc; I think there should be a nicer way to do this. I didn't test this with the compiler, but I guess you can do something like this: struct { DVCOMPRESSIONINFO info; const WCHAR name[]; } codec = { {80, {0x8de12fd4,0x7cb3,0x48ce {0xa7,0xe8,0x9c,0x47,0xa2,0x2e,0x8a,0xc5}}, &codec.name, NULL, 0, 64000}}, {'M','S','-','P','C','M',' ','6','4',' ','k','b','i','t','/','s',0}; }; ... memcpy(pData, codec, sizeof(codec)); I don't know how well the variable-size array at the end of the struct works. It also won't easily work for more than one element. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUuUN7AAoJEN0/YqbEcdMwFwcP/iSIxX72VcW9TSqbWHnq1Pi6 7Yv9zcL3h/3Mx0rERFiaT15Tmz7+YNyKfngR6kZwM7ms5usqePHCW1y1dT7ImCfM gSAgd5WBTKuk5qpr0k2zLgl4O3TVJn4zTP8wKNa+lwGDJgY7d3ThcgDd/LI6kkiU KI2Uv+jyh00Co2G6egmhlZDfwWo3dI/b+7fndC1jnYCcyIIxjLywdiQ80SCi3IgB sktBaQW7mvzzQDtMKgwR/BNUSze6AQeWQ5+xmWivIm4jsPGETmr3r0VnRtxxMduA LzXJJewnGojJoaQ1dsjsXJJ+S+3rKCd5cKrbnlyFXJ2pqHGrBdkQwbFTWse+8Tsf +Au00otO85InuwenrvKutN92c4pP8hfyxAQbKJUjVCnD5ppMDXkRrx0xKfAy7SWB FpQuO6KLeWMotDYcC21kwY3jGLAxKOWGh02p7S5AUIlnZ0m1kJ3PK1DxhomRHYax 4pgQx0jb/MITw1/L5hJ8KlNcucLJxC2FBGpgRC32LAUHMVcNurs6bHQbgbl9UKUS zH4gOA7PzNTGG3G3To/IqmayhmzNMLk/b0XusIGKF1Ao3uyU3Yw+5RuzPlGaKOkT cAhRIl5Ujbcjt8JKgtdq4x1VeGMutHlePhPuUpgZX98n+/Bgk9uZ5rScVLW1ELGW XQ6zfKUWW2qirySBqy+A =StHs -----END PGP SIGNATURE-----

2 4

Re: [2/3] msi: Open 32-bit component registry keys with KEY_WOW64_32KEY flag. (try 2)
by Marvin 18 Jan '15

18 Jan '15

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=11200 Your paranoid android. === wxppro (32 bit install) === The test timed out

1 0

Re: user32: Allocate memory based on HICON instead of DWORD to fix 64 bit problems
by Stefan Dösinger 18 Jan '15

18 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-01-17 um 23:51 schrieb Bruno Jesus: > - frames = HeapAlloc( GetProcessHeap(), 0, sizeof(DWORD)*header.num_frames ); > + frames = HeapAlloc( GetProcessHeap(), 0, sizeof(HICON)*header.num_frames ); sizeof(*frames)*header.num_frames would be better. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUu45mAAoJEN0/YqbEcdMwtrkP/2a+96GGXGtHq4g8P+UYBWjc AxGPcxAq5ND++lDYK22TyY1XC5ZXjByvxYOcrMsb4yhYRfJbPVgKx6gY+ALe6aog ilAFF0waM7kRPxXcNotcE9ZlXQpKAfLvTQajJSH9e1MgYUfcMbaSS8eSJMSNslcM Sa9rDDaeabp6wNymbvKOtpTjIOS767Jz9m7xCw+NtA9FFIHwrZsZ/LxeWiDQxDmR STNGPoEELt+vvAPB0K2Rnn/5AZrjekdYy0cUR78htsEqGIodBO86kD6K20r3cQ5s 7cmiAj8lHtUJ/6FPB54DynmSpNiPiXOlPc0dSL+ujsEEGJ/rI8wFtM/kCIzEe6GY 6sv881G8mXX8AMDgOg+O3Tlo0qprfWvVmkTE5ASGXGsdck04yPO4UfKvOon3IaXI dyrjRkBK8w2X63L5R39BzmKvtcZgKQj+r4M8is8Rn4hk2iAmz4ejFYlzcDVCJ0Zg W/kurjSSroUcOKsjcjMuB738W43mgHhh9xdbO/06FOYXULXOQVDFO7x19NI2ilpi VK5x6XRg4OxARuFU6tuSqll1a9PtNgIuzWc+BHDOS9Htc5WVpDTQvPUPtVif/6L/ 6MZbDeC9rm+IAytmXvpFDU+C6c2/axUMCfwB9idAKFaTKI5nemKLCeEPLiq1nVUh 5xulwJdbSnxoi7M72Vf6 =Tg70 -----END PGP SIGNATURE-----

1 0

Re: [PATCH (try 3) 2/2] dpvoice: Turn GetCompressionTypes into a semi-stub.
by Stefan Dösinger 16 Jan '15

16 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-01-16 um 08:44 schrieb Alex Henrie: > Star Trek Armada II needs GetCompressionTypes to return at least > one value, see https://bugs.winehq.org/show_bug.cgi?id=29238 Is the game happy if you return DV_OK and set *pdwNumElements = 0? > MS-PCM is guaranteed to be present on Windows XP, and it's already > implemented in Wine, so advertising this codec shouldn't cause any > trouble. Even though we have the codec we probably don't have the dpvoice infrastructure to hook up a dpvoice client to the codec, right? That's not necessarily a reason to reject the semi-stub though. > +extern HRESULT DPVOICE_GetCompressionTypes(DVCOMPRESSIONINFO > *pData, DWORD *pdwDataSize, DWORD *pdwNumElements, DWORD dwFlags) > DECLSPEC_HIDDEN; Please avoid hungarian notation names (dwThisIsAdWord, *pThisIsAPointer). > + string_loc = (LPWSTR)((char*)pData + sizeof(pcm_type)); + > memcpy(pData, &pcm_type, sizeof(pcm_type)); + memcpy(string_loc, > pcm_name, sizeof(pcm_name)); + pData->lpszName = string_loc; I think there should be a nicer way to do this. I didn't test this with the compiler, but I guess you can do something like this: struct { DVCOMPRESSIONINFO info; const WCHAR name[]; } codec = { {80, {0x8de12fd4,0x7cb3,0x48ce {0xa7,0xe8,0x9c,0x47,0xa2,0x2e,0x8a,0xc5}}, &codec.name, NULL, 0, 64000}}, {'M','S','-','P','C','M',' ','6','4',' ','k','b','i','t','/','s',0}; }; ... memcpy(pData, codec, sizeof(codec)); I don't know how well the variable-size array at the end of the struct works. It also won't easily work for more than one element. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUuUNyAAoJEN0/YqbEcdMwb/wP/3QuWJc0dQtO7tcPo/alre6S ASLeDH+5+F+LBTwFBnlNJhkizO7PtpRUCqH6k0fxGtSprsNMnyu3T/KqBPTku8kx XUhS4jNcV6lDzSvruKEHx4m+Lrpgs/onSK4pLUa9cP0FvZgKpLA+XTJtXgOuX40K 31/TOW/DRq6gXeGE11Oxz97Vx2mILfhmLfhtIeTRA4RpkGyMlWlKST9l3xyNn0dt ystZG62OWVnljq/g2U8Ce4n+zz97Hlxzkk7uB4ZI2/m8/EBdGEhOgGTsUdEulu6P cChWJqzJOo8zxJr+RXeWnQN38V2yKW6CwxnIQ90INKd1WV1NvGZfiYDMXdUBMrYm XrQ4A6xaLwfCIVgzJ1wyPDGYFb92sOr34ly3v/fTuQNb2DnamdgENhw/Gj9APsIS ErfHiTgoWGbh77WuRm2GC/GfxpOsK2lpnO2uwXcrWXyYy8u2GP9zEhHLl3ohcG2+ dEL7Q0MABEitbGQJ4qTbpNffFIbLwWdKcKEP67gBFM2T937/4z5ISce0WlI6SBHX l+yXKK/vSJ1U+/B2i+fsbyFOr0rQMCIt1k6uAOlnPM29uwZOjJtG3gCp6BbK+vqw Jc2yGJl3PdAjwfHuHGTakWx6EflZLLGqqcLXWnfs3gzgExHnbHGZaOdKDYx+qsqz cEUAmwJUxAcp6cMGiuQX =ue9K -----END PGP SIGNATURE-----

1 0

Re: [PATCH (try 2) 1/2] dpvoice/tests: Add GetCompressionTypes tests.
by Stefan Dösinger 16 Jan '15

16 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-01-15 um 12:55 schrieb Alex Henrie: > + DVCOMPRESSIONINFO data[32]; I can't really find any documentation about this. Is there a documented maximum number of elements returned? > + int i, j; Afaics you can make those unsigned. > + LPWSTR string_loc; Is the use of the LPFOO type intentional? > + if(GetCompressionTypes(iface, NULL, NULL, NULL, 0) == E_NOTIMPL) > + { > + skip("%s: GetCompressionTypes not implemented\n", name); > + return; > + } I think todo_wine ok(0, "GetCompressionTypes not implemented") is better here, but I don't particularly mind since you remove it in the next patch anyway. > + ok(data_size > sizeof(DVCOMPRESSIONINFO) && data_size < sizeof(data) - 1, > + "%s: tests[%i]: expected data_size between %i and %i got data_size=%i\n", > + name, i, sizeof(DVCOMPRESSIONINFO), sizeof(data) - 1, data_size); data_size is unsigned, you should use %u instead of %i. Same for i and j once you change them to unsigned. > + string_loc = (LPWSTR)((char*)data + num_elements * sizeof(DVCOMPRESSIONINFO)); It's interesting that native places the string in the same data blob, but it kinda makes sense. I think (WCHAR *)(data + num_elements) or (WCHAR *)&data[num_elements] should work as well. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUt7l0AAoJEN0/YqbEcdMwf/sQAIGsh8jbGM7AsbdeHt5uEJUD AGGg9OcqrDnW0PoCd5w36G70tNF/NFMRleNJ0tOL4r3HG8TD16BDXCkxW/U9hR7G 6c+DGAqnOFG0y6CjSAMGSvRh5VZVrD5OlI4XRTNFqYdL1QkVD0yQ/kXQl8YsvMUu x/sWJ1kF4FCcojmmhIP5tSo6AmZJlso18tlOReCBBnHDkdq+0ej8ltR/pG0NmZUp 3eOdSfyHd0Swc9P8nLossRKbieORr88fE0ZUBP7oOtg2JbLfs3l/F4fudbPoMF8v 5JbJXD+KuHdNvGYBJ2ppHEZCUC2ArHEYgMW0m2ffRoWfoXmrJCUE8AnJsyHsjaYI LFRiRGom7kRjoY8fhbTSJWdNTKLbW5swAiCzW7A+NkQvrXn5dcL2kZVpi2Z4x1gu 1JKYmb5G9G6SG+U4wblTWET4RWv5rAzoNeXvDZtznBW/KinnkNX2Ic7kug1/usqj ATJ9q8ARt+3DMPYRonk7sXzFdyRRXhlCROlBvqHBkPitVz3tLxvziB/4C1SZ9ybu wy28DMfEYfwbi/9iQnaHsn+811d7uf85QkKgiV6CBvS8XJ2xVzvHWnSWlbc0wNj1 /Gy5gCuKkluFWbJJjAliAf6+uHIypvBbFr85/Gn3gQy/tNUOH4FFSXPB18XrBXh3 CFH+vOFS/SN8fEA6WOtw =EJNM -----END PGP SIGNATURE-----

2 2

Re: [PATCH 4/5] opengl32: Store the OpenGL context version in the handle value.
by Alexandre Julliard 16 Jan '15

16 Jan '15

Matteo Bruni <mbruni(a)codeweavers.com> writes: > @@ -53,7 +53,14 @@ enum wgl_handle_type > { > HANDLE_CONTEXT = 0 << 12, > HANDLE_PBUFFER = 1 << 12, > - HANDLE_TYPE_MASK = 15 << 12 > + HANDLE_TYPE_MASK = 7 << 12 > +}; > + > +enum wgl_opengl_version > +{ > + OPENGL_1 = 0 << 15, > + OPENGL_3 = 1 << 15, > + OPENGL_VER_MASK = 1 << 15 > }; That's certainly acceptable, but since it only applies to contexts I'm wondering if it wouldn't be cleaner to add a CONTEXT_V3 type in the existing enum. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: iphlpapi: Set 0.0.0.0 as the IP and mask of disconnected interfaces
by Bruno Jesus 16 Jan '15

16 Jan '15

On Thu, Jan 15, 2015 at 10:13 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Superseeds 108610. > > In Windows if the eth cable is disconnected the interface returns > 0.0.0.0, when it's connected and using DHCP but no DHCP server is > found it returns an APIPA [1] address. In our case it's simpler to > assume that an IP less interface is a disconnected interface. > > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=32205 > > [1] http://www.webopedia.com/TERM/A/APIPA.html I see the patch is pending. In defense of the patch all I can do is say that I manually tested this in different Windows versions by disconnecting the interface (physical cable/wifi connection). If there is a specific concern about it please tell me so I can look for alternatives. Windows 98 connected (ETH): Adapter '', IP 172.16.204.135, Mask 255.255.255.0 Windows 98 disconnected (ETH): Adapter '', IP 0.0.0.0, Mask 0.0.0.0 Windows XP connected (ETH): Adapter '{02FB7145-66CB-4DF2-8975-BBCAC6044973}', IP 172.16.204.131, Mask 255.255.255.0 Windows XP disconnected (ETH): Adapter '{02FB7145-66CB-4DF2-8975-BBCAC6044973}', IP 0.0.0.0, Mask 0.0.0.0 Windows 8.1 connected (ETH): Adapter '{8973E4B8-0C69-45E0-85D0-EF4A71D6BD87}', IP 10.100.200.60, Mask 255.0.0.0 Windows 8.1 disconnected (ETH): Adapter '{8973E4B8-0C69-45E0-85D0-EF4A71D6BD87}', IP 0.0.0.0, Mask 0.0.0.0 Windows 8.1 connected (WIFI): Adapter '{1E13889D-F3CC-49BC-A750-FFBE451AC8E1}', IP 192.168.251.136, Mask 255.255.255.0 Windows 8.1 disconnected (WIFI): Adapter '{1E13889D-F3CC-49BC-A750-FFBE451AC8E1}', IP 0.0.0.0, Mask 0.0.0.0 Best Regards, Bruno

1 0

Re: [PATCH 3/5] opengl32: Update to GL 4.5.
by Alexandre Julliard 15 Jan '15

15 Jan '15

Matteo Bruni <mbruni(a)codeweavers.com> writes: > I fixed up manually a couple of misgenerated bits, my feeling is that > similar fixups were done last time too. I'm not aware that fixups have ever been done by hand, that doesn't sound like a good idea. Please try to fix the script instead. -- Alexandre Julliard julliard(a)winehq.org

2 1