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

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

Dec. 19, 2014

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 Dec. 18, 2014

Dec. 18, 2014

> 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 Dec. 18, 2014

Dec. 18, 2014

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 Dec. 18, 2014

Dec. 18, 2014

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 Dec. 18, 2014

Dec. 18, 2014

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 Dec. 17, 2014

Dec. 17, 2014

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 Dec. 17, 2014

Dec. 17, 2014

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 Dec. 17, 2014

Dec. 17, 2014

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 Dec. 17, 2014

Dec. 17, 2014

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 Dec. 17, 2014

Dec. 17, 2014

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 Dec. 17, 2014

Dec. 17, 2014

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 Dec. 17, 2014

Dec. 17, 2014

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 Dec. 16, 2014

Dec. 16, 2014

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 Dec. 16, 2014

Dec. 16, 2014

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 Dec. 15, 2014

Dec. 15, 2014

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 Dec. 15, 2014

Dec. 15, 2014

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 Dec. 15, 2014

Dec. 15, 2014

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 Dec. 15, 2014

Dec. 15, 2014

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 Dec. 15, 2014

Dec. 15, 2014

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 Dec. 14, 2014

Dec. 14, 2014

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 Dec. 13, 2014

Dec. 13, 2014

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 Dec. 13, 2014

Dec. 13, 2014

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 Dec. 12, 2014

Dec. 12, 2014

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ö Dec. 12, 2014

Dec. 12, 2014

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 Dec. 11, 2014

Dec. 11, 2014

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