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

Re: [PATCH] ntdll/tests: NtOpenFile a directory with NULL ObjectName.

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=13614 Your paranoid android. === w8 (32 bit file) === file.c:408: Test failed: mismatched file size for L"WindowsUpdate.log"

May 27, 2015

RE: programs/regsvr32: Output strings as WCHAR to support non-ascii characters

by Hugh McMaster

On Tuesday, 26 May 2015 11:38:09 -0300, Bruno Jesus wrote: > On Tue, May 26, 2015 at 5:56 AM, Hugh McMaster wrote: >> Your patch had the unfortunate side-effect of breaking output for almost all >> resource strings used in regsvr32. The problem is that the names of DLLs and >> input commands are still in ASCII. > > I have no idea what you are talking about, I thought it would be an > easy bug to fix in my coffee time, but obviously it's something much > more complex than I could expect. Sorry, I didn't explain this very well. regsvr32 uses "int main(int argc, char* argv[])". As you know, this only takes ascii characters. So, calling "./wine regsvr32 abc.dll" makes all input args ascii. When regsvr32 outputs a resource string using WriteConsoleW, it tries to print everything as Unicode. STRING_REGISTER_SUCCESSFUL, "regsvr32: Successfully registered DLL '%1'\n" This will be Unicode, but the replacement for %1 (abc.dll) is still ascii, which prints as garbage with WriteConsoleW. Unfortunately, WriteConsoleW doesn't convert ascii characters to Unicode without specifying the token as %1!S! in the resource string. So we'd have to do this to every resource string. >> Fixing the issue requires more work, as regsvr32 needs to be converted to >> Unicode first. >> >> I wrote patches to do that last year, but Alexandre felt they weren't >> needed. He said something like, "If it isn't broken, don't fix it". But now >> there is a problem, as translations are broken. >> >> I've rebased the patches against the latest commit base and uploaded them to >> my Dropbox account. [1] >> >> Feel free to use them. Or, if you like, I'll resend them to wine-patches. > > We do have a real bug now, so I think the sane thing to do is for you > to resend your patches. Making the whole program Unicode is probably a better solution, so I'll review the patches and resend.

May 27, 2015

Re: [1/3] include: Add stuff related to WSAPoll() (try 2)

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > On Tue, May 26, 2015 at 10:59 AM, Alexandre Julliard > <julliard(a)winehq.org> wrote: >> Unfortunately that doesn't work on mingw: >> >> In file included from ../../../wine/include/winsock2.h:50:0, >> from ../../../wine/include/ws2tcpip.h:22, >> from ../../../wine/dlls/jsproxy/main.c:34: >> ../../../wine/include/winsock2.h:287:19: error: redefinition of ‘struct pollfd’ >> ../../../wine/include/ws2def.h:27:18: note: in definition of macro ‘WS’ >> In file included from ../../../wine/dlls/jsproxy/main.c:20:0: >> ../../../wine/include/wine/port.h:284:8: note: originally defined here > > Thanks for the feedback, any hints? Can anybody explain why it works > for fd_set and not pollfd? Because pollfd is defined in wine/port.h, for other parts of Wine that need it. -- Alexandre Julliard julliard(a)winehq.org

May 26, 2015

Re: [PATCH 3/8] wined3d: Keep track of renderbuffer capabilities.

by Matteo Bruni

2015-05-26 12:54 GMT+02:00 Stefan Dösinger <stefandoesinger(a)gmail.com>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2015-05-25 um 10:50 schrieb Henri Verbeet: >> I guess, but it doesn't really seem worth it if that means >> duplicating much of the generic usage/format validation code. > I tried to move the code to resource_init and the non power of 2 > handling is a big problem. resource_init doesn't care about power of 2 > and non power of 2 sizes, and I don't think it should. It would need > to know that though to switch between 2D and RECT. > > Adding a flag for "this resource type supports NP2 textures" isn't > really an option either. If we have neither TEXTURE_NP2 nor > TEXTURE_RECTANGLE (some GL ES systems according to Matteo) we want to > use 2D textures with padding. Just to clarify on this point, even though it's quite tangential to the discussion: basic GL ES 2 has pretty much the same limitations as a D3D device with D3DPTEXTURECAPS_NONPOW2CONDITIONAL: NP2 textures are supported as long as you use CLAMP_TO_EDGE texcoord wrapping and don't make use of mipmapping in minification filtering. In theory D3D applications should check the cap bit and avoid that kind of usage, except often times they don't. The texture handling stuff related with WINED3D_GL_NORMALIZED_TEXRECT and WINED3D_TEXTURE_COND_NP2 mostly does the right thing here and yeah, it would be nice if that stays around. BTW, rectangle textures are not supported in OpenGL ES.

May 26, 2015

Re: programs/regsvr32: Output strings as WCHAR to support non-ascii characters

by Bruno Jesus

On Tue, May 26, 2015 at 5:56 AM, Hugh McMaster <hugh.mcmaster(a)outlook.com> wrote: > On Mon, 25 May 2015 12:06:43 -0300, Bruno Jesus wrote: >> Fixes https://bugs.winehq.org/show_bug.cgi?id=38638 > > Hi Bruno, Hi =) > Your patch had the unfortunate side-effect of breaking output for almost all > resource strings used in regsvr32. The problem is that the names of DLLs and > input commands are still in ASCII. I have no idea what you are talking about, I thought it would be an easy bug to fix in my coffee time, but obviously it's something much more complex than I could expect. > Fixing the issue requires more work, as regsvr32 needs to be converted to > Unicode first. > > I wrote patches to do that last year, but Alexandre felt they weren't > needed. He said something like, "If it isn't broken, don't fix it". But now > there is a problem, as translations are broken. > > I've rebased the patches against the latest commit base and uploaded them to > my Dropbox account. [1] > > Feel free to use them. Or, if you like, I'll resend them to wine-patches. We do have a real bug now, so I think the sane thing to do is for you to resend your patches. > -- > Hugh McMaster > > [1] > https://www.dropbox.com/sh/7j8wh9n0n09znk5/AADz3Fa3oEmtRUhqVG-Kq0kIa?dl=0 Best wishes, Bruno

May 26, 2015

Re: [1/3] include: Add stuff related to WSAPoll() (try 2)

by Bruno Jesus

On Tue, May 26, 2015 at 10:59 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Bruno Jesus <00cpxxx(a)gmail.com> writes: > >> try 2: >> I found the solution to typedef the struct pollfd just like it's done >> with fd_set. > > Unfortunately that doesn't work on mingw: > > In file included from ../../../wine/include/winsock2.h:50:0, > from ../../../wine/include/ws2tcpip.h:22, > from ../../../wine/dlls/jsproxy/main.c:34: > ../../../wine/include/winsock2.h:287:19: error: redefinition of ‘struct pollfd’ > ../../../wine/include/ws2def.h:27:18: note: in definition of macro ‘WS’ > In file included from ../../../wine/dlls/jsproxy/main.c:20:0: > ../../../wine/include/wine/port.h:284:8: note: originally defined here Thanks for the feedback, any hints? Can anybody explain why it works for fd_set and not pollfd? Best wishes, Bruno

May 26, 2015

Re: [1/3] include: Add stuff related to WSAPoll() (try 2)

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > try 2: > I found the solution to typedef the struct pollfd just like it's done > with fd_set. Unfortunately that doesn't work on mingw: In file included from ../../../wine/include/winsock2.h:50:0, from ../../../wine/include/ws2tcpip.h:22, from ../../../wine/dlls/jsproxy/main.c:34: ../../../wine/include/winsock2.h:287:19: error: redefinition of ‘struct pollfd’ ../../../wine/include/ws2def.h:27:18: note: in definition of macro ‘WS’ In file included from ../../../wine/dlls/jsproxy/main.c:20:0: ../../../wine/include/wine/port.h:284:8: note: originally defined here -- Alexandre Julliard julliard(a)winehq.org

May 26, 2015

Re: [PATCH 3/8] wined3d: Keep track of renderbuffer capabilities.

by Henri Verbeet

On 26 May 2015 at 13:33, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > I'd have to move or duplicate the power of two size calculation > (texture.c lines 1092 - 1123) to resource_init, and I don't think the > generic resource code should have to deal with this functionality that > is very specific to 2D textures. Passing a "this is a np2 texture" > flag to resource_init is a possible option, but it would still take > quite a bit of 2D texture specific code along with it (in particular > the switch between true NP2, faked WINED3D_GL_NORMALIZED_TEXRECT NP2, > ARB_texture_rectangle and 2D texture emulated NP2). > You don't really need pow2_width/pow2_height itself though, you just need to determine if the resource dimensions are powers of two, which is much easier. (I.e., "!(desc->width & desc->width - 1)", etc.)

May 26, 2015

Re: [PATCH 3/8] wined3d: Keep track of renderbuffer capabilities.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-05-26 um 13:03 schrieb Henri Verbeet: > On 26 May 2015 at 12:54, Stefan Dösinger > <stefandoesinger(a)gmail.com> wrote: >> I tried to move the code to resource_init and the non power of 2 >> handling is a big problem. resource_init doesn't care about power >> of 2 and non power of 2 sizes, and I don't think it should. It >> would need to know that though to switch between 2D and RECT. >> > What is the issue exactly? I'd have to move or duplicate the power of two size calculation (texture.c lines 1092 - 1123) to resource_init, and I don't think the generic resource code should have to deal with this functionality that is very specific to 2D textures. Passing a "this is a np2 texture" flag to resource_init is a possible option, but it would still take quite a bit of 2D texture specific code along with it (in particular the switch between true NP2, faked WINED3D_GL_NORMALIZED_TEXRECT NP2, ARB_texture_rectangle and 2D texture emulated NP2). I'm not saying we can't do it that way. I just don't think it is nicer. I'll see if I can extract the flag checks into a separate function that texture_init and resource_init can call. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVZFoKAAoJEN0/YqbEcdMwk8cP/2yLi7Ol7FJU/YFsjA50IAGG 0WpmXBNw93UQLU8DK63+l4+0y+ExqpvO27ACkmMotwAVJT8WhNIK8wxWQ2uUiirD jXCLq1dq70o4X7xm5odjY0x2k6zqDcbeptdQ0j9U0cy8GxedmII8wKEH7FZEOtsW 2v/6BCP7z300nfDGu3Gpv9i9M0KZ0OyS2D8CiPgxl1k4TU2diDEcTHwCPEAPTOpB 73a9aWJfn27nGAYJcGlpe14lNxBuHTzP8E+QSk2Jiv3lySPWi3WonArmjTRnexkW vgoR5ZCn+7SYo99qMJI2TM2gvdDKwbfckriSnJLGNiZjgi2OWRwXN1TVCWn6W0gu kZQ/cjrEfgkxb87vpQViM/+mwoKcdLL4PDJyHWIx5cBkjkyCbaGsGpzI5MTlvYa4 SNs83DRdGlAt5GQo7tAORRYBbUPXfVI1zCtwYwfVwOWmPQ10WppnKy4zuH+TOad4 H07sRm+xhYWBqw5TB11z3j0Yp/HSfnvYeks66ZdHe8iVL0YuzSONfy3gVX2DQqoK xY8tERj9IkRwUcpyepV5nO57tk32VRiUv3FWqyx7g8xWJTd17gF2fXZPSpAhTbcX 778iXhtmPFm/6wedHcr7a2fECM3ZaaKSaX+Ch9jhKadvxSIx57TjmlntWv7jt8OE BzPGbwd56AVgu0uJmi47 =lNvw -----END PGP SIGNATURE-----

May 26, 2015

Re: [PATCH 3/8] wined3d: Keep track of renderbuffer capabilities.

by Henri Verbeet

On 26 May 2015 at 12:54, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > I tried to move the code to resource_init and the non power of 2 > handling is a big problem. resource_init doesn't care about power of 2 > and non power of 2 sizes, and I don't think it should. It would need > to know that though to switch between 2D and RECT. > What is the issue exactly?

May 26, 2015