July 2012 - Wine-devel - list.winehq.org

re: Investigating iexplore/activex issues
by Dan Kegel 27 Jul '12

27 Jul '12

I'm running into a similar problem, http://bugs.winehq.org/show_bug.cgi?id=23058 If you're using a different activex control, please file a new bug, with a way for others to reproduce the problem. Any chance you could add an HTML5 mode? http://praegnanz.de/html5video/ shows a bunch of HTML5 video player components, and lists which ones have Flash fallback for old browsers. You could turn it on if you detect a Linux client, and otherwise use the old activex solution.

2 1

Re: kernel32: implement IsValidLocaleName (with tests)
by Nikolay Sivov 27 Jul '12

27 Jul '12

On 7/27/2012 06:00, Austin English wrote: > > > + if ( !locale_name.matches ) > + return FALSE; > + return TRUE; Considering recent cleanup of such constructs please return like 'return locale_name.matches != 0;' or something like that. > +static void test_IsValidLocaleName(void) > +{ > + static const WCHAR enW[] = {'e','n',0}; > + static const WCHAR enusW[] = {'e','n','-','U','S',0}; > + static const WCHAR zzW[] = {'z','z',0}; > + static const WCHAR zzzzW[] = {'z','z','-','Z','Z',0}; > + BOOL ret; Please iterate through test data so it could be easily extended in future. Also it looks like duplication, please add some invalid locale names tests for LocaleNameToLCID and if return 0 for example, simply use it for validation (you'll get covered with LOCALE_NAME_USER_DEFAULT things for example).

1 0

Re: [1/5] d3drm: Implement IDirect3DRMLight_[Get|Set]ConstantAttenuation
by André Hentschel 26 Jul '12

26 Jul '12

that's the case of "mails to the mailinglist are received weeks later", you can obviously ignore it Am 05.06.2012 23:35, schrieb André Hentschel: > --- > dlls/d3drm/light.c | 11 +++++++---- > 1 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/dlls/d3drm/light.c b/dlls/d3drm/light.c > index 12c8623..750bb5f 100644 > --- a/dlls/d3drm/light.c > +++ b/dlls/d3drm/light.c > @@ -35,6 +35,7 @@ typedef struct { > D3DRMLIGHTTYPE type; > D3DCOLOR color; > D3DVALUE range; > + D3DVALUE cattenuation; > } IDirect3DRMLightImpl; > > static inline IDirect3DRMLightImpl *impl_from_IDirect3DRMLight(IDirect3DRMLight *iface) > @@ -243,9 +244,11 @@ static HRESULT WINAPI IDirect3DRMLightImpl_SetConstantAttenuation(IDirect3DRMLig > { > IDirect3DRMLightImpl *This = impl_from_IDirect3DRMLight(iface); > > - FIXME("(%p/%p)->(%f): stub\n", iface, This, cattenuation); > + TRACE("(%p/%p)->(%f)\n", iface, This, cattenuation); > > - return E_NOTIMPL; > + This->cattenuation = cattenuation; > + > + return D3DRM_OK; > } > > static HRESULT WINAPI IDirect3DRMLightImpl_SetLinearAttenuation(IDirect3DRMLight* iface, > @@ -299,9 +302,9 @@ static D3DVALUE WINAPI IDirect3DRMLightImpl_GetConstantAttenuation(IDirect3DRMLi > { > IDirect3DRMLightImpl *This = impl_from_IDirect3DRMLight(iface); > > - FIXME("(%p/%p)->(): stub\n", iface, This); > + TRACE("(%p/%p)->()\n", iface, This); > > - return 0; > + return This->cattenuation; > } > > static D3DVALUE WINAPI IDirect3DRMLightImpl_GetLinearAttenuation(IDirect3DRMLight* iface) > > > > -- Best Regards, André Hentschel

1 0

Re: [1/2] ntdll: Implement RtlIpv4StringToAddressW.
by Thomas Faber 26 Jul '12

26 Jul '12

Hi, what can I do to get this in committable shape? I don't see how it can be reasonably split up; tests are in place. I've noticed I forgot to remove the L prefixes on character constants, which I'll correct. I'll gladly fix any other style issues. The function _could_ be implemented using strto(u)l instead of using its own conversion function, but that would require the removal of some tests as "too strict". I much prefer the "correct" version. Thanks for any input. Best regards, Tom

2 1

Apologies for yesterday's 'Marvin' spam
by Francois Gouget 26 Jul '12

26 Jul '12

I wish to apologize to everyone for yesterday's round of 'Marvin' spam. To clean up your mailboxes you can delete all the mails sent to fgouget(a)amboise.dolphin. I'm working on WineTestBot[1] and I was checking for reliability issues so I ran it through a subset of the patches on Wine's web site[2]. Before doing that I checked that it would not spam the patch authors or the patches web site status. But I missed the CC to wine-devel! I have now fixed that oversight and modified WineTestBot[3] so that by default it won't send emails to anybody but the site administrator (me in this case). [1] http://www.winehq.org/pipermail/wine-devel/2012-June/096043.html [2] http://source.winehq.org/patches/ [3] https://github.com/fgouget/winetestbot/commits/libvirt Note that the above branch is a work in progress and not all of it is suitable for use on the current production WineTestBot server. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Wine's support for reporting calling conventions
by Roger Cruz 26 Jul '12

26 Jul '12

In dlls/dbghelp/dwarf.c, there is this snippet of code which appears to hard-code the calling convention to CALL_FAR_C. Does Wine not support reporting a function's calling convention correctly then? Is it a limitation of DWARF or just that it is not implemented? I can see that DWARF has a DW_AT_calling_convention field but when I examine a Wine DLL with objdump, it does not show this field in use. /* FIXME: assuming C source code */ sig_type = symt_new_function_signature(ctx->module, ret_type, CV_CALL_FAR_C); Thanks Roger

3 5

Re: start: Support getting the file to open by AppleEvent.
by Alexandre Julliard 26 Jul '12

26 Jul '12

Per Johansson <pelle(a)morth.org> writes: > Series goal: Implement app bundle start menu / file type associations on OS X. > > > From 681ea02fb9e3df819f812e359d3fe76c77423e32 Mon Sep 17 00:00:00 2001 > From: Per Johansson <per(a)morth.org> > Date: Tue, 17 Apr 2012 21:29:13 +0200 > Subject: start: Support getting the file to open by AppleEvent. > To: wine-patches <wine-patches(a)winehq.org> > Reply-To: wine-devel <wine-devel(a)winehq.org> > > Uses a private API. You really don't want to do that. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [PATCH 1/2] ieframe: Added default action implementation for IDocHostUIHandler::GetExternal
by Nikolay Sivov 26 Jul '12

26 Jul '12

On 5/16/2012 14:21, Jacek Caban wrote: > --- > dlls/ieframe/Makefile.in | 1 + > dlls/ieframe/dochost.c | 16 ++- > dlls/ieframe/ieframe.h | 2 + > dlls/ieframe/shelluihelper.c | 378 > ++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 395 insertions(+), 2 deletions(-) > create mode 100644 dlls/ieframe/shelluihelper.c > +*ppDispatch = (IDispatch*)This->shell_ui_helper; > + IDispatch_AddRef(*ppDispatch); > + return S_OK; IShellUIHelper2 supports IDispatch, so these three lines and a cast could be replaced with one QI like: return IShellUIHelper2_QueryInterface(This->shell_ui_helper,&IID_IDispatch, (void**)ppDispatch); if I'm not missing something.

1 0

Re: [PATCH 1/9] hhctrl.ocx: Implement HH_CLOSE_ALL (resend).
by Jacek Caban 26 Jul '12

26 Jul '12

On 07/09/12 02:13, Erich E. Hoover wrote: > + case HH_CLOSE_ALL: { > + struct list *ptr; > + HHInfo *info; > + > + LIST_FOR_EACH(ptr, &window_list) > + { > + info = LIST_ENTRY(ptr, HHInfo, entry); > + TRACE("Destroying window %s.\n", debugstr_w(info->pszType)); > + if (info->WinType.hwndHelp) > + DestroyWindow(info->WinType.hwndHelp); > + list_remove(&info->entry); > + } How is it supposed to work? AFAICS you're destroying windows, removing info object from the list and forget about it. If your intention is to destroy these objects, then ReleaseHelpViewer seems more appropriate. Also moving list_remove call to ReleaseHelpViewer seems preferable, so that it's removed from the list regardless of the reason for being destroyed. Same for list_add_tail, shouldn't it be done in CreateHelpViewer? Jacek

2 4

Re: [PATCH 4/4] dsound: Resample to float, not device format
by Alexander E. Patrakov 26 Jul '12

26 Jul '12

Andrew Eikum wrote: > Before this patch, the chain is > secondary format > =(Resample)=> float > =(Reformat)=> device format > =(Mix)=> float > =(Reformat)=> device format > > Now it's > secondary format > =(Resample)=> float > =(Mix)=> float > =(Reformat)=> device format Overall, this looks like a good cleanup. However, the chart above uses the word "(Mix)" for a combination of two operations: 1) apply volume to each sample, 2) calculate sum of samples corresponding to all playing buffers. I'd like you to resend this patch with these two steps shown separately (this also applies to the copy in the comments in mixer.c). Some notes about the code: The planned optimization that groups secondary buffers by sample rate before resampling the mix of them depends on having the volume applied before resampling, not after. So these operations have to be reordered in a later patch. > void put_mono2stereo(const IDirectSoundBufferImpl *dsb, DWORD pos, DWORD channel, float value) > { > dsb->put_aux(dsb, pos, 0, value); > dsb->put_aux(dsb, pos, 1, value); > } ... > - dsb->put_aux = putbpp[dsb->device->pwfx->wBitsPerSample/8 - 1]; > + dsb->put_aux = putieee32; > > dsb->get = dsb->get_aux; > dsb->put = dsb->put_aux; ... and then dsb-> put and dsb->get are possibly overwritten Here it looks like we can also remove put_aux by always using put_ieee32 in put_mono2stereo(). > + vLeft = dsb->volpan.dwTotalLeftAmpFactor / ((float)0xFFFF); > + vRight = dsb->volpan.dwTotalRightAmpFactor / ((float)0xFFFF); If dwTotal{Left,Right}AmpFactor is not something public, then we can as well store it as a float. All of the above can, of course, be addressed later. -- Alexander E. Patrakov

1 0