- wine-devel - winehq.org

Re: gdi32: Simplify font->aveWidth sanity-checking to fix possible division by zero. (try 2)
by Christian Costa 08 May '13

08 May '13

Le 08/05/2013 11:45, Sam Edwards a écrit : > After feedback from Dmitry (thanks!), I redid this patch with the > following changes: > > * I misunderstood before what the test did; I initially thought this > was just a workaround to get aveWidth to behave, but as it turns out, > Windows has the same "maximum ratio of 100" limit. I changed the > comment to reflect that; hopefully this stops someone else from making > my mistake. :) > * Negative aveWidth checking is removed. I agree that there should be > a test to put this in, but Windows treats negative aveWidths as > invalid (according to Aric), so it can't be tested on Windows. That's > a much bigger mess than a simple "fix divide by zero" patch is worth. > * The division is done differently, to avoid potential overflow > problems. The result of the comparison is still exactly the same as > before the patch, except zero values are now handled gracefully. > > This supersedes 96111 (which, I forgot to mention before, supersedes > 96053 and 96047). > > Best, > Sam > + if (font->aveWidth && + (font->aveWidth - 1) / 100 >= font->potm->otmTextMetrics.tmHeight) { - if ((font->aveWidth + font->potm->otmTextMetrics.tmHeight - 1) / font->potm->otmTextMetrics.tmHeight > 100) - { Hi Sam, The test in the if is not that long. Shouldn't this fit into a single like as the previous test? Christian

1 0

Re: [2/2] comdlg32: Add a test for nCopies/dmCopies returned by PrintDlg.
by Marvin 08 May '13

08 May '13

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=25483 Your paranoid android. === WVISTAX64 (32 bit printdlg) === printdlg.c:242: Test failed: expected nCopies 1234, got 1 Timeout === W2K8SE (32 bit printdlg) === printdlg.c:242: Test failed: expected nCopies 1234, got 1 Timeout === W7PROX64 (32 bit printdlg) === Timeout === TEST64_W7SP1 (32 bit printdlg) === Timeout === WVISTAX64 (64 bit printdlg) === printdlg.c:242: Test failed: expected nCopies 1234, got 1 Timeout === W7PROX64 (64 bit printdlg) === Timeout === TEST64_W7SP1 (64 bit printdlg) === Timeout

1 0

Re: [PATCH] mscms: Use lcms2, when available
by Hans Leidekker 08 May '13

08 May '13

On Tue, 2013-05-07 at 22:45 +0200, Detlef Riekenberg wrote: > lcms2 was released on 8. May 2010 and should be present in important > distributions since a while. > > lcms v1 is on the way to be phased out in the newest distribution > versions. Are there any distributions that have released without v1?

1 0

Re: [1/5] kernel32: Add more remote process tests.
by Marvin 08 May '13

08 May '13

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=25479 Your paranoid android. === TEST64_W7SP1 (32 bit loader) === loader.c:1210: Test failed: expected thread exit code 195, got 259 loader.c:1210: Test failed: expected thread exit code 195, got 259 loader.c:1220: Test failed: expected WAIT_ABANDONED, got 0x102 loader.c:1236: Test failed: expected WAIT_OBJECT_0, got 0x102 loader.c:1238: Test failed: expected WAIT_OBJECT_0, got 0x102

2 1

Re: gdi32: Simplify font->aveWidth sanity-checking to remove possible division by zero.
by Dmitry Timoshkov 08 May '13

08 May '13

Sam Edwards <cfsworks(a)gmail.com> wrote: > It makes the most sense to get rid of this sanity check altogether, but > until then, this should be a more robust way of doing it. > + * TODO: This sounds like a workaround for a much deeper bug involving > + * aveWidth's calculation. We should investigate if/why this is needed. > + */ This comment is confusing and wrong. There is a test case for which this check is required. > + if (font->aveWidth < 0 || font->aveWidth > font->potm->otmTextMetrics.tmHeight * 100) A check for an overflow is probably needed. Also a check for negative aveWidth should be a separate patch at best, and needs a test case. -- Dmitry.

1 0

Re: [PATCH 1/8] ole32: Use MSHLFLAGS_TABLEWEAK marshaling in CoRegisterClassObject.
by Alexandre Julliard 07 May '13

07 May '13

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/ole32/compobj.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) It doesn't work here: ../../../tools/runtest -q -P wine -M wscript.exe -T ../../.. -p wscript.exe_test.exe.so run.c && touch run.ok wine: Unhandled page fault on read access to 0x00000000 at address 0x555a9468 (thread 0088), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x555a9468). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:555a9468 ESP:0033f7d0 EBP:0033f868 EFLAGS:00010202( R- -- I - - - ) EAX:00000000 EBX:555d2cac ECX:0033f810 EDX:00000001 ESI:00000000 EDI:0033f828 Stack dump: 0x0033f7d0: 0033f828 00000005 00000000 555c7f30 0x0033f7e0: 0033f814 001407a4 0000000c 0013c414 0x0033f7f0: 0000000c 00000000 00000000 00000000 0x0033f800: 00142020 00000000 00000000 001373b0 0x0033f810: ffffffff 00000000 0033f868 7b85382e 0x0033f820: 00000000 00000001 178fc166 4e24f585 Backtrace: =>0 0x555a9468 Global_CreateObject+0x178() in vbscript (0x0033f868) 1 0x555b6b3c DispatchEx_InvokeEx+0x65b(iface=<couldn't compute location>, id=<couldn't compute location>, lcid=<couldn't compute location>, wFlags=<couldn't compute location>, pdp=<couldn't compute location>, pvarRes=<couldn't compute location>, pei=<couldn't compute location>, pspCaller=<couldn't compute location>) [/home/julliard/wine/wine/dlls/vbscript/vbdisp.c:215] in vbscript (0x0033f958) 2 0x555b899d disp_call+0x9c(ctx=0x1373b0, disp=0x13f368, id=0xaf, dp=0x33fa40, retv=0x33fa80) [/home/julliard/wine/wine/dlls/vbscript/../../include/dispex.h:299] in vbscript (0x0033f9e8) 3 0x555af05c do_icall+0x20b(ctx=<is not available>, res=<is not available>) [/home/julliard/wine/wine/dlls/vbscript/interp.c:511] in vbscript (0x0033fa68) 4 0x555af1dd interp_icall+0x2c(ctx=<is not available>) [/home/julliard/wine/wine/dlls/vbscript/interp.c:558] in vbscript (0x0033fa98) 5 0x555aeb42 exec_script+0x191(ctx=<is not available>, func=<is not available>, this_obj=<is not available>, dp=<is not available>, res=<is not available>) [/home/julliard/wine/wine/dlls/vbscript/interp.c:1918] in vbscript (0x0033fb58) 6 0x555be4a7 exec_global_code+0x46(ctx=0x1373b0, code=<is not available>) [/home/julliard/wine/wine/dlls/vbscript/vbscript.c:83] in vbscript (0x0033fb88) 7 0x555bedab VBScript_SetScriptState+0x17a() in vbscript (0x0033fbe8) 8 0x684fc3dd wWinMain+0x9bc(hInst=<couldn't compute location>, hPrevInst=<couldn't compute location>, cmdline=<couldn't compute location>, cmdshow=<couldn't compute location>) [/home/julliard/wine/wine/programs/wscript/../../include/activscp.h:1013] in wscript (0x0033fd88) 9 0x684fc671 wmain+0xb0(argc=0x5, argv=0x110380) [/home/julliard/wine/wine/dlls/winecrt0/exe_wmain.c:50] in wscript (0x0033fe18) 10 0x684fc5a5 __wine_spec_exe_wentry+0x84(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_wentry.c:36] in wscript (0x0033fe58) 11 0x7b86053c call_process_entry+0xb() in kernel32 (0x0033fe78) 12 0x7b86171b start_process+0x6a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1084] in kernel32 (0x0033feb8) 13 0x7bc7a800 call_thread_func_wrapper+0xb() in ntdll (0x0033fed8) 14 0x7bc7d70d call_thread_func+0x7c(entry=0x7b8616b0, arg=0x7ffdf000, frame=0x33ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2567] in ntdll (0x0033ffa8) 15 0x7bc7a7de call_thread_entry_point+0x11() in ntdll (0x0033ffc8) 16 0x7bc5004e start_process+0x1d(kernel_start=0x7b8616b0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2691] in ntdll (0x0033ffe8) 17 0x6802947d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 18 0x6802953b wine_switch_to_stack+0x2a(func=0x7bc50030, arg=0x7b8616b0, stack=0x340000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xffeb7758) 19 0x7bc55b27 LdrInitializeThunk+0x3a6(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2747] in ntdll (0xffeb77c8) 20 0x7b867d00 __wine_kernel_init+0xbbf() [/home/julliard/wine/wine/dlls/kernel32/process.c:1256] in kernel32 (0xffeb86d8) 21 0x7bc561f3 __wine_process_init+0x182() [/home/julliard/wine/wine/dlls/ntdll/loader.c:2956] in ntdll (0xffeb8768) 22 0x680270c2 wine_init+0x2a1(argc=0x6, argv=0xffeb8cb4, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:847] in libwine.so.1 (0xffeb87c8) 23 0x7bf00e7b main+0x7a(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:237] in <wine-loader> (0xffeb8c08) 24 0x681cee46 __libc_start_main+0xe5() in libc.so.6 (0xffeb8c88) 0x555a9468 Global_CreateObject+0x178 in vbscript: movl 0x0(%eax),%edx -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] dlls/gdi32/freetype.c: A better divide by zero fix, report bad fonts.
by Sam Edwards 07 May '13

07 May '13

On 05/06/2013 03:05 PM, Max TenEyck Woodbury wrote: > Just to make this clear, the most recent version of this patch is such > a graceful handling, right? I haven't worked on gdi32/freetype.c much, so I wouldn't be the one to say for sure (you should probably talk to Alexandre Julliard, Dmitry Timoshkov, or Huw Davies), but I'll give you my thoughts anyway: On 05/05/2013 12:48 PM, max(a)mtew.isa-geek.net wrote: > > + /* HACKHACK: If a font has tmHeight=0, let us know. */ > + if (!font->potm->otmTextMetrics.tmHeight) { > + ERR("Font named '%s' has tmHeight=0, aveWidth=%d!\n", font->ft_face->family_name, font->aveWidth); > + } > + Since we've learned that tmHeight=0 is not actually an error, it doesn't make sense to log it using ERR(...). I would suggest a TRACE(...) or (preferably) nothing at all. Also, when I wrote the ERR message patch for you, it was intended only to help you locate the problematic font and wasn't meant to be included in upstream Wine. (Which is why I marked it with HACKHACK and didn't bother to use debugstr_a.) As for the actual check, it makes sense to consider what the math is trying to do: If aveWidth is extremely large (relative to tmHeight), then assume aveWidth is wrong and set it to 0. If tmHeight is 0, then it seems reasonable to assume that aveWidth isn't valid either. I'm not sure why the sanity check cares to do this: (aveWidth+tmHeight-1) / tmHeight > 100 When it can just do this: (aveWidth+tmHeight-1) / tmHeight > 100 = (aveWidth-1)/tmHeight + 1 > 100 = (aveWidth-1)/tmHeight > 99 = (aveWidth-1) > tmHeight*99 = aveWidth > tmHeight*99 + 1 ≈ aveWidth > tmHeight*100 This allows us to write out tmHeight just once, and is also much easier to understand at a glance. So, I would just simplify the whole sanity check to something like: /* Make sure that the font has sane width/height ratio */ if (font->aveWidth > font->potm->otmTextMetrics.tmHeight * 100) { WARN("Ignoring too large font->aveWidth %d\n", font->aveWidth); font->aveWidth = 0; } But even then, the sanity check itself sounds like a workaround for a much deeper bug. Maybe add a "FIXME: Investigate why this is necessary" comment while you're at it? Best, Sam

2 1

[PATCH] msvcrt: fix character/byte confusion in buffer overflow branch
by Max Kellermann 07 May '13

07 May '13

The first memcpy() call in puts_clbk_str_w() confuses character count and byte count. It uses the number of characters (out->len) as number of bytes. This leaves half of the buffer undefined. Interestingly, the second memcpy() call in the same function is correct. This bug potentially makes applications expose internal (secret) data. Usually, the destination buffer is on the stack, and the stack often contains secrets. Therefore, one could argue that this bug constitutes a security vulnerability. --- dlls/msvcrt/printf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dlls/msvcrt/printf.h b/dlls/msvcrt/printf.h index cfba4b7..8b749bc 100644 --- a/dlls/msvcrt/printf.h +++ b/dlls/msvcrt/printf.h @@ -48,7 +48,7 @@ static int FUNC_NAME(puts_clbk_str)(void *ctx, int len, const APICHAR *str) return len; if(out->len < len) { - memcpy(out->buf, str, out->len); + memcpy(out->buf, str, out->len*sizeof(APICHAR)); out->buf += out->len; out->len = 0; return -1;

3 4

Re: user32: Implement IMR_QUERYCHARPOSITION handling in the edit control
by Dmitry Timoshkov 07 May '13

07 May '13

Aric Stewart <aric(a)codeweavers.com> wrote: > dlls/user32/edit.c | 21 +++++++++++++++++++++ > include/imm.h | 9 +++++++++ > 2 files changed, 30 insertions(+) Using usual 4 spaces indentation would slightly improve the readability. -- Dmitry.

2 2

Re: [PATCH 6/8] ieframe: Added more InternetExplorer object tests.
by Marvin 07 May '13

07 May '13

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=25463 Your paranoid android. === W2KPROSP4 (32 bit ie) === Timeout

1 0

Re: [PATCH] dlls/gdi32/fretype.c: Avoid division by zero.
by Dmitry Timoshkov 06 May '13

06 May '13

max(a)mtew.isa-geek.net wrote: > + if ( font->aveWidth && font->potm->otmTextMetrics.tmHeight ) { > + if (((font->aveWidth + font->potm->otmTextMetrics.tmHeight - 1) / > + font->potm->otmTextMetrics.tmHeight) > 100) { > WARN("Ignoring too large font->aveWidth %d\n", font->aveWidth); > font->aveWidth = 0; > } In which case font->potm->otmTextMetrics.tmHeight is going to be 0? -- Dmitry.

6 19

Re: d3dx9 [patch 2 / 3]: Avoid useless computations in D3DXMatrixAffineTransformation
by Rico Schüller 06 May '13

06 May '13

On 05.05.2013 23:01, Nozomi Kodama wrote: > > + FLOAT xw, xx, xy, xz, yw, yy, yz, zw, zz; > I'm not very happy with the additional amount of variables... Please have a look at the attached patches. I think something like the first one (d3dx9: Apply rotationcenter only when a rotation is done.) should be done but has no influence on your patch (it is only attached, because the second patch influences the same part). 1. The amount of variables needed could be reduced to 3 by reordering the calculations (see patch 2, lines 36 - 58). This could also be done in your patch. Though I'm not sure that's a good idea ... comments and other opinions are welcome. Below this the points are not directly related to your patch: 2. In the next step we could also avoid a couple of multiplications by multiplying the scaling and adjusting the constants (see patch 2, lines 70 - 79). 3. We could also avoid the temps by reordering the calculation (Doing rotationcenter before the scaling). This way the tempxx could be avoided by using the out matrix directly. Cheers Rico

1 0

Re: d3dx9 [patch 1 / 3]: Avoid useless computations in D3DXMatrixAffineTransformation2D
by Rico Schüller 06 May '13

06 May '13

On 05.05.2013 23:00, Nozomi Kodama wrote: > + FLOAT tmp1, tmp2; > > + tmp1 = cosf(rotation); > + tmp2 = sinf(rotation); > As of it is really clear what's in those variables, we may name them with a better name instead of tmp1/tmp2 ... but I'm fine with either version. Cheers Rico

1 0

Re: [1/3] server: Add a process flag indicating whether the process is terminating, use it to block thread creation in a bei
by Marvin 06 May '13

06 May '13

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=25445 Your paranoid android. === W7PROX64 (64 bit loader) === loader.c:1638: Test failed: expected WAIT_OBJECT_0, got 0x102 loader.c:1648: Test failed: expected thread exit code 196, got 259 loader.c:1210: Test failed: expected thread exit code 196, got 259 loader.c:1220: Test failed: expected WAIT_ABANDONED, got 0x102 loader.c:1236: Test failed: expected WAIT_OBJECT_0, got 0x102

2 1

GSoC 2013 - Registry Merging Project
by orzhvs 04 May '13

04 May '13

Hi, everyone. Thank you for your viewing and comments on the proposal. Sorry that the rough plan is kind of mess and now I've rewritten this part a little more like a Time Schedule. I appreciate it if you have a glance at it. >From now to 27th, May. Work on some basic knowledge such as the usage of WineTestBot, getting familiar to debugging in wine or so, with help of the community, and do some favor if possible. 28th, May to 16th, June. Have interviews with the mentor at any time if convenient. Put forward my initial frame design and make puzzles clear, then adjust the plan under the guide of the mentor. So that the testing and development plan will be settled down after this part. 17th, June to 24, June. Carry out pre-work tests on variety versions of Windows. Write test reports which definite some questions and guesses. I wish to report some bugs during this part once I found one. Some invoking tests vie different layer of dlls both some additional test code (maybe for difference between versions of windows) to the existing one in the advapi32.dll should be written. 25th, June to 24th, July. Prophase of the official development. I'll implement almost all of the registry merging feature, especially code in the server part, so that I can submit my patch and looking forward to feedbacks as early as possible. 25th, July to 31st, July. The Mid-term evaluations will be finished and submitted. 1st, Auguest to 31st, August. Second stage of the development. Implement the rest part of our scheme. In this part, changes will be real-time reported in the mailing-list and apply improvement timely to make it closer to a final product. 1st, September to 27th, September. Only clean-ups and small fix of code should be left here. I'll write and verify the final evaluations and final test results, together with other documents produced in the project. Then with some modification from the mentor it's submitted to Google. The schedule will be carried out up to speed so that I may finish ahead of the end date in each part, in which case I'd like make prepare for the next part and contritube my spare time to the commutiry, rather that only such narrowed in one project. Considering that it may be a little fuzzy in boundarys of different phases, I came up with some Possible Milestones : 1.Pre-development test works are finished. 2.Complete the mostly full test codes. 3.Merging of classes in HKCU and HKLM is implemented in server part. 4.Merging is implemented in all aviable layer. 5.Compatibility of different Windows versions are fullfilled. 6.All the work including documents are done on time. That's most of the schedule I can think of now, and I'll be very happy to improve it before submitting it to the mentor If you have futher advise, to save time and make the communication smoother. Best Regards, Guo Jian

1 0

Re: winex11.drv: Fixed XInput2 errors with mislabeled mice axis. (try 2)
by Alexandre Julliard 04 May '13

04 May '13

Christopher Cope <ccope3(a)utk.edu> writes: > @@ -286,8 +286,10 @@ static void enable_xinput2(void) > class->number, class->min, class->max, class->resolution, class->mode, > XGetAtomName( data->display, class->label )); > if (class->label == x11drv_atom( Rel_X ) || class->label == x11drv_atom( Rel_Y )) count++; > - /* workaround for drivers that don't provide labels */ > - if (!class->label && class->number <= 1 && class->mode == XIModeRelative) count++; > + /* workaround for drivers that don't provide correct labels */ > + if (((!class->label && class->number <= 1) || class->label == x11drv_atom( Abs_X ) || > + class->label == x11drv_atom( Abs_Y )) > + && class->mode == XIModeRelative) count++; The whole point of testing labels was because some platforms don't set the relative mode correctly, so this is going to break them again. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH 1/6] ole32: Added IExternalConnection support.
by Alexandre Julliard 03 May '13

03 May '13

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/ole32/compobj_private.h | 2 ++ > dlls/ole32/stubmanager.c | 16 ++++++++++++++++ > 2 files changed, 18 insertions(+) It doesn't work here: ../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so defaulthandler.c && touch defaulthandler.ok defaulthandler.c:189: Test failed: unexpected interface: {00000019-0000-0000-C000-000000000046} make: *** [defaulthandler.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] d3dcompiler: Add a LUT to find compilation targets info.
by Matteo Bruni 03 May '13

03 May '13

2013/5/2 Christian Costa <titan.costa(a)gmail.com>: > > --- > dlls/d3dcompiler_43/compiler.c | 101 +++++++++++++++++++++++------ > dlls/d3dcompiler_43/d3dcompiler_private.h | 1 > 2 files changed, 81 insertions(+), 21 deletions(-) > > diff --git a/dlls/d3dcompiler_43/compiler.c b/dlls/d3dcompiler_43/compiler.c > index 4942985..a6a9867 100644 > --- a/dlls/d3dcompiler_43/compiler.c > +++ b/dlls/d3dcompiler_43/compiler.c > @@ -490,6 +490,66 @@ HRESULT WINAPI D3DAssemble(const void *data, SIZE_T datasize, const char *filena > return hr; > } > > +struct { Please make it static const. > + const char *name; > + enum shader_type type; > + DWORD sm_major; > + DWORD sm_minor; > + DWORD level_major; > + DWORD level_minor; > + BOOL sw; > + BOOL support; > +} targets_info[] = { > + /* SM 1 */ > + { "vs_1_0", ST_VERTEX, 1, 0, 0, 0, FALSE, TRUE }, > + { "vs_1_1", ST_VERTEX, 1, 1, 0, 0, FALSE, TRUE }, > + { "ps_1_0", ST_PIXEL, 1, 0, 0, 0, FALSE, TRUE }, > + { "ps_1_1", ST_PIXEL, 1, 1, 0, 0, FALSE, FALSE }, > + { "ps_1_2", ST_PIXEL, 1, 2, 0, 0, FALSE, FALSE }, > + { "ps_1_3", ST_PIXEL, 1, 3, 0, 0, FALSE, FALSE }, > + { "ps_1_4", ST_PIXEL, 1, 4, 0, 0, FALSE, FALSE }, > + { "tx_1_0", ST_UNKNOWN, 1, 0, 0, 0, FALSE, FALSE }, > + /* SM 2 */ > + { "vs_2_0", ST_VERTEX, 2, 0, 0, 0, FALSE, TRUE }, > + { "vs_2_a", ST_VERTEX, 2, 1, 0, 0, FALSE, FALSE }, > + { "vs_2_sw", ST_VERTEX, 2, 0, 0, 0, TRUE, FALSE }, > + { "ps_2_0", ST_PIXEL, 2, 0, 0, 0, FALSE, TRUE }, > + { "ps_2_a", ST_PIXEL, 2, 1, 0, 0, FALSE, FALSE }, > + { "ps_2_b", ST_PIXEL, 2, 2, 0, 0, FALSE, FALSE }, > + { "ps_2_sw", ST_PIXEL, 2, 0, 0, 0, TRUE, FALSE }, > + { "fx_2_0", ST_UNKNOWN, 2, 0, 0, 0, FALSE, FALSE }, > + /* SM 3 */ > + { "vs_3_0", ST_VERTEX, 3, 0, 0, 0, FALSE, TRUE }, > + { "vs_3_sw", ST_VERTEX, 3, 0, 0, 0, TRUE, FALSE }, > + { "ps_3_0", ST_PIXEL, 3, 0, 0, 0, FALSE, TRUE }, > + { "ps_3_sw", ST_PIXEL, 3, 0, 0, 0, TRUE, FALSE }, > + /* SM 4 */ > + { "vs_4_0_level_9_0", ST_VERTEX, 4, 0, 9, 0, FALSE, FALSE }, > + { "vs_4_0_level_9_1", ST_VERTEX, 4, 0, 9, 1, FALSE, FALSE }, > + { "vs_4_0_level_9_3", ST_VERTEX, 4, 0, 9, 3, FALSE, FALSE }, > + { "vs_4_0", ST_VERTEX, 4, 0, 0, 0, FALSE, TRUE }, > + { "vs_4_1", ST_VERTEX, 4, 1, 0, 0, FALSE, TRUE }, > + { "ps_4_0_level_9_0", ST_PIXEL, 4, 0, 9, 0, FALSE, FALSE }, > + { "ps_4_0_level_9_1", ST_PIXEL, 4, 0, 9, 1, FALSE, FALSE }, > + { "ps_4_0_level_9_3", ST_PIXEL, 4, 0, 9, 3, FALSE, FALSE }, > + { "ps_4_0", ST_PIXEL, 4, 0, 0, 0, FALSE, TRUE }, > + { "ps_4_1", ST_PIXEL, 4, 1, 0, 0, FALSE, TRUE }, > + { "gs_4_0", ST_UNKNOWN, 4, 0, 0, 0, FALSE, FALSE }, > + { "gs_4_1", ST_UNKNOWN, 4, 1, 0, 0, FALSE, FALSE }, > + { "cs_4_0", ST_UNKNOWN, 4, 0, 0, 0, FALSE, FALSE }, > + { "cs_4_1", ST_UNKNOWN, 4, 1, 0, 0, FALSE, FALSE }, > + { "fx_4_0", ST_UNKNOWN, 4, 0, 0, 0, FALSE, FALSE }, > + { "fx_4_1", ST_UNKNOWN, 4, 1, 0, 0, FALSE, FALSE }, > + /* SM 5 */ > + { "vs_5_0", ST_VERTEX, 5, 0, 0, 0, FALSE, TRUE }, > + { "ps_5_0", ST_PIXEL, 5, 0, 0, 0, FALSE, TRUE }, > + { "hs_5_0", ST_UNKNOWN, 5, 0, 0, 0, FALSE, FALSE }, > + { "gs_5_0", ST_UNKNOWN, 5, 0, 0, 0, FALSE, FALSE }, > + { "ds_5_0", ST_UNKNOWN, 5, 0, 0, 0, FALSE, FALSE }, > + { "cs_5_0", ST_UNKNOWN, 5, 0, 0, 0, FALSE, FALSE }, > + { "fx_5_0", ST_UNKNOWN, 5, 0, 0, 0, FALSE, FALSE }, > +}; > + > static HRESULT compile_shader(const char *preproc_shader, const char *target, const char *entrypoint, > ID3DBlob **shader_blob, ID3DBlob **error_messages) > { > @@ -500,38 +560,37 @@ static HRESULT compile_shader(const char *preproc_shader, const char *target, co > ID3DBlob *buffer; > char *pos; > enum shader_type shader_type; > + ULONG i; > + ULONG nb = sizeof(targets_info) / sizeof(targets_info[0]); > > TRACE("Preprocessed shader source: %s\n", debugstr_a(preproc_shader)); > > TRACE("Parsing compilation target %s.\n", debugstr_a(target)); > - if (strlen(target) != 6 || target[1] != 's' || target[2] != '_' || target[4] != '_') > + for (i = 0; i < nb; i++) > { > - FIXME("Unknown compilation target %s.\n", debugstr_a(target)); > - return D3DERR_INVALIDCALL; > + if (!strcmp(target, targets_info[i].name)) > + { > + if (!targets_info[i].support) > + { > + FIXME("Compilation target %s not yet supported\n", debugstr_a(target)); > + return D3DERR_INVALIDCALL; > + } > + else > + { > + shader_type = targets_info[i].type; > + major = targets_info[i].sm_major; > + minor = targets_info[i].sm_minor; > + break; > + } > + } > } > > - if (target[0] == 'v') > - shader_type = ST_VERTEX; > - else if (target[0] == 'p') > - shader_type = ST_PIXEL; > - else > + if (i == nb) > { > - FIXME("Unsupported shader target type %s.\n", debugstr_a(target)); > + FIXME("Unknown compilation target %s\n", debugstr_a(target)); > return D3DERR_INVALIDCALL; > } > > - major = target[3] - '0'; > - if (major == 0 || major > 5) > - { > - FIXME("Unsupported shader target major version %d.\n", major); > - return D3DERR_INVALIDCALL; > - } > - minor = target[5] - '0'; > - if (minor > 1 || (minor == 1 && (shader_type != ST_VERTEX || major > 1))) > - { > - FIXME("Unsupported shader target minor version %d.\n", minor); > - return D3DERR_INVALIDCALL; > - } > shader = parse_hlsl_shader(preproc_shader, shader_type, major, minor, entrypoint, &messages); > > if (messages) > diff --git a/dlls/d3dcompiler_43/d3dcompiler_private.h b/dlls/d3dcompiler_43/d3dcompiler_private.h > index c8a92f1..63745e0 100644 > --- a/dlls/d3dcompiler_43/d3dcompiler_private.h > +++ b/dlls/d3dcompiler_43/d3dcompiler_private.h > @@ -51,6 +51,7 @@ enum shader_type > { > ST_VERTEX, > ST_PIXEL, > + ST_UNKNOWN > }; > I'd prefer ST_UNKNOWN to be in the first place here (so that it doesn't get pushed down when we'll add more target types) but it's not a big deal. > typedef enum BWRITER_COMPARISON_TYPE { > > > The patch is probably fine otherwise but can you check that targets in the form "vs.1.0" aren't accepted by native D3DCompile? I suppose those tokens are assembler-only, but better be safe than sorry.

2 1

IID mess
by Daniel Jeliński 03 May '13

03 May '13

Hello, I just tried compiling all of Wine with my patch series applied and, to my surprise, compilation failed. The reason was that IID_IResourceManager was already declared elsewhere. Now, according to this page: http://mikolajapp.appspot.com/uuid/query?q={56a868ac-0ad4-11ce-b03a-0020af0… Wine's strmif.h declares IID_IResourceManager, while SDK declares __declspec(uuid) as IResourceManager. SDK declares IID_IResourceManager elsewhere: http://mikolajapp.appspot.com/uuid/query?q={03741d21-87eb-11ce-8081-0080c75… I'm new to COM, so I'm not sure what exactly is the difference between IID and declspec(uuid). Could anyone explain or suggest a fix? Thanks, Daniel

2 3

Re: [PATCH 5/6] ieframe: Added more InternetExplorer object tests.
by Marvin 03 May '13

03 May '13

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=25429 Your paranoid android. === W2KPROSP4 (32 bit ie) === Timeout

1 0

Re: [AppDB] version: Only display comments section in case version has maintainers
by Hin-Tak Leung 03 May '13

03 May '13

------------------------------ On Fri, May 3, 2013 00:35 BST Rosanne DiMesio wrote: >On Thu, 2 May 2013 23:26:24 +0100 (BST) >Hin-Tak Leung <htl10(a)users.sourceforge.net> wrote: >> >> - "volunteer" is what it means: "volunteer". To try to make anybody "volunteer" in any activity any manner which is less than whole-heartedly willingly, sounds wrong. >> > >Nobody's trying to make anyone volunteer. I doubt anyone will. > >> There is no reason why the AppDB shouldn't work that way. i.e. just deal with the persistent ones, and let the individual readers skip over the occasional rest as they come. > >And who do you propose should "deal with" the persistent spammers? people who are bothered by them, or people who are paid to spend such time. I am neither. To be honest, i am more bothered by this thread (in a list which i subscribe to) than spam on appdb (which i don't). >> To ban such exchanges - between people who ask for help and might even offer incentives, and those who can offer help but not willing/possible to commit to a regular role - seem over-zealous. > >We have a perfectly good user's forum for such exchanges. > >-- >Rosanne DiMesio <dimesio(a)earthlink.net>

1 0

Re: [AppDB] version: Only display comments section in case version has maintainers
by Frédéric Delanoy 02 May '13

02 May '13

On Thu, May 2, 2013 at 7:23 PM, Rosanne DiMesio <dimesio(a)earthlink.net>wrote: > On Thu, 2 May 2013 17:57:16 +0200 > Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > > > > > This won't prevent it, but I'm not sure hiding/disabling comments won't > do > > more harm than good. > > My opinion, based on close to 5 years experience as an active AppDB admin > and maintainer, is it will inconvenience a few people, but overall do far > more good than harm, for reasons that go beyond simple spam control. The > number of unmaintained apps with an active community of commenters is > small; in most unmaintained apps, questions posted just sit there > unanswered. Users seeking help would be much better off posting on the forum. > Of course, but we don't want people to ask the same questions over and over again on the forum. I thought the whole point of the appdb entry was to centralize information on running apps with wine (comments being common to all versions of the software tested)... > Since Andre's patch (thank you, Andre) merely disables comments for > unmaintained apps, any user who really thinks it's vital that the comments > appear in a particular entry can make that happen themselves simply by > volunteering to be a maintainer. If it's not important enough to someone to > put forth the trivial effort required to do that, then it's not important > to them, period. Maintaining/testing app entries may not be so trivial for everyone, and you can't expect everyone wanting to know how to run an app to become a maintainer... Maybe merely disabling *new* (vs all) comments for unmaintained apps would also do the job??? Frédéric

3 2

Google Summer of Code 2013, Tools - Implement new control panel applets
by Brock York 02 May '13

02 May '13

Hey Everyone, I've been wanting to get into Google Summer of Code and Wine development for quite a while now. I was looking on the wine ideas page : http://wiki.winehq.org/SummerOfCode I'm interested in doing the first one: Tools - Implement new control panel applets, but am wondering what I would actually be able to do. I've done basic opengl applications before but using a library like SDL to do the lowerlevel stuff. What kind of opengl test would be preferred? Something like a port of GLXgears to wine or something that just tests if it can create a Opengl context and then exits saying success? I don't know how to test whether opengl was compiled into wine either, would that be very hard to do? I've never had write code to test if a feature was enabled before. Any suggestions on what kind of test I should try and implement would be greatly appreciated so I can try and get a proposal in. I know I'm leaving it pretty late but I only found out it was open a few hours ago. For a background of my knowledge I'm currently in my 3rd year of a computer science degree at my University, I also did a year of programming at a college. I've been using linux for 6 years but haven't been able to get to grips with programming for wine I always get confused or lost when trying to learn how wine works when trying to debug a game. I'm hoping doing something like this will be able to get me started on wine with a mentors help to guide me. Thanks. Regards Brock York

2 1

Re: [2/6] uuid: add transact.h and txdtc.h
by Frédéric Delanoy 02 May '13

02 May '13

On Wed, May 1, 2013 at 11:19 PM, Daniel Jeliński <djelinski1(a)gmail.com>wrote: > #include "msdasc.h" > > +#include "transact.h" > +#include "txdtc.h" > > A patch only adding new headers for inclusion is likely not acceptable. You should merge it with another patch making use of it. Frédéric

2 1

Re: [AppDB] version: Only display comments section in case version has maintainers
by Christopher Cope 02 May '13

02 May '13

I understand the premise, but I disagree. A lot of apps that I use don't have maintainers. However, the comments are typically helpful. I believe this should be approached differently. "André Hentschel" <nerv(a)dawncrow.de> wrote: >Am 28.04.2013 18:57, schrieb Rosanne DiMesio: >> Forced moderation of comments could work for apps with maintainers >who are doing their job, but most of the spam I recently deleted was in >unmaintained apps. My suggestion would be to block comments altogether >on unmaintained apps, not just because of spam, but because of other >inappropriate things that are not being monitored, such as posting >links to illegal downloads. As for the maintainers who clearly aren't >doing their jobs (about 20-25% of the spam I found was in entries with >maintainers), admins already have the capability of removing them. > > >--- > include/version.php | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > >diff --git a/include/version.php b/include/version.php >index 8f02b24..bf1d7ab 100644 >--- a/include/version.php >+++ b/include/version.php >@@ -1180,9 +1180,12 @@ class version { > > echo note::displayNotesForEntry($this->iVersionId); > >- // Comments Section >- if($this->iVersionId) >- Comment::view_app_comments($this->iVersionId); >+ if(sizeof($aMaintainers)>0) >+ { >+ // Display comments section in case version has >maintainers >+ if($this->iVersionId) >+ Comment::view_app_comments($this->iVersionId); >+ } > } > > public static function lookup_name($versionId) >-- >1.7.10.4

3 4

Re: Re: msi/tests: Add a trailing '\n' to an ok() call.
by Marvin 02 May '13

02 May '13

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=25396 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: msi/tests: Add a trailing '\n' to an ok() call.
by Christian Costa 02 May '13

02 May '13

2013/5/2 Francois Gouget <fgouget(a)free.fr> > --- > dlls/msi/tests/install.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/msi/tests/install.c b/dlls/msi/tests/install.c > index e5d996e..0c322be 100644 > --- a/dlls/msi/tests/install.c > +++ b/dlls/msi/tests/install.c > @@ -3110,7 +3110,7 @@ static void test_continuouscabs(void) > > /* Filename from msi is right and the one from cab is wrong */ > create_cc_test_files(); > - ok(MoveFile("test2.cab", "test2_.cab"), "Cannot rename test3.cab to > test3_.cab"); > + ok(MoveFile("test2.cab", "test2_.cab"), "Cannot rename test3.cab to > test3_.cab\n"); > create_database(msifile, cc3_tables, sizeof(cc3_tables) / > sizeof(msi_table)); > > MsiSetInternalUI(INSTALLUILEVEL_NONE, NULL); > -- > 1.7.10.4 > > > Hi François, Can you fix the typo test3 to test2 as well please ? Thanks Christian

1 0

Re: [1/6] include: add transact.h, txdtc.h and txcoord.h (try 2)
by Alexandre Julliard 02 May '13

02 May '13

Daniel Jeliński <djelinski1(a)gmail.com> writes: > From 6b7cd0b30b3eaf22d9b9bbef733163e74cc04ca8 Mon Sep 17 00:00:00 2001 > From: Daniel Jelinski <djelinski1(a)gmail.com> > Date: Wed, 1 May 2013 20:28:10 +0200 > Subject: include: add transact.h, txdtc.h and txcoord.h > > this time based on minGW headers. Originals found here: > http://sourceforge.net/apps/trac/mingw-w64/browser/experimental/headers_add… This clearly needs to be generated from idl instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

wine-patches
by Daniel Jeliński 02 May '13

02 May '13

Hello, I sent a ~200KB patch to wine-patches last night and it disappeared without a trace. I'm wondering if it got lost or just went to moderation. Regards, Daniel PS.I just resent it, still no luck.

2 1

Re: [2/4] include: added transact.idl (resend)
by Alexandre Julliard 01 May '13

01 May '13

Daniel Jeliński <djelinski1(a)gmail.com> writes: > +import "unknwn.idl"; > + > +interface ITransaction; > +interface ITransactionDispenser; > +interface ITransactionOptions; > +interface ITransactionOutcomeEvents; > +interface ITransactionCompletionEvents; > + > +/*========================================================================== > + * Transaction related types > + *==========================================================================*/ > + > +[local,pointer_default(unique)] > +interface BasicTransactionTypes > + { > + > + typedef struct BOID { > + byte rgb[16]; > + } BOID; > + > + cpp_quote("#define BOID_NULL (*((BOID*)(&IID_NULL)))") > + > + /* change the following two line together */ > + cpp_quote("#ifndef MAX_TRAN_DESC_DEFINED") /* conflicts with uimsg.h. This is temporary work around */ > + cpp_quote("#define MAX_TRAN_DESC_DEFINED") > + typedef enum TX_MISC_CONSTANTS > + { > + MAX_TRAN_DESC = 40 > + } TX_MISC_CONSTANTS; > + cpp_quote("#endif") > + > + /* Unit Of Work. */ > + > + typedef BOID XACTUOW; > + > + /* Data type for isolation level values. */ > + > + typedef LONG ISOLEVEL; > + > + /* Constants that specifiy isolation level of a transaction. */ > + > + typedef enum ISOLATIONLEVEL { > + ISOLATIONLEVEL_UNSPECIFIED = 0xFFFFFFFF, > + ISOLATIONLEVEL_CHAOS = 0x00000010, > + ISOLATIONLEVEL_READUNCOMMITTED = 0x00000100, > + ISOLATIONLEVEL_BROWSE = 0x00000100, /* Synonym for _READUNCOMITTED */ > + ISOLATIONLEVEL_CURSORSTABILITY = 0x00001000, > + ISOLATIONLEVEL_READCOMMITTED = 0x00001000, /* Synonym for _CURSORSTABILITY */ > + ISOLATIONLEVEL_REPEATABLEREAD = 0x00010000, > + ISOLATIONLEVEL_SERIALIZABLE = 0x00100000, > + ISOLATIONLEVEL_ISOLATED = 0x00100000, /* Synonym for _SERIALIZABLE */ > + } ISOLATIONLEVEL; > + > + /* Transaction information structure, used in ITransaction */ > + > + typedef struct XACTTRANSINFO { > + XACTUOW uow; /* The current unit of work */ > + ISOLEVEL isoLevel; /* The isolation level for the current UOW */ > + ULONG isoFlags; /* Values from ISOFLAG enumeration */ > + DWORD grfTCSupported; /* Flags indicating capabilities */ > + DWORD grfRMSupported; /* ... of this transaction wrt */ > + DWORD grfTCSupportedRetaining; /* ... parameters to Commit */ > + DWORD grfRMSupportedRetaining; /* ... */ > + } XACTTRANSINFO; > + > + typedef struct XACTSTATS { > + ULONG cOpen; /* The number of currently extant transactions. */ > + ULONG cCommitting; /* The number of transactions which are proceding towards committing. */ > + ULONG cCommitted; /* The number of transactions that are have been committed. */ > + ULONG cAborting; /* The number of transactions which are in the process of aborting. */ > + ULONG cAborted; /* The number of transactions that are have been aborted. */ > + ULONG cInDoubt; /* The number of transactions which are presently in doubt. */ > + ULONG cHeuristicDecision; /* The number of transactions that have completed by heuristic decision. */ > + FILETIME timeTransactionsUp; /* The amount of time that this transaction service has been up. */ > + } XACTSTATS; This is clearly a straight copy of the SDK header. You can't do that. -- Alexandre Julliard julliard(a)winehq.org

3 3

GSoC proposal
by George Stephanos 01 May '13

01 May '13

Hello wine-devel! This is my proposal as a student for Google Summer of Code 2013. I'm George Stephanos from the "Arab Academy for Science and Technology" situated in Egypt. gsteph on #winehackers I'm currently about to finish my second semester as a BSc in CS. Previous Experience: I haven't developed for Wine before though I've always been a big fan of the project. I'm fairly good with C/C++ and Python and I think I have enough Win32 API experience. I've previously developed small WinSock, DirectX and classic GUI applications (with and without MFC). I'm a freelancer. I've worked (alone) on around 25-30 projects rating 4+/5 in each. I've enrolled in Google Code-In 2010 and 2011 (which is basically GSoC for high school students) writing lots of ARM assembly code for VideoLAN (#x264dev on freenode). In 2011, I would have ranked 12th if not for an issue that occurred between VideoLAN and Google. Proposal: I've read your ideas page and the only registry task [1] has particularly caught my attention. I'm aware of what I need to do. I've read [2], [3] and [4]. I haven't yet browsed the Wine tree at all and I'll probably be missing implementation strategies but that'll hopefully be worked out with my mentor. [1] - http://wiki.winehq.org/SummerOfCode?#head-40e316e01066b5a129cd65073fa4b89dd… [2] - http://bugs.winehq.org/show_bug.cgi?id=14771 [3] - http://msdn.microsoft.com/en-us/library/windows/desktop/ms724475(v=vs.85).a… [4] - http://msdn.microsoft.com/en-us/library/windows/desktop/ms724498(v=vs.85).a… Tell me if you need more information. Hope you consider me! Thanks, George

3 2

Re: server: Map update region to children even if window just moved.
by Alexandre Julliard 01 May '13

01 May '13

Sergey Guralnik <serhio(a)etersoft.ru> writes: > @@ -1618,7 +1618,7 @@ static void set_window_pos( struct window *win, struct window *previous, > const rectangle_t old_visible_rect = win->visible_rect; > const rectangle_t old_client_rect = win->client_rect; > rectangle_t rect; > - int client_changed, frame_changed; > + int client_changed, frame_changed, frame_moved = 0; > int visible = (win->style & WS_VISIBLE) || (swp_flags & SWP_SHOWWINDOW); > > if (win->parent && !is_visible( win->parent )) visible = 0; > @@ -1727,9 +1727,10 @@ static void set_window_pos( struct window *win, struct window *previous, > client_rect->bottom - old_client_rect.bottom != y_offset || > !valid_rects || > memcmp( &valid_rects[0], client_rect, sizeof(*client_rect) )); > + frame_moved = x_offset || y_offset; > } > > - if (frame_changed || client_changed) > + if (frame_changed || client_changed || frame_moved) It doesn't make sense to have all these complicated tests if we are going to always repaint anyway, which is essentially what your patch does. There has to be more to it than that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] msi: Use next cabinet from the media table instead of failing when there is a mismatch with continuous cabinet.
by Marvin 01 May '13

01 May '13

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=25385 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 2/2] msi: Use next cabinet from the media table instead of failing when there is a mismatch with continuous cabinet.
by Hans Leidekker 01 May '13

01 May '13

On Wed, 2013-05-01 at 12:40 +0200, Christian Costa wrote: > diff --git a/dlls/msi/media.c b/dlls/msi/media.c > index 612624d..4145c76 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 => use latter one\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); The cabinet name alone can be up 256 characters so you should at least check that you're not overflowing the buffer.

2 1

winex11.drv
by Christopher Cope 01 May '13

01 May '13

I am unsure how the "enum x11drv_atoms" in the file dlls/winex11.dev/x11drv.h works. My /usr/include/Xatom.h defines XA_LAST_PREDEFINED as 68. Presumably, therefore XATOM_Rel_X and XATOM_Rel_X should be 81 and 82 respectively. However, when I dump the values I get 195 and 196. I am attempting to add XATOM_Abs_X and XATOM_Abs_X with values of 480 and 481 for a patch I'm working on. I could simply define the values elsewhere, but I assumed I should try to make it blend with the other code as much as possible. Any help is appreciated thank you.

2 4

GSoC proposal
by George Stephanos 01 May '13

01 May '13

Hello wine-devel! This is my proposal as a student for Google Summer of Code 2013. I'm George Stephanos from the "Arab Academy for Science and Technology" situated in Egypt. gsteph on #winehackers I'm currently about to finish my second semester as a BSc in CS. Previous Experience: I haven't developed for Wine before though I've always been a big fan of the project. I'm fairly good with C/C++ and Python and I think I have enough Win32 API experience. I've previously developed small WinSock, DirectX and classic GUI applications (with and without MFC). I'm a freelancer. I've worked (alone) on around 25-30 projects rating 4+/5 in each. I've enrolled in Google Code-In 2010 and 2011 (which is basically GSoC for high school students) writing lots of ARM assembly code for VideoLAN (#x264dev on freenode). In 2011, I would have ranked 12th if not for an issue that occurred between VideoLAN and Google. Proposal: I've read your ideas page and the only registry task [1] has particularly caught my attention. I'm aware of what I need to do. I've read [2], [3] and [4]. I haven't yet browsed the Wine tree at all and I'll probably be missing implementation strategies but that'll hopefully be worked out with my mentor. [1] - http://wiki.winehq.org/SummerOfCode?#head-40e316e01066b5a129cd65073fa4b89dd… [2] - http://bugs.winehq.org/show_bug.cgi?id=14771 [3] - http://msdn.microsoft.com/en-us/library/windows/desktop/ms724475(v=vs.85).a… [4] - http://msdn.microsoft.com/en-us/library/windows/desktop/ms724498(v=vs.85).a… Tell me if you need more information. Hope you consider me! Thanks, George

1 0

Re: [PATCH 2/2] gdi32: Clip font glyphs to fit within text metrics. (try 3)
by Alexandre Julliard 01 May '13

01 May '13

Sam Edwards <cfsworks(a)gmail.com> writes: > Content-wise, this is the same as try 2. However, there are two differences: > > 1. I merged the tests down into the same patch. > 2. This won't crash anymore: see patch 1 in this series. It still crashes: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff550f680 in get_glyph_outline (incoming_font=<optimized out>, glyph=<optimized out>, format=24, lpgm=0x20, abc=0x22c7d0, buflen=288, buf=0x538c4, lpmat=0x7ffff5535140) at ../../../wine/dlls/gdi32/freetype.c:6389 6389 ((unsigned int)src[hmul * x + rgb_interval * 2] << 0) | (gdb) bt #0 0x00007ffff550f680 in get_glyph_outline (incoming_font=<optimized out>, glyph=<optimized out>, format=24, lpgm=0x20, abc=0x22c7d0, buflen=288, buf=0x538c4, lpmat=0x7ffff5535140) at ../../../wine/dlls/gdi32/freetype.c:6389 #1 0x00007ffff550fd1e in freetype_GetGlyphOutline (dev=0x40df0, glyph=<optimized out>, format=<optimized out>, lpgm=0x22c9f0, buflen=288, buf=0x538c4, lpmat=0x7ffff5535140) at ../../../wine/dlls/gdi32/freetype.c:7133 #2 0x00007ffff54fcd84 in GetGlyphOutlineW (hdc=<optimized out>, uChar=103, fuFormat=17, lpgm=0x22c9f0, cbBuffer=288, lpBuffer=0x538c4, lpmat2=0x7ffff5535140) at ../../../wine/dlls/gdi32/font.c:2813 #3 0x00007ffff54c97b5 in render_string (hdc=0x490031, dib=<optimized out>, font=0x43cb0, x=95, y=11, flags=12288, str=0x51b70, count=13, dx=0x53470, clipped_rects=0x22cbb0, bounds=0x22cba0) at ../../../wine/dlls/gdi32/dibdrv/graphics.c:707 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 4/4] d3dx9_36: Remove todo in tests as it works now with last d3dxof fixes.
by Matteo Bruni 01 May '13

01 May '13

2013/4/29 Christian Costa <titan.costa(a)gmail.com>: > > --- > dlls/d3dx9_36/tests/xfile.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/d3dx9_36/tests/xfile.c b/dlls/d3dx9_36/tests/xfile.c > index 1238bcd..e514a5f 100644 > --- a/dlls/d3dx9_36/tests/xfile.c > +++ b/dlls/d3dx9_36/tests/xfile.c > @@ -77,7 +77,7 @@ static void test_templates(void) > ok(ret == D3DXFERR_BADFILEFLOATSIZE, "RegisterTemplates returned %#x, expected %#x\n", ret, D3DXFERR_BADFILEFLOATSIZE); > > ret = d3dxfile->lpVtbl->RegisterTemplates(d3dxfile, templates_parse_error, sizeof(templates_parse_error) - 1); > - todo_wine ok(ret == D3DXFERR_PARSEERROR, "RegisterTemplates returned %#x, expected %#x\n", ret, D3DXFERR_PARSEERROR); > + ok(ret == D3DXFERR_PARSEERROR, "RegisterTemplates returned %#x, expected %#x\n", ret, D3DXFERR_PARSEERROR); > > ret = d3dxfile->lpVtbl->RegisterTemplates(d3dxfile, templates, sizeof(templates) - 1); > ok(ret == S_OK, "RegisterTemplates failed with %#x\n", ret); Hi Christian, good catch for that todo_wine. However, this should be merged with the patch actually fixing the test (I guess it's patch 2).

2 1

Re: [1/4] xolehlp: fix calling convention
by Nikolay Sivov 01 May '13

01 May '13

On 5/1/2013 01:43, Daniel Jeliński wrote: Please fix spec file accordingly.

2 2

Re: [PATCH 1/2] gdi32: Clip font glyphs to fit within text metrics. (try 2)
by Alexandre Julliard 30 Apr '13

30 Apr '13

Sam Edwards <cfsworks(a)gmail.com> writes: > From a2905abf287ff1ac44c93119d76b14b6fc3992c3 Mon Sep 17 00:00:00 2001 > From: Sam Edwards <CFSworks(a)gmail.com> > Date: Sat, 20 Apr 2013 05:48:07 -0600 > Subject: gdi32: Clip font glyphs to fit within text metrics. It doesn't work here: ../../../../wine/tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so ../../../../wine/dlls/comctl32/tests/listview.c && touch listview.ok wine: Unhandled page fault on write access to 0x400053b34 at address 0x2b4c3d69e6b7 (thread 0398), starting debugger... winedbg: Internal crash at 0x2b53f78066b7 make: *** [listview.ok] Error 84 -- Alexandre Julliard julliard(a)winehq.org

3 5

Re: [2/2] include: Make KNONVOLATILE_CONTEXT_POINTERS match PSDK definition.
by Dmitry Timoshkov 30 Apr '13

30 Apr '13

Hi, This patch has status "Build failure", but it compiles without errors here with 32 and 64-builds. What kind of a failure is that? -- Dmitry.

2 1

Re: kernel32: Add some tests for PEB and loader locks.
by Marvin 30 Apr '13

30 Apr '13

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=25367 Your paranoid android. === TEST64_W7SP1 (32 bit loader) === loader.c:1952: Test failed: WaitForSingleObject failed: 102 loader.c:1954: Test failed: expected exit code 199, got 259 loader.c:1963: Test failed: WaitForSingleObject failed: 102 loader.c:1968: Test failed: expected 198, got 259 loader.c:1972: Test failed: expected STATUS_PROCESS_IS_TERMINATING, got 0 loader.c:2018: Test failed: expected ERROR_ACCESS_DENIED, got 487 loader.c:2028: Test failed: VirtualFreeEx should fail loader.c:2029: Test failed: expected ERROR_ACCESS_DENIED, got -559038737 loader.c:2032: Test failed: VirtualAllocEx should fail loader.c:2033: Test failed: expected ERROR_ACCESS_DENIED, got -559038737 loader.c:2042: Test failed: expected STATUS_PROCESS_IS_TERMINATING, got 0

1 0

Re: riched20: Fix richtext copy/paste to OOffice.
by Nikolay Sivov 30 Apr '13

30 Apr '13

On 4/30/2013 10:20, Sergey Guralnik wrote: > When copying cyrillic text from wordpad (or any richedit) > to Open Office document I get unreadable text. It seems > like some another codepage was used to display text. > This path solves this problem. > --- > dlls/riched20/writer.c | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > Is it really supposed to do that? Does native module help?

2 1

Re: server: Map update region to children even if window just moved.
by Sergey Guralnik 30 Apr '13

30 Apr '13

On 2013-04-25 16:06, Sergey Guralnik wrote: > --- > dlls/user32/tests/win.c | 1 - > server/window.c | 5 +++-- > 2 files changed, 3 insertions(+), 3 deletions(-) Is something wrong with this one? -- Sergey

1 0

[GSOC2013] [Tools - Winetest Graphical User Interface]
by Nouri Hamza 30 Apr '13

30 Apr '13

Hi, My name is Hamza Nouri,23 years old. I'm in my second year of computer science engineering at Esprit,Tunis,Tunisia. I'm also Candidate for “Informatique et mathématiques Appliqués à la finance et aux assurances” (I.M.A.F.A) – a one year specialized postgraduate degree in computer science and mathematics applied to finance and insurances. I've took a look at Wine and found the project very promising. and i'm excited to partipate in coding for Wine and giving a help to Wine Users around the world. Regarding my technical skills, i have an experience in c/c++, java ,php,mysql and HTML5. i've done some projects using these languages that you can find in my personnal blog (http://tunisiansimpson.blogspot.com/). Here an example of Kakuro game made with language C that i've made last year : http://tunisiansimpson.blogspot.com/2012/12/kakuro.html I'm interested in the project "Tools - Winetest Graphical User Interface". I've already installed Wine and i'm starting using it. I have no prior experience in Open Source development, and i found this a good opportunity to begin coding for the good wealth of the international community. About my availability at the summer, i'll be free starting from the 9th June. I'll be pleased if you can provide me more details about the "Tools - Winetest Graphical User Interface" project and advice me with the better ways to succed my proposal. Hamza nouri best regards. Email address : hamza.nouri(a)esprit.tn CV : docs.google.com/a/esprit.tn/file/d/0B9vfb3FMh7gDU2JrRUQ2aF9PZGM/edit CV : twitter.com/tunisiansimpson Blog : tunisiansimpson.blogspot.com/ Facebook : www.facebook.com/nourihamza89

1 0

[GSOC 2013] Tools - Implement new control panel applets
by Kaiyi Zhang 30 Apr '13

30 Apr '13

I'm Kaiyi Zhang,A Computer Science and Engineering student from Civil Aviation University of China.I hear the GSOC and I'm very Interested in this,I look through many projects until i see the "Tools - Implement new control panel applets". I have used wine for a long time,it's very useful and i love it,it is the first time i apply for the GSOC. when i see the wine is also in the list,i decide to contribute to the wine ,i have learned the c program language which required to this project, but i know the more things i need to learn..I have confidence in doing this well,one of my best technologies is using the internet ,search the information i want.. I send for this email to see if i'm on the right track. Look forward to you reply,Thanks for reading..

2 2

Re: [PATCH] kernel32: Fixed string comparision for non-canonical locale identifiers such as zh_CN VS zh-Hans on OS X.
by Ken Thomases 29 Apr '13

29 Apr '13

On Apr 29, 2013, at 3:41 PM, Qian Hong wrote: > Thanks Ken for many helps! You're welcome and, regarding the patch: looks good to me. -Ken

1 0

Re: [AppDB]: Only display comments section in case version has maintainers
by Joerg Schiermeier 29 Apr '13

29 Apr '13

Hi list, > Forced moderation of comments could work for apps with maintainers > who are doing their job, but most of the spam I recently deleted was > in unmaintained apps. This will be the first step towards a better maintained AppDB! > My suggestion would be to block comments > altogether on unmaintained apps, not just because of spam, but > because of other inappropriate things that are not being monitored, > such as posting links to illegal downloads. For me it seems to be a got idea to get the maintainers more in charge also to everything around their maintained applications. I general I would like to have this submitted patch in the actual AppDB. And if it is so bad for some maintainers, they might start a new discussion here.. Thanks to all who did some work when creating an patch and wrote some issues here! -- Kindly regards Joerg Schiermeier Bielefeld/Germany

1 0

Re: opengl32: add a test for WGL_EXT_swap_control [try 2]
by Ken Thomases 29 Apr '13

29 Apr '13

On Apr 29, 2013, at 10:42 AM, Roderick Colenbrander wrote: > Updated version of the patch which marks the failing test as todo_wine. The > final goal is to make the swap interval in the winex11 driver not global > anymore (and store it with the drawable) and add some new functionality. > <0001-opengl32-add-a-test-for-WGL_EXT_swap_control.patch> For what it's worth, the Mac driver does it (apparently) wrong but in the other way. In the Mac driver, the swap interval is currently part of the context state, so not part of the drawable. But it's definitely not global. -Ken

1 0

Re: opengl32: add a test for WGL_EXT_swap_control
by Alexandre Julliard 29 Apr '13

29 Apr '13

Roderick Colenbrander <thunderbird2k(a)gmail.com> writes: > From 1a9ce7c13bef6e600bc9893f93da8770c8fc7767 Mon Sep 17 00:00:00 2001 > From: Roderick Colenbrander <thunderbird2k(a)gmail.com> > Date: Sun, 28 Apr 2013 16:39:28 -0700 > Subject: [PATCH] opengl32: add a test for WGL_EXT_swap_control > > --- > dlls/opengl32/tests/opengl.c | 123 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 123 insertions(+) It doesn't work here: ../../../tools/runtest -q -P wine -M opengl32.dll -T ../../.. -p opengl32_test.exe.so opengl.c && touch opengl.ok opengl.c:1584: Test failed: Expected swap interval 1, got 0 make[1]: *** [opengl.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

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