March 2014 - Wine-Devel - list.winehq.org

Re: [2/4] widl: Pass type attributes from write_array_tfs to write_pointer_description.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > This allows to differentiate strings and write appropriate rpc type >> > (FC_C_C[W]STRING instead of FC_[W]CHAR). >> >> It also changes some pointers from UP to RP, that doesn't look right. > > I don't see any changes in server_c.c and server_s.c in dlls/rpcrt4/tests, > do you see this somewhere else? In many of the generated proxy files, in actxprxy for instance. -- Alexandre Julliard julliard(a)winehq.org

March 20, 2014

Re: [2/4] widl: Pass type attributes from write_array_tfs to write_pointer_description.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > This allows to differentiate strings and write appropriate rpc type > > (FC_C_C[W]STRING instead of FC_[W]CHAR). > > It also changes some pointers from UP to RP, that doesn't look right. I don't see any changes in server_c.c and server_s.c in dlls/rpcrt4/tests, do you see this somewhere else? -- Dmitry.

March 20, 2014

Re: [2/4] widl: Pass type attributes from write_array_tfs to write_pointer_description.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This allows to differentiate strings and write appropriate rpc type > (FC_C_C[W]STRING instead of FC_[W]CHAR). It also changes some pointers from UP to RP, that doesn't look right. -- Alexandre Julliard julliard(a)winehq.org

March 20, 2014

Re: [4/4] rpcrt4/tests: Add a couple of tests for marshalling an array of strings. Resend.

by Dmitry Timoshkov

Marvin <testbot(a)winehq.org> wrote: > 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=5800 > > Your paranoid android. > > > === build (build) === > Make failed This is because testbot didn't use widl with previous patches from sequence applied and used a broken one instead. -- Dmitry.

March 20, 2014

Re: [4/4] rpcrt4/tests: Add a couple of tests for marshalling an array of strings. Resend.

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=5800 Your paranoid android. === build (build) === Make failed

March 20, 2014

wintab32: fixing a typo which prevented sending correct pkSerialNumber

by Eriks Dobelis

This submission Obsoletes patch id#103302. I split it into parts for easier review and will later submit the rest of patches, but each of them will resolve a single issue and they are not interdependent. Common goal is to resolve http://bugs.winehq.org/show_bug.cgi?id=18517. This patch fixes a typo in a code, which was a cause for wrong pkSerialNumber values to be sent in messages. TRACE entries showed correct values, because TRACE statement was executed before actual sending of the packet. Due to this it took quite a time to spot the problem :) dlls/wintab32/context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

March 20, 2014

Re: [PATCH]msvcr110: added missing functions in msvcr110.spec

by Piotr Caban

On 03/19/14 23:39, Natalino Cordeiro wrote: > +@ stub -arch=arm ?_NewTokenState(a)_CancellationTokenState@details(a)Concurrency@@SAPAV123(a)XZ > @ stub -arch=win32 ?_NewTokenState(a)_CancellationTokenState@details(a)Concurrency@@SAPAV123(a)XZ The ?_NewTokenState(a)_CancellationTokenState@details(a)Concurrency@@SAPAV123(a)XZ function is already exported on arm (there's other entry with the same name and -arch=win32 specifier). > -@ stub -arch=i386,win64 __crtCompareStringEx > +@ stub -arch=arm,i386,win64 __crtCompareStringEx It's not really important but in this case -arch option may be removed. Cheers, Piotr

March 20, 2014

Re: [PATCH] scrrun/tests: Update idl file in tests

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

March 20, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-03-19 22:45, schrieb Christopher Thielen: > I determined this isn't the User32 cursor stuff. It's probably a > D3D surface with incorrect properties. Apitrace works for d3d9. > Can anyone recommend an OpenGL debugger or other mechanism for > exploring the surfaces of a given scene and playing with their > properties? My guess is the tools are pretty primitive for this > kind of thing. Did you see if d3d+warn writes anything about failed surface creation? You can try to record a game drawing with apitrace on Windows and see if it plays back correctly on Wine. Also check if the playback shows the mouse pointer in Windows. I don't know if d3d9 recording with apitrace works in Wine - it might just work, or it might be missing some DECLSPEC_HOTPATCH markers on some d3d9 functions. You can also use the Linux version of apitrace to record the opengl calls wined3d creates. This will probably not help you in your case. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTKhZ3AAoJEN0/YqbEcdMwuxsP/iK9wDECv6CoMjYxjDo1yxQV jPC0KbSUw2DwUl0fFTCdWi6PxeTUoz8Hp2IC60D07BvGDiPaxJwRvewfO5jeYuqr sINzPgk5NgnZjkUN+cs4oGYlEFXY4p02eSe3uZhihlD0lnbJ0pV/g+8f4RPeIctM acTdC6kaIOUQLkRGliOotaj3w27e5QomXiaHcn1l8Ov3of7dBnJtg7hJTvlymL0g bUOpnCVHtN1BoeWwQUPUEzhqMjmU4gUCgBZ7lBDsbReeNmFHoeR0QaIqC8EWKr0D jznbKuAjuK+9GB/cVhqJj+hHlCaj6xoyNfOQQ34KHYcdtbAMhOTCkJbKzPmCeH8r xU3C2nSH88fld/Ie7oULE671XUNnXjPgDQPIcyeBC3PYZ33dR5vzLJrMA63/zA9X dP2qiF/A2N7Sk0Mq0FHtKcLICo9W+w7AXOdksZlrWEX4iiUB6LX3sQ+vMm+IePL0 WxcxP4CEAhXGiu/bub4hj8y3BbvbfyQklrZ4cz05iIf+WS4xYo6cwZ53ciVpgwBu V52s8N/XpC6QSy7UpqV1b6JuvMliHlLKGSbCZMezbsB6mShKdGyq45T1JhGukkh0 Q3DEQoX5TQSg8RqyRwr8coDZDwD0zese6uE+aVuzzznyY0LrTDo4Jio+Y3mWL45e jivFvw1C6uoFTKPqU8oM =QPSs -----END PGP SIGNATURE-----

March 19, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Christopher Thielen

I determined this isn't the User32 cursor stuff. It's probably a D3D surface with incorrect properties. Can anyone recommend an OpenGL debugger or other mechanism for exploring the surfaces of a given scene and playing with their properties? My guess is the tools are pretty primitive for this kind of thing. On 2/18/14, 7:19 PM, Christopher Thielen wrote: > Good point. Maybe knowing the offset isn't too useful for now. > > I still haven't figured out through what mechanism the game draws this > missing cursor. The D3D9 cursor functions never make a sound in the logs > and while the User32 LoadCursor/SetCursor/clipping stuff is called an > awful lot on initialization, it looks like it's always for the system > cursors. I also pasted in a method to dump to a .bmp file anything that > goes through LoadIcon and wound up with one icon I don't recall and > another which was simply Wine's icon. > > So, my hunch now is that the game draws the cursor using DirectX and > uses User32 only for setting mouse clipping. > > Is there a decent way to dump as a file every DX resource loaded that's > under a certain size? I'd like to confirm my theory and maybe if I'm > lucky figure out which DX surface/texture is being drawn incorrectly (if > any). > > - Christopher Thielen > > On 02/18/2014 12:16 AM, Stefan Dösinger wrote: >> >> Am 18.02.2014 um 06:12 schrieb Christopher Thielen >> <christopher(a)thielen.co>: >>> Two questions: >>> 1) Is there a way to add timestamps to the TRACE statements in Wine? >> WINEDEBUG=+timestamp >> >> This adds timestamps to other traces, so you can do e.g. >> WINEDEBUG=d3d,timestamp to get a d3d trace with timestamps. >> >>> 2) If I know which file is opened by the game, is there a way to >>> debug from that point on, i.e. capture the fopen() and enable >>> +cursor,+resource,+d3d TRACES for say, only 5 seconds after that >>> point? Something along those lines? >> Afaik no. You could use some search and replace tricks in text editors >> or with command line text tools though. >>> >>> I can find the exact offset within the data file used to load the >>> missing resource - but I'd need a way to know when a fread() was that >>> far along. I figure if I can determine that I can determine if the >>> cursor is loaded as a Windows cursor or as a D3D surface and go from >>> there. >> Note that there are plenty of ways to open and read files. fopen and >> fread are just one of them. There are win32 equivalents of those C >> functions, and there are specific resource loading functions which >> you’ve probably already seen. >> > >

March 19, 2014