May 2013 - Wine-Devel - list.winehq.org

[PATCH] msvcrt: fix character/byte confusion in buffer overflow branch
by Max Kellermann May 7, 2013

May 7, 2013

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: [PATCH] dlls/gdi32/freetype.c: A better divide by zero fix, report bad fonts.
by Sam Edwards May 7, 2013

May 7, 2013

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

Re: user32: Implement IMR_QUERYCHARPOSITION handling in the edit control
by Dmitry Timoshkov May 7, 2013

May 7, 2013

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 May 7, 2013

May 7, 2013

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 May 6, 2013

May 6, 2013

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 May 6, 2013

May 6, 2013

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 May 6, 2013

May 6, 2013

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 May 6, 2013

May 6, 2013

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 May 4, 2013

May 4, 2013

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 May 4, 2013

May 4, 2013

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 May 3, 2013

May 3, 2013

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 May 3, 2013

May 3, 2013

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 May 3, 2013

May 3, 2013

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 May 3, 2013

May 3, 2013

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 May 2, 2013

May 2, 2013

------------------------------ 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 May 2, 2013

May 2, 2013

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 May 2, 2013

May 2, 2013

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 May 2, 2013

May 2, 2013

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 May 2, 2013

May 2, 2013

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 May 2, 2013

May 2, 2013

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 May 2, 2013

May 2, 2013

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 May 2, 2013

May 2, 2013

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 May 2, 2013

May 2, 2013

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 May 1, 2013

May 1, 2013

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 May 1, 2013

May 1, 2013

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 May 1, 2013

May 1, 2013

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 May 1, 2013

May 1, 2013

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 May 1, 2013

May 1, 2013

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 May 1, 2013

May 1, 2013

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 May 1, 2013

May 1, 2013

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 May 1, 2013

May 1, 2013

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 May 1, 2013

May 1, 2013

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 May 1, 2013

May 1, 2013

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

2 2