- wine-devel - winehq.org

Re: mshtml: Implement IHTMLFrameBase_put_name()
by Jacek Caban 01 Oct '12

01 Oct '12

Hi Nikolay, On 09/30/12 20:36, Nikolay Sivov wrote: > http://bugs.winehq.org/show_bug.cgi?id=31835 The code may be simple and obvious, but I'd still like to see a test. A simple call should be enough just to make sure it's executed when I test new Gecko builds. Jacek

2 1

Re: [PATCH] rpcrt4: wait_async_request: return error if we received an error
by Jacek Caban 01 Oct '12

01 Oct '12

Hi Marcus, On 09/29/12 11:44, Marcus Meissner wrote: > Hi, > > Various coverity issues complain about user-after-free scenarios, > all involving this code path. > > I strongly think if call_ret signals error, we also need to return > an error condition to avoid the callers from proceeding as if nothing > happened. Agreed, thanks for catching it. > Ciao, Marcus > --- > dlls/rpcrt4/rpc_transport.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/rpcrt4/rpc_transport.c b/dlls/rpcrt4/rpc_transport.c > index 686ce68..e572b78 100644 > --- a/dlls/rpcrt4/rpc_transport.c > +++ b/dlls/rpcrt4/rpc_transport.c > @@ -1882,7 +1882,7 @@ static RPC_STATUS wait_async_request(RpcHttpAsyncData *async_data, BOOL call_ret > > if(call_ret) { > RpcHttpAsyncData_Release(async_data); > - return RPC_S_OK; > + return call_ret; /* The Http* status codes map into the RPC_S namespace */ Not really, Http* APIs return BOOL and GetLastError() call is needed to get error code. AFAIR, when I tested this code, most HTTP-related errors were translated to RPC_S_SERVER_UNAVAILABLE by rpcrt4. That may be a better choice here as well. Jacek

1 0

Re: d3dx9_36 [patch 2/5, try 4]: Speed-up some tests.
by Rico Schüller 01 Oct '12

01 Oct '12

On 01.10.2012 03:28, Nozomi Kodama wrote: > + for (order = 0; order <= D3DXSH_MAXORDER + 1 ; order++) Well, I'm not sure what you are doing with the spaces ... I say it again, if you got a comment, read it carefully take a look at your code and fix it. I mentioned white space issues a couple of times. And I think I mentioned the problem already ... I accidentally send it to wine-patches instead of wine-devel (sorry, this was my mistake): http://www.winehq.org/pipermail/wine-patches/2012-September/118230.html. Cheers Rico

1 0

Re: d3dx9_36 [patch 1/5, try 4]: Implement D3DXSHMultiply4
by Rico Schüller 01 Oct '12

01 Oct '12

On 01.10.2012 03:27, Nozomi Kodama wrote: > I used FLOAT * WINAPI, though I don't like it. Yeah, that's not much of an issue... and this is not the showstopper. > + TRACE("(out %p, a %p, b %p)\n", out, a, b); What I'm a bit curious about is, why do you reinvent a new style in a new patch (see http://www.winehq.org/pipermail/wine-devel/2012-September/097133.html and http://www.winehq.org/pipermail/wine-devel/2012-September/097131.html)? I'm not sure if my wording is that hard to understand. For me the preferred option for the TRACE is: "TRACE("out %p, a %p, b %p\n", out, a, b);" And the one also used in the file is: "TRACE("(%p, %p, %p)\n", out, a, b);" Please use exactly one of those. Not mixture, no extra brackets... Sorry, I should have written an answer to the (try 3), but I wasn't fast enough. Cheers Rico

1 0

Re: ws2_32: Fix TRACE format in WS_getsockname
by Dmitry Timoshkov 01 Oct '12

01 Oct '12

Bruno Jesus <00cpxxx(a)gmail.com> wrote: > @@ -2444,7 +2444,7 @@ int WINAPI WS_getsockname(SOCKET s, struct WS_sockaddr *name, int *namelen) > int fd; > int res; > > - TRACE("socket: %04lx, ptr %p, len %8x\n", s, name, *namelen); > + TRACE("socket: %04lx, ptr %p, len %08x\n", s, name, *namelen); > > /* Check if what we've received is valid. Should we use IsBadReadPtr? */ > if( (name == NULL) || (namelen == NULL) ) Taking into account check after the trace printing the contents of namelen should be replaced by printing its pointer. -- Dmitry.

1 0

Re: [PATCH 5/5] ntoskrnl.exe: Implement IoAllocateMdl.
by Dmitry Timoshkov 01 Oct '12

01 Oct '12

Christian Costa <titan.costa(a)gmail.com> wrote: > PMDL WINAPI IoAllocateMdl( PVOID VirtualAddress, ULONG Length, BOOLEAN SecondaryBuffer, BOOLEAN ChargeQuota, PIRP Irp ) > { > PMDL mdl; > + ULONG address = (ULONG)VirtualAddress; This won't work on 64-bit. > + mdl->StartVa = (PVOID)page_address; and this. > + mdl->ByteCount = Length; > + mdl->ByteOffset = address - page_address; Probably the type of size holding parameters/variables should be SIZE_T. -- Dmitry.

1 0

Re: dmusic: Fix a copy and paste error
by Christian Costa 29 Sep '12

29 Sep '12

Le 29/09/2012 17:11, Sven Baars a écrit : > This should fix http://bugs.winehq.org/show_bug.cgi?id=31805 > > Good catch !

1 0

Re: [PATCH] msi: Use next cabinet from the media table instead of failing when there is a mismatch with continuous cabinet.
by Hans Leidekker 29 Sep '12

29 Sep '12

On Thu, 2012-09-27 at 09:59 +0200, Christian Costa wrote: > diff --git a/dlls/msi/media.c b/dlls/msi/media.c > index 612624d..8a39fcd 100644 > --- a/dlls/msi/media.c > +++ b/dlls/msi/media.c > @@ -358,8 +358,18 @@ static INT_PTR cabinet_next_cabinet(FDINOTIFICATIONTYPE fdint, > > if (strcmpiW( mi->cabinet, cab )) > { > - ERR("Continuous cabinet does not match the next cabinet in the Media table\n"); > - goto done; > + LPSTR next_cab; > + > + WARN("Continuous cabinet %s does not match the next cabinet %s in the media table\n", debugstr_w(cab), debugstr_w(mi->cabinet)); > + > + /* Use cabinet name from the media table */ > + next_cab = strdupWtoA(mi->cabinet); > + /* Modify path to cabinet file with full filename (psz3 points to a 256 bytes buffer that can be modified contrary to psz1 and psz2) */ > + strcat(pfdin->psz3, "\\"); > + strcat(pfdin->psz3, next_cab); > + /* Path psz3 and cabinet psz1 are concatenated by FDI so just reset psz1 */ > + *pfdin->psz1 = 0; > + msi_free(next_cab); > } > > if (!(cabinet_file = get_cabinet_filename(mi))) The requirement that the continuous cabinet name matches the next cabinet in the media table might simply be too strict. Perhaps we need to try them one by one and let FDI decide based on the setID and iCabinet fields. Can you please add some tests?

2 3

Re: [PATCH] wined3d: move texture reference decrement to end of usage (Coverity)
by Henri Verbeet 29 Sep '12

29 Sep '12

On 29 September 2012 11:14, Marcus Meissner <marcus(a)jet.franken.de> wrote: > Hi, > > I do not fully understand all this, but it seem the decref needs to > be behind the last usage of prev. > Sort of. It's probably better to do it like this, but a non-zero bind_count implies a non-zero reference count as well, so in practice there's no danger of using prev after it's free'd.

1 0

Fwd: CIA going down: KGB wants your commits!
by Austin English 29 Sep '12

29 Sep '12

-- -Austin ---------- Forwarded message ---------- From: Martín Ferrari <martin.ferrari(a)gmail.com> Date: Thu, Sep 27, 2012 at 3:52 PM Subject: CIA going down: KGB wants your commits! To: debian-project(a)lists.debian.org, Debian Developers <debian-devel(a)lists.debian.org> Hi there! Not to "to knock 'em when they're down", but since it seems that the CIA.vc service has officially closed recently (cannot find exactly when did that happen), I think it's worthwhile offering this little project we (dam@, gregoa@, and me) have since a few years ago, called KGB (ha-ha). It's a very simple and dumb client-server architecture: IRC bots running in our personal servers listen for SOAP messages sent by kgb-clients called from post-commit hooks in repos out there. The bot just relays and formats a message, nothing fancier than that. So, if you're looking for a simple IRC notification of your commits, this might be of help. You can either run your own bot (debian package kgb-bot), or use ours. As for the client, alioth does not have it installed, but you can run it off /home/groups/kgb. There's a sample configuration there too. In /home/groups/pkg-perl/meta/pkg-perl-post-receive you can see how to use it from a post-commit hook. If you rather use our bots, we'll need you to provide: a project/repository name, an IRC channel, and a password (used to avoid spam, not really secure). -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/CAL60Pd_7zoPk4w4rta49-jymxzKOU+K7DdqZUiqsP32KZ9bQBA…

3 2

Re: comctl32: use GetWindowLong to check for scrollbar (try 2)
by Nikolay Sivov 28 Sep '12

28 Sep '12

On 9/28/2012 20:43, Daniel Jelinski wrote: > Corrected from first try: > - uses GetWindowLong instead of GetWindowLongPtr > - does not touch dwStyle Sorry, was busy to reply earlier. I think this fix is ok if it really helps, thanks for working on this.

1 0

Re: [PATCH] configure: use -Wp, -D_FORTIFY_SOURCE=0 instead of -D_FORTIFY_SOURCE=0
by Alexandre Julliard 28 Sep '12

28 Sep '12

Anssi Hannula <anssi.hannula(a)iki.fi> writes: > Some Linux distributions (at least Mageia) build packages with > -Wp,-D_FORTIFY_SOURCE=2 by default. There is a check in configure which > checks for enabled fortify and adds "-U_FORTIFY_SOURCE > -D_FORTIFY_SOURCE=0". Unfortunately, -Wp,-Dfoo are applied after -Dfoo, > so the added flags fail to override the fortify in the CFLAGS. I would say that's a distro bug. Defaulting to Fortify is already broken enough, but making it even harder to disable is stupid. I don't think we want to get into that kind of arms race. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: gdiplus: Reuse an existing image stream in GdipImageSelectActiveFrame. Take 2.
by Vincent Povirk 28 Sep '12

28 Sep '12

Looks good, thanks.

1 0

Re: [PATCH 2/2] vbscript: Added MonthName implementation
by Marvin 28 Sep '12

28 Sep '12

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 http://testbot.winehq.org/JobDetails.pl?Key=21880 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: gdi32: Fixed freetype working function
by Alexandre Julliard 28 Sep '12

28 Sep '12

Сергей Мосин <svmosin(a)gmail.com> writes: > The function WineEngAddFontMemResourceEx in gdi32/fretype.c contained > strange XOR operation with some random number 0x87654321, instead of > returning the real font handle. Do you have an app that depends on this? What does it do with the handle? -- Alexandre Julliard julliard(a)winehq.org

1 0

is CreateThread(CREATE_SUSPENDED) fully functional?
by Joerg-Cyril.Hoehle＠t-systems.com 27 Sep '12

27 Sep '12

Hi, Recently I thought I found a use-case for CreateThread(CREATE_SUSPENDED). The idiom is to get the thread handle before the thread starts a life on its own. I looked at the kernel tests, http://source.winehq.org/source/dlls/kernel32/tests/thread.c#L460 However, both invocations with CREATE_SUSPENDED actually test the pair CreateThread + SuspendThread. The tests do not prove that CREATE_SUSPENDED works! They only prove that the suspend counter and perhaps SuspendThread work. a) Does Wine not support CREATE_SUSPENDED, so that the tests do the best they can? In such a case, a WARN("ignoring SUSPENDED flag, beware of race conditions\n") would be appropriate. or b) CREATE_SUSPENDED is fully supported on all platforms. Then the tests need some refinement. Thank you, Jörg Höhle

3 2

Re: [1/3] gdiplus: Move font substitution test into a separate body.
by Vincent Povirk 27 Sep '12

27 Sep '12

The series looks good to me. Very cool to have a fix for this.

1 0

Re: gdiplus: Reuse an existing image stream in GdipImageSelectActiveFrame.
by Vincent Povirk 27 Sep '12

27 Sep '12

> @@ -3898,7 +3894,7 @@ GpStatus WINGDIPAPI GdipImageSelectActiveFrame(GpImage *image, GDIPCONST GUID *d > return Ok; > } > > - IStream_Release(stream); > + IStream_Release(image->stream); > return stat; > } I don't think it's necessary to AddRef/Release the stream anymore in GdipImageSelectActiveFrame. Creating the new image and freeing the old one will update the refcount as necessary. And it's a bit confusing since technically the current image->stream is released by free_image_data then overwritten (with the same value, fortunately) by copying new_image to image. Looks good otherwise.

1 0

'sort' implementation (Bug 27933) - any easy way?
by Ann and Jason Edmeades 27 Sep '12

27 Sep '12

Hello, While working on more of the 'for' processing in the command shell, I've come across a stumbling block that wildcard expansion 'ordering' is not guaranteed (findfirst/findnext) meaning I cannot automate tests for some of the key bits - this is frustrating as we really need tests for the things I'm looking at as the code is getting complex. Looking in the cmd testsuite, there's already some commented out tests as well, saying we really need a 'sort' implementation, and that would also resolve the problem I have at the moment. Therefore, I'd like to know if there's any simple way to implement a command line sort program which we can call from the command shell. This has subsequently been raised as bug 27933. My first thought was to avoid reinventing the wheel and to have a windows program called sort which parses its parameters and then runs the Unix 'sort' command with an equivalent command line. I think most of the windows command line parameters have Unix equivalents, and for the majority of cases it would be a case of transposing a windows path to a Unix path, and just running the Unix sort. However, I then started to get concerned about stdin / stdout... Is there any way to take the windows stdin and 'connect it' to the unix program you spawn, and vica-versa for the stdout. Whilst I dont accurately need this for the testsuite, without it the wine implementation would not match the windows one. So I think my specific questions are... 1. Is wrappering an existing (Linux) 'sort' program an option for this, or do we really need a whole unique implementation of sort (which I would have no idea how to write!)? If it is an option, the two key questions I have are: 2. How do I handle stdin / stdout, so sort can work in pipes / redirects 3. Is it ok to use wine_get_unix_file_name to convert files and directories to the unix equivalents when building the unix equivalent command line? (as per winepath) Thanks. Jason

1 0

Re: d3dx9_36 [patch 6/6]: Implement D3DXSHEvalHemisphereLight
by Rico Schüller 27 Sep '12

27 Sep '12

Well I think, if you rework a series, please add something like try xyz or so ... Also try to avoid to add / remove some patches, at least if they actually don't have anything todo with the rest of the patch set (if they could be submitted on their own). On 27.09.2012 10:00, Nozomi Kodama wrote: > + TRACE("%u, %p, %p, %p, %p, %p, %p\n", order, dir, &top, &bottom, rout, gout, bout); Sure, that's an other form of the trace. I think we hadn't one with such a version... other traces in the file look like (the one marked with * is my preferred version): TRACE("out %p, order %u, a %p, b %p\n", out, order, a, b); * TRACE("(%p, %p, %u)\n", pout, pin, n); I don't think it makes much sense to print the address for &top. It doesn't gather some useful information, does it? Instead you may print the actual content for r,g,b if you like. > + if ( gout ) Also here, I prefer "if (gout)" ... I know there are several occurrences for the other style ... I should have mentioned that earlier ... it's not something which is critical... git grep "if (" dlls/d3dx9_36/* | wc -l reveals ~2000 while git grep "if ( " dlls/d3dx9_36/* | wc -l does ~100 > + ok(relative_error(expected, blue_out[j]) < admitted_error, > + "Blue: case %u, order %u: expected[%u] = %f, received %f \n", l, order, j, expected, blue_out[j]); Please indent 8 instead of 2 spaces when a new line is used ... Cheers Rico

1 0

dsound: Don't bother shrinking the secondary buffer list.
by Joerg-Cyril.Hoehle＠t-systems.com 27 Sep '12

27 Sep '12

Michael, >+#include <assert.h> your patch is already committed, yet I believe that the least that dsound needs is new asserts. Asserts in dsound have been a PITA in Wine for the last decade. It's ok for the kernel to crash in an assert. IMHO it is not ok for an optional thing like sound. The assert's backtrace will not help anybody, because the logical error will have happened much earlier. Instead, a plain ERR would have been just as telling. Let's quote http://www.winehq.org/docs/winedev-guide/debugging#DBG-CLASSES "ERR: Messages in this class indicate serious errors in Wine, such as as conditions that should never happen by design." I recommend: - assert(device->buffers[0] == pDSB); + if (pdevice->buffers[0] != pDSB) + ERR("broken device buffer %p\n", device->buffers[0]); HeapFree(GetProcessHeap(), 0, device->buffers); device->buffers = NULL; The ERR is IMHO revealing enough in a user's log. If a sound component detects a bogus state, I'd very much prefer that it disables sound -- without crashing. Regards, Jörg Höhle

2 1

Re: d3dx9_36 [patch 1/6]: Implement D3DXSHMultiply4
by Rico Schüller 27 Sep '12

27 Sep '12

On 27.09.2012 09:56, Nozomi Kodama wrote: > +FLOAT* WINAPI D3DXSHMultiply4(FLOAT *out, CONST FLOAT *a, CONST FLOAT *b) FLOAT * WINAPI D3DXSHMultiply4(FLOAT *out, const FLOAT *a, const FLOAT *b) A minor nitpick, anyone against something like? I think that was what Matteo meant in http://www.winehq.org/pipermail/wine-devel/2012-September/096924.html with "Fix the FLOAT*"? > + TRACE("(%p, %p, %p)\n", out, a, b); I would probably prefer: TRACE("out %p, a %p, b %p\n", out, a, b); I know the other Multiply functions and so on use your trace format... > + out[0] = 0.28209479f * a[0] * b[0]; There are still double spaces ... Hint: it's not the only occurrence. Cheers Rico

1 0

Re: d3dx9_36 [patch 2/6]: Speed-up some tests
by Rico Schüller 27 Sep '12

27 Sep '12

On 27.09.2012 09:57, Nozomi Kodama wrote: > - FLOAT a[64], b[64], got; > + FLOAT a[49], b[49], got; > CONST FLOAT expected[] = > { 0.5f, 0.5f, 25.0f, 262.5f, 1428.0f, 5362.0f, 15873.0f, 39812.0f, 88400.0f, }; > > - for (i = 0; i < 64; i++) > + for (i = 0; i < 49; i++) > > - for (i = 0; i < 9; i++) > + for (i = 0; i <= D3DXSH_MAXORDER + 1; i++) Again: You may correct the (array) size for the expected value ... If we run til element 7 instead of 8, I think the last element could be thrown away? Cheers Rico

1 0

Re : d3dx9 [patch 1/5]: Implement D3DXSHMultiply4
by Nozomi Kodama 26 Sep '12

26 Sep '12

>On 26.09.2012 12:17, Nozomi Kodama wrote: >> + ta =0.28209479f * a[0]+ 0.14567312f * a[8]+ 0.12615663f * a[6]; >> + tb =0.28209479f * b[0]+ 0.14567312f * b[8]+ 0.12615663f * b[6]; >> + out[13] += ta * b[13] + tb * a[13]; <> + t = a[13] * b[13]; >> + out[0] +=0.28209479f *t; >Please use spaces with care. >The preferred way is "x = 123 * a[0] + 456 * b[234]; Mostly one space is enough, only use two or more if >you like to indent something, that's mostly not the case when calculating a value. Even then, please be >consistent across your patch. oops!!! I will take care of this one. >> + D3DXSHMultiply4(c, a, b); >>What happens if you use something like D3DXSHMultiply4(c, c, c). Is that allowed? Tests in native show that D3DXSHMultiply gives what I implemented. We can not reuse a input variable as output (we don't obtain what we expect logically). >Also is there a reason why it uses slightly different values than e.g. D3DXSHMultiply3? Why don't we >use defines? A problem might be to find good names... Maybe the Multiply functions could share the >same base? To me it looks like they do share a lot of calculations, And if the order doesn't matter (see >comment above) then it may be possible to rearrange the calculation. > >ta = 0.28209479f * a[0] - 0.12615663f * a[6] - 0.21850969f * a[8]; >vs >ta = 0.28209479f * a[0] - 0.12615662f * a[6] - 0.21850968f * a[8]; I do the computations with a formal computation software. Unfortunately I did not use the same for D3DXSHMultiply4 and D3DXSHMultiply3 ..... (Xcas vs Maple). And obtain the exact values look beyond the capacities of these softwares. And even the worst, since the integrated functions oscillate, the internal algorithm of the software are not robust to compute the integrals. For a given number of significative digits, that's why we obtain slightly different values for the both softwares. Addind defines will add tons on variables for no gain. But I can simplify slightly the function by calling D3DXSHMultiply3. I will give it a try. I worry about efficiency. Best regards Nozomi >Cheers >Rico

2 1

Re: oledb32: Add support for IDBInitialize interface in IDataInitialize
by Alexandre Julliard 26 Sep '12

26 Sep '12

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Changelog: > oledb32: Add support for IDBInitialize interface in IDataInitialize It doesn't work here: ../../../tools/runtest -q -P wine -M oledb32.dll -T ../../.. -p oledb32_test.exe.so database.c && touch database.ok database.c:43: Test failed: Unable to load oledb library make[1]: *** [database.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: (try 3) imm32: there is only 1 default Hwnd per thread
by Alexandre Julliard 26 Sep '12

26 Sep '12

Aric Stewart <aric(a)codeweavers.com> writes: > - if (data->imeWnd == NULL) > + if (defWnd == NULL) > { > /* create the ime window */ > - data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, > + defWnd = CreateWindowExW( WS_EX_TOOLWINDOW, > data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, 1, 1, 0, > 0, data->immKbd->hIME, 0); > - SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); > - IMM_GetThreadData()->hwndDefault = data->imeWnd; > + SetWindowLongPtrW(defWnd, IMMGWL_IMC, (LONG_PTR)data); > + IMM_GetThreadData()->hwndDefault = defWnd; So now, shouldn't you be resetting IMMGWL_IMC at some point? -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: (resend) imm32: there is only 1 default Hwnd per thread
by Alexandre Julliard 26 Sep '12

26 Sep '12

Aric Stewart <aric(a)codeweavers.com> writes: > This corrects issues with applications that create and manage multiple IMCs > try 2: > avoid premature destruction of the window > --- > dlls/imm32/imm.c | 22 ++++++++++++---------- > dlls/imm32/tests/imm32.c | 28 ++++++++++++++++++++++++++++ > 2 files changed, 40 insertions(+), 10 deletions(-) > > > > diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c > index 7394101..a18aa26 100644 > --- a/dlls/imm32/imm.c > +++ b/dlls/imm32/imm.c > @@ -678,10 +678,6 @@ static BOOL IMM_DestroyContext(HIMC hIMC) > data->immKbd->pImeSelect(hIMC, FALSE); > SendMessageW(data->IMC.hWnd, WM_IME_SELECT, FALSE, (LPARAM)GetKeyboardLayout(0)); > > - if (IMM_GetThreadData()->hwndDefault == data->imeWnd) > - IMM_GetThreadData()->hwndDefault = NULL; > - DestroyWindow(data->imeWnd); > - > ImmDestroyIMCC(data->IMC.hCompStr); > ImmDestroyIMCC(data->IMC.hCandInfo); > ImmDestroyIMCC(data->IMC.hGuideLine); > @@ -2323,12 +2319,18 @@ BOOL WINAPI ImmSetOpenStatus(HIMC hIMC, BOOL fOpen) > > if (data->imeWnd == NULL) > { > - /* create the ime window */ > - data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, > - data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, 1, 1, 0, > - 0, data->immKbd->hIME, 0); > - SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); > - IMM_GetThreadData()->hwndDefault = data->imeWnd; > + HWND def = IMM_GetThreadData()->hwndDefault; > + if (def == NULL) > + { > + /* create the ime window */ > + data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, > + data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, 1, 1, 0, > + 0, data->immKbd->hIME, 0); > + SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); > + IMM_GetThreadData()->hwndDefault = data->imeWnd; > + } > + else > + data->imeWnd = def; So why is there a window in the IMC at all, if it's not used for anything? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 2/8] vbscript: Added VT_R8 support to to_int
by Marvin 26 Sep '12

26 Sep '12

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 http://testbot.winehq.org/JobDetails.pl?Key=21824 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/8] vbscript: Added Round implementation
by Marvin 26 Sep '12

26 Sep '12

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 http://testbot.winehq.org/JobDetails.pl?Key=21823 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: d3dx9 [patch 1/5]: Implement D3DXSHMultiply4
by Rico Schüller 26 Sep '12

26 Sep '12

On 26.09.2012 12:17, Nozomi Kodama wrote: > + ta =0.28209479f * a[0]+ 0.14567312f * a[8]+ 0.12615663f * a[6]; > + tb =0.28209479f * b[0]+ 0.14567312f * b[8]+ 0.12615663f * b[6]; > + out[13] += ta * b[13] + tb * a[13]; > + t = a[13] * b[13]; > + out[0] +=0.28209479f *t; Please use spaces with care. The preferred way is "x = 123 * a[0] + 456 * b[234]; Mostly one space is enough, only use two or more if you like to indent something, that's mostly not the case when calculating a value. Even then, please be consistent across your patch. > + D3DXSHMultiply4(c, a, b); What happens if you use something like D3DXSHMultiply4(c, c, c). Is that allowed? Also is there a reason why it uses slightly different values than e.g. D3DXSHMultiply3? Why don't we use defines? A problem might be to find good names... Maybe the Multiply functions could share the same base? To me it looks like they do share a lot of calculations, And if the order doesn't matter (see comment above) then it may be possible to rearrange the calculation. ta = 0.28209479f * a[0] - 0.12615663f * a[6] - 0.21850969f * a[8]; vs ta = 0.28209479f * a[0] - 0.12615662f * a[6] - 0.21850968f * a[8]; Cheers Rico

1 0

Re: winspool/tests: Don't crash when AddJob/GetJob fails (win8)
by Marvin 25 Sep '12

25 Sep '12

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 http://testbot.winehq.org/JobDetails.pl?Key=21799 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Wine Mono 0.0.6 Release - Because hey, why not?
by Vincent Povirk 25 Sep '12

25 Sep '12

I have published version 0.0.6 of Wine Mono on Sourceforge, because it's probably not good to let it get too stale. The source tarball is at http://sourceforge.net/projects/wine/files/Wine%20Mono/0.0.6/wine-mono-0.0.… The binary is at http://sourceforge.net/projects/wine/files/Wine%20Mono/0.0.6/wine-mono-0.0.… For developers, the source repository is at https://github.com/madewokherd/wine-mono Changes since 0.0.4: * Updated the visual basic class libraries from upstream. * Updated mono from 2.11.1 to 2.11.4. Unfortunately, there wasn't a nice changelog like 2.11.1 had. Here are some highlights: * Beginnings of support for hosting ActiveX controls inside winforms. (Alistair Leslie-Hughes) * Various HttpClient-related fixes. (Martin Baulig) * "Intermediate" state check boxes now rendered in winforms. (Steven Boswell II) * ACL support on Windows. (James Bellinger) * One can now specify WINE_MONO_TRACE=wrapper to log all transitions between native and managed code, which is sort of the Mono equivalent of a relay log. * RVA fields can now be accessed properly via the ldsfld[a] instruction. This should help with Managed C++ support. * Fix for winehq bug 30947 - Mono would cause a hang when a dll is loaded after Mono is loaded but before it is used to run any .NET code. * Because of a problem with the build system, MonoPosixHelper.dll was not present, and this prevented some builtin methods in Mono from working correctly. This has been resolved. * Added hashes for all included files in the msi package, which is needed for msi to replace the files on upgrade. * Added 64-bit registry entries to the msi package.

1 1

Re: imm32: there is only 1 default Hwnd per thread
by Alexandre Julliard 25 Sep '12

25 Sep '12

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -2323,12 +2323,18 @@ BOOL WINAPI ImmSetOpenStatus(HIMC hIMC, BOOL fOpen) > > if (data->imeWnd == NULL) > { > - /* create the ime window */ > - data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, > - data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, 1, 1, 0, > - 0, data->immKbd->hIME, 0); > - SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); > - IMM_GetThreadData()->hwndDefault = data->imeWnd; > + HWND def = IMM_GetThreadData()->hwndDefault; > + if (def == NULL) > + { > + /* create the ime window */ > + data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, > + data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, 1, 1, 0, > + 0, data->immKbd->hIME, 0); > + SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); > + IMM_GetThreadData()->hwndDefault = data->imeWnd; > + } > + else > + data->imeWnd = def; So what happens to the window if the first IMC is destroyed? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] iphlpapi: Set DhcpEnabled to TRUE for all interfaces.
by Juan Lang 25 Sep '12

25 Sep '12

Hi Qian, > There is a winpcap based network authentication client which check for the DhcpEnabled value, this patch make the app happy and then the app works with André's pcap wrapper [1]. > > Please let me know if this is acceptable, or we have to correctly implement DhcpEnabled status? I think this is fine, but you'd want to remove/fix some outdated comments I wrote at the same time: * NOTES * Since GetAdaptersInfo never returns adapters that have DHCP enabled, * this function does nothing. * * FIXME * Stub, returns ERROR_NOT_SUPPORTED. */ DWORD WINAPI IpReleaseAddress(PIP_ADAPTER_INDEX_MAP AdapterInfo) { TRACE("AdapterInfo %p\n", AdapterInfo); /* not a stub, never going to support this (and I never mark an adapter as DHCP enabled, see GetAdaptersInfo, so this should never get called) */ The same comments are in IpRenewAddress. Historical reason: when I wrote iphlpapi's first implementation, I had recently been working on a Windows app that released and renewed IP addresses on DHCP-enabled interfaces, because Windows at the time was pretty poor at doing so in response to changes to wireless connection state. I figured I wouldn't be the only one to have had to work around this issue, so I didn't want to have to implement IpReleaseAddress and IpRenewAddress in Wine. That was almost 10 years ago now, so these reasons no longer apply. I'm pretty sure the app I wrote isn't in use any longer, and even if it is, it isn't in use on Wine (I also wrote a Linux version.) Thanks, --Juan

3 2

Re: vbscript: Added Space() implementation
by Marvin 25 Sep '12

25 Sep '12

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 http://testbot.winehq.org/JobDetails.pl?Key=21787 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/2] mshtml: Added DISPATCH_PROPERTYGET|DISPATCH_METHOD flags support for elements exposed as window properties
by Marvin 25 Sep '12

25 Sep '12

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 http://testbot.winehq.org/JobDetails.pl?Key=21785 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: shlwapi: PathCreateFromUrlA() should not crash when given NULL buffers.
by Alexandre Julliard 25 Sep '12

25 Sep '12

Francois Gouget <fgouget(a)codeweavers.com> writes: > Add NULL and insufficient buffer tests for PathCreateFromUrl(). > --- > dlls/shlwapi/path.c | 3 +++ > dlls/shlwapi/tests/path.c | 49 +++++++++++++++++++++++++++++---------------- > 2 files changed, 35 insertions(+), 17 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M shlwapi.dll -T ../../.. -p shlwapi_test.exe.so path.c && touch path.ok path.c:322: Test succeeded inside todo block: got len = 22 expected 22 from url file:///localhost/c:/foo/bar path.c:322: Test succeeded inside todo block: got len = 19 expected 19 from url file://host//c:/foo/bar make: *** [path.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oledb32: Add support for IDBInitialize interface in IDataInitialize
by Marvin 25 Sep '12

25 Sep '12

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 http://testbot.winehq.org/JobDetails.pl?Key=21782 Your paranoid android. === WNT4WSSP6 (32 bit marshal) === marshal.c:66: Test failed: CoMarshalInterface failed with error 0x80040155 marshal.c:239: Test failed: "CoUnmarshalInterface" failed with error 0x8003001e marshal: unhandled exception c0000005 at 004165D0

2 1

Re: [5/6] start: Support getting the file to open by AppleEvent. (resend)
by Per Johansson 25 Sep '12

25 Sep '12

Hi, I should probably add a note that when I wrote this I had some doubts it it belongs in start.exe, and I still somewhat do. The alternative would be to write a new program. The advantage to that is: 1. start.exe is left more similar to it's windows counterpart. 2. This other program could handle multiple files sent in the same AppleEvent, which is possible. 3. The same program could also act as a proxy for a dock icon, handling clicks and activating windows (this is a later project). I'd imagine it'd be called winehostproxy or somesuch and handle several types of interaction with the host (is that what we call it btw?). If you think that's more appropriate I can work on that instead of adding this to start. Regards, -- Per Johansson 2012/9/23 Per Johansson <pelle(a)morth.org> >

2 2

Re: [5/5] dxgi/tests: Test some reference counts.
by Alexandre Julliard 25 Sep '12

25 Sep '12

Ričardas Barkauskas <rbarkauskas(a)codeweavers.com> writes: > --- > dlls/dxgi/tests/device.c | 69 > ++++++++++++++++++++++++++++++++++------------ > 1 file changed, 51 insertions(+), 18 deletions(-) In general testing reference count values is not useful, unless you have an app that depends on it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Spam applications for testbot accounts
by Scott Ritchie 25 Sep '12

25 Sep '12

Never underestimate the overeagerness of bots, I suppose... We're getting a lot of spam applications for testbot accounts now, maybe 2-3 per day. Some are easy to discard because they put stuff like penis pills into the info field, but others look like just names. Suggestions are welcome. In the meantime it would be nice if anyone requesting a legit account put some sort of non-spammy text in there like "Hey I'm a human I read wine-devel"

2 1

Overriding the check for ownership of a prefix
by Joerg-Cyril.Hoehle＠t-systems.com 25 Sep '12

25 Sep '12

Scott, I don't think you need to override this check, esp. given that there's a good reason for it being there: >Note that there is a problem with this setup if the app modifies the >registry and we then need to update the prefix-default registry I've excellent experience with symbolic links. In fact, none of the apps (games) I use are installed directly within any .wine prefix. Drive_c/Program Files/Games is a symbolic link to a large partition. >Imagine a distro package containing a Windows game in the form of a >read-only copy of an installed prefix (into, say, /opt). So I recommend the following setup: - Have the game's main directory be something like /opt/games/XYZ in UNIX, but tell it to install to C:\games/XYZ - During installation, write down all registry keys that the app creates and every file that it stores outside of its local directory. Beware: the name of the directory C:\Program.. depends upon every user's locale at .wine creation time! Use C:\Games\ instead to avoid that pitfall. For every user: - After .wine is created normally, add a symlink from Drive_c/Games to /opt/games - Add registry keys or dlls needed by the app. wineprefixcreate ln -s /opt/games/XYZ $HOME/.wine/drive_c/games cp -p whatever.dll $HOME/.wine/drive_c/windows/system32/ wine regedit xyz.reg Trivial, isn't it? Typically, you don't need to recreate the content of user-local APPDATA directories. The app will create them upon each run, since they ought to run with different users on one machine. Caveat: Although my .wine and games directories are distinct, I've no experience with write-protecting the games partition. Obviously, this only has a chance to work with modern apps, written after MS started recommending separating the app's dir from its per-local configuration files to be since stored in ~/LOCALAPPDATA or the like. Thus w9x/w2k-era games are ruled out. Still, I don't know where those apps attempt to store e.g. crash logs. I've seen apps write high-scores or savegames to their central directory when w2k was set in winecfg, and use HKCU/LOCALAPPDATA (what's the exact name?) when running in xp mode. I've made excellent experience with plenty of apps sharing a single .wine-games prefix with such a setup. I.e. you don't need one prefix per app. Like on a real box, the apps ought to be able to coexist. Drawback: when I was initially attracted to Wine 5 years ago, every .wine was a tiny 3-4MB. Nowadays it's more than 10 times that size, and I'm not happy with that. Using a single onion-union-fs to share drive_c/xyz may be interesting -- for as long as one single version of Wine is in use. Regards, Jörg Höhle

2 1

d3dx9: Implement D3DXSHEvalDirectionalLight
by Nozomi Kodama 24 Sep '12

24 Sep '12

Hello, do it remain problems with this patch? Nozomi

1 0

Re: [PATCH] dmusic: Add master clock tests.
by Andrew Eikum 24 Sep '12

24 Sep '12

On Sun, Sep 23, 2012 at 08:44:59PM +0200, Christian Costa wrote: > @@ -66,6 +68,11 @@ static void test_dmusic(void) > return; > } > > + hr = IDirectMusic_GetMasterClock(dmusic, &guid_clock, &clock); > + ok(hr == S_OK, "IDirectMusic_GetMasterClock returned: %x\n", hr); > + ok(clock != NULL, "No clock returned\n"); > + trace(" guidPort = %s\n", debugstr_guid(&guid_clock)); > + Minor nit-pick: you never release the clock.

1 0

Re: [PATCH 2/2] mshtml: Added function overriding tests
by Marvin 24 Sep '12

24 Sep '12

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 http://testbot.winehq.org/JobDetails.pl?Key=21757 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/2] jscript: Added support for limit argument in String.split
by Marvin 24 Sep '12

24 Sep '12

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 http://testbot.winehq.org/JobDetails.pl?Key=21756 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: Assorted spelling fixes.
by Julian Rüger 24 Sep '12

24 Sep '12

Hi Francois, > - /* if we set the bufferpointer to NULL here UrlUnescape fails and string gets not converted */ > + /* if we set the buffer pointer to NULL here UrlUnescape fails and the string is not converted */ for consistency with the other buffer pointer comments and better readability, I suggest you add a comma here: + /* if we set the buffer pointer to NULL here, UrlUnescape fails and the string is not converted */ Best regards, Julian

1 0

Re: [PATCH 4/4] mshtml: Added IHTMLElement::contains implementation
by Marvin 24 Sep '12

24 Sep '12

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 http://testbot.winehq.org/JobDetails.pl?Key=21753 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 2/4] mshtml: Added function overriding tests
by Marvin 24 Sep '12

24 Sep '12

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 http://testbot.winehq.org/JobDetails.pl?Key=21751 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

RFC: Locale-independent case-insensitive string comparison
by Francois Gouget 24 Sep '12

24 Sep '12

diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c index 28f82a3..f465ad7 100644 --- a/dlls/wininet/http.c +++ b/dlls/wininet/http.c @@ -640,7 +640,7 @@ static void HTTP_FixURL(http_request_t *request) } } - if(CSTR_EQUAL != CompareStringW( LOCALE_SYSTEM_DEFAULT, NORM_IGNORECASE, + if(CSTR_EQUAL != CompareStringW( LOCALE_INVARIANT, NORM_IGNORECASE, request->path, strlenW(request->path), szHttp, strlenW(szHttp) ) && request->path[0] != '/') /* not an absolute path ?? --> fix it !! */ { In this code snippet it feels wrong to have this string comparison depend on the system locale, which in Wine's case would come from the user's Unix locale. Isn't this a case where LOCALE_INVARIANT would be better? However I have not found a case where this makes a difference anyway, either with 'http:' or with 'file:'. That is, 'file:' always matches 'FILE:', even in Turkish, as long as I don't use NORM_LINGUISTIC_CASING. Conversely, 'fîle:' is different from 'FILE:' no matter what. Once I have a CompareString() test-case I can make some for UrlIs(), PathCreateFormURL(), possibly ShellExecute(), etc. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel