October 2007 - Wine-Devel - list.winehq.org

Support GCOV for Wine 1.0?

by Detlef Riekenberg

Hi. A while ago (2004), there was some work about wine with gcov, with the focus on "Picassa 2": ( http://www.cs.hmc.edu/clinic/projects/2004/google/ ) Final Report: ( http://www.cs.hmc.edu/clinic/projects/2004/google/final_report/main.pdf ) It would be nice, when we can support gcov in current Wine "out of the box". That would help us a lot, when we write more tests for the suggested Wine 1.0 Applications. GCOV: http://gcc.gnu.org/onlinedocs/gcc/Gcov.html -- By by ... Detlef

Oct. 12, 2007

Re: server: Use the security descriptor passed in when creating events.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Use a new object_attributes struct for passing the information about > whether a security descriptor is specified or not to the server. This breaks Photoshop CS2, we segfault while trying to access a security descriptor it gives us. -- Alexandre Julliard julliard(a)winehq.org

Oct. 12, 2007

Re: kernel32/locale.c: partially implement GetUserGeoID() (try2)

by Alexandre Julliard

EA Durbin <ead1234(a)hotmail.com> writes: > GEOID WINAPI GetUserGeoID( GEOCLASS GeoClass ) > { > - FIXME("%d\n",GeoClass); > - return GEOID_NOT_AVAILABLE; > + GEOID ret = GEOID_NOT_AVAILABLE; > + static const WCHAR geoW[] = {'G','e','o',0}; > + static const WCHAR nationW[] = {'N','a','t','i','o','n',0}; > + WCHAR bufferW[10], *end; The buffer is too small since it has to contain the key information too. > + switch(GeoClass){ > + case GEOCLASS_NATION: > + if((NtQueryValueKey(hSubkey, &keyW, KeyValuePartialInformation, (LPBYTE)bufferW, count, &count) == STATUS_SUCCESS) && (info->DataLength)) > + ret = strtolW((LPCWSTR)info->Data, &end, 10); You have to make sure the buffer is null-terminated. -- Alexandre Julliard julliard(a)winehq.org

Oct. 12, 2007

Re: [2/5] WineD3D: Add support for other ps 3.0 varyings

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > + usage = (usage_token & WINED3DSP_DCL_USAGE_MASK) >> WINED3DSP_DCL_USAGE_SHIFT; > + usage_idx = (usage_token & WINED3DSP_DCL_USAGEINDEX_MASK) >> WINED3DSP_DCL_USAGEINDEX_SHIFT; > + //shader_glsl_get_write_mask(register_token, reg_mask); Please clean up this sort of thing before submitting. > + switch(usage) { > + case WINED3DDECLUSAGE_BLENDWEIGHT: > + shader_addline(buffer, "varying vec4 var_blendweight;\n", i, reg_mask, reg_mask); > + break; > + > + case WINED3DDECLUSAGE_BLENDINDICES: > + shader_addline(buffer, "varying vec4 var_blendindices;\n", i, reg_mask, reg_mask); > + break; Why are you passing parameters that won't be used? -- Alexandre Julliard julliard(a)winehq.org

Oct. 12, 2007

Re: 1.0 Bugs - Microsoft Office 2003

by Francois Gouget

On Sun, 7 Oct 2007, Dan Kegel wrote: [...] > Do we want to add Microsoft Word 2003 to the "must have" apps list for 1.0? > It might delay the release. I think the only applications which should block Wine releases should be ones which are freely downloadable and for which automated tests exist (with cxtest, yawt or something). The rational is that everyone should be able to run the tests and confirm that the 'must have' applications do work. But then I might be biased... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

Oct. 12, 2007

Re: defining and revamping our bugzilla categories

by Francois Gouget

On Thu, 11 Oct 2007, Steven Edwards wrote: [...] > > gdi > > printing [...] > Yes I second this motion. The components should be named as simply as > possible. Users are going to be the ones filing the reports and > whoever is doing triage is going to have to move it around if its in > the wrong area. Abstract names like DirectX, Sound, Graphics, > Installers and Printing are a much better idea than dllnames. [...] Sounds good to me too. But just for the sake of it, I will mention that we have keywords too. So we can have broad categories like 'printing' and 'display', and dll-specific keywords like 'gdi32' and 'comctl32'. Or we can do the opposite and have broad keywords for 'printing' and 'display', and then dll-specific categories. Or we could stay with the current scheme because both of the above may be abuses of the keyword system. Up to you. One more issue to raise: is the reason why we have 'wine-' as the prefix to avoid conflicts between different products? That is, if we have a 'printing' category in the 'Wine' product, is it going to interfer with the 'printing' category of a 'Wine-doc' product? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Oct. 12, 2007

Re: kernel32: fix memory leak (found by Smatch).

by Alexandre Julliard

Lionel Debroux <lionel_debroux(a)yahoo.fr> writes: > Is there anything wrong with this patch ? I think this one is a real memory leak. nt_name is still leaked, and now you are leaking a file handle too. You really need to be more careful with these fixes. -- Alexandre Julliard julliard(a)winehq.org

Oct. 12, 2007

Re: user32 [1/7]: Increase the message timeout

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > Changelog: > * Increase the message timeout. This is making the test very slow, it needs to be done differently. Why are all these Sleeps necessary? -- Alexandre Julliard julliard(a)winehq.org

Oct. 12, 2007

Re: kernel32: fix memory leak (found by Smatch).

by Lionel Debroux

Is there anything wrong with this patch ? I think this one is a real memory leak. "WaitNamedPipeW" in dlls/kernel32/sync.c gets flagged by Michael Stefaniuc's unfree-wine.pl script for leaking "pipe_wait". pipe_wait isn't used anywhere between its allocation and the memory leak in the error path. nt_name.Length, which is used for computing sz_pipe_wait isn't modified either in those lines. Therefore, I fixed the leak in the error path by moving the allocation later in the program. 2007-10-06 Lionel Debroux <lionel_debroux(a)yahoo.fr> * dlls/kernel32/sync.c: kernel32: fix memory leak (found by Smatch). _____________________________________________________________________________ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

Oct. 12, 2007

Re: defining and revamping our bugzilla categories

by Steven Edwards

On 10/11/07, James Hawkins <truiken(a)gmail.com> wrote: > No, because not all printing problems are gdi, and if you don't have > gdi-printing, there's no need for gdi-video; just plain gdi works. > The same argument goes for gdi-video. So, we should have: > > gdi > printing > > and any bugs that are marked as wine-gdi-(printing) should be set to > one or the other. Yes I second this motion. The components should be named as simply as possible. Users are going to be the ones filing the reports and whoever is doing triage is going to have to move it around if its in the wrong area. Abstract names like DirectX, Sound, Graphics, Installers and Printing are a much better idea than dllnames. Hell I don't even know what shdocvw does really and when an application starts spewing FIXME messages that have random dllnames in them we are just going to get bad bug reports. Its much better to have abstract categories that match behavioral issues. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Oct. 12, 2007