December 2014 - wine-devel

Re: [PATCH 3/4] ntdll: Implement storing DOS attributes in NtSetInformationFile (try 2).
by Marvin 19 Dec '14

19 Dec '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=10823 Your paranoid android. === w8 (32 bit file) === file.c:397: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

Re: [PATCH 3/4] ntdll: Implement storing DOS attributes in NtSetInformationFile.
by cdavis5x＠gmail.com 18 Dec '14

18 Dec '14

> On Dec 18, 2014, at 10:16 AM, Erich E. Hoover <erich.e.hoover(a)gmail.com> wrote: > This patch implements storing DOS attributes in the Samba format > "user.DOSATTRIB" extended attribute using fsetxattr and fremovexattr. > FILE_ATTRIBUTE_NORMAL is masked out since that attribute is > unnecessary, and leaving it out avoids having to store an attribute > for every file on the system. Only NORMAL? There are quite a few DOS attributes. Here’s a list from <winnt.h>: #define FILE_ATTRIBUTE_READONLY 0x00000001 #define FILE_ATTRIBUTE_HIDDEN 0x00000002 #define FILE_ATTRIBUTE_SYSTEM 0x00000004 #define FILE_ATTRIBUTE_DIRECTORY 0x00000010 #define FILE_ATTRIBUTE_ARCHIVE 0x00000020 #define FILE_ATTRIBUTE_DEVICE 0x00000040 #define FILE_ATTRIBUTE_NORMAL 0x00000080 #define FILE_ATTRIBUTE_TEMPORARY 0x00000100 #define FILE_ATTRIBUTE_SPARSE_FILE 0x00000200 #define FILE_ATTRIBUTE_REPARSE_POINT 0x00000400 #define FILE_ATTRIBUTE_COMPRESSED 0x00000800 #define FILE_ATTRIBUTE_OFFLINE 0x00001000 #define FILE_ATTRIBUTE_NOT_CONTENT_INDEXED 0x00002000 #define FILE_ATTRIBUTE_ENCRYPTED 0x00004000 (Yes, all of those are in Microsoft’s public headers. I checked.) Of those, these are the ones that Samba lets clients set: FILE_ATTRIBUTE_READONLY FILE_ATTRIBUTE_HIDDEN FILE_ATTRIBUTE_SYSTEM FILE_ATTRIBUTE_ARCHIVE FILE_ATTRIBUTE_OFFLINE and these are the ones that Samba returns: FILE_ATTRIBUTE_READONLY FILE_ATTRIBUTE_HIDDEN FILE_ATTRIBUTE_SYSTEM FILE_ATTRIBUTE_DIRECTORY FILE_ATTRIBUTE_ARCHIVE FILE_ATTRIBUTE_SPARSE_FILE (Weird. They let people set OFFLINE, but never return it…) These are the ones that MSDN says Windows lets programs set with SetFileAttributes() (but I can’t vouch for MSDN’s accuracy, so this really needs to be demonstrated with a test): FILE_ATTRIBUTE_READONLY FILE_ATTRIBUTE_HIDDEN FILE_ATTRIBUTE_SYSTEM FILE_ATTRIBUTE_NORMAL FILE_ATTRIBUTE_ARCHIVE FILE_ATTRIBUTE_TEMPORARY FILE_ATTRIBUTE_OFFLINE FILE_ATTRIBUTE_NOT_CONTENT_INDEXED and these are the ones that CreateFile() is supposed to let programs set: FILE_ATTRIBUTE_READONLY FILE_ATTRIBUTE_HIDDEN FILE_ATTRIBUTE_SYSTEM FILE_ATTRIBUTE_NORMAL FILE_ATTRIBUTE_ARCHIVE FILE_ATTRIBUTE_TEMPORARY FILE_ATTRIBUTE_OFFLINE FILE_ATTRIBUTE_ENCRYPTED I definitely think we shouldn’t be letting people set the DEVICE attribute (this is, I suspect, the attribute you get from a device handle), or the REPARSE_POINT attribute (this is what Windows returns for e.g. symlinks and junctions); MSDN says that the SET_REPARSE_POINT FSCTL is supposed to be able to set this attribute, though. Samba also forcibly sets the DIRECTORY attribute according to whether the file is or is not actually a directory; we should do this, too. MSDN also says the COMPRESSED attribute is supposed to be set by the SET_COMPRESSION FSCTL, the ENCRYPTED attribute is supposed to be set by advapi32.EncryptFile() (which I suspect just makes a SET_ENCRYPTION FSCTL) or when the file is created, and the SPARSE_FILE attribute is supposed to be set by the SET_SPARSE FSCTL, so we should mask all those out too. (Or error out, depending on what native does; as always, the tests are your friends here.) Also, NORMAL is only supposed to be valid by itself, so if any attributes are set along with NORMAL, we may need to error out. We REALLY need tests for all this. ;) (We have some tests for setting file attributes, but not enough IMO.) Chip

2 1

Re: [PATCH 4/4] ntdll: Implement storing DOS attributes in NtCreateFile.
by Marvin 18 Dec '14

18 Dec '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=10817 Your paranoid android. === build (build) === Make in include dir failed

1 0

Re: [PATCH 3/4] ntdll: Implement storing DOS attributes in NtSetInformationFile.
by Marvin 18 Dec '14

18 Dec '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=10816 Your paranoid android. === build (build) === Make in include dir failed

1 0

Re: winex11.drv: don't drop raw input events after mouse warp
by Patrick Rudolph 18 Dec '14

18 Dec '14

Am 2014-12-17 20:56, schrieb Alexandre Julliard: > Patrick Rudolph <siro(a)das-labor.org> writes: > >> This patch fixes bug https://bugs.winehq.org/show_bug.cgi?id=32913 >> After each mouse move the cursor is warped back to the center of the >> screen. This is OK for XInput, but not for XInput2 as XInput2 reports >> raw events that doesn't care about absolute screen coordinates and >> doesn't need to be dropped. There're frequent cursor warps resulting >> in lot's of dropped raw motion events (up to all). These dropped >> motion events cause mouse jitter, which is notable in FPS games, but >> not while using any GUI that only needs pixel coordinates. > > The problem is that warping the mouse also generates events, and you > have to ignore those. I've attached a log file, here: https://bugs.winehq.org/attachment.cgi?id=50258 As you can see XWarpCursor inserts MotionNotify events, that are correctly ignored using the serial, but there're no inserted RawMotion events. So there's no need to drop them, correct me if I'm wrong. Sadly I couldn't find any documentation for XWarpCursor and RawMotion events. Kind Regards, Patrick

2 1

Re: winex11.drv: don't drop raw input events after mouse warp
by Alexandre Julliard 17 Dec '14

17 Dec '14

Patrick Rudolph <siro(a)das-labor.org> writes: > This patch fixes bug https://bugs.winehq.org/show_bug.cgi?id=32913 > After each mouse move the cursor is warped back to the center of the > screen. This is OK for XInput, but not for XInput2 as XInput2 reports > raw events that doesn't care about absolute screen coordinates and > doesn't need to be dropped. There're frequent cursor warps resulting > in lot's of dropped raw motion events (up to all). These dropped > motion events cause mouse jitter, which is notable in FPS games, but > not while using any GUI that only needs pixel coordinates. The problem is that warping the mouse also generates events, and you have to ignore those. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] mmdevapi: More accurately track device position
by Marvin 17 Dec '14

17 Dec '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=10797 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] libs/wine/string.c: Always return (int)written
by Hugh McMaster 17 Dec '14

17 Dec '14

On Wednesday, Dec 17 05:54:42 CST 2014, Jonathan Vollebregt wrote: >No: http://msdn.microsoft.com/en-us/library/1kt27hek.aspx#returnValueToggle >> vsnprintf ,_vsnprintf, and _vsnwprintf return the number of characters written if the number of characters to write is less than or equal to count; if the number of characters to write is greater than count, these functions return -1 indicating that output has been truncated. The return value does not include the terminating null, if one is written. >> >> If buffer or format is NULL, or if count is less than or equal to zero, these functions invoke the invalid parameter handler, as described in Parameter Validation. If execution is allowed to continue, these functions return -1 and set errno to EINVAL. I disagree. vsnprintfW is not a Windows function. We should be following the Linux form here, which returns the number of chars that would be written.

2 1

Re: [PATCH] libs/wine/string.c: Always return (int)written
by Jonathan Vollebregt 17 Dec '14

17 Dec '14

No: http://msdn.microsoft.com/en-us/library/1kt27hek.aspx#returnValueToggle > vsnprintf ,_vsnprintf, and _vsnwprintf return the number of characters written if the number of characters to write is less than or equal to count; if the number of characters to write is greater than count, these functions return -1 indicating that output has been truncated. The return value does not include the terminating null, if one is written. > > If buffer or format is NULL, or if count is less than or equal to zero, these functions invoke the invalid parameter handler, as described in Parameter Validation. If execution is allowed to continue, these functions return -1 and set errno to EINVAL. On 12/17/2014 12:47 PM, Hugh McMaster wrote: > Both GCC and Windows versions of vsnprintf return the number of chars that would be written to a given buffer when vsnprintf(NULL, 0, fmt, va_args) is called. > > Wine currently returns -1, which is incorrect. > > Also, if there is a short buffer, that is, buffer <= len, not only is any output truncated, but the return value is the number of chars that would be written if the buffer had sufficient space. > > Here, Wine returns -1, which is, again, incorrect. > > In all cases, the return value should be the number of chars written or the number of chars that would be written if the buffer has sufficient space.

1 0

RE: (resend) regedit: Improve error message when recasing a key.
by Hugh McMaster 17 Dec '14

17 Dec '14

On Wednesday, 17 Dec 2014 01:31:53 +0300, Dmitry Kozliuk wrote: >+ IDS_ERROR_RENAMING_VALUE "Error Renaming Value" >+ IDS_KEY_ALREADY_EXISTS "The Registry Editor cannot rename %s. > The specified key name already exists. Type another name and try again." You cannot use those strings. The first is a verbatim copy from native regedit.exe. The second is almost verbatim, with the exception of "key name". Native regedit.exe uses "value name". Please craft different text with the same meaning.

1 0

Re: shell32: Implement IApplicationAssociationRegistration, QueryCurrentDefault (try 4)
by Nikolay Sivov 17 Dec '14

17 Dec '14

On 12/17/2014 08:11 AM, Alistair Leslie-Hughes wrote: > - test_IApplicationAssociationRegistration_QueryInterface(); > + /* this works since Vista */ > + hr = CoCreateInstance(&CLSID_ApplicationAssociationRegistration, NULL, CLSCTX_INPROC_SERVER, > + &IID_IApplicationAssociationRegistration, (LPVOID*)&appreg); > + if (hr == S_OK) > + { > + test_IApplicationAssociationRegistration_QueryInterface(appreg); > + test_IApplicationAssociationRegistration_QueryCurrentDefault(appreg); > + > + IApplicationAssociationRegistration_Release(appreg); > + } > + else > + skip("IApplicationAssociationRegistration not supported: 0x%x\n", hr); This should be win_skip().

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByName (try 3)
by Marvin 17 Dec '14

17 Dec '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=10793 Your paranoid android. === w8 (32 bit address) === The test timed out

2 1

Re: [1/2] server: Never attempt to wake up the current thread.
by Sebastian Lackner 16 Dec '14

16 Dec '14

On 16.12.2014 06:23, Sebastian Lackner wrote: > Alternative approach for patch #107840 "server: Avoid sending unexpected wakeup with uninitialized cookie value." (which should also still be fine, but this solution is probably a bit easier). > > We never want to send any wakeup cookies to our currently active thread, so just fake success in this case. > To demonstrate what happens without this patch (and to avoid any regressions) I've also added a test in patch 2/2. > > The unexpected cookies itself are not visible without debug messages of course, but because of the buffer size limitation the whole wineserver freezes. > When forcefully killing the test, the wineserver also crashes with: > > ==14785== Invalid read of size 4 > ==14785== at 0x807CE1B: select_on (thread.c:830) > ==14785== by 0x807E604: req_select (thread.c:1462) > ==14785== by 0x8076003: call_req_handler (request.c:247) > ==14785== by 0x807620A: read_request (request.c:302) > ==14785== by 0x807B8C1: thread_poll_event (thread.c:267) > ==14785== by 0x805679F: fd_poll_event (fd.c:446) > ==14785== by 0x8056A43: main_loop_epoll (fd.c:541) > ==14785== by 0x8056E2F: main_loop (fd.c:886) > ==14785== by 0x805F4B6: main (main.c:148) > ==14785== Address 0x50 is not stack'd, malloc'd or (recently) free'd > ==14785== > ==14785== Process terminating with default action of signal 11 (SIGSEGV): dumping core > > Reason for the crash is that the wakeup write() syscall fails -> the thread is terminated with kill_thread() -> this sets current = NULL - the code later assumes that 'current' is still a valid pointer. By not sending wakeup cookies we avoid this whole code path, and the test runs well. > > --- > server/thread.c | 4 ++++ > 1 file changed, 4 insertions(+) > Please ignore this patch for now, there are some situations (not covered by existing tests) where this idea would not work correctly.

1 0

Re: include/ddk: add csq.h
by Austin English 16 Dec '14

16 Dec '14

On Thu, Nov 13, 2014 at 3:30 PM, Austin English <austinenglish(a)gmail.com> wrote: > > > -- > -Austin > Patch dropped off the tracker without comment, could I get some feedback please? -- -Austin

1 0

Re: zh_CN Translation Submittion
by Nikolay Sivov 15 Dec '14

15 Dec '14

On 15.12.2014 17:39, Jeff Bai wrote: > Umm... I think POEdit is the one who made these changes... Not sure if it's my settings or what. Yes, it's mostly likely it. But you don't have to use it, your favorite text editor will work just fine. > > >> 在 2014年12月15日，上午12:01，Nikolay Sivov <bunglehead(a)gmail.com> 写道： >> >>> On 15.12.2014 7:53, Jeff Bai wrote: >>> Hello, fellow developers. >>> >>> I've got several hundred strings translated to zh_CN, and according to >>> you guys' wiki I am supposed to submit a patch of what I've changed. >>> >>> So here it is (too long, used PasteBin) >>> >>> https://pastebin.anthonos.org/view/bb82ca07 >>> >>> Also, I am not sure if I would be fast enough to get them all done by >>> 1.7.34 (nearly two weeks apart?), so is it Okay for me to submit them >>> bit by bit, like this time, several hundred? There's still about 950 >>> left as I can see on POEdit - and I think I can push this to 100% after >>> my high school final four days later. >>> >>> Thanks everyone, Wine is AWESOME. >>> >>> Regards, >>> >>> Jeff Bai (白铭骢) >> >> Hi, Jeff. >> >> I think it's okay to submit full diff at once. But please avoid changing original messages like you do here (or maybe not you directly but poedit): >> >>> #: oleview.rc:121 >>> -msgid "" >>> -"Toggle the display of component categories that are not meant to be visible" >>> +msgid "Toggle the display of component categories that are not meant to be visible" >>> msgstr "切换隐藏组件类显示" >> >> So keep msgid part as it is and touch only msgstr part, this will also help reducing resulting diff. >> >> And once you fixed that you should send a patch to wine-patches(a)winehq.org as it says here http://wiki.winehq.org/SubmittingPatches.

1 0

setting break point in 16 bit Windows app
by Marius Cirsta 15 Dec '14

15 Dec '14

I'd like to use winedbg to set a break point in a 16 bit Windows app, to stop execution on some function call. From what I've read this is broken as of 2005 ( https://www.winehq.org/pipermail/wine-devel/2006-June/048343.html ). Has anything happened since ? I'm interested in getting this to work but it all depends on the effort involved. Can anyone provide an estimate as to how much work is needed ? Thanks.

1 0

Re: d3d9: Don't assert when apps pass in the wrong shader iface.
by Sebastian Lackner 15 Dec '14

15 Dec '14

On 15.12.2014 15:29, Michael Stefaniuc wrote: > Fixes a regression reported in > https://bugs.winehq.org/show_bug.cgi?id=37723 > --- > dlls/d3d9/shader.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/dlls/d3d9/shader.c b/dlls/d3d9/shader.c > index 0c2c881..9541028 100644 > --- a/dlls/d3d9/shader.c > +++ b/dlls/d3d9/shader.c > @@ -165,9 +165,8 @@ HRESULT vertexshader_init(struct d3d9_vertexshader *shader, struct d3d9_device * > > struct d3d9_vertexshader *unsafe_impl_from_IDirect3DVertexShader9(IDirect3DVertexShader9 *iface) > { > - if (!iface) > + if (!iface && iface->lpVtbl != &d3d9_vertexshader_vtbl) ^^^^ Shouldn't it be !iface || iface->lpVtbl != &d3d9_vertexshader_vtbl ? > return NULL; > - assert(iface->lpVtbl == &d3d9_vertexshader_vtbl); > > return impl_from_IDirect3DVertexShader9(iface); > } > @@ -315,9 +314,8 @@ HRESULT pixelshader_init(struct d3d9_pixelshader *shader, struct d3d9_device *de > > struct d3d9_pixelshader *unsafe_impl_from_IDirect3DPixelShader9(IDirect3DPixelShader9 *iface) > { > - if (!iface) > + if (!iface && iface->lpVtbl != &d3d9_pixelshader_vtbl) > return NULL; > - assert(iface->lpVtbl == &d3d9_pixelshader_vtbl); > > return impl_from_IDirect3DPixelShader9(iface); > } >

1 0

Re: zh_CN Translation Submittion
by Nikolay Sivov 15 Dec '14

15 Dec '14

On 15.12.2014 7:53, Jeff Bai wrote: > Hello, fellow developers. > > I've got several hundred strings translated to zh_CN, and according to > you guys' wiki I am supposed to submit a patch of what I've changed. > > So here it is (too long, used PasteBin) > > https://pastebin.anthonos.org/view/bb82ca07 > > Also, I am not sure if I would be fast enough to get them all done by > 1.7.34 (nearly two weeks apart?), so is it Okay for me to submit them > bit by bit, like this time, several hundred? There's still about 950 > left as I can see on POEdit - and I think I can push this to 100% after > my high school final four days later. > > Thanks everyone, Wine is AWESOME. > > Regards, > > Jeff Bai (白铭骢) > > > Hi, Jeff. I think it's okay to submit full diff at once. But please avoid changing original messages like you do here (or maybe not you directly but poedit): > #: oleview.rc:121 > -msgid "" > -"Toggle the display of component categories that are not meant to be visible" > +msgid "Toggle the display of component categories that are not meant to be visible" > msgstr "切换隐藏组件类显示" So keep msgid part as it is and touch only msgstr part, this will also help reducing resulting diff. And once you fixed that you should send a patch to wine-patches(a)winehq.org as it says here http://wiki.winehq.org/SubmittingPatches.

1 0

Re: ole32:fix CoWaitForMultipleHandles cause RPC hang
by Changhui Liu 15 Dec '14

15 Dec '14

Hi, I got it. The CoWaitForMultipleHandles of Microsoft implement is this: The message loop continue although has received WM_QUIT, but just dispatch message who sent to the OleMainThreadWndClass Window. I attached a latest patch and a verify function. Run the test_CoWaitForMultipleHandlesDispatchMsg, We will only get the message who send to cowait_test_class window . It also pass your PeekMessage test at: https://github.com/wine-compholio/wine-staging/blob/master/patches/ole32-Co… Please help me review it again when you are free. Thank you. ------------------ Regards. ------------------ Original ------------------ From: "Sebastian Lackner"<sebastian(a)fds-team.de>; Date: Sat, Dec 13, 2014 11:32 PM To: "Changhui Liu"<liuchanghui(a)linuxdeepin.com>; Cc: "wine-devel"<wine-devel(a)winehq.org>; Subject: Re: ole32:fix CoWaitForMultipleHandles cause RPC hang Hi, On 13.12.2014 16:15, Changhui Liu wrote: > Hi Sebastian, > > > I tested your current work-in-progress patch: > https://github.com/wine-compholio/wine-staging/blob/master/patches/ole32-Co… > > I have two puzzles about these code: >> index = 0xdeadbeef; >> PostMessageA(hWnd, WM_DDE_FIRST, 0, 0); >> PostQuitMessage(44); >> thread = CreateThread(NULL, 0, post_message_thread, hWnd, 0, &tid); >> ok(thread != NULL, "CreateThread failed, error %u\n", GetLastError()); >> hr = CoWaitForMultipleHandles(0, 100, 2, handles, &index); >> ok(hr == RPC_S_CALLPENDING, "expected RPC_S_CALLPENDING, got 0x%08x\n", hr); >> ok(index == 0 || broken(index == 0xdeadbeef) /* Win 8 */, "expected index 0, got %u\n", index); >> success = PeekMessageA(&msg, hWnd, WM_DDE_FIRST, WM_DDE_FIRST, PM_REMOVE); >> ok(success, "PeekMessageA failed, error %u\n", GetLastError()); > > > The first, why use the PeekMessage to check if received a WM_DDE_FIRST message? > Is there an real application do like that way? Of course there are multiple ways to test for window messages in the message queue, I just picked PeekMessageA because it doesn't require setting up a Wndproc. > > > In fact CoWaitForMultipleHandles has a message loop, the WM_DDE_FIRST message has been > dispatched to the window's WNDPROC. So the PeekMessageA certainly failed. No, it doesn't. Feel free to run the tests yourself on a Windows machine, I have tested them with the Wine testbot and all tests pass on 2000/XP/Vista/8/2008/... - which means that Windows does not process all WM_DDE_FIRST messages. This is also why I am unsure about how to fix it. When changing the behaviour in order to fix one of the tests which fails in Wine (marked with todo_wine), it breaks other tests which were working well before. > > > I think the correct test should be this: > 1, Define a custom WNDPROC function named cowait_test_wnd_proc . > 2, Define a global int variable named g_count_of_wm_dde_first. > 3, Set the value of g_count_of_wm_dde_first to zero before call CoWaitForMultipleHandles. > 4, Increase the value of g_count_of_wm_dde_first by one, once received a WM_DDE_FIRST message in cowait_test_wnd_proc. > 5, Check if the value of g_count_of_wm_dde_first is equal to 2 after CoWaitForMultipleHandles returned. > This testing method would also be fine, but you would get 1 instead of 2. My patch doesn't show any test failures on Windows, which means that one of the WM_DDE_FIRST messages is still in the queue. > > The second is why use todo_wine ? > todo_wine > ok(!success, "PeekMessageA succeeded\n"); > why not just write? > ok(!success, "PeekMessageA succeeded\n"); > The Wine coding guideline does not allow to add new test failures, instead all tests which do not pass yet have to be marked with "todo_wine". This makes easily visible which tests need further work just by looking at the source code, moreover it avoids introducing regressions (breaking tests which were working well before). Take a look at some of the other Wine tests, this is not the only place where its used. > > > > Thank you. Regards, Sebastian

1 1

Re: [1/2] jscript: Support PROPERTYGET in Date Value
by Jacek Caban 14 Dec '14

14 Dec '14

On 12/14/14 00:18, Alistair Leslie-Hughes wrote: > case INVOKE_PROPERTYGET: > + { > + DateInstance *date; > + > + if(!(date = date_this(jsthis))) > + return throw_type_error(ctx, JS_E_DATE_EXPECTED, NULL); It's guaranteed that jsthis is of DataInstance type in case of *_value functions, so there is no need to check that in runtime. You may simply cast it here. Jacek

1 0

Re: ole32:fix CoWaitForMultipleHandles cause RPC hang
by Sebastian Lackner 13 Dec '14

13 Dec '14

On 11.12.2014 15:07, Changhui Liu wrote: > Because there's a RPC request need to be handled by OLE apartment window proc apartment_wndproc. > So, after received a WM_QUIT, > if the GUI thread in calling CoWaitForMultipleHandles don't handle message loop any more , > the RPC will never be handled, the RPC dispatch thread will be hang. > > > > There are several issues with this patch. You wrote in your last mail: > so this patch can't pass test on testbot.winehq.org, it only pass test on wine. > The test result is here, https://testbot.winehq.org/JobDetails.pl?Key=10727. It is not clear what you mean. The test should of course also pass on testbot.winehq.org, if it doesn't, this means that Wine doesn't properly reproduce the expected behaviour. You need to create a test so that it passes on both wine and the testbot, otherwise nothing is tested at all. Other issues in your patch: * It seems very unlikely that this is how quit messages are processed. Immediately calling PostQuitMessage(...) but continuing to process messages means that effectively WM_QUIT is lost. * Always add a "\n" at the end of ok(...) messages. * Try to avoid huge sleeps like Sleep(5000). This will probably cause the tests time out. Unfortunately I didn't have much time to look into this issue myself so far, but I guess I'll have more time at the weekend. Regards, Sebastian

2 4

Re: [PATCH v3 03/10] reg: Add system error printing function
by Indrek Altpere 13 Dec '14

13 Dec '14

Seems that the patches have reached the magical "1 month" limit where they disappear from the list silently. Last I saw, your patchset contained about 8 or 10 patches? Not sure if the best suggestion by official rules/guidelines, but perhaps it would be possible to add the new stuff in multiple, smaller patchsets, instead of one mega-patchset? It would mean that reviewers don't have to dig around in hundreds of lines of code changes that change a lot of functionality, makes it hard to keep track of all of it and review it thoroughly. Many big patchsets have gotten stalled like that: reviewer notices a few things, notifies developer, developer makes the changes, sends the changed full patchset again, reviewer checks full patchset again, finds more stuff in next files (or even the same files), notifies developer and so on and so on. Sometimes multiple reviewers also cause havoc, because due to many coding rules not being written down (http://wiki.winehq.org/SubmittingPatches contains general and vague guidelines, but essentially 0 hard examples) and each reviewer having a bit different viewpoint about what styling issues are could-be or should-be, so sending a huge set will end up with responses "here's about ~10 things wrong with your code" and like that after each submit. As I understand, someone correct me if I'm wrong, there is currently also no active reg component maintainer, who would be able to review things quickly, so smaller patchset would probably help things move along much faster? About https://source.winehq.org/patches/data/107580 getting stalled, I have no clue/opinion, does not seem to be overly complex? Regards, Indrek Altpere

3 2

Re: jscript: Added test of Date object default value.
by Marvin 12 Dec '14

12 Dec '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=10746 Your paranoid android. === w2000pro (32 bit run) === run.c:1962: Test failed: Invoke failed: 8000ffff run.c:1963: Test failed: V_VT(v) = 0

1 0

Re: [PATCH v4 2/4] combase: Implement creation and deletion of HSTRING objects.
by Martin Storsjö 12 Dec '14

12 Dec '14

On Wed, 10 Dec 2014, Martin Storsjo wrote: > --- > configure.ac | 1 + > .../api-ms-win-core-winrt-string-l1-1-0.spec | 8 +- > dlls/combase/Makefile.in | 3 +- > dlls/combase/combase.spec | 8 +- > dlls/combase/string.c | 143 +++++++++++++++++++++ > dlls/combase/tests/Makefile.in | 4 + > dlls/combase/tests/string.c | 128 ++++++++++++++++++ > tools/make_specfiles | 1 + > 8 files changed, 287 insertions(+), 9 deletions(-) > create mode 100644 dlls/combase/string.c > create mode 100644 dlls/combase/tests/Makefile.in > create mode 100644 dlls/combase/tests/string.c Any further comments on these ones (2-4), or should I resubmit them for a new look? // Martin

1 0

Drawbridge -- WinAPI/NT API sandbox in Windows
by Saulius Krasuckas 11 Dec '14

11 Dec '14

Hello, I just have heard about MS project called Drawbridge. [*] They use NT kernel (ntoskrnl + win32k) implementation in user-mode (NTUM) to load native DLLs and services from different versions of Windows, IIUC. Set of downcalls from NTUM (to native kernel) is reduced to 45 items. This way a process-based isolation is achieved. Some sort of sandbox/container. It sounds like Wine on Windows. Just FYI. S. [*] http://research.microsoft.com/en-us/projects/drawbridge/

1 0

Re: ole32:fix CoWaitForMultipleHandles cause RPC hang
by Marvin 11 Dec '14

11 Dec '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=10727 Your paranoid android. === w2000pro (32 bit compobj) === compobj.c:2325: compobj.c:2299: Test failed: sleep 5 second === wxppro (32 bit compobj) === compobj.c:2325: compobj.c:2299: Test failed: sleep 5 second === wvistau64 (32 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === w2008s64 (32 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === w7u (32 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === w8 (32 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === wvistau64 (64 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === w2008s64 (64 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK!

1 0

Re: ole32:fix CoWaitForMultipleHandles cause RPC hang
by Marvin 11 Dec '14

11 Dec '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=10726 Your paranoid android. === w2000pro (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === wxppro (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === wvistau64 (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === w2008s64 (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === w7u (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === w8 (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === wvistau64 (64 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === w2008s64 (64 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second

1 0

Re: d3dx9: ID3DXFont PreloadCharacters return S_OK
by Bruno Jesus 11 Dec '14

11 Dec '14

On Thu, Dec 11, 2014 at 1:27 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > If any program uses the SharpDX library, it throws an exception when > PreloadCharacters > returns E_NOTIMPL. > > Changelog: > d3dx9: ID3DXFont PreloadCharacters return S_OK Missing patch. > > Best Regards > Alistair Leslie-Hughes Regards, Bruno

1 0

Re: dwrite: Block creation of unsupported face types
by Marvin 10 Dec '14

10 Dec '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=10716 Your paranoid android. === wvistau64 (32 bit font) === font.c:1056: Test failed: got 0x80070057 === w2008s64 (32 bit font) === font.c:1056: Test failed: got 0x80070057 === wvistau64 (64 bit font) === font.c:1056: Test failed: got 0x80070057 === w2008s64 (64 bit font) === font.c:1056: Test failed: got 0x80070057

1 0

Re: [8/9] winhttp: Don't try to read data when the server response is HTTP_STATUS_NO_CONTENT or HTTP_STATUS_NOT_MODIFIED.
by Bruno Jesus 10 Dec '14

10 Dec '14

On Tue, Dec 9, 2014 at 9:50 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > Tests based on a patch by Bruno Jesus. > --- > dlls/winhttp/request.c | 15 ++++++----- > dlls/winhttp/tests/winhttp.c | 62 +++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 69 insertions(+), 8 deletions(-) > Hans, I can no longer find the bug that this was about. Can you please give the bug URL? Do you think your current patch set fixed it? Best regards, Bruno

2 1

Re: [PATCH v3 4/7] include: Add hstring.h and winstring.h.
by Alexandre Julliard 10 Dec '14

10 Dec '14

Martin Storsjo <martin(a)martin.st> writes: > --- > No changes since v2. > --- > include/Makefile.in | 2 ++ > include/hstring.h | 39 +++++++++++++++++++++++++++++++++++++++ > include/winstring.h | 46 ++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 87 insertions(+) > create mode 100644 include/hstring.h > create mode 100644 include/winstring.h hstring.h should be generated from idl. -- Alexandre Julliard julliard(a)winehq.org

2 1

RE: [PATCH v3 03/10] reg: Add system error printing function
by Hugh McMaster 09 Dec '14

09 Dec '14

On Saturday, 8 Nov 2014 11:26:44 +0100, Jonathan Vollebregt wrote: +static void reg_print_error(LSTATUS error_code) +{ + switch (error_code) + { + case ERROR_SUCCESS: + return; + case ERROR_BAD_COMMAND: + reg_message(STRING_INVALID_CMDLINE); + return; + default: + { + static const WCHAR error_string[] = {'%','0','5','d',':',' ','%','s',0}; + WCHAR *message = NULL; + FormatMessageW(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_ALLOCATE_BUFFER, NULL, + error_code, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (WCHAR *)&message, 0, NULL); + + reg_message(STRING_ERROR); + reg_printfW(error_string, error_code, message); + LocalFree(message); + return; + } + } +}This seems like a step backwards to me. It would be much better to add the required functionality -- e.g. FormatMessage() -- and fix reg.exe printf-style functions in one go. See http://source.winehq.org/patches/data/107578 for what I mean. Also, mixing reg_message() and reg_printfW() just seems wrong. A clear resource string incorporating your formatting above would suffice, I expect. -- Hugh McMaster

2 3

Re: [8/9] winhttp: Don't try to read data when the server response is HTTP_STATUS_NO_CONTENT or HTTP_STATUS_NOT_MODIFIED.
by Marvin 09 Dec '14

09 Dec '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=10702 Your paranoid android. === w7u (32 bit winhttp) === winhttp.c:2035: Test failed: failed to receive response 12030 winhttp.c:2039: Test failed: failed to query status code 12019 winhttp.c:2040: Test failed: request failed unexpectedly 589826 winhttp.c:2044: Test failed: failed to query authentication schemes 4317 winhttp.c:2045: Test failed: got deadbeef winhttp.c:2046: Test failed: got deadbeef winhttp.c:2047: Test failed: got deadbeef === w8 (32 bit winhttp) === winhttp.c:2035: Test failed: failed to receive response 12030 winhttp.c:2039: Test failed: failed to query status code 12019 winhttp.c:2040: Test failed: request failed unexpectedly 589826 winhttp.c:2044: Test failed: failed to query authentication schemes 4317 winhttp.c:2045: Test failed: got deadbeef winhttp.c:2046: Test failed: got deadbeef winhttp.c:2047: Test failed: got deadbeef

2 1

Re: [9/9] winhttp/tests: Close the connection immediately after authentication.
by Marvin 09 Dec '14

09 Dec '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=10703 Your paranoid android. === w2008s64 (32 bit winhttp) === winhttp.c:2250: Test failed: WinHttpReceiveResponse failed: 12152 winhttp.c:2255: Test failed: WinHttpQueryHeaders failed: 12019 winhttp.c:2256: Test failed: got 0 winhttp.c:2260: Test failed: WinHttpQueryDataAvailable failed: 12019 === w7u (32 bit winhttp) === winhttp.c:2041: Test failed: failed to receive response 12030 winhttp.c:2045: Test failed: failed to query status code 12019 winhttp.c:2046: Test failed: request failed unexpectedly 589826 winhttp.c:2050: Test failed: failed to query authentication schemes 4317 winhttp.c:2051: Test failed: got deadbeef winhttp.c:2052: Test failed: got deadbeef winhttp.c:2053: Test failed: got deadbeef === w8 (32 bit winhttp) === winhttp.c:2041: Test failed: failed to receive response 12030 winhttp.c:2045: Test failed: failed to query status code 12019 winhttp.c:2046: Test failed: request failed unexpectedly 589826 winhttp.c:2050: Test failed: failed to query authentication schemes 4317 winhttp.c:2051: Test failed: got deadbeef winhttp.c:2052: Test failed: got deadbeef winhttp.c:2053: Test failed: got deadbeef

1 0

Re: gdiplus: fix GdipFillRectangleI no effect on memory DC whose windoworigin point has changed
by Marvin 09 Dec '14

09 Dec '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=10699 Your paranoid android. === w7u (32 bit graphics) === graphics.c:5575: Test failed: Expected the color of memory bitmap is blue!graphics: 4644 tests executed (0 marked as todo, 1 failure), 0 skipped.

1 0

Re: [PATCH v2 08/10] combase: Implement creation and deletion of HSTRING objects.
by Sebastian Lackner 09 Dec '14

09 Dec '14

On 08.12.2014 10:26, Martin Storsjo wrote: > + return E_INVALIDARG; > + if (str == NULL) > + { > + *out = NULL; <--- > + return S_OK; <--- > + } > + if (priv->reference) > + return WindowsCreateString(priv->buffer, priv->length, out); Wrong indentation. Moreover I noticed a mistake in patch 10. I had the guess that preallocating an empty string should also return a NULL string-buffer. + /* Test creation of an empty buffer */ + ok(pWindowsPreallocateStringBuffer(0, &ptr, &buf) == S_OK, "Failed to preallocate string buffer\n"); + ok(buf != NULL, "Empty string buffer is a null string\n"); + ok(ptr != NULL, "Empty string didn't return a buffer pointer\n"); + ok(pWindowsDeleteStringBuffer(buf) == S_OK, "Failed to delete string buffer\n"); + The testbot seems to confirm that: https://newtestbot.winehq.org/JobDetails.pl?Key=10687 ( I would suggest to wait with resending till after the daily commits, everything from patch 1-7 should be fine, and it probably doesn't make sense to resend the whole series several times. ;) ) Regards, Sebastian

2 2

Re: gdiplus: fix GdipFillRectangleI no effect on memory DC whose window origin point has changed
by Marvin 09 Dec '14

09 Dec '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=10695 Your paranoid android. === w7u (32 bit graphics) === graphics.c:5575: Test failed: Expected the color of memory bitmap is blue!graphics: 4645 tests executed (0 marked as todo, 1 failure), 0 skipped.

1 0

Puzzle about ExtSelectClipRgn?
by Changhui Liu 08 Dec '14

08 Dec '14

Dear all, I test this code : void test (HDC hdc, HRGN hregion) { RECT srcbox; RECT dstbox; GetClipBox(hdc, &dstbox); GetRgnBox(hregion, &srcbox); TRACE("Before ExtSelectClipRgn:%s,%s\n", wine_dbgstr_rect(&srcbox), wine_dbgstr_rect(&dstbox) ); ExtSelectClipRgn(hdc, hregion, RGN_AND ); GetClipBox(graphics->hdc,&dstbox); TRACE("After ExtSelectClipRgn:%s,%s\n", wine_dbgstr_rect(&dstbox) ); } It output in wine is : Before ExtSelectClipRgn:(693,5)-(763,28),(693,5)-(763,28) After ExtSelectClipRgn:(693,5)-(693,5) But I think it should be output: Before ExtSelectClipRgn:(693,5)-(763,28),(693,5)-(763,28) After ExtSelectClipRgn:(693,5)-(763,28) Where is my understanding mistake, or is it a bug in ExtSelectClipRgn? Thank you!

3 3

Re: [PATCH 4/4] dwrite: Implement GetDesignGlyphAdvances()
by Marvin 08 Dec '14

08 Dec '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=10681 Your paranoid android. === wvistau64 (32 bit font) === font: unhandled exception c0000005 at 00409EDC === w2008s64 (32 bit font) === font: unhandled exception c0000005 at 00409EDC === wvistau64 (64 bit font) === font: unhandled exception c0000005 at 0000000000409275 === w2008s64 (64 bit font) === font: unhandled exception c0000005 at 0000000000409275

1 0

Re: [PATCH 3/4] dwrite: Implement IsMonospacedFont()
by Marvin 08 Dec '14

08 Dec '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=10680 Your paranoid android. === wvistau64 (32 bit font) === font: unhandled exception c0000005 at 00409EDC === w2008s64 (32 bit font) === font: unhandled exception c0000005 at 00409EDC === wvistau64 (64 bit font) === font: unhandled exception c0000005 at 0000000000409275 === w2008s64 (64 bit font) === font: unhandled exception c0000005 at 0000000000409275

1 0

Re: [PATCH] msvcr120: Implement more C99 math functions.
by Piotr Caban 08 Dec '14

08 Dec '14

On 12/06/14 17:07, Martin Storsjo wrote: > +/********************************************************************* > + * cbrt (MSVCR120.@) > + */ > +double CDECL MSVCR120_cbrt(double x) > +{ > +#ifdef HAVE_CBRT > + return cbrt(x); > +#else > + return x < 0 ? -powf(-x, 1.0 / 3.0) : powf(x, 1.0 / 3.0); > +#endif Please use pow instead of powf here. Thanks, Piotr

2 1

Re: [PATCH 05/10] combase: Add stub dll.
by Sebastian Lackner 08 Dec '14

08 Dec '14

Hi Martin, a few things where I am not sure about: [PATCH 05/10] [...] > +@ stub COMBASE_63 > +@ stub COMBASE_64 > +@ stub COMBASE_65 > +@ stub COMBASE_66 > +@ stub COMBASE_67 > +@ stub COMBASE_68 [...] Are these really named exports, or exports by ordinal? If they are by ordinal and have no name assigned they are probably internal, and its not worth exporting them in Wine. I also noticed that combase.dll exports a lot of functions (Co*), which in Wine are implemented in ole32. It probably makes sense to sync that, but that can also be added in a later patch in my opinion. I don't think make_specfiles already supports such a situation. [PATCH 06/10 and also following patches] > +/*********************************************************************** > + * RoInitialize (api-ms-win-core-winrt-l1-1-0.@) > + */ Those comments should probably be changed. [PATCH 07/10] Does creating an empty string really return a HSTRING or just NULL (which seems to behave identical)? It probably makes sense to add a test for that. Does WindowsCreateString or WindowsCreateStringReference strip terminating NULL chars? (Embedded NULL chars are allowed obviously, but it might be possible that trailing NULL chars are handled differently). nsivov on #winehackers also suggested that it might be worth trying to find out what the structure is on Windows, but not sure if its worth the effort. If we're not trying at all to be compatible, we could get rid of one of the two memory allocations by allocating (sizeof(hstring_private) + length) as a single chunk, and setting ->buffer according. [PATCH 09/10] I would also suggest adding tests for the content of the buffer. You can use for example memcmp(...) to verify that the content is correct. [PATCH 10/10] Is the buffer initialized? Are terminating NULLs stripped from the buffer? Regards, Sebastian

2 2

Re: [PATCH 3/4] api-ms-win-core-winrt-string: Implement a few HSTRING functions.
by Sebastian Lackner 07 Dec '14

07 Dec '14

Hi Martin, most of the patch looks okay, but I think there are a few things you should (or could) change. For patch 3/4: * I would split it up in several patches, and after adding the minimally necessary functions always combine the implementation with the corresponding tests. The huge number of functions in a single patch makes it difficult to review. * Include files should also be added as a separate patch. At the moment the formatting looks a bit ugly (random number of linebreaks?). I would also suggest to rename the function arguments to make sure they don't look exactly like MSDN. * Rename function arguments in the implementation itself, to avoid that they look identical to MSDN. * Internal helper functions (like alloc_string) do not necessarily need to return a HRESULT return value, when there are only two possible results. I would suggest using BOOL instead. * In the specfile use 'wstr' for arguments which are widechar strings. This allows to print them with the +relay debug channel. * Not sure how strict Wine is about the coding style, but generally a slighly different style is preferred for new code. Instead of --- snip --- if (...) { .... } --- snip --- the preferred version is --- snip --- if (...) { ... } --- snip --- The same applies also for for and do-while loops. Moreover cast operations like "(HSTRING)string" should usually have no space inbetween of the type and variable name. For patch 4/4: * C++-Style comments like "// ..." are not allowed in Wine source, instead use "/* ... */" for single-line comments or --- snip --- /* ... * ... */ --- snip --- for multi-line comments. * To avoid crashes on machines where this library is not available, it is recommended to skip the tests in such a case. For example: --- snip --- hmod = LoadLibraryA(...); if (!hmod) { win_skip("Failed to load api-ms-win-core-winrt-string-l1-1-0, skipping tests\n"); return; } --- snip --- * It is okay to use define macros for loading function pointers, but they should be defined directly before, and undefined immediately afterwards, to avoid collision with other definitions. I also don't think that checking for != NULL is really necessary, these api-* dlls have a well-defined set of export functions, so it is basically guaranteed that all functions are available. * check_string should also show the line number because it is used very often. The general way to do that is: --- snip --- #define check_string(str, length, has_null) _check_string(__LINE__, str, length, has_null) static void check_string(int line, HSTRING str, UINT32 length, BOOL has_null) { ... ok_(__FILE__, line)(condition, ...); ... } --- snip --- This allows to determine much easier where something goes wrong. * I would also suggest to split the tests. There is no need to put everything in a single function, especially because api-*-string only implements string functions. ;) I would prefer something like: --- snip --- START_TEST(...) { if (!init_functions()) return; test_CreateString(); test_DuplicateString(); ... } --- snip --- (Of course this doesn't mean that WindowsCreateString can only be used in one function.) Regards, Sebastian

2 4

Re: [PATCH 4/4] api-ms-win-core-winrt-string-l1-1-0: Add tests.
by Marvin 07 Dec '14

07 Dec '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=10659 Your paranoid android. === build (build) === Can't determine base name

1 0

Re: [PATCH 15/15] api-ms-win-core-winrt-string: Implement a few HSTRING functions.
by Sebastian Lackner 06 Dec '14

06 Dec '14

On 01.12.2014 11:27, Martin Storsjo wrote: > + > + buf = malloc(sizeof(*buf)); > + if (!buf) > + return E_OUTOFMEMORY; > + buf->buffer = malloc((length + 1) * sizeof(*buf->buffer)); > + if (!buf->buffer) { > + free(buf); > + return E_OUTOFMEMORY; > + } Some of your previous patches also contain changes to ./configure which is an autogenerated file. Afaik its not allowed to include that when submitting patches. Feedback for this part: * HSTRING and HSTRING_HEADER should probably be defined in some include fine. To ensure that the size of private structure matches you could also use C_ASSERT(...), and maybe even disable align of the structure fields. * You should avoid using malloc(...) in Wine source * http://msdn.microsoft.com/en-us/library/br224632(v=vs.85).aspx mentions: """Calling WindowsDeleteString decrements the reference count of the backing buffer, and if the reference count reaches 0, the Windows Runtime de-allocates the buffer.""" I don't see the concept of refcounted backing buffers anywhere in your code, which is most likely wrong. Its difficult to fix that later. * I would suggest starting with some stub functions, and then add tests before sending the actual implementation. BTW: Michael Müller was also working on some api-ms-win-core-* stubs, but I think he is also fine when your patches get upstream instead: https://github.com/wine-compholio/wine-staging/tree/master/patches/api-ms-w… Regards, Sebastian

3 9

Please help spread the word about the Software Freedom Conservancy
by Jeremy White 05 Dec '14

05 Dec '14

Folks, Tony at the Conservancy reached out to us to ask our help in spreading the word about Conservancy. The Conservancy is our sponsoring organization, and they have been a great friend to Wine through the years. As they requested, I'm sending an email blast to our mailing list to spread the word. I'd ask you to scan their email and if you can help them in any of the ways they ask, please help them. They're good people, and good for Wine. Thanks, Jeremy -------- Forwarded Message -------- Subject: Conservancy projects: help us launch the Official Conservancy Supporter program! Date: Wed, 03 Dec 2014 17:17:47 -0500 From: Tony Sebro Hi, all: We at Conservancy are committed to doing whatever we can to support our member projects, and to help you produce great, freely-licensed software for the public's benefit. At this time, we could use the support of you, our member projects, as well. Today, Conservancy launched the official Conservancy Supporter program (http://sfconservancy.org/supporter/). This is our first campaign to build awareness about Conservancy, and our first attempt to really engage the public in a fundraising campaign. While we're glad to help you organize project-specific revenue-generating activities (e.g., project fundraisers, conferences, etc.), we've kept the percentage of revenue we receive from member projects under our FSA so low that it doesn't even pay for a single Conservancy staff member. So, we need our member projects' help to get the word out about who we are, what we do, and how friends of free and open source software can become Conservancy Supporters. Conservancy Supporters will receive: - an "Official Conservancy Supporter" badge for display on their personal websites; - a printable "Official Conservancy Supporter" card; and - a snazzy Conservancy T-Shirt. _ Ways__you can help spread the word_: - Follow @Conservancy on Twitter and/or Identi.ca - Tweet/Dent/Microblog about the Conservancy Supporter program on your social media platform of choice, with a link to the campaign page (please use the #ConservancySupporter hashtag) - If your project has an official social media account, please use that to microblog as well - Send email blasts to your project's mailing lists - Write a blog post or a testimonial about Conservancy (we'd really appreciate it) We thank you in advance for your support -- especially during this giving time of the year! Best, -Tony

1 0

Re: ws2_32/tests: Add SO_BSP_STATE tests
by Marvin 05 Dec '14

05 Dec '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=10633 Your paranoid android. === wxppro (32 bit sock) === sock.c:610: Test failed: oob_server (190): unexpectedly at the OOB mark: 0

1 0

Re: [PATCH 9/9] wined3d: Pass WM_SYSCOMMAND(SC_RESTORE) to DefWindowProc.
by Marvin 05 Dec '14

05 Dec '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=10625 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 8/9] wined3d: Filter messages generated by focus handling.
by Marvin 05 Dec '14

05 Dec '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=10623 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 5/9] d3d8/tests: Test WM_SYSCOMMAND handling.
by Marvin 04 Dec '14

04 Dec '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=10620 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

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 December 2014