August 2009 - Wine-devel - list.winehq.org

Re: [2/2] comdlg32/tests: Fix a failing test on Win2k and above.
by Paul Vriens 04 Aug '09

04 Aug '09

Nicolas Le Cam wrote: > Hi, > > Following Rein's commit 1f825a3631c78ac08383dd6062005526fc9c483d I've > got a new failure on my Win2k box. > > I did a first patch to filter Win2k failure that happens on > GetSaveFileNameW case only but, according to test.winehq.org, Win9x > boxes are failing on more cases so I did a more general (and simple) > fix. > > -- > Nicolas Le Cam > > > ------------------------------------------------------------------------ > > Hi Nicolas, Judging by the results on test.winehq.org I'd say that W2K and below (except ME) fails these tests (and there is even a Win95 box that doesn't fail so it seems). I guess just changing that comment should do the trick, not? -- Cheers, Paul.

2 1

Re: [2/2] comdlg32/tests: Fix a failing test on Win2k and above.
by Rein Klazes 04 Aug '09

04 Aug '09

On Mon, 03 Aug 2009 21:02:30 +0200, you wrote: > > >Following Rein's commit 1f825a3631c78ac08383dd6062005526fc9c483d I've >got a new failure on my Win2k box. > >I did a first patch to filter Win2k failure that happens on >GetSaveFileNameW case only but, according to test.winehq.org, Win9x >boxes are failing on more cases so I did a more general (and simple) >fix. > ... >+ ok( maxtextrows == 0 || broken(maxtextrows == 1), /* Win2k and above */ Then I think that should be "Win2k and below". Rein.

1 0

Re: programs/start: handle /B & /I options
by Frédéric Delanoy 03 Aug '09

03 Aug '09

Well, IMHO bug 10912 should stay open since /B option is not really supported, but rather silently ignored. Frédéric On Mon, Aug 3, 2009 at 2:34 AM, Austin English<austinenglish(a)gmail.com> wrote: > Fixes bug 10912. > > -- > -Austin

2 1

Re: ws2_32: Add debug support for IPv6 addresses
by Alexandre Julliard 03 Aug '09

03 Aug '09

Juan Lang <juan.lang(a)gmail.com> writes: > + case WS_AF_INET: > + return wine_dbg_sprintf("{ family %d, address %s, port %d }", > + ((const struct sockaddr_in *)a)->sin_family, > + inet_ntoa(((const struct sockaddr_in *)a)->sin_addr), > + ntohs(((const struct sockaddr_in *)a)->sin_port)); > + case WS_AF_INET6: > + { > + char buf[46]; > + const char *p; > + struct WS_sockaddr_in6 *sin = (struct WS_sockaddr_in6 *)a; > + > + p = WS_inet_ntop( WS_AF_INET6, &sin->sin6_addr, buf, sizeof(buf) ); > + if (!p) > + p = "(unknown IPv6 address)"; > + return wine_dbg_sprintf("{ family %d, address %s, port %d }", > + sin->sin6_family, p, ntohs(sin->sin6_port)); There's no need to display family as a number since you know its value already, you could print it in symbolic form. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: Prevent page faults from ATL thunk check to reach debuggers
by Alexandre Julliard 03 Aug '09

03 Aug '09

Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> writes: > send_debug_event will not send the "first chance exception" message (or > any other) when Peb->BeingDebugged is zero. Of course you can't do that, BeingDebugged is global not per-thread. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: 2/4 winex11: make sure r8g8b8 is used when using get_xrender_color
by Alexandre Julliard 03 Aug '09

03 Aug '09

Roderick Colenbrander <thunderbird2k(a)gmail.com> writes: > The text color of a physdev is in 24-bit r8g8b8 independent of the > depth, so make sure the picture format passed to get_xrender_color is > also in this format. This prepares for dibsections with support in > depths other than the screen depth. This is wrong, the text pixel is in device-specific format. The color conversion functions that are used for the text pixel and similar variables need to be expanded to take into account multiple depths (not to mention DIB color maps...) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/3] WineD3D: Test SetRenderTarget-Stateblock recording interaction
by Henri Verbeet 03 Aug '09

03 Aug '09

I actually meant integrating it with the existing stateblock tests, i.e. test_state_management(), but I can also do that myself afterwards. Please add a test for d3d8 as well though, both render targets and stateblocks are slightly different there.

2 1

Re: [2/3] WineD3D: SetRenderTarget sets the scissor rect
by Henri Verbeet 03 Aug '09

03 Aug '09

2009/8/3 Stefan Dösinger <stefan(a)codeweavers.com>: >- ok(hr == D3D_OK, "IDirect3DDevice9_BeginStateBlock failed, hr = %08x\n", hr); >+ ok(hr == D3D_OK, "IDirect3DDevice9_EndStateBlock failed, hr = %08x\n", hr); This should have been part of the first patch.

2 1

Cursor & Icon patches
by Daniel Santos 03 Aug '09

03 Aug '09

Hello everybody! Attached is my current cursor icon patches based upon work by Henri Verbeet and Andrew Riedi for review and comment. I finished the actual code about 3 weeks ago, but it's been a lot of work for me to split it out into smaller pieces, especially being new to git. Here is a break-down of what these patches do and the theory. * Adds real 32-bit handles (instead of converting 16-bit handles to 32 bit). * Cursors & icons stored in non-moveable memory block (a.k.a., "32 bit data") in addition to existing 16-bit moveable block. * A new 'struct cursor_header' (include/wine/winuser16.h) is pre-pended to the 32-bit cursor/icon data (16-bit data format is untouched). * A new 'struct cursor_map_entry' (dlls/user32/cursoricon.c) is used to manage a cursor's association with its handles and data. * Adds more complete .ani support (I think nearly 100% complete). * Adds themed icon support (from your X-windows theme). * Fixes a lot of bugs. * And finally, moves cursors to the server. The server opaquely stores the raw 32-bit cursor/icon data. Since the client does all interaction with winex11.drv, the server doesn't really need to understand it. The client caches all objects locally, but attempts to retrieve from the server any handle it doesn't know about. Locally, the client uses a pair of rbtrees to associate cursor objects (actually struct cursor_map_entry) with their respective 16 & 32 bit handles. The 16 bit cursor data is automatically generated on the client and can still be directly manipulated from 16 bit programs; in such cases, the 32-bit cursor data will be updated from the modified 16 bit data. The CRITICAL_SECTION IconCrst is used to synchronize access to the rbtrees and ensure that data is unmodified once an operation on that data begins (in database terms, IconCrst is used to lock the entire "table" and there's no "row-level" locking). There are several new functions to query and manipulate the rbtrees: add_cursor_entry : (self-explanatory) remove_cursor_entry: (self-explanatory) get_cursor_handle16: retrieves a 16-bit handle from a 32-bit one get_cursor_handle : visa-versa Layered on top of that are a basic set of functions for higher level management of cursor/icon objects: alloc_cursor_data : allocate & initialize cursor data & header create_cursor : creates cursor and auto-generates 16-bit data destroy_cursor : destroys cursor and associated 16-bit data get_cursor_entry : will look both locally and on the server get_cursor_object : returns the cursor's data update_cursor_data16: creates or updates the 16-bit data from 32-bit data CURSORICON_refresh_cursor16: updates the 32-bit data from 16-bit data The functions add_cursor_entry and get_cursor_entry directly return a pointer to the struct cursor_map_entry and therefore require locking IconCrst in advance of calling (or will fail an assertion). Having direct access to the cursor_map_entry reduces complexity in some circumstances. One of the oddest fixes is the fake_cursor() function, which is used to accommodate deleting the active cursor, which windows doesn't mind. This isn't the only way to go about it, but the alternative was to make the cursor empty and I'm not certain that that is the visual behavior of windows when deleting the active cursor, so I'm more than open to feedback on that as well as anything else in these patches. Thanks! Daniel

5 7

Re: 2/4 winex11: make sure r8g8b8 is used when using get_xrender_color
by Henri Verbeet 03 Aug '09

03 Aug '09

2009/8/2 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > Hi, > > The text color of a physdev is in 24-bit r8g8b8 independent of the > depth, so make sure the picture format passed to get_xrender_color is > also in this format. This prepares for dibsections with support in > depths other than the screen depth. > Shouldn't the format of the pixel be compatible with the picture you're using it on?

2 2