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

Re: [PATCH 1/3] amstream: Add CLSID_AMAudioData implementation. (try 2)

by Michael Stefaniuc

Hello Christian, On 04/03/2012 07:53 AM, Christian Costa wrote: > +/*** IUnknown methods ***/ > +static HRESULT WINAPI IAudioDataImpl_QueryInterface(IAudioData *iface, REFIID riid, void **ppv) > +{ > + AMAudioDataImpl *This = impl_from_IAudioData(iface); > + > + TRACE("(%p/%p)->(%s,%p)\n", iface, This, debugstr_guid(riid), ppv); > + > + if (IsEqualGUID(riid, &IID_IUnknown) || > + IsEqualGUID(riid, &IID_IMemoryData) || > + IsEqualGUID(riid, &IID_IAudioData)) > + { > + IUnknown_AddRef(iface); > + *ppv = This; even though MS loves to call ppv ppvObject it isn't an object but a pointer to an interface. As this object has just one interface you can get rid of This and just assign iface to *ppv. > + return S_OK; > + } > + > + ERR("(%p)->(%s,%p),not found\n", This, debugstr_guid(riid), ppv); > + return E_NOINTERFACE; > +} > + bye michael

April 3, 2012

Re: [PATCH 4/4] d3drm: Implement IDirect3DRMFrameX_GetChildren method and IDirect3DRMFrameArray interface. (resend)

by Marvin

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=17650 Your paranoid android. === WNT4WSSP6 (32 bit d3drm) === d3drm.c:472: Test failed: Invalid refcount. Expected 3 got 2 d3drm.c:480: Test failed: Invalid refcount. Expected 4 got 3 d3drm.c:482: Test failed: Invalid refcount. Expected 3 got 2

April 3, 2012

Re: [PATCH 2/3] dmsynth: Check the rigth CLSID to create the DirectMusicSynthSink object. (resend)

by Marvin

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

April 3, 2012

Re: [website] Add Portuguese translation for release 1.5.1

by Bruno Jesus

2012/4/2 Lucas Fialho Zawacki <lfzawacki(a)gmail.com>: >> + <li>Suporte a fontes redimensionáveis em recursos.</li> A more correct translation for: - Support for scalable font resources. Would be: - Suporte para recursos de fontes escaláveis. Instead of: - Suporte a fontes redimensionáveis em recursos. Maybe "redimensionáveis" instead of "escaláveis" as you first used. Best wishes, Bruno

April 3, 2012

Re: RFC: KUSER_SHARED_DATA update patch to fix bug 29168

by Joey Yandle

> > Can you use a separate process -- a Win32 service -- to update this shared memory? > Something like plugplay.exe? I don't see why not. I'll look over the plugplay.exe code and see if it looks promising. cheers, Joey

April 3, 2012

Re: RFC: KUSER_SHARED_DATA update patch to fix bug 29168

by Ken Thomases

On Apr 2, 2012, at 10:01 PM, Joey Yandle wrote: >> You need to make wineserver multithreaded then, and that idea has been >> shot down as well. > > Yes, either wine or wineserver will need a thread to set these values > with the required precision. Can you use a separate process -- a Win32 service -- to update this shared memory? Regards, Ken

April 3, 2012

Re: RFC: KUSER_SHARED_DATA update patch to fix bug 29168

by Joey Yandle

> It's been continously said that any memory sharing scheme between a client > and wineserver won't be accepeted, ever. You're the second person to make that assertion without pointing out the relevant discussion. Such assertions are not helpful. > You need to make wineserver multithreaded then, and that idea has been > shot down as well. Yes, either wine or wineserver will need a thread to set these values with the required precision. The current question is whether turning on such functionality via a registry setting is acceptable, since it is clearly not okay for the general case.

April 3, 2012

Re: RFC: KUSER_SHARED_DATA update patch to fix bug 29168

by Dmitry Timoshkov

Joey Yandle <dragon(a)dancingdragon.be> wrote: > > Why do you need to update the data in wineserver and not in the client? > > The problem is that the timer updates need to be extremely precise, or > they are worse than useless. So we can either do that in every wine > process, or do it once in wineserver and share the memory. > > On Windows, the kernel shares this memory with all applications for this > exact reason. It's been continously said that any memory sharing scheme between a client and wineserver won't be accepeted, ever. > > Consider each wineserver call just an RPC, and leave it alone, server > > doesn't run anything in the background, and can't magically update timers > > behind the client's back. > > I certainly agree that wineserver doesn't do this currently, but the > Windows kernel does, and there's no reason why wineserver can't. You need to make wineserver multithreaded then, and that idea has been shot down as well. -- Dmitry.

April 3, 2012

Re: Programmatically determining arguments to a WinAPI function

by Roger Cruz

Hi Juan, Thanks for replying. I am looking at that tool's directory and I'm not sure how to use it. There is little documentation on the sources and a google search didn't provide much help. No matter what directory I run the executables found there, they all give me this error. Is there any documentation on how to use these tools and what is their purpose? ~/sandbox/wine/sources/wine-1.3.36$ ~/sandbox/wine/sources/wine-1.3.36/tools/winapi/winapi_extract winapi_extract: You must run this tool in the main Wine directory or a sub directory Thanks Roger R. Cruz ________________________________ From: Juan Lang <juan.lang(a)gmail.com> To: Roger Cruz <roger_r_cruz(a)yahoo.com> Cc: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> Sent: Monday, April 2, 2012 3:45 PM Subject: Re: Programmatically determining arguments to a WinAPI function Hi Roger, On Mon, Apr 2, 2012 at 10:41 AM, Roger Cruz <roger_r_cruz(a)yahoo.com> wrote: > I'm looking for a way to determine programmatically what the arguments to a > Win32 API implemented in Wine are. I'm trying to implement an API > redirection stub that I can use to trace calls into all of the > Wine-implemented DLLs. My stub needs to know what each argument passed into > the Win32 API, their types and sizes, and whether they reside on the stack > or register when calling the routine and finally their return value. I think you want to look at winapi (http://source.winehq.org/source/tools/winapi/) > In researching Wine, I have come to find out two tools, winedump and > winebuild that may be helpful in doing this but I have yet to find out how > to use them correctly to get the information I seek. Maybe they just don't > have that capability or maybe I just haven't played with them enough to find > all of its uses. > > For example, I found that each DLL has a *.spec file which looks to have > some of the info I need: > > @ stdcall GetSystemTimeAsFileTime(ptr) > > Looking at the man pages, this tells me that GetSystemTimeAsFileTime takes > in an argument as a pointer but I don't see any return value information > here. Also, does this file ever represent arguments passed by value on the > stack, like a structure? If so, does it capture how big the structure is? > What about function prototypes with variable arguments (similar to > printf(...)).. are those capture in the file? Can I also assume (based on > the calling convention listed as stdcall) which arguments will be on > registers and which will be on the stack? Yes. stdcall, cdecl, and fastcall are all documented as to their calling convention. In particular, stdcall and cdecl both accept all arguments on the stack and return through EAX. (They differ in who pops arguments from the stack.) This is basic Win32 stuff, any Windows reference in the last 25+ years ought to tell you it. fastcall is more recent, but they're all up on Wikipedia: http://en.wikipedia.org/wiki/X86_calling_conventions --Juan

April 3, 2012

Re: RFC: KUSER_SHARED_DATA update patch to fix bug 29168

by Joey Yandle

> Why do you need to update the data in wineserver and not in the client? The problem is that the timer updates need to be extremely precise, or they are worse than useless. So we can either do that in every wine process, or do it once in wineserver and share the memory. On Windows, the kernel shares this memory with all applications for this exact reason. > Consider each wineserver call just an RPC, and leave it alone, server > doesn't run anything in the background, and can't magically update timers > behind the client's back. I certainly agree that wineserver doesn't do this currently, but the Windows kernel does, and there's no reason why wineserver can't.

April 3, 2012