April 2008 - Wine-Devel - list.winehq.org

Re: msdmo: Fix calculation of array size in bytes
by James Hawkins April 9, 2008

April 9, 2008

On Wed, Apr 9, 2008 at 4:16 PM, Andrew Talbot <andrew.talbot(a)talbotville.com> wrote: > Changelog: > msdmo: Fix calculation of array size in bytes. > > diff --git a/dlls/msdmo/dmoreg.c b/dlls/msdmo/dmoreg.c > index f6d71bd..c6eb1b6 100644 > --- a/dlls/msdmo/dmoreg.c > +++ b/dlls/msdmo/dmoreg.c > @@ -293,11 +293,11 @@ lend: > */ > HRESULT WINAPI DMOGetName(REFCLSID clsidDMO, WCHAR szName[]) > { > -#define NAME_SIZE 80 /* Size of szName[] */ > WCHAR szguid[64]; > HRESULT hres; > HKEY hrkey = 0; > HKEY hkey = 0; > + enum {max_name_len = 80}; > DWORD count; > > TRACE("%s\n", debugstr_guid(clsidDMO)); > Don't you think a static const int would be even better? -- James Hawkins

2 1

optimizations for 1.0
by Steven Edwards April 9, 2008

April 9, 2008

Hi, Given we are coming up close to the freeze, I think this may be a good time to look in to optimizations. I propose we spend some time trying different compilers and profiling Wine under different usage patterns to see what type of speedup we can get. I'm going to see if its possible to compile Wine with LLVM and I think it would be a good idea if someone with an ICC license gave it another shot. Also any gentoo users lurking, now would be a good time to go crazy with your compiler flags, run some benchmarks and file bug reports. -- 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

3 5

Implement D3DXMatrixStack_Push
by David Adam April 9, 2008

April 9, 2008

On 08/04/2008, David Adam <david.adam.cnrs at gmail.com <http://www.winehq.org/mailman/listinfo/wine-patches>> wrote: >* + This->current = This->current +1; *>* + HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, This->matrix, (This->current +1) * sizeof(D3DXMATRIX) ); *>* + if ( This->matrix == NULL ) return E_OUTOFMEMORY; * > Aside from being a bit suboptimal (doing a realloc on every push), > this probably doesn't do what you want. Consider what happens to the > size of the array when you do something like push/pop/push/pop/...etc. > > It would be better to keep track of the current stack size, and then > grow it by a factor (eg. 2 or 1.5) if a push would overflow the > current stack. > You could also consider shrinking the array again if a > pop would make it use less than a certain percentage of the current > size (eg. a third). This would increase the size of the stack exponentially. Would it be better to do this: Take a stack_size_reference (for instance 32 items) When This->current =32, then increase the size of the stack of stack_size_reference (that is 64 items now) Then when This->current is =64, again increase the size of the stack of stack_size_reference (that is 98 items now), and so on.... This would increase the size of the stack linearly instead of exponentially. In the opposite, for MatrixStack_Pop, assume that the size of the stack is 98 and This->current is 64. Then one could shrink the size of the stack from 98 to 98-size_stack_reference that is 64. > You should also assign the result of HeapReAlloc() to This->matrix > again. *I thought that HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, This->matrix, ..........);** * do exactly what you say Although it's quite possible for HeapReAlloc to just grow the > current block without changing its location, there's no guarantee it > will. The NULL check is useless this way. Thanks for your very useful feedback. David

3 4

Compile broken on Ubuntu Hardy/gutsy/feisty
by Austin English April 9, 2008

April 9, 2008

In today's git, I can't compile in either my Kubuntu Hardy or Ubuntu feisty machines. A user also reported this on wine-user (1), using Ubuntu Gutsy (64bit). Compile is failing in make depend on: make[2]: Entering directory `/home/austin/wine-git/dlls/qedit/tests' ../../../tools/makedep -C. -S../../.. -T../../.. mediadet.c qedit.rc sound_test.avi: No such file or directory sound_test.avi was first included from qedit.rc:25 make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/austin/wine-git/dlls/qedit/tests' make[1]: *** [qedit/tests/__depend__] Error 2 make[1]: Leaving directory `/home/austin/wine-git/dlls' make: *** [dlls/__depend__] Error 2 Regression test points to: austin(a)austin-desktop:~/wine-git$ git bisect good d3061d48e1c78c331b93be7a880876ebff2730dd is first bad commit commit d3061d48e1c78c331b93be7a880876ebff2730dd Author: Dan Hipschman <dsh(a)linux.ucla.edu> Date: Tue Apr 8 16:53:52 2008 -0700 qedit: Implement IMediaDet_get_OutputStreams. :040000 040000 a897c878bae291a217075d8a2db3c6d04de1ad2a 6d6e883a2629e004b361ceb844a0ca0680a1fa75 M dlls The patch below fixes it: diff --git a/dlls/qedit/tests/qedit.rc b/dlls/qedit/tests/qedit.rc index a0b8b80..733beac 100644 --- a/dlls/qedit/tests/qedit.rc +++ b/dlls/qedit/tests/qedit.rc @@ -22,5 +22,5 @@ /* @makedep: test.avi */ TEST_AVI_RES AVI_RES_TYPE test.avi -/* @makedep: sound_test.avi */ +/* @makedep: test_sound.avi */ TEST_SOUND_AVI_RES AVI_RES_TYPE test_sound.avi I'll submit it to wine-patches. (1) http://forum.winehq.org/viewtopic.php?t=498

2 1

[PATCH 3/3] user32: fix a typo. (resend)
by Lei Zhang April 9, 2008

April 9, 2008

Resending...

1 0

Re: qedit: fix compile error in qedit.rc
by Dan Hipschman April 9, 2008

April 9, 2008

On Wed, Apr 09, 2008 at 12:10:55PM -0500, Austin English wrote: > /* @makedep: test.avi */ > TEST_AVI_RES AVI_RES_TYPE test.avi > -/* @makedep: sound_test.avi */ > +/* @makedep: test_sound.avi */ > TEST_SOUND_AVI_RES AVI_RES_TYPE test_sound.avi Oops, sorry, and thanks for fixing it.

1 0

.net 2 first light on nontrivial apps
by Dan Kegel April 9, 2008

April 9, 2008

It looks like 'winetricks dotnet20' and current wine is good enough that .net support isn't quite the limiting factor anymore! See http://bugs.winehq.org/show_bug.cgi?id=8499 http://bugs.winehq.org/show_bug.cgi?id=12457 http://bugs.winehq.org/show_bug.cgi?id=12458 for three sizeable apps that actually put up their GUIs, at least briefly. MySQL Workbench actually runs well enough to explore the GUI.

2 2

Re: Updated three Power Profile functions to match MSDN
by Dmitry Timoshkov April 9, 2008

April 9, 2008

"Black Dragon" <blackdragon1157(a)gmail.com> wrote: First of all Wine doesn't accept patches from an anonymous person, please use your real name. > + if(PowerCaps.SystemS4==TRUE && PowerCaps.HiberFilePresent==TRUE) { return TRUE; } > + else return FALSE; You should never compare against TRUE, and add braces only when necessary: return PowerCaps.SystemS4 && PowerCaps.HiberFilePresent; is much shorter and clearer. > + if(PowerCaps.SystemS5==TRUE) { return TRUE; } > + else return FALSE; Same here: return PowerCaps.SystemS5; or return PowerCaps.SystemS5 != 0; > + if(PowerCaps.SystemS1==TRUE && PowerCaps.SystemS2==TRUE && PowerCaps.SystemS3==TRUE) { return true; } > + else return FALSE; Same here, also don't use 'true', it's not portable. -- Dmitry.

2 1

Re: d3dx8: D3DXGetFVFVertexSize 2/4
by H. Verbeet April 9, 2008

April 9, 2008

On 08/04/2008, Luis Busquets <luis.busquets(a)ilidium.com> wrote: > Implementation of D3DXGetFVFVertexSize. With this patch WINE responds > correctly to the tests of D3DXGetFVFVertexSize sent in patch 1/4 of today. > You have to either send the implementation first and the test afterwards, or wrap the test in a todo_wine block, and remove it when you send the implementation.

3 2

Re: LoadStringW [1/2]
by Dmitry Timoshkov April 9, 2008

April 9, 2008

"Christopher" <raccoonone(a)procyongames.com> wrote: > +static void test_LoadStringW(void) > +{ > + HINSTANCE hInst = GetModuleHandle(NULL); > + WCHAR copiedstring[128], returnedstring[128], *resourcepointer = NULL; > + int strlen, strlen2; > + > + /* Check that the string which is returned by LoadStringW matches > + the string at the pointer returned by Load StringW when called with buflen = 0 */ > + strlen = LoadStringW(hInst, 2, (WCHAR *) &resourcepointer, 0); /* get pointer to resource. */ > + ok(strlen > 0, "LoadStringW failed to get pointer to resource 2, ret %d, err %d \n", strlen, GetLastError()); > + > + strlen2 = LoadStringW(hInst, 2, returnedstring, sizeof(returnedstring) /sizeof(WCHAR)); > + ok(strlen == strlen2, "LoadStringW returned different values dependent on buflen. ret1 %d, ret2 %d \n", > + strlen, strlen2); > + ok(strlen2 > 0, "LoadStringW failed to load resource 2, ret %d, err %d \n", strlen2, GetLastError()); > + > + if(resourcepointer != NULL) > + { > + memcpy(copiedstring, resourcepointer, strlen * sizeof(WCHAR)); > + copiedstring[strlen] = '\0'; > + } > + /* check that strings match */ > + ok(!memcmp(copiedstring, returnedstring, (strlen + 1)*sizeof(WCHAR)), > + "LoadStringW returned a string that does not match the string pointed to by the pointer it returned. \ > + returnedstring = %ls, copiedstring = %ls", returnedstring, copiedstring); > +} It's not clear what this test is supposed to show. If the 1st call to LoadStringW is supposed to set resourcepointer to not NULL, why don't you test it? Then 'if(resourcepointer != NULL)' check and copying to copiedstring are not needed. Also, if the test depends on a later patch to not fail, the test should be included in the patch. -- Dmitry.

4 15