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

Re: d3d10

by Stefan Dösinger

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.

Oct. 31, 2009

Re: Another virus-in-wine story

by Detlef Riekenberg

On Sa, 2009-10-24 at 22:07 -0700, Dan Kegel wrote: > This is about the fifth article of this sort, so it's not really news > anymore, but it's still fun to read about. > http://linux.slashdot.org/story/09/10/24/1759213/Now-Linux-Can-Get-Viruses-… The blogger mention the bad website, but the malware file change to often. Yesterday, you will get a fake "Adobe Flash Player.exe" (crash early in Wine) after redirection to a different Website (looks like facebook.com) http://www.virustotal.com/analisis/a7c8ccfd07652f8622edb3f7ea2bbb975ddb3a74… Today, you will receive "surprise.exe" (crash early in Wine) from the Website: http://www.virustotal.com/analisis/8f753cbb1ddc3edda4a0b4ec0ce14475c2ed5e58… -- By by ... Detlef

Oct. 31, 2009

Re: [PATCH] MSI: Shedule rename operation also for ERROR_USER_MAPPED_FILE.

by Hans Leidekker

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

Oct. 31, 2009

Re: msvcrt: do not overlap in strcpy (valgrind) (try 2)

by André Hentschel

Vitaliy Margolen schrieb: > André Hentschel wrote: >> diff --git a/dlls/msvcrt/math.c b/dlls/msvcrt/math.c >> index 010e1a6..08eaf73 100644 >> --- a/dlls/msvcrt/math.c >> +++ b/dlls/msvcrt/math.c >> @@ -856,7 +856,7 @@ char * CDECL _ecvt( double number, int ndigits, int *decpt, int *sign ) >> snprintf(data->efcvt_buffer, 80, "%.*le", prec - 1, number); >> /* take the decimal "point away */ >> if( prec != 1) >> - strcpy( data->efcvt_buffer + 1, data->efcvt_buffer + 2); >> + memmove( data->efcvt_buffer + 1, data->efcvt_buffer + 2, strlen(data->efcvt_buffer) ); > You don't need additional strlen. You already have a length from snprintf > (that's returned but not assigned to anything). > > Vitaliy. > > > thx again, really didnt got that. -- Best Regards, André Hentschel

Oct. 31, 2009

Re: comctl32/tests: make v6 functions inline

by André Hentschel

Nikolay Sivov schrieb: > 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) > --- oops, thank you. > Why do you need such changes? I don't think inline it's useful here. Its that old Problem that tests including that header just to use the manifest get warnings that they didnt use the static functions. Of course this warnings disappear when using inline. Maybe i should wait until my patch is finished and relies on it, but somehow its a general problem so ill send a try 2. -- Best Regards, André Hentschel

Oct. 31, 2009

Re: [PATCH] MSI: Shedule rename operation also for ERROR_USER_MAPPED_FILE.

by Hans Leidekker

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

Oct. 31, 2009

Re: [PATCH 0/3] Handling DOS drives in mountmgr (try 2)

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > I thought I fixed all the issues. What's wrong with my patches now? Many things, it's a lot more complicated than that. For instance you can't just kill the fstab support, this needs to be preserved somehow, probably on the mountmgr side. Also you can't have a single file descriptor per device, you need one for each open. -- Alexandre Julliard julliard(a)winehq.org

Oct. 31, 2009

Re: msvcrt: do not overlap in strcpy (valgrind) (try 2)

by Vitaliy Margolen

André Hentschel wrote: > > diff --git a/dlls/msvcrt/math.c b/dlls/msvcrt/math.c > index 010e1a6..08eaf73 100644 > --- a/dlls/msvcrt/math.c > +++ b/dlls/msvcrt/math.c > @@ -856,7 +856,7 @@ char * CDECL _ecvt( double number, int ndigits, int *decpt, int *sign ) > snprintf(data->efcvt_buffer, 80, "%.*le", prec - 1, number); > /* take the decimal "point away */ > if( prec != 1) > - strcpy( data->efcvt_buffer + 1, data->efcvt_buffer + 2); > + memmove( data->efcvt_buffer + 1, data->efcvt_buffer + 2, strlen(data->efcvt_buffer) ); You don't need additional strlen. You already have a length from snprintf (that's returned but not assigned to anything). Vitaliy.

Oct. 31, 2009

Re: comctl32/tests: make v6 functions inline

by Nikolay Sivov

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.

Oct. 31, 2009

Re: [PATCH 0/3] Handling DOS drives in mountmgr (try 2)

by Charles Davis

Charles Davis wrote: > Hi, > > This patch series moves drive handling over to mountmgr. Mountmgr will > now associate UNIX device files directly to its created devices instead > of having ntdll handle converting something like \??\D: to > $WINEPREFIX/dosdevices/d::. This way, we can implement storage I/O > controls in mountmgr instead of ntdll, while the storage I/O controls > already in ntdll continue to work. > > It also allows drivers to associate UNIX device files to their device > objects, paving the way for separating the driver code from ntdll. > > Since nobody's said anything about my patches, I'll have to assume > they're good. (They work for me.) > > Chip > > I thought I fixed all the issues. What's wrong with my patches now? Chip

Oct. 31, 2009