March 2011 - Wine-devel - list.winehq.org

Please ban this spammer from the forum
by Rosanne DiMesio 17 Mar '11

17 Mar '11

We've had repeated spam posts from user darlingntq9 over the past couple of days. Please ban him/her from the forum. -- Rosanne DiMesio <dimesio(a)earthlink.net>

1 0

Re: [2/2] server: Make sure that CreateFile(CREATE_ALWAYS) overwrites existing file attributes.
by Alexandre Julliard 17 Mar '11

17 Mar '11

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > @@ -1829,6 +1828,11 @@ struct fd *open_fd( struct fd *root, const char *name, int flags, mode_t *mode, > return NULL; > } > ftruncate( fd->unix_fd, 0 ); > + if (flags & O_CREAT) > + { > + fchmod( fd->unix_fd, *mode ); > + fstat( fd->unix_fd, &st ); > + } You'd have to take umask into account. And I'd like to see some tests for this at the ntdll level. > @@ -178,7 +178,7 @@ static struct object *create_file( struct fd *root, const char *nameptr, data_si > switch(create) > { > case FILE_CREATE: flags = O_CREAT | O_EXCL; break; > - case FILE_OVERWRITE_IF: /* FIXME: the difference is whether we trash existing attr or not */ > + case FILE_OVERWRITE_IF: /* the difference is whether we trash existing attr or not */ It's still a FIXME. -- Alexandre Julliard julliard(a)winehq.org

1 0

Solution for "Could not find dependent assembly" error
by Alexandru Bolboaca-Diaconu 17 Mar '11

17 Mar '11

1 0

Re: mshtml,shdocvw: Initialize OLEINPLACEFRAMEINFO.cb for IOleInPlaceSite::GetWindowContext (try 2)
by Dmitry Timoshkov 17 Mar '11

17 Mar '11

Thomas Faber <thfabba(a)gmx.de> wrote: > ip_frame = NULL; > ip_uiwindow = NULL; > + frame_info.cb = sizeof(OLEINPLACEFRAMEINFO); Using sizeof(frame_info) here and in other places instead of sizeof(OLEINPLACEFRAMEINFO) would be better IMHO. -- Dmitry.

1 0

Re: wined3d/device: Avoid repeated calculations of idx and shift in IWineD3DDeviceImpl_MarkStateDirty(). (resend)
by Adam Martinson 16 Mar '11

16 Mar '11

On 03/16/2011 02:24 PM, Alexandre Julliard wrote: > Adam Martinson<amartinson(a)codeweavers.com> writes: > >> Look at any d3d app with oprofile. That function is called >> EVERYWHERE. In my testing this reduces >> IWineD3DDeviceImpl_MarkStateDirty() from 4.8% of wined3d CPU time to >> 3.3%. > What compiler are you using? I don't see any difference here. > GCC 4.4.5, running the 3DMark06 batch size tests.

2 2

re: kernel32: CreateProcessA should not call CreateProcessW directly
by Dan Kegel 16 Mar '11

16 Mar '11

Does that work when compiling with -O3 ? Maybe you need a noinline attribute, http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attribu…

2 1

winmm DriverCallback with 0 CALLBACK_WINDOW
by Joerg-Cyril.Hoehle＠t-systems.com 16 Mar '11

16 Mar '11

Hi, Testbot job #9994 proves that Wine and native differ in their handling of a 0 CALLBACK_WINDOW handle. Wine's PostMessage redirects a 0 handle to PostThreadMessage(currentThreadID()), while native finds no notification on the thread's queue in such a case. (As a consequence, Wine's player thread will send notification messages to itself ...) Alas, the test case does not allow to tell whether the difference in with - winmm:DriverCallback or - whether winmm:midiOutOpen sees the 0 handle and remap to CALLBACK_NULL internally, before ever calling DriverCallback. Likewise, a NULL CALLBACK_FUNCTION does not cause a crash since w2k, but we don't know whether winmm:DriverCallback catches that case (as Wine does nowadays) or whether winmm:wave/midi/mixer/Open remap that to maybe CALLBACK_NULL and proceed. Is there any means to tell the difference, short of writing a real driver with debug output and installing it on a native system, having native DriverCallback called directly? Any ideas? Jörg Höhle BTW, why does winealsa.drv:mixer use a custom callback mechanism instead of the generic DriverCallback that the other winmm drivers use? Historical reasons only?

2 1

lifetime of the MIDI/MIXER/WAVEOPENDESC structure?
by Joerg-Cyril.Hoehle＠t-systems.com 16 Mar '11

16 Mar '11

Hi, MSDN is silent about the lifetime of the MIDI/MIXER/WAVEOPENDESC structure that is deliverred via the W/MODM_OPEN/MXM_OPEN message to the winmm drivers (WAVEOOPENDESC is not even documented for MS-Windows (not CE) anymore). http://msdn.microsoft.com/en-us/library/ff537518%28v=vs.85%29.aspx MIDIOPENDESC IMHO, it would make a lot of sense if the structure remained allocated for the whole lifetime of the open/close cycle, so the driver need not make a copy of it. Is there anybody who knows more about this topic? Thank you, Jörg Höhle

2 1

Re: wined3d/device: Avoid repeated calculations of idx and shift in IWineD3DDeviceImpl_MarkStateDirty(). (resend)
by Alexandre Julliard 16 Mar '11

16 Mar '11

Adam Martinson <amartinson(a)codeweavers.com> writes: > --- > dlls/wined3d/device.c | 17 ++++++++--------- > 1 files changed, 8 insertions(+), 9 deletions(-) You still need to demonstrate that this is an improvement. Compilers are pretty good nowadays, and doing such micro-optimizations at the source level is usually futile. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: d3dx9_36/tests: Replace a malloc() with HeapAlloc()+HeapFree().
by Dylan Smith 16 Mar '11

16 Mar '11

On Wed, Mar 16, 2011 at 3:57 AM, Francois Gouget <fgouget(a)free.fr> wrote: > Any reason why we were not freeing glyphmetrics_float? > No reason, just a mistake on my part.

1 0