- wine-devel - winehq.org

Can my WINE program write to files in /usr directory?
by John Found 20 May '14

20 May '14

In my program I want to copy some files in the /usr and other system directories. Is it possible from WINE program and how? In the FAQ I read: >/!\ NEVER run Wine as root! Doing so gives Windows programs (and >viruses) full access to your computer and every piece of media >attached to it. Running with sudo also has these same risks but with >the added bonus of breaking the permissions on your ~/.wine folder >in the process. If you have run Wine with sudo you need to fix the >permission errors as described in the next question, and then run >winecfg to set Wine up again. You should always run Wine as the >normal user you use to login. Is it so important? -- asm32.info <johnfound(a)asm32.info>

4 7

Re: [PATCH] msxml3: removed unused allocation (Coverity)
by Marvin 20 May '14

20 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=7177 Your paranoid android. === w2008s64 (32 bit domdoc) === Unable to set the VM system time: the "nc -q0 '10.42.42.136' '4242'" command returned 1

1 0

Re: [2/2] server: Clear the queue's QS_SMRESULT bit when sending a new message.
by Alexandre Julliard 19 May '14

19 May '14

Vincent Povirk <madewokherd(a)gmail.com> writes: > This keeps the QS_SMRESULT bit in sync with the reply status of the > most recent sent message, if it happens that the > previously-most-recent sent message already has a reply. > wait_message_reply depends on this to work correctly. I believe you'll also need to set it again when the result is removed. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 3/3] user32: Don't rely on HMENU for showing popups
by Alexandre Julliard 19 May '14

19 May '14

Andrew Eikum <aeikum(a)codeweavers.com> writes: > The idea here is to push the conversions from HMENU to struct pointer > up the call stack until eventually we are only converting to/from > HMENUs near the client code border, so we don't depend on HMENU > internally at all. To do this right, you'd want to increase the refcount every time you get a pointer. Otherwise the pointer could become invalid as soon as control is transferred to the app through SendMessage (not that the current code always gets it right, but when using handles the problem is much reduced). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: vbscript: Support multibyte characters in Global_Chr
by Marvin 19 May '14

19 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=7147 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/2] mmdevapi: Clock rate should be in bytes for shared mode
by Marvin 19 May '14

19 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=7145 Your paranoid android. === w7u (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.501088 render.c:2005: Test failed: Got wrong volume: 0.501088 === w8 (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.671337 render.c:2005: Test failed: Got wrong volume: 0.671337

1 0

Re: [PATCH 1/2] mmdevapi: Make buffer size divisible by number of periods
by Marvin 19 May '14

19 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=7144 Your paranoid android. === w7u (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.501088 render.c:2005: Test failed: Got wrong volume: 0.501088 === w8 (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.671337 render.c:2005: Test failed: Got wrong volume: 0.671337

1 0

Re: [PATCH] vbscript: Implemented CCur
by Piotr Caban 19 May '14

19 May '14

On 05/19/14 08:47, Shuai Meng wrote: > +Call ok(CCur(0.000149) = 0.0001, "CCur(0.000149) = " & CCur(0.000149)) > +Call ok(getVT(CCur(0.000149)) = "VT_CY", "getVT(CCur(0.000149)) = " & getVT(CCur(0.000149))) > +Call ok(CCur(2147483647.99) = 2147483647.99, "CCur(2147483647.99) = " & CCur(2147483647.99)) > +Call ok(getVT(CCur(2147483647.99)) = "VT_CY", "getVT(CCur(2147483647.99)) = " & getVT(CCur(2147483647.99))) This tests are failing on polish locale. > +Call ok(CCur(MyObject) = 0, "CCur(MyObject) = " & CCur(MyObject)) > +Call ok(getVT(CCur(MyObject)) = "VT_CY", "getVT(CCur(MyObject)) = " & getVT(CCur(MyObject))) > +MyObject.myval = 1 > +Call ok(CCur(MyObject) = 1, "CCur(MyObject) = " & CCur(MyObject)) > +Call ok(getVT(CCur(MyObject)) = "VT_CY", "getVT(CCur(MyObject)) = " & getVT(CCur(MyObject))) > +MyObject.myval = 0 > +Call ok(CCur(MyObject) = 0, "CCur(MyObject) = " & CCur(MyObject)) > +Call ok(getVT(CCur(MyObject)) = "VT_CY", "getVT(CCur(MyObject)) = " & getVT(CCur(MyObject))) There are two identical tests on MyObject. MyObject.myval is set to 0 in first test (it's set this way in earlier tests). Thanks, Piotr

2 2

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory.
by Alexandre Julliard 19 May '14

19 May '14

Zhenbo Li <litimetal(a)gmail.com> writes: > @@ -353,8 +353,13 @@ static BOOL SHELL_DeleteDirectoryW(HWND hwnd, LPCWSTR pszDir, BOOL bShowUI) > HANDLE hFind; > WIN32_FIND_DATAW wfd; > WCHAR szTemp[MAX_PATH]; > + DWORD attrib; > > /* Make sure the directory exists before eventually prompting the user */ > + attrib = GetFileAttributesW(pszDir); > + if (attrib == INVALID_FILE_ATTRIBUTES || !(attrib & FILE_ATTRIBUTE_DIRECTORY)) > + return FALSE; It would be better to avoid a redundant file lookup, particularly since it's only to set last error (which BTW you are not setting at all in the non-directory case). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [website] German translation for release 1.7.19
by Frédéric Delanoy 19 May '14

19 May '14

On Sun, May 18, 2014 at 5:40 PM, Julian Rüger <jr98(a)gmx.net> wrote: > Hi Frédéric, > >> "writer" should probably be translated as well... > > I don't think there is a useful translation that is not clunky or sounds > awkward. Plus, "writer" is probably a familiar term to most users > because of i.e. LibreOffice Writer. LibreOffice Writer is an English product name, and maybe not known to non-techies (it's just a word processing application to them) IMHO. In German, it should probably be something like Redaktor, but you know German better than me ;-) Frédéric Delanoy

2 1

Re: msi: Prevent call to memset with a nullptr in get_tablecolumns function
by Hans Leidekker 19 May '14

19 May '14

On Sun, 2014-05-18 at 13:27 -0400, Daniel Beitler wrote: > This is a fix for bug #36139. > > It looks like calling memset with a nullptr is undefined behavior. Gcc > 4.9 will actually optimize out the "if(colinfo)" condition if memset was > called on colinfo before. > > > --- > dlls/msi/table.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) Looks good, thanks.

1 0

Re: [patch]Japanese Translation update
by Akihiro Sagawa 18 May '14

18 May '14

On Fri, 16 May 2014 10:08:47 -0400 (EDT), Toshiaki Hirose wrote: > From 67e0fca928a2f2de03adaf96f7a1f8f55e2cf85d Mon Sep 17 00:00:00 2001 > Message-Id: <67e0fca928a2f2de03adaf96f7a1f8f55e2cf85d.1400248197.git.t_hirose(a)aol.com> > From: Toshiaki Hirose <t_hirose(a)aol.com> > Date: Fri, 16 May 2014 22:49:46 +0900 > Subject: [PATCH] Japanese Translation Update for 1.7.18 > > --- > po/ja.po | 172 ++++++++++++++++++++++++--------------------------------------- > 1 file changed, 65 insertions(+), 107 deletions(-) Hello Hirose-san, Your translation is getting better, but it needs some more work. Could you read my comments and submit again? I also welcome your feedback. > #: oleacc.rc:97 > -#, fuzzy > #| msgid "Normal" > -msgctxt "object state" > msgid "normal" > -msgstr "標準" > +msgstr "normal" Msgctxt line can't be removed. The line indicates message context, and is used with msgid to specify translation. > #: oleacc.rc:98 > #: oleacc.rc:99 : : > #: oleacc.rc:128 Same as above. > #: regsvr32.rc:41 > msgid "" > "regsvr32: Invalid or unrecognized switch [%1]\n" > "\n" > msgstr "" > +"regsvr32: 無効または認識できない切り替えです[%1]\n" > +"\n" I'm not sure about this translation. This `switch' means `command-line switch'. In that case, we usually translate into `スイッチ'. For instance, see http://support.microsoft.com/kb/227091/ja vs http://support.microsoft.com/kb/227091/en-us . > #: regsvr32.rc:46 > msgid "regsvr32: Failed to unregister DLL '%1'\n" > -msgstr "" > +msgstr "regsvr32: DLL '%1'の登録消去に失敗しました。\n" You removed some full-stops, but didn't about this line. > #: regsvr32.rc:49 > msgid "regsvr32: Successfully installed DLL '%1'\n" > -msgstr "" > +msgstr "regsvr32: DLL '%1'のインストールに成功しました。\n" Ditto. Otherwise looks fine. Regards, Akihiro Sagawa

1 0

Re: [website] German translation for release 1.7.19
by André Hentschel 18 May '14

18 May '14

Am 17.05.2014 02:10, schrieb Julian Rüger: > +<date>16. Main 2014</date> -n, everything else is fine ;)

3 2

msvcp90/msvcp90.h: right-hand operand of comma expression has no effect
by Gerald Pfeifer 18 May '14

18 May '14

Building git head with GCC development sources (soon to be GCC 4.9.0) gives me the following warnings ../msvcp90/msvcp90.h:529:75: warning: right-hand operand of comma expression has no effect [-Wunused-value] ../msvcp90/msvcp90.h:530:77: warning: right-hand operand of comma expression has no effect [-Wunused-value] several times. Digging into this in more detail I see ../msvcp90/ios.c: In function 'basic_streambuf_char__Xsgetn_s': ../msvcp90/msvcp90.h:529:75: warning: right-hand operand of comma expression has no effect [-Wunused-value] #define memcpy_s( dst, size, src, count ) (memcpy( (dst), (src), (count) ), 0) ^ ../msvcp90/ios.c:1218:13: note: in expansion of macro 'memcpy_s' memcpy_s(ptr+copied, size, *this->prpos, chunk); ^ Someone must have written that code intentionally, so I am wondering how to best address this. Gerald

2 2

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory.
by Marvin 17 May '14

17 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=6958 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

2 2

Re: vbscript: Parse doubles with bigger precision in parse_numeric_literal
by Marvin 16 May '14

16 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=7112 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: gdi32/tests: tmLastChar is solely governed by the last entry before 0xffff in the cmap.
by Marvin 16 May '14

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

3 2

Wine Test analysis, report
by Jeremy White 16 May '14

16 May '14

Just wanted to report that I do periodically do my analysis. It looks as though the test bot is beginning to be usable again, although the results are currently ugly: http://www.winehq.org/~jwhite/fba08e34c447.html I'm waiting for Francois to report that things are essentially operational again; until I get that word, I'm not planning to beat the drum. Francois, can we get an update? Cheers, Jeremy

7 8

Re: audio reset failed
by Pawel Por 16 May '14

16 May '14

>>* I receive periodically the following error popup window: *>>* "Audio Reset Failed: Access violation at address 7BC503AA in module *>>* 'ntdll.dll'. Write of address F818611C" * >What is displaying this message? Wine itself does not contain the >message "Audio Reset Failed." This message is from the application that generates text voice messages using SAPI4 voices. This application works perfectly under wine launched in 32 bit linux. >>* When it occurs the audio hangs up and only the restart of the wine *>>* application helps. * >There is a list of sound-related debug log channels at ><http://wiki.winehq.org/Sound>. Getting a debug log with those >channels set could give us a clue as to what's going wrong. I've upgraded wine to version wine 1.7.18 (Arch Linux). I still receive the message: "Audio Reset Failed: Access violation at address 7BC4D272 in module 'ntdll.dll'. Write of address F82A011C" This time I've run wine with the following debug channels: +tid,+mmdevapi,+winmm,+driver,+msacm,+midi,+dsound,+dsound3d,+dmusic,+mci,+oss,+alsa,+coreaudio. I've attached the log. Please write me if I can provide anything else. Great thanks for your help.

2 1

Re: mshtml: Added IHTMLLocation::assign method implementation.
by Nikolay Sivov 16 May '14

16 May '14

> HTMLLocation *This = impl_from_IHTMLLocation(iface); > - FIXME("(%p)->(%s)\n", This, debugstr_w(bstr)); > - return E_NOTIMPL; > + TRACE("(%p)->(%s)\n", This, debugstr_w(bstr)); > + return HTMLLocation_put_href(iface, bstr); I don't know if it correct or not, but please use method wrappers when calling from interface pointer instead of calling implementation directly.

1 0

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 3)
by Alexandre Julliard 16 May '14

16 May '14

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > diff --git a/dlls/dpnet/Makefile.in b/dlls/dpnet/Makefile.in > index 541e104..70ccef0 100644 > --- a/dlls/dpnet/Makefile.in > +++ b/dlls/dpnet/Makefile.in > @@ -7,6 +7,7 @@ C_SRCS = \ > client.c \ > dpnet_main.c \ > lobbiedapp.c \ > + lobbyclient.c \ > peer.c \ > server.c \ > threadpool.c Please merge that code into some existing files, we don't need so many new files. -- Alexandre Julliard julliard(a)winehq.org

4 4

Re: [PATCH 2/5] wined3d: Set palettes on the swapchain.
by Henri Verbeet 16 May '14

16 May '14

On 15 May 2014 14:33, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/palette.c b/dlls/wined3d/palette.c > index 3f7e2ad..780f068 100644 > --- a/dlls/wined3d/palette.c > +++ b/dlls/wined3d/palette.c > @@ -136,8 +136,8 @@ HRESULT CDECL wined3d_palette_set_entries(struct wined3d_palette *palette, > if (resource->type == WINED3D_RTYPE_SURFACE) > { > struct wined3d_surface *surface = surface_from_resource(resource); > - if (surface->palette == palette) > - surface->surface_ops->surface_realize_palette(surface); > + if (surface->swapchain && surface->swapchain->palette == palette) > + surface->swapchain->swapchain_ops->swapchain_realize_palette(surface->swapchain); > } > } > I don't think this kind of thing should be needed. You should be able to make the palette texture that currently lives in the ARB program shader backend a property of the wined3d palette, and then presents can just make sure the palette texture is current. Something similar, if perhaps slightly more involved, should be possible for the GDI swapchain with GDI palettes.

2 3

Re: [PATCH 4/5] d2d1: Add the ID2D1RenderTarget interface.
by Jacek Caban 16 May '14

16 May '14

Hi Henri, On 05/16/14 09:59, Henri Verbeet wrote: > diff --git a/dlls/d2d1/d2d1_main.c b/dlls/d2d1/d2d1_main.c > index 9a389a2..d1e5e8f 100644 > --- a/dlls/d2d1/d2d1_main.c > +++ b/dlls/d2d1/d2d1_main.c > @@ -21,6 +21,9 @@ > #include "wine/port.h" > #include "wine/debug.h" > > +#include "winbase.h" > +#include "winuser.h" > +#undef DrawText It's probably better to place such #undef in .idl file itself (inside cpp_quote). That's what we already do in quite a few places and it avoids the need for hacking every .c file using the header. Jacek

1 0

Re: mshtml: Fixed a few more IE11 test failures.
by Marvin 15 May '14

15 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=7098 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2861: Test failed: unexpected command 74 === w8 (32 bit htmldoc) === htmldoc.c:2861: Test failed: unexpected command 74 htmldoc.c:2861: Test failed: unexpected command 74

1 0

Re: audio reset failed
by Pawel Por 15 May '14

15 May '14

> An HTML attachment was scrubbed... > URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20140513/8f5f34ee/at…> I've uploaded the wine log at (37 KB): http://www.sendspace.pl/en/file/294794be77c2a1703e60d94 thanks for your help

2 1

Re: [PATCH 7/7] oleacc: Add WindowFromAccessibleObject implementation
by Marvin 15 May '14

15 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=7083 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: oleacc: Add WindowFromAccessibleObject implementation
by Marvin 15 May '14

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

1 0

Re: [PATCH 6/7] oleacc: Add IOleWindow::GetWindow implementation in default client accessible object
by Marvin 15 May '14

15 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=7082 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: [PATCH 4/7] oleacc: Add IOleWindow interface stub to default client accessible object
by Marvin 15 May '14

15 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=7081 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: [PATCH 5/5] includes: Fix an in/out annotation in shobjidl.idl.
by Nikolay Sivov 15 May '14

15 May '14

On 5/15/2014 16:33, Stefan Dösinger wrote: > --- > include/shobjidl.idl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/shobjidl.idl b/include/shobjidl.idl > index c9297a8..ae42c2e 100644 > --- a/include/shobjidl.idl > +++ b/include/shobjidl.idl > @@ -3350,7 +3350,7 @@ interface ITransferAdviseSink : IUnknown > HRESULT FileFailure([in] IShellItem *item, > [in, unique, string] LPCWSTR itemname, > [in] HRESULT hr, > - [out, unique, size_is(crename)] LPWSTR rename, > + [in, out, unique, size_is(crename)] LPWSTR rename, > [in] ULONG crename); > HRESULT SubStreamFailure([in] IShellItem *item, > [in, string] LPCWSTR stream, According to PSDK existing attributes are correct. Where did you find additional [in] ?

3 3

Re: [PATCH 3/7] oleacc: Disable tests on old oleacc
by Marvin 15 May '14

15 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=7080 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: [PATCH 2/7] oleacc: Don't return partial data in GetRoleTextA if buffer is too small
by Marvin 15 May '14

15 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=7079 Your paranoid android. === wxppro (32 bit main) === main.c:96: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: [PATCH 4/4] xmllite/writer: Implement Flush() method
by Marvin 15 May '14

15 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=7075 Your paranoid android. === wvistau64 (32 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>?> === w2008s64 (64 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>ncoding="UT

1 0

Re: [PATCH 3/4] xmllite/writer: Initial support for starting a document
by Marvin 15 May '14

15 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=7074 Your paranoid android. === wvistau64 (32 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>?> === w2008s64 (64 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>ncoding="UT

1 0

Re: [PATCH 2/4] xmllite/writer: Initial support of output buffer creation
by Marvin 15 May '14

15 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=7073 Your paranoid android. === wvistau64 (32 bit writer) === writer.c:219: Test failed: got <?xml version="1.0"?>?> === w2008s64 (64 bit writer) === writer.c:219: Test failed: got <?xml version="1.0"?>ncoding="UT

1 0

Re: [PATCH 1/5] wined3d: Move get_dc palette updates to ddraw (v2).
by Henri Verbeet 15 May '14

15 May '14

On 15 May 2014 14:33, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +void __cdecl wined3d_palette_apply_to_dc(const struct wined3d_palette *palette, HDC hdc); Can we avoid "Hungarian" in wined3d, please?

1 0

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

15 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-14 06:46, schrieb Alistair Leslie-Hughes: > +#define COBJMACROS > +#include "windef.h" > +#include "winbase.h" > +#include "wingdi.h" > +#include "winuser.h" > +#include "objbase.h" > +#include "wine/debug.h" Another thing I did not notice before: Do you need them all? At least wingdi.h seems suspicious, I guess winuser.h shouldn't be needed either - unless dpnet pops up dialogs. > +static HRESULT WINAPI lobbyclient_QueryInterface(IDirectPlay8LobbyClient *iface, REFIID riid, void **ppobj) > ... > + IUnknown_AddRef(iface); > + *ppobj = This; IMO this should be *ppobj = &This->IDirectPlay8LobbyClient_iface. That way it doesn't break if someone uses > +static HRESULT WINAPI lobbyclient_EnumLocalPrograms(IDirectPlay8LobbyClient *iface, GUID* pGuidApplication, BYTE* pEnumData, DWORD* pdwEnumData, DWORD* pdwItems, DWORD flags) You de-hungarified flags, but not the others (pSomePointer, pdwSomePointerToADWord). There are many more cases in the other functions. > +static HRESULT WINAPI lobbyclient_ConnectApplication(IDirectPlay8LobbyClient *iface, DPL_CONNECT_INFO* pdplConnectionInfo, PVOID pvConnectionContext, DPNHANDLE* hApplication, DWORD dwTimeOut, DWORD flags) > +{ > + IDirectPlay8LobbyClientImpl *This = impl_from_IDirectPlay8LobbyClient(iface); > + > + FIXME("(%p)->(%p %p %p %d %x)\n", This, pdplConnectionInfo, pvConnectionContext, hApplication, dwTimeOut, flags); a DWORD is an unsigned value, it should use %u. This applies to dwTimeOut here, but there are other cases in other functions. > +static HRESULT WINAPI lobbyclient_SetConnectionSettings(IDirectPlay8LobbyClient *iface, DPNHANDLE hConnection, const DPL_CONNECTION_SETTINGS* pdplSessionInfo, DWORD flags) > +{ > + IDirectPlay8LobbyClientImpl *This = impl_from_IDirectPlay8LobbyClient(iface); > + > + FIXME("(%p)->(%d %p %x)\n", This, hConnection, pdplSessionInfo, flags); > + > + return E_NOTIMPL; > +} You might want a helper function that prints DPL_CONNECTION_SETTINGS at some point. I'm ok with adding this in a later patch. Don't forget to check for NULL before you print though. > + > + > +static const IDirectPlay8LobbyClientVtbl DirectPlay8LobbiedClient_Vtbl = > +{ Really minor nitpick: There's an extra newline. > +HRESULT DPNET_CreateDirectPlay8LobbyClient(IClassFactory *iface, IUnknown *outer, REFIID riid, void **obj) > +{ > + IDirectPlay8LobbyClientImpl *app; Why is it called "app"? > + HRESULT ret; > + > + TRACE("(%p, %s, %p)\n", outer, debugstr_guid(riid), obj); You forgot to print iface here. Is that intentional? > diff --git a/dlls/dpnet/tests/Makefile.in b/dlls/dpnet/tests/Makefile.in > index f6e45ea..5b97aa1 100644 > +#define WIN32_LEAN_AND_MEAN > +#include <stdio.h> Is this needed? I don't see a function call, but maybe I'm missing something +static HRESULT WINAPI DirectPlayLobbyMessageHandler(PVOID context, DWORD message_id, PVOID buffer) PJUNK There are more PJUNKs in this file. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTdIsTAAoJEN0/YqbEcdMwxkkQAJVt/Y/QT5MIj7VKXsOHwZLJ 2prBQIrzBCPZHxS8EyzEEI008kZ+M2hquPD5Eeinj5L69D4wV5sv6VIFBk2Gz40P SpJaCdE/Srjto+2MQAgRjJ1JMhNCKCWMGg/w+OBRtBs8JM63gHwQNk+ZUQpdl58B OdNpGPbj7Ynlqt+fENUOOxMrbHwToMU1BvgfBogVdWD1P2AnvlFuoRZxSoZuF9Kn 3kloiFs/hv266ZCof1ngrxVuc2uojHWdlev4t2bWYSNoXewIVVRzvtJEvJpveQjq bWzGFe6ZmIhmSJ+2nCnAhXpZjNAv2+o2bdUK1q7EAkUHHv8cb/rTJ+8yX7HiG0UD NxmAtM4EMwLOBRl2yOATR52Q47r195JFv/YOJUHPRW+wL8rIkE/FC6kk4h6zB9/r 5rwLNpWoqagdD9bSJ6LZneRoQzsJ+SMy+8FInnEfDpFZaHRPue4UPFoUNWHQd3f/ ruuIWcWwQwQ7msI8Nr2JgNstGNCO7d6XQfjvJDwqZUZwLihrxEiOa8fVfCRA54Lu hS3esozn+0oQWmSKPm9fw5OA4RIZGY2zLGf3mkFX9BLuBWmKCfxQ5t+1c0nv6Q/f ZSHjUSjem6aLtwq6+48gilS5MsbqsqDQXRE+rEBzFNzcJbQByyd+0yMiYckBajAp H7j+HVl6L6VSGTY9LrMu =S78r -----END PGP SIGNATURE-----

1 0

Support for DirectX 11
by Dyweni - Wine-Devel 14 May '14

14 May '14

Hi, I'd like to know if anyone has an idea on when DirectX 11 would be completed, at least to a point of being able to play DirectX 11 only games? Thanks, Dyweni

1 0

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 4)
by Henri Verbeet 14 May '14

14 May '14

On 14 May 2014 16:12, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/d3d9/tests/device.c | 133 ++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 107 insertions(+), 26 deletions(-) > Unfortunately this still fails for me on Windows. The returned counts change between runs, which could perhaps be related to the backbuffer size being larger than the window size. It does seem to reliably pass when either running the test in fullscreen mode, or changing the backbuffer size to e.g. 640x480. The former is probably the easier fix. > + ok(data.word[0] == (WORD)expected || broken(!data.word[0]), > + "Occlusion query returned an unexpected result (0x%.8x).\n", data.dword[0]); > + if (!data.word[0]) > + { > + skip("Occlusion query result looks broken, ignoring returned count.\n"); > + broken_occlusion = TRUE; > + } At 1024x768 for example, "expected" is going to be 0xc0000. Is this for drivers that always return 0 for occlusion queries, or is this for the testbot, which IIRC runs at the resolution? If it's really broken, I think this should also check for "(WORD)expected" being 0, and then use win_skip() instead of skip().

2 1

Re: oleaut32: Added debugstr_variant helper for better debug traces.
by Michael Stefaniuc 14 May '14

14 May '14

Hello Jacek, On 05/14/2014 04:55 PM, Jacek Caban wrote: > > 0001-oleaut32-Added-debugstr_variant-helper-for-better-deb.diff wouldn't it be better to make debugstr_variant aka add it to include/wine/debug.h? VARIANTs are used in a lot more places then just oleaut32. > > > diff --git a/dlls/oleaut32/varformat.c b/dlls/oleaut32/varformat.c > index e72a170..0e1c370 100644 > --- a/dlls/oleaut32/varformat.c > +++ b/dlls/oleaut32/varformat.c > @@ -1201,9 +1201,8 @@ static HRESULT VARIANT_FormatNumber(LPVARIANT pVarIn, LPOLESTR lpszFormat, > const BYTE* pToken = NULL; > HRESULT hRes = S_OK; > > - TRACE("(%p->(%s%s),%s,%p,0x%08x,%p,0x%08x)\n", pVarIn, debugstr_VT(pVarIn), > - debugstr_VF(pVarIn), debugstr_w(lpszFormat), rgbTok, dwFlags, pbstrOut, > - lcid); > + TRACE("(%s,%s,%p,0x%08x,%p,0x%08x)\n", debugstr_variant(pVarIn), debugstr_w(lpszFormat), > + rgbTok, dwFlags, pbstrOut, lcid); bye michael

2 1

Re: [PATCH 3/3] oleacc: Add GetStateText implementation
by Nikolay Sivov 14 May '14

14 May '14

> + ret = GetStateTextW(0, (WCHAR*)&ptr, 0); Why not use id symbols, instead of magic numbers?

2 1

RFC: "once" FIXME capability
by Erich E. Hoover 14 May '14

14 May '14

While at LinuxTag Sebastian Lackner, Michael Müller, and I were chatting with Michael Stefaniuc and Anastasius Focht about the way we currently implement "one-time FIXME". It was discussed that a more global approach to this was desired, but that it should have the following characteristics: 1) It should work with ANSI C compilers (the variadic macro problem) 2) It should be something that we can disable with a debug channel (something AF would really appreciate that our current ad-hoc approach does not support) 3) It should be expandable to handling a "once per flag" capability Toward that end the three of us have put together several proposed "once" implementations. All three patch-sets are based on variations of the following trick to allow defining in-place static variables without any special compiler requirements: if(1) { \ static int __wine_debug_once = 0; \ int __wine_debug_once_temp = __wine_debug_once; \ if(!__wine_debug_once) __wine_debug_once = 1; \ if(__wine_debug_once_temp == 0) \ goto __WINE_LIMIT_LABEL(__LINE__); \ } else __WINE_LIMIT_LABEL(__LINE__): Here are the various approaches: 1) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_1.tgz This implementation is a macro (LIMIT_ONCE, LIMIT_FLAG_ONCE) that you would use to prefix a FIXME/WARN/etc. The feature can be disabled by enabling the "+nolimit" WINEDEBUG option (patch 3). 2) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_2.tgz This implementation builds onto the existing FIXME to add a FIXME_ONCE (and FIXME_FLAG_ONCE). The feature can be disabled by enabling the "+nolimit" WINEDEBUG option (patch 4). 3) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_3.tgz This implementation builds onto the existing FIXME to add a FIXME_ONCE (and FIXME_FLAG_ONCE). The feature can be disabled by enabling the "nolimit+<channel>" WINEDEBUG option (patch 4). This version benefits from the ability to turn off limiting on a per-channel basis, which should make it easier to track down problems when an unrelated debug channel is also spamming the console. We'd love to hear which approach everyone likes the most or any feedback you might have. Best, Erich

2 1

Re: [PATCH 4/5] d2d1: Add the ID2D1Bitmap interface.
by Nikolay Sivov 14 May '14

14 May '14

On 5/14/2014 09:56, Henri Verbeet wrote: > +[ > + local, > + object, > + uuid(a2296057-ea42-4099-983b-539fb6505426) > +] > +interface ID2D1Bitmap : ID2D1Image > +{ > + D2D1_SIZE_F GetSize(); > + D2D1_SIZE_U GetPixelSize(); > + D2D1_PIXEL_FORMAT GetPixelFormat(); > + void GetDpi( > + [out] float *dpi_x, > + [out] float *dpi_y > + ); > + HRESULT CopyFromBitmap( > + [in, optional] const D2D1_POINT_2U *dst_point, > + [in] ID2D1Bitmap *bitmap, > + [in, optional] const D2D1_RECT_U *src_rect > + ); > + HRESULT CopyFromRenderTarget( > + [in, optional] const D2D1_POINT_2U *dst_point, > + [in] ID2D1RenderTarget *render_target, > + [in, optional] const D2D1_RECT_U *src_rect > + ); > + HRESULT CopyFromMemory( > + [in, optional] const D2D1_RECT_U *dst_rect, > + [in] const void *src_data, > + [in] UINT32 pitch > + ); > +} > + > I don't think it makes sense to match msdn here regarding [optional] attribute, and that's why: - 'optional' without 'defaultvalue' has no effect on headers, as far as I can see; - you can't mix 'optional' with required arguments like that, midl will refuse to process such idl, optional arguments should be at the end of arguments list only; - msdn says that it only applies to VARIANT and VARIANT* types, not sure about that, probably it's meant to talk about typelib generation only. And we don't need a typelib for d2d1 anyway. It makes sense imo to eventually make widl more midl-compliant adding similar consistency checks, like 'optional' position, also duplicated guids in typelibs come to mind. It's up to you to keep it as it is, just pointing out potential problems.

3 6

Re: [user32] add a dde test for OEM CP
by Marvin 13 May '14

13 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=7029 Your paranoid android. === w2000pro (32 bit dde) === dde.c:1797: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 6 dde.c:1820: Test failed: DdeQueryStringA returned wrong string String dde.c:1831: Test failed: DdeQueryStringA returned wrong length 6 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wxppro (32 bit dde) === dde.c:1797: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1820: Test failed: DdeQueryStringA returned wrong string ?" dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wvistau64 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w2008s64 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w7u (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w8 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wvistau64 (64 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w2008s64 (64 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom

1 0

Re: oleacc: Add GetStateText implementation (try3)
by Alexandre Julliard 13 May '14

13 May '14

Piotr Caban <piotr(a)codeweavers.com> writes: > +UINT WINAPI GetStateTextW(DWORD state_bit, WCHAR *state_str, UINT state_str_len) > +{ > + DWORD state_id; > + > + TRACE("%x %p %u\n", state_bit, state_str, state_str_len); > + > + state_id = IDS_STATE_MIN; > + while(state_bit) { > + state_id++; > + state_bit /= 2; > + } > + > + if(state_id>=IDS_STATE_MIN && state_id<=IDS_STATE_MAX) { > + UINT ret; > + > + if(state_str) { > + ret = LoadStringW(oleacc_handle, state_id, state_str, state_str_len); > + }else { > + WCHAR tmp; > + ret = LoadStringW(oleacc_handle, state_id, &tmp, 0); > + } > + > + if(!ret && state_str && state_str_len) > + state_str[0] = 0; > + return ret; > + } The id range check doesn't seem very useful. Also it would be worth testing that a 0 length is supposed to return the string pointer the way LoadString does. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ntdll: Pad the FILE_*_DIRECTORY_INFORMATION with zero bytes
by Alexandre Julliard 13 May '14

13 May '14

Martin Storsjo <martin(a)martin.st> writes: > Instead of memcpying in whatever uninitialized data there was at > the end of long_nameW, memset the tail of the struct to zero > instead. > > This fixes running cl.exe from MSVC 2013 with native > msvcr120/msvcp120, fixing bug 35335. > > MSVC 2013 (or msvcr120?) seems to use NtQueryDirectoryFile to > iterate through the headers in directories in the include path, > and prior to this change, the file names found during iteration > could get a suffix consisting of an uninitialized WCHAR. That doesn't make much sense, given that there may not be space for a final null, and that your patch doesn't clear the right location anyway. It looks like more investigation is needed. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 3/5] wined3d: Always store the palette index in the alpha component.
by Henri Verbeet 13 May '14

13 May '14

On 12 May 2014 15:12, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -1458,8 +1457,7 @@ static void surface_download_data(struct wined3d_surface *surface, const struct > int src_pitch = 0; > int dst_pitch = 0; > > - /* In case of P8 the index is stored in the alpha component if the primary render target uses P8. */ > - if (format->id == WINED3DFMT_P8_UINT && swapchain_is_p8(surface->resource.device->swapchains[0])) > + if (format->id == WINED3DFMT_P8_UINT) > { > gl_format = GL_ALPHA; > gl_type = GL_UNSIGNED_BYTE; This branch is pretty pointless, the format / type for WINED3DFMT_P8_UINT is always GL_ALPHA / GL_UNSIGNED_BYTE. (If ARB_fragment_program is supported, and the format is supported at all anyway.) > @@ -3256,53 +3252,19 @@ static void read_from_framebuffer(struct wined3d_surface *surface, DWORD dst_loc > switch (surface->resource.format->id) > { > case WINED3DFMT_P8_UINT: > - { > - if (swapchain_is_p8(context->swapchain)) > - { > - /* In case of P8 render targets the index is stored in the alpha component */ > - fmt = GL_ALPHA; > - type = GL_UNSIGNED_BYTE; > - mem = data.addr; > - bpp = surface->resource.format->byte_count; > - } > - else > - { > - /* GL can't return palettized data, so read ARGB pixels into a > - * separate block of memory and convert them into palettized format > - * in software. Slow, but if the app means to use palettized render > - * targets and locks it... > - * > - * Use GL_RGB, GL_UNSIGNED_BYTE to read the surface for performance reasons > - * Don't use GL_BGR as in the WINED3DFMT_R8G8B8 case, instead watch out > - * for the color channels when palettizing the colors. > - */ > - fmt = GL_RGB; > - type = GL_UNSIGNED_BYTE; > - pitch *= 3; > - mem = HeapAlloc(GetProcessHeap(), 0, surface->resource.size * 3); > - if (!mem) > - { > - ERR("Out of memory\n"); > - return; > - } > - bpp = surface->resource.format->byte_count * 3; > - } > - } > - break; > + fmt = GL_ALPHA; > + type = GL_UNSIGNED_BYTE; > + break; > > default: > - mem = data.addr; > fmt = surface->resource.format->glFormat; > type = surface->resource.format->glType; > - bpp = surface->resource.format->byte_count; > } Like above. > if (!srcIsUpsideDown) > { > - UINT len; > /* glReadPixels returns the image upside down, and there is no way to prevent this. > - Flip the lines in software */ > - len = surface->resource.width * bpp; > + * Flip the lines in software. > + * TODO: Consider flipping the image in an FBO. */ Possibly, but that would be a decision for surface_load_sysmem(), not read_from_framebuffer(). Note that reading the front buffer isn't particularly fast on Windows either though. > + row = HeapAlloc(GetProcessHeap(), 0, pitch); > + goto error; This looks unintentional. > @@ -3088,38 +3088,7 @@ DWORD wined3d_format_convert_from_float(const struct wined3d_surface *surface, c > } > > if (format->id == WINED3DFMT_P8_UINT) > - { > - const RGBQUAD *e; > - BYTE r, g, b, a; > - > - if (!surface->palette) > - { > - WARN("Surface doesn't have a palette, returning 0.\n"); > - return 0; > - } > - > - r = (BYTE)((color->r * 255.0f) + 0.5f); > - g = (BYTE)((color->g * 255.0f) + 0.5f); > - b = (BYTE)((color->b * 255.0f) + 0.5f); > - a = (BYTE)((color->a * 255.0f) + 0.5f); > - > - e = &surface->palette->colors[a]; > - if (e->rgbRed == r && e->rgbGreen == g && e->rgbBlue == b) > - return a; > - > - WARN("Alpha didn't match index, searching full palette.\n"); > - > - for (i = 0; i < 256; ++i) > - { > - e = &surface->palette->colors[i]; > - if (e->rgbRed == r && e->rgbGreen == g && e->rgbBlue == b) > - return i; > - } > - > - FIXME("Unable to convert color to palette index.\n"); > - > - return 0; > - } > + return (BYTE)((color->a * 255.0f) + 0.5f); So this could just use the table now, right?

2 3

Re: dpnet: Stub interface IDirectPlay8LobbyClient
by Stefan Dösinger 13 May '14

13 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-13 02:04, schrieb Alistair Leslie-Hughes: > @@ -127,6 +127,7 @@ extern HRESULT DPNET_CreateDirectPlay8Peer(LPCLASSFACTORY iface, LPUNKNOWN punkO > extern HRESULT DPNET_CreateDirectPlay8Address(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > extern HRESULT DPNET_CreateDirectPlay8LobbiedApp(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > extern HRESULT DPNET_CreateDirectPlay8ThreadPool(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > +extern HRESULT DPNET_CreateDirectPlay8LobbyClient(IClassFactory *iface, IUnknown *pUnkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; If you don't use LPJUNK for the iface and UnkOuter (yay :-) ), you might also do it for LPVOID. > +static HRESULT WINAPI lobbyclient_Initialize(IDirectPlay8LobbyClient *iface, PVOID pvUserContext, PFNDPNMESSAGEHANDLER pfn, DWORD dwFlags) No Hungarian notation please (dwFlags, pThisIsAPointer). Also, (L)PJUNK again. > + app = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectPlay8LobbyClientImpl)); > + if (NULL == app) { > + *ppobj = NULL; > + return E_OUTOFMEMORY; > + } Style inconsistency with the rest of the patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTcddPAAoJEN0/YqbEcdMwu2oP/iKSBrRhn/4PoGRTAE6hHQsd 4qwWb7WNS+mczHW+ucVfBogFvPkecpUauHWMpEyND3mYp8kli/2BDqtQrovcvabK h5QRqrP3ToRyIm6VMgaijMx4WlrjsZKHKKzW7/k8TxBTAs25OOaBAUC8ihK1A65s lQVywsqPPHuq4u8LzFjr4xE8s5UyZy5tCPYyDFym0otbiRX9+MQJjztFtC3wd8si Fznv681ZTrpR5m3qvcrMn1Eo2mKFvM1Wbi7W58uO2QTEH6BRiMlfd3A/fqVbhCdZ jiYdcDgUSWugOxIoWtaJNzU/mh3oChyPe+WWFXNoPy5W0/wrJHXUbssAW/s5bX1p wRO6rqmbf27rGCFp57oimJMxb/QJT0o+sU2ZdYHv2hjAX7U1csGU6Z3bUQ/KYLlG AztBJBVkTbe9aoIKhsZx/ISHIQ5GYJyY8KntqBOadrziu/I0kzX0ONtDfTdFzkne RhBSXUFjlKxxm17hXyOEftMsD1tkMn74fChJzFOJUo6v3thkH1IcbMhqwNLvj6++ Om2bO4M5Lw77u/9jR84WpFWUh4wUUqgs+v1/VPpt07QTIhwAERU3CiMt1wlkZFvB cyiWm+a3q/GekR1gyyku31bbkqInDRZENDkRl3FXWS/t1Om38j2JgB45mCMEFKCq HoNMnRF44iY4XWaXwd5M =3BFT -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 3)
by Henri Verbeet 12 May '14

12 May '14

On 12 May 2014 17:45, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/d3d9/tests/device.c | 119 ++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 96 insertions(+), 23 deletions(-) > This fails here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so device && touch device.ok ... device.c:4609: Test failed: Occlusion query returned an unexpected result (0x00060300). device.c:4621: Test failed: Occlusion query returned an unexpected result (0x00060300). device.c:4628: Test failed: Occlusion query returned an unexpected result (0x00060300). And on Windows: device.c:4609: Test failed: Occlusion query returned an unexpected result (0xffff052a). device.c:4621: Test failed: Occlusion query returned an unexpected result (0x0008052a). device.c:4628: Test failed: Occlusion query returned an unexpected result (0x0008052a).

2 1

Re: testbot/log2revtimes: Add a script to extract the VM revert times from the WineTestBot log and prepare them for analysis.
by Francois Gouget 12 May '14

12 May '14

On Mon, 12 May 2014, Francois Gouget wrote: > --- > > I'm using this script to parse the Engine log and generate a CSV files I > can import in a spreadsheet to generate a graph of the VM revert times. > But having it only on my machine feels wrong. So I propose to put it in > the scripts directory (which feels like a sort of contrib directory) so > it can be used by others. And here is the spreadsheet I import the 'CVS' file into: http://fgouget.free.fr/wtb/vm1-revtime.xls.bz2 And the corresponding graphs: * Since the beginning of times This graph shows all the revert times since the new TestBot was put online. The Y axis is logarithmic so the high revert times don't cause all the low ones to be crunched together. Note that the stratification is caused by the 1 second ganularity of the mesurements. I guess it needs an annotation with the different events. http://fgouget.free.fr/wtb/vm1-revtimes-all.png * Since last April This shows the revert times a bit before the VM1 host crashed and went through reconstruction. This confirms my suspicions: the revert times are not very good :-( http://fgouget.free.fr/wtb/vm1-revtimes-recent.png -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

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