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

Re: [2/4] comdlg32: Implement open dropdown menu.

by Alexandre Julliard

Vincent Povirk <madewokherd(a)gmail.com> writes: > This implements the open dropdown button as a separate button, rather > than using BS_SPLITBUTTON, which is unimplemented in Wine. This adds > some complexity, but I don't think it changes things enough to get in > the way of other work on this component. > > I have an implementation using BS_SPLITBUTTON that works on Windows, > and could theoretically be used once we have support for window class > redirection and BS_SPLITBUTTON. I will send that to wine-devel so you > can see how much complexity this approach adds, and what the correct > approach will look like. It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M comdlg32.dll -p comdlg32_test.exe.so itemdlg && touch itemdlg.ok itemdlg.c:2088: Test succeeded inside todo block: got 0x00000000. itemdlg.c:2089: Test succeeded inside todo block: got 0. Makefile:270: recipe for target 'itemdlg.ok' failed make: *** [itemdlg.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2015

Re: ws2_32: WSACleanup cleans up open sockets (OSX only)

by Henri Verbeet

On 26 August 2015 at 23:28, Matt Durgavich <mattdurgavich(a)gmail.com> wrote: > Bruno wrote a patch a while back that tracked sockets in a linked list, and the feedback there was to use a hashing scheme similar to how files are handled since sockets, like files, can be opened and closed rapidly. > I must have missed that mail. Do you have a message ID or a link to the mailing list archive? > Chip made this point re ws2_32 tracking sockets: > > "The second option I gave might be preferable, because e.g. someone could DuplicateHandle() a winsock handle into another process, and WSACleanup() might not close it when it runs. (Someone should write a test for that.)” > Tests would certainly be useful. > For the server side approach, I’d need to map the fd back to a handle that can be closed. > Well, no, you'd just enumerate all the socket handles in the process' handle table. > Can we get a consensus here as to the right approach? I don’t want to polish a patch that is wrong-headed. > I can't necessarily tell you what the right approach is, I've only spent about 10 minutes looking at the problem. But I'm fairly sure a hash table in ws2_32 isn't it.

Aug. 27, 2015

Re: [PATCH 5/5] dxgi/tests: Add a Test presentation parameter combinations.

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=16348 Your paranoid android. === wvistau64 (32 bit device) === device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 12. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 13. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 19. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 24. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 25. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 27. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 28. device.c:1173: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 29. device.c:1173: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 35. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 36. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 40. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 41. device.c:1173: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 42. === w2008s64 (32 bit device) === device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 12. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 13. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 19. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 35. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 36. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 42. === w7u (32 bit device) === device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 24. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 25. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 27. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 28. device.c:1173: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 29. device.c:1173: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 35. device.c:1173: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 36. device.c:1173: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 40. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 41. device.c:1173: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 42. device.c:1173: Test failed: Got usage 160, expected 60, test 42, buffer 15. === w8 (32 bit device) === device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 24. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 25. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 27. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 28. device.c:1173: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 29. device.c:1173: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 35. device.c:1173: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 36. device.c:1173: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 40. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 41. device.c:1173: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 42. device.c:1173: Test failed: Got usage 160, expected 60, test 42, buffer 15. === wvistau64 (64 bit device) === device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 12. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 13. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 19. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 35. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 36. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 42. === w2008s64 (64 bit device) === device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 12. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 13. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 19. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 35. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 36. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 42.

Aug. 26, 2015

Re: Winelib and C++ static initialization

by Luke Dunstan

On Thu, 27 Aug 2015 at 00:44 Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > You dropped the wine-devel CC. Was that intentional? There are people > who have more clues about winelib than I do. > No, it was accidental, sorry. > > >> I found that OutputDebugStringA doesn't write anything here, > >> even if successful. I replaced it with printf calls to get > >> actual output. > > > > OK, but why exactly is this necessary? This is just an artificial > > example to demonstrate the general problem. > I looked into the source code of OutputDebugStringA, but I couldn't find > an obvious answer. It certainly does a lot more than just write a string > to STDOUT. I didn't really understand what it was doing. > Yes, it sends the message to the attached debugger if any, not to stdout. On Windows or Wine you can run SysInternals DbgView.exe to see it. It's just an example though, and many other APIs also crash when called from initialisers. >> Though it's not quite working here either: > > > > Any ideas why, or how it could be fixed? > Sorry, no idea :-( . > > > Yes. My hope was that Winelib could be used to help port a legacy > > Windows CE 4.x application to Linux (ARM, though I am testing on > > x86 right now). Initially I could try compiling on Windows and > > running it on Linux, but the real goal would be to port the > > application in stages, so changing a few modules at a time to use > > Linux APIs while leaving some parts using the Win32 (and MFC) APIs. > > Eventually there would be no need for Winelib but I'd expect that > > porting all of the code at once would resulting in a lot more > > debugging effort because changes would not be localised. > Hmm yeah, that sounds like a task where you need winelib. Unfortunately > winelib isn't something that gets used a lot, and even less so with C++. > > Also keep in mind that Wine doesn't target Windows CE applications, so > you'll have to invest a lot of time into bridging Windows CE <-> Win32 > differences. > Yes I understand, but fortunately most of the application also runs on normal Win32. You'll also have to compile MFC with Winelib to target ARM. It should > be possible to compile MFC (or at least parts of it) with winelib, but > I don't expect this to be easy either. > That's true, and that was actually the first thing I tried to do. I tried both static and dynamic libraries but it crashes before it gets to WinMain(), hence my question. GDB can trap the crash but the stack trace gives no function names or other useful information. (gdb) bt #0 0x00000000 in ?? () #1 0x7ec4b7c0 in ?? () #2 0x7ec4b77e in ?? () #3 0x7ec4b79e in ?? () #4 0xb7febd77 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Winedbg cannot even get that far. But I will try 1.7... Luke

Aug. 26, 2015

Re: [PATCH 4/5] d3d8/tests: Test presentation parameter combinations.

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=16347 Your paranoid android. === w8 (32 bit device) === device.c:1216: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1261: Test failed: Reset failed, hr 0x88760868. device.c:1263: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1267: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1274: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1275: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1276: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1277: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1278: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1279: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1284: Test failed: Screen width is 640, expected 800. device.c:1285: Test failed: Screen height is 480, expected 600. device.c:1291: Test failed: Back buffer width is 640, expected 800. device.c:1293: Test failed: Back buffer height is 480, expected 600. device.c:1323: Test failed: Screen width is 640, expected 1024. device.c:1324: Test failed: Screen height is 480, expected 768. device.c:2571: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2576: Test failed: The focus window is active. device.c:2584: Test failed: Got unexpected hr 0x88760869. device.c:2590: Test failed: Got unexpect screen size 800x600. device.c:2605: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2614: Test failed: Got unexpect screen size 800x600. device.c:2627: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2635: Test failed: Got unexpect width 640. device.c:2636: Test failed: Got unexpect height 480.

Aug. 26, 2015

Re: ws2_32: WSACleanup cleans up open sockets (OSX only)

by Matt Durgavich

Bruno wrote a patch a while back that tracked sockets in a linked list, and the feedback there was to use a hashing scheme similar to how files are handled since sockets, like files, can be opened and closed rapidly. Chip made this point re ws2_32 tracking sockets: "The second option I gave might be preferable, because e.g. someone could DuplicateHandle() a winsock handle into another process, and WSACleanup() might not close it when it runs. (Someone should write a test for that.)” For the server side approach, I’d need to map the fd back to a handle that can be closed. I imagine a server call is somewhat pricey, but WSACleanup shouldn’t be called often. Is there more subtly to the problem than that? Can we get a consensus here as to the right approach? I don’t want to polish a patch that is wrong-headed. Thanks, -Matt > On Aug 26, 2015, at 4:59 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > > On 26 August 2015 at 21:50, Ken Thomases <ken(a)codeweavers.com> wrote: >> On Aug 25, 2015, at 9:09 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >>> If the idea is just to keep track of all the sockets you give out you >>> want neither of those of course, but just something like a handle >>> table or a list. >> I think the intent was to make it efficient to find a given socket handle in the list. >> > You'd just lookup the handle in the table. Of course it would probably > be much easier to just do it in the server, since it already keeps > track of socket handles.

Aug. 26, 2015

Re: [PATCH 5/5] dxgi/tests: Add a Test presentation parameter combinations.

by Henri Verbeet

On 26 August 2015 at 21:50, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + wc.lpfnWndProc = DefWindowProcA; > + wc.lpszClassName = "dxgi_test_wc"; > + RegisterClassA(&wc); Do we really need that?

Aug. 26, 2015

Re: ws2_32: WSACleanup cleans up open sockets (OSX only)

by Henri Verbeet

On 26 August 2015 at 21:50, Ken Thomases <ken(a)codeweavers.com> wrote: > On Aug 25, 2015, at 9:09 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> If the idea is just to keep track of all the sockets you give out you >> want neither of those of course, but just something like a handle >> table or a list. > I think the intent was to make it efficient to find a given socket handle in the list. > You'd just lookup the handle in the table. Of course it would probably be much easier to just do it in the server, since it already keeps track of socket handles.

Aug. 26, 2015

Re: ws2_32: WSACleanup cleans up open sockets

by Ken Thomases

On Aug 25, 2015, at 2:18 PM, Matt Durgavich <mattdurgavich(a)gmail.com> wrote: > @@ -4987,6 +5023,11 @@ static int WS2_sendto( SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, > DWORD bytes_sent; > BOOL is_blocking; > > + if (!socket_in_table(s)) { > + SetLastError(WSAENOTSOCK); > + return SOCKET_ERROR;; > + } > + I raised this in my reply to Henri, but: why was this added? And if it's sensible to have it here, why not in any of the other functions? > +static void cache_update(SOCKET new_entry, SOCKET old_entry) Still calling it a "cache"? > +{ > + int index, depth, tries; > + LONG *bucket; > + > + index = socket_to_index(new_entry == 0 ? old_entry : new_entry); > + depth = 0; > + bucket = (LONG*)&socket_table[index]; > + tries = 0; > + do > + { > + LONG *slot = (LONG*)&bucket[depth++]; > + if (InterlockedCompareExchange(slot, new_entry, old_entry) == old_entry) I think it would be better to do: if (*slot == old_entry && InterlockedCompareExchange(slot, new_entry, old_entry) == old_entry) While InterlockedCompareExchange() is faster than locking, it's still not cheap. Doing it on every element without the prior belief that that element matches seems wasteful. > + break; > + if (depth == BUCKET_DEPTH) > + { > + ++tries; > + depth = 0; > + } > + > + } while (tries < 3); > + if (tries == 3) > + { > + ERR("Socket hash table bucket overflow. Resize buckets"); > + } > +} I don't see any reason to try multiple times. The chances of a slot changing from one pass to the next is miniscule. If you're searching for a free slot (old_entry is 0) and you don't find one on the first pass, then you should still resize the buckets, even if you would hypothetically find one on a second or third pass. If old_entry is not 0, then it's really unlikely that another thread would add that specific socket to the table. How could that happen that wouldn't be a bug? > + > +static void add_to_table(SOCKET s) > +{ > + cache_update(s, 0); > +} > + > +static BOOL remove_from_table(SOCKET s) > +{ > + if (!socket_in_table(s)) > + return FALSE; > + > + cache_update(0, s); > + return TRUE; This is two passes when one should do. More importantly, though, it seems race-prone. If two threads are both closing the same socket, they could each first determine that the socket is in the table and thus return TRUE, when only one should return TRUE. You could make cache_udpate() return a success/failure value and simply make this a wrapper around cache_update(0, s). -Ken

Aug. 26, 2015

Re: ws2_32: WSACleanup cleans up open sockets (OSX only)

by Ken Thomases

On Aug 25, 2015, at 9:09 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 25 August 2015 at 06:46, Ken Thomases <ken(a)codeweavers.com> wrote: >>> On Aug 24, 2015, at 10:49 PM, Matt Durgavich <mattdurgavich(a)gmail.com> wrote: >>> +#define CACHE_SIZE 256 >>> +#define CACHE_DEPTH 16 >>> +static SOCKET socket_cache[CACHE_SIZE][CACHE_DEPTH]; >>> + >>> +/* Cache support */ >>> +static void add_to_cache(SOCKET s); >>> +static BOOL remove_from_cache(SOCKET s); >>> +static BOOL socket_in_cache(SOCKET s); >> I'm not sure this is a "cache", per se. It's a hash table, but naming issues are fairly minor. >> > If the idea is just to keep track of all the sockets you give out you > want neither of those of course, but just something like a handle > table or a list. I think the intent was to make it efficient to find a given socket handle in the list. However, that may be premature optimization. Whether it's worth using a hash table for that depends on how many sockets a process is likely to open and how frequently it does an operation that needs to check the list. For example, the patch adds a check of the list in WS2_sendto(). I'm not sure why it adds that check (and only to that specific function), but you wouldn't want to slow that down too much. -Ken

Aug. 26, 2015