October 2009 - Wine-devel - list.winehq.org

Re: d3d10
by Stefan Dösinger 31 Oct '09

31 Oct '09

Am 29.10.2009 um 21:29 schrieb Luis C. Busquets Pérez: > Dear all, > > Since d3d10effect has advanced a lot during the latest weeks I was > wondering what are the next steps that you are planning to develop. I'm still working on d3d9-related stuff only, no guarantees that the following is correct > 1. Do DepthStencil and RasterizerState present major differences in > terms of capabilities compared to D3D9? I mean that coding > ID3D10EffectDepthStencilVariable is very easy once you have > ID3D10DepthStencilState (just call > ID3D10Device_CreateDepthStencilState for > ID3D10EffectDepthStencilVariable::GetDepthStencilState and > ID3D10EffectDepthStencilVariable::GetBackingStore should only be > recovering the data from a private variable). I see no additional features in D3D10_DEPTH_STENCIL_DESC. A ID3D10Device::OMSetDepthStencilState could just call the proper IWined3DDevice::SetRenderState calls, or a depthstencilstate could contain a wined3d stateblock with the proper pre-recorded states. > Furthermore, ID3D10Device::OMSetDepthStencilState is just a bunch > of IWineD3DDevice_SetRenderState calls because I think that wined3d > already implements all the required functionality, doesn't it?. > ID3D10Device::OMGetDepthStencilState would be a bunch of > IWineD3DDevice_GetRenderState. > ID3D10EffectRasterizerVariable. presents the analogous thing > (together with ID3D10Device::RSSetState), doesn't it? For OMSetDepthStencilState, your idea seems correct, as outloned above. For GetDepthStencilState you'd probably cache the correct interface pointer in d3d10core, since an app may create more than one ID3D10DepthStencilState states and expect the one it set when it calls the getter. > 2. For ID3D10EffectBlendVariable I think that that is different. > what are the major difficulties concerning the capabilities that > D3D10 offers compared to D3D9 conerning blending and do you see them > achievable beofre this year ends? You'd probably use a ID3D10BlendState for D3D10EffectBlendVariable. D3D10_BLEND_DESC adds a few new features compared to d3d9. AlphaToCoverageEnable doesn't exist per se, but there's a MAKEFOURCC ('A','T','O','C') hack ATI and nvidia added(sorta a d3d9 "extension"). ATOC is supported by opengl multisampling afaik. So the proper way is probably to add a proper state to wined3d, and implement the atoc hack in d3d9(using the newly added wined3d state), and also use this state from d3d10. The separate blend enable isn't supported by wined3d yet, but you can just add new render states and implement them via GL_EXT_draw_buffers2. Should be pretty easy, unless EnableIndexedEXT / DisableIndexedEXT complain if you enable/disable blend on a color target that's not defined in the current FBO, which would tie blending to the render target setting. > 3. Last, for ID3D10Device::RSGetViewports/ > ID3D10Device::RSSetViewports and ID3D10Device::RSGetScissorRects/ > ID3D10Device::RSSetScissorRects, the difficulty may lay in accepting > in the wine driver more thatn one rect/viewport. Do you agree? Are > you planning an upgrade in wined3d to refer to *rect rather than > rect in the stateblock definition? The analogous question applies to > viewports. Adding different viewports to wined3d and passing them to the according GL function isn't too difficult - make the viewport and scissor rect states arrays in wined3d, and modify the Getters, Setters, stateblock apply/capture and state applying code accordingly. What may be more difficult is finding the right GL functions. This is not related to the functionality added by GL_EXT_draw_buffers2. From the MSDN docs, it seems to be related to geometry shaders, but on a quick search I couldn't find any hints in GL_EXT_geometry_shader4 and GL_EXT_gpu_shader4.

1 0

Another virus-in-wine story
by Dan Kegel 31 Oct '09

31 Oct '09

This is about the fifth article of this sort, so it's not really news anymore, but it's still fun to read about. TFA is clueless about how to clean up a wine installation (he thought uninstalling wine would do it), buts lots of readers supply the missing clue. http://linux.slashdot.org/story/09/10/24/1759213/Now-Linux-Can-Get-Viruses-…

8 13

Re: [PATCH] MSI: Shedule rename operation also for ERROR_USER_MAPPED_FILE.
by Hans Leidekker 31 Oct '09

31 Oct '09

On Saturday 31 October 2009 11:10:35 Michael Martin wrote: > Understand, > I guess ill write some wine test to check different return values for differences on mapped files. > Can you give me a pointer on where this would best fit in? > kernel32/tests/file.c: test_CopyFileW, or should i make my own function for the tests? This likely also affects CreateFile, MoveFile, etc, so I would create a new function for it. -Hans

1 0

Re: comctl32/tests: make v6 functions inline
by Nikolay Sivov 31 Oct '09

31 Oct '09

2009/10/31 André Hentschel <nerv(a)dawncrow.de>: > So that there are no warnings if tests only use the constant variables in that header. > --- > dlls/comctl32/tests/v6util.h | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/comctl32/tests/v6util.h b/dlls/comctl32/tests/v6util.h > index 21a8e4f..ae3dbbe 100644 > --- a/dlls/comctl32/tests/v6util.h > +++ b/dlls/comctl32/tests/v6util.h > @@ -56,7 +56,7 @@ static const CHAR manifest[] = > "</dependency>\n" > "</assembly>\n"; > > -static void unload_v6_module(ULONG_PTR cookie) > +static inline void unload_v6_module(ULONG_PTR cookie) > You're using old source tree. Current prototype is: --- static void unload_v6_module(ULONG_PTR cookie, HANDLE hCtx) --- Why do you need such changes? I don't think inline it's useful here.

2 1

Re: [PATCH] MSI: Shedule rename operation also for ERROR_USER_MAPPED_FILE.
by Hans Leidekker 31 Oct '09

31 Oct '09

On Saturday 31 October 2009 05:22:31 you wrote: > I haven't came across an installer yet that fails on WINE because of this. > I have jumped ahead a bit here. > > Regardless, if a file has been mapped by using CreateFileMapping/MapViewOfFile > and the CopyFile api (having the last parameter as FALSE) is used in an attempt > to overwrite it, CopyFile will of course fail. > In Windows, XP and 2k at least, GetLastError in this case will return > ERROR_USER_MAPPED_FILE. Currently WINE does not return this error code, actually > it returns ERROR_ALREADY_EXISTS which is incorrect. So that would have to be > fixed in WINE to see the problem in an msi installer. > > Im assuming Im gonna have to create a test for for kernel32/file.c showing the > wrong error set for CopyFile failing in that case before this patch can be accepted? It would need a fix as well. There's no point in checking for this error if Wine doesn't return it. -Hans

1 0

Implement source alpha plus SourceConstantAlpha combined transparency.
by Jaime Rave 31 Oct '09

31 Oct '09

Anything wrong with this patch?? It helps a lot in MSN Messenger and some other programs. http://www.winehq.org/pipermail/wine-patches/2009-October/080539.html Jaime Rave Torrres

2 1

Re: [PATCH] MSI: Shedule rename operation also for ERROR_USER_MAPPED_FILE.
by Hans Leidekker 31 Oct '09

31 Oct '09

On Friday 30 October 2009 14:10:27 Michael Martin wrote: > Add check for ERROR_USER_MAPPED_FILE in addition to ERROR_SHARING_VIOLATION > when scheduling a rename operation. ERROR_USER_MAPPED_FILE can be set when > trying to overwrite true type fonts in windows. > For more info see http://support.microsoft.com/kb/944507 Which installer is affected by this? -Hans

1 0

Order of setting audio Play/Pause state and device opening
by Joerg-Cyril.Hoehle＠t-systems.com 31 Oct '09

31 Oct '09

Ken, I was please to see your recent changes to winecoreaudio. In my quest for audio bugs, when I reviewed the code, I found the following which I believe is wrong or I don't understand. Maybe you could look at it? BTW, the code and comments are the same in both wineoss.drv and winecoreaudio.drv. In audio.c/wodPause: /* The order of the following operations is important since we can't hold * the mutex while we make an Audio Unit call. Stop the Audio Unit before * setting the PAUSED state. That's indeed what the code below does. * Although we can be in PAUSED * state with the Audio Unit still running, Quite to the contrary, PAUSED state is only set after the unit stopped. * that's harmless because the * render callback will just produce silence. I can't comment on that. The code is (error checking not shown): status = AudioOutputUnitStop(wwo->audioUnit); OSSpinLockLock(&wwo->lock); if (wwo->state == WINE_WS_PLAYING) wwo->state = WINE_WS_PAUSED; OSSpinLockUnlock(&wwo->lock); In audio.c/wodRestart: * In wodRestart, the order is reversed. Indeed. * This guarantees that we can't get into a situation where the state is * PLAYING but the Audio Unit isn't running. Quite to the contrary, PLAYING state is reached yet AudioOutputUnitStart is only called a few instructions afterwards. Likewise above, it's stopped and PLAYING state is only unset afterwards. OSSpinLockLock(&wwo->lock); if (wwo->state == WINE_WS_PAUSED) wwo->state = WINE_WS_PLAYING; OSSpinLockUnlock(&wwo->lock); status = AudioOutputUnitStart(wwo->audioUnit); Is my understanding wrong? Does the code need be changed to reflect the comments? Do the comments need correction? Thanks, Jorg Hohle

2 1

Re: wined3d: recognize Nvidia 8500 GT
by Roderick Colenbrander 30 Oct '09

30 Oct '09

We use this mechanism on purpose. We can't have hundreds of cards in the database. The real name isn't that important it is mostly cosmetic, so it is not a real bug. Roderick

2 1

Re: kernel32/tests: add more tests for Formatmessage{A,W} (try 2)
by Paul Vriens 30 Oct '09

30 Oct '09

On 10/29/2009 01:09 AM, Louis Lenders wrote: > changes: > > -fixed typo in ok-call > -removed FormatMessageW-tests (W behaves same as A) > -removed useless test for GetLastError in case FormatMessageA succeeds > > Hi Louis, These new tests introduce some test failures on several platforms: http://test.winehq.org/data/tests/kernel32:format_msg.html On Win9x/WinMe it seems like just another last error. There seems to be an issue with a particular test when run on a Windows box with no English locale (or something different about the locale): http://test.winehq.org/data/1be99033b1892aa59589e7997f4c5a0ce77e2b42/2000_w… On Vista/Win7/W2K8 there are also different last errors but some are not yet defined in our headers: 15100 : ERROR_MUI_FILE_NOT_FOUND 15105 : ERROR_MUI_FILE_NOT_LOADED Could you have a look? -- Cheers, Paul.

3 2