October 2013 - Wine-Devel - list.winehq.org

Re: [3/3] ws2_32: Always return the source address from WSAAccept.

by Hans Leidekker

On Tue, 2013-10-01 at 09:32 -0300, Bruno Jesus wrote: > On Tue, Oct 1, 2013 at 6:37 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > > --- > > dlls/ws2_32/socket.c | 9 +-------- > > dlls/ws2_32/tests/sock.c | 6 +++--- > > 2 files changed, 4 insertions(+), 11 deletions(-) > > > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > > index c34de4b..6855298 100644 > > --- a/dlls/ws2_32/socket.c > > +++ b/dlls/ws2_32/socket.c > > @@ -6546,12 +6546,8 @@ SOCKET WINAPI WSAAccept( SOCKET s, struct WS_sockaddr *addr, LPINT addrlen, > > TRACE("Socket %04lx, sockaddr %p, addrlen %p, fnCondition %p, dwCallbackData %ld\n", > > s, addr, addrlen, lpfnCondition, dwCallbackData); > > > > - > > - size = sizeof(src_addr); > > - cs = WS_accept(s, &src_addr, &size); > > - > > + cs = WS_accept(s, addr, addrlen); > > The parameter addr may be NULL in WSAAccept, I can't check the source > code right now but what will WS_accept do in this case? It will skip the WS_getpeername call. Good point, I'll add some tests for this case and resubmit the series.

Oct. 1, 2013

Re: [1/3] ws2_32: Always clear res on error in getaddrinfo/GetAddrInfoW.

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://newtestbot.winehq.org/JobDetails.pl?Key=2419 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (2a4): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (774): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (884): unexpectedly at the OOB mark: 0 === w7pro64 (64 bit sock) === sock.c:509: Test failed: oob_server (af8): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (af8): unexpectedly at the OOB mark: 0 sock.c:288: Test failed: do_synchronous_recv (af8): error 10054: sock.c:534: Test failed: oob_server (af8): not at the OOB mark: 1

Oct. 1, 2013

Re: [3/3] ws2_32: Always return the source address from WSAAccept.

by Bruno Jesus

On Tue, Oct 1, 2013 at 6:37 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > --- > dlls/ws2_32/socket.c | 9 +-------- > dlls/ws2_32/tests/sock.c | 6 +++--- > 2 files changed, 4 insertions(+), 11 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index c34de4b..6855298 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -6546,12 +6546,8 @@ SOCKET WINAPI WSAAccept( SOCKET s, struct WS_sockaddr *addr, LPINT addrlen, > TRACE("Socket %04lx, sockaddr %p, addrlen %p, fnCondition %p, dwCallbackData %ld\n", > s, addr, addrlen, lpfnCondition, dwCallbackData); > > - > - size = sizeof(src_addr); > - cs = WS_accept(s, &src_addr, &size); > - > + cs = WS_accept(s, addr, addrlen); The parameter addr may be NULL in WSAAccept, I can't check the source code right now but what will WS_accept do in this case? Best wishes, Bruno

Oct. 1, 2013

Re: [PATCH 2/5] wined3d: Move location management into the resource.

by Henri Verbeet

Please split this.

Oct. 1, 2013

Re: [PATCH 2/5] wined3d: Move location management into the resource.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, To illustrate the goal of these patches I've attached an archive of all surface cleanup patches to this mail. The goal is to merge GL buffer object handling of buffers, surfaces and volumes. The main motivation for this is to handle WINED3D_MAP_DISCARD in one central place once dynamic resource handling is implemented in the command stream. The 4 patches in this series move location and buffer handling code from volume.c to resource.c. The next patches remove broken(overlay, partial rectangle handling) and half-broken(direct DIB maps, buffers) surface features. The next step is migrating surfaces to the resource location and loading code in resource.c. After that WINED3D_LOCATION_DISCARDED handling is improved and previously removed surface features re-added. Due to the removal of some surface features, performance regressions are possible. I think it's unlikely because the existing surface PBO code doesn't really do what it is supposed to do. Functional regressions should not happen. This patchset does not deal with d3d buffers. The central aspect of merging buffer handling is removing color and rhw conversion support. (or, alternatively, adding a separate location WINED3D_LOCATION_CONVBUFFER if we really want to keep the conversion code.) There are some problems later in the patchset that need fixing: Patch 24 is too big, patches 48 and 52 need to be moved. Non-GL ddraw rendering is broken at the moment (black screen). My patches don't make this any worse, but I'd like to fix it to make sure non-GL operation works as intended. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSSqzhAAoJEN0/YqbEcdMww1wP/jYYo0B/igDHd0QwOkwk8DIz ip4PKHxRgqaSYzswcBGZge+iBrJrvXSHh3cScG9KJ1a/VeaRlPyhDsFDzPce1VDK 0IX7iF/gKpZazPVy21lSIPQMlErSVy58fkIsd/PqKV/zyU8zNyZDkYU3n80itYrq Y3hPhaKbJIDN8QbhIOZu0egaiHObcwomBgZCfrUv+hr+xf+gMERYbqN9gj2JWFwJ dx4EzdeTFw1CZkFExbAJKt5zWA2KeFyitVU887WOSJpa3UbqemGpOID8vnYZlABZ mmqrS22XWjXlo2+0s0NufxeQJHvzpkcludLkg8a12r4FDs+ORYYnGbUeUy2o2Rud uV2quoeucA1TEAyF20JCrVNuCvDz5nvQq19rzR51k7FF/IsKGiI823ZGA54F4Dkn DZkyDcE0rnI2Re+br1aM31ZUt/maTxQMpk10BAAjwz1jbXQ4plZ9dtO9/DObdw8r nfPDJz+DsuBv19Th7MPjTxvXRjxVFTzlfuXNk/cOfAhgNdpEFSOGCAexGi6moSq1 6slQeLb8PqmO/83JQBuz4OI86dSoGSC6O9c/TtWXdW1PgCDyHgFvNb3jmQHsf7ya U1o2TkkNhLvfYz5Eo85Ep8oyVIF09CDrqQzUo10q33K5Y2E3RM8Xbxc+crGtjgxA TGwCwR8SRvAW+DfeP7bq =MEk/ -----END PGP SIGNATURE-----

Oct. 1, 2013

Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().

by Ralf Habacker

On 01.10.2013 12:40, Alexandre Julliard wrote: > Ralf Habacker <ralf(a)habacker.de> writes: > >> On 01.10.2013 12:12, Alexandre Julliard wrote: >>> Ralf Habacker <ralf.habacker(a)freenet.de> writes: >>> >>>> With other patches i have been told to implement such stuff in the dib >>>> driver. Unfortunally this do not works in this case, because in the top >>>> level function it looks like having driver specific stuff using display >>>> coordinates. >>> It would still most likely have to be in the driver, >> which is freetype_GetTextExtentExPoint() ? >> >>> though maybe the driver would not be calling that exact entry point. >> not sure i understand right: >> >> GetTextExtentExPointW() calls get_char_positions(), which runs >> dev->funcs->pGetTextExtentExPoint(), which is mapped to >> freetype_GetTextExtentExPoint(), which is in the driver. Which entry >> point your are refering else ? > The various text rendering entry points in the graphics drivers. > >>> In any case, you can't change the DC transform like this >> then a real solution requires to move the transformation to logical >> coordinates stuff in BOOL GetTextExtentExPointW() to >> freetype_GetTextExtentExPoint() and to manipulate the related matrixes >> in freetype_GetTextExtentExPoint() directly wen using GM_ADVANCED ? > No, I don't think so. The transform is only used to determine the font > scaling factor. how then ? >>> and you'll need test cases. >>> >> Do you mean in detail: >> >> 1. Create a specific font >> 2. Run GetTextExtentExPointW() which specific parameters >> 3. check if it results expected values > Well, yes, that's what all tests do. >

Oct. 1, 2013

Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > The tests show that this is how fully up to date Windows versions starting > from XP behave, isn't that convincing enough? If not, what else do you need > to see? An application that breaks because of this. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2013

Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > Do you propose to leave NtWriteFile/NtReadFile in the state when they > > return STATUS_SUCCESS for overlapped writes and reads? But that's clearly > > not how Windows implements this accordingto the tests, and that would > > require changing all the tests to accept both values so that they pass > > under Wine. > > Well, the tests fail mostly because you have decided that this behavior > is broken. I'm not convinced. The tests show that this is how fully up to date Windows versions starting from XP behave, isn't that convincing enough? If not, what else do you need to see? -- Dmitry.

Oct. 1, 2013

Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().

by Alexandre Julliard

Ralf Habacker <ralf(a)habacker.de> writes: > On 01.10.2013 12:12, Alexandre Julliard wrote: >> Ralf Habacker <ralf.habacker(a)freenet.de> writes: >> >>> With other patches i have been told to implement such stuff in the dib >>> driver. Unfortunally this do not works in this case, because in the top >>> level function it looks like having driver specific stuff using display >>> coordinates. >> It would still most likely have to be in the driver, > which is freetype_GetTextExtentExPoint() ? > >> though maybe the driver would not be calling that exact entry point. > not sure i understand right: > > GetTextExtentExPointW() calls get_char_positions(), which runs > dev->funcs->pGetTextExtentExPoint(), which is mapped to > freetype_GetTextExtentExPoint(), which is in the driver. Which entry > point your are refering else ? The various text rendering entry points in the graphics drivers. >> In any case, you can't change the DC transform like this > > then a real solution requires to move the transformation to logical > coordinates stuff in BOOL GetTextExtentExPointW() to > freetype_GetTextExtentExPoint() and to manipulate the related matrixes > in freetype_GetTextExtentExPoint() directly wen using GM_ADVANCED ? No, I don't think so. The transform is only used to determine the font scaling factor. >> and you'll need test cases. >> > Do you mean in detail: > > 1. Create a specific font > 2. Run GetTextExtentExPointW() which specific parameters > 3. check if it results expected values Well, yes, that's what all tests do. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2013

Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Do you propose to leave NtWriteFile/NtReadFile in the state when they > return STATUS_SUCCESS for overlapped writes and reads? But that's clearly > not how Windows implements this accordingto the tests, and that would > require changing all the tests to accept both values so that they pass > under Wine. Well, the tests fail mostly because you have decided that this behavior is broken. I'm not convinced. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2013