- wine-devel - winehq.org

Re: [PATCH 3/3] hhctrl.ocx: Resize the window when HH_SET_WIN_TYPE is called (try 3, resend 2).
by Alexandre Julliard 05 Sep '12

05 Sep '12

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > @@ -266,7 +266,7 @@ void MergeChmProperties(HH_WINTYPEW *src, HHInfo *info) > if (merge & HHWIN_PARAM_PROPERTIES) dst->fsWinProperties = src->fsWinProperties; > if (merge & HHWIN_PARAM_STYLES) dst->dwStyles = src->dwStyles; > if (merge & HHWIN_PARAM_EXSTYLES) dst->dwExStyles = src->dwExStyles; > - if (merge & HHWIN_PARAM_RECT) dst->rcWindowPos = src->rcWindowPos; > + if (merge & HHWIN_PARAM_RECT || override) dst->rcWindowPos = src->rcWindowPos; > if (merge & HHWIN_PARAM_NAV_WIDTH) dst->iNavWidth = src->iNavWidth; > if (merge & HHWIN_PARAM_SHOWSTATE) dst->nShowState = src->nShowState; > if (merge & HHWIN_PARAM_INFOTYPES) dst->paInfoTypes = src->paInfoTypes; You still need to check the source flags. -- Alexandre Julliard julliard(a)winehq.org

1 0

Building winetest-latest.exe?
by Dan Kegel 05 Sep '12

05 Sep '12

Hi folks, how does one build the native version of winetest.exe? I looked around a bit, and didn't see any obvious instructions. http://www.winehq.org/pipermail/wine-devel/2011-July/091144.html touches on it, but doesn't say much. I ask because I'm interested in tracking down why testbot doesn't think vcomp.dll is installed. ( cf. http://www.winehq.org/pipermail/wine-devel/2012-August/096642.html ) - Dan

5 7

Re: d3dx9_36 [try 4 ]: Implement D3DXSHRotate
by Rico Schüller 05 Sep '12

05 Sep '12

On 05.09.2012 08:02, Nozomi Kodama wrote: + out[15] = -0.9682458639f * in[13] + 0.25f * in[15]; ! You didn't find all trailing white spaces. I made a !, so it could be seen. You could easily get around that by changing your editors preference. Most editors are able to remove that automatically (see e.g. for vim http://vim.wikia.com/wiki/Remove_unwanted_spaces). You may also have a look at http://wiki.winehq.org/GitWine#head-b20b05157175835751686365f9818ae978ceca23 . Both are really easy to use. Be warned, that's not the only occurrence, so please look carefully if you remove them by hand. What you get from a comment to a patch are only hints. But you may check for all mentioned hints to the specific patch (even to previous tries), if you have fulfilled them or you may add a comment why you think the hint is bad. If you don't understand a hint, please ask - before sending another try, sometimes the hints could be wrong and sometimes they are worth to think about it. That's all I have to say, there won't be any more comments from my side to this patch. I need my time to get my own screwed up patches into wine. :-) Cheers Rico

1 0

Re: [PATCH 1/3] [cmd] "PATH=value" fails whereas "PATH value" works
by Marvin 04 Sep '12

04 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=21386 Your paranoid android. === WVISTAADM (32 bit) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

2 1

Re: [1/2] gdiplus: Add some tests for scaling an image with various pixel offset modes.
by Vincent Povirk 04 Sep '12

04 Sep '12

> match = memcmp(dst_8x1, td[i].image, sizeof(dst_8x1)) == 0; > + if (!match) > + todo_wine ok(match, "%d: data should match\n", i); > + else > ok(match, "%d: data should match\n", i); This sort of thing makes me nervous. Couldn't you do this in such a way that we'll notice if the existing tests break, like adding a todo field to the structure?

1 0

Re: d3dx9_36 [try 3]: Implement D3DXSHRotate
by Rico Schüller 04 Sep '12

04 Sep '12

On 04.09.2012 13:19, Nozomi Kodama wrote: + FLOAT expected, in[100], out[100], ... + for (i = 0; i < 49; i++) + in[i] = i + 1.01f; I guess this belongs together. I'd like to make some suggestions, please don't take it personally. When you got a comment on a patch, read it carefully. Think about it, if it makes sens to do the change (just adding what I've said is not always the best, it just gives you a hint, that you may improve some things, the list is not always complete and different people may have different suggestions) and try to improve your patch. After you are done, read your patch. Well mistakes happen, especially when you try to get something done really fast. (1) Take you some time and read it again and see if you've done that as best as possible and if you are happy with the code you've done, then submit it. If you've found a bug don't submit, fix it and go to #1. The earlier a bug is found the cheaper is it to solve it. I hope this helps a bit and it hopefully saves you some time to get a patch in the feature accepted. Thought I'd like to thank you for your patience and hopefully I haven't annoyed you and we'll see some good quality patches in the feature from you. :-) Cheers Rico

3 4

Re: wininet: Set last error for invalid URL argument
by Marvin 04 Sep '12

04 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=21380 Your paranoid android. === W2KPROSP4 (32 bit internet) === Timeout

1 0

Re: [2/2] gdiplus: Add preliminary support for pixel offset modes.
by Vincent Povirk 04 Sep '12

04 Sep '12

> return sample_bitmap_pixel(src_rect, bits, width, height, > - gdip_round(point->X), gdip_round(point->Y), attributes); > + point->X + pixel_offset, point->Y + pixel_offset, attributes); > + } This is going to break tiling. By removing gdip_round you're implicitly truncating the number instead of flooring, which will give you the wrong result when X or Y is negative. I suggest explicitly adding a floorf.

1 0

Re: jscript: Fixed empty cases in the end of switch statement
by Marvin 04 Sep '12

04 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=21379 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/4] mshtml: Properly expose frame and iframe element's windows to scripts
by Marvin 04 Sep '12

04 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=21376 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

Wine Gecko 1.8-beta1
by Jacek Caban 04 Sep '12

04 Sep '12

Hi all, It's time for another Gecko update. I've uploaded to SourceForge [1] new Gecko builds. These are based on Firefox 16 beta. Other than tons of changes inherited from Firefox and usual fixes to keep it working well for us, it brings a few visible fixes: - Proper <noscript> tag handling - Synchronous ActiveX loading - Possibility to properly call APIs requiring JSContext - Possibility to implement HTMLStyleElement::styleSheet property As usually, to test it you need the attached patch and Gecko build placed in the right place [2]. Any help with testing is appreciated! On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build. Here are my thoughts about reasoning (in random order): - People use debug build mostly to retrieve better backtraces. Unstripped builds also give that ability. - If someone really needs debug build, it's easy enough to build it himself (and that's usually a good idea anyway) - Debug builds are seriously different than release build, so it occasionally exposes different set of problems, leading to invalid assumptions. This is really something for developers rather than users. - It costs my time spent builds and tests. And I consider it a serious matter. Amount of work needed to keep Gecko relevant is constantly growing. I try to mitigate it by doing long-term improvements upstream, automating the process and improving my hardware, but that has its limits. And the time spent on Gecko maintenance (as in pure maintenance, not real improvements) costs Wine in terms of improvements I could make in this time. If someone has a reason to keep debug builds, let me know. Any comments are welcomed. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.8-beta1/ [2] http://wiki.winehq.org/Gecko

3 3

Re: d3dx9_36 [try 2]: Implement D3DXSHRotate
by Rico Schüller 04 Sep '12

04 Sep '12

On 03.09.2012 20:59, Nozomi Kodama wrote: > Thanks Rico and Henri for your help. > > Nozomi > > > The patch looks much better now. But I have some minor things which I didn't mention last time... + ok(received_ptr == out, "order %u, Expected %p, received %p\n", order, out, received_ptr); We may write the variables all starting with upper or lower char, maybe the first word will start with a upper char and the rest with a lower char. The mixture as is looks a bit ugly, doesn't it? Please have a look at the surrounding code, but not at test_D3DXSHRotateZ. ;-) And of course only going til 7 we won't need the in/out array till 100. 49 should fit, shouldn't it? That would be reducing the time spend in the for loops, even if it's only the test... Cheers Rico

1 0

vcomp.dll, vcomp90.dll missing on testbot?
by Dan Kegel 03 Sep '12

03 Sep '12

I'm trying to test a better set of stubs for vcomp.dll and its ilk, but those dlls don't seem to be installed on testbot. Is vcomp{,90,100}.dll not installed by default on Windows? If not, should we install it on a few of the VMs?

3 9

Re: [PATCH 1/6] mshtml: Moved getting frame by name to separated function
by Alexandre Julliard 03 Sep '12

03 Sep '12

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/htmlwindow.c | 127 > ++++++++++++++++++++++++++-------------------- > 1 files changed, 72 insertions(+), 55 deletions(-) gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -Werror -I/usr/include/freetype2 -g -O2 -o htmlwindow.o htmlwindow.c htmlwindow.c: In function ‘HTMLWindow2_item’: htmlwindow.c:416:13: error: variable ‘hres’ set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make: *** [htmlwindow.o] Error 1 -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/3] kernel32: Support UTF-7 in MultiByteToWideChar.
by Alexandre Julliard 03 Sep '12

03 Sep '12

Alex Henrie <alexhenrie24(a)gmail.com> writes: > I was asked to split this patch up, so I did. The complaint about the > last version was "You are still overflowing the source." I have not > been able to find any test case that my implementation handled > incorrectly, however, I did find that (*src == 0 && srclen < 0) will > never evaluate to true, so I removed this if statement from the code. I > also changed example #2 in the tests to be slightly more stringent, but > the last patch would also have passed. > > If this patch series is rejected, please show me a test case that > demonstrates what I am doing wrong. You don't have a single test with an explicit source length, so obviously you are not going to find problems in that area. Like I said, you need a lot more tests. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] msctf: also free the sink in the non-source branch (Coverity)
by Marvin 03 Sep '12

03 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=21357 Your paranoid android. === TEST64_W7SP1 (32 bit inputprocessor) === inputprocessor.c:259: Test failed: Unexpected TextStoreACP_GetStatus sink inputprocessor.c:259: Test failed: Unexpected TextStoreACP_GetStatus sink

1 0

Re: wined3d: Use backup swapchain DC for devices created with desktop window.
by Henri Verbeet 03 Sep '12

03 Sep '12

On 3 September 2012 00:51, Adam Jakubek <ajakubek(a)gmail.com> wrote: > Hi, > > This patch causes wined3d to use backup swapchain DC when > IDirect3DDevice9 is created using the desktop window. > Windows allows to create such device as long its type is > D3DDEVTYPE_REF or D3DDEVTYPE_NULLREF. > > Unpatched Wine will fail in IDirect3D9_CreateDevice method, since it > incorrectly uses the X root window. > > Relevant d3d test case is included. > Patch closes bug #18490. > How is actual rendering to the desktop window supposed to work?

2 1

Re: [PATCH 6/6] mshtml: Added IHTMLIFrameElement3 stub implementation
by Marvin 03 Sep '12

03 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=21355 Your paranoid android. === WXPPROSP3 (32 bit dom) === dom.c:5225: Test failed: Could not get {30510433-98B5-11CF-BB82-00AA00BDCE0B} interface: 80004002 dom.c:5262: Test failed: Could not get {30510433-98B5-11CF-BB82-00AA00BDCE0B} interface: 80004002 === WVISTAADM (32 bit dom) === dom.c:5225: Test failed: Could not get {30510433-98B5-11CF-BB82-00AA00BDCE0B} interface: 80004002 dom.c:5262: Test failed: Could not get {30510433-98B5-11CF-BB82-00AA00BDCE0B} interface: 80004002

1 0

Re: d3dx9_36: Implement D3DXSHRotate
by Rico Schüller 03 Sep '12

03 Sep '12

I had another look and like to give some suggestion. On 02.09.2012 22:28, Nozomi Kodama wrote: + sinb = sqrt( 1.0f - matrix->u.m[2][2] * matrix->u.m[2][2] ); I'd prefer to declare the variables as locally as possible. + D3DXSHRotateZ(temp5, order, alpha, temp4); + memcpy(out, temp5, sizeof(float) * order * order); + + return out; You probably may avoid the memcpy. What do you think about something like: return D3DXSHRotateZ(out, order, alpha, temp4); + FLOAT alpha, beta, gamma, sinb, temp1[36], temp2[36], temp3[36], temp4[36], temp5[36]; Do we really need that much temps? I think one is enough, but definitively 2 (I think you are able to use out as one "temp"). If you don't like the usage of out, you may use temp2 instead, but I think it could be avoided. D3DXSHRotateZ(out, order, gamma, in); RotateX(temp, order, 1, out); D3DXSHRotateZ(out, order, beta, temp); RotateX(temp, order, 0, out); D3DXSHRotateZ(out, order, alpha, temp); +static FLOAT* RotateX(FLOAT *out, UINT order, UINT pm, FLOAT *in) The return value is never used. Probably you may return void or you'd like to stack the function calls above a bit and reuse the returned pointer. You also may use "BOOL pm" since it uses only 0 and 1 or you may pass the "FLOAT a" directly to the function. Whatever pm stands for... Cheers Rico

2 1

Re: [PATCH] kernel32: add condition variables prototypes and tests (2nd try)
by Dmitry Timoshkov 03 Sep '12

03 Sep '12

Marcus Meissner <meissner(a)suse.de> wrote: > + if (!pInitializeConditionVariable) { > + skip("no condition variable support.\n"); > + return; > + } Probably this should be a win_slip(). > + /* fprintf(stderr,"produced %d, c1 %d, c2 %d\n", totalproduced, cnt1, cnt2); */ > + > + /* The sleeps of the producer or consumer should not go above 10000, otherwise > + * the implementation does not sleep correctly. */ > + > + /* fprintf(stderr,"producer sleep %d, consumer sleep %d\n", condvar_producer_sleepcnt, condvar_consumer_sleepcnt); */ There is trace() for debug output, it's shorter and more convenient IMHO. -- Dmitry.

4 3

Re: d3dx9_36: Implement D3DXSHRotate
by Rico Schüller 03 Sep '12

03 Sep '12

On 02.09.2012 23:46, Nozomi Kodama wrote: > For instance, D3DXSHAdd and D3DXSHDot accept order>D3DXSH_MAXORDER. So > we must check whether it is acceptable for other D3DXSH functions to > give such an order. If it is not acceptable, then we must know what the > function returns. Yes, they do and I agree with you. But why do you chose to try from 0 to 9 (<10) instead of 0-7 (<8) - which I think is enough and nothing more changes? (It includes the first round of not touched values.) Asking the other way around, why don't you try lets say till 1000? I guess the easy answer is, because the output values won't be touched for orders >6. The test results show the same for the tests 7-9 (and would til 1000) and thus testing for 7 is enough, testing 8 and 9 brings no new information, beside you would miss to test from 10 to open end. > > For the out of bound problem, I agree that we reach an out of bound. But > it is not a problem, since for such an index, expected is defined by an > other value. > If there is a complaining compiler about this, I can modify the tests > though. I'm not sure if the compiler is complaining, but I think it's much better to set it in the else case. You may get an unhandled exception and this is not what the software should do in the first place, it should run and not produce exceptions! :-) The same is done in test_D3DXSHRotateZ, which I'm not happy about it. Cheers Rico

1 0

Re: wined3d: Use backup swapchain DC for devices created with desktop window.
by Marvin 02 Sep '12

02 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=21350 Your paranoid android. === WXPPROSP3 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W2K3R2SESP2 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === WVISTAADM (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W2K8SE (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W7PRO (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W7PROX64 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === TEST64_W7SP1 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W7PROX64 (64 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === TEST64_W7SP1 (64 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a.

1 0

Re : d3dx9_36: Implement D3DXSHRotate
by Nozomi Kodama 02 Sep '12

02 Sep '12

For instance, D3DXSHAdd and D3DXSHDot accept order>D3DXSH_MAXORDER. So we must check whether it is acceptable for other D3DXSH functions to give such an order. If it is not acceptable, then we must know what the function returns. For the out of bound problem, I agree that we reach an out of bound. But it is not a problem, since for such an index, expected is defined by an other value. If there is a complaining compiler about this, I can modify the tests though. Nozomi

1 0

Re: d3dx9_36: Implement D3DXSHRotate
by Rico Schüller 02 Sep '12

02 Sep '12

On 02.09.2012 22:28, Nozomi Kodama wrote: > > + for (order = 0; order < 10; order++) > Is there a reason why we'd want to test til 9? D3DXSH_MAXORDER is 6, so 7 Should be enough? I know the other test do this, but technically I see no reason for that. Specifically the if (.. order > D3DXSH_MAXORDER) says exactly that, so no need to further than 7, since the parameters or did I miss something? I guess you'd also out of bounds? table[36 * j + i]; (for j=3 and i=99 => 207) since the table only has 4*36 => 144 elements. Cheers Rico

1 0

Re: winhttp: disable TLSv1.1/1.2 by default
by Henri Verbeet 02 Sep '12

02 Sep '12

On 26 August 2012 18:56, André Hentschel <nerv(a)dawncrow.de> wrote: > It's for http://bugs.winehq.org/show_bug.cgi?id=30598 > So it has its reason > So assuming I don't feel like reading through various bug trackers to figure this out, what is the specific issue this patch is supposed to address?

1 0

Re: [PATCH 3/3] hhctrl.ocx: Resize the window when HH_SET_WIN_TYPE is called (try 3, resend 2).
by Charles Davis 02 Sep '12

02 Sep '12

On Sep 2, 2012, at 11:23 AM, Erich E. Hoover wrote: > This patch adds the final feature to make the embedded help work > properly, allowing Elster to resize the HTML Help window whenever the > application window is resized. Without this feature the HTML Help > window would always remain at the same size as when the window was > first created. Er, uh, what patch? Chip

2 1

Re: [PATCH] kernel32: add condition variables prototypes and tests
by Marvin 02 Sep '12

02 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=21332 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH] kernel32: add condition variables prototypes and tests
by Marvin 02 Sep '12

02 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=21331 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: netapi32: Add stub for NetScheduleJobAdd
by Jacek Caban 01 Sep '12

01 Sep '12

Hi Jong, On 09/01/12 17:13, Jong Bin, Chae wrote: > --- > dlls/netapi32/netapi32.c | 6 ++++++ > dlls/netapi32/netapi32.spec | 2 +- > 2 files changed, 7 insertions(+), 1 deletions(-) > > diff --git a/dlls/netapi32/netapi32.c b/dlls/netapi32/netapi32.c > index 470adf0..f6c6d20 100644 > --- a/dlls/netapi32/netapi32.c > +++ b/dlls/netapi32/netapi32.c > @@ -238,6 +238,12 @@ NET_API_STATUS WINAPI NetUseEnum(LMSTR server, > DWORD level, LPBYTE* bufptr, DWOR > return ERROR_NOT_SUPPORTED; > } > > +NET_API_STATUS WINAPI NetScheduleJobAdd(LPCWSTR server, LPBYTE > bufptr, LPDWORD jobid) > +{ > + FIXME("stub (%s, %p, %p)\n", debugstr_w(server), bufptr, jobid); It looks like your mail client wraps lines. Please send patches as attachments or reconfigure your mail client. Cheers, Jacek

1 0

Wine Gecko 1.8-beta1
by Jacek Caban 01 Sep '12

01 Sep '12

Hi all, It's time for another Gecko update. I've uploaded to SourceForge [1] new Gecko builds. These are based on Firefox 16 beta. Other than tons of changes inherited from Firefox and usual fixes to keep it working well for us, it brings a few visible fixes: - Proper <noscript> tag handling - Synchronous ActiveX loading - Possibility to properly call APIs requiring JSContext - Possibility to implement HTMLStyleElement::styleSheet property As usually, to test it you need the attached patch and Gecko build placed in the right place [2]. Any help with testing is appreciated! On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build. Here are my thoughts about reasoning (in random order): - People use debug build mostly to retrieve better backtraces. Unstripped builds also give that ability. - If someone really needs debug build, it's easy enough to build it himself (and that's usually a good idea anyway) - Debug builds are seriously different than release build, so it occasionally exposes different set of problems, leading to invalid assumptions. This is really something for developers rather than users. - It costs my time spent builds and tests. And I consider it a serious matter. Amount of work needed to keep Gecko relevant is constantly growing. I try to mitigate it by doing long-term improvements upstream, automating the process and improving my hardware, but that has its limits. And the time spent on Gecko maintenance (as in pure maintenance, not real improvements) costs Wine in terms of improvements I could make in this time. If someone has a reason to keep debug builds, let me know. Any comments are welcomed. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.8-beta1/ [2] http://wiki.winehq.org/Gecko PS: This is a second resend. For some reason this mail didn't make to wine-devel yesterday.

1 0

Re: winhttp: disable TLSv1.1/1.2 by default
by Hiroshi Miura 01 Sep '12

01 Sep '12

Hi, Thanks André to point the discussion On 2012年08月27日 01:56, André Hentschel wrote: > Am 26.08.2012 17:46, schrieb Marcus Meissner: >> On Sun, Aug 26, 2012 at 11:50:15AM +0900, Hiroshi Miura wrote: >>> >>> Windows 7 disables TLSv1.1/1.2 by default. >>> This patch intend to behave same as Windows. >> >> >> Please do not... The newer TLSv1.x fix some shortcomings >> of the older TLS versions. >> >> Is there a specific problem you see? >> >> Otherwise, I object. >> > > It's for http://bugs.winehq.org/show_bug.cgi?id=30598 > So it has its reason > Yes it has a reason to disable TLS 1.1 1.2 by DEFAULT. It also provide interface to enable it through registry entry, which is same as windows does. I also prefer to use TLS 1.1/1.2 than before SSL3.0/TLS1.0. but here is a interoperability issue with SSL3.0/TLS 1.0 only site and TLS1.1/1.2 enabled Wine program. In evernote case, client program use wininet dll instead of winhttp. Even such a case, it should be a same behavior for registry values in secur32/schannel, wininet, and winhttp dlls. I understand that wininet/winhttp has a issue to re-implement it using schannel instead of openssl. It means if we support a behavior disabling/enabling TLS1.1/1.2 with registry entry for Schannel, wininet/winhttp should also have a same behavior. We need to add function that enable/disable TLS1.1/1.2 in secur32/schannel according to this registry, but I've not implemented it yet. registry entry is like; ---- Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 ----- see http://netsekure.org/2009/10/tls-1-2-in-windiows-7/ Hiroshi

1 0

Re: [1/16] po: Update Russian translation
by Nikolay Sivov 31 Aug '12

31 Aug '12

On 8/24/2012 10:13, Oleg Yarigin wrote: > > > "To install a new program from a floppy disk, CD-ROM drive, or your hard " > "drive, click Install." > msgstr "" > -"Чтобы установить программу с CD-ROM, дискеты или жёсткого диска, нажмите " > -"Установить." > +"Для установки программы с компакт- или жёсткого диска нажмите «Установить»." You only need to fix quotation marks in original string, the variant you proposed doesn't say what English string is saying. > #: appwiz.rc:62 > -msgid "" > -"The following software can be automatically removed. To remove a program or " > -"to modify its installed components, select it from the list and click Modify/" > -"Remove." > -msgstr "" > -"Перечисленные программы можно автоматически удалить. Чтобы удалить программу " > -"или изменить состав установленных компонентов, выберите её в списке и " > +msgid "The following software can be automatically removed. To remove a " > +"program or to modify its installed components, select it from the list and " > +"click Modify/Remove." > +msgstr "Перечисленные программы могут быть удалены. Для удаления " > +"или изменения состава установленных компонентов, выберите их в списке и " > "нажмите кнопку Изменить/Удалить." Again, don't alter original meaning, no reason to remove 'automatically' here. > #: appwiz.rc:76 > msgid "The following information can be used to get technical support for %s:" > -msgstr "" > -"Указанная информация может быть использована для получения технической " > +msgstr "Указанная информация может быть использована для получения технической " > "поддержки приложения %s:" Nothing changed here. > #: appwiz.rc:35 shell32.rc:141 shell32.rc:238 regedit.rc:122 winefile.rc:104 > msgid "Name" > -msgstr "Имя" > +msgstr "Название" That's questionable. If you really want to change that it will need to depend on context I guess. > #: avifil32.rc:33 > msgid "Wine AVI-default-filehandler" > -msgstr "Обработчик по умолчанию avi-файлов в Wine" > +msgstr "Обработчик avi-файлов по умолчанию в Wine" This alters a meaning a bit, now what you did means that there're some default avi-files in Wine.

3 5

Re: kernel32: Return correct drive type for empty drives
by Alexandre Julliard 31 Aug '12

31 Aug '12

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > Should fix bug #17037 > I followed your advice and now, I only ask the mountmgr when needed. > --- > dlls/kernel32/volume.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) This is failing here when the drive is empty: ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so volume.c && touch volume.ok volume.c:132: Tests skipped: can't test removing fake drive volume.c:785: Test failed: IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) failed, last error = 87 make: *** [volume.ok] Error 1 If I put a DVD in I get: volume.c:813: Test failed: IOCTL_DVD_READ_STRUCTURE should have failed Probably the tests need some fixing. -- Alexandre Julliard julliard(a)winehq.org

4 3

Wine Gecko 1.8-beta1
by Jacek Caban 31 Aug '12

31 Aug '12

Hi all, It's time for another Gecko update. I've uploaded to SourceForge [1] new Gecko builds. These are based on Firefox 16 beta. Other than tons of changes inherited from Firefox and usual fixes to keep it working well for us, it brings a few visible fixes: - Proper <noscript> tag handling - Synchronous ActiveX loading - Possibility to properly call APIs requiring JSContext - Possibility to implement HTMLStyleElement::styleSheet property As usually, to test it you need the attached patch and Gecko build placed in the right place [2]. Any help with testing is appreciated! On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build. Here are my thoughts about reasoning (in random order): - People use debug build mostly to retrieve better backtraces. Unstripped builds also give that ability. - If someone really needs debug build, it's easy enough to build it himself (and that's usually a good idea anyway) - Debug builds are seriously different than release build, so it occasionally exposes different set of problems, leading to invalid assumptions. This is really something for developers rather than users. - It costs my time spent builds and tests. And I consider it a serious matter. Amount of work needed to keep Gecko relevant is constantly growing. I try to mitigate it by doing long-term improvements upstream, automating the process and improving my hardware, but that has its limits. And the time spent on Gecko maintenance (as in pure maintenance, not real improvements) costs Wine in terms of improvements I could make in this time. If someone has a reason to keep debug builds, let me know. Any comments are welcomed. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.8-beta1/ [2] http://wiki.winehq.org/Gecko

1 0

Re: kernel32: Add UTF-7 support. (try 5)
by Alexandre Julliard 31 Aug '12

31 Aug '12

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Try 5 adds two tests for the case where srclen < -1 and passes them both. You are still overflowing the source. You need to spend more time on this. You also need to split the patch, and write some sort of table-driven tests so you can test a lot more cases, the ones you have are clearly not sufficient. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Moving pages to/from wiki
by Kyle Auble 31 Aug '12

31 Aug '12

Wed, Aug 29, 2012 16:09, André Hentschel wrote: > get the website source and do "grep -Ri cvs *" > then ignore wwn/ and news/ ... > all that should somehow bring you to http://www.winehq.org/cvs or be deleted grep -r "...." * is rapidly becoming a very good friend of mine ;) I just checked http://cvs.winehq.org and sure enough, there is still a very outdated CVS repository there, but I can't find a template or a PHP applet for it, just the same links you found (most in WWN issues). I've CCed Jeremy Newman because I'm guessing the site admin would have to remove it. As for redirecting to http://www.winehq.org/cvs, since that was designed as a notice page for people trying to browse the source code, I was picturing just redirecting the links to http://source.winehq.org/git and deleting http://www.winehq.org/cvs as only WWN issues and news would still have dangling links. I don't want to remove it if there's another reason for keeping it though. - Kyle

5 6

Re: [PATCH 2/5] hhctrl.ocx: Implement HH_SET_WIN_TYPE (try 7).
by Alexandre Julliard 30 Aug '12

30 Aug '12

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > @@ -1784,11 +1785,25 @@ void ReleaseHelpViewer(HHInfo *info) > OleUninitialize(); > } > > -HHInfo *CreateHelpViewer(LPCWSTR filename, HWND caller) > +static BOOL info_in_list(HHInfo *info) > +{ > + HHInfo *i; > + > + LIST_FOR_EACH_ENTRY(i, &window_list, HHInfo, entry) > + { > + if(i == info) > + return TRUE; > + } > + return FALSE; > +} You should never need that sort of thing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: Add UTF-7 support. (try 4)
by Alexandre Julliard 30 Aug '12

30 Aug '12

Alex Henrie <alexhenrie24(a)gmail.com> writes: > + do > + { > + if (src[source_index] == 0 && srclen == -1) > + { > + if (dry_run) dest_index++; else if (write_to_w_string(dst, dstlen, &dest_index, 0)) return -1; > + /* when srclen=-1, terminate at the first null character found */ > + break; > + } > + else if (src[source_index] == '+') > + { > + WCHAR byte_pair = 0; > + short offset = 0; > + > + source_index++; /* skip the + sign */ > + > + if (src[source_index] == '-') > + { > + /* just a plus sign escaped as +- */ > + if (dry_run) dest_index++; else if (write_to_w_string(dst, dstlen, &dest_index, '+')) return -1; > + source_index++; > + continue; > + } You are not checking properly for the source string length. Also please add tests for such cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

Moving pages to/from wiki
by Kyle Auble 29 Aug '12

29 Aug '12

I'm starting to work on moving static pages to and from the wiki, but I wanted to ask for opinions on a few changes first: 1. Move all static IRC pages to the wiki or add info from the wiki to the static templates? The static pages only mention #winehq and don't describe guidelines, but IRC details shouldn't change much right? 2. For the static About page, some languages also have wiki versions. Do we want to keep the sparser versions currently in use, or add the more detailed information from the wiki version? Both versions seem well-written, and exist for English, Hebrew, & Spanish (I deleted the Polish wiki version; it was a duplicate). 3. Do we still need the static "cvs" page, or should I just redirect any links to it, then delete? On a related note, the WineHQ ToDo on the wiki still claims that a browser for the old CVS source tree is lurking on the site somewhere. Is that true, or do I need to cut that line from the ToDo list? 4. Since licensing tends to be really static could we just redirect the WikiLicense page to the static license page, or should they be kept separate? While I'd think it wouldn't be too hard to reword the static page's intro to include other projects, I'm leery of editing any legal-ese without asking first. By the way, the WikiLicense page says it's LGPL v2.1 in the intro text, but the included license actually looks like v2.0 of the GPL with a modification for libraries. If the wiki version of the page should stay, I'll put in a copy of v2.1 - Kyle

2 1

Re: [Tools] testbot: Add LICENSE and COPYING.LIB files.
by Henri Verbeet 29 Aug '12

29 Aug '12

On 29 August 2012 16:35, Francois Gouget <fgouget(a)codeweavers.com> wrote: > --- > > I think this made total sense when th WineTestBot was in its own > repository. Now maybe the COPYING.LIB and LICENSE files can be > considered to apply to all of the Wine tools and should go to the > top-level directory? > Not all of the code in tools.git is under LGPL 2.1. (And personally I'd argue that GPL 3 is probably more appropriate for most of the things in there anyway.)

2 1

Wine bot results
by Alistair Leslie-Hughes 29 Aug '12

29 Aug '12

Hi, I have a patch that when run on on the testbot, it fails on all but two machines. However when I build the exe myself and run it, it pass on all but two machines. http://testbot.winehq.org/JobDetails.pl?Key=21257 http://testbot.winehq.org/JobDetails.pl?Key=21256 Ubuntu 12.04. Any Ideas on the different results? Best Regards Alistair Leslie-Hughes

5 7

Re: d3dx9: ID3DXConstantTable
by Józef Kucia 29 Aug '12

29 Aug '12

On Tue, Aug 21, 2012 at 10:52 PM, gurketsky <gurketsky(a)googlemail.com>wrote: > I just like to present the state of the ID3DXConstantTable implementation, > so that possibly no work is done twice. This goes specifically to Józef. > I'm not sure what's the plan on this. There are two problems which arise > and I did not had time to sort those out, yet. > Thanks for notifying me. I was about to write some tests for structures in constant tables. I see that you've already written such tests. Cheers, Józef Kucia

4 8

Re: gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text. Take 2.
by Vincent Povirk 28 Aug '12

28 Aug '12

This looks correct to me. Lack of shared logic and GenericTypographic still makes me sad, but not too sad because the added logic is simple.

1 0

Re: About WineHQ Wiki
by Kyle Auble 28 Aug '12

28 Aug '12

Sat, 25 Aug 2012 14:44, Oleg Yarigin wrote: > When I edited pages in the WineHQ Wiki, I notised, its markup lankuage > isn`t so good as MediaWiki`s one. How do you think about moving the Wiki > into MediaWiki engine? Besides, moving each language section of the Wiki > into separated subdomain (like in Wikipedia) would be a good idea too. I've been working a lot on the wiki recently, and I actually brought up something similar in this thread: http://www.winehq.org/pipermail/wine-devel/2012-July/096198.html While I'm busy with other things right now, I wanted to discuss this in more detail in the near future, particularly how it ties into possibly migrating the entire site over to a CMS. The Moinmoin syntax was new to me too, but after using it a little, I don't mind it too much. There are definitely a few missing features and rough edges compared to MediaWiki. However, and this is just my impression, I think MediaWiki has really evolved to fit Wikipedia's needs. I'm not sure how well it integrates (style-wise at least) if you don't run your entire site off of it, and while I haven't actually looked at MediaWiki's code, I've heard that it can be really tricky to setup, maintain, and reprogram. There are some pluggable parsers for Moinmoin, and there may be one that allows MediaWiki syntax. After going through and checking, categorizing, and editing so many pages, I definitely agree with your suggestion that each language be given a domain, instead of one flat namespace. Then maybe just add a single common "translation" menu to the side toolbar? I've come to the opinion that we should probably stick with Moinmoin, and migrate to a new engine other than MediaWiki only if there are strong reasons. What might be best is if we actually got in touch with some of the Moinmoin developers and put in some feature requests. Helping with the wiki's engine is on my list so I'd like to hear some more opinions. -Kyle

5 8

Re: [PATCH 1/5] d3dx9: Add some traces to D3DXLoadSurfaceFromMemory().
by Henri Verbeet 28 Aug '12

28 Aug '12

2012/8/28 Rico Schüller <kgbricola(a)web.de>: > + FIXME("Format conversation missing %#x -> %#x\n", src_format, surfdesc.Format); I don't think that's really what we want it to say.

1 0

Re: shell32: Make ShellExecute use native file association databases as fallback path (resend)
by Alexandre Julliard 28 Aug '12

28 Aug '12

Erik van Pienbroek <erik(a)vanpienbroek.nl> writes: > +#if defined(HAVE_FORK) && defined(HAVE_WAITPID) > +static UINT_PTR SHELL_try_native_execute ( const char *openCmd, const char *unixName ) > +{ > + UINT_PTR retval = SE_ERR_NOASSOC; > + pid_t cpid; > + struct stat st; > + > + if (stat(openCmd, &st) == -1) > + { > + TRACE("stat() %s failed: %s\n", openCmd, strerror(errno)); > + return retval; > + } > + > + cpid = fork(); > + if (!cpid) > + { > + /* Prevent the situation where the native file association database > + * tries to run wine to execute a program and we trigger this fallback > + * path again and end up in a recursive loop */ > + if (getenv("WINE_INSIDE_SHELLEXECUTE")) > + { > + TRACE("recursive loop detected, not continuing with ShellExecute call\n"); > + exit(EXIT_SUCCESS); > + } > + setenv("WINE_INSIDE_SHELLEXECUTE", "1", 0); > + > + TRACE("running %s %s\n", openCmd, unixName); > + execlp(openCmd, openCmd, unixName, (char*) NULL); > + /* execlp replaces the current process image with a new process image, > + * so no code below here should get executed by the forked child */ > + } else { > + int status; > + waitpid(cpid, &status, 0); > + TRACE("status %x\n", status); > + if(!WEXITSTATUS(status)) > + retval = 33; > + } > + > + return retval; > +} You want spawnvp(), but that sort of thing should probably go in winebrowser or something like that, and be configurable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: Try to get the drive type from the mountmgr first [resend]
by Alexandre Julliard 28 Aug '12

28 Aug '12

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > Should fix bug #17037 > Now that my patch disappeared from source.winehq.org/patches, I'm resending it. > Before commenting, please read the e-mail I sent in July (winehq.org/pipermail/wine-devel/2012-July/096587.html) The goal here is to avoid a mountmgr round-trip for the common case, calling mountmgr first defeats this. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 6/6] Always define WIDL_C_INLINE_WRAPPERS
by Marvin 28 Aug '12

28 Aug '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=21287 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 6/6] Always define WIDL_C_INLINE_WRAPPERS
by Marvin 28 Aug '12

28 Aug '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=21286 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 6/6] Always define WIDL_C_INLINE_WRAPPERS
by Marvin 28 Aug '12

28 Aug '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=21285 Your paranoid android. === 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

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