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

Re: po: Add English (Canada) resource [Take 2]
by Ken Sharp Aug. 2, 2013

Aug. 2, 2013

Please disregard this patch. I missed a couple of words and with those corrected en_CA.po becomes identical to en.po (except that "serialisation" is fuzzy) and Wine defaults to that anyway for Canadian English. Will re-submit if there are any changes (just noticed -able/-eable). Will keep an eye on the English translations. On 30/07/13 22:37, Ken Sharp wrote: > - Re-based to latest git > - Removed all the fuzzies thanks to http://www.etymonline.com/index.php > > Turns out all the -ise/-ize words used in Wine are of Latin origin anyway. > > > -------- Original Message -------- > Subject: po: Add English (Canada) resource > Date: Mon, 22 Jul 2013 19:28:51 +0100 > From: Ken Sharp <kennybobs(a)o2.co.uk> > To: wine-patches(a)winehq.org > > Canadian English follows some British/French rules but not others. > > I have left some of the -ise/-ize words fuzzy because: > > "the etymological convention that verbs derived from Greek roots are > spelled with -ize and those from Latin with -ise is preserved in that > practice." > http://en.wikipedia.org/wiki/Canadian_english#Spelling_and_dictionaries > > I tried looking for the origins of the words and I couldn't get any. The > non-fuzzies are correct. > > With British, US and Canadian I believe all the English variations (used > in Wine) are covered, except Philippines (follows US rules). > > >

1 1

Re: reg.exe: Add query function
by Nikolay Sivov Aug. 2, 2013

Aug. 2, 2013

On 8/1/2013 17:44, Hugh McMaster wrote: > This patch builds significantly on the query function stub in programs/reg.exe. The patch includes recursion for subkeys. > > Some examples of usage: > > wine reg.exe query "HKCU" > wine reg.exe query "HKCU\Console" > wine reg.exe query "HKCU\Console" /v "ScreenSize" > wine reg.exe query "HKCU\Software" /s > > --- > programs/reg/reg.c | 232 +++++++++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 221 insertions(+), 11 deletions(-) > > +static LPVOID WINAPI mem_alloc(size_t size) > +{ > + return HeapAlloc(GetProcessHeap(), 0, size); > +} > + > +static void WINAPI mem_free(LPVOID mem) > +{ > + HeapFree(GetProcessHeap(), 0, mem); > +} Why WINAPI? It's better to follow naming from existing module, there's plenty of them with similar helpers. > + case REG_SZ: > + case REG_MULTI_SZ: > + case REG_EXPAND_SZ: No tabs please. > +static void reg_output_subkey(LPWSTR key_name, LPWSTR subkeyName) > +{ > + reg_printfW(formatSW, key_name); > + > + if (subkeyName > 0) > + { > + reg_printfW(formatSW, slashW); > + reg_printfW(formatSW, subkeyName); > + reg_printfW(formatSW, newlineW); > + } > +} Comparison looks a bit odd. Also why do you need to break it down to three printf calls instead of one? > + p = strchrW(key_name,'\\'); > + if (!p) > + { > + p = 0; > + } > + else p++; I'm not sure what this is supposed to do. > + case REG_BINARY: > + case REG_NONE: > + pValue = value; > + for (i=0; i<valueSize; i++, pValue++) > + reg_printfW(formatXW, *pValue); > + break; There's no need for separate variable here nor for incrementing pointer.

2 3

Clang warns on "wrong" header guard in "config.h"
by Charles Davis Aug. 2, 2013

Aug. 2, 2013

Hi, I've been building Wine with Clang, and it (apparently, unlike GCC) produces warnings like this: ../../include/config.h:4:9: warning: 'WINE_CROSSTEST' is used as a header guard here, followed by #define of a different macro [-Wheader-guard] #ifndef WINE_CROSSTEST ^~~~~~~~~~~~~~ ../../include/config.h:5:9: note: '__WINE_CONFIG_H' is defined here; did you mean 'WINE_CROSSTEST'? #define __WINE_CONFIG_H ^~~~~~~~~~~~~~~ WINE_CROSSTEST I tracked this down to these three lines in configure.ac: AH_TOP([#ifndef WINE_CROSSTEST #define __WINE_CONFIG_H]) AH_BOTTOM([#endif /* WINE_CROSSTEST */]) These lines generate what Clang thinks is the header guard for the "config.h" header, but we know that it isn't--that header AFAICT has never had an include guard, and __WINE_CONFIG_H is just there to indicate that it's been included. Should we change the __WINE_CONFIG_H macro to be a real header guard instead, or (as I'll admit it has been in the past) is Clang broken here? I'd imagine you guys don't want to rig configure to add -Wno-header-guard to CFLAGS if you can help it. I will point out that lots of these warnings are generated when building with Clang, because (for obvious reasons) this particular header is included all over the place. It makes it harder to see real warnings (like the ones that caused AJ not to commit my last two patches). And please don't tell me to use GCC instead. I suspect that GCC might pick up a similar warning--there's been lots of cross pollination going on between GCC and Clang, so we might have to deal with this sooner or later--and I'd prefer sooner. (I know the commit that added the WINE_CROSSTEST checks is from over 3 years ago, but this warning was only added recently to Clang, which is why I'm only bringing this up now.) Chip

2 1

Re: [PATCH] d3dx9_36: Implement ID3DXEffect_FindNextValidTechnique + add tests.
by Rico Schüller Aug. 2, 2013

Aug. 2, 2013

On 02.08.2013 00:03, Christian Costa wrote: > + technique = (D3DXHANDLE)0xdeadbeef; > + hr = effect->lpVtbl->FindNextValidTechnique(effect, technique1, &technique); > + ok(hr == D3D_OK, "FindNextValidTechnique failed, got %#x, expected %#x\n", hr, D3D_OK); > + ok(technique == technique2, "Technique returned %p, expected %p\n", technique, technique2); > + > + technique = (D3DXHANDLE)0xdeadbeef; > + hr = effect->lpVtbl->FindNextValidTechnique(effect, technique2, &technique); > + ok(hr == S_FALSE, "FindNextValidTechnique, got %#x, expected %#x\n", hr, S_FALSE); Looks fine to me, but I found one minor issue. I'd write "FindNextValidTechnique failed, ..." as in the line above. Cheers Rico

1 0

Re: [11/11] apphelp: Add tests.
by Marvin Aug. 1, 2013

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

1 0

gdi32: Don't let the gdi32 driver allocate memory in the dplayx region.
by Alexei Svitkine Aug. 1, 2013

Aug. 1, 2013

Don't let the gdi32 driver allocate memory in the dplayx region. Fixes bug: http://bugs.winehq.org/show_bug.cgi?id=34095 The issue is that the dplayx code in wine needs to allocate some memory at a static address (0x50000000) and loading the Mac native gdi driver ends up using that part of the address space. This patch fixes that by reserving that part of memory while the display driver is initialized and releasing it after. --- dlls/gdi32/driver.c | 10 ++++++++++ 1 file changed, 10 insertions(+)

2 5

Re: [PATCH 1/4] d3dx9: Track ID3DXEffect::Begin/End().
by Bruno Jesus Aug. 1, 2013

Aug. 1, 2013

On Thu, Aug 1, 2013 at 9:14 AM, Rico Schüller <kgbricola(a)web.de> wrote: > --- > dlls/d3dx9_36/effect.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > + if (!This->started) > + return D3D_OK; > + > + This->started = FALSE; > + > + return D3D_OK; Sorry to bother but why not simply force false and using a single return? Best wishes, Bruno

2 1

Re: [PATCH 1/11] apphelp: Add definitions.
by Alexandre Julliard Aug. 1, 2013

Aug. 1, 2013

Mislav Blazevic <krofnica996(a)gmail.com> writes: > @@ -25,6 +26,209 @@ extern "C" { > > BOOL WINAPI ApphelpCheckShellObject(REFCLSID, BOOL, ULONGLONG *); > > +typedef enum _PATH_TYPE { > + DOS_PATH, > + NT_PATH > +} PATH_TYPE; > + > +typedef struct _DB { > + HANDLE file; > + DWORD size; > + PBYTE data; > +} DB, *PDB; > + > +typedef DWORD TAGID; > +typedef WORD TAG; > + > +#define TAGID_NULL 0x0 > +#define TAGID_ROOT 0x0 > + > +/* The above definition of TAGID_ROOT is used in winapi but doesn't make > + * sense, especially internally, because TAGID represents offset into > + * database data and there is a header at offset 0, NOT a tag. > + * Therfore, this definition should only be used internally. */ > +#define _TAGID_ROOT 0xC If it's internal it shouldn't be in the public header. In fact I don't see any of these definitions in the SDK header. -- Alexandre Julliard julliard(a)winehq.org

1 0

reg.exe: Add query function
by Hugh McMaster Aug. 1, 2013

Aug. 1, 2013

This patch significantly builds on the query function stub in programs/reg.exe. The patch includes recursion for subkeys. Some examples of usage: wine reg.exe query "HKCU" wine reg.exe query "HKCU\Console" wine reg.exe query "HKCU\Console" /v "ScreenSize" wine reg.exe query "HKCU\Software" /s --- programs/reg/reg.c | 232 +++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 221 insertions(+), 11 deletions(-)

2 2

Re: [PATCH 2/2] ddraw: Fix double to float conversion warnings
by Henri Verbeet Aug. 1, 2013

Aug. 1, 2013

On 1 August 2013 12:25, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/ddraw/executebuffer.c b/dlls/ddraw/executebuffer.c > index 2925cfa..5c12272 100644 > --- a/dlls/ddraw/executebuffer.c > +++ b/dlls/ddraw/executebuffer.c > @@ -382,10 +382,10 @@ HRESULT d3d_execute_buffer_execute(struct d3d_execute_buffer *buffer, > dst->u8.tv = src->u8.tv; > > /* Now, the matrix multiplication */ > - dst->u1.sx = (src->u1.x * mat._11) + (src->u2.y * mat._21) + (src->u3.z * mat._31) + (1.0 * mat._41); > - dst->u2.sy = (src->u1.x * mat._12) + (src->u2.y * mat._22) + (src->u3.z * mat._32) + (1.0 * mat._42); > - dst->u3.sz = (src->u1.x * mat._13) + (src->u2.y * mat._23) + (src->u3.z * mat._33) + (1.0 * mat._43); > - dst->u4.rhw = (src->u1.x * mat._14) + (src->u2.y * mat._24) + (src->u3.z * mat._34) + (1.0 * mat._44); > + dst->u1.sx = (src->u1.x * mat._11) + (src->u2.y * mat._21) + (src->u3.z * mat._31) + (1.0f * mat._41); > + dst->u2.sy = (src->u1.x * mat._12) + (src->u2.y * mat._22) + (src->u3.z * mat._32) + (1.0f * mat._42); > + dst->u3.sz = (src->u1.x * mat._13) + (src->u2.y * mat._23) + (src->u3.z * mat._33) + (1.0f * mat._43); > + dst->u4.rhw = (src->u1.x * mat._14) + (src->u2.y * mat._24) + (src->u3.z * mat._34) + (1.0f * mat._44); > I get where the 1.0f comes from, but I think you might as well just remove the multiplication completely. And please get rid of the tabs if you're resending anyway.

1 0