- wine-devel - winehq.org

Re: oleaut32: Fix TLB dependencies lookup
by Nikolay Sivov 04 Jun '14

04 Jun '14

> -IMPORTS = oleaut32 ole32 rpcrt4 user32 gdi32 advapi32 > +IMPORTS = oleaut32 ole32 rpcrt4 user32 gdi32 advapi32 shlwapi > + StrCatW(pathW, (WCHAR[3]){'\\','4',0}); You don't need this. Just use lstrcatW() and please define constant string in a cleaner way.

1 0

Re: oleaut32: Fix TLB dependencies lookup
by Andrew Eikum 04 Jun '14

04 Jun '14

Looking mostly good, but some problems below. On Tue, Jun 03, 2014 at 08:50:46PM +0200, guillaume.charifi(a)sfr.fr wrote: > + hr = LoadTypeLibEx(testTLBNameW, REGKIND_NONE, &ptLib); > + if(hr == S_OK) { > + ITypeLib_Release(ptLib); > + win_skip("test_tlb.tlb is on the path or registered, skipping typelib dependency tests\n"); > + return; > + } > + This fails when I run the tests in my source tree: [aeikum@aeikum tests]$ pwd /home/aeikum/wine/dlls/oleaut32/tests typelib.c:5434: Test failed: test_tlb.tlb is on the path or registered, skipping typelib dependency tests Makefile:345: recipe for target 'typelib.ok' failed make: *** [typelib.ok] Error 1 > + /* Search in resource table */ > + if(1) { Why is this if-statement here? > + static const WCHAR TYPELIBW[] = {'T','Y','P','E','L','I','B',0}; > + struct search_res_tlb_param *param = heap_alloc(sizeof(*param)); Why aren't you allocating this on the stack? > + > + param->guid = (GUID *)TLB_get_guid_null(ref_type->pImpTLInfo->guid); > + > + EnumResourceNamesW(NULL, TYPELIBW, search_res_tlb, (LONG_PTR)param); > + > + pTLib = param->pTLib; > + result = param->result; If search_res_tlb() is never run, I think (result == 0 == S_OK). You should initialize it to some failure condition before calling EnumResourceNames. Andrew

1 0

Re: oleaut32: Fix TLB dependencies lookup
by Guillaume Charifi 04 Jun '14

04 Jun '14

Hello, Thanks for your remarks, I am sending a corrected patch. Regards

1 0

Re: oleaut32: Fix TLB dependencies lookup
by Marvin 03 Jun '14

03 Jun '14

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=7404 Your paranoid android. === w2000pro (32 bit typelib) === typelib.c:5451: Test failed: got: 80029c4a

1 0

Re: [3/3] msvcrt: Implement 4k block flushing behavior.
by Piotr Caban 03 Jun '14

03 Jun '14

On 05/31/14 01:00, Grazvydas Ignotas wrote: > + } else if(wrcnt >= MSVCRT_WRITE_BLOCK_SIZE) { > + if(msvcrt_set_write_direction(file) != 0) > + break; > + > + if(file->_bufsiz && file->_ptr != file->_base) > + if(msvcrt_flush_buffer(file) == MSVCRT_EOF) > + break; > + > + if(MSVCRT__write(file->_file, ptr, MSVCRT_WRITE_BLOCK_SIZE) <= 0) { > + file->_flag |= MSVCRT__IOERR; > + break; > + } > + written += MSVCRT_WRITE_BLOCK_SIZE; > + wrcnt -= MSVCRT_WRITE_BLOCK_SIZE; > + ptr = (const char*)ptr + MSVCRT_WRITE_BLOCK_SIZE; This doesn't look right for me. It doesn't make sense to have some special size blocks written in different way. I think this is caused by 2 differences in native and wine's implementation of fwrite: - if you check file->_bufsiz value on windows it's set to 4096 (on wine it's 512), this is probably causing the flash to be done when 4096 bytes are written - probably there's some kind of optimization that writes integral number of buffers directly to file - I was not checking it but maybe native flushes the output when buffer is full, wine will exit fwrite with full buffer in this case I've also seen that _bufsiz is set to 0 on wine if buffer was not yet allocated. On windows it's value is 4096 just after opening the file. Cheers, Piotr

2 3

Re: [PATCH 4/6] d3d8/tests: Add a test for D3DUSAGE_WRITEONLY.
by Marvin 03 Jun '14

03 Jun '14

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=7398 Your paranoid android. === w8 (32 bit device) === device.c:2397: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:3039: Test failed: Expected wndproc 0x412780, got 0x412780.

1 0

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4
by Stefan Dösinger 03 Jun '14

03 Jun '14

Am 23.05.2014 um 00:23 schrieb Andrei Slăvoiu <andrei.slavoiu(a)gmail.com>: > Mesa drivers do not expose EXT_GPU_SHADER4 as all functionality it offers is > already part of OpenGL 3.0. This causes all cards that are not explicitly > recognized by wine (for example all GCN cards) to be treated as DX9 cards and > presented to Windows apps as Radeon 9500. The problem is that without GL_EXT_gpu_shader4 or GL_ARB_shader_texture_lod we cannot handle the texldd instruction. Right now we cannot use core contexts, so unless the driver exposes one of those extensions in compatibility contexts we are stuck on a shader model 2 feature level :-( . The level detection your patch changes isn't directly related to this, as the shader model version support is controlled differently. But a Radeon 9500 matches a card with shader model 2 support much better than a Radeon R9. Does this driver / gpu combination support GL_ARB_shader_texture_lod?

3 9

[PATCH 0/4] Improve compilation with musl libc
by Felix Janda 03 Jun '14

03 Jun '14

Hello, I'm trying to reduce the number of patches required to build wine on a musl libc[1] based system. The first two patches merely fix warnings because of use of deprecated headers. So they are not strictly necessary. The patches should also update configure but why is configure at all in the git repo? To compile wine without patches two other issues remain: Various tools used during the build expect getopt_long_only() to have GNU semantics. They don't expect that musl's getopt_long_only() stops after the first non-option argument. The cleanest fix seems to be to add a configure check testing whether getopt_long_only() behaves correctly instead of just testing for its existence. Then there are problems with compiling dlls/ws2_32/socket.c related to IPX but I haven't investigated their cause yet. [1]: http://musl-libc.org Felix Janda (4): Use <poll.h> instead of <sys/poll.h> Remove unecessary <sys/signal> includes Add missing includes of <poll.h> (POLLIN,...) dnsapi: Replace NETDB_INTERNAL by -1 configure.ac | 2 -- dlls/dinput/joystick_linux.c | 4 ++-- dlls/dinput/joystick_linuxinput.c | 4 ++-- dlls/dnsapi/query.c | 2 +- dlls/iphlpapi/icmp.c | 4 ++-- dlls/kernel32/console.c | 4 ++-- dlls/ntdll/file.c | 5 +---- dlls/ntdll/serial.c | 4 ++-- dlls/ntdll/signal_arm.c | 3 --- dlls/ntdll/signal_arm64.c | 3 --- dlls/ntdll/signal_i386.c | 3 --- dlls/ntdll/signal_powerpc.c | 4 ---- dlls/ntdll/signal_x86_64.c | 3 --- dlls/ntdll/sync.c | 5 +---- dlls/rpcrt4/rpc_transport.c | 4 ++-- dlls/wineoss.drv/midi.c | 5 +---- dlls/winex11.drv/event.c | 5 +---- dlls/wininet/internet.c | 5 +---- dlls/wininet/netconnection.c | 5 +---- dlls/winmm/time.c | 5 +---- dlls/ws2_32/socket.c | 5 +---- include/config.h.in | 6 ------ programs/winedbg/gdbproxy.c | 4 ++-- server/change.c | 3 +++ server/fd.c | 5 +---- server/file.c | 2 +- server/named_pipe.c | 2 +- server/object.h | 4 ++-- server/process.c | 2 +- server/queue.c | 3 +++ server/request.c | 2 +- server/serial.c | 2 +- server/signal.c | 5 +---- server/sock.c | 3 +++ server/thread.c | 2 +- 35 files changed, 42 insertions(+), 87 deletions(-) -- 1.8.5.5

3 8

Re: ntdll: Use lockfree implementation for get_cached_fd.
by Ken Thomases 02 Jun '14

02 Jun '14

On May 31, 2014, at 10:28 AM, Sebastian Lackner wrote: > Explanation: The basic idea of this patch is that we have a global > counter 'fd_cache_epoch' which is incremented, whenever the file > descriptor cache is updated. get_cached_fd() first reads the counter, > then the fd entry, and afterwards the counter again - if the counter has > changed we know that a second thread has maybe modified the content, and > have to read it again. The memory barrier is there to ensure that > compilers don't optimize away the two reads of 'fd_cache_epoch'. Please > note that: > > * the order of the write instructions when updating the content is > important - this way we ensure that threads only see either (0, *) = not > set, or a valid entry. > > * I assume that reading/writing up to the pointer size can be done as an > atomic operation (threads either see the old or new value, but no > partial updates). This assumption is also used in a lot other parts of > wine, for example here: > http://source.winehq.org/source/dlls/ntdll/sync.c#L1295 > [ It would probably be more safe to introduce special > interlocked_get/interlocked_set macros/functions for that, but not sure > what other people think about that... ] Thanks for working on this. Interesting stuff. I think there are still some issues. In order to ensure a consistent view of the ordering of memory operations, memory barriers have to be used in both the writer and the reader. The writer issues a write barrier after it has written and the reader issues a read barrier before it reads. The appropriate barriers are implicit in interlocked_xchg_add() for incrementing fd_cache_epoch, but the first read of it in get_cached_fd() has no read barrier before it. I think this is benign, though, because I think this can only result in the code thinking the epoch changed when it hasn't. It may retry unnecessarily. More problematic is the writing of the fd and its attributes. There are barriers implicit in the interlocked_xchg() which clears the fd, but there's no write barrier after the final write to it. There's no read barrier before the first read of them. You mention the order of writing, attributes first then fd, as being important. But there's no barrier in between the two operations, so either the compiler or the CPU could reorder either the writes or the reads, thwarting your design. The compiler can also reorder the reading of the fd_cache_epoch with respect to the reading of the fd or attributes. I think you can get this as the effective sequence: thread1 / get_cached_fd / read fd, get old fd thread2 / add_fd_to_cache / clear fd thread2 / add_fd_to_cache / increment epoch thread2 / add_fd_to_cache / set fd thread1 / get_cached_fd / read epoch thread1 / get_cached_fd / check if epoch has changed, conclude it hasn't thread1 / get_cached_fd / return old fd I think it's sufficient to have a write barrier after writing the fd and then a read barrier just before reading it. I _think_ that this obviates the need for the barrier at the bottom of the do-while loop. That is, you can just move that barrier up a line. I'm not 100% confident of my analysis of that. (Well, frankly, I'm never 100% certain of my analysis of this sort of code.) In the email thread regarding Daniel Horn's patch, I suggested an approach using interlocked_cmpxchg() to check if the fd had changed after reading the attributes. Was there a reason you rejected that approach? You mentioned an approach you experimented with using interlocked_cmpxchg64(). What was that about? Were you treating the fd and attributes combined as a single 64-bit value and then checking them both? Was that safer than my suggestion for some reason? If the only advantage is a slight performance improvement (especially in light of the huge difference that either approach has to the status quo, judging by your chart), then I'd argue for the simpler approach that's more easily analyzed for correctness. If the above issue is addressed, that leaves one remaining problem: get_cached_fd() can encounter a false negative: thread1 / add_fd_to_cache / set fd to -1 thread1 / add_fd_to_cache / increment epoch thread2 / get_cached_fd / read epoch thread2 / get_cached_fd / read attributes thread2 / get_cached_fd / read fd, gets -1 thread2 / get_cached_fd / check if epoch has changed, conclude it hasn't thread1 / add_fd_to_cache / set attributes thread1 / add_fd_to_cache / set fd thread2 / get_cached_fd / return -1 thread2 / server_get_unix_fd / see get_cached_fd as having failed since it returns -1 thread2 / server_get_unix_fd / do get_handle_fd server request thread2 / server_get_unix_fd / call add_fd_to_cache to cache the new fd I think you want to try get_cached_fd() again, inside the critical section, if the first call fails. -Ken

2 2

Re: [2/2] imagehlp: Implement (parts of) BindImageEx (try 8)
by Marvin 02 Jun '14

02 Jun '14

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=7391 Your paranoid android. === wvistau64 (64 bit image) === image.c:426: Test failed: Expected StatusRoutine to be called once with reason BindImportProcedure, but it was called 0 times === w2008s64 (64 bit image) === image.c:426: Test failed: Expected StatusRoutine to be called once with reason BindImportProcedure, but it was called 0 times

1 0

Re: [1/2] imagehlp: Implement (parts of) BindImageEx (try 8)
by Marvin 02 Jun '14

02 Jun '14

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=7390 Your paranoid android. === wvistau64 (64 bit image) === image.c:426: Test failed: Expected StatusRoutine to be called once with reason BindImportProcedure, but it was called 0 times === w2008s64 (64 bit image) === image.c:426: Test failed: Expected StatusRoutine to be called once with reason BindImportProcedure, but it was called 0 times

1 0

Video memory size detection in D3D
by Ruslan Kabatsayev 02 Jun '14

02 Jun '14

Hello all, It seems Wine doesn't use any way to reliably detect video memory size, and for many video cards needs it to be specified as HKCU\Software\Wine\Direct3D\VideoMemorySize key in registry. But there exist at least three (vendor-specific) GL/GLX extensions which seem to address exactly this. Namely, for Mesa it's GLX_MESA_query_renderer [1], for nVidia it's GL_NVX_gpu_memory_info [2], and for ATI/AMD it's GL_ATI_meminfo [3]. Mesa extension is shipping starting from Mesa 10.0, nVidia ships their extension in 195.XX drivers (said in specification; I have it exposed with my 313.09 driver), don't know status of ATI extension though (marked as "???" in spec). It'd be good if Wine could utilize these. Is there any work towards this already? Regards, Ruslan [1]: http://www.opengl.org/registry/specs/MESA/glx_query_renderer.txt [2]: https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt [3]: http://www.opengl.org/registry/specs/ATI/meminfo.txt

5 6

New Wine patches
by Chakke, Neha (GE Oil & Gas) 02 Jun '14

02 Jun '14

Hello , I am trying to run a GE software and hardware on Debian (Linux platform) using WineHQ. In order to run the hardware we need to install device drivers for USB (Cypress) . http://wiki.winehq.org/USB I have been trying to look for some solutions online since a week. Could you kindly send me the new wine patches and please guide me with the procedure. Thanks and regards, Miss Neha Chakke Engineering/Technology GE Oil & Gas Measurement & Control T: +49 (0) 2233 601 123 neha.chakke(a)ge.com<mailto:neha.chakke@ge.com> www.ge-mcs.com<http://www.ge-mcs.com/> [NewMeatball] GE Sensing & Inspection Technologies GmbH Robert-Bosch-Str. 3 50354 Hürth Germany

3 2

Re: [PATCH 3/3] vbscript: Fixed CInt(try 2)
by Marvin 02 Jun '14

02 Jun '14

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=7387 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 2/3] vbscript: Implemented CLng(try 2)
by Marvin 02 Jun '14

02 Jun '14

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=7386 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/3] vbscript: Implemented CDbl(try 2)
by Marvin 02 Jun '14

02 Jun '14

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=7385 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: shlwapi/tests: Skip if test ini file wasn't created
by Marvin 01 Jun '14

01 Jun '14

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=7382 Your paranoid android. === wvistau64 (32 bit ordinal) === ordinal.c:1934: Test failed: expected (L"01 \062c\0648\0627\0646, 2014") got (L"\200f01 \200f\062c\0648\0627\0646, \200f2") for date part ordinal.c:1960: Test failed: expected (L"01 \062c\0648\0627\0646, 2014") got (L"\200f01 \200f\062c\0648\0627\0646, \200f2") for date part === wvistau64 (64 bit ordinal) === ordinal.c:1934: Test failed: expected (L"01 \062c\0648\0627\0646, 2014") got (L"\200f01 \200f\062c\0648\0627\0646, \200f2") for date part ordinal.c:1960: Test failed: expected (L"01 \062c\0648\0627\0646, 2014") got (L"\200f01 \200f\062c\0648\0627\0646, \200f2") for date part

2 1

Re: ntdll: Use lockfree implementation for get_cached_fd. (try 2)
by Ken Thomases 01 Jun '14

01 Jun '14

On May 31, 2014, at 12:05 PM, Sebastian Lackner wrote: > Changes in try 2: > > * Always try to access the fd cache two times - this ensures that we > don't release a file descriptor when its still in use by a second thread. Heh. Well, you can ignore that part of my reply to your previous try. :) > * Replace interlocked_xchg() with an assert(). The original code looks > like its valid that the fd is nonzero at this point, but in fact this > would cause releasing a file descriptor which is still in use. I'll leave it to others to comment on that. > Replacing with an assert() also saves a couple of CPU cycles. I understand that this is an attempt to improve performance, but I don't think it's necessary to squeeze every last CPU cycle out of this code. -Ken

2 1

Re: ntdll/tests: Fix exception test failures on x86_64.
by Marvin 31 May '14

31 May '14

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=7354 Your paranoid android. === w2000pro (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00950000/00950001 exception: unhandled exception 80000004 at 00950000 exception.c:406: Test failed: 42: Wrong exception address 7C5C20B0/00950001 === wxppro (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00A30000/00A30001 exception: unhandled exception 80000004 at 00A30000 exception.c:406: Test failed: 42: Wrong exception address 7C80DF3C/00A30001 === wvistau64 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003D0000/003D0001 exception: unhandled exception 80000004 at 003D0000 exception.c:406: Test failed: 42: Wrong exception address 7751ED97/003D0001 === w2008s64 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:406: Test failed: 42: Wrong exception address 77E5ED97/003C0001 === w7u (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:406: Test failed: 42: Wrong exception address 77CDE34F/003C0001 === w8 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00290000/00290001 exception: unhandled exception 80000004 at 00290000 exception.c:406: Test failed: 42: Wrong exception address 77174D17/00290001

1 0

Re: dmscript/tests: Test some IPersistStream methods of DMScriptTrack.
by Marvin 31 May '14

31 May '14

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=7339 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)
by Stefan Dösinger 30 May '14

30 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-29 01:33, schrieb Andrei Slăvoiu: > Drop the check for glsl_version. All wine shaders use #version 120 > so it doesn't matter. That's not quite right. Yes, it is true that we never use GLSL 130, so the version check isn't representative for what wined3d actually supports. For shader model 4 support we need much more than just GLSL 130, half of the d3d10 infrastructure is still missing. GL_ARB_shader_texture_lod doesn't imply shader model 4 support. My Radeon X1600 supports this extension on OSX, and this is a shader model 3 card. The X1600 doesn't support EXT_gpu_shader4 or GLSL 130. The point of this code is to check the capabilities of the card, not the capabilities of our d3d implementation. Thus to prevent SM 3 cards from being reported with PCI IDs that suggest SM 4 capabilities you need to check for all the other functionality that's supported by EXT_gpu_shader4 / GLSL 130. Even if we have a SM 4 capable card our d3d9 implementation does not expose SM 4 support. But neither does Microsoft's d3d9 implementation. There's also GLX_MESA_query_renderer. It gives us the PCI IDs and video memory size directly, without all the string parsing guesswork. We cannot use it wined3d directly. A possible approach would be to expose a similar WGL_WINE/MESA_query_renderer extension from winex11.drv and winemac.drv and use that in wined3d. The current wined3d guesswork code could be moved to winex11.drv and used in cases where GLX_MESA_query_renderer is not supported. (OSX has similar functionality that's always available) User32 also has a function (EnumDisplayDevices) to query the GPU identification string, and some applications (Company of Heroes demo) fail if the user32 GPU name differs from the d3d9 GPU name. So maybe a WGL extension isn't quite the right interface, and it should be something that does not require a GL context so user32.dll can use it as well. EnumDisplayDevices does not export all the information wined3d needs though - the PCI IDs and video memory size are missing I think. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThvZZAAoJEN0/YqbEcdMwsY8QAJG1NQVMSqjwaguVR0cwwNXq IMYCRWL+5cJPxK4Eodt4bF+zZDObqCz9r3hAJVlkA6bJIcflNHJwedT0ddeOAfpe 0Xc8g+NvspN715yNt51PpzcnlSqh2vS18qp1JLb4l00pZuPt8PMNqC0gaePkv+tY 1wY3B/kgbl0TfcIRpxWbwZBcIAM2h4g+FGCHFPFeznhMYWqFaJ67OKW1KAdfpBTT lPZsaNDXtU8hSaVQYVk7ITulUl0C8tW/MExnh4zclz6b/wQuG+/M0WRg5v/YDlNq 0ZAsVqT60+MbepR87ehYDnLB7RMjZMjZhEZ4/drafFbOQBmqL7YJjgbFsbBBXLTt COf/1mjiz7TptUvSUyDRc27o1K+YP1UoswsVdXT37sWkP9gtHtQFeLLNx8ZuR4pa 2yQ7xNIBi7KPNBjz9Q0RKYvc11oGVUvFSuD0gLgNuHZxdOmBWwZyHeSce9adHHGU 5t4Oz0FsTZuEiiuJXPTDatp06KQQpUZ/c7FgcO7bxIpn/NNUCZGKZdKT/ZYM1waf BEtBL2Ov+DzRnvRM3/lVPdaiMD1IY54bqTeU7NOiKCEFhBl0elCAblj155tVaKdR 5WekiCEsvB8S4FE6stDa+GewpBWUZiVLGSL49S0MViPqAbkbgcjcNlRVg6IEH2Zo tyQIl6/9DwdY1TCllA9W =Z1W8 -----END PGP SIGNATURE-----

3 7

vs2013 support
by Daniel Lehman 29 May '14

29 May '14

Is anyone already working on VS2013 support (msvcp120.dll)? or have plans to? Thanks daniel

1 0

Re: [2/2] ws2_32: Properly implement SO_CONNECT_TIME (try 2)
by Marvin 29 May '14

29 May '14

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=7316 Your paranoid android. === wvistau64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === w2008s64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000

1 0

Re: [2/2] ws2_32: Properly implement SO_CONNECT_TIME
by Marvin 28 May '14

28 May '14

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=7301 Your paranoid android. === w2000pro (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === wvistau64 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w2008s64 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w7u (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w8 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === wvistau64 (64 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w2008s64 (64 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0

1 0

About wineserver and winsock
by Bruno Jesus 27 May '14

27 May '14

Hi all, after studying the ws2_32 dll code for some time while looking for ways to optimize it I started wondering why is the wineserver required (please don't stop reading yet). make test takes 45 seconds in my machine while it takes 25 seconds in a XP VM running on the same machine. The culprit is test_send() [1] which takes 24 seconds in wine and 1.8 seconds in windows. This long time is related to the 1 million recv() calls in test_send(). Each call to recv() has to call wineserver to do a enable_event(FD_READ) operation, if you comment that line out [2] wine magically takes 1.7 seconds, just like windows does (obviously commenting that line generaters other errors related to event sequences). So, in simple words: what if we move all wineserver socket code to a thread that is started in the ws2_32 DLL. I know this may sound very silly for the experienced wine developers, maybe some operations are impossible without the wineserver, maybe there is much more things affected, but I think it's better to ask and get crushed with (hopefully) constructive criticism than forget about the idea. My main objective with this is to speedup the whole implementation and properly implement the select call (different socket states result in different checks required) and WSACleanup call (which needs to close every open socket on last cleanup) and some other get/setsockopt stuff. [1] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ws2_32/tests/sock.c#l… [2] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ws2_32/socket.c#l6684 Best wishes, Bruno

5 4

Re: [PATCH 2/2] propsys: Forward exported calls to corresponding methods
by Jacek Caban 27 May '14

27 May '14

Hi Nikolay, On 05/27/14 11:09, Nikolay Sivov wrote: > From 386a536f9ae75505cd95601e4a8ca936b826658c Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <nsivov(a)codeweavers.com> > Date: Mon, 26 May 2014 22:38:35 +0400 > Subject: [PATCH 2/2] propsys: Forward exported calls to corresponding methods It seems to me that forwarding the other way be more logical. Jacek

1 0

Re: [PATCH 2/2] shell32: Improve checking for folder index validity in NameSpace()
by Marvin 27 May '14

27 May '14

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=7279 Your paranoid android. === w2000pro (32 bit shelldispatch) === shelldispatch.c:94: Test failed: got 00000001 shelldispatch: unhandled exception c0000005 at 0040EB1D

1 0

Re: [PATCH] vbscript: Implemented CDbl(try 2)
by Marvin 27 May '14

27 May '14

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=7277 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: mshtml: Added IHTMLTableRow::insertCell method implementation. (try 3)
by Jacek Caban 26 May '14

26 May '14

Hi Zhenbo, This version looks good except: On 05/24/14 11:56, Zhenbo Li wrote: > + *row = (IDispatch *)&elem->IHTMLElement_iface; > + IDispatch_AddRef(*row); > + IHTMLElement_Release(&elem->IHTMLElement_iface); You don't need to add such AddRef()/Release() calls. Reference count doesn't change anyway. Cheers, Jacek

1 0

Re: Japanese translation updates (try 4) for 1.7.19.
by Akihiro Sagawa 25 May '14

25 May '14

On Wed, 21 May 2014 12:09:30 -0400 (EDT), Toshiaki Hirose wrote: > From 16832fa3d12785db591144f2005f953dd8937b9f Mon Sep 17 00:00:00 2001 > Message-Id: <16832fa3d12785db591144f2005f953dd8937b9f.1400688520.git.t_hirose(a)aol.com> > From: Toshiaki Hirose <t_hirose(a)aol.com> > Date: Thu, 22 May 2014 01:08:29 +0900 > Subject: [PATCH] Japanese translation updates(try4) for 1.7.19 > > --- > po/ja.po | 159 ++++++++++++++++++++++++++------------------------------------- > 1 file changed, 65 insertions(+), 94 deletions(-) Looks good to me. Akihiro Sagawa

2 1

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory. (try 2)
by Zhenbo Li 24 May '14

24 May '14

Excuse me, could someone have a look with this patch? Thank you. 2014-05-21 9:23 GMT+08:00 Zhenbo Li <litimetal(a)gmail.com>: > Thanks Alexandre > > try 2: > 1. Let SHELL_DeleteDirectoryW return DWORD > 2. Get the right return value by > ret = SHNotifyRemoveDirectoryW(pszDir) > origin: > Thanks Bruno Jesus > This patch would fix bug 34324, by returning correct > error value of SHFileOperation. > > --- > dlls/shell32/shlfileop.c | 55 > +++++++++++++++++++++--------------------- > dlls/shell32/tests/shlfileop.c | 4 --- > 2 files changed, 27 insertions(+), 32 deletions(-) > > -- Have a nice day! Zhenbo Li

1 0

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 4)
by Stefan Dösinger 23 May '14

23 May '14

Am 21.05.2014 um 08:23 schrieb Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > Moved to be client.c. > Flags are printed as 0x%08x. You may want to move the test to tests/client.c as well. Otherwise this looks good to me.

1 0

Re: mshtml: Added IHTMLTableRow::insertCell method implementation. (try 2)
by Jacek Caban 23 May '14

23 May '14

Hi Zhenbo, On 05/23/14 14:20, Zhenbo Li wrote: > iff --git a/dlls/mshtml/htmltablerow.c b/dlls/mshtml/htmltablerow.c > index 731b403..f1b672b 100644 > --- a/dlls/mshtml/htmltablerow.c > +++ b/dlls/mshtml/htmltablerow.c > @@ -308,8 +308,27 @@ static HRESULT WINAPI HTMLTableRow_get_cells(IHTMLTableRow *iface, IHTMLElementC > static HRESULT WINAPI HTMLTableRow_insertCell(IHTMLTableRow *iface, LONG index, IDispatch **row) > { > HTMLTableRow *This = impl_from_IHTMLTableRow(iface); > - FIXME("(%p)->(%d %p)\n", This, index, row); > - return E_NOTIMPL; > + nsIDOMHTMLElement *nselem; > + HTMLElement *elem = NULL; You shouldn't need to initialize it here. > + nsresult nsres; > + HRESULT hres; > + > + TRACE("(%p)->(%d %p)\n", This, index, row); > + nsres = nsIDOMHTMLTableRowElement_InsertCell(This->nsrow, index, &nselem); > + if(NS_FAILED(nsres)) { > + ERR("Insert Cell at %d failed: %08x\n", index, nsres); > + return E_FAIL; > + } > + > + hres = HTMLTableCell_Create(This->element.node.doc, nselem, &elem); > + if (FAILED(hres)) { > + ERR("Create TableCell failed: %08x\n", hres); > + return hres; > + } > + nsIDOMHTMLElement_Release(nselem); There it a leak in error case. Move Release call before if statement. > + > + hres = IHTMLElement_QueryInterface(&elem->IHTMLElement_iface, &IID_IDispatch, (void **)row); > + return hres; You don't need QueryInterface here. Cast is fine as long as it's done on an interface inheriting from IDispatch (but not on object, as you did in previous version of the patch). Cheers, Jacek

1 0

Re: (try 2) gdi32/tests: tmLastChar is solely governed by the last entry before 0xffff in the cmap.
by Marvin 23 May '14

23 May '14

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=7224 Your paranoid android. === w2000pro (32 bit font) === font.c:5077: Test failed: got 00a8 === wxppro (32 bit font) === font.c:5077: Test failed: got 00a8 === wvistau64 (32 bit font) === The test timed out === w2008s64 (32 bit font) === font.c:5077: Test failed: got 00a8 === w7u (32 bit font) === font.c:5077: Test failed: got 00a8 === w8 (32 bit font) === font.c:5077: Test failed: got 00a8 === wvistau64 (64 bit font) === font.c:5077: Test failed: got 00a8 === w2008s64 (64 bit font) === font.c:5077: Test failed: got 00a8

1 0

Re: [PATCH 3/3] vbscript: Fixed CInt
by Nikolay Sivov 23 May '14

23 May '14

> - hres = to_int(arg, &val); > + V_VT(&v) = VT_EMPTY; > + hres = VariantChangeType(&v, arg, 0, VT_I2); > if(FAILED(hres)) > return hres; > > - return return_int(res, val); > + if(!res) { > + VariantClear(&v); > + return DISP_E_BADVARTYPE; > + } > + > + *res = v; > + return S_OK; I can't comment on removing to_int() here, I don't know this code well. But is it really possible to get a NULL 'res'? It looks like you can just use 'res' without intermediate 'v'. In any case you don't need VariantClear() on VT_I2 variant.

2 1

Re: [PATCH 3/3] vbscript: Fixed CInt
by Marvin 23 May '14

23 May '14

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=7223 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 2/3] vbscript: Implemented CLng
by Marvin 23 May '14

23 May '14

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=7222 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/3] vbscript: Implemented CDbl
by Marvin 23 May '14

23 May '14

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=7221 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Debugging wine with winedbg
by Alexander Almaleh 21 May '14

21 May '14

I'm trying to debug Wine, and I want to step into the BitBlt function using winedbg. I've set a breakpoint at BitBlt, and it is being hit, however, when I list the source code, it points somewhere completely differently in the source. I have no idea why that is. Does it mean that Wine is not setup correctly for debugging? I cloned Wine from Git a few days ago, and I've used "./tools/wineinstall" to compile and install it. This is an excerpt of the debugging session. sashoalm@aspire:~$ winedbg /tmp/xformtest.exe WineDbg starting on pid 0022 start_process () at /home/sashoalm/Workspace/wine/wine-git/dlls/kernel32/process.c:1097 0x7b86235f start_process+0x5f [/home/sashoalm/Workspace/wine/wine-git/dlls/kernel32/process.c:1097] in kernel32: movl %edi,0x4(%esp) 1097 return call_process_entry( peb, entry ); Wine-dbg>break BitBlt fixme:dbghelp_dwarf:dwarf2_parse_subprogram Unhandled Tag type 0x1 at ctx(0x32bfec,L"gdi32<elf>"), for debug_info(abbrev:0x15f2148,symt:0x175a660) Breakpoint 1 at 0x7ebcac00 BitBlt in gdi32 Wine-dbg>cont Stopped on breakpoint 1 at 0x7ebcac00 BitBlt in gdi32 Wine-dbg>list 1097 return call_process_entry( peb, entry ); 1098 } 1099 1100 1101 /*********************************************************************** 1102 * set_process_name 1103 * 1104 * Change the process name in the ps output. 1105 */ 1106 static void set_process_name( int argc, char *argv[] ) 1107 { Wine-dbg>n copy_bitmap () at /home/sashoalm/Workspace/wine/wine-git/dlls/user32/cursoricon.c:382 382 DeleteDC( dst );

1 1

Vacations
by Alexandre Julliard 21 May '14

21 May '14

Folks, I'll be away for the next two weeks, though I may still push some commits if I can get decent Internet. I'm also going to skip next week's release, so 1.7.20 should happen on June 13. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] add function iphlpapi/CreateSortedAddressPairs, FreeMibTable
by Bruno Jesus 21 May '14

21 May '14

This patch is just a hack, I'll send a correct stub later. On Wed, May 21, 2014 at 8:10 AM, Akira Nakagawa <matyapiro31(a)gmail.com> wrote: > -- universe* god::bigbang (void); //and then it all began...

2 1

Re: [patch]japanese translation updates for 1.7.19.
by Akihiro Sagawa 21 May '14

21 May '14

On Tue, 20 May 2014 13:38:12 -0400 (EDT), Toshiaki Hirose wrote: > po/ja.po | 159 ++++++++++++++++++++++++++------------------------------------- > 1 file changed, 65 insertions(+), 94 deletions(-) Hi, Hirose-san, I just figure out two points. Following msgid line introduces unnecessary changes. > #: oleacc.rc:97 > -#, fuzzy > -#| msgid "Normal" > msgctxt "object state" > -msgid "normal" > -msgstr "標準" > +msgid "normal" > +msgstr "normal" This change might be unintentional because other oleacc resources aren't translated yet. If you adopt this translation, please remove redundant "(&R)". > #: oleacc.rc:104 > -#, fuzzy > -#| msgid "&Read Only" > msgctxt "object state" > msgid "read only" > msgstr "読み取り専用(&R)" Otherwise looks fairly good. Regards, Akihiro Sagawa

1 0

Re: [1/2] ws2_32: Avoid memory allocation for simple sends
by Austin English 21 May '14

21 May '14

On Mon, May 19, 2014 at 2:16 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > send() will ever use a single wsabuffer structure and most common > applications use of WSASend() will also send a single buffer. Saves > over 6 thousand calls to HeapAlloc in make test. > In (very non-scientific) timing runs, these two patches reduced valgrind test time by ~20% (5 vs 4 minutes), thanks! -- -Austin

2 1

Re: [PATCH 1/2] riched20: Implement ITextSelection::GetText.
by Nikolay Sivov 21 May '14

21 May '14

> +HRESULT ME_ITextGetText(ME_TextEditor *editor, ME_Cursor *start, ME_Cursor *end, BSTR *pb) DECLSPEC_HIDDEN; Is this really needed? > + buffer = heap_alloc((nChars + 1) * sizeof(WCHAR)); > + if (!buffer) > + return E_OUTOFMEMORY; > + ME_GetTextW(editor, buffer, nChars, start, nChars, 0); > + buffer[nChars] = 0; > + /* FIXME: a '\r' should be appended at the end of a story */ > + *pb = SysAllocString(buffer); > + heap_free(buffer); This could be simplified with SysAllocStringLen().

2 3

BitBlt doesn't honor the rotation specified by SetWorldTransform
by Alexander Almaleh 21 May '14

21 May '14

I have a test program that shows how BitBlt does not support rotation, when the rotation is specified by SetWorldTransform. Interestinly, the Rectangle() function works correctly and the rectangle is rotated. Here's a screenshot of the program in VirtualBox and in Wine<http://imgur.com/TIYx7XU> . Here is the code of the program. I'm setting a rotation XFORM, and then calling BitBlt. I load a bitmap file from the current directory for the BitBlt. hdc = BeginPaint(hWnd, &ps); double angle = 0.385398163; XFORM xf; xf.eDx = 0; xf.eDy = 0; xf.eM11 = cos(angle); xf.eM12 = sin(angle); xf.eM21 = -sin(angle); xf.eM22 = cos(angle); SetGraphicsMode(hdc, GM_ADVANCED); SetWorldTransform(hdc, &xf); HBITMAP hbmp = (HBITMAP) LoadImage( NULL, L"a.bmp", IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE); HDC hmemdc = CreateCompatibleDC(hdc); SelectObject(hmemdc, hbmp); BitBlt(hdc, 100, 0, 150, 50, hmemdc, 0, 0, SRCCOPY); EndPaint(hWnd, &ps);

1 0

Re: [PATCH 2/2] riched20: Implement ITextSelection::GetChar.
by Marvin 21 May '14

21 May '14

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=7197 Your paranoid android. === wvistau64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF57FACFA === w2008s64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF745ACFA

1 0

Re: [PATCH 1/2] riched20: Implement ITextSelection::GetText.
by Marvin 21 May '14

21 May '14

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=7196 Your paranoid android. === wvistau64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF57FACFA === w2008s64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF745ACFA

1 0

Re: mshtml: Added IHTMLTableRow::insertCell method implementation.
by Zhenbo Li 21 May '14

21 May '14

Sorry, I've found that this patch may have some problems. Please ignore that, and I'll send a fixed one later. 2014-05-21 9:45 GMT+08:00 Zhenbo Li <litimetal(a)gmail.com>: > --- > dlls/mshtml/htmltablerow.c | 26 ++++++++++++++++++++++++-- > dlls/mshtml/tests/dom.c | 7 +++++++ > 2 files changed, 31 insertions(+), 2 deletions(-) > > -- Have a nice day! Zhenbo Li

1 0

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory. (try 2)
by Marvin 21 May '14

21 May '14

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=7194 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

1 0

Re: [PATCH 1/2] wined3d: Set palettes on the swapchain (v2).
by Henri Verbeet 20 May '14

20 May '14

On 20 May 2014 13:09, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -3372,7 +3301,7 @@ static BOOL color_in_range(const struct wined3d_color_key *color_key, DWORD colo > > void d3dfmt_p8_init_palette(const struct wined3d_surface *surface, BYTE table[256][4]) > { > - const struct wined3d_palette *pal = surface->palette; > + const struct wined3d_palette *pal = surface->swapchain ? surface->swapchain->palette : NULL; > unsigned int i; > > if (!pal) This function is a bit silly. I think all callers should be able to just use palette->colors[], and avoid the extra copy. I'd guess that if no palette is set on the swapchain it should use the system palette, but perhaps it's ok to leave that undefined for now. > @@ -619,6 +625,14 @@ void x11_copy_to_screen(const struct wined3d_swapchain *swapchain, const RECT *r > > TRACE("swapchain %p, rect %s.\n", swapchain, wine_dbgstr_rect(rect)); > > + if (swapchain->palette && (swapchain->palette != swapchain->last_gdi_blt_palette > + || swapchain->palette->changed)) > + { > + wined3d_palette_apply_to_dc(swapchain->palette, swapchain->front_buffer->hDC); > + swapchain->last_gdi_blt_palette = swapchain->palette; > + swapchain->palette->changed = FALSE; > + } > + > front = swapchain->front_buffer; > if (front->resource.map_count) > ERR("Trying to blit a mapped surface.\n"); This is problematic in wined3d, because you can have multiple swapchains using the same palette. In practice that never happens, but that depends on knowing about everything that calls wined3d. If you really need this kind of scheme you'd have to make "palette->changed" a counter, and then iterate over all swapchains on wrap, but couldn't you just create a GDI palette for the wined3d palette, and then select that into the DC for the blit? Or just always update the palette, which is pretty much what we do now in the GL case.

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel