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

Re: [PATCH 3/3] winecoreaudio.drv: Use AUHAL API instead of AudioQueue

by Ken Thomases

Hi, I'm concerned about the use of the AudioConverter API within the capture callback (ca_capture_cb). I have it embedded in my memory that it's not permitted to call a converter on the device thread. I can't find a hard and fast declaration of that in the documentation, although Technical Note TN2091: Device input using the HAL Output Audio Unit does say this: <https://developer.apple.com/library/mac/technotes/tn2091/_index.html> "If sample rate conversion is needed, it can be accomplished by buffering the input and converting the data on a separate thread with another AudioConverter." If what you're doing were allowed, it would seem they would have mentioned that and not suggested the use of "a separate thread". It also seems that the HAL Output Audio Unit would just do this itself and not have the restriction on the sample rate in the first place. I could have sworn that the API would actually generate errors if you tried to use it on the AUHAL's thread, but I may be thinking of the AUConverter audio unit, instead. Ah, after more searching, I believe it was for the AUConverter audio unit. There's an error, kAudioUnitErr_CannotDoInCurrentContext, that is generated if you try to use such a unit or if you try to make the AudioOutputUnit do the conversion itself. Besides my specific recollection that sample rate conversion is not allowed, there's the general requirement to avoid slow operations in those callbacks. The call to AudioConverterFillComplexBuffer() may be such a slow operation. So could the calls to malloc() in your ca_capture_cb() and feed_cb(). Could you not move the sample rate conversion to the application thread, at the point where the application calls in to get the captured data (or metadata about it)? In AudioClient_IsFormatSupported(), is it really the case that any format for which a stream description can be constructed is supported? Is there a need to try setting the format on an AudioConverter to see if it will accept it? There are still two mentions of AudioQueue in lines like: WARN("AudioQueue doesn't support per-channel volume control\n"); -Ken

June 30, 2014

Re: d3dx9: Implement D3DXCreateTorus() + tests

by Matteo Bruni

Hi Gediminas, 2014-06-30 19:29 GMT+02:00 Gediminas Jakutis <gediminas(a)varciai.lt>: > --- > dlls/d3dx9_36/d3dx9_36.spec | 2 +- > dlls/d3dx9_36/mesh.c | 129 +++++++++++++++++++++++++++++++ > dlls/d3dx9_36/tests/mesh.c | 183 ++++++++++++++++++++++++++++++++++++++++++++ > include/d3dx9shape.h | 2 + > 4 files changed, 315 insertions(+), 1 deletion(-) > +HRESULT WINAPI D3DXCreateTorus(struct IDirect3DDevice9 *device, + float innerradius, float outerradius, UINT sides, UINT rings, struct ID3DXMesh **mesh, ID3DXBuffer **adjacency) The "usual" style is 8 spaces for line continuations (that also applies to some other places in the patch). + float sin; + float cos; Not really an issue but I'd prefer if these wouldn't shadow the functions from math.h. + if (!device || innerradius < 0.0f || outerradius < 0.0f || sides < 3 || rings < 3 || !mesh) + { + return D3DERR_INVALIDCALL; + } Not strictly required but you can either avoid the curly braces (here and below) or add a WARN for the error return condition. Probably a WARN here is nicer. + rotation_step = D3DX_PI / sides * -2.0f; + rotation_curr = 0; Please use 0.0f there instead. + for (i = 0; i < sides; ++i) + { + sin = sinf(rotation_curr); + cos = cosf(rotation_curr); + vertices[i].position.x = innerradius * cos + outerradius; + vertices[i].position.y = 0.0f; + vertices[i].position.z = innerradius * -sin; + vertices[i].normal.x = cos; + vertices[i].normal.y = 0.0f; + vertices[i].normal.z = -sin; + + rotation_curr += rotation_step; + } I might be mistaken but I think you can remove the "-" from the previous "-2.0f" and from both "-sin" here. + for (i = 0; i < numfaces - sides * 2; ++i) + { + faces[i][0] = i % 2 ? i / 2 + sides : i / 2; + faces[i][1] = (i / 2 + 1) % sides ? i / 2 + 1 : i / 2 + 1 - sides; + if ((i + 1 >= sides * 4) && !((i + 1) % sides) && !((i + 1) / sides % 2)) + { + faces[i][2] = (i + 1) / 2; + } + else if (i) + { + faces[i][2] = (i + 1) % (sides * 2) ? (i + 1) / 2 + sides : (i / sides) * sides; + } + else + { + faces[i][2] = sides; + } + } Can't the last "else" just be dropped (and the condition from the previous "else" removed)? I.e. the first "else" for the i == 0 case is equivalent to the second one, AFAICS. Actually the first two branches also look to be the same so this should be enough for the third vertex of each face: faces[i][2] = (i + 1) % (sides * 2) ? (i + 1) / 2 + sides : (i + 1) / 2; + for (j = 0; i < numfaces; ++i, ++j) + { + faces[i][0] = i % 2 ? j / 2 : sides * (rings - 1) + j / 2; This should be equivalent: faces[i][0] = i % 2 ? j / 2 : i / 2; I don't mind all that much for this one though. + faces[i][1] = (i / 2 + 1) % sides ? i / 2 + 1 : i / 2 + 1 - sides; + faces[i][2] = i == numfaces - 1 ? 0 : (j + 1) / 2; + } I guess this separate loop for the last "strip" of the mesh is there to avoid a bunch of "% numvert" in the previous loop. That's okay for me. + hr = D3DXCreateTorus(NULL, 0.0f, 0.0f, 3, 3, &torus, NULL); + ok(hr == D3DERR_INVALIDCALL, "Got result %x, expected %x (D3DERR_INVALIDCALL)\n",hr,D3DERR_INVALIDCALL); Missing spaces after the commas. The notes regarding vertices and faces generation also apply to compute_torus in the test obviously. For some reason your patch has DOS-style CRLF line terminators and that made "git apply" fail for me. Testbot didn't complain though so probably that's not an issue. Generally it's preferred to generate patches with "git format-patch" or even better directly "git send-email".

June 30, 2014

Re: Wine freetext search no longer working

by Jeremy Newman

OK, I'll recover the missing files from the old machine. Should happen later today. -N On 06/29/2014 06:44 AM, Hugh McMaster wrote: > As of 29 June 2014, the freetext source code search option at http://source.winehq.org/search is not working. > > The error message is "Unexpected return value 2 from Glimpse". > > A quick search on the internet reveals the following from http://lxr.sourceforge.net/en/troubleshooting.shtml: > > Unexpected return value x from Glimpse > Glimpse was unable to complete the free-text search query. > If x is 2, files are inaccessible. These usually are the auxiliary caches, which may be missing or have incorrect access rights. The relevant directory is defined by the 'glimpsedir' or 'glimpsedirbase' configuration parameters. > > There is no problem with the identifier search option. > > -- > Hugh McMaster > >

June 30, 2014

Re: [PATCH] riched20: Don't create too many IRichEditOle interfaces for a RichEdit. (try 3)

by Jactry Zeng

Hi, Another try was sent: http://source.winehq.org/patches/data/105376 2014-06-26 19:10 GMT+08:00 Jactry Zeng <jactry92(a)gmail.com>: > Hi Huw, > 2014-06-26 15:54 GMT+08:00 Huw Davies <huw(a)codeweavers.com>: > > > > > > > I'm sure you can think about how to simplify this a bit. > > The clue that it needs simplification is that you've > > got two AddRef()s in there. > > > > Hint: The code is trying to do two things: > > > > 1. If needed, assign an interface to reOle > > 2. AddRef and return. > > > > > --- a/dlls/riched20/richole.c > > > +++ b/dlls/riched20/richole.c > > > @@ -126,12 +126,13 @@ IRichEditOle_fnRelease(IRichEditOle *me) > > > > > > TRACE ("%p ref=%u\n", This, ref); > > > > > > - if (!ref) > > > + if (ref == 1) > > > { > > > TRACE ("Destroying %p\n", This); > > > This->txtSel->reOle = NULL; > > > ITextSelection_Release(&This->txtSel->ITextSelection_iface); > > > > IOleClientSite_Release(&This->clientSite->IOleClientSite_iface); > > > + This->editor->reOle = NULL; > > > > No, this is wrong. This function should remain unchanged. > > > > The editor is in charge of the reOle reference, so it > > needs to release it when the editor is destroyed - > > ie in ME_DestroyEditor(). > > > > I will try again. > Thanks for your review. :) > > > -- > Regards, > Jactry Zeng > > -- Regards, Jactry Zeng

June 30, 2014

Re: RFC: patch 105133

by Henri Verbeet

On 30 June 2014 16:12, Jérôme Gardou <jerome.gardou(a)reactos.org> wrote: > Oh... I thought it at least tried to apply the patch and run the test suite > with the patched wine binary. We'd like that in the future, but currently it only runs the tests on Windows.

June 30, 2014

Re: RFC: patch 105133

by Jérôme Gardou

Le 30.06.2014 16:06, Henri Verbeet a écrit : > On 30 June 2014 16:01, Jérôme Gardou <jerome.gardou(a)reactos.org> wrote: >> According to the patch status page, the following patch is still marked as >> "new". >> http://source.winehq.org/patches/data/105133 >> Is there any prioritisation for the testbot regarding the jobs it processes >> ? >> > There is, but since that patch doesn't touch the tests the testbot is > not really involved. Oh... I thought it at least tried to apply the patch and run the test suite with the patched wine binary.

June 30, 2014

Re: RFC: patch 105133

by Henri Verbeet

On 30 June 2014 16:01, Jérôme Gardou <jerome.gardou(a)reactos.org> wrote: > According to the patch status page, the following patch is still marked as > "new". > http://source.winehq.org/patches/data/105133 > Is there any prioritisation for the testbot regarding the jobs it processes > ? > There is, but since that patch doesn't touch the tests the testbot is not really involved.

June 30, 2014

RFC: patch 105133

by Jérôme Gardou

Hello wine team. According to the patch status page, the following patch is still marked as "new". http://source.winehq.org/patches/data/105133 Is there any prioritisation for the testbot regarding the jobs it processes ? Also, that put aside, I'd like to discuss the approach and the problem there as I understand it: with "modern" stubs, allocations and frees are made per argument. If there is no prioritisation on how this is done, the "freeer" of one argument can rely on data which were freed before in the loop and overwritten, thus causing the mayhem in the heap that can be witnessed here (see https://bugs.winehq.org/show_bug.cgi?id=36743) The patch tries to overcome the problem and frees the arguments marked as "MustFree" before anything else. I believe this is the right approach, but a comment from someone more proficient as me in RPC matters would be greatly appreciated. Regards Jérôme

June 30, 2014

Re: [PATCH 3/5] d3d8: Check the device status in present calls.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7768 Your paranoid android. === w8 (32 bit device) === device.c:2397: Test failed: Expected foreground window 000301BA, got 0002004C. device.c:3039: Test failed: Expected wndproc 0x412780, got 0x412780.

June 30, 2014

Re: [PATCH 2/5] d3d8: Improve d3d8_device_TestCooperativeLevel().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7767 Your paranoid android. === w8 (32 bit device) === device.c:2397: Test failed: Expected foreground window 000301BA, got 0002004C. device.c:3039: Test failed: Expected wndproc 0x412780, got 0x412780.

June 30, 2014

Re: [2/2] ddraw: add dsurface dimension tests, try 10

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, You forgot to fix some IDirectDrawSurface2 macros. Otherwise this looks good. Thanks again for your work! Stefan Am 2014-06-29 16:37, schrieb Patrick Rudolph: > + hr = IDirectDraw2_CreateSurface(ddraw, &surfacedesc, &surface, NULL); > + ok(hr == tests[i].hr, "Pixelformat %s, test %d returned %08x\n", formats[j].name, i, hr); > + > + if (surface) > + { > + IDirectDrawSurface2_Release(surface); > + surface = NULL; > + } > ... > + hr = IDirectDraw2_CreateSurface(ddraw, &surfacedesc, &surface, NULL); > + ok(SUCCEEDED(hr), "CreateSurface returned %08x\n", hr); > + if (surface) > + { > + hr = IDirectDrawSurface2_GetSurfaceDesc(surface, &surfacedesc); > + ok(SUCCEEDED(hr), "GetSurfaceDesc returned %x\n", hr); -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTsTBWAAoJEN0/YqbEcdMwThEP/3uJuJuU4gZNiiRy3AkP6guK cVnLXyasOBmwMNxLSFnt1RXQmYmcmY/cR16I/RRd1NbemC8+tB8PbO3Vp6bTGnx0 i4ZM+EFh+6F6xFzjua99sK67x0MNXqW+fp1L8tz5804piaqcJK/MX9XloMeG45ZL WrGVFqZnFKb67OjoXKqZSo0S4bR/GJveRz9x8KxpGnqsc2Wa/sRftIoiO67FSoaq P1ffH0OEPbkj7pzXFyV2BwHFVIC4LzFXmTWVNgmZfNSnTPossSyg8tuCe9+ZvVZa lVHRu95nda2nh/RRfEk+jH2strX2psmb20/bsNa1RQ4ujWJT+HBcaGbeicsyzqZL i+iJjNG/Pm0DRZ6DPfnUfW6/xIJW89L1fZ8sHLtSJ+jsR3tGQeYV5IAh0G5SBnM2 tXsbrQkVeZ3UfwGVK3zxl+C4UqkXyOhxSR2Bagr3QJqPGi7z2MR0/ScRdfJAAuMj 3yUbHZFYzsGBrgWZ4LYGDaZN2HL2Bnb7Er7QXPCSApgE8klHUwGTOPiRmyuKyYkJ cgysMnnxflVRwLEaMO6roLw4xL849yOiWGIJkFJ+zWZxuweEBEjOPUUv7ch+PfLY UNAWE7+BerPf/0UyNZvXw3MtYOd7cQxFCfwItboUV3iFEaG3ZBYhpT6+/mITHJ2i eP7C9M4fGnoU8F6TbLcZ =ELAp -----END PGP SIGNATURE-----

June 30, 2014

Re: [1/2] ddraw: add dsurface dimension tests, try 10

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch looks good to me. There are two minor style issues, but I don't think they warrant a resend. If Henri has further suggestions you can fix those style issues as well: Note that I have not tested them on Windows yet. My my Mingw is currently broken, and I'm still struggling with Gentoo's crossdev tool. The tests pass on Linux on 32 and 64 bit Wine builds. Am 2014-06-29 16:37, schrieb Patrick Rudolph: > + if ((desc->dwWidth>0xFFFF) || (desc->dwHeight>0xFFFF)) Most other places (and your patch 2) use 0xffff and spaces around ">". > - > - /* Check that we have enough video ram left */ > + > if (pool == WINED3D_POOL_DEFAULT && d3d->flags & WINED3D_VIDMEM_ACCOUNTING) Trailing whitespace. I think Alexandre's git automatically removes that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTsS+qAAoJEN0/YqbEcdMwrjwP/1duFUNuI9buzIl58xj/uRc0 zueU33ssfT0ktJWY2RIWpsOQI79j+WX3MlQvRTCKBY6vYPhYKM8DzAN4QNgGhGLT yPBnmrKQiQwRfmDlpXJkwB1/mV3gSIc6RYHW2vMu2qyiOAPS13Mb5gDuQFnlhLNm tlWrVmvTslkL0hdFt5w/uumqZO/NHnN7kdSktMHFtdQaRYT9PSldYGdYQTT4mFul 8lQ2DaKfUQPc92iJSywEMRwQs/NZf0FYsNaNN47YDAj+8xi4tsQjHoSAZzaU6LVP /izGhSzwTFToEO+MHgYbuU8NNFLSGcceNSkaEzMikIyLYvaHYvBhRSnb9ki6Y04s F2timDIagvSUqn97GTlM2FvQBn8vHVlTFLKx4FPlFC6sFXoJPkQkDf6zjPuRn4oY ZkbXemBJNnU+sLHoOpRJGhoYLktEYmOvHc0WPar3QvrGd1xKbUeRAOUO5YMMPiKe CbhBs00GBrxjaBoXUkiGRnHCs+cBRIo3IbcFrCE3LX5/aDlASNg70p6y2JqGi+BJ aiitq7ds6+OAlvbagPwuuR2YMfSVa5DFbvi8kMpJj+Uh+VQa/8829oY1XVqS3n9j uE/Vd1LqCmLA/wKVG8WqJ60O/pz0nO3fXx4ChLp3fVWu+DHF+XT4PW83FFAX8+u/ jkU5hoc6qI3sXbmggbS6 =ApEH -----END PGP SIGNATURE-----

June 30, 2014

Re: [PATCH 3/5] d3d8: Check the device status in present calls.

by Michael Stefaniuc

On 06/30/2014 11:17 AM, Henri Verbeet wrote: > diff --git a/dlls/d3d8/swapchain.c b/dlls/d3d8/swapchain.c > index e9f4976..067a3e0 100644 > --- a/dlls/d3d8/swapchain.c > +++ b/dlls/d3d8/swapchain.c > @@ -91,11 +91,15 @@ static HRESULT WINAPI d3d8_swapchain_Present(IDirect3DSwapChain8 *iface, > const RGNDATA *dirty_region) > { > struct d3d8_swapchain *swapchain = impl_from_IDirect3DSwapChain8(iface); > + struct d3d8_device *device = impl_from_IDirect3DDevice8(swapchain->parent_device); I kinda don't like this: impl_from_IFoo() should be called only from methods of IFoo. For the rest there is unsafe_impl_from_IFoo(). But in this case, my first impulse would be to make swapchain->parent_device a struct d3d8_device thus avoiding the impl_from_IDirect3DDevice8() altogether. bye michael

June 30, 2014

Re: Test bot error unrelated to patch, should I resend?

by Joris van der Wel

Ah I see, thank you. I probably need to register first to restart jobs, I will do that now. On Sun, Jun 29, 2014 at 12:13 PM, Francois Gouget <fgouget(a)codeweavers.com> wrote: > On Fri, 27 Jun 2014, Joris van der Wel wrote: > > > After I submitted a patch the testbot failed because of an error > unrelated > > to my patch: > > > > === build (build) === > > Could not copy the patch to the VM: the "nc -q0 '10.42.42.130' '4242'" > > command returned 1 > > > > Should I resend my patch, or will this be resolved on its own? > > It is indeed unrelated to the patch. This particular error happens when > the TestBot server fails to connect to the agent inside the VM to send > it work to do. The next set of TestBot patches should cause it to retry > when that happens to make this more robust. > > Note that in the meantime if you get a boterror on a job and you have an > account you can go to the web site and restart your job (which I did on > your job). > > -- > Francois Gouget <fgouget(a)codeweavers.com> >

June 29, 2014

RE: [Patch 1/2] winecfg: Set default button in Libraries tab [fixes bug 12804]

by Hugh McMaster

On Wednesday, 25 June 2014 6:01 AM, André Hentschel wrote: > Am 24.06.2014 10:35, schrieb Hugh McMaster: > > This patch sets the default button to IDC_DLLS_ADDDLL in the Libraries tab > of winecfg when a user is typing in the combo box. > > > > This allows the user to hit the Enter key and add the override. Currently, > hitting the Enter key closes winecfg, which is causing problems with many > users. > > > > The patch fixes bug 12804 and was tested by Austin English. > > That's just a workaround, if you modify winecfg to run on Windows you'll see > that the button works there as expected, the problem lies deeper in the > Wine code... Confirmed. I'll keep looking.

June 29, 2014

Wine freetext search no longer working

by Hugh McMaster

As of 29 June 2014, the freetext source code search option at http://source.winehq.org/search is not working. The error message is "Unexpected return value 2 from Glimpse". A quick search on the internet reveals the following from http://lxr.sourceforge.net/en/troubleshooting.shtml: Unexpected return value x from Glimpse Glimpse was unable to complete the free-text search query. If x is 2, files are inaccessible. These usually are the auxiliary caches, which may be missing or have incorrect access rights. The relevant directory is defined by the 'glimpsedir' or 'glimpsedirbase' configuration parameters. There is no problem with the identifier search option. -- Hugh McMaster

June 29, 2014

Re: [4/5] user32: Set capture earlier on popup menus.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7665 Your paranoid android. === wxppro (32 bit msg) === msg.c:11766: Test failed: SetActiveWindow(0): 0: the msg sequence is not complete: expected 0086 - actual 0000 msg.c:11787: Test failed: SetActiveWindow(hwnd), hwnd not visible: 8: in msg 0x0086 expecting wParam 0x1 got 0x0 msg.c:11793: Test failed: SetActiveWindow(popup), hwnd not visible, popup not visible: 9: in msg 0x0086 expecting wParam 0x1 got 0x0 msg.c:13528: Test failed: key release only: 0: the msg sequence is not complete: expected 0101 - actual 0000 msg.c:13540: Test failed: key press only: 0: the msg sequence is not complete: expected 0100 - actual 0000 msg.c:13552: Test failed: key press repeat: 0: the msg sequence is not complete: expected 0100 - actual 0000 msg.c:13564: Test failed: key release repeat: 0: the msg sequence is not complete: expected 0101 - actual 0000 msg.c:13584: Test failed: key press after setkeyboardstate: 0: the msg sequence is not complete: expected 0100 - actual 0000 msg.c:13604: Test failed: key release after setkeyboardstate: 0: the msg sequence is not complete: expected 0101 - actual 0000 msg.c:13804: Test failed: window hotkey press LWIN: 1: the msg sequence is not complete: expected 0100 - actual 0000 msg.c:13829: Test failed: window hotkey release: 1: the msg sequence is not complete: expected 0101 - actual 0000 msg.c:13834: Test failed: window hotkey release LWIN: 1: the msg sequence is not complete: expected 0101 - actual 0000 msg.c:13862: Test failed: window hotkey combined: 7: the msg sequence is not complete: expected 0100 - actual 0000 msg.c:13876: Test failed: window hotkey previous: 4: the msg sequence is not complete: expected 0100 - actual 0000 msg.c:13891: Test failed: window hotkey new: 3: the msg sequence is not complete: expected 0101 - actual 0000 msg.c:13915: Test failed: thread hotkey press LWIN: 1: the msg sequence is not complete: expected 0100 - actual 0000 msg.c:13944: Test failed: thread hotkey release: 1: the msg sequence is not complete: expected 0101 - actual 0000 msg.c:13952: Test failed: thread hotkey release LWIN: 1: the msg sequence is not complete: expected 0101 - actual 0000 === w7u (32 bit msg) === msg.c:12099: Test failed: unexpected hwnd 00090138 msg.c:12121: Test failed: bad time 30ab9/30ac9

June 29, 2014

Re: Test bot error unrelated to patch, should I resend?

by Francois Gouget

On Fri, 27 Jun 2014, Joris van der Wel wrote: > After I submitted a patch the testbot failed because of an error unrelated > to my patch: > > === build (build) === > Could not copy the patch to the VM: the "nc -q0 '10.42.42.130' '4242'" > command returned 1 > > Should I resend my patch, or will this be resolved on its own? It is indeed unrelated to the patch. This particular error happens when the TestBot server fails to connect to the agent inside the VM to send it work to do. The next set of TestBot patches should cause it to retry when that happens to make this more robust. Note that in the meantime if you get a boterror on a job and you have an account you can go to the web site and restart your job (which I did on your job). -- Francois Gouget <fgouget(a)codeweavers.com>

June 29, 2014

Re: [2/2] ddraw: add dsurface dimension tests, try 9

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-06-28 17:43, schrieb Patrick Rudolph: > + for (j = 0; j < sizeof(formats) / sizeof(*formats); j ++) > + { > + for (i = 0; i < sizeof(tests) / sizeof(*tests); i ++) > + { I don't think we use "i ++" with a space anywhere. Please make it i++ or ++i. > + hr = IDirectDraw_SetCooperativeLevel(ddraw, NULL, DDSCL_NORMAL); > + ok(SUCCEEDED(hr), "SetCooperativeLevel failed with %08x\n", hr); > + IDirectDraw_Release(ddraw); > + DestroyWindow(window); > +} The SetCooperativeLevel call is redundant here. I think it was used in the old test because dsurface.c re-used the IDirectDraw object. > + hr = IDirectDraw2_CreateSurface(ddraw, &surfacedesc, &surface, NULL); > + ok(hr == tests[i].hr, "Pixelformat %s, test %d returned %08x\n", formats[j].name, i, hr); > + > + if (surface) > + { > + IDirectDrawSurface2_Release(surface); > + surface = NULL; > + } IDirectDraw2_CreateSurface returns an IDirectDrawSurface, not IDirectDrawSurface2. Other than that this patch looks good to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTr7XvAAoJEN0/YqbEcdMwYwMP/RXeG9kiO+8EJVRDOaPiSi3O YOWppnsurP6oDCWo9RdtdbarfLGYeypGMPwTi/RAkdgYFbBJvqZhMGyINQ3DqCkn nLVKZCfSBkKFFRG3IR4HixVqqlk/vXqtdFizV7IuzQYuGLdUCFPDKYqldDCQtdGH vKGH97qJjIe28ArcHXPufdpV0ZxJBgKPn4XxD8ZquElPEPB0obF7jONYMohmWvWr 7bea+n7ecKNlfWUM/ROb0S/OBP2l8aQ/ZoGKdxQTJKDS6LJzAbkClt5limDnsToV uabvHXvfv8t4jw2Sa3MkJEAcqWQ4fgkcqxltGk/AKNdmgs0Wfhp7ZdLGpZqFPjp6 tlNWsoU69NHRocghc41UB2droIbcU17U7jP7hd1kZOwGg1ksjDoDF2P/n375MFV7 gdKEMELD0c/i9Hy6pFYpQUgnS5X6pNcnHJR3EcxOi/lLUMBMnPpsWiDIQzcG9f58 hcTznm8MR2J1tphYZ4bnE7VmOXZOpDNqY7kyLe8PRMaOJlo70Z2yRAiqTL1dCqVP ntZ7i7CeSxrejg8SWkzWwgBKKMHJ22fCK3UkfewbLqxmUcMVteypZ/ESh82C3LFE OZVOW/iY2Ilt+dEdoH6guRV/2trzfj3UXOsLC9ZNmcl+VL4PLN+N8gytH9Q23/Ak ApTtStXqJfLTv4OI7AHI =VHdx -----END PGP SIGNATURE-----

June 29, 2014

Re: [1/2] ddraw: add dsurface dimension tests, try 9

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-06-28 17:43, schrieb Patrick Rudolph: > + if ((desc->ddsCaps.dwCaps & DDSCAPS_VIDEOMEMORY) && (hr == E_OUTOFMEMORY)) > + hr = DDERR_OUTOFVIDEOMEMORY; I don't like this. wined3d should return WINED3DERR_OUTOFVIDEOMEMORY when the emulated adapter memory is exhausted. I guess it returns E_OUTOFMEMORY because it first tries to allocate heap memory and then checks if there's enough adapter memory left. If you swap the order of operations in resource_init() in dlls/wined3d/resource.c this should be much nicer. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTr7QkAAoJEN0/YqbEcdMwQEAQAJbgNG0XDSpLeU6PjGhJf9+2 jAwldh9cCrKtSotndSe7IQ9aKGKtG/akF7u219ciaEHE2oXy9Qtcj31PIpA0Zh80 V2kv+rMU4gN+b55OaInIO8hEFxMcHEUGcaMguMyUJdjsZtHUBX066QwmP2VKP822 mYsNT4E4pNi20Bn7HoddGzlb5oA0EwNXLojnQhHQLBE6EUSA/EIgYWuRBRcyTGrY 4144gvnXHUMSxajxi+cQKcWKD56+hODNGTtDZeuo94h+PoV/B+QNz0OOUCy5O+3F KnNL/Njy/FeNYoi+MCdVdBhhJiQAaUuV2vhxGbSmHmBf1p71/JcCsORAg5pefemD hRsThGJrNfPPFdksF6pbszEQRPNLU8n0a+5HQ2j7xKqGTmT+Rek1H8etVQM/xVt3 e3nhN5VY2UNT0irckjK0imMr/3ydYs7wWxE++Xh4mKAeXbWII1lcVJSlq+dGTnVx dtOdPUtJS9QSiMgDjBETRG1JjyC57TNfXK2IwLHst1wZ+0jMZ3tENZZX2H6F2XWT T+UK9+lLJnvztmcA8KC4VirsLPJmJJGlhFsuZEsCUUH/rUC3CFFCAuvk3fA83mJp +Nxf/uLkUkSZTAMX717vXoL5p0i6/Vzdx2vYjX3O/H7DiP1mU/OyTOccklhmAhb/ 7K15mms5Z4VV6FdOjXPG =dq6I -----END PGP SIGNATURE-----

June 29, 2014

XFORM matrix and rotation bug

by Alexander Almaleh

While working on the previous bug with PlgBlt(), I noticed there is another one with the XFORM matrix. I've submitted a bug report at https://bugs.winehq.org/show_bug.cgi?id=36815 . I want to try to debug it and find a solution, but I need some help. Can someone tell me where the code is where the XFORM matrix is used to transform the coordinates? I mean where the actual blitting is done. Also, how is it done? Does wine use an internal buffer and all the operations are made manually, or does it just translate the blitting operations to the X server?

June 28, 2014

Re: Test bot error unrelated to patch, should I resend?

by Frédéric Delanoy

On Fri, Jun 27, 2014 at 9:34 PM, Joris van der Wel <joris(a)jorisvanderwel.com> wrote: > After I submitted a patch the testbot failed because of an error unrelated > to my patch: > > === build (build) === > Could not copy the patch to the VM: the "nc -q0 '10.42.42.130' '4242'" > command returned 1 > > Should I resend my patch, or will this be resolved on its own? It's generally a temporary error, so please resend. If it persists, you can contact François Gouget, who manages the testbot. -- Frédéric Delanoy

June 28, 2014

Re: mshtml/tests: Fix a memory leak (valgrind).

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7746 Your paranoid android. === w2000pro (32 bit htmldoc) === htmldoc: unhandled exception c0000005 at 00090100 === wxppro (32 bit htmldoc) === htmldoc: unhandled exception c0000005 at 3C8363A7 === wvistau64 (32 bit htmldoc) === htmldoc: unhandled exception c0000005 at 00000000 === w7u (32 bit htmldoc) === htmldoc.c:2863: Test failed: unexpected command 74 The test timed out === w8 (32 bit htmldoc) === htmldoc.c:2863: Test failed: unexpected command 74 htmldoc.c:2863: Test failed: unexpected command 74 htmldoc.c:2863: Test failed: unexpected command 74 htmldoc.c:6113: Test failed: LoadHistory failed: 80070057 htmldoc.c:6117: Test failed: expected FireBeforeNavigate2 htmldoc.c:6118: Test failed: expected Invoke_AMBIENT_SILENT htmldoc.c:6119: Test failed: expected Invoke_AMBIENT_OFFLINEIFNOTCONNECTED htmldoc.c:2781: Test failed: unexpected state L"uninitialized", expected 1 htmldoc.c:2781: Test failed: VT_I4(out)=0, expected 1 htmldoc.c:367: Test failed: expected Exec_SETTITLE htmldoc.c:5666: Test failed: unexpected state L"uninitialized", expected 1 htmldoc.c:5666: Test failed: VT_I4(out)=0, expected 1 htmldoc.c:2781: Test failed: unexpected state L"uninitialized", expected 1 htmldoc.c:2781: Test failed: VT_I4(out)=0, expected 1 htmldoc.c:2781: Test failed: unexpected state L"uninitialized", expected 1 htmldoc.c:2781: Test failed: VT_I4(out)=0, expected 1 The test timed out === wvistau64 (64 bit htmldoc) === htmldoc: unhandled exception c0000005 at 000000007137D8A6

June 28, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 4)

by Shuai Meng

Thank you Piotr. Yes, Sgn(Null) will return error, so do conversion functions. I wonder whether should I send some patches to fix the conversion functions. As for Sgn(Null), I don't know how describe this error, I mean, I can't match the error_const_value between wine and windows document. For example, when Err.number = 458, it is described as DISP_E_BADVERTYPE in wine while in windows document it is Variable uses an Automation type not supported in VBScript <http://msdn.microsoft.com/en-us/library/93dk459a(v=vs.84).aspx> ( http://msdn.microsoft.com/en-us/library/xe43cc8d(v=vs.84).aspx) I have found that when Sgn(Null) is called, Err.number = 94, this error is described as Invalid use of Null <http://msdn.microsoft.com/en-us/library/c6ct86c6(v=vs.84).aspx>, but I can't find the correspond description in wine/include/winerror.h. So I shall be very grateful if you can offer some hints. 2014-06-27 17:42 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > Please add VT_NULL argument handling and tests. This function is returning > error on Sgn(Null) call. >

June 28, 2014

Test bot error unrelated to patch, should I resend?

by Joris van der Wel

After I submitted a patch the testbot failed because of an error unrelated to my patch: === build (build) === Could not copy the patch to the VM: the "nc -q0 '10.42.42.130' '4242'" command returned 1 Should I resend my patch, or will this be resolved on its own? Thanks

June 27, 2014

Re: [PATCH 2/3] mmdevapi: Don't stop sending event signals after IAudioClient::Stop

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7740 Your paranoid android. === w7u (32 bit capture) === capture.c:427: Test failed: Wait(event) after Stop gave 102 === w8 (32 bit capture) === capture.c:228: Test failed: Position 1655 expected 823 capture.c:256: Test failed: Position 1655 expected 823 capture.c:307: Test failed: expect DISCONTINUITY 0 capture.c:313: Test failed: Position 2103 gap 832 capture.c:333: Test failed: Position 3063 expected 1719 capture.c:334: Test failed: flags 1 capture.c:358: Test failed: Position 4215 expected 2167 === 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

June 27, 2014

Re: New WineHQ Server

by Jerome Leclanche

Congrats on the new server guys. And thanks to the anonymous donor. :) J. Leclanche On Fri, Jun 27, 2014 at 2:48 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: > Hi Folks, > > As you probably saw, we have deployed a new server to replace our 5 year old > work horse. This new server will hopefully hold us for the next 5 years. > It's got good specs; 6 core Xeon, 32G of RAM (easily expandable to 128), > raid 10 (also easily expandable). > > In a particularly nice development, this server was purchased by the > Software Freedom Conservancy using funds provided by a donor. This donor > doesn't want a particularly big fuss made out of it, and so prefers that I > not announce a name publicly. > > I'd like to thread this needle somewhat carefully, as *I* think it's a > remarkably generous gift. So I propose that, at our next convenient > opportunity, we all lift a glass in appreciation of anonymous donors > everywhere! > > Cheers, > > Jeremy > >

June 27, 2014

New WineHQ Server

by Jeremy White

Hi Folks, As you probably saw, we have deployed a new server to replace our 5 year old work horse. This new server will hopefully hold us for the next 5 years. It's got good specs; 6 core Xeon, 32G of RAM (easily expandable to 128), raid 10 (also easily expandable). In a particularly nice development, this server was purchased by the Software Freedom Conservancy using funds provided by a donor. This donor doesn't want a particularly big fuss made out of it, and so prefers that I not announce a name publicly. I'd like to thread this needle somewhat carefully, as *I* think it's a remarkably generous gift. So I propose that, at our next convenient opportunity, we all lift a glass in appreciation of anonymous donors everywhere! Cheers, Jeremy

June 27, 2014

Re: [PATCH 1/4] vbscript: Implemented TypeName(try 4)

by Shuai Meng

2014-06-27 17:37 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > This patch was already committed. Please update wine source before sending > patches. > > Thank you Piotr, but this patch is not completed, I think I should resend it. If not, maybe I can add some getVT tests to it. > Cheers, > Piotr >

June 27, 2014

Re: [PATCH 2/5] d3d8/tests: Add some lost device tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7731 Your paranoid android. === w8 (32 bit device) === device.c:2397: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:3039: Test failed: Expected wndproc 0x412780, got 0x412780.

June 27, 2014

Re: [PATCH 4/4] vbscript: Implemented Abs(try 4)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7727 Your paranoid android. === build (build) === Patch failed to apply

June 27, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 4)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7726 Your paranoid android. === build (build) === Patch failed to apply

June 27, 2014

Re: [PATCH 2/4] vbscript: Implemented VarType(try 4)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7725 Your paranoid android. === build (build) === Patch failed to apply

June 27, 2014

Re: [PATCH 1/4] vbscript: Implemented TypeName(try 4)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7724 Your paranoid android. === build (build) === Patch failed to apply

June 27, 2014

Re: [2/7] advapi32: Changed an invalid comment

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7716 Your paranoid android. === w2008s64 (32 bit security) === Unable to set the VM system time: the "nc -q0 '10.42.42.136' '4242'" command returned 1

June 27, 2014

Re: [PATCH 4/4] vbscript: Implemented Abs(try 4)

by Piotr Caban

On 06/27/14 04:44, Shuai Meng wrote: > static HRESULT Global_Abs(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > { > - FIXME("\n"); > - return E_NOTIMPL; > + double v; > + HRESULT hres; > + > + TRACE("(%s)\n", debugstr_variant(arg)); > + > + assert(args_cnt == 1); > + > + > + if(V_VT(arg) == VT_NULL) > + return return_null(res); > + > + hres = to_double(arg, &v); > + if (FAILED(hres)) > + return hres; > + > + if(res) { > + V_VT(res) = VT_R8; > + V_R8(res) = v >= 0 ? v : -v; > + } > + return S_OK; > } You can use return_double helper here. Also there are 2 newlines after assert.

June 27, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 4)

by Piotr Caban

Please add VT_NULL argument handling and tests. This function is returning error on Sgn(Null) call.

June 27, 2014

Re: [PATCH 2/4] vbscript: Implemented VarType(try 4)

by Piotr Caban

On 06/27/14 04:40, Shuai Meng wrote: > + if(res) { > + V_VT(res) = VT_I2; > + V_I2(res) = V_VT(arg); > + } > + return S_OK; You can use return_short helper here.

June 27, 2014

Re: [PATCH 1/4] vbscript: Implemented TypeName(try 4)

by Piotr Caban

This patch was already committed. Please update wine source before sending patches. Cheers, Piotr

June 27, 2014

Fwd: [1/7] server: Any of the 4 SE_*_DEFAULTED controls should not be stored on objects, their usage is transient. (try 3)

by Joris van der Wel

Just a heads up in case anyone missed this, it looks like the VM is offline? ---------- Forwarded message ---------- From: Marvin <testbot(a)winehq.org> Date: Thu, Jun 26, 2014 at 10:05 PM Subject: Re: [1/7] server: Any of the 4 SE_*_DEFAULTED controls should not be stored on objects, their usage is transient. (try 3) To: joris(a)jorisvanderwel.com Cc: wine-devel(a)winehq.org 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=7715 Your paranoid android. === build (build) === Could not copy the patch to the VM: the "nc -q0 '10.42.42.130' '4242'" command returned 1

June 26, 2014

Re: [1/7] server: Any of the 4 SE_*_DEFAULTED controls should not be stored on objects, their usage is transient. (try 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7715 Your paranoid android. === build (build) === Could not copy the patch to the VM: the "nc -q0 '10.42.42.130' '4242'" command returned 1

June 26, 2014

Re: [PATCH 4/5] msvcrt: Use file->_flag to check if file buffering is enabled

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/msvcrt/file.c | 64 > +++++++++++++++++++++++++++++------------------------- > 1 file changed, 35 insertions(+), 29 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M mshtml.dll -p mshtml_test.exe.so dom && touch dom.ok wine: Unhandled page fault on write access to 0x00000000 at address 0x559c685b (thread 0045), starting debugger... Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x559c685b). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:559c685b ESP:0032ea30 EBP:0032ea58 EFLAGS:00210246( R- -- I Z- -P- ) EAX:00000000 EBX:55a2ba90 ECX:00000030 EDX:00000001 ESI:55a33cc0 EDI:003d2de3 Stack dump: 0x0032ea30: 0000001e 00000000 4d430003 00000000 0x0032ea40: 0032ea60 55a2ba90 0032ea98 559c6943 0x0032ea50: 55a2ba90 55a33cc0 0032ea98 559c6a7e 0x0032ea60: 00000030 55a33cc0 0032ed78 7bc3c409 0x0032ea70: 00000000 003d2d24 0000004b 00000000 0x0032ea80: 000001f4 003d2de3 0032eab8 003d2d98 Backtrace: =>0 0x559c685b MSVCRT__flsbuf+0x4b(c=<is not available>, file=<is not available>) [/home/julliard/wine/wine/dlls/msvcrt/file.c:3671] in msvcrt (0x0032ea58) 1 0x559c6a7e MSVCRT_fwrite+0x17d(ptr=<is not available>, size=<is not available>, nmemb=<is not available>, file=<is not available>) [/home/julliard/wine/wine/dlls/msvcrt/file.c:3738] in msvcrt (0x0032ea98) 2 0x00334cd0 in nspr4 (+0x4ccf) (0x0032eab8) 3 0x003354d3 in nspr4 (+0x54d2) (0x0032ed38) 4 0x6a65ce06 in xul (+0xa1ce05) (0x0032edd8) 5 0x69f4e2ef in xul (+0x30e2ee) (0x0032ef18) 0x559c685b MSVCRT__flsbuf+0x4b [/home/julliard/wine/wine/dlls/msvcrt/file.c:3671] in msvcrt: movb %cl,0x0(%eax) 3671 *file->_ptr++ = c; -- Alexandre Julliard julliard(a)winehq.org

June 26, 2014

Re: [PATCH 3/5] msvcrt: Support NULL buffer in setvbuf

by Francois Gouget

On Thu, 26 Jun 2014, Piotr Caban wrote: [...] > Testbot failed to update wine source yesterday. For whatever reason the build VM's disk image became corrupted. This is why it suddenly got a Perl error in an unchanged Perl script. It also had a bunch of other errors with many tools like ls not working anymore. So time morning I restored the disk image from backup and now it appears to be working fine again. I'm keeping the broken disk image around in case someone's interested in doing some forensic analysis to figure out what happened (I checked that the file could be read without trouble so it's not an issue in the host's disk). However given that the VM host still runs the 3.2.0 kernel (to avoid further instability in newer kernels ironically), it may not be very fruitful. -- Francois Gouget <fgouget(a)codeweavers.com>

June 26, 2014

Re: [PATCH 4/4] vbscript: Implemented Abs(try 2)

by Piotr Caban

On 06/26/14 12:13, Shuai Meng wrote: > I guess you mean that I need to handle res==NULL case in branch > if(V_VT(arg) == VT_NULL), right? Yes, but return_null() function will already cover it for you. > There is another problem: though Abs(Null) should return Null according to > http://msdn.microsoft.com/en-__us/library/307330xe(v=vs.84).__aspx > <http://msdn.microsoft.com/en-us/library/307330xe(v=vs.84).aspx> , but I > test it in WINXP, i.e. when arg == Null, the vbscript code: > Call Abs(Null) > and > dim b > b = Abs(Null) > MsgBox b > returns an error. I don't see this issue. Probably you have done something incorrectly. Here's result from a testbot run that tests Abs(Null). The tests are working on all machines. http://newtestbot.winehq.org/JobDetails.pl?Key=7712

June 26, 2014

Re: [PATCH] gdi32: XFORM matrix in PlgBlt() is calculated incorrectly

by GOUJON Alexandre

On 06/26/2014 02:04 PM, Alexander Almaleh wrote: > As suggested by Sebastian Lackner, I am submitting his much simpler > version of the fix. Only one line is touched. The patch file is attached. > > The bugzilla link is http://bugs.winehq.org/show_bug.cgi?id=36504 Patches should be sent to wine-patches(a)winehq.org, please read http://wiki.winehq.org/SubmittingPatches for more information

June 26, 2014

Re: [PATCH] gdi32: XFORM matrix in PlgBlt() is calculated incorrectly

by Alexander Almaleh

I see that the file was scrubbed, I don't know why, so I'm pasting it, just in case. >From 603c09dee7beda5a6be08fe252bffecda8d48ed8 Mon Sep 17 00:00:00 2001 From: Alexander Almaleh <sashoalm(a)gmail.com> Date: Thu, 26 Jun 2014 14:56:49 +0300 Subject: [PATCH] Fix for http://bugs.winehq.org/show_bug.cgi?id=36504. --- dlls/gdi32/bitblt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dlls/gdi32/bitblt.c b/dlls/gdi32/bitblt.c index 4750d1b..762ca0f 100644 --- a/dlls/gdi32/bitblt.c +++ b/dlls/gdi32/bitblt.c @@ -1037,7 +1037,7 @@ BOOL WINAPI PlgBlt( HDC hdcDest, const POINT *lpPoint, /* Y components */ xf.eM12 = (plg[1].y*(rect[2].y - rect[0].y) - plg[2].y*(rect[1].y - rect[0].y) - plg[0].y*(rect[2].y - rect[1].y)) / det; - xf.eM22 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y - rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det; + xf.eM22 = (rect[1].x*(plg[2].y - plg[0].y) - rect[2].x*(plg[1].y - plg[0].y) - rect[0].x*(plg[2].y - plg[1].y)) / det; xf.eDy = (rect[0].x*(rect[1].y*plg[2].y - rect[2].y*plg[1].y) - rect[1].x*(rect[0].y*plg[2].y - rect[2].y*plg[0].y) + rect[2].x*(rect[0].y*plg[1].y - rect[1].y*plg[0].y) -- 1.7.10.4 On Thu, Jun 26, 2014 at 3:04 PM, Alexander Almaleh <sashoalm(a)gmail.com> wrote: > As suggested by Sebastian Lackner, I am submitting his much simpler > version of the fix. Only one line is touched. The patch file is attached. > > The bugzilla link is http://bugs.winehq.org/show_bug.cgi?id=36504 > >

June 26, 2014

[PATCH] gdi32: XFORM matrix in PlgBlt() is calculated incorrectly

by Alexander Almaleh

As suggested by Sebastian Lackner, I am submitting his much simpler version of the fix. Only one line is touched. The patch file is attached. The bugzilla link is http://bugs.winehq.org/show_bug.cgi?id=36504

June 26, 2014

Re: [PATCH] riched20: Don't create too many IRichEditOle interfaces for a RichEdit. (try 3)

by Jactry Zeng

Hi Huw, 2014-06-26 15:54 GMT+08:00 Huw Davies <huw(a)codeweavers.com>: > > > I'm sure you can think about how to simplify this a bit. > The clue that it needs simplification is that you've > got two AddRef()s in there. > > Hint: The code is trying to do two things: > > 1. If needed, assign an interface to reOle > 2. AddRef and return. > > > --- a/dlls/riched20/richole.c > > +++ b/dlls/riched20/richole.c > > @@ -126,12 +126,13 @@ IRichEditOle_fnRelease(IRichEditOle *me) > > > > TRACE ("%p ref=%u\n", This, ref); > > > > - if (!ref) > > + if (ref == 1) > > { > > TRACE ("Destroying %p\n", This); > > This->txtSel->reOle = NULL; > > ITextSelection_Release(&This->txtSel->ITextSelection_iface); > > IOleClientSite_Release(&This->clientSite->IOleClientSite_iface); > > + This->editor->reOle = NULL; > > No, this is wrong. This function should remain unchanged. > > The editor is in charge of the reOle reference, so it > needs to release it when the editor is destroyed - > ie in ME_DestroyEditor(). > I will try again. Thanks for your review. :) -- Regards, Jactry Zeng

June 26, 2014

Re: [PATCH 3/5] msvcrt: Support NULL buffer in setvbuf

by Piotr Caban

On 06/26/14 12:31, Marvin wrote: > 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=7709 > > Your paranoid android. > > > === build (build) === > Patch failed to apply Testbot failed to update wine source yesterday.

June 26, 2014

Re: [PATCH 5/5] msvcrt: Don't touch _bufsiz value while initializing FILE structure

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7710 Your paranoid android. === build (build) === Patch failed to apply

June 26, 2014

Re: [PATCH 3/5] msvcrt: Support NULL buffer in setvbuf

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7709 Your paranoid android. === build (build) === Patch failed to apply

June 26, 2014

Re: [PATCH 4/4] vbscript: Implemented Abs(try 2)

by Shuai Meng

2014-06-26 16:08 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 06/26/14 06:05, Shuai Meng wrote: > >> Hi, >> I notice that Abs(Null) should return Null according to >> http://msdn.microsoft.com/en-us/library/307330xe(v=vs.84).aspx >> >> In wine source code, NULL is defined as 0 in >> file dlls/windowscodecs/ungif.h, line 66. I have tried to write like this: >> 1260 if(V_VT(arg) == VT_NULL) { >> 1261 V_VT(res) = VT_NULL; >> 1262 V_NULL(res) = NULL; >> 1263 } >> > In case of VT_NULL variant type there's no need to set variant value. You > only need to set V_VT(res) to VT_NULL. Thank you Piotr. I get it. > You also need to handle res==NULL case here. > I guess you mean that I need to handle res==NULL case in branch if(V_VT(arg) == VT_NULL), right? There is another problem: though Abs(Null) should return Null according to http://msdn.microsoft.com/en-us/library/307330xe(v=vs.84).aspx , but I test it in WINXP, i.e. when arg == Null, the vbscript code: Call Abs(Null) and dim b b = Abs(Null) MsgBox b returns an error.

June 26, 2014

Re: [4/7] server: Setting a security descriptor should not replace an existing owner or group if only a DACL is being set.

by Michael Stefaniuc

Hello Joris, On 06/26/2014 01:13 AM, Joris van der Wel wrote: > +#define CHECK_DACL_IS_NULL(o) \ > + do{ \ > + SECURITY_DESCRIPTOR *queriedSD = NULL; \ > + PACL queriedAcl = NULL; \ > + BOOL dacl_present; \ > + BOOL dacl_defaulted; \ > + SECURITY_DESCRIPTOR_CONTROL control; \ > + DWORD revision; \ > + queriedSD = test_get_security_descriptor( o, __LINE__ ); \ > + queriedAcl = (PACL)0xdeadbeef; \ > + res = GetSecurityDescriptorDacl(queriedSD, &dacl_present, &queriedAcl, &dacl_defaulted); \ > + ok(res, "GetSecurityDescriptorDacl failed with error %d\n", GetLastError()); \ > + res = GetSecurityDescriptorControl(queriedSD, &control, &revision); \ > + ok(res, "GetSecurityDescriptorControl failed with error %d\n", GetLastError()); \ > + ok(dacl_present, "DACL should be present (even though the DACL is NULL)\n"); \ > + ok(queriedAcl == NULL, "Setting a NULL DACL, should also return a NULL DACL\n"); \ > + ok(!dacl_defaulted, "Defaulted is true\n"); \ > + ok((control & SE_DACL_DEFAULTED) == 0, "SE_DACL_DEFAULTED is set\n"); \ > + HeapFree(GetProcessHeap(), 0, queriedSD); \ > + }while(0) > + please try to avoid monster macros and use separate functions instead. You can still use a macro to pass __LINE__ to the function and use ok(__FILE__, line)(...) inside that function. bye michael

June 26, 2014

Re: [PATCH 4/4] vbscript: Implemented Abs(try 2)

by Shuai Meng

2014-06-26 16:20 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > > On 06/26/14 06:05, Shuai Meng wrote: > > In wine source code, NULL is defined as 0 in > > file dlls/windowscodecs/ungif.h, line 66. I have tried to write like > this: > > 1260 if(V_VT(arg) == VT_NULL) { > > 1261 V_VT(res) = VT_NULL; > > 1262 V_NULL(res) = NULL; > > 1263 } > > Hint: there already is return_null helper. > > Jacek > Thank you Jacek, that helps a lot :) I should read source code more frequently in case of forgetting something.

June 26, 2014

Re: [PATCH 4/4] vbscript: Implemented Abs(try 2)

by Jacek Caban

On 06/26/14 06:05, Shuai Meng wrote: > In wine source code, NULL is defined as 0 in > file dlls/windowscodecs/ungif.h, line 66. I have tried to write like this: > 1260 if(V_VT(arg) == VT_NULL) { > 1261 V_VT(res) = VT_NULL; > 1262 V_NULL(res) = NULL; > 1263 } Hint: there already is return_null helper. Jacek

June 26, 2014

Re: [PATCH 2/4] vbscript: Implemented VarType(try 2)

by Piotr Caban

On 06/26/14 06:15, Shuai Meng wrote: > I think over these codes again, ~VT_TYPEMASK is equal to 0, V_VT(arg) & > ~VT_TYPEMASK will always be equal to 0, and then the codes belong to > this if branch will never be executed, so why we write them? ~VT_TYPEMAST is not equal to 0.

June 26, 2014

Re: [PATCH 4/4] vbscript: Implemented Abs(try 2)

by Piotr Caban

On 06/26/14 06:05, Shuai Meng wrote: > Hi, > I notice that Abs(Null) should return Null according to > http://msdn.microsoft.com/en-us/library/307330xe(v=vs.84).aspx > > In wine source code, NULL is defined as 0 in > file dlls/windowscodecs/ungif.h, line 66. I have tried to write like this: > 1260 if(V_VT(arg) == VT_NULL) { > 1261 V_VT(res) = VT_NULL; > 1262 V_NULL(res) = NULL; > 1263 } In case of VT_NULL variant type there's no need to set variant value. You only need to set V_VT(res) to VT_NULL. You also need to handle res==NULL case here.

June 26, 2014

Re: [PATCH] riched20: Don't create too many IRichEditOle interfaces for a RichEdit. (try 3)

by Huw Davies

On Thu, Jun 26, 2014 at 02:52:16PM +0800, Jactry Zeng wrote: > diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c > index 2af2582..55821bf 100644 > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -4468,7 +4468,20 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > case EM_GETOLEINTERFACE: > { > LPVOID *ppvObj = (LPVOID*) lParam; > - return CreateIRichEditOle(editor, ppvObj); > + if (editor->reOle) > + { > + *ppvObj = editor->reOle; > + IRichEditOle_AddRef(*ppvObj); > + return 1; > + } > + > + if (CreateIRichEditOle(editor, ppvObj)) > + { > + editor->reOle = *ppvObj; > + IRichEditOle_AddRef(*ppvObj); > + return 1; > + } > + return 0; I'm sure you can think about how to simplify this a bit. The clue that it needs simplification is that you've got two AddRef()s in there. Hint: The code is trying to do two things: 1. If needed, assign an interface to reOle 2. AddRef and return. > --- a/dlls/riched20/richole.c > +++ b/dlls/riched20/richole.c > @@ -126,12 +126,13 @@ IRichEditOle_fnRelease(IRichEditOle *me) > > TRACE ("%p ref=%u\n", This, ref); > > - if (!ref) > + if (ref == 1) > { > TRACE ("Destroying %p\n", This); > This->txtSel->reOle = NULL; > ITextSelection_Release(&This->txtSel->ITextSelection_iface); > IOleClientSite_Release(&This->clientSite->IOleClientSite_iface); > + This->editor->reOle = NULL; No, this is wrong. This function should remain unchanged. The editor is in charge of the reOle reference, so it needs to release it when the editor is destroyed - ie in ME_DestroyEditor(). Huw.

June 26, 2014

Re: [PATCH 2/4] vbscript: Implemented VarType(try 2)

by Shuai Meng

2014-06-17 17:40 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > On 06/17/14 07:59, Shuai Meng wrote: > > diff --git a/dlls/vbscript/global.c b/dlls/vbscript/global.c > > index 5357df8..c2b2edd 100644 > > --- a/dlls/vbscript/global.c > > +++ b/dlls/vbscript/global.c > > @@ -602,8 +602,52 @@ static HRESULT Global_Oct(vbdisp_t *This, VARIANT > *arg, unsigned args_cnt, VARIA > > > > static HRESULT Global_VarType(vbdisp_t *This, VARIANT *arg, unsigned > args_cnt, VARIANT *res) > > { > > - FIXME("\n"); > > - return E_NOTIMPL; > > + TRACE("(%s)\n", debugstr_variant(arg)); > > + > > + assert(args_cnt == 1); > > + > > + if(res) { > > + V_VT(res) = VT_I2; > > + switch(V_VT(arg)) { > > + case VT_EMPTY: > > + V_I2(res) = VT_EMPTY; > > + break; > > + case VT_NULL: > > + V_I2(res) = VT_NULL; > > + break; > > + case VT_I2: > > + V_I2(res) = VT_I2; > > + break; > (...) > > This all could be just: > > V_I2(res) = V_VT(arg); > > To handle unsupported types, you could use something like: > > if(V_VT(arg) & ~VT_TYPEMASK) { > FIXME("..."); > return E_NOTIMPL; > } > > I think over these codes again, ~VT_TYPEMASK is equal to 0, V_VT(arg) & ~VT_TYPEMASK will always be equal to 0, and then the codes belong to this if branch will never be executed, so why we write them? > if(res) { > V_VT(res) = VT_I2; > V_I2(res) = V_VT(arg); > } > > Jacek >

June 26, 2014

Re: [PATCH 4/4] vbscript: Implemented Abs(try 2)

by Shuai Meng

Hi, I notice that Abs(Null) should return Null according to http://msdn.microsoft.com/en-us/library/307330xe(v=vs.84).aspx In wine source code, NULL is defined as 0 in file dlls/windowscodecs/ungif.h, line 66. I have tried to write like this: 1260 if(V_VT(arg) == VT_NULL) { 1261 V_VT(res) = VT_NULL; 1262 V_NULL(res) = NULL; 1263 } 1264 else { 1265 hres = to_double(arg, &v); 1266 if (FAILED(hres)) 1267 return hres; 1268 1269 if(res) { 1270 V_VT(res) = VT_R8; 1271 V_R8(res) = v >= 0 ? v : -v; 1272 } 1273 } 1274 return S_OK; But apparently this makes no sense: V_NULL is defined in dlls/oleaut32/tests/vartest.c, not along with V_I2 in include/oleauto.h; I don't know how give res a "Null" value in C. 2014-06-17 17:44 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > On 06/17/14 08:00, Shuai Meng wrote: > > diff --git a/dlls/vbscript/global.c b/dlls/vbscript/global.c > > index d21784d..e646a29 100644 > > --- a/dlls/vbscript/global.c > > +++ b/dlls/vbscript/global.c > > @@ -1302,8 +1302,24 @@ static HRESULT Global_ChrW(vbdisp_t *This, > VARIANT *arg, unsigned args_cnt, VARI > > > > static HRESULT Global_Abs(vbdisp_t *This, VARIANT *arg, unsigned > args_cnt, VARIANT *res) > > { > > - FIXME("\n"); > > - return E_NOTIMPL; > > + VARIANT v; > > + HRESULT hres; > > + > > + TRACE("(%s)\n", debugstr_variant(arg)); > > + > > + assert(args_cnt == 1); > > + > > + V_VT(&v) = VT_EMPTY; > > + hres = VariantChangeType(&v, arg, VARIANT_LOCALBOOL, VT_R8); > > + if (FAILED(hres)) > > + return S_OK; > > Please use to_double here. Also note weird indention here. > > Jacek > > >

June 26, 2014

Re: wined3d: Use shader and fragment capabilities to select d3d level

by Henri Verbeet

On 25 June 2014 21:25, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > În ziua de Mie 25 Iun 2014, la 10:50:49, Henri Verbeet a scris: >> Please avoid C99 features like // comments. > So I suppose C11 features are out of the question? Do you have any suggestion > for an alternative to _Static_assert? > There's C_ASSERT in winnt.h.

June 25, 2014

Re: wined3d: Use shader and fragment capabilities to select d3d level

by Andrei Slăvoiu

În ziua de Mie 25 Iun 2014, la 10:50:49, Henri Verbeet a scris: > Please avoid C99 features like // comments. So I suppose C11 features are out of the question? Do you have any suggestion for an alternative to _Static_assert? > > + if (gl_info->limits.textures > 1) > > + return 6; > > That's "fragment_caps.MaxSimultaneousTextures". Right, that makes more sense. > It probably makes sense to reorganize things a bit. For example, the > gl_info parameter to the select_card() callbacks in struct > gl_vendor_selection is really only used by select_card_nvidia_binary() > and select_card_amd_binary() to call d3d_level_from_gl_info(), but I > don't think anything of value would be lost if those used a plain > table like e.g. select_card_amd_mesa(). (At which point you wouldn't > need a callback there anymore either.) d3d_level_from_gl_info() should > probably get the shader and fragment caps passed as parameters, and be > renamed. It probably makes sense to make it return some kind of enum > instead of a plain number, so you can e.g. distinguish between D3D9 > SM2 and D3D9 SM3. That would also allow the fallback card selection > code to use plain tables instead of callbacks. Ok, I think I understand what you mean, I'll give it a try.

June 25, 2014

Re: Tahoma fonts and Greek language

by Erich E. Hoover

On Wed, Jun 25, 2014 at 2:32 AM, Huw Davies <huw(a)codeweavers.com> wrote: > On Tue, Jun 24, 2014 at 11:07:26AM +0300, Petros F wrote: >> Hello, >> >> When you install wine in a PC with Greek language, or run a program that >> requires or uses Greek fonts, the fonts could not appear correctly because of >> the pre-installed tahoma font which it hasn't Greek letters for some reason. So >> the user has to change the font manually to another font or to paste a Greek >> tahoma font into /usr/share/fonts or /home/.fonts folder. >> I was wondering if it is possible to include these tahoma fonts (that have >> Greek letters) and the procedure of their installation in the wine >> installation? > > No, of course not. You'll have to draw the Greek glyphs yourself. Hi Petros, I think it's necessary to further clarify Huw's email. The copyright on the original Tahoma font prohibits Wine from distributing it, so we cannot include it in the project. The replacement font Wine uses for Tahoma is a modified version of "Bitstream Vera Sans," which, unfortunately, does not include Greek characters. However, a quick Google search reveals that there is a modified version of this font with Greek characters: http://dejavu-fonts.org/wiki/index.php?title=Bitstream_Vera_derivatives#Are… So, if you're willing to look into any possible license conflicts (and find that there are none) then you could potentially use FontForge to merge these glyphs into the font Wine uses and submit a patch to the font. If you require help with this process then feel free to ask. You can also open a bug in the bug tracker (http://bugs.winehq.org/) which might help others that encounter the same problem to find your workarounds. Best, Erich

June 25, 2014

Re: [PATCH] riched20: Don't create too many IRichEditOle interfaces for a RichEdit. (try 2)

by Jactry Zeng

Hi Huw, 2014-06-25 19:18 GMT+08:00 Huw Davies <huw(a)codeweavers.com>: > > > diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c > > index 2af2582..65e70fa 100644 > > --- a/dlls/riched20/editor.c > > +++ b/dlls/riched20/editor.c > > @@ -4468,6 +4468,13 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > > case EM_GETOLEINTERFACE: > > { > > LPVOID *ppvObj = (LPVOID*) lParam; > > + if (editor->reOle) > > + { > > + *ppvObj = editor->reOle; > > + IRichEditOle_AddRef(*ppvObj); > > + return 1; > > + } > > + > > return CreateIRichEditOle(editor, ppvObj); > > } > > case EM_GETPASSWORDCHAR: > > > Better to assign editor->reOle here too. > That will be one ref, then every returned iface should add > another ref. So the first iface returned will have > refcount of 2 and then your tests will pass. > > You release the final ref in the editor destructor. Is this the right way? : @@ -4468,7 +4468,20 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, case EM_GETOLEINTERFACE: { LPVOID *ppvObj = (LPVOID*) lParam; - return CreateIRichEditOle(editor, ppvObj); + if (editor->reOle) + { + *ppvObj = editor->reOle; + IRichEditOle_AddRef(*ppvObj); + return 1; + } + + if (CreateIRichEditOle(editor, ppvObj)) + { + editor->reOle = *ppvObj; + IRichEditOle_AddRef(*ppvObj); + return 1; + } + return 0; } ref will be one when created, and will increase every time returned iface. And in this way, IRichEditOle_fnRelease also should be modified: @@ -126,12 +126,13 @@ IRichEditOle_fnRelease(IRichEditOle *me) TRACE ("%p ref=%u\n", This, ref); - if (!ref) + if (ref == 1) { TRACE ("Destroying %p\n", This); This->txtSel->reOle = NULL; ITextSelection_Release(&This->txtSel->ITextSelection_iface); IOleClientSite_Release(&This->clientSite->IOleClientSite_iface); + This->editor->reOle = NULL; heap_free(This); } return ref; > > > diff --git a/dlls/riched20/editstr.h b/dlls/riched20/editstr.h > > index f139c29..3722c82 100644 > > --- a/dlls/riched20/editstr.h > > +++ b/dlls/riched20/editstr.h > > @@ -388,6 +388,7 @@ typedef struct tagME_TextEditor > > { > > HWND hWnd, hwndParent; > > ITextHost *texthost; > > + LPVOID reOle; > > Needs correct type. @@ -388,6 +388,7 @@ typedef struct tagME_TextEditor { HWND hWnd, hwndParent; ITextHost *texthost; + IRichEditOle *reOle; BOOL bEmulateVersion10; ME_TextBuffer *pBuffer; ME_Cursor *pCursors; Thanks again! -- Regards, Jactry Zeng

June 25, 2014

Failing tests on test bots

by Jeremy White

Alright, We have a new VM server. We have a new WineHQ server. Things should be stable, or getting better from now on. But we still have 32 failures: http://www.winehq.org/~jwhite/e29fd5429234.html This sucks. Let's fix it. Cheers, Jeremy

June 25, 2014

Re: [PATCH 2/4] vbscript: Implemented VarType(try 3)

by Shuai Meng

2014-06-25 21:44 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 06/25/14 15:34, Shuai Meng wrote: > >> 2014-06-25 17:32 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com >> <mailto:piotr.caban(a)gmail.com>>: >> >> >> On 06/25/14 04:19, Shuai Meng wrote: >> >> static HRESULT Global_VarType(vbdisp_t *This, VARIANT *arg, >> unsigned args_cnt, VARIANT *res) >> { >> - FIXME("\n"); >> - return E_NOTIMPL; >> + TRACE("(%s)\n", debugstr_variant(arg)); >> + >> + assert(args_cnt == 1); >> + >> + if(V_VT(arg) & ~VT_TYPEMASK) { >> + FIXME("not supported %s\n", debugstr_variant(arg)); >> + return E_NOTIMPL; >> + } >> + >> + if(!res) >> + return DISP_E_BADVARTYPE; >> >> This function should not return error if res is NULL. >> >> But it returned error when res was NULL in CInt and other conversion >> functions. Will you please explain this? >> > You need to implement it in the same way as on windows. A test for this > behavior may be following: > Call VarType(Empty) > because the function is not returning error the script is executed > successfully. > > In general functions are supposed to behave in the same way no matter if > return value is used or not. Unfortunately there are some functions that > behave differently. > > > OK, I finally understand the secret, keep the same with windows.

June 25, 2014

Re: [PATCH 2/4] vbscript: Implemented VarType(try 3)

by Piotr Caban

On 06/25/14 15:34, Shuai Meng wrote: > 2014-06-25 17:32 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com > <mailto:piotr.caban(a)gmail.com>>: > > On 06/25/14 04:19, Shuai Meng wrote: > > static HRESULT Global_VarType(vbdisp_t *This, VARIANT *arg, > unsigned args_cnt, VARIANT *res) > { > - FIXME("\n"); > - return E_NOTIMPL; > + TRACE("(%s)\n", debugstr_variant(arg)); > + > + assert(args_cnt == 1); > + > + if(V_VT(arg) & ~VT_TYPEMASK) { > + FIXME("not supported %s\n", debugstr_variant(arg)); > + return E_NOTIMPL; > + } > + > + if(!res) > + return DISP_E_BADVARTYPE; > > This function should not return error if res is NULL. > > But it returned error when res was NULL in CInt and other conversion > functions. Will you please explain this? You need to implement it in the same way as on windows. A test for this behavior may be following: Call VarType(Empty) because the function is not returning error the script is executed successfully. In general functions are supposed to behave in the same way no matter if return value is used or not. Unfortunately there are some functions that behave differently.

June 25, 2014

Re: [PATCH 2/4] vbscript: Implemented VarType(try 3)

by Shuai Meng

2014-06-25 17:32 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 06/25/14 04:19, Shuai Meng wrote: > >> static HRESULT Global_VarType(vbdisp_t *This, VARIANT *arg, unsigned >> args_cnt, VARIANT *res) >> { >> - FIXME("\n"); >> - return E_NOTIMPL; >> + TRACE("(%s)\n", debugstr_variant(arg)); >> + >> + assert(args_cnt == 1); >> + >> + if(V_VT(arg) & ~VT_TYPEMASK) { >> + FIXME("not supported %s\n", debugstr_variant(arg)); >> + return E_NOTIMPL; >> + } >> + >> + if(!res) >> + return DISP_E_BADVARTYPE; >> > This function should not return error if res is NULL. > But it returned error when res was NULL in CInt and other conversion functions. Will you please explain this?

June 25, 2014

RE: [Patch 1/2] winecfg: Set default button in Libraries tab [fixes bug 12804]

by Hugh McMaster

On Wednesday, 25 June 2014 6:01 AM, André Hentschel wrote: > Am 24.06.2014 10:35, schrieb Hugh McMaster: > > This patch sets the default button to IDC_DLLS_ADDDLL in the Libraries tab > > of winecfg when a user is typing in the combo box. > > > > This allows the user to hit the Enter key and add the override. Currently, > > hitting the Enter key closes winecfg, which is causing problems with many > > users. > That's just a workaround, if you modify winecfg to run on Windows you'll see > that the button works there as expected, the problem lies deeper in the > Wine code... What's the best way to modify winecfg? I've stripped almost everything from libraries.c and main.c, and I'm compiling these two files with i686-w64-mingw32-gcc . The dialog doesn't appear on Windows though. Do you mean the Add button works on Windows with the call SendMessageW(GetParent(dialog), DM_SETDEFID, IDC_DLLS_ADDDLL, 0);? Or does it work without the GetParent(dialog) call? > Of course we maybe want a workaround to satisfy our users... The bug was reported over six years ago and the problem is apparently confusing/frustrating a lot of people. It's not a perfect solution by any means... but it is up to Alexandre Julliard to decide what to do.

June 25, 2014

Re: [PATCH] riched20: Don't create too many IRichEditOle interfaces for a RichEdit. (try 2)

by Huw Davies

On Wed, Jun 25, 2014 at 06:56:00PM +0800, Jactry Zeng wrote: > diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c > index 2af2582..65e70fa 100644 > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -4468,6 +4468,13 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > case EM_GETOLEINTERFACE: > { > LPVOID *ppvObj = (LPVOID*) lParam; > + if (editor->reOle) > + { > + *ppvObj = editor->reOle; > + IRichEditOle_AddRef(*ppvObj); > + return 1; > + } > + > return CreateIRichEditOle(editor, ppvObj); > } > case EM_GETPASSWORDCHAR: Better to assign editor->reOle here too. That will be one ref, then every returned iface should add another ref. So the first iface returned will have refcount of 2 and then your tests will pass. You release the final ref in the editor destructor. > diff --git a/dlls/riched20/editstr.h b/dlls/riched20/editstr.h > index f139c29..3722c82 100644 > --- a/dlls/riched20/editstr.h > +++ b/dlls/riched20/editstr.h > @@ -388,6 +388,7 @@ typedef struct tagME_TextEditor > { > HWND hWnd, hwndParent; > ITextHost *texthost; > + LPVOID reOle; Needs correct type. Huw.

June 25, 2014

Re: [PATCH] riched20: Don't create too many IRichEditOle interfaces for a RichEdit.

by Jactry Zeng

2014-06-25 16:24 GMT+08:00 Huw Davies <huw(a)codeweavers.com>: > > > This is not the way to do this. You want to be calling AddRef > on the interface. You probably want to do the if(editor->reOle) > check in the EM_GETOLEINTERFACE handler and only call this > constructor when needed. Thanks Huw! A newer version will be sent. -- Regards, Jactry Zeng

June 25, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 3)

by Shuai Meng

2014-06-25 17:37 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 06/25/14 11:35, Piotr Caban wrote: > >> On 06/25/14 04:21, Shuai Meng wrote: >> >>> + hres = VariantChangeType(&dst, v, VARIANT_LOCALBOOL, VT_R8); >>> >> There's no need to pass VARIANT_LOCALBOOL flag here. >> >> static HRESULT Global_Sgn(vbdisp_t *This, VARIANT *arg, unsigned >>> args_cnt, VARIANT *res) >>> { >>> - FIXME("\n"); >>> - return E_NOTIMPL; >>> + double v; >>> + HRESULT hres; >>> + >>> + TRACE("(%s)\n", debugstr_variant(arg)); >>> + >>> + assert(args_cnt == 1); >>> + >>> + hres = to_double(arg, &v); >>> + if (FAILED(hres)) >>> + return S_OK; >>> >> I haven't seen it earlier, you should probably return hres here. > Yes, you are right, I made a mistake here. Thank you.

June 25, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 3)

by Piotr Caban

On 06/25/14 11:35, Piotr Caban wrote: > On 06/25/14 04:21, Shuai Meng wrote: >> + hres = VariantChangeType(&dst, v, VARIANT_LOCALBOOL, VT_R8); > There's no need to pass VARIANT_LOCALBOOL flag here. > >> static HRESULT Global_Sgn(vbdisp_t *This, VARIANT *arg, unsigned >> args_cnt, VARIANT *res) >> { >> - FIXME("\n"); >> - return E_NOTIMPL; >> + double v; >> + HRESULT hres; >> + >> + TRACE("(%s)\n", debugstr_variant(arg)); >> + >> + assert(args_cnt == 1); >> + >> + hres = to_double(arg, &v); >> + if (FAILED(hres)) >> + return S_OK; I haven't seen it earlier, you should probably return hres here.

June 25, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 3)

by Piotr Caban

On 06/25/14 04:21, Shuai Meng wrote: > + hres = VariantChangeType(&dst, v, VARIANT_LOCALBOOL, VT_R8); There's no need to pass VARIANT_LOCALBOOL flag here. > static HRESULT Global_Sgn(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > { > - FIXME("\n"); > - return E_NOTIMPL; > + double v; > + HRESULT hres; > + > + TRACE("(%s)\n", debugstr_variant(arg)); > + > + assert(args_cnt == 1); > + > + hres = to_double(arg, &v); > + if (FAILED(hres)) > + return S_OK; > + > + if(!res) > + return DISP_E_BADVARTYPE; This function should not return error if res is NULL. There's similar mistake in Abs implementation. Cheers, Piotr

June 25, 2014

Re: [PATCH 2/4] vbscript: Implemented VarType(try 3)

by Piotr Caban

On 06/25/14 04:19, Shuai Meng wrote: > static HRESULT Global_VarType(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > { > - FIXME("\n"); > - return E_NOTIMPL; > + TRACE("(%s)\n", debugstr_variant(arg)); > + > + assert(args_cnt == 1); > + > + if(V_VT(arg) & ~VT_TYPEMASK) { > + FIXME("not supported %s\n", debugstr_variant(arg)); > + return E_NOTIMPL; > + } > + > + if(!res) > + return DISP_E_BADVARTYPE; This function should not return error if res is NULL.

June 25, 2014

Re: wined3d: Use shader and fragment capabilities to select d3d level

by Henri Verbeet

On 23 June 2014 21:10, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > +static UINT d3d_level_from_gl_info(const struct wined3d_gl_info *gl_info) > +{ > + struct shader_caps shader_caps; > + struct fragment_caps fragment_caps; > + const struct wined3d_shader_backend_ops *shader_backend; > + const struct fragment_pipeline *fragment_pipeline; > + > + shader_backend = select_shader_backend(gl_info); > + shader_backend->shader_get_caps(gl_info, &shader_caps); > + > + if (shader_caps.vs_version >= 4) > + return 10; > + //wine can not use SM 4 on mesa drivers as the necessary functionality is not exposed on compatibility contexts, but still set the pci id accordingly Please avoid C99 features like // comments. > + if (shader_caps.vs_version == 3 && gl_info->glsl_version >= MAKEDWORD_VERSION(1, 30)) > + return 10; > + if (shader_caps.vs_version >= 2) > + return 9; > + if (shader_caps.vs_version == 1) > + return 8; > + > + fragment_pipeline = select_fragment_implementation(gl_info, shader_backend); > + fragment_pipeline->get_caps(gl_info, &fragment_caps); > + > + if (fragment_caps.TextureOpCaps & WINED3DTEXOPCAPS_DOTPRODUCT3) > + return 7; > + if (gl_info->limits.textures > 1) > + return 6; That's "fragment_caps.MaxSimultaneousTextures". It probably makes sense to reorganize things a bit. For example, the gl_info parameter to the select_card() callbacks in struct gl_vendor_selection is really only used by select_card_nvidia_binary() and select_card_amd_binary() to call d3d_level_from_gl_info(), but I don't think anything of value would be lost if those used a plain table like e.g. select_card_amd_mesa(). (At which point you wouldn't need a callback there anymore either.) d3d_level_from_gl_info() should probably get the shader and fragment caps passed as parameters, and be renamed. It probably makes sense to make it return some kind of enum instead of a plain number, so you can e.g. distinguish between D3D9 SM2 and D3D9 SM3. That would also allow the fallback card selection code to use plain tables instead of callbacks.

June 25, 2014

Re: Tahoma fonts and Greek language

by Huw Davies

On Tue, Jun 24, 2014 at 11:07:26AM +0300, Petros F wrote: > Hello, > > When you install wine in a PC with Greek language, or run a program that > requires or uses Greek fonts, the fonts could not appear correctly because of > the pre-installed tahoma font which it hasn't Greek letters for some reason. So > the user has to change the font manually to another font or to paste a Greek > tahoma font into /usr/share/fonts or /home/.fonts folder. > I was wondering if it is possible to include these tahoma fonts (that have > Greek letters) and the procedure of their installation in the wine > installation? No, of course not. You'll have to draw the Greek glyphs yourself. Huw.

June 25, 2014

Re: [PATCH] riched20: Don't create too many IRichEditOle interfaces for a RichEdit.

by Huw Davies

On Wed, Jun 25, 2014 at 01:59:42PM +0800, Jactry Zeng wrote: > @@ -1502,6 +1503,13 @@ LRESULT CreateIRichEditOle(ME_TextEditor *editor, LPVOID *ppObj) > { > IRichEditOleImpl *reo; > > + if (editor->reOle) > + { > + reo = editor->reOle; > + reo->ref++; > + *ppObj = reo; > + return 1; > + } > reo = heap_alloc(sizeof(IRichEditOleImpl)); > if (!reo) > return 0; This is not the way to do this. You want to be calling AddRef on the interface. You probably want to do the if(editor->reOle) check in the EM_GETOLEINTERFACE handler and only call this constructor when needed. Huw.

June 25, 2014

RE: [Patch 3/3] regsvr32: Convert char* to WCHAR*

by Hugh McMaster

On Wednesday, 25 June 2014 2:07 AM, Vincent Povirk wrote: > You should probably combine this with patch 1, so we don't have an > intermediate stage where the output is broken. Good point. I'll send a combined patch. Thank you.

June 25, 2014

Re: [PATCH 4/4] vbscript: Implemented Abs(try 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7680 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

June 25, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7679 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

June 25, 2014

Re: [PATCH 2/4] vbscript: Implemented VarType(try 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7678 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

June 25, 2014

Re: [PATCH 1/4] vbscript: Implemented TypeName(try 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7677 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

June 25, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 2)

by Shuai Meng

2014-06-25 0:50 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > On 06/24/14 15:59, Shuai Meng wrote: > > > > > 2014-06-19 8:30 GMT+08:00 Shuai Meng <mengshuaicalendr(a)gmail.com>: > >> >> >> >> 2014-06-17 17:43 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: >> >> On 06/17/14 07:59, Shuai Meng wrote: >>> > diff --git a/dlls/vbscript/global.c b/dlls/vbscript/global.c >>> > index c2b2edd..d21784d 100644 >>> > --- a/dlls/vbscript/global.c >>> > +++ b/dlls/vbscript/global.c >>> > @@ -1320,8 +1320,24 @@ static HRESULT Global_Int(vbdisp_t *This, >>> VARIANT *arg, unsigned args_cnt, VARIA >>> > >>> > static HRESULT Global_Sgn(vbdisp_t *This, VARIANT *arg, unsigned >>> args_cnt, VARIANT *res) >>> > { >>> > - FIXME("\n"); >>> > - return E_NOTIMPL; >>> > + VARIANT v; >>> > + HRESULT hres; >>> > + >>> > + TRACE("(%s)\n", debugstr_variant(arg)); >>> > + >>> > + assert(args_cnt == 1); >>> > + >>> > + V_VT(&v) = VT_EMPTY; >>> > + hres = VariantChangeType(&v, arg, VARIANT_LOCALBOOL, VT_R8); >>> > + if (FAILED(hres)) >>> > + return S_OK; >>> >>> Please use to_double() instead. to_double may need some fixes (it may >>> require similar changes as you did for to_string first). >>> >>> Yes, to_double is better and simpler. >> >>> Jacek >>> >>> >>> >> I have tried to_double, but I don't think it is as convenient as > VariantChangeType. > > > Not if you fix to_double first. Just call VariantChangeType inside > to_double, like you did in to_string: > Thank you, but when I use git blame, it turns out that it's you modify to_string, not me :) > > http://source.winehq.org/git/wine.git/commitdiff/6bef4da592c8be4857dc0fa179… > > > I have to add more types such as VT_CY and VT_EMPTY, and they don't > work. For example, if > 185 switch(V_VT(v)) { > 186 case VT_EMPTY: > 187 *ret = VT_EMPTY(v); > > but there is no VT_EMPTY(), how can I give ret whose type is double a > "EMPTY" value? > > > Well... of course there is no. As the name suggests, the type "empty" is > empty and has no values ;) What will be result of converting empty to > double is a matter of language semantic and vbscript happens to have the > same semantic as VT_EMPTY->VT_R8 conversion in VariantChangeType. > > > Why must we pick up to_double and give up VariantChangeType? > > > I'm not saying about giving up VariantChangeType, I just want to use it > right. > > Jacek >

June 25, 2014

Re: [5/5] user32: Skip menu loop for empty popup menus.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7669 Your paranoid android. === w7u (32 bit msg) === msg.c:12099: Test failed: unexpected hwnd 003D013E msg.c:12121: Test failed: bad time 30e71/30e80

June 24, 2014

Re: [3/5] user32: Set capture on the owner of popup menus.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7664 Your paranoid android. === w7u (32 bit msg) === msg.c:12098: Test failed: unexpected hwnd 0007013A

June 24, 2014

Re: [4/5] user32: Set capture earlier on popup menus.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7665 Your paranoid android. === build (build) === Failure running the build script in the VM: network read timed out (Connect:AgentVersion.h:0/9)

June 24, 2014

Re: ntdll/nt: Improve NtQuerySystemInformation, cpu_user/cpu_nice already include cpu_guest/cpu_guest_nice

by André Hentschel

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 24.06.2014 01:57, schrieb Bernard Ladenthin: Somehow too many comments... Also you just number your patches like e.g. [1/2] in the subject, see other patches -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQGcBAEBAgAGBQJTqdl5AAoJEGm5GZTakYssInAL/j59ymw++Chfn8hfF9TYsGU7 Gg8w1k451vXrezpRHsLrYB72UrLbnlD35TJx3FBV3nCEhuX/LVGj7EyTh6gA+aki p1RmHmqZSvxzuI7RF6a9LbfwjwwSQ392huraBUzmNFOMKMwQ1cZfCfFxA+Xvr/kL bwKcN/+EeSBYDUHIp3ug9ib0SL+d1IMeqQDSstviEKEHfAjbUsAICWBKMU5jmrDt ZEHLrugbfQ15qRITbBbqKvPTSrR1VRglOYwT44kwB4w+xZCJ8u+zgEQhMpg6dN6H JkgG4VjH7ObksiASY0wUAmL+c9KwNcmwyJ7SwG5o+nmgF/kNjzOZhgw80wtrXNCi 659GCVBLFENKSOPWh84nxhRFXKlH6uubqxcRI4WtTNQGfdsI7MqB1qGf9Y45TvyP aHfEd/hBVvNaNRj9Vzax3z3ze2nshEczhpuv8PkTcyLUr/zA+ju+w+FkwUJesjY9 zbGao2AjHszVl9LDvJoKXV6cc+lCTqlIe3BTYa79qw== =8YJ/ -----END PGP SIGNATURE-----

June 24, 2014

Re: [Patch 1/2] winecfg: Set default button in Libraries tab [fixes bug 12804]

by André Hentschel

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 24.06.2014 10:35, schrieb Hugh McMaster: > This patch sets the default button to IDC_DLLS_ADDDLL in the Libraries tab of winecfg when a user is typing in the combo box. > > This allows the user to hit the Enter key and add the override. Currently, hitting the Enter key closes winecfg, which is causing problems with many users. > > The patch fixes bug 12804 and was tested by Austin English. That's just a workaround, if you modify winecfg to run on Windows you'll see that the button works there as expected, the problem lies deeper in the Wine code... Of course we maybe want a workaround to satisfy our users... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQGcBAEBAgAGBQJTqdjyAAoJEGm5GZTakYsswH4L/198JPSwjgYiwSnLkYgBjZJ6 YD5XWVA3YfdexdV2urNIIN8fHv97xVR9INqnbEksS/HJpTY9QU9CIYTSw8IkxlS4 3423KKJe+St7cjKLwoAMFK6LJNQrtloxik2S8Y7y7QMLocPxmRPZOFK45032RTEM BH/vAwxtud4yux13rKsl9TX4Z6LwoqeKcGk9k0I2vYy0ez53rIS0bP9sytasNTLL 34Vmj65kVX5lQGYNhECgkd5W2LNDSUxXecpc+BQ1iaHNNnGkne0uZPERVoqIRHYv TZuhtzF/VI4nXO9bRnAkZhMycHH8aZI4vk5D/kvamzEApDx8dC78S+s0by+RFLfb 7UMaV24GM6DI3QS6aK7e/UjTSBKq4fqyOykrn0Pdjhb7fx5OPHevV84HoPil5Sx0 LRsrNZQY+tr+0jqHvAV0YPohspZb05qZDQbv/6jnt085m6SIQdPiJq4RqD6Vwl81 cpy1fYd1hTO1hY5zSrVl+6TbN9PgniTb6d5OfhI5+g== =Z18S -----END PGP SIGNATURE-----

June 24, 2014

Re: fix stack corruption and LastError results in shlwapi PathCombine

by Vincent Povirk

The length of the ANSI string doesn't necessarily match the length of the Unicode string after conversion. We should be checking the return value of MultiByteToWideChar to find out whether the converted string fit. Why aren't the 'strlenW(szTemp) + strlenW(lpszFile)' test and uses of lstrcpynW in PathCombineW sufficient to avoid stack corruption?

June 24, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 2)

by Jacek Caban

On 06/24/14 15:59, Shuai Meng wrote: > > > > 2014-06-19 8:30 GMT+08:00 Shuai Meng <mengshuaicalendr(a)gmail.com > <mailto:mengshuaicalendr(a)gmail.com>>: > > > > > 2014-06-17 17:43 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com > <mailto:jacek(a)codeweavers.com>>: > > On 06/17/14 07:59, Shuai Meng wrote: > > diff --git a/dlls/vbscript/global.c b/dlls/vbscript/global.c > > index c2b2edd..d21784d 100644 > > --- a/dlls/vbscript/global.c > > +++ b/dlls/vbscript/global.c > > @@ -1320,8 +1320,24 @@ static HRESULT Global_Int(vbdisp_t > *This, VARIANT *arg, unsigned args_cnt, VARIA > > > > static HRESULT Global_Sgn(vbdisp_t *This, VARIANT *arg, > unsigned args_cnt, VARIANT *res) > > { > > - FIXME("\n"); > > - return E_NOTIMPL; > > + VARIANT v; > > + HRESULT hres; > > + > > + TRACE("(%s)\n", debugstr_variant(arg)); > > + > > + assert(args_cnt == 1); > > + > > + V_VT(&v) = VT_EMPTY; > > + hres = VariantChangeType(&v, arg, VARIANT_LOCALBOOL, > VT_R8); > > + if (FAILED(hres)) > > + return S_OK; > > Please use to_double() instead. to_double may need some fixes > (it may > require similar changes as you did for to_string first). > > Yes, to_double is better and simpler. > > Jacek > > > > I have tried to_double, but I don't think it is as convenient as > VariantChangeType. Not if you fix to_double first. Just call VariantChangeType inside to_double, like you did in to_string: http://source.winehq.org/git/wine.git/commitdiff/6bef4da592c8be4857dc0fa179… > I have to add more types such as VT_CY and VT_EMPTY, and they don't > work. For example, if > 185 switch(V_VT(v)) { > 186 case VT_EMPTY: > 187 *ret = VT_EMPTY(v); > > but there is no VT_EMPTY(), how can I give ret whose type is double a > "EMPTY" value? Well... of course there is no. As the name suggests, the type "empty" is empty and has no values ;) What will be result of converting empty to double is a matter of language semantic and vbscript happens to have the same semantic as VT_EMPTY->VT_R8 conversion in VariantChangeType. > Why must we pick up to_double and give up VariantChangeType? I'm not saying about giving up VariantChangeType, I just want to use it right. Jacek

June 24, 2014

Re: [Patch 3/3] regsvr32: Convert char* to WCHAR*

by Vincent Povirk

You should probably combine this with patch 1, so we don't have an intermediate stage where the output is broken. On Tue, Jun 24, 2014 at 7:07 AM, Hugh McMaster <hugh.mcmaster(a)masterindexing.com> wrote: > This patch converts the char* strings of DllRegisterServer, DllUnregisterServer and DllInstall to WCHAR* strings for direct Unicode output. This avoids the need to modify any resource strings. > > >

June 24, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 2)

by Shuai Meng

2014-06-19 8:30 GMT+08:00 Shuai Meng <mengshuaicalendr(a)gmail.com>: > > > > 2014-06-17 17:43 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > > On 06/17/14 07:59, Shuai Meng wrote: >> > diff --git a/dlls/vbscript/global.c b/dlls/vbscript/global.c >> > index c2b2edd..d21784d 100644 >> > --- a/dlls/vbscript/global.c >> > +++ b/dlls/vbscript/global.c >> > @@ -1320,8 +1320,24 @@ static HRESULT Global_Int(vbdisp_t *This, >> VARIANT *arg, unsigned args_cnt, VARIA >> > >> > static HRESULT Global_Sgn(vbdisp_t *This, VARIANT *arg, unsigned >> args_cnt, VARIANT *res) >> > { >> > - FIXME("\n"); >> > - return E_NOTIMPL; >> > + VARIANT v; >> > + HRESULT hres; >> > + >> > + TRACE("(%s)\n", debugstr_variant(arg)); >> > + >> > + assert(args_cnt == 1); >> > + >> > + V_VT(&v) = VT_EMPTY; >> > + hres = VariantChangeType(&v, arg, VARIANT_LOCALBOOL, VT_R8); >> > + if (FAILED(hres)) >> > + return S_OK; >> >> Please use to_double() instead. to_double may need some fixes (it may >> require similar changes as you did for to_string first). >> >> Yes, to_double is better and simpler. > >> Jacek >> >> >> > I have tried to_double, but I don't think it is as convenient as VariantChangeType. I have to add more types such as VT_CY and VT_EMPTY, and they don't work. For example, if 185 switch(V_VT(v)) { 186 case VT_EMPTY: 187 *ret = VT_EMPTY(v); but there is no VT_EMPTY(), how can I give ret whose type is double a "EMPTY" value? Why must we pick up to_double and give up VariantChangeType?

June 24, 2014

Re: wininet/tests: Add more HTTP_QUERY_RAW_HEADERS tests

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > Related to http://bugs.winehq.org/show_bug.cgi?id=36641 It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M wininet.dll -p wininet_test.exe.so http && touch http.ok http.c:647: Test succeeded inside todo block: HttpQueryInfoA(HTTP_QUERY_RAW_HEADERS) failed with error 122 http.c:649: Test succeeded inside todo block: Expected 0x00, got 00 http.c:652: Test succeeded inside todo block: Value should not have changed: 465 != 465 http.c:647: Test succeeded inside todo block: HttpQueryInfoA(HTTP_QUERY_RAW_HEADERS) failed with error 122 http.c:649: Test succeeded inside todo block: Expected 0x00, got 00 http.c:652: Test succeeded inside todo block: Value should not have changed: 403 != 403 wine: Unhandled page fault on write access to 0x00630065 at address 0x7bc4ef6f (thread 0088), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

June 24, 2014

Re: opengl32: glGetString() requires an active GL context (try 2)

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > try2: > > Add tests. That test will work fine on Wine without code changes, so it's not very convincing. -- Alexandre Julliard julliard(a)winehq.org

June 24, 2014

Re: gdi32: Avoid compiler warnings in freetype_SelectFont. Simplify logic a bit.

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > This is similar to the warning removal patch I submitted yesterday. > > On top of that it replaces > ! something == ! a_0_1_boolean > by > !! something == a_0_1_boolean > since !! reflects the intention (to convert whatever value to one of > 0 or 1) better than the former and may be more efficient, too. That's not an improvement. -- Alexandre Julliard julliard(a)winehq.org

June 24, 2014

Tahoma fonts and Greek language

by Petros F

Hello, When you install wine in a PC with Greek language, or run a program that requires or uses Greek fonts, the fonts could not appear correctly because of the pre-installed tahoma font which it hasn't Greek letters for some reason. So the user has to change the font manually to another font or to paste a Greek tahoma font into /usr/share/fonts or /home/.fonts folder. I was wondering if it is possible to include these tahoma fonts (that have Greek letters) and the procedure of their installation in the wine installation? Petros

June 24, 2014

Re: opengl32: glBindTexture() and glDeleteTextures() require an active GL context

by Bruno Jesus

On Sat, Jun 21, 2014 at 6:47 PM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > Hi Bruno, > > Regarding the make_opengl script it generates the code from templates from > the opengl site. The templates contain all the function definitions. The > script has some function which in the end generates code for each function. > Look for something common e.g. trace lines to find your way around the > script. Please take a look at the attached patch, Sebastian Lackner helped me with the perl code and the patch generates the same changes I manually created in my previous attempt. It's done in a way it will not mess with all functions, only the ones required. > Thanks, > Roderick Best wishes, Bruno

June 24, 2014

Re: user32/tests: Add a missing call to ReleaseActCtx().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7654 Your paranoid android. === w7u (32 bit msg) === msg.c:12099: Test failed: unexpected hwnd 0012013E msg.c:12121: Test failed: bad time 30e90/30ea0

June 24, 2014

Re: WineHQ Downtime (try 2)

by Jeremy Newman

Server is back online. Feel free to let me know if you notice anything broken or a change in behavior from the old server. -N On 06/23/2014 08:53 AM, Jeremy Newman wrote: > Just a reminder that the server will be going offline in about an hour. > > -N > > On 06/20/2014 11:51 AM, Jeremy Newman wrote: >> WineHQ will be going offline starting at 10:00 CDT Monday 2014-06-23 and >> will be down for up to an hour. We are moving the site and all services >> (other than the Wiki) to new hardware. >> >> This includes: WineHQ.org, Forums, AppDB, Bugzilla, Git, FTP, Mailing >> lists, and WineTestBot Web >> >> Even after the things come back online, some services may need some >> tweaking. We will be on the issues as fast as we can. >> >> -N >> >> > >

June 23, 2014

Re: WineHQ Downtime (try 2)

by Jeremy Newman

Just a reminder that the server will be going offline in about an hour. -N On 06/20/2014 11:51 AM, Jeremy Newman wrote: > WineHQ will be going offline starting at 10:00 CDT Monday 2014-06-23 and > will be down for up to an hour. We are moving the site and all services > (other than the Wiki) to new hardware. > > This includes: WineHQ.org, Forums, AppDB, Bugzilla, Git, FTP, Mailing > lists, and WineTestBot Web > > Even after the things come back online, some services may need some > tweaking. We will be on the issues as fast as we can. > > -N > >

June 23, 2014

Re: [3/3] ntdll/tests: Add tests for DBG_RIPEXCEPTION debugger events.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7645 Your paranoid android. === w2000pro (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 00950000/00950001 exception: unhandled exception 80000004 at 00950000 exception.c:484: Test failed: 42: Wrong exception address 7C5C20B0/00950001 === wxppro (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 00A30000/00A30001 exception: unhandled exception 80000004 at 00A30000 exception.c:484: Test failed: 42: Wrong exception address 7C80DF3C/00A30001 === wvistau64 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:484: Test failed: 42: Wrong exception address 7751ED97/003C0001 === w2008s64 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 002C0000/002C0001 exception: unhandled exception 80000004 at 002C0000 exception.c:484: Test failed: 42: Wrong exception address 77E5ED97/002C0001 === w7u (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:484: Test failed: 42: Wrong exception address 77CDE34F/003C0001 === w8 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 003F0000/003F0001 exception: unhandled exception 80000004 at 003F0000 exception.c:484: Test failed: 42: Wrong exception address 77174D17/003F0001

June 23, 2014

Re: msvcp90/msvcp90.h: right-hand operand of comma expression has no effect (PING)

by Gerald Pfeifer

On Thu, 12 Jun 2014, Alexandre Julliard wrote: >>>> ../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); >>>> ^ >>> memcpy_s() returns an errno_t so the author tried to force returning >>> zero (no error). >> >> Since, clearly, the result is never intended to be used, we can as >> well simply cast the result away instead of using ", 0". > memcpy_s is supposed to return a value, and callers could (and probably > should) check it. Okay, so how about this patch which removes the ", 0" as part of the #define? That does not establish what you are suggesting, but at least removes this unconditional silencing (and dozens of warnings for GCC). Gerald diff --git a/dlls/msvcp90/msvcp90.h b/dlls/msvcp90/msvcp90.h index 0d5e124..5d85639 100644 --- a/dlls/msvcp90/msvcp90.h +++ b/dlls/msvcp90/msvcp90.h @@ -526,7 +526,7 @@ typedef struct { } complex_double; #if _MSVCP_VER < 80 -#define memcpy_s( dst, size, src, count ) (memcpy( (dst), (src), (count) ), 0) +#define memcpy_s( dst, size, src, count ) (memcpy( (dst), (src), (count) )) #define memmove_s( dst, size, src, count ) (memmove( (dst), (src), (count) ), 0) #define mbstowcs_s( ret, wcs, size, mbs, count ) (mbstowcs( (wcs), (mbs), (count) ), 0) #define hypotf( x, y ) ((float)hypot( (double)(x), (double)(y) ))

June 22, 2014

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory. (try 3)

by Zhenbo Li

On 06/21/2014 10:56 PM, Marvin wrote: > 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=7630 > > 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 As the test result for master branch[1], I think these two errors are not caused by my patch. [1]: http://testbot.winehq.org/JobDetails.pl?Key=7640

June 22, 2014

Re: opengl32: glBindTexture() and glDeleteTextures() require an active GL context

by Roderick Colenbrander

Hi Bruno, Regarding the make_opengl script it generates the code from templates from the opengl site. The templates contain all the function definitions. The script has some function which in the end generates code for each function. Look for something common e.g. trace lines to find your way around the script. Thanks, Roderick On Sat, Jun 21, 2014 at 1:39 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > On Sat, Jun 21, 2014 at 5:33 PM, Roderick Colenbrander > <thunderbird2k(a)gmail.com> wrote: > > Hi Bruno, > > > > My initial feeling is that the app is just buggy, since calling functions > > without a context is very questionable. Assuming we want to any checking > on > > NULL-contexts, please edit the make_opengl script since opengl_norm.c is > all > > auto-generated. Since this code is tricky, I would recommend writing a > test > > case for our test suite. Years ago (pre-wine 1.0) we had code to keep > some > > implicit GL context around, because allegedly some game required it (I > think > > it was Homeland). Though when I tried to reproduce that behavior I didn't > > see it in the game. I think I wrote some tests for Windows, but don't > > remember the results. > > Hi, thanks for the reply. I agree the app is buggy but as it works in > Windows I thought the patch was useful, I tried checking the > make_opengl but didn't understand it, there is no glBindTexture there > for example. I'll leave the bug to someone else with real experience > in the area. > > > Thanks, > > Roderick > > Best regards, > Bruno >

June 21, 2014

Re: opengl32: glBindTexture() and glDeleteTextures() require an active GL context

by Bruno Jesus

On Sat, Jun 21, 2014 at 5:33 PM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > Hi Bruno, > > My initial feeling is that the app is just buggy, since calling functions > without a context is very questionable. Assuming we want to any checking on > NULL-contexts, please edit the make_opengl script since opengl_norm.c is all > auto-generated. Since this code is tricky, I would recommend writing a test > case for our test suite. Years ago (pre-wine 1.0) we had code to keep some > implicit GL context around, because allegedly some game required it (I think > it was Homeland). Though when I tried to reproduce that behavior I didn't > see it in the game. I think I wrote some tests for Windows, but don't > remember the results. Hi, thanks for the reply. I agree the app is buggy but as it works in Windows I thought the patch was useful, I tried checking the make_opengl but didn't understand it, there is no glBindTexture there for example. I'll leave the bug to someone else with real experience in the area. > Thanks, > Roderick Best regards, Bruno

June 21, 2014

Re: opengl32: glBindTexture() and glDeleteTextures() require an active GL context

by Roderick Colenbrander

Hi Bruno, My initial feeling is that the app is just buggy, since calling functions without a context is very questionable. Assuming we want to any checking on NULL-contexts, please edit the make_opengl script since opengl_norm.c is all auto-generated. Since this code is tricky, I would recommend writing a test case for our test suite. Years ago (pre-wine 1.0) we had code to keep some implicit GL context around, because allegedly some game required it (I think it was Homeland). Though when I tried to reproduce that behavior I didn't see it in the game. I think I wrote some tests for Windows, but don't remember the results. Thanks, Roderick On Sat, Jun 21, 2014 at 11:36 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Very similar to bug 36506 but for other functions. > > Fixes bug http://bugs.winehq.org/show_bug.cgi?id=34847 > > > >

June 21, 2014

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory. (try 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7630 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

June 21, 2014

Re: WineHQ Downtime (try 2)

by André Hentschel

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 20.06.2014 23:00, schrieb Jeremy Newman: > Short answer: The focus of this downtime is new hardware. > > Longer answer: The the majority of our websites use PHP. SPDY requires moving away from mod_php to cgi, as mod_php is not compatible with mod_spdy. This could cause all sorts of problems as we have things tailored for mod_php, things like .htaccess directives, path info via mod_rewrite. All of it is solvable, but solving takes time. Didn't know about that, was just an idea from my outside view. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQGcBAEBAgAGBQJTpKXVAAoJEGm5GZTakYssI+kL/19puGr+CrfIR06V8IQSbd7R xuNA2r8ThhV75l0tgqqt1w2Hj6U9Jb0WaDZP2d5UPhqgYcaHpzLH0FToN+nrvjI0 BhwOH8LtRiknpLtJaC0LZG+awo++fGG6KwTT+BJ9fwwpgPufn12Dgh6qOZBtn2Xm P8r+ZeRQ+Az9M1fTM6IILM3bxB+TgV8GSg9TT3P6MWyecHvv2l8NoWYOofYxUEED hk9mC2zQrCOKVmYEfpouGNK6g/HDuhmcIRjf5bqJkMH0eNb5mTpOKEUNIuQXdvQU bzzjmr7acbeByuovICHbP3IoLYYuaWh2s7uCl7l1ttlpv1upKwMsE1iywePrbJsi os1S3sjnU39SgkkUwmJd5M/cUx/Eh56ptG0JzLPV31QpKqBoMeQ0jZ1dmaitBYEa L+NN57MULQamudG30Zd+tW/3pyOLLUXKOri/IemAeM/pHCQ1qs8lR0QExE8bbSV2 vL93GyPj5gUPOm2b017hnTgmvnzKabINwcuzulaBjw== =bnfu -----END PGP SIGNATURE-----

June 20, 2014

Re: WineHQ Downtime (try 2)

by Jeremy Newman

Short answer: The focus of this downtime is new hardware. Longer answer: The the majority of our websites use PHP. SPDY requires moving away from mod_php to cgi, as mod_php is not compatible with mod_spdy. This could cause all sorts of problems as we have things tailored for mod_php, things like .htaccess directives, path info via mod_rewrite. All of it is solvable, but solving takes time. If I was going to go through all that effort, I might as well go ahead and look into replacing Apache altogether with Nginx. I do plan on doing more research and testing on my development server after this round of hardware upgrades is complete. -N On 06/20/2014 12:11 PM, André Hentschel wrote: > What about taking the chance to integrate SPDY support? > http://spdycheck.org/#winehq.org > http://googledevelopers.blogspot.de/2014/06/modspdy-is-now-apache-project.h…

June 20, 2014

Re: windowscodecs: Fix interlaced PNG writing.

by Sebastian Lackner

Am 20.06.2014 22:15, schrieb Vincent Povirk: > + row_pointers = HeapAlloc(GetProcessHeap(), 0, This->height * sizeof(png_byte*)); > + if (!row_pointers) > + { > + LeaveCriticalSection(&This->lock); > + return E_OUTOFMEMORY; > + } There should be a corresponding HeapFree( ... ) to release row_pointers again.

June 20, 2014

Re: WineHQ Downtime (try 2)

by André Hentschel

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 20.06.2014 18:51, schrieb Jeremy Newman: > WineHQ will be going offline starting at 10:00 CDT Monday 2014-06-23 and will be down for up to an hour. We are moving the site and all services (other than the Wiki) to new hardware. > > This includes: WineHQ.org, Forums, AppDB, Bugzilla, Git, FTP, Mailing lists, and WineTestBot Web > > Even after the things come back online, some services may need some tweaking. We will be on the issues as fast as we can. > What about taking the chance to integrate SPDY support? http://spdycheck.org/#winehq.org http://googledevelopers.blogspot.de/2014/06/modspdy-is-now-apache-project.h… -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQGcBAEBAgAGBQJTpGtcAAoJEGm5GZTakYssDE0MAKK2c+/cHlmaWYD79p/oKLfJ WOyxZl8DO7D9nivqd4osUAHprYejMzL1858hfiMEhz5ne8SWjDEP4pknJ0e0ukHn i70HFV3VbLTSNiUgaMgOVaOXOkHpsBYW8AwffUicXrOG/wxFaQRfGajBepBqrgN/ 91KYbyAf1FJnrGzaiWlcnCVk73ypexgmIm7iDJzjQuhNOTqfB4nQuDFEVDLZ0vuB OHzWjcAV689A8A8Cie0gW/4JpP9fM4yDKy3RNz+Gjj+sFzCJy2lYoilg6C5M/EIM ZnaXUlx+dSTdYL9RwsbEGwlWHzq8w/36ZK/5sU5tb9LCykigaAHrj9fexrwYBnbm 8DTmcTWef1YLyxYjbvT1j6joCeeSYQPWZUtoZNhBOk/jCWYp7wf1rIMM/G7vOsyH X6oOI+P6wBUr3rqA4ND5KKQFjXQ8p6cfjLjlY04DgR6kLFxDa9HeTCSaAWE7muxz pQ+ipWTla7VKP55aV42JRYqnc1GU6PIVHQE/otvAZQ== =kz8x -----END PGP SIGNATURE-----

June 20, 2014

WineHQ Downtime (try 2)

by Jeremy Newman

WineHQ will be going offline starting at 10:00 CDT Monday 2014-06-23 and will be down for up to an hour. We are moving the site and all services (other than the Wiki) to new hardware. This includes: WineHQ.org, Forums, AppDB, Bugzilla, Git, FTP, Mailing lists, and WineTestBot Web Even after the things come back online, some services may need some tweaking. We will be on the issues as fast as we can. -N

June 20, 2014

Re: [3/4] server: Process OutputDebugString events like regular exceptions.

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > As recently mentioned in one of my other patches, Windows internally > processes debug string events the same way as regular exceptions. This > patch removes the output_debug_string wineserver call, and instead uses > always an exception to send debug strings to the debugger. The > wineserver function queue_exception_event is then responsible to > translate exceptions into the corresponding debug events. Make sure to > run ./tools/make_requests after applying this patch. This could probably be done on the client side when retrieving the event, to avoid adding special cases in the server code. -- Alexandre Julliard julliard(a)winehq.org

June 20, 2014

Re: [4/4] ntdll/tests: Add more tests for debug string events.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7619 Your paranoid android. === w2000pro (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 00950000/00950001 exception: unhandled exception 80000004 at 00950000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 7C5C20B0/00950001 === wxppro (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 00A30000/00A30001 exception: unhandled exception 80000004 at 00A30000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 7C80DF3C/00A30001 === wvistau64 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 7751ED97/003C0001 === w2008s64 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 002D0000/002D0001 exception: unhandled exception 80000004 at 002D0000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 77E5ED97/002D0001 === w7u (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 77CDE34F/003C0001 === w8 (32 bit exception) === exception.c:1127: Test failed: Got exception offset 0x1b, expected 0x19 exception.c:1136: Test failed: Got exception offset 0x19, expected 0x17 exception.c:484: Test failed: 42: Wrong exception address 003E0000/003E0001 exception: unhandled exception 80000004 at 003E0000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 77174D17/003E0001

June 20, 2014

Re: [2/4] ntdll/tests: Run crashing i386 exception tests as the last step.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7618 Your paranoid android. === w2000pro (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 00950000/00950001 exception: unhandled exception 80000004 at 00950000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 7C5C20B0/00950001 === wxppro (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 00A30000/00A30001 exception: unhandled exception 80000004 at 00A30000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 7C80DF3C/00A30001 === wvistau64 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 002C0000/002C0001 exception: unhandled exception 80000004 at 002C0000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 7751ED97/002C0001 === w2008s64 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 003D0000/003D0001 exception: unhandled exception 80000004 at 003D0000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 77E5ED97/003D0001 === w7u (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 00280000/00280001 exception: unhandled exception 80000004 at 00280000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 77CDE34F/00280001 === w8 (32 bit exception) === exception.c:1102: Test failed: Got exception offset 0x1b, expected 0x19 exception.c:1111: Test failed: Got exception offset 0x19, expected 0x17 exception.c:484: Test failed: 42: Wrong exception address 004F0000/004F0001 exception: unhandled exception 80000004 at 004F0000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 77174D17/004F0001

June 20, 2014

Re: [1/4] ntdll/tests: Use an EXCEPTION_REGISTRATION_RECORD array to prevent compiler from reordering variables.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7617 Your paranoid android. === w2000pro (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 00950000/00950001 exception: unhandled exception 80000004 at 00950000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 7C5C20B0/00950001 === wxppro (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 00A30000/00A30001 exception: unhandled exception 80000004 at 00A30000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 7C80DF3C/00A30001 === wvistau64 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 002C0000/002C0001 exception: unhandled exception 80000004 at 002C0000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 7751ED97/002C0001 === w2008s64 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 002C0000/002C0001 exception: unhandled exception 80000004 at 002C0000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 77E5ED97/002C0001 === w7u (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 002F0000/002F0001 exception: unhandled exception 80000004 at 002F0000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 77CDE34F/002F0001 === w8 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 003F0000/003F0001 exception: unhandled exception 80000004 at 003F0000 exception.c:481: Test failed: 42: Wrong exception code c0000027/80000004 exception.c:484: Test failed: 42: Wrong exception address 77174D17/003F0001

June 20, 2014

Re: Revert "windowscodecs: Fix leak in test_QueryCapability."

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7603 Your paranoid android. === build (build) === Patch failed to apply

June 19, 2014

Re: ntdll: Add exception tests for RtlUnwind on i386.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7598 Your paranoid android. === w2000pro (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 00950000/00950001 exception: unhandled exception 80000004 at 00950000 exception.c:484: Test failed: 42: Wrong exception address 7C5C20B0/00950001 === wxppro (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 00A30000/00A30001 exception: unhandled exception 80000004 at 00A30000 exception.c:484: Test failed: 42: Wrong exception address 7C80DF3C/00A30001 === wvistau64 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 002D0000/002D0001 exception: unhandled exception 80000004 at 002D0000 exception.c:484: Test failed: 42: Wrong exception address 7751ED97/002D0001 === w2008s64 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 002D0000/002D0001 exception: unhandled exception 80000004 at 002D0000 exception.c:484: Test failed: 42: Wrong exception address 77E5ED97/002D0001 === w7u (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:484: Test failed: 42: Wrong exception address 77CDE34F/003C0001 === w8 (32 bit exception) === exception.c:484: Test failed: 42: Wrong exception address 00310000/00310001 exception: unhandled exception 80000004 at 00310000 exception.c:484: Test failed: 42: Wrong exception address 77174D17/00310001

June 19, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 2)

by Shuai Meng

2014-06-17 17:43 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > On 06/17/14 07:59, Shuai Meng wrote: > > diff --git a/dlls/vbscript/global.c b/dlls/vbscript/global.c > > index c2b2edd..d21784d 100644 > > --- a/dlls/vbscript/global.c > > +++ b/dlls/vbscript/global.c > > @@ -1320,8 +1320,24 @@ static HRESULT Global_Int(vbdisp_t *This, VARIANT > *arg, unsigned args_cnt, VARIA > > > > static HRESULT Global_Sgn(vbdisp_t *This, VARIANT *arg, unsigned > args_cnt, VARIANT *res) > > { > > - FIXME("\n"); > > - return E_NOTIMPL; > > + VARIANT v; > > + HRESULT hres; > > + > > + TRACE("(%s)\n", debugstr_variant(arg)); > > + > > + assert(args_cnt == 1); > > + > > + V_VT(&v) = VT_EMPTY; > > + hres = VariantChangeType(&v, arg, VARIANT_LOCALBOOL, VT_R8); > > + if (FAILED(hres)) > > + return S_OK; > > Please use to_double() instead. to_double may need some fixes (it may > require similar changes as you did for to_string first). > > Yes, to_double is better and simpler. > Jacek > > >

June 19, 2014

Re: windowscodecs: Fix leak in test_QueryCapability.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7580 Your paranoid android. === wvistau64 (32 bit tiffformat) === tiffformat.c:245: Test failed: CreateDecoderFromStream error 0x88982f8b tiffformat: unhandled exception c0000005 at 0EEE3AA7 === w2008s64 (32 bit tiffformat) === tiffformat.c:245: Test failed: CreateDecoderFromStream error 0x88982f8b tiffformat: unhandled exception c0000005 at 0EEE3AA7 === w7u (32 bit tiffformat) === tiffformat.c:245: Test failed: CreateDecoderFromStream error 0x88982f8b tiffformat: unhandled exception c0000005 at 0EEE3AA7 === w8 (32 bit tiffformat) === tiffformat: unhandled exception c0000005 at 0042395C === wvistau64 (64 bit tiffformat) === No test summary line found === w2008s64 (64 bit tiffformat) === No test summary line found

June 18, 2014

Re: [PATCH 1/4] packager: Implement IOleObject::SetClientSite

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7573 Your paranoid android. === build (build) === Patch failed to apply

June 18, 2014

Re: WineHQ Downtime

by Jeremy Newman

The move is postponed. Nothing will be happening today. -N On 06/17/2014 01:38 PM, Jeremy Newman wrote: > WineHQ will be going offline starting at 10:00 CDT tomorrow (Wednesday > 2014-06-18) and will be down for up to an hour. We are moving the site > and all services (other than the Wiki) to new hardware. > > This includes: WineHQ.org, Forums, AppDB, Bugzilla, Git, FTP, Mailing > lists, and WineTestBot Web > > Even after the things come back online, some services may need some > tweaking. We will be on the issues as fast as we can.

June 18, 2014

Re: oleaut32: Fix TLB dependencies lookup (retry 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7567 Your paranoid android. === w2000pro (32 bit typelib) === typelib.c:5491: Test failed: got: 80029c4a

June 18, 2014

Re: WineHQ Downtime

by Francois Gouget

On Wed, 18 Jun 2014, Piotr Caban wrote: [...] > It's not possible to submit tasks to testbot. The server responds with "500 > Internal Server Error". I guess the migration was not done yet, but letting > you know just in case it's related. This issue was actually unrelated to the server reshuffling. The trouble is that whenever the website's Perl code is modified it's necessary to restart the Apache server. The reason is that while mod_perl automatically reloads the perl scripts that generate the pages, it fails to detect that the Perl modules they use have changed. This results in inconsistencies and thus Perl errors. I'm looking into Apache:Reload as a way to avoid this issue, the drawback being that they say it costs a little bit in performance (but I guess there's not that much traffic on WineTestBot so it may be ok). -- Francois Gouget <fgouget(a)codeweavers.com>

June 18, 2014

Re: WineHQ Downtime

by Michael Stefaniuc

On 06/18/2014 10:05 AM, Piotr Caban wrote: > On 06/17/14 20:38, Jeremy Newman wrote: >> WineHQ will be going offline starting at 10:00 CDT tomorrow (Wednesday >> 2014-06-18) and will be down for up to an hour. We are moving the site >> and all services (other than the Wiki) to new hardware. >> >> This includes: WineHQ.org, Forums, AppDB, Bugzilla, Git, FTP, Mailing >> lists, and WineTestBot Web >> >> Even after the things come back online, some services may need some >> tweaking. We will be on the issues as fast as we can. > > It's not possible to submit tasks to testbot. The server responds with > "500 Internal Server Error". I guess the migration was not done yet, but > letting you know just in case it's related. Piotr, 10:00 CDT is only in about 6 hours from now. bye michael

June 18, 2014

Re: WineHQ Downtime

by Piotr Caban

On 06/17/14 20:38, Jeremy Newman wrote: > WineHQ will be going offline starting at 10:00 CDT tomorrow (Wednesday > 2014-06-18) and will be down for up to an hour. We are moving the site > and all services (other than the Wiki) to new hardware. > > This includes: WineHQ.org, Forums, AppDB, Bugzilla, Git, FTP, Mailing > lists, and WineTestBot Web > > Even after the things come back online, some services may need some > tweaking. We will be on the issues as fast as we can. It's not possible to submit tasks to testbot. The server responds with "500 Internal Server Error". I guess the migration was not done yet, but letting you know just in case it's related.

June 18, 2014

Re: [2/3] msvcrt: Clear _cnt on buffer flush.

by Piotr Caban

On 06/18/14 02:03, Grazvydas Ignotas wrote: > @@ -3662,6 +3662,7 @@ int CDECL MSVCRT__flsbuf(int c, MSVCRT_FILE* file) > if(file->_cnt <= 0) > res = msvcrt_flush_buffer(file); > if(!res) { > + file->_cnt=file->_bufsiz; > *file->_ptr++ = c; > file->_cnt--; > } file->_cnt value should only be set if msvcrt_flush_buffer was called. Cheers, Piotr

June 18, 2014

Re: [4/5] msvcrt: Move write flag setting code for reuse.

by Grazvydas Ignotas

On Tue, Jun 17, 2014 at 1:16 PM, Piotr Caban <piotr.caban(a)gmail.com> wrote: > On 06/14/14 01:23, Grazvydas Ignotas wrote: >> >> --- >> dlls/msvcrt/file.c | 27 +++++++++++++++------------ >> 1 file changed, 15 insertions(+), 12 deletions(-) >> >> diff --git a/dlls/msvcrt/file.c b/dlls/msvcrt/file.c >> index 7523bbb..d6fb9ef 100644 >> --- a/dlls/msvcrt/file.c >> +++ b/dlls/msvcrt/file.c >> @@ -3641,6 +3641,17 @@ MSVCRT_wchar_t * CDECL MSVCRT_fgetws(MSVCRT_wchar_t >> *s, int size, MSVCRT_FILE* f >> return buf_start; >> } >> >> +static inline int msvcrt_set_write_direction(MSVCRT_FILE* file) >> +{ >> + if(!(file->_flag & MSVCRT__IOWRT)) { >> + if(file->_flag & MSVCRT__IORW) >> + file->_flag |= MSVCRT__IOWRT; >> + else >> + return MSVCRT_EOF; >> + } >> + return 0; >> +} > > I don't see a good reason for making this code reusable. The code is used to > inform how the buffer is used (if it's used for writing or reading). This > means that it doesn't make sense to set it if buffer is not used. The only > valid use of it I can see in wine sources is _flsbuf. > > I've wrote a test that shows that _IOWRT flag is not set if _bufsiz==0 or in > the case you're implementing. You can see it's code and result on windows > here: > https://testbot.winehq.org/JobDetails.pl?Key=7552 I see, thanks for the test. Not setting the flag in that case however uncovers another problem where after rewind/fflush _cnt is not 0, so _flsbuf doesn't get called and _IOWRT doesn't get set, as a result next fflush doesn't flush the buffer at all. I've added a few patches that try to deal with that. -- Gražvydas

June 18, 2014

WineHQ Downtime

by Jeremy Newman

WineHQ will be going offline starting at 10:00 CDT tomorrow (Wednesday 2014-06-18) and will be down for up to an hour. We are moving the site and all services (other than the Wiki) to new hardware. This includes: WineHQ.org, Forums, AppDB, Bugzilla, Git, FTP, Mailing lists, and WineTestBot Web Even after the things come back online, some services may need some tweaking. We will be on the issues as fast as we can. -N

June 17, 2014

Re: [PATCH 2/2] packager: Add loading support for Ole10Native storage objects

by Vincent Povirk

+ hr = IStorage_OpenStream(pStg, ole10nativeW, NULL, + STGM_READWRITE | STGM_SHARE_EXCLUSIVE, 0, &stream); You should probably use STGM_READ here.

June 17, 2014

Re: [4/5] msvcrt: Move write flag setting code for reuse.

by Piotr Caban

On 06/14/14 01:23, Grazvydas Ignotas wrote: > --- > dlls/msvcrt/file.c | 27 +++++++++++++++------------ > 1 file changed, 15 insertions(+), 12 deletions(-) > > diff --git a/dlls/msvcrt/file.c b/dlls/msvcrt/file.c > index 7523bbb..d6fb9ef 100644 > --- a/dlls/msvcrt/file.c > +++ b/dlls/msvcrt/file.c > @@ -3641,6 +3641,17 @@ MSVCRT_wchar_t * CDECL MSVCRT_fgetws(MSVCRT_wchar_t *s, int size, MSVCRT_FILE* f > return buf_start; > } > > +static inline int msvcrt_set_write_direction(MSVCRT_FILE* file) > +{ > + if(!(file->_flag & MSVCRT__IOWRT)) { > + if(file->_flag & MSVCRT__IORW) > + file->_flag |= MSVCRT__IOWRT; > + else > + return MSVCRT_EOF; > + } > + return 0; > +} I don't see a good reason for making this code reusable. The code is used to inform how the buffer is used (if it's used for writing or reading). This means that it doesn't make sense to set it if buffer is not used. The only valid use of it I can see in wine sources is _flsbuf. I've wrote a test that shows that _IOWRT flag is not set if _bufsiz==0 or in the case you're implementing. You can see it's code and result on windows here: https://testbot.winehq.org/JobDetails.pl?Key=7552

June 17, 2014

Re: [PATCH 1/5] d2d1: Implement d2d_d3d_render_target_CreateSolidColorBrush().

by Henri Verbeet

On 16 June 2014 16:50, Jacek Caban <jacek(a)codeweavers.com> wrote: >> struct d2d_brush *b = unsafe_impl_from_ID2DBrush(brush); > > Since you have many different vtbls for ID2DBrush implementation, you > can't use the usual vtbl trick for checking if passed pointer is really > our implementation. One way this can be solved is to abuse Other places that do this kind of thing just check against multiple vtbls. > QueryInterface, so that you could call: > > ID2DBrush_QueryInterface(brush, &IID_brush_struct, (void**)&brush_struct); > > QueryInterface could just return the struct directly for that special > IID. And yeah, returning struct instead of an interface is not pretty, > but that's probably fine here. You could even skip AddRef in this case. > That works, although personally I'd say it's a little more complex than just having the casts, and not really any prettier. I don't care too strongly though, so as far as I'm concerned it comes down to whatever Alexandre prefers. >> ... >> ID3D10Device_PSSetShader(device, b->shader); >> ID3D10Device_PSSetConstantBuffers(device, 0, 1, &b->cb); >> ... >> ID3D10Device_DrawIndexed(device, ...); > > I see, this could really use common code. > Sure. Eventually we'll probably have something like "d2d_brush_apply(brush, device);", and we'll probably want to queue up and merge draw operations until ID2D1RenderTarget::EndDraw(), but that's the basic idea. >> I think the two casts, while not very pretty, are worth it in comparison. > > This, again, depends on how this will look when the implementation is > more complete. Such casts are usually a sign of a design problem, but > the final decision is up to you. *If* such casts will be only in brush > creation code, that's not too bad. Yeah, it should only be needed in the creation / initialization code, everything else should just operate on struct d2d_brush. > You could make them even more local > (eg. by replacing d2d_solid_color_brush_init by a function that returns > ID2D1SolidBrush interface pointer, so that caller doesn't need to do any > more cast and the problem does not spread across the code). > Yeah, perhaps. Effectively that just means moving most of the body of d2d_d3d_render_target_CreateSolidColorBrush() to brush.c, and it's another one of those things that I'm not really opposed to, but don't really think are worth it either.

June 17, 2014

Re: [PATCH 4/4] vbscript: Implemented Abs(try 2)

by Jacek Caban

On 06/17/14 08:00, Shuai Meng wrote: > diff --git a/dlls/vbscript/global.c b/dlls/vbscript/global.c > index d21784d..e646a29 100644 > --- a/dlls/vbscript/global.c > +++ b/dlls/vbscript/global.c > @@ -1302,8 +1302,24 @@ static HRESULT Global_ChrW(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARI > > static HRESULT Global_Abs(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > { > - FIXME("\n"); > - return E_NOTIMPL; > + VARIANT v; > + HRESULT hres; > + > + TRACE("(%s)\n", debugstr_variant(arg)); > + > + assert(args_cnt == 1); > + > + V_VT(&v) = VT_EMPTY; > + hres = VariantChangeType(&v, arg, VARIANT_LOCALBOOL, VT_R8); > + if (FAILED(hres)) > + return S_OK; Please use to_double here. Also note weird indention here. Jacek

June 17, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 2)

by Jacek Caban

On 06/17/14 07:59, Shuai Meng wrote: > diff --git a/dlls/vbscript/global.c b/dlls/vbscript/global.c > index c2b2edd..d21784d 100644 > --- a/dlls/vbscript/global.c > +++ b/dlls/vbscript/global.c > @@ -1320,8 +1320,24 @@ static HRESULT Global_Int(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIA > > static HRESULT Global_Sgn(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > { > - FIXME("\n"); > - return E_NOTIMPL; > + VARIANT v; > + HRESULT hres; > + > + TRACE("(%s)\n", debugstr_variant(arg)); > + > + assert(args_cnt == 1); > + > + V_VT(&v) = VT_EMPTY; > + hres = VariantChangeType(&v, arg, VARIANT_LOCALBOOL, VT_R8); > + if (FAILED(hres)) > + return S_OK; Please use to_double() instead. to_double may need some fixes (it may require similar changes as you did for to_string first). Jacek

June 17, 2014

Re: [PATCH 2/4] vbscript: Implemented VarType(try 2)

by Jacek Caban

On 06/17/14 07:59, Shuai Meng wrote: > diff --git a/dlls/vbscript/global.c b/dlls/vbscript/global.c > index 5357df8..c2b2edd 100644 > --- a/dlls/vbscript/global.c > +++ b/dlls/vbscript/global.c > @@ -602,8 +602,52 @@ static HRESULT Global_Oct(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIA > > static HRESULT Global_VarType(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > { > - FIXME("\n"); > - return E_NOTIMPL; > + TRACE("(%s)\n", debugstr_variant(arg)); > + > + assert(args_cnt == 1); > + > + if(res) { > + V_VT(res) = VT_I2; > + switch(V_VT(arg)) { > + case VT_EMPTY: > + V_I2(res) = VT_EMPTY; > + break; > + case VT_NULL: > + V_I2(res) = VT_NULL; > + break; > + case VT_I2: > + V_I2(res) = VT_I2; > + break; (...) This all could be just: V_I2(res) = V_VT(arg); To handle unsupported types, you could use something like: if(V_VT(arg) & ~VT_TYPEMASK) { FIXME("..."); return E_NOTIMPL; } if(res) { V_VT(res) = VT_I2; V_I2(res) = V_VT(arg); } Jacek

June 17, 2014

Re: [PATCH 1/4] vbscript: Implemented TypeName(try 2)

by Jacek Caban

On 06/17/14 07:58, Shuai Meng wrote: > iff --git a/dlls/vbscript/global.c b/dlls/vbscript/global.c > index 5160374..5357df8 100644 > --- a/dlls/vbscript/global.c > +++ b/dlls/vbscript/global.c > @@ -1502,8 +1502,57 @@ static HRESULT Global_DatePart(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, > > static HRESULT Global_TypeName(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > { > - FIXME("\n"); > - return E_NOTIMPL; > + static const WCHAR ByteW[] = {'B', 'y', 't', 'e', 0}; > + static const WCHAR IntegerW[] = {'I', 'n', 't', 'e', 'g', 'e', 'r', 0}; > + static const WCHAR LongW[] = {'L', 'o', 'n', 'g', 0}; > + static const WCHAR SingleW[] = {'S', 'i', 'n', 'g', 'l', 'e', 0}; > + static const WCHAR DoubleW[] = {'D', 'o', 'u', 'b', 'l', 'e', 0}; > + static const WCHAR CurrencyW[] = {'C', 'u', 'r', 'r', 'e', 'n', 'c', 'y', 0}; > + static const WCHAR DecimalW[] = {'D', 'e', 'c', 'i', 'm', 'a', 'l', 0}; > + static const WCHAR DateW[] = {'D', 'a', 't', 'e', 0}; > + static const WCHAR StringW[] = {'S', 't', 'r', 'i', 'n', 'g', 0}; > + static const WCHAR BooleanW[] = {'B', 'o', 'o', 'l', 'e', 'a', 'n', 0}; > + static const WCHAR EmptyW[] = {'E', 'm', 'p', 't', 'y', 0}; > + static const WCHAR NullW[] = {'N', 'u', 'l', 'l', 0}; > + /*static const WCHAR ObjectW[] = {'O', 'b', 'j', 'e', 'c', 't', 0}; Please don't leave such commented things in the patch. You could remove it, but ideally this should have tests and implementation. > + static const WCHAR NothingW[] = {'N', 'o', 't', 'h', 'i', 'n', 'g', 0};*/ > + > + TRACE("(%s)\n", debugstr_variant(arg)); > + > + assert(args_cnt == 1); > + > + if(res) { This if() is not needed. return_string will take care of NULL res. > + switch(V_VT(arg)) { > + case VT_UI1: Please don't add 8 space indention. I personally prefer no additional indentions for cases, but in any case, if you do indention, use 4 spaces as the rest of file. > + return return_string(res, ByteW); > + case VT_I2: > + return return_string(res, IntegerW); > + case VT_I4: > + return return_string(res, LongW); > + case VT_R4: > + return return_string(res, SingleW); > + case VT_R8: > + return return_string(res, DoubleW); > + case VT_CY: > + return return_string(res, CurrencyW); > + case VT_DECIMAL: > + return return_string(res, DecimalW); > + case VT_DATE: > + return return_string(res, DateW); > + case VT_BSTR: > + return return_string(res, StringW); > + case VT_BOOL: > + return return_string(res, BooleanW); > + case VT_EMPTY: > + return return_string(res, EmptyW); > + case VT_NULL: > + return return_string(res, NullW); > + default: > + FIXME("arg %s not supported\n", debugstr_variant(arg)); > + return E_NOTIMPL; > + } > + } > + return S_OK; > } > > static HRESULT Global_Array(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > diff --git a/dlls/vbscript/tests/api.vbs b/dlls/vbscript/tests/api.vbs > index 2cf9bb7..32f4dc3 100644 > --- a/dlls/vbscript/tests/api.vbs > +++ b/dlls/vbscript/tests/api.vbs > @@ -845,4 +845,25 @@ MyObject.myval = 0 > Call ok(CSng(MyObject) = 0, "CSng(MyObject) = " & CSng(MyObject)) > Call ok(getVT(CSng(MyObject)) = "VT_R4", "getVT(CSng(MyObject)) = " & getVT(CSng(MyObject))) > > +Call ok(TypeName(CByte(255)) = "Byte", "TypeName(CByte(255)) = " & TypeName(CByte(255))) > +Call ok(getVT(TypeName(CByte(255))) = "VT_BSTR", "getVT(TypeName(CByte(255))) = " & getVT(TypeName(CByte(255)))) > +Call ok(TypeName(255) = "Integer", "TypeName(255) = " & TypeName(255)) > +Call ok(getVT(TypeName(255)) = "VT_BSTR", "getVT(TypeName(255)) = " & getVT(TypeName(255))) > +Call ok(TypeName(32768) = "Long", "TypeName(32768) = " & TypeName(32768)) > +Call ok(getVT(TypeName(32768)) = "VT_BSTR", "getVT(TypeName(32768)) = " & getVT(TypeName(32768))) > +Call ok(TypeName(CSng(0.5)) = "Single", "TypeName(CSng(0.5)) = " & TypeName(CSng(0.5))) > +Call ok(getVT(TypeName(CSng(0.5))) = "VT_BSTR", "getVT(TypeName(CSng(0.5))) = " & getVT(TypeName(CSng(0.5)))) > +Call ok(TypeName(-0.5) = "Double", "TypeName(-0.5) = " & TypeName(-0.5)) > +Call ok(getVT(TypeName(-0.5)) = "VT_BSTR", "getVT(TypeName(-0.5)) = " & getVT(TypeName(-0.5))) > +Call ok(TypeName(CCur(0.5)) = "Currency", "TypeName(CCur(0.5)) = " & TypeName(CCur(0.5))) > +Call ok(getVT(TypeName(CCur(0.5))) = "VT_BSTR", "getVT(TypeName(CCur(0.5))) = " & getVT(TypeName(CCur(0.5)))) > +Call ok(TypeName(CStr(0.5)) = "String", "TypeName(CStr(0.5)) = " & TypeName(CStr(0.5))) > +Call ok(getVT(TypeName(CStr(0.5))) = "VT_BSTR", "getVT(TypeName(CStr(0.5))) = " & getVT(TypeName(CStr(0.5)))) > +Call ok(TypeName(CBool(0.5)) = "Boolean", "TypeName(CBool(0.5)) = " & TypeName(CBool(0.5))) > +Call ok(getVT(TypeName(CBool(0.5))) = "VT_BSTR", "getVT(TypeName(CBool(0.5))) = " & getVT(TypeName(CBool(0.5)))) Using True or False directly instead of CBool() would be cleaner. Jacek

June 17, 2014

Re: [PATCH 4/4] vbscript: Implemented Abs(try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7551 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

June 17, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn(try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7550 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

June 17, 2014

Re: [PATCH 2/4] vbscript: Implemented VarType(try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7549 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

June 17, 2014

Re: [PATCH 1/4] vbscript: Implemented TypeName(try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7548 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

June 17, 2014

Re: [PATCH 4/4] vbscript: Implemented Abs

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7547 Your paranoid android. === build (build) === Patch failed to apply

June 17, 2014

Re: [PATCH 3/4] vbscript: Implemented Sgn

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7546 Your paranoid android. === build (build) === Patch failed to apply

June 17, 2014

Re: [PATCH 2/4] vbscript: Implemented VarType

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7545 Your paranoid android. === build (build) === Patch failed to apply

June 17, 2014

Re: [PATCH 1/4] vbscript: Implemented TypeName

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7544 Your paranoid android. === build (build) === Patch failed to apply

June 17, 2014

Re: Fix for PlgBlt, the XFORM matrix was calculated incorrectly

by Michael Mc Donnell

Thank you Sebastian for reviewing the code and digging into the equations. Sounds good that it is possibly a small fix. Alexander can you verify this with your test case? Thanks, Michael On Sun, Jun 15, 2014 at 11:59 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Hi guys, > > by comparing the "new" equations > (http://www.winehq.org/pipermail/wine-devel/2009-December/080391.html) > and the old ones (http://source.winehq.org/source/dlls/gdi32/bitblt.c) > you'll find the following differences: > > eM11: identical > eM21: identical > eDx: identical > > eM12: identical > eM22: plg <-> rect swapped > eDy: identical > > It isn't obvious at the first look, but the only difference is that in > eM22 plg and rect are swapped. By taking a bit closer look at ... > > http://source.winehq.org/source/dlls/gdi32/bitblt.c#L1040 > > ... and comparing the equations for the X-component (eM11, eM21) and the > Y-component (eM12, eM22) you'll notice that this must be right, the > current equation violate the symmetry - no need to calculate, you can > see that with the naked eye ;) > > The correct equation for eM22 should be: > > xf.eM22 = (rect[1].x*(plg[2].y - plg[0].y) - rect[2].x*(plg[1].y - > plg[0].y) - rect[0].x*(plg[2].y - plg[1].y)) / det; > > Could someone please test if this change alone is sufficient to fix the > issue? Should be way easier to get that upstream than all the other > "no-op" changes. > > Regards, > Sebastian > > Am 16.06.2014 04:07, schrieb Michael Mc Donnell: >> Hi Alexander >> >> On Wed, Jun 11, 2014 at 5:36 AM, Alexander Almaleh <sashoalm(a)gmail.com> wrote: >>> >>> I just realized that it would be impossible to write an automated test for PlgBlt now, because Wine has a second, unrelated but, for which I already wrote another email to wine-devel. It's titled "BitBlt doesn't honor the rotation specified by SetWorldTransform". So even with my fixed PlgBlt, Wine's version would still not work correctly, until that second, unrelated bug is fix. That's why I submitted a Windows project where I compare my patched PlgBlt, and Wine's PlgBlt under Windows. >> >> I do not understand how that would stop you from writing an automated >> test? You can use todo_wine to show how the code is supposed to work. >> You can then cross compile the test and upload it to the Wine TestBot. >> The Wine TestBot will run your test on Windows and report back if it >> is correct. The automated test can then be applied to the wine source >> tree. Once your patch with the fix is ready you can submit it together >> with a patch that removes the todo_wine. >> >>> Bearing that in mind, what is your advice? Bruno Jesus already wrote that he can confirm my code runs in Windows. Should I just explain how I reached the formula for the XFORM matrix? >> >> I think you will need to be able to explain why the old code is wrong >> and explain why yours is better. Explaining what the formula is might >> be a good way to *help* explain it. It is important that your code >> does not break anything. You have found one example where your code >> works better but it might break other examples. >> >> I see Nikolay Sivov, the author of the function, has already given you >> feedback earlier [1]. He will probably be one of the people you need >> to convince. When he said: >> >> "P.S. I don't see your point on inlining determinant expression." >> >> He probably means you should rewrite your equation to use the >> determinant, unless you have a very good reason, in which case you >> need to explain it. I personally think you might be able to fix his >> code instead of replacing it. >> >> Good luck, >> Michael >> >> [1] http://www.winehq.org/pipermail/wine-devel/2009-December/080392.html >> >> > > >

June 17, 2014

Re: msvcr110: Fix typo in exported symbol _set_SSE2_enable.

by Piotr Caban

Hi, You need to generate the patch on top of newest wine from git. Cheers, Piotr

June 16, 2014

Re: ole32: Return the correct error in FileLockBytesImpl_*LockRegion*().

by Vincent Povirk

It looks to me like locks that fail due to conflicts will set ERROR_LOCK_VIOLATION, not ERROR_ACCESS_DENIED. We should probably add some tests for the error to the LockFileEx tests. I'd also be interested in what Windows returns on a filesystem that doesn't support locking, if such a thing exists.

June 16, 2014

Re: ole32: Fix StorageImpl_LockRegionSync() to actually wait between locking attempts.

by Vincent Povirk

Oops. Thanks for the fix. On Mon, Jun 16, 2014 at 11:23 AM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > dlls/ole32/storage32.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/ole32/storage32.c b/dlls/ole32/storage32.c > index 757138d..49d16fd 100644 > --- a/dlls/ole32/storage32.c > +++ b/dlls/ole32/storage32.c > @@ -2874,16 +2874,16 @@ static HRESULT StorageImpl_LockRegionSync(StorageImpl *This, ULARGE_INTEGER offs > ULARGE_INTEGER cb, DWORD dwLockType) > { > HRESULT hr; > + int delay; > > /* if it's a FileLockBytesImpl use LockFileEx in blocking mode */ > if (SUCCEEDED(FileLockBytesImpl_LockRegionSync(This->lockBytes, offset, cb))) > return S_OK; > > /* otherwise we have to fake it based on an async lock */ > + delay = 0; > do > { > - int delay=0; > - > hr = ILockBytes_LockRegion(This->lockBytes, offset, cb, dwLockType); > > if (hr == STG_E_ACCESSDENIED) > -- > 2.0.0 > > >

June 16, 2014

Re: [PATCH 1/5] d2d1: Implement d2d_d3d_render_target_CreateSolidColorBrush().

by Jacek Caban

On 06/16/14 14:39, Henri Verbeet wrote: > On 16 June 2014 14:15, Jacek Caban <jacek(a)codeweavers.com> wrote: >> I don't know this how will this be used in the future, so my ideas may >> not be best fit. For the code that you sent so far, a separated struct > As far as the API is concerned, brushes are mostly used for drawing > commands like e.g. ID2D1RenderTarget::FillRectangle() and the like. > These all take ID2D1Brush pointers. The way the implementation is > likely to work in the future is that brush types will have an > associated fragment shader, and some constant buffer data. I.e., a > typical drawing function implementation would do something along the > lines of the following: > > struct d2d_brush *b = unsafe_impl_from_ID2DBrush(brush); Since you have many different vtbls for ID2DBrush implementation, you can't use the usual vtbl trick for checking if passed pointer is really our implementation. One way this can be solved is to abuse QueryInterface, so that you could call: ID2DBrush_QueryInterface(brush, &IID_brush_struct, (void**)&brush_struct); QueryInterface could just return the struct directly for that special IID. And yeah, returning struct instead of an interface is not pretty, but that's probably fine here. You could even skip AddRef in this case. > ... > ID3D10Device_PSSetShader(device, b->shader); > ID3D10Device_PSSetConstantBuffers(device, 0, 1, &b->cb); > ... > ID3D10Device_DrawIndexed(device, ...); I see, this could really use common code. >> for all brush types would do the job. I guess that different brush types >> will store different data in the future, so separated structs will be >> needed anyway. If having some sort of shared struct is desired, this >> could be introduced as separated struct: >> >> struct d2d1_brash { >> /* shared stuff, maybe even refcount */ >> }; >> >> struct d2d1_solid_brush { >> ID2D1SolidColorBrush ID2D1SolidColorBrush_iface >> LONG refcount; >> struct brush base_brush; >> /* Stuff specific to solid brush */ >> }; >> >> This has some drawbacks like the fact that d2d1_brush can't be easily >> casted to ID2D1Brush. This may be avoided by design or, with some > It's mostly the ID2D1Brush -> struct d2d_brush conversion that's the > issue. If you do the above, you either need to do multiple > QueryInterface() calls in each drawing function, or introduce a > private interface to get at the embedded d2d_brush structure, and then > implement that for every single brush. The QI trick above makes it one QI call and no extra interface. > I think the two casts, while not very pretty, are worth it in comparison. This, again, depends on how this will look when the implementation is more complete. Such casts are usually a sign of a design problem, but the final decision is up to you. *If* such casts will be only in brush creation code, that's not too bad. You could make them even more local (eg. by replacing d2d_solid_color_brush_init by a function that returns ID2D1SolidBrush interface pointer, so that caller doesn't need to do any more cast and the problem does not spread across the code). >> runtime overhead, d2d1_brush could store a pointer to ID2D1Brush (which >> would be initialized to solid_brush->ID2D1SoludBrush_iface in this case) > That would only help for getting an ID2D1Brush from struct d2d_brush, > but even then, you'd just reintroduce the casts you were trying to > avoid. Not really. If you have random d2d_brush instance, you can't cast it anyway. If it's not random, then you probably should be able to use specialized structs like d2d1_solid_brush, which could be casted safely. Jacek

June 16, 2014

Re: [PATCH 5/5] ddraw/tests: Properly declare matrices.

by Henri Verbeet

On 16 June 2014 15:09, Marvin <testbot(a)winehq.org> wrote: > === w8 (32 bit visual) === > visual.c:2619: Test failed: unexpected colortable on offscreen surface > > === w2000pro (32 bit d3d) === > d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag > > === wxppro (32 bit d3d) === > d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag > > === wvistau64 (32 bit d3d) === > d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag > > === w2008s64 (32 bit d3d) === > d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag > > === w7u (32 bit d3d) === > d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag > > === w8 (32 bit d3d) === > d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag > > These are existing failures, for what it's worth.

June 16, 2014

Re: [PATCH 5/5] ddraw/tests: Properly declare matrices.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7524 Your paranoid android. === w8 (32 bit visual) === visual.c:2619: Test failed: unexpected colortable on offscreen surface === w2000pro (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === wxppro (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === wvistau64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w2008s64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w7u (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w8 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag

June 16, 2014

Re: [PATCH 1/5] d2d1: Implement d2d_d3d_render_target_CreateSolidColorBrush().

by Henri Verbeet

On 16 June 2014 14:15, Jacek Caban <jacek(a)codeweavers.com> wrote: > I don't know this how will this be used in the future, so my ideas may > not be best fit. For the code that you sent so far, a separated struct As far as the API is concerned, brushes are mostly used for drawing commands like e.g. ID2D1RenderTarget::FillRectangle() and the like. These all take ID2D1Brush pointers. The way the implementation is likely to work in the future is that brush types will have an associated fragment shader, and some constant buffer data. I.e., a typical drawing function implementation would do something along the lines of the following: struct d2d_brush *b = unsafe_impl_from_ID2DBrush(brush); ... ID3D10Device_PSSetShader(device, b->shader); ID3D10Device_PSSetConstantBuffers(device, 0, 1, &b->cb); ... ID3D10Device_DrawIndexed(device, ...); > for all brush types would do the job. I guess that different brush types > will store different data in the future, so separated structs will be > needed anyway. If having some sort of shared struct is desired, this > could be introduced as separated struct: > > struct d2d1_brash { > /* shared stuff, maybe even refcount */ > }; > > struct d2d1_solid_brush { > ID2D1SolidColorBrush ID2D1SolidColorBrush_iface > LONG refcount; > struct brush base_brush; > /* Stuff specific to solid brush */ > }; > > This has some drawbacks like the fact that d2d1_brush can't be easily > casted to ID2D1Brush. This may be avoided by design or, with some It's mostly the ID2D1Brush -> struct d2d_brush conversion that's the issue. If you do the above, you either need to do multiple QueryInterface() calls in each drawing function, or introduce a private interface to get at the embedded d2d_brush structure, and then implement that for every single brush. I think the two casts, while not very pretty, are worth it in comparison. > runtime overhead, d2d1_brush could store a pointer to ID2D1Brush (which > would be initialized to solid_brush->ID2D1SoludBrush_iface in this case) That would only help for getting an ID2D1Brush from struct d2d_brush, but even then, you'd just reintroduce the casts you were trying to avoid.

June 16, 2014

Re: [PATCH 1/5] d2d1: Implement d2d_d3d_render_target_CreateSolidColorBrush().

by Jacek Caban

On 06/16/14 13:59, Henri Verbeet wrote: > On 16 June 2014 13:57, Jacek Caban <jacek(a)codeweavers.com> wrote: >> Yup, and that patch has the same problem with parent to child interface >> casts. >> > What are you suggesting instead? I don't know this how will this be used in the future, so my ideas may not be best fit. For the code that you sent so far, a separated struct for all brush types would do the job. I guess that different brush types will store different data in the future, so separated structs will be needed anyway. If having some sort of shared struct is desired, this could be introduced as separated struct: struct d2d1_brash { /* shared stuff, maybe even refcount */ }; struct d2d1_solid_brush { ID2D1SolidColorBrush ID2D1SolidColorBrush_iface LONG refcount; struct brush base_brush; /* Stuff specific to solid brush */ }; This has some drawbacks like the fact that d2d1_brush can't be easily casted to ID2D1Brush. This may be avoided by design or, with some runtime overhead, d2d1_brush could store a pointer to ID2D1Brush (which would be initialized to solid_brush->ID2D1SoludBrush_iface in this case) or have some internal vtbl-like casting functions. Jacek

June 16, 2014

Re: [PATCH 1/5] d2d1: Implement d2d_d3d_render_target_CreateSolidColorBrush().

by Henri Verbeet

On 16 June 2014 13:57, Jacek Caban <jacek(a)codeweavers.com> wrote: > Yup, and that patch has the same problem with parent to child interface > casts. > What are you suggesting instead?

June 16, 2014

Re: [PATCH 1/5] d2d1: Implement d2d_d3d_render_target_CreateSolidColorBrush().

by Jacek Caban

On 06/16/14 13:53, Henri Verbeet wrote: > On 16 June 2014 13:44, Jacek Caban <jacek(a)codeweavers.com> wrote: >> Given how you use this object, this should be ID2D1SolidColorBrush. > No, struct d2d_brush is also used for e.g. 105100. Yup, and that patch has the same problem with parent to child interface casts. Jacek

June 16, 2014

Re: [PATCH 1/5] d2d1: Implement d2d_d3d_render_target_CreateSolidColorBrush().

by Henri Verbeet

On 16 June 2014 13:44, Jacek Caban <jacek(a)codeweavers.com> wrote: > Given how you use this object, this should be ID2D1SolidColorBrush. No, struct d2d_brush is also used for e.g. 105100.

June 16, 2014

Re: [PATCH 1/5] d2d1: Implement d2d_d3d_render_target_CreateSolidColorBrush().

by Jacek Caban

Hi Henri, On 06/16/14 13:13, Henri Verbeet wrote: > diff --git a/dlls/d2d1/d2d1_private.h b/dlls/d2d1/d2d1_private.h > index 5609db6..9e91728 100644 > --- a/dlls/d2d1/d2d1_private.h > +++ b/dlls/d2d1/d2d1_private.h > @@ -33,4 +33,13 @@ struct d2d_d3d_render_target > void d2d_d3d_render_target_init(struct d2d_d3d_render_target *render_target, ID2D1Factory *factory, > IDXGISurface *surface, const D2D1_RENDER_TARGET_PROPERTIES *desc) DECLSPEC_HIDDEN; > > +struct d2d_brush > +{ > + ID2D1Brush ID2D1Brush_iface; Given how you use this object, this should be ID2D1SolidColorBrush. I guess you want to somehow reuse this struct for other brush types, but there should be better ways for this. Then: +void d2d_solid_color_brush_init(struct d2d_brush *brush, ID2D1RenderTarget *render_target, + const D2D1_COLOR_F *color, const D2D1_BRUSH_PROPERTIES *desc) +{ + FIXME("Ignoring brush properties.\n"); + + brush->ID2D1Brush_iface.lpVtbl = (ID2D1BrushVtbl *)&d2d_solid_color_brush_vtbl; + brush->refcount = 1; +} This cast should not be needed. > + LONG refcount; > +}; > + > +void d2d_solid_color_brush_init(struct d2d_brush *brush, ID2D1RenderTarget *render_target, > + const D2D1_COLOR_F *color, const D2D1_BRUSH_PROPERTIES *desc) DECLSPEC_HIDDEN; > + > #endif /* __WINE_D2D1_PRIVATE_H */ > diff --git a/dlls/d2d1/render_target.c b/dlls/d2d1/render_target.c > index be9c1b6..e8c56a0 100644 > --- a/dlls/d2d1/render_target.c > +++ b/dlls/d2d1/render_target.c > @@ -117,9 +117,19 @@ static HRESULT STDMETHODCALLTYPE d2d_d3d_render_target_CreateBitmapBrush(ID2D1Re > static HRESULT STDMETHODCALLTYPE d2d_d3d_render_target_CreateSolidColorBrush(ID2D1RenderTarget *iface, > const D2D1_COLOR_F *color, const D2D1_BRUSH_PROPERTIES *desc, ID2D1SolidColorBrush **brush) > { > - FIXME("iface %p, color %p, desc %p, brush %p stub!\n", iface, color, desc, brush); > + struct d2d_brush *object; > > - return E_NOTIMPL; > + TRACE("iface %p, color %p, desc %p, brush %p.\n", iface, color, desc, brush); > + > + if (!(object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*object)))) > + return E_OUTOFMEMORY; > + > + d2d_solid_color_brush_init(object, iface, color, desc); > + > + TRACE("Created brush %p.\n", object); > + *brush = (ID2D1SolidColorBrush *)&object->ID2D1Brush_iface; Same here, the cast should not be needed. Also allocating memory in brush.c seems more logical to me (although that's a matter of taste). Cheers, Jacek

June 16, 2014

Re: Fix for PlgBlt, the XFORM matrix was calculated incorrectly

by Sebastian Lackner

Hi guys, by comparing the "new" equations (http://www.winehq.org/pipermail/wine-devel/2009-December/080391.html) and the old ones (http://source.winehq.org/source/dlls/gdi32/bitblt.c) you'll find the following differences: eM11: identical eM21: identical eDx: identical eM12: identical eM22: plg <-> rect swapped eDy: identical It isn't obvious at the first look, but the only difference is that in eM22 plg and rect are swapped. By taking a bit closer look at ... http://source.winehq.org/source/dlls/gdi32/bitblt.c#L1040 ... and comparing the equations for the X-component (eM11, eM21) and the Y-component (eM12, eM22) you'll notice that this must be right, the current equation violate the symmetry - no need to calculate, you can see that with the naked eye ;) The correct equation for eM22 should be: xf.eM22 = (rect[1].x*(plg[2].y - plg[0].y) - rect[2].x*(plg[1].y - plg[0].y) - rect[0].x*(plg[2].y - plg[1].y)) / det; Could someone please test if this change alone is sufficient to fix the issue? Should be way easier to get that upstream than all the other "no-op" changes. Regards, Sebastian Am 16.06.2014 04:07, schrieb Michael Mc Donnell: > Hi Alexander > > On Wed, Jun 11, 2014 at 5:36 AM, Alexander Almaleh <sashoalm(a)gmail.com> wrote: >> >> I just realized that it would be impossible to write an automated test for PlgBlt now, because Wine has a second, unrelated but, for which I already wrote another email to wine-devel. It's titled "BitBlt doesn't honor the rotation specified by SetWorldTransform". So even with my fixed PlgBlt, Wine's version would still not work correctly, until that second, unrelated bug is fix. That's why I submitted a Windows project where I compare my patched PlgBlt, and Wine's PlgBlt under Windows. > > I do not understand how that would stop you from writing an automated > test? You can use todo_wine to show how the code is supposed to work. > You can then cross compile the test and upload it to the Wine TestBot. > The Wine TestBot will run your test on Windows and report back if it > is correct. The automated test can then be applied to the wine source > tree. Once your patch with the fix is ready you can submit it together > with a patch that removes the todo_wine. > >> Bearing that in mind, what is your advice? Bruno Jesus already wrote that he can confirm my code runs in Windows. Should I just explain how I reached the formula for the XFORM matrix? > > I think you will need to be able to explain why the old code is wrong > and explain why yours is better. Explaining what the formula is might > be a good way to *help* explain it. It is important that your code > does not break anything. You have found one example where your code > works better but it might break other examples. > > I see Nikolay Sivov, the author of the function, has already given you > feedback earlier [1]. He will probably be one of the people you need > to convince. When he said: > > "P.S. I don't see your point on inlining determinant expression." > > He probably means you should rewrite your equation to use the > determinant, unless you have a very good reason, in which case you > need to explain it. I personally think you might be able to fix his > code instead of replacing it. > > Good luck, > Michael > > [1] http://www.winehq.org/pipermail/wine-devel/2009-December/080392.html > >

June 16, 2014

Re: Fix for PlgBlt, the XFORM matrix was calculated incorrectly

by Michael Mc Donnell

Hi Alexander On Wed, Jun 11, 2014 at 5:36 AM, Alexander Almaleh <sashoalm(a)gmail.com> wrote: > > I just realized that it would be impossible to write an automated test for PlgBlt now, because Wine has a second, unrelated but, for which I already wrote another email to wine-devel. It's titled "BitBlt doesn't honor the rotation specified by SetWorldTransform". So even with my fixed PlgBlt, Wine's version would still not work correctly, until that second, unrelated bug is fix. That's why I submitted a Windows project where I compare my patched PlgBlt, and Wine's PlgBlt under Windows. I do not understand how that would stop you from writing an automated test? You can use todo_wine to show how the code is supposed to work. You can then cross compile the test and upload it to the Wine TestBot. The Wine TestBot will run your test on Windows and report back if it is correct. The automated test can then be applied to the wine source tree. Once your patch with the fix is ready you can submit it together with a patch that removes the todo_wine. > Bearing that in mind, what is your advice? Bruno Jesus already wrote that he can confirm my code runs in Windows. Should I just explain how I reached the formula for the XFORM matrix? I think you will need to be able to explain why the old code is wrong and explain why yours is better. Explaining what the formula is might be a good way to *help* explain it. It is important that your code does not break anything. You have found one example where your code works better but it might break other examples. I see Nikolay Sivov, the author of the function, has already given you feedback earlier [1]. He will probably be one of the people you need to convince. When he said: "P.S. I don't see your point on inlining determinant expression." He probably means you should rewrite your equation to use the determinant, unless you have a very good reason, in which case you need to explain it. I personally think you might be able to fix his code instead of replacing it. Good luck, Michael [1] http://www.winehq.org/pipermail/wine-devel/2009-December/080392.html

June 16, 2014

Re: kernel32: Raise DBG_PRINTEXCEPTION_C exception in OutputDebugStringA.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7510 Your paranoid android. === w2000pro (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00950000/00950001 exception: unhandled exception 80000004 at 00950000 exception.c:406: Test failed: 42: Wrong exception address 7C5C20B0/00950001 === wxppro (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00A30000/00A30001 exception: unhandled exception 80000004 at 00A30000 exception.c:406: Test failed: 42: Wrong exception address 7C80DF3C/00A30001 === wvistau64 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00340000/00340001 exception: unhandled exception 80000004 at 00340000 exception.c:406: Test failed: 42: Wrong exception address 7751ED97/00340001 === w2008s64 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:406: Test failed: 42: Wrong exception address 77E5ED97/003C0001 === w7u (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003F0000/003F0001 exception: unhandled exception 80000004 at 003F0000 exception.c:406: Test failed: 42: Wrong exception address 77CDE34F/003F0001 === w8 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 004F0000/004F0001 exception: unhandled exception 80000004 at 004F0000 exception.c:406: Test failed: 42: Wrong exception address 77174D17/004F0001

June 15, 2014

Re: windowscodecs/tests: Fixed some leaks on error path (Valgrind)

by Vincent Povirk

+ if (FAILED(hr)) + { + IStream_Release(stream); + IWICComponentFactory_Release(factory); + return; + } The rest of the function is already has code to handle failure, so returning early is unnecessary.

June 15, 2014

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory. (try 2)

by Zhenbo Li

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

June 14, 2014

Re: ws2_32/socket.c: Fix compile for linux systems without net/ipx.h

by Felix Janda

Bruno Jesus wrote: > On Fri, Jun 13, 2014 at 2:14 PM, Felix Janda <felix.janda(a)posteo.de> wrote: > > ... > > Not defining HAS_IPX would also fix the compilation but I don't see > > why one has to disable IPX because of 2 ipx specific constants not > > declared in linux/ipx.h. (The 2 constants are also declared in an > > kernel header not exported to userspace.) > > > > I'm not sure what's the best solution. I guess that one of the main > > remaining uses of IPX in linux is to play old network games in wine. > > Other possible solutions are for musl to include a netipx/ipx.h > > header (unlikely, the headers are tried to be kept as clean as > > possible) or declare the constants in sys/socket.h (maybe) or for > > the kernel to include the constants in linux/ipx.h. > > If the system does not #define the required variables to support IPX > then I don't think it's right to manually define then and assume they > will work. I'll download it and give it a try later. The constants are only used for the [sg]etsockopt() system calls. They are hardcoded in the linux kernel. As stated above I'm open to alternative solutions than the patch. Thanks for trying to reproduce the problem. Felix

June 13, 2014

Re: ws2_32/socket.c: Fix compile for linux systems without net/ipx.h

by Bruno Jesus

On Fri, Jun 13, 2014 at 2:14 PM, Felix Janda <felix.janda(a)posteo.de> wrote: > ... > Not defining HAS_IPX would also fix the compilation but I don't see > why one has to disable IPX because of 2 ipx specific constants not > declared in linux/ipx.h. (The 2 constants are also declared in an > kernel header not exported to userspace.) > > I'm not sure what's the best solution. I guess that one of the main > remaining uses of IPX in linux is to play old network games in wine. > Other possible solutions are for musl to include a netipx/ipx.h > header (unlikely, the headers are tried to be kept as clean as > possible) or declare the constants in sys/socket.h (maybe) or for > the kernel to include the constants in linux/ipx.h. If the system does not #define the required variables to support IPX then I don't think it's right to manually define then and assume they will work. I'll download it and give it a try later. Bruno

June 13, 2014

Re: ws2_32/socket.c: Fix compile for linux systems without net/ipx.h

by Felix Janda

Bruno Jesus wrote: > On Mon, Jun 2, 2014 at 3:01 PM, Felix Janda <felix.janda(a)posteo.de> wrote: > > --- > > dlls/ws2_32/socket.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > > index e31f396..cf5473d 100644 > > --- a/dlls/ws2_32/socket.c > > +++ b/dlls/ws2_32/socket.c > > @@ -109,6 +109,8 @@ > > # include <linux/types.h> > > # endif > > # include <linux/ipx.h> > > +# define SOL_IPX 256 > > +# define IPX_TYPE 1 > > # define HAS_IPX > > #endif > > Hi, can you share the details about how you are compiling this? There > may be a better solution like not defining HAS_IPX if SOL_IPX is not > present. If you help me reproduce the issue I can help to fix it. Thanks for your review. All my patches stem from issues when trying to compile wine on a musl libc[1] based system. The wiki[2] contains information on how to get a musl based distro but in order to reproduce the issue it should be enough to rename the netipx/ipx.h header file. The situation is that there is no netipx/ipx.h in musls headers but if linux headers are installed then there will be linux/ipx.h. So except for the definitions of SOL_IPX and IPX_TYPE everything is declared in order to make dlls/ws2_32/socket.c compile with HAS_IPX. Without the patch HAS_IPX will be declared anyway since linux/ipx.h exists. Then there are passages in socket.c behind #ifdef HAS_IPX where #ifdef SOL_IPX is used in order to determine whether to take linux or BSD specific code. musl pulls in the BSD specific code and so the compilation will fail. Not defining HAS_IPX would also fix the compilation but I don't see why one has to disable IPX because of 2 ipx specific constants not declared in linux/ipx.h. (The 2 constants are also declared in an kernel header not exported to userspace.) I'm not sure what's the best solution. I guess that one of the main remaining uses of IPX in linux is to play old network games in wine. Other possible solutions are for musl to include a netipx/ipx.h header (unlikely, the headers are tried to be kept as clean as possible) or declare the constants in sys/socket.h (maybe) or for the kernel to include the constants in linux/ipx.h. Felix [1]: http://musl-libc.org [2]: http://wiki.musl-libc.org

June 13, 2014

Re: [1/4] msvcrt/tests: Add a test for fwrite flushing behavior. (try 2)

by Piotr Caban

On 06/13/14 18:11, Grazvydas Ignotas wrote: > On Fri, Jun 13, 2014 at 12:00 PM, Piotr Caban <piotr.caban(a)gmail.com> wrote: >> Hi, >> >> >> On 06/13/14 01:27, Grazvydas Ignotas wrote: >>> >>> +static void test_write_flush(void) >>> +{ >>> + char iobuf[1024]; >>> + char *tempf; >>> + FILE *file; >>> + >>> + tempf = _tempnam(".","wne"); >>> + file = fopen(tempf, "wb+"); >>> + ok(file != NULL, "unable to create test file\n"); >>> + /* the default should be 4K */ >>> + test_write_flush_size(file, 4096); >> >> It would be nice to read the size from the file->_bufsiz instead of >> hard-coding 4096. This value is not initialized while the file is opened so >> you will need to call something before reading it's value. > > One of the goals of this test was to test if the default buffer size > is really 4K, after reading file->_bufsiz that will no longer be > tested. Also no test currently is accessing FILE members, so I'd > prefer to keep it as-is. I don't see any problem with accessing FILE members in tests. If you want to make sure it's set to 4096 just add following test: ok(file->_bufsiz == 4096, ...); You are generally testing behavior that depends on _bufsiz so I think it's cleaner to pass it there. >>> + unlink(tempf); >>> + free(tempf); >> >> _tempnam returns internal buffer, free should not be called on it. > > Are you sure? From what I see wine does MSVCRT__strdup(tmpbuf), unix > manpage also says it should be freed, many tests are already freeing > it. You're right, this buffer needs to be freed, sorry.

June 13, 2014

Re: [1/4] msvcrt/tests: Add a test for fwrite flushing behavior. (try 2)

by Grazvydas Ignotas

On Fri, Jun 13, 2014 at 12:00 PM, Piotr Caban <piotr.caban(a)gmail.com> wrote: > Hi, > > > On 06/13/14 01:27, Grazvydas Ignotas wrote: >> >> +static void test_write_flush(void) >> +{ >> + char iobuf[1024]; >> + char *tempf; >> + FILE *file; >> + >> + tempf = _tempnam(".","wne"); >> + file = fopen(tempf, "wb+"); >> + ok(file != NULL, "unable to create test file\n"); >> + /* the default should be 4K */ >> + test_write_flush_size(file, 4096); > > It would be nice to read the size from the file->_bufsiz instead of > hard-coding 4096. This value is not initialized while the file is opened so > you will need to call something before reading it's value. One of the goals of this test was to test if the default buffer size is really 4K, after reading file->_bufsiz that will no longer be tested. Also no test currently is accessing FILE members, so I'd prefer to keep it as-is. > >> + setvbuf(file, iobuf, _IOFBF, sizeof(iobuf)); >> + test_write_flush_size(file, sizeof(iobuf)); >> + fclose(file); > > Current implemententation of setvbuf is broken in wine. This code will cause > free(iobuf) to be called. I think that setvbuf needs to be fixed before this > test can be added. ok > >> + unlink(tempf); >> + free(tempf); > > _tempnam returns internal buffer, free should not be called on it. Are you sure? From what I see wine does MSVCRT__strdup(tmpbuf), unix manpage also says it should be freed, many tests are already freeing it. -- Gražvydas

June 13, 2014

Re: vbscript: Reset error number on error mode change.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7476 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

June 13, 2014

Re: [PATCH 1/2] riched20: Implement ITextSelection::GetText.

by Jactry Zeng

Hello, Could someone take a look at this patch? Any comment will be appreciate! Thanks. 2014-05-28 15:17 GMT+08:00 Jactry Zeng <wine(a)jactry.com>: > ChangeLog: > - skip a test in native 64bit riched20 > - implementing without helper function > > --- > dlls/riched20/richole.c | 28 +++++++++++++- > dlls/riched20/tests/richole.c | 88 ++++++++++++++++++++++++++++++ > ++++++++++++- > 2 files changed, 113 insertions(+), 3 deletions(-) > > > > > > -- Regards, Jactry Zeng

June 13, 2014

Re: [PATCH 2/2] vbscript: Fixed CStr

by Shuai Meng

2014-06-13 19:45 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > Hi Shuai, > > On 06/13/14 06:26, Shuai Meng wrote: > > - hres = to_string(arg, &str); > > + assert(args_cnt == 1); > > + > > + V_VT(&v) = VT_EMPTY; > > + hres = VariantChangeType(&v, arg, VARIANT_LOCALBOOL, VT_BSTR); > > Why do you change it? to_string() already does the same call. > Yes, you are right, I made a mistake, it's unnecessary to change it. > > Jacek > > >

June 13, 2014

Re: ws2_32/socket.c: Fix compile for linux systems without net/ipx.h

by Bruno Jesus

On Mon, Jun 2, 2014 at 3:01 PM, Felix Janda <felix.janda(a)posteo.de> wrote: > --- > dlls/ws2_32/socket.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index e31f396..cf5473d 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -109,6 +109,8 @@ > # include <linux/types.h> > # endif > # include <linux/ipx.h> > +# define SOL_IPX 256 > +# define IPX_TYPE 1 > # define HAS_IPX > #endif Hi, can you share the details about how you are compiling this? There may be a better solution like not defining HAS_IPX if SOL_IPX is not present. If you help me reproduce the issue I can help to fix it. Best regards, Bruno

June 13, 2014

Re: [3/4] msvcrt: change default buffer size to 4k.

by Piotr Caban

On 06/13/14 13:34, Grazvydas Ignotas wrote: > On Fri, Jun 13, 2014 at 12:08 PM, Piotr Caban <piotr.caban(a)gmail.com> wrote: >> On 06/13/14 01:27, Grazvydas Ignotas wrote: >>> >>> -#define MSVCRT_BUFSIZ 512 >>> +#define MSVCRT_BUFSIZ 4096 >> >> You can't change BUFSIZ value. > > Why not? This is internal MSVCRT_BUFSIZ from internal header, not the > public BUFSIZ one, which is more or less unrelated. > It's there because it's not possible to include msvcrt headers in the dll. You will also need BUFSIZ==512 for setvbuf implementation.

June 13, 2014

Re: [PATCH 2/2] vbscript: Fixed CStr

by Jacek Caban

Hi Shuai, On 06/13/14 06:26, Shuai Meng wrote: > - hres = to_string(arg, &str); > + assert(args_cnt == 1); > + > + V_VT(&v) = VT_EMPTY; > + hres = VariantChangeType(&v, arg, VARIANT_LOCALBOOL, VT_BSTR); Why do you change it? to_string() already does the same call. Jacek

June 13, 2014

Re: [3/4] msvcrt: change default buffer size to 4k.

by Grazvydas Ignotas

On Fri, Jun 13, 2014 at 12:08 PM, Piotr Caban <piotr.caban(a)gmail.com> wrote: > On 06/13/14 01:27, Grazvydas Ignotas wrote: >> >> -#define MSVCRT_BUFSIZ 512 >> +#define MSVCRT_BUFSIZ 4096 > > You can't change BUFSIZ value. Why not? This is internal MSVCRT_BUFSIZ from internal header, not the public BUFSIZ one, which is more or less unrelated. -- Gražvydas

June 13, 2014

Re: [PATCH 2/2] vbscript: Fixed CStr

by Piotr Caban

On 06/13/14 06:26, Shuai Meng wrote: > --- > dlls/vbscript/global.c | 16 +++++++++++++--- > dlls/vbscript/tests/api.vbs | 21 +++++++++++++++++++++ > 2 files changed, 34 insertions(+), 3 deletions(-) > You have probably sent wrong patch, one that you've sent me earlier is better (https://github.com/Shuai-Meng/wine/commit/54bb6a783a623a3bf30c8fe33187c8a35…) Taking in account you'll need to resend it, could you please also change: + if(!res) + return DISP_E_BADVARTYPE; + else { + *res = v; + return S_OK; + } to if(!res) return DISP_E_BADVARTYPE; *res = v; return S_OK; It's a style change that makes your code similar to other code in global.c Thanks, Piotr

June 13, 2014

Re: [3/4] msvcrt: change default buffer size to 4k.

by Piotr Caban

On 06/13/14 01:27, Grazvydas Ignotas wrote: > -#define MSVCRT_BUFSIZ 512 > +#define MSVCRT_BUFSIZ 4096 You can't change BUFSIZ value.

June 13, 2014

Re: [1/4] msvcrt/tests: Add a test for fwrite flushing behavior. (try 2)

by Piotr Caban

Hi, On 06/13/14 01:27, Grazvydas Ignotas wrote: > +static void test_write_flush(void) > +{ > + char iobuf[1024]; > + char *tempf; > + FILE *file; > + > + tempf = _tempnam(".","wne"); > + file = fopen(tempf, "wb+"); > + ok(file != NULL, "unable to create test file\n"); > + /* the default should be 4K */ > + test_write_flush_size(file, 4096); It would be nice to read the size from the file->_bufsiz instead of hard-coding 4096. This value is not initialized while the file is opened so you will need to call something before reading it's value. > + setvbuf(file, iobuf, _IOFBF, sizeof(iobuf)); > + test_write_flush_size(file, sizeof(iobuf)); > + fclose(file); Current implemententation of setvbuf is broken in wine. This code will cause free(iobuf) to be called. I think that setvbuf needs to be fixed before this test can be added. > + unlink(tempf); > + free(tempf); _tempnam returns internal buffer, free should not be called on it. Thanks, Piotr

June 13, 2014

Re: [PATCH 2/2] vbscript: Fixed CStr

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7468 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

June 13, 2014

Re: [PATCH 1/2] msvcrt: Add _strxfrm_l implementation

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7457 Your paranoid android. === w2000pro (32 bit string) === string: unhandled exception c0000005 at 78010362 === wxppro (32 bit string) === string: unhandled exception c0000005 at 77C47AD8

June 12, 2014

Re: services: Defer service delete until all handles are closed

by Nikolay Sivov

On 6/12/2014 01:32, Marvin wrote: > 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=7438 > > Your paranoid android. > > > === w7u (32 bit service) === > service.c:1381: Test failed: Something wrong in the calculation > service.c:1417: Test failed: Active services mismatch 1 > The test timed out I believe it's not related to a patch, only another open/close was added and some code handling Wine bug was removed. I don't see how it can make it time out, especially since all other VMs are fine.

June 12, 2014

Re: [PATCH 07/10] dmloader: Use the generic DirectMusicObject implementation for DMContainer.

by Michael Stefaniuc

On 06/12/2014 11:57 AM, Marvin wrote: > 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=7450 > > Your paranoid android. > > > === build (build) === > Patch failed to apply Patch depends on the outstanding http://source.winehq.org/patches/data/104953 Full dmloader test results can be seen in https://testbot.winehq.org/JobDetails.pl?Key=7424 (canceled it once I had enough results; the 64bit tests are skipped anyway). This apply failure cascades through to patch 8 and 9 which depend on patch 7. bye michael

June 12, 2014

Re: [PATCH 09/10] dmloader: Add and use a generic IPersistStream_GetClassID.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7452 Your paranoid android. === build (build) === Patch failed to apply

June 12, 2014

Re: [PATCH 08/10] dmloader/tests: Add more DirectMusicCollection tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7451 Your paranoid android. === build (build) === Patch failed to apply

June 12, 2014

Re: [PATCH 07/10] dmloader: Use the generic DirectMusicObject implementation for DMContainer.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7450 Your paranoid android. === build (build) === Patch failed to apply

June 12, 2014

Re: msvcp90/msvcp90.h: right-hand operand of comma expression has no effect (PING)

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > On Wed, 16 Apr 2014, Paul Chitescu wrote: >>> 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); >>> ^ >> memcpy_s() returns an errno_t so the author tried to force returning >> zero (no error). > > Since, clearly, the result is never intended to be used, we can as > well simply cast the result away instead of using ", 0". memcpy_s is supposed to return a value, and callers could (and probably should) check it. -- Alexandre Julliard julliard(a)winehq.org

June 12, 2014

Re: services: Defer service delete until all handles are closed

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7438 Your paranoid android. === w7u (32 bit service) === service.c:1381: Test failed: Something wrong in the calculation service.c:1417: Test failed: Active services mismatch 1 The test timed out

June 11, 2014

Re: wined3d: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4 (try 4)

by Henri Verbeet

On 11 June 2014 21:00, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > On Fri, May 30, 2014 at 5:10 AM, Stefan Dösinger > Try 1 was commited [1] instead of try 4 [2], was that intentional? > > [1] http://source.winehq.org/git/wine.git/commitdiff/fbdf618251c7d9c3f01f53bc53… > [2] http://source.winehq.org/patches/data/104891 > Yeah.

June 11, 2014

Re: wined3d: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4 (try 4)

by Bruno Jesus

On Fri, May 30, 2014 at 5:10 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-05-30 00:45, schrieb Andrei Slăvoiu: >> Add back glsl check to make sure the card is capable of DX10. >> >> --- dlls/wined3d/directx.c | 4 +++- 1 file changed, 3 >> insertions(+), 1 deletion(-) > Looks good to me. Note that Alexandre and Henri are on holidays right > now, so it might take a while before it is committed or you receive > further comments. Try 1 was commited [1] instead of try 4 [2], was that intentional? [1] http://source.winehq.org/git/wine.git/commitdiff/fbdf618251c7d9c3f01f53bc53… [2] http://source.winehq.org/patches/data/104891 Best regards, Bruno

June 11, 2014

Re: [PATCH 4/5] ddraw: Properly support creating compressed user memory surfaces.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7433 Your paranoid android. === wvistau64 (64 bit ddraw7) === ddraw7.c:6467: Test failed: Test 7: Got unexpected pitch 252, expected 256. === w2008s64 (64 bit ddraw7) === ddraw7.c:6467: Test failed: Test 7: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw4) === ddraw4.c:6644: Test failed: Test 7: Got unexpected pitch 252, expected 256. === w2008s64 (64 bit ddraw4) === ddraw4.c:6644: Test failed: Test 7: Got unexpected pitch 252, expected 256.

June 11, 2014

Re: [PATCH 1/5] ddraw: Clear DDSD_LINEARSIZE on uncompressed surfaces.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7432 Your paranoid android. === wvistau64 (64 bit ddraw2) === ddraw2.c:5647: Test failed: Test 3: Got unexpected pitch 252, expected 256. ddraw2.c:5647: Test failed: Test 7: Got unexpected pitch 252, expected 256. === w2008s64 (64 bit ddraw2) === ddraw2.c:5647: Test failed: Test 3: Got unexpected pitch 252, expected 256. ddraw2.c:5647: Test failed: Test 7: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw1) === ddraw1.c:4571: Test failed: Test 3: Got unexpected pitch 252, expected 256. ddraw1.c:4571: Test failed: Test 7: Got unexpected pitch 252, expected 256. === w2008s64 (64 bit ddraw1) === ddraw1.c:4571: Test failed: Test 3: Got unexpected pitch 252, expected 256. ddraw1.c:4571: Test failed: Test 7: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw7) === ddraw7.c:6377: Test failed: Test 7: Got unexpected pitch 252, expected 256. === w2008s64 (64 bit ddraw7) === ddraw7.c:6377: Test failed: Test 7: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw4) === ddraw4.c:6554: Test failed: Test 7: Got unexpected pitch 252, expected 256. === w2008s64 (64 bit ddraw4) === ddraw4.c:6554: Test failed: Test 7: Got unexpected pitch 252, expected 256.

June 11, 2014

Re: Fix for PlgBlt, the XFORM matrix was calculated incorrectly

by Alexander Almaleh

Hi Michael, I just realized that it would be impossible to write an automated test for PlgBlt now, because Wine has a second, unrelated but, for which I already wrote another email to wine-devel. It's titled "BitBlt doesn't honor the rotation specified by SetWorldTransform". So even with my fixed PlgBlt, Wine's version would still not work correctly, until that second, unrelated bug is fix. That's why I submitted a Windows project where I compare my patched PlgBlt, and Wine's PlgBlt under Windows. Bearing that in mind, what is your advice? Bruno Jesus already wrote that he can confirm my code runs in Windows. Should I just explain how I reached the formula for the XFORM matrix? On Tue, May 27, 2014 at 11:40 PM, Alexander Almaleh <sashoalm(a)gmail.com> wrote: > Ok. Btw, I have some other things on my head now, so it might be a week or > two before I come back to this. > > > On Fri, May 23, 2014 at 1:35 AM, Michael Mc Donnell <michael(a)mcdonnell.dk> > wrote: > >> Hi Alexander >> >> On Thu, May 22, 2014 at 2:25 AM, Alexander Almaleh <sashoalm(a)gmail.com> >> wrote: >>> >>> OK, I'll try to write a unit test. I found this tutorial - >>> https://www.winehq.org/docs/winedev-guide/testing, is it the correct >>> thing to read? >>> >> >> Yes that is the correct thing to read. >> >> >>> You might be able to get your patch in without the automated test, >>>> but I think you need to explain clearly what was wrong with the old code >>>> and what you are doing instead. A few more simplified examples that test >>>> other cases in your bug report might also help. >>>> >>> >>> The trouble is I don't quite remember the exact steps I took 5 years ago >>> to come up with the new formula. However, I do remember I came up to it by >>> solving a system of linear equations. Since XFORM matrix is applied to each >>> point, I took 3-4 measurements of how points are transformed by PlgBlt, and >>> then used that to make equations of the type applyXFORM(xSrc) = xDest. By >>> solving the equations for the XFORM matrix, I came up with the correct >>> formula I need to get the XFORM matrix from the input variables. I used an >>> online linear equation solver, so there's no human error. >>> >>> I'll try to recreate the steps, maybe it'll be easier to just explain >>> them. I'll look into making automated tests, too. >>> >> >> Sounds good. Like you are saying, figuring out the formulas again would >> be a good idea. The current code does not explain where the formulas are >> coming from. Adding that as comments in your patch would make it easier to >> verify than the current code. >> >> Michael >> >> >

June 11, 2014

Re: Undocumented Function in WINE-API

by Austin English

On Tue, Jun 10, 2014 at 8:54 AM, Pit Demmer <Pit(a)lets.de> wrote: > > Hi! > > > > I´m a 47 year old German - programming BASIC, Assembler and sometime pure C since 1981. Please! NO discussion´s about my love - the VB and Power BASIC's... ;-) > > My newest project (It´s called LetsLOCO), is a "MultiIO-LongDistance-BusSystem for Logging and Controlling" over an electrical- and protocol-extended I2C-Bus which can adress standard I2C compatible IC´s, too. The fully Project is not only Software! I´ve made many HardWare, too. > > I want to make this Project free. Hardware fully free under a license similar to a GPL. The Software should be at first Freeware, but only for running under WINE! If somebody plan to use the Software outside WINE... I want some little money for it. > > And here is the problem... I need a function, which exist in the WINE-API but not in the Original Win-API´s. > > Can anyone from the WINE-Developers help me? Exist a little ‘dummy’-function in user32.dll, kernel32.dll, shell32.dll,... which have no similar function in the original Win-DLL´s? Any other 'safe' way to verify that my EXEs and DLLs running through WINE is welcome, too. > > > > Thanks! And sorry for my English! > > > > Pit > > > > > > Try ntdll.wine_get_version() -- -Austin

June 11, 2014

Undocumented Function in WINE-API

by Pit Demmer

Hi! I´m a 47 year old German - programming BASIC, Assembler and sometime pure C since 1981. Please! NO discussion´s about my love - the VB and Power BASIC's... ;-) My newest project (It´s called LetsLOCO), is a "MultiIO-LongDistance-BusSystem for Logging and Controlling" over an electrical- and protocol-extended I2C-Bus which can adress standard I2C compatible IC´s, too. The fully Project is not only Software! I´ve made many HardWare, too. I want to make this Project free. Hardware fully free under a license similar to a GPL. The Software should be at first Freeware, but only for running under WINE! If somebody plan to use the Software outside WINE... I want some little money for it. And here is the problem... I need a function, which exist in the WINE-API but not in the Original Win-API´s. Can anyone from the WINE-Developers help me? Exist a little 'dummy'-function in user32.dll, kernel32.dll, shell32.dll,... which have no similar function in the original Win-DLL´s? Any other 'safe' way to verify that my EXEs and DLLs running through WINE is welcome, too. Thanks! And sorry for my English! Pit

June 10, 2014

Re: gdi32: CLIP_DFA_DISABLE should disable the font association mechanism.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7430 Your paranoid android. === wvistau64 (32 bit font) === The test timed out === wvistau64 (64 bit font) === The test timed out

June 10, 2014

Re: ntdll: Use lockfree implementation for get_cached_fd. (try 3)

by Bruno Jesus

On Tue, Jun 10, 2014 at 12:08 AM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Thanks for all the feedback @ Ken, Daniel, Bruno and all the other > people I talked to. > > Changes in try 3: > > * Although the fd_cache_epoch was slightly faster in my tests (-> see > plots in mail for try 1) and should also work on PPC, its probably > better to choose a method which is easier to verify, and where we can be > sure, that it doesn't break with the next gcc release. ;) In this patch > I switched back to the old approach using interlocked_cmpxchg64 to > set/get both fd and associated attributes at the same time. > > * Although used in some other places, its probably better to avoid > assert() for stuff, which should never be optimized away. Just an update to my tests: http://influenza.blog.br/wine/testpatch3.pdf As expected it' slightly slower (Try 3 column), but still much better than the current implementation and still under windows 7 measures in my machine. Best wishes, Bruno

June 10, 2014

Re: [PATCH 6/6] wined3d: Do not warn about WINED3DUSAGE_WRITEONLY.

by Henri Verbeet

On 5 June 2014 12:32, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-06-04 19:21, schrieb Henri Verbeet: >> I could imagine buffers being moved from VRAM to GART when they're >> mapped, which would then make subsequent draws potentially slower. >> Dynamic buffers are more or less expected to be in GART, but we >> want static buffers to be in VRAM as much as possible. I could also >> perhaps imagine the driver keeping a copy in CPU memory instead, >> but that would then use up address space. > I guess those things are possible, but at the moment hypothetical. I > don't think we should keep printing the FIXME because of them. If we > print anything it would be better to write a FIXME if DYNAMIC is set, > but WRITEONLY isn't. > I suppose you could replace the current FIXME with some kind of d3d_perf WARN in buffer_init(). I'd still prefer benchmarking about the impact of the flag in various scenarios be done.

June 5, 2014

Re: [PATCH 6/6] wined3d: Do not warn about WINED3DUSAGE_WRITEONLY.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-06-04 19:21, schrieb Henri Verbeet: > I could imagine buffers being moved from VRAM to GART when they're > mapped, which would then make subsequent draws potentially slower. > Dynamic buffers are more or less expected to be in GART, but we > want static buffers to be in VRAM as much as possible. I could also > perhaps imagine the driver keeping a copy in CPU memory instead, > but that would then use up address space. I guess those things are possible, but at the moment hypothetical. I don't think we should keep printing the FIXME because of them. If we print anything it would be better to write a FIXME if DYNAMIC is set, but WRITEONLY isn't. (Yes, I am aware of some buffer handling performance problems on the Nvidia driver, but as far as I understand them they are not about VRAM vs GART placement, but about unneeded synchronization.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTkEdGAAoJEN0/YqbEcdMw2NwP/3Qd4GmbLHnqjM5UNiK1eXiB iOGlbKdGtLhRzaDC4uA7Ncc4/1GhWilDNPMq0ebWE5VqsZOcqqcefcHymoo2rG1x sMf85aVZEX+pq18rfaue2b3IXbS0mYtB9hQ1jzruszG3g8aKeMX95w7vG6OCT92h 0a0IOZ4+NPKoUm98S1qck1M4hpxNlpXsdThq40J/z0+dNcrU/7NDQypwNvmz7KEk qp/8a+86YGKVD5i3Cpj6qge5z1YMaaPbB9vEE40ypwndXRG8g0RMJkFUXOMlAVFV zZKwICGxKMKUSLN3Lczp+Sy4fME6nEqs3/BLYlIVKv2++6dYg6fEgxg7bU3r4+XF 4sVxC915CdLfPBEEUls97b94D/s6zt15cNLjvJ1MbuGuOgqz2MFmlQtKY4vV4rSh OC0MpGobGSSMDatfav47SyTJIXU6uljp3wXMFkwJyzcyz1rTbhF6NJMiYXzMSv4l SeU9Bcpc2WbpBjdOFyOsYqYp6kZufTdvpHi2TzuUc7J1JLupGFMfkERpO1kzru9B 23VGHIYg0n4vcYj4Om+iDBLYJxhJRYDvw/3p8PC9S/OsPyhSj5PFldukkNK3o5ua xbTdw5GraDkZ7xrls66QbBnNC9W4ZczTjLWHfjFe+pT/euI2tvMBjM9h3jNGQRzx UvslS/2Cn1+rfD6YfVuj =qyev -----END PGP SIGNATURE-----

June 5, 2014

Re: [PATCH try2] vbscript: Added support for exponental form of numeric literals.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7411 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

June 5, 2014

Re: vbscript: Added support for exponental form of numeric literals.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7409 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

June 5, 2014