Re: ddraw: Allow creating back buffer for pre-DirectX 7 interfaces. (try 2)
Hi Roderick,
On Thursday 22 July 2010 00:23:46 Roderick Colenbrander wrote:
> Hi Oldřich,
>
> Not to discourage you, but in Wine tests serve as proof to show that a
> patch is right, so you should first get all the tests you want in. The
> bug should be fixed afterward. It is likely that the test will reveal
> new issues.
No problem. I've started with this implementation to test if the game works
and to check if the way how I've fixed it can be done that way according to
wine developpers. That would be no fun otherwise.
So if you have nothing against the way how the patch tries to fix the
BACKBUFFER creation, we can focus more on the background (see if the fix is
sufficient).
> Like I mentioned yesterday, checking memory location related
> capabilities in the surface descriptor of the created surface might be
> useful. For instance It might show that a standalone backbuffer is not
> created in video memory. If that's the case then it is something
> different from a backbuffer on the swapchain.
The function GetSurfaceDesc for DDSCAPS_BACKBUFFER-only surface on Windows XP
SP3 returns
DDSCAPS_BACKBUFFER | DDSCAPS_VIDEOMEMORY | DDSCAPS_LOCALVIDMEM
This conforms to logic in method ddraw_create_surface that adds the two flags
if they are missing.
I have prepared one test on which I tried the DirectX CreateSurface logic
specifically for BACKBUFFERs on different DirectX interface versions. I used
similar commands as in SurfaceCapsTest() in ddraw/tests/dsurface.c.
Is there something more you see that needs tests to verify if it is the same
as on Windows? As I wrote I'm a newbie in the DirectX programming, so I will
definitely need some help.
This is the only thing that blocks the game from running, so from the bug
perspective only the CreateSurface for DirectX1 interface needs fixing, because
the other operation - blitting - works (and other flip-chain modification
methods are not used and are unsupported on DirectX anyway).
When I have the CreateSurface test ready with all the DirectX interface
versions, I will send it. There is also more to fix - the usage of SURFACEDESC
and SURFACEDESC2. Windows don't accept the former version on the newer
interfaces.
For now it looks I will send 4 patches: CreateSurface BACKBUFFER tests as the
first one; tests of usage of SURFACEDESC/2 as the second one; fix of BACKBUFFER
creation as third; added checking of surface descriptor in CreateSurface as
the last one.
Cheers,
Oldrich.
> Roderick
>
> 2010/7/21 Oldřich Jedlička :
> > Hi all,
> >
> > I've made one discovery - the explicit BACKBUFFER creation (as shown in
> > logs) works only for IID_IDirectDraw interface, not for any newer (on my
> > Windows XP). I will do some more testing, add tests into a separate
> > patch and send it afterwards.
> >
> > Regards,
> > Oldrich.
> >
> > On Wednesday 21 July 2010 20:51:49 Oldřich Jedlička wrote:
> >> Old DirectX interfaces allowed creation of explicit back buffers, so
> >> move the restrictive check to DirectX 7 implementation.
> >>
> >> This fixes bug #9008.
> >> ---
> >> dlls/ddraw/ddraw.c | 35 ---
> >> 1 files changed, 28 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c
> >> index e55ac5b..9f13c8b 100644
> >> --- a/dlls/ddraw/ddraw.c
> >> +++ b/dlls/ddraw/ddraw.c
> >> @@ -2967,7 +2967,7 @@ static HRESULT
> >> ddraw_create_gdi_swapchain(IDirectDrawImpl *ddraw, IDirectDrawSur *
> >> DDERR_* if an error occurs
> >> *
> >>
> >>
> >> ** ***/ -static HRESULT WINAPI ddraw7_CreateSurface(IDirectDraw7 *iface,
> >> +static HRESULT WINAPI CreateSurface(IDirectDraw7 *iface,
> >> DDSURFACEDESC2 *DDSD, IDirectDrawSurface7 **Surf, IUnknown
> >> *UnkOuter) {
> >> IDirectDrawImpl *This = (IDirectDrawImpl *)iface;
> >> @@ -3030,8 +3030,8 @@ static HRESULT WINAPI
> >> ddraw7_CreateSurface(IDirectDraw7 *iface, return DDERR_NOEXCLUSIVEMODE;
> >> }
> >>
> >> -if(DDSD->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER |
> >> DDSCAPS_BACKBUFFER)) { -WARN("Application tried to create an
> >> explicit front or back buffer\n"); +if(DDSD->ddsCaps.dwCaps &
> >> DDSCAPS_FRONTBUFFER) { +WARN("Application tried to create an
> >> explicit front buffer\n"); LeaveCriticalSection(&ddraw_cs);
> >> return DDERR_INVALIDCAPS;
> >> }
> >> @@ -3391,6 +3391,27 @@ static HRESULT WINAPI
> >> ddraw7_CreateSurface(IDirectDraw7 *iface, return hr;
> >> }
> >>
> >> +static HRESULT WINAPI ddraw7_CreateSurface(IDirectDraw7 *iface,
> >> +DDSURFACEDESC2 *surface_desc, IDirectDrawSurface7 **surface,
> >> IUnknown *outer_unknown) +{
> >> +TRACE("iface %p, surface_desc %p, surface %p, outer_unknown %p.\n",
> >> +iface, surface_desc, surface, outer_unknown);
> >> +
> >> +if(surface_desc->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER |
> >> DDSCAPS_BACKBUFFER)) +{
> >> +
RFC: draft HLSL test suite
Hi,
First of all, let me introduce myself. I'm a young software developer
entering college this fall. I've always been interested in helping out
the WINE project, especially in the areas of DirectX and Direct3D. Dan
Kegel suggested in http://wiki.winehq.org/HLSLTestSuite that writing
an HLSL test suite might be a good place to start, so here's a draft
of a test framework and a few tests that use it. It's not complete, I
know (for one, I need to write tests for vertex shaders), but before I
go any farther, I'd like to know get peoples' opinion on the design.
Is this the way a wine HLSL test suite should look? Is there something
else I should incorporate into these tests? I'm absolutely open to
suggestions.
And lastly, I'd like to thank the wine developers for producing such a
wonderful piece of software. We really appreciate you all!
Travis Athougies.
diff --git a/dlls/d3dx9_36/tests/Makefile.in b/dlls/d3dx9_36/tests/Makefile.in
index b9ad40d..ed7857a 100644
--- a/dlls/d3dx9_36/tests/Makefile.in
+++ b/dlls/d3dx9_36/tests/Makefile.in
@@ -13,7 +13,8 @@ C_SRCS = \
math.c \
mesh.c \
shader.c \
- surface.c
+ surface.c \
+ hlsl.c
RC_SRCS = rsrc.rc
diff --git a/dlls/d3dx9_36/tests/hlsl.c b/dlls/d3dx9_36/tests/hlsl.c
new file mode 100644
index 000..9c91294
--- /dev/null
+++ b/dlls/d3dx9_36/tests/hlsl.c
@@ -0,0 +1,703 @@
+/*
+ * Copyright (C) 2010 - Travis Athougies
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ */
+#define CINTERFACE
+#define COBJMACROS
+#include "wine/test.h"
+
+#include
+#include
+#include
+#include
+#include
+
+#include "hlsl.h"
+
+/* if GEN_EXPECTED is #define'd, then we will dump the values generated by the
+ PIXEL_SHADER_TEST_LINEAR's tests. You can use this to generate the expected
+ values tables.
+*/
+
+/* Global variables, etc */
+static LPDIRECT3DVERTEXBUFFER9 geometry = 0;
+static LPDIRECT3DVERTEXSHADER9 vshader = 0;
+static LPDIRECT3DVERTEXDECLARATION9 vdeclaration = 0;
+static LPDIRECT3DDEVICE9 device = 0;
+
+#ifdef GEN_EXPECTED
+static HANDLE output = 0;
+#endif
+
+const struct vertex
+{
+float x, y, z;
+} geometry_vertices[4] = {
+{-1, -1, 0},
+{-1, 1, 0},
+{1, -1, 0},
+{1, 1, 0}
+};
+
+const D3DVERTEXELEMENT9 vdeclelements[] = {
+{0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0},
+D3DDECL_END()
+};
+
+/* For ps_3_0 shaders, we need a vertex shader */
+const char* vshader_hlsl =
+"float4 vshader(float4 pos: POSITION): POSITION \
+{ \
+ return pos; \
+} \
+";
+
+/* Generic functions to create windows, initialize Direct3D, etc. */
+static HWND create_window(void)
+{
+WNDCLASS wc = {0};
+wc.lpfnWndProc = DefWindowProc;
+wc.lpszClassName = "d3d9_test_wc";
+RegisterClass(&wc);
+
+return CreateWindow("d3d9_test_wc", "d3d9_test",
+0, 0, 0, 0, 0, 0, 0, 0, 0);
+}
+
+static IDirect3DDevice9 *init_d3d9(HMODULE d3d9_handle)
+{
+IDirect3D9 * (__stdcall * d3d9_create)(UINT SDKVersion) = 0;
+IDirect3D9 *d3d9_ptr = 0;
+IDirect3DDevice9 *device_ptr = 0;
+D3DPRESENT_PARAMETERS present_parameters;
+D3DXMATRIX projection_matrix;
+
+void* temp_geometry_vertices;
+
+LPD3DXBUFFER compiled = NULL;
+LPD3DXBUFFER errors;
+
+HRESULT hres;
+
+d3d9_create = (void *)GetProcAddress(d3d9_handle, "Direct3DCreate9");
+ok(d3d9_create != NULL, "Failed to get address of Direct3DCreate9\n");
+if (!d3d9_create) return NULL;
+
+d3d9_ptr = d3d9_create(D3D_SDK_VERSION);
+if (!d3d9_ptr)
+{
+skip("could not create D3D9\n");
+return NULL;
+}
+
+ZeroMemory(&present_parameters, sizeof(present_parameters));
+present_parameters.Windowed = TRUE;
+present_parameters.hDeviceWindow = create_window();
+present_parameters.SwapEffect = D3DSWAPEFFECT_DISCARD;
+
+hres = IDirect3D9_CreateDevice(d3d9_ptr, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, NULL, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &present_parameters, &device_ptr);
+ok(SUCCEEDED(hres), "Could not create device, IDirect3D9_CreateDevice returned: %08x", hres);
+
+/* Create the geometry on which our pixel shader will run */
+hres = IDirect3DDevice9_CreateVertexBuffer(device_ptr, 4 * sizeof(struct vertex), D3DUSAGE_WRITEONLY, 0, D3DPOOL_DEFAULT
Re: oleaut32: Remove the ignored common resource attributes.
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=3687 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found
Re: user32: Remove the ignored common resource attributes.
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=3686 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found
Re: comdlg32: Remove the ignored common resource attributes.
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=3685 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found
Re: include/wine/debug.h: ... and uses of '_ONCE' variants.
Please discard this series of patches. They will not work with compilers that do not support macros with variable numbers of arguments. While most modern compilers do provide variadic macros, some older compilers do not. To do this right a non-intuitive syntax would be required. (i.e. 'FIXME_ONCE((...));'.) Also, the current implementation is imperfect. There should be a test in 'configure' for the various kinds of variadic macro support and the conditionals should be based on what configure finds, not on the use of any particular compiler. -Max
Re: comctl32: Remove the ignored common resource attributes.
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=3684 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found
Re: [PATCH 2/2] shlwapi: Implement SHSetIniStringW
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=3668 Your paranoid android. === W98SE (32 bit ordinal) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit ordinal) === ordinal.c:604: Test failed: GetShellSecurityDescriptor should fail ordinal.c:627: Test failed: returned value is not valid SD No test summary line found === WVISTAADM (32 bit ordinal) === Timeout === W2K8SE (32 bit ordinal) === Timeout === W7PRO (32 bit ordinal) === Timeout === W7PROX64 (32 bit ordinal) === Timeout === W7PROX64 (64 bit ordinal) === Timeout
Re: [PATCH 1/2] shlwapi: Implement SHGetIniStringW
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=3667 Your paranoid android. === W98SE (32 bit ordinal) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit ordinal) === ordinal.c:603: Test failed: GetShellSecurityDescriptor should fail ordinal.c:626: Test failed: returned value is not valid SD No test summary line found === WVISTAADM (32 bit ordinal) === Timeout === W2K8SE (32 bit ordinal) === Timeout === W7PRO (32 bit ordinal) === Timeout === W7PROX64 (32 bit ordinal) === Timeout === W7PROX64 (64 bit ordinal) === Timeout
Re: ddraw: Allow creating back buffer for pre-DirectX 7 interfaces. (try 2)
Hi Oldřich,
Not to discourage you, but in Wine tests serve as proof to show that a
patch is right, so you should first get all the tests you want in. The
bug should be fixed afterward. It is likely that the test will reveal
new issues.
Like I mentioned yesterday, checking memory location related
capabilities in the surface descriptor of the created surface might be
useful. For instance It might show that a standalone backbuffer is not
created in video memory. If that's the case then it is something
different from a backbuffer on the swapchain.
Roderick
2010/7/21 Oldřich Jedlička :
> Hi all,
>
> I've made one discovery - the explicit BACKBUFFER creation (as shown in logs)
> works only for IID_IDirectDraw interface, not for any newer (on my Windows
> XP). I will do some more testing, add tests into a separate patch and send it
> afterwards.
>
> Regards,
> Oldrich.
>
>
> On Wednesday 21 July 2010 20:51:49 Oldřich Jedlička wrote:
>> Old DirectX interfaces allowed creation of explicit back buffers, so move
>> the restrictive check to DirectX 7 implementation.
>>
>> This fixes bug #9008.
>> ---
>> dlls/ddraw/ddraw.c | 35 ---
>> 1 files changed, 28 insertions(+), 7 deletions(-)
>>
>> diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c
>> index e55ac5b..9f13c8b 100644
>> --- a/dlls/ddraw/ddraw.c
>> +++ b/dlls/ddraw/ddraw.c
>> @@ -2967,7 +2967,7 @@ static HRESULT
>> ddraw_create_gdi_swapchain(IDirectDrawImpl *ddraw, IDirectDrawSur *
>> DDERR_* if an error occurs
>> *
>>
>> **
>> ***/ -static HRESULT WINAPI ddraw7_CreateSurface(IDirectDraw7 *iface,
>> +static HRESULT WINAPI CreateSurface(IDirectDraw7 *iface,
>> DDSURFACEDESC2 *DDSD, IDirectDrawSurface7 **Surf, IUnknown
>> *UnkOuter) {
>> IDirectDrawImpl *This = (IDirectDrawImpl *)iface;
>> @@ -3030,8 +3030,8 @@ static HRESULT WINAPI
>> ddraw7_CreateSurface(IDirectDraw7 *iface, return DDERR_NOEXCLUSIVEMODE;
>> }
>>
>> - if(DDSD->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER | DDSCAPS_BACKBUFFER))
>> { - WARN("Application tried to create an explicit front or back
>> buffer\n"); + if(DDSD->ddsCaps.dwCaps & DDSCAPS_FRONTBUFFER) {
>> + WARN("Application tried to create an explicit front buffer\n");
>> LeaveCriticalSection(&ddraw_cs);
>> return DDERR_INVALIDCAPS;
>> }
>> @@ -3391,6 +3391,27 @@ static HRESULT WINAPI
>> ddraw7_CreateSurface(IDirectDraw7 *iface, return hr;
>> }
>>
>> +static HRESULT WINAPI ddraw7_CreateSurface(IDirectDraw7 *iface,
>> + DDSURFACEDESC2 *surface_desc, IDirectDrawSurface7 **surface,
>> IUnknown *outer_unknown) +{
>> + TRACE("iface %p, surface_desc %p, surface %p, outer_unknown %p.\n",
>> + iface, surface_desc, surface, outer_unknown);
>> +
>> + if(surface_desc->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER |
>> DDSCAPS_BACKBUFFER)) + {
>> + if (TRACE_ON(ddraw))
>> + {
>> + TRACE(" (%p) Requesting surface desc :\n", iface);
>> + DDRAW_dump_surface_desc(surface_desc);
>> + }
>> +
>> + WARN("Application tried to create an explicit front or back
>> buffer\n"); + return DDERR_INVALIDCAPS;
>> + }
>> +
>> + return CreateSurface(iface, surface_desc, surface, outer_unknown);
>> +}
>> +
>> static HRESULT WINAPI ddraw4_CreateSurface(IDirectDraw4 *iface,
>> DDSURFACEDESC2 *surface_desc, IDirectDrawSurface4 **surface,
>> IUnknown *outer_unknown) {
>> @@ -3401,7 +3422,7 @@ static HRESULT WINAPI
>> ddraw4_CreateSurface(IDirectDraw4 *iface, TRACE("iface %p, surface_desc
>> %p, surface %p, outer_unknown %p.\n", iface, surface_desc, surface,
>> outer_unknown);
>>
>> - hr = ddraw7_CreateSurface((IDirectDraw7 *)ddraw, surface_desc,
>> (IDirectDrawSurface7 **)surface, outer_unknown); + hr =
>> CreateSurface((IDirectDraw7 *)ddraw, surface_desc, (IDirectDrawSurface7
>> **)surface, outer_unknown); impl = (IDirectDrawSurfaceImpl *)*surface;
>> if (SUCCEEDED(hr) && impl)
>> {
>> @@ -3425,7 +3446,7 @@ static HRESULT WINAPI
>> ddraw3_CreateSurface(IDirectDraw3 *iface, TRACE("iface %p, surface_desc
>> %p, surface %p, outer_unknown %p.\n", iface, surface_desc, surface,
>> outer_unknown);
>>
>> - hr = ddraw7_CreateSurface((IDirectDraw7 *)ddraw, (DDSURFACEDESC2
>> *)surface_desc, &surface7, outer_unknown); + hr =
>> CreateSurface((IDirectDraw7 *)ddraw, (DDSURFACEDESC2 *)surface_desc,
>> &surface7, outer_unknown); if (FAILED(hr))
>> {
>> *surface = NULL;
>> @@ -3453,7 +3474,7 @@ static HRESULT WINAPI
>> ddraw2_CreateSurface(IDirectDraw2 *iface, TRACE("iface %p, surface_desc
>> %p, surface %p, outer_unknown %p.\n", iface, surface_desc, surface,
>> outer_unknown);
>>
>> - hr = ddraw7_CreateSurface((IDirectDraw7 *)ddraw, (DDSURFACEDESC2
>> *)surface_desc, &surface7, outer_unknown); + hr =
>> CreateSurface((IDirectDraw7 *)ddraw, (DDSURFACEDESC2 *)surface_desc,
>> &surface7, outer_unk
Re: ddraw: Allow creating back buffer for pre-DirectX 7 interfaces. (try 2)
Hi all,
I've made one discovery - the explicit BACKBUFFER creation (as shown in logs)
works only for IID_IDirectDraw interface, not for any newer (on my Windows
XP). I will do some more testing, add tests into a separate patch and send it
afterwards.
Regards,
Oldrich.
On Wednesday 21 July 2010 20:51:49 Oldřich Jedlička wrote:
> Old DirectX interfaces allowed creation of explicit back buffers, so move
> the restrictive check to DirectX 7 implementation.
>
> This fixes bug #9008.
> ---
> dlls/ddraw/ddraw.c | 35 ---
> 1 files changed, 28 insertions(+), 7 deletions(-)
>
> diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c
> index e55ac5b..9f13c8b 100644
> --- a/dlls/ddraw/ddraw.c
> +++ b/dlls/ddraw/ddraw.c
> @@ -2967,7 +2967,7 @@ static HRESULT
> ddraw_create_gdi_swapchain(IDirectDrawImpl *ddraw, IDirectDrawSur *
> DDERR_* if an error occurs
> *
>
> **
> ***/ -static HRESULT WINAPI ddraw7_CreateSurface(IDirectDraw7 *iface,
> +static HRESULT WINAPI CreateSurface(IDirectDraw7 *iface,
> DDSURFACEDESC2 *DDSD, IDirectDrawSurface7 **Surf, IUnknown
> *UnkOuter) {
> IDirectDrawImpl *This = (IDirectDrawImpl *)iface;
> @@ -3030,8 +3030,8 @@ static HRESULT WINAPI
> ddraw7_CreateSurface(IDirectDraw7 *iface, return DDERR_NOEXCLUSIVEMODE;
> }
>
> -if(DDSD->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER | DDSCAPS_BACKBUFFER))
> { -WARN("Application tried to create an explicit front or back
> buffer\n"); +if(DDSD->ddsCaps.dwCaps & DDSCAPS_FRONTBUFFER) {
> +WARN("Application tried to create an explicit front buffer\n");
> LeaveCriticalSection(&ddraw_cs);
> return DDERR_INVALIDCAPS;
> }
> @@ -3391,6 +3391,27 @@ static HRESULT WINAPI
> ddraw7_CreateSurface(IDirectDraw7 *iface, return hr;
> }
>
> +static HRESULT WINAPI ddraw7_CreateSurface(IDirectDraw7 *iface,
> +DDSURFACEDESC2 *surface_desc, IDirectDrawSurface7 **surface,
> IUnknown *outer_unknown) +{
> +TRACE("iface %p, surface_desc %p, surface %p, outer_unknown %p.\n",
> +iface, surface_desc, surface, outer_unknown);
> +
> +if(surface_desc->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER |
> DDSCAPS_BACKBUFFER)) +{
> +if (TRACE_ON(ddraw))
> +{
> +TRACE(" (%p) Requesting surface desc :\n", iface);
> +DDRAW_dump_surface_desc(surface_desc);
> +}
> +
> +WARN("Application tried to create an explicit front or back
> buffer\n"); +return DDERR_INVALIDCAPS;
> +}
> +
> +return CreateSurface(iface, surface_desc, surface, outer_unknown);
> +}
> +
> static HRESULT WINAPI ddraw4_CreateSurface(IDirectDraw4 *iface,
> DDSURFACEDESC2 *surface_desc, IDirectDrawSurface4 **surface,
> IUnknown *outer_unknown) {
> @@ -3401,7 +3422,7 @@ static HRESULT WINAPI
> ddraw4_CreateSurface(IDirectDraw4 *iface, TRACE("iface %p, surface_desc
> %p, surface %p, outer_unknown %p.\n", iface, surface_desc, surface,
> outer_unknown);
>
> -hr = ddraw7_CreateSurface((IDirectDraw7 *)ddraw, surface_desc,
> (IDirectDrawSurface7 **)surface, outer_unknown); +hr =
> CreateSurface((IDirectDraw7 *)ddraw, surface_desc, (IDirectDrawSurface7
> **)surface, outer_unknown); impl = (IDirectDrawSurfaceImpl *)*surface;
> if (SUCCEEDED(hr) && impl)
> {
> @@ -3425,7 +3446,7 @@ static HRESULT WINAPI
> ddraw3_CreateSurface(IDirectDraw3 *iface, TRACE("iface %p, surface_desc
> %p, surface %p, outer_unknown %p.\n", iface, surface_desc, surface,
> outer_unknown);
>
> -hr = ddraw7_CreateSurface((IDirectDraw7 *)ddraw, (DDSURFACEDESC2
> *)surface_desc, &surface7, outer_unknown); +hr =
> CreateSurface((IDirectDraw7 *)ddraw, (DDSURFACEDESC2 *)surface_desc,
> &surface7, outer_unknown); if (FAILED(hr))
> {
> *surface = NULL;
> @@ -3453,7 +3474,7 @@ static HRESULT WINAPI
> ddraw2_CreateSurface(IDirectDraw2 *iface, TRACE("iface %p, surface_desc
> %p, surface %p, outer_unknown %p.\n", iface, surface_desc, surface,
> outer_unknown);
>
> -hr = ddraw7_CreateSurface((IDirectDraw7 *)ddraw, (DDSURFACEDESC2
> *)surface_desc, &surface7, outer_unknown); +hr =
> CreateSurface((IDirectDraw7 *)ddraw, (DDSURFACEDESC2 *)surface_desc,
> &surface7, outer_unknown); if (FAILED(hr))
> {
> *surface = NULL;
> @@ -3483,7 +3504,7 @@ static HRESULT WINAPI
> ddraw1_CreateSurface(IDirectDraw *iface, /* Remove front buffer flag, this
> causes failure in v7, and its added to normal * primaries anyway. */
> surface_desc->ddsCaps.dwCaps &= ~DDSCAPS_FRONTBUFFER;
> -hr = ddraw7_CreateSurface((IDirectDraw7 *)ddraw, (DDSURFACEDESC2
> *)surface_desc, &surface7, outer_unknown); +hr =
> CreateSurface((IDirectDraw7 *)ddraw, (DDSURFACEDESC2 *)surface_desc,
> &surface7, outer_unknown); if (FAILED(hr))
> {
> *surface = NULL;
Re: winhlp32 italian translation update
Hi Davide, On 07/21/2010 11:31 PM, Davide Pizzetti wrote: @@ -53,9 +53,9 @@ MAIN_MENU MENU LANGUAGE LANG_ITALIAN, SUBLANG_NEUTRAL Your tree is not up-to-date. The above per-resource LANGUAGE settings have been removed by 6e8c900d1960e804227e83826a529f075e09443e. -- Cheers, Paul.
Re: [1/5] gameux: Add initial implementation of gameux.dll
Am 21.07.2010 19:01, schrieb Mariusz Pluciński: > W dniu 19.07.2010 15:02, Henri Verbeet pisze: >> 2010/7/18 Mariusz Pluciński: >>> +static HINSTANCE hInstance; >> This is unused. >> >> You're mixing tabs and spaces, and have a couple of trailing spaces. >> >> Also: >>> + * DllRegisterServer (OLEAUT32.@) > The code of "my" regsvr.c is almost non-modified copy of the same > file in oleaut32.dll implementation. If it's bad formatted, why it > exists in official Wine code? For the same reason why intentation patches are not accepted, because it makes the use of "git blame" hard. > However, I modified my copy to fulfill Wine's formatting assumptions > and resent it. Hope it's acceptable now. > > That's the right way. -- Best Regards, André Hentschel
Re: [1/5] gameux: Add initial implementation of gameux.dll
W dniu 19.07.2010 15:02, Henri Verbeet pisze: 2010/7/18 Mariusz Pluciński: +static HINSTANCE hInstance; This is unused. You're mixing tabs and spaces, and have a couple of trailing spaces. Also: + * DllRegisterServer (OLEAUT32.@) The code of "my" regsvr.c is almost non-modified copy of the same file in oleaut32.dll implementation. If it's bad formatted, why it exists in official Wine code? However, I modified my copy to fulfill Wine's formatting assumptions and resent it. Hope it's acceptable now.
Re: [PATCH 4/4] wined3d: Use a more consistent name for the normalized texrect "extension".
On 21 July 2010 18:29, Stefan Dösinger wrote: > I'd consider normalized_texrect a GL extension for WineD3D's purposes, mostly > due to lack of reasons not to consider it a GL extension, If it's not on http://www.opengl.org/registry/, or at least making progress towards going there, it's not a GL extension.
Re: [PATCH 4/4] wined3d: Use a more consistent name for the normalized texrect "extension".
Am Mittwoch 21 Juli 2010, 14:13:59 schrieb Henri Verbeet: > On 21 July 2010 14:12, Stefan Dösinger wrote: > > Am 21.07.2010 um 13:01 schrieb Henri Verbeet: > >> Consistency with the enum name, and WINED3D_GL_EXT_NONE, > >> WINED3D_GL_EXT_COUNT and WINED3D_GL_VERSION_2_0. > > > > But those aren't extensions. > > Neither is this, which was kind of the point. OK with me in this case. I'd consider normalized_texrect a GL extension for WineD3D's purposes, mostly due to lack of reasons not to consider it a GL extension, but I am fine with either way.
Re: [1\4]wined3d: Extend IWineD3D_GetAdapterDisplayMode with an extra paramater to pass back some extra adapter info. Henri Verbeet hverbeet at gmail.com
On 21 July 2010 17:18, Louis Lenders wrote: > also thanks, i made a new patch here: http://pastebin.com/y5Kv52h0 > would that be ok? > Well, that patch can never work, but the change to WINED3DDISPLAYMODE struct is what I meant, yes. >>I also think the wined3d call should simply >>retrieve all info, d3d9ex can discard it again if it feels like it. > > I don't exactly get what you mean here. Currently we can't retrieve display > orientation as wine's EnumDisplaySettingsExW doesn't work as expected. Once > EnumDisplaySettingsExW is implemented enough (for rotated stuff), > IWineD3DImpl_GetAdapterDisplayMode will pass back the correct display > orientation. Is that what you meant by remark above? > I mean that I don't think the "rotation" argument to GetAdapterDisplayMode() should be allowed to be NULL. It probably also makes sense to properly start adding the required support from the bottom. XRandR should be able to retrieve the display rotation, but if that's not available you can just let winex11.drv return an identity rotation.
Re: wined3d: Add Nvidia 8800GTX detection
On 21 July 2010 17:30, Roderick Colenbrander wrote: > Sure, GL_*_memory_info extensions could help there but I think we > should be cautious with just adding such support to there. Over the > past few months I have seen various reports of users who run games > which say to require lets say 128MB of video memory and they just > don't work on Wine if you don't select a higher amount of video memory > in the registry. I haven't looked at this at all yet but perhaps the > current code has some tracking bugs or perhaps the fact that we don't > track video memory of managed resources perhaps confuses some games. > It could also be something else but perhaps you have seen things like > this. > Yeah. There are some flaws in our resource management and associated memory tracking, although it's also certainly possible those reports turn out to be completely unrelated to that. I'd expect that using the actual info from the card would help rather than hurt there though.
Re: wined3d: Add Nvidia 8800GTX detection
On Wed, Jul 21, 2010 at 4:02 AM, Henri Verbeet wrote: > On 21 July 2010 05:08, Roderick Colenbrander wrote: >> I think 'select_card_*' should just return the pci device id and the >> default amount of video memory should be stored in lets say the driver >> version table (a different name for the table might make sense). It > Yeah, this should be based on the card id, like the description > string. You can probably also do much of the gl_renderer matching > based on a table. Ultimately you may want to move it out of the source > code completely, into a file, or perhaps the registry. The card db > could be updated independent of Wine itself then, though at that point > you'll have to start worrying about compatibility between Wine > versions. > > Also note that while accurately detecting the total amount of video > memory is nice, GetAvailableTextureMem() is probably at least as > important. > Sure, GL_*_memory_info extensions could help there but I think we should be cautious with just adding such support to there. Over the past few months I have seen various reports of users who run games which say to require lets say 128MB of video memory and they just don't work on Wine if you don't select a higher amount of video memory in the registry. I haven't looked at this at all yet but perhaps the current code has some tracking bugs or perhaps the fact that we don't track video memory of managed resources perhaps confuses some games. It could also be something else but perhaps you have seen things like this. Roderick
[1\4]wined3d: Extend IWineD3D_GetAdapterDisplayMode with an extra paramater to pass back some extra adapter info. Henri Verbeet hverbeet at gmail.com
Hi, @Chris: thanks for the remarks, i'll adjust patch [3\4] accordingly @Henry also thanks, i made a new patch here: http://pastebin.com/y5Kv52h0 would that be ok? >I also think the wined3d call should simply >retrieve all info, d3d9ex can discard it again if it feels like it. I don't exactly get what you mean here. Currently we can't retrieve display orientation as wine's EnumDisplaySettingsExW doesn't work as expected. Once EnumDisplaySettingsExW is implemented enough (for rotated stuff), IWineD3DImpl_GetAdapterDisplayMode will pass back the correct display orientation. Is that what you meant by remark above? Regards
Re: [2/6] shdocvw: Implement InterneExplorer::ExecWB
Onsdag 21. juli 2010 15.39.56 skrev Alexander Nicolaysen Sørnes :
> Onsdag 21. juli 2010 14.43.59 skrev Jacek Caban :
> > On 7/21/10 2:08 PM, Alexander Nicolaysen Sørnes wrote:
> > > Implement InterneExplorer::ExecWB
> >
> > +
> >
> > if(IUnknown_QueryInterface(This->doc_host.document,&IID_IOleCommandTarget
> >, (LPVOID*)&Target) != S_OK) +{
> > +return E_NOTIMPL;
> >
> > It doesn't seem like a right error code.
> >
> > +} else
> > +{
> >
> > You don't really need else block if you return in if anyway.
> >
> > +HRESULT ret = IOleCommandTarget_Exec(Target,&CGID_MSHTML, cmdID,
> > cmdexecopt, pvaIn, pvaOut);
> >
> > Did you test that it should use CGID_MSHTML? I'm not saying that it's
> > wrong and writing a test for winetest would be tricky, but I'd like to
> > know that it's somehow confirmed, esp. because you depend on it in next
> > patches.
> >
> > Jacek
>
> No, I didn't test it. My only reference is MSDN, which linked to a list of
> MSHTML command identifiers for a set of valid commands.
>
> I can remove it from the patchset for now. It's only used for printing,
> which crashes anyway.
>
> Oh, and thanks for the review! :)
>
>
> Alexander
>
Just to clarify: When writing the patch, I did some research into old articles
to confirm that doing execWB() with IDM_PRINT is supposed to work.
I was unable to test it, however, because the command had been disabled in
newer IE versions due to security concerns.
Alexander N. Sørnes
Re: D3DXCreateTeapot
Why not a tea pot pouring into a wine glass then? On Wed, Jul 21, 2010 at 10:12 AM, Peter Urbanec wrote: > On 20/07/10 04:54, Ian Macfarlane wrote: >> >> Following the question as to how to implement D3DXCreateTeapot, might I >> suggest making it in the form of a wine glass? >> >> Given that is unlikely to negatively affect anything (indeed the entire >> method does border on the ridiculous) I think it would make a nice hidden >> touch. > > The geometrical properties of a wine glass and the teapot are sufficiently > different that I would argue against that. For starters, a teapot is not > symmetrical, like a wine glass would be. The handle of the teapot also > creates a topological feature that is not present in a wine glass. > > > >
Re: D3DXCreateTeapot
On 20/07/10 04:54, Ian Macfarlane wrote: Following the question as to how to implement D3DXCreateTeapot, might I suggest making it in the form of a wine glass? Given that is unlikely to negatively affect anything (indeed the entire method does border on the ridiculous) I think it would make a nice hidden touch. The geometrical properties of a wine glass and the teapot are sufficiently different that I would argue against that. For starters, a teapot is not symmetrical, like a wine glass would be. The handle of the teapot also creates a topological feature that is not present in a wine glass.
Re: kernel32: make wine_get_dos_file_name independent from drive mappings
Damjan Jovanovic writes: > Changelog: > * kernel32: make wine_get_dos_file_name independent from drive mappings > > ... by returning \\?\unix/home/user/path/to/file.txt style paths. That should actually be done in wine_unix_to_nt_file_name, and only when there is no suitable DOS drive. -- Alexandre Julliard julli...@winehq.org
Re: kernel32.dll: implementation of GetVolumePathNamesForVolumeNameA/W (try 2)
Thanks for the patch. However it has number of issues:
On 07/20/2010 08:33 PM, Tuomo Mattila wrote:
@ stdcall GetVolumeNameForVolumeMountPointW(wstr ptr long)
@ stdcall GetVolumePathNameA(str ptr long)
@ stdcall GetVolumePathNameW(wstr ptr long)
-# @ stub GetVolumePathNamesForVolumeNameA
+@ stdcall GetVolumePathNamesForVolumeNameA(str ptr long ptr)
Broken formatting.
+/* FIXME: The winxp version of this function raises an exception (access
violation) if called with a NULL volumename or volumepathname argument.
Alternatively, we might want to set an error code and return a failure */
+/*
+if (volumename == NULL || volumepathname == NULL)
That indicates that you shouldn't be doing any null checks here. Commented
out code is not accepted into Wine. Also please don't use such long lines,
especially comments. leek
+{
+return FALSE;
+}
+*/
+
+volumepathnameW = HeapAlloc(GetProcessHeap(), 0, buflen*sizeof(WCHAR));
+if (volumepathnameW == NULL) return FALSE;
This should probably set LastError as well. Need a test to verify.
+
+if ((volumenameW = FILE_name_AtoW(volumename, TRUE)) == 0) return FALSE;
You leaking volumepathnameW here.
+WCHAR volumename2string[50];
+LPWSTR volumename2 = volumename2string;
Don't do that. Unless you need to do some extra pointer arithmetic don't
create extra pointer that points to a buffer.
-FIXME("(%s, %p, %d, %p), stub!\n", debugstr_w(volumename), volumepathname,
buflen, returnlen);
You should replace FIXME with appropriate TRACE.
+if (strncmpW(volumename, volname_prefix, 11) != 0 || volumename[19] != '-'
|| volumename[24] != '-' || volumename[29] != '-' || volumename[34] != '-' ||
volumename[47] != '}')
You are not checking the length of the volumename. If it's too short you
accessing it past the end. Also comment about what exactly you are looking
for and how volume string is supposed to look like will be good.
+/* FIXME: combination of the above may set other error codes */
Such as? Need a test for that.
+memset(volumename2string, 0, sizeof(volumename2string));
Don't do this sort of thing. There is never a need to clear the entire
buffer, especially on each iteration.
+if (available_drives& (1<<(letter-'A')))
+{
+pstr[0] = letter;
+if( (GetVolumeNameForVolumeMountPointW(pathstring, volumename2,
50))&& (!strncmpW(volumename, volumename2, 50)))
Don't use magic numbers. Always use sizeof() when need a buffer size. And as
I said before you should use volumename2string directly here.
Vitaliy.
Re: [2/6] shdocvw: Implement InterneExplorer::ExecWB
Onsdag 21. juli 2010 14.43.59 skrev Jacek Caban :
> On 7/21/10 2:08 PM, Alexander Nicolaysen Sørnes wrote:
> > Implement InterneExplorer::ExecWB
>
> +
> if(IUnknown_QueryInterface(This->doc_host.document,&IID_IOleCommandTarget,
> (LPVOID*)&Target) != S_OK) +{
> +return E_NOTIMPL;
>
> It doesn't seem like a right error code.
>
> +} else
> +{
>
> You don't really need else block if you return in if anyway.
>
> +HRESULT ret = IOleCommandTarget_Exec(Target,&CGID_MSHTML, cmdID,
> cmdexecopt, pvaIn, pvaOut);
>
> Did you test that it should use CGID_MSHTML? I'm not saying that it's wrong
> and writing a test for winetest would be tricky, but I'd like to know that
> it's somehow confirmed, esp. because you depend on it in next patches.
>
> Jacek
>
No, I didn't test it. My only reference is MSDN, which linked to a list of
MSHTML command identifiers for a set of valid commands.
I can remove it from the patchset for now. It's only used for printing, which
crashes anyway.
Oh, and thanks for the review! :)
Alexander
Re: [4/6] shdocvw: Add About dialog to IE
On 7/21/10 2:09 PM, Alexander Nicolaysen Sørnes wrote:
Add About dialog to IE
+static void ie_dialog_about(HWND hwnd)
+{
+HICON icon = LoadImageW(GetModuleHandleW(0),
MAKEINTRESOURCEW(IDI_APPICON), IMAGE_ICON, 48, 48, LR_SHARED);
+
+ShellAboutW(hwnd, wszWineInternetExplorer, NULL, icon);
+}
You leak icon here.
Jacek
Re: [2/6] shdocvw: Implement InterneExplorer::ExecWB
On 7/21/10 2:08 PM, Alexander Nicolaysen Sørnes wrote:
Implement InterneExplorer::ExecWB
+if(IUnknown_QueryInterface(This->doc_host.document,&IID_IOleCommandTarget,
(LPVOID*)&Target) != S_OK)
+{
+return E_NOTIMPL;
It doesn't seem like a right error code.
+} else
+{
You don't really need else block if you return in if anyway.
+HRESULT ret = IOleCommandTarget_Exec(Target,&CGID_MSHTML, cmdID,
cmdexecopt, pvaIn, pvaOut);
Did you test that it should use CGID_MSHTML? I'm not saying that it's wrong and
writing a test for winetest would be tricky, but I'd like to know that it's
somehow confirmed, esp. because you depend on it in next patches.
Jacek
Re: [1/2] shlwapi: Partially implement SHGetShellKey (try2)
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=3649 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:595: Test failed: GetShellSecurityDescriptor should fail ordinal.c:618: Test failed: returned value is not valid SD No test summary line found === WVISTAADM (32 bit ordinal) === No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1768: Test failed: got 28 ordinal.c:1818: Test failed: got 28 ordinal.c:1826: Test failed: got 28 ordinal.c:1834: Test failed: got 39, length 40 ordinal.c:1845: Test failed: got 42 === W7PROX64 (32 bit ordinal) === ordinal.c:1768: Test failed: got 25 ordinal.c:1818: Test failed: got 25 ordinal.c:1826: Test failed: got 25 ordinal.c:1834: Test failed: got 34, length 35 ordinal.c:1845: Test failed: got 37 === W7PROX64 (64 bit ordinal) === ordinal.c:1762: Test failed: got 10 ordinal.c:1783: Test failed: got 7 ordinal.c:1796: Test failed: got 10 ordinal.c:1804: Test failed: got 10 ordinal.c:1834: Test failed: got 34, length 35 ordinal.c:1845: Test failed: got 37 ordinal.c:1856: Test failed: got 20 ordinal.c:1867: Test failed: got 23
Re: [1/6] shdocvw: Add menu bar to Internet Explorer
Hi Alexander,
On 7/21/10 2:07 PM, Alexander Nicolaysen Sørnes wrote:
This series adds a menu bar and Open URL dialog box to Wine's IE.
-FIXME("(%p)->(%x)\n", This, Value);
-return E_NOTIMPL;
+HMENU hMenu = NULL;
Please use better names (without type prefix) like 'menu'.
+
+TRACE("(%p)->(%x)\n", This, Value);
+
+if(Value == VARIANT_TRUE)
You shouldn't compare Value directly to VARIANT_TRUE.
+hMenu = LoadMenuW(shdocvw_hinstance,
MAKEINTRESOURCEW(IDR_BROWSE_MAIN_MENU));
+
+if(!SetMenu(This->frame_hwnd, hMenu))
+return HRESULT_FROM_WIN32(GetLastError());
+
+
+return S_OK;
You leak hMenu here.
Jacek
Re: [PATCH 4/4] wined3d: Use a more consistent name for the normalized texrect "extension".
On 21 July 2010 14:12, Stefan Dösinger wrote: > > Am 21.07.2010 um 13:01 schrieb Henri Verbeet: > >> On 20 July 2010 22:05, Stefan Dösinger wrote: >>> >>> Am 20.07.2010 um 18:51 schrieb Henri Verbeet: - || gl_info->supported[WINE_NORMALIZED_TEXRECT]) + || gl_info->supported[WINED3D_GL_NORMALIZED_TEXRECT]) >>> I understand the WINE->WINED3D part - it's a wined3d specific thing, >>> nothing wine global. But why did you add GL to the name? >>> >> Consistency with the enum name, and WINED3D_GL_EXT_NONE, >> WINED3D_GL_EXT_COUNT and WINED3D_GL_VERSION_2_0. > But those aren't extensions. > Neither is this, which was kind of the point.
Re: [PATCH 4/4] wined3d: Use a more consistent name for the normalized texrect "extension".
Am 21.07.2010 um 13:01 schrieb Henri Verbeet: > On 20 July 2010 22:05, Stefan Dösinger wrote: >> >> Am 20.07.2010 um 18:51 schrieb Henri Verbeet: >>> -|| gl_info->supported[WINE_NORMALIZED_TEXRECT]) >>> +|| gl_info->supported[WINED3D_GL_NORMALIZED_TEXRECT]) >> I understand the WINE->WINED3D part - it's a wined3d specific thing, nothing >> wine global. But why did you add GL to the name? >> > Consistency with the enum name, and WINED3D_GL_EXT_NONE, > WINED3D_GL_EXT_COUNT and WINED3D_GL_VERSION_2_0. But those aren't extensions.
Re: dmusic: remove unused variable
On 21 July 2010 09:21, Nikolay Sivov wrote:
> On 7/21/2010 11:16, Austin English wrote:
>> Hm, good point. How's this?
>>
>> diff --git a/dlls/dmusic/port.c b/dlls/dmusic/port.c
>> index 021f1e2..23fa1b8 100644
>> --- a/dlls/dmusic/port.c
>> +++ b/dlls/dmusic/port.c
>> @@ -382,7 +382,8 @@ HRESULT WINAPI DMUSIC_CreateDirectMusicPortImpl
>> (LPCGUID lpcGUID, LPVOID *ppobj,
>> obj->pDirectSound = NULL;
>> obj->pLatencyClock = NULL;
>> hr = DMUSIC_CreateReferenceClockImpl(&IID_IReferenceClock,
>> (LPVOID*)&obj->pLatencyClock, NULL);
>> -
>> + if(hr != S_OK)
>> + return E_FAIL;
>> if(0)
>> {
>> if (pPortParams->dwValidParams& DMUS_PORTPARAMS_CHANNELGROUPS) {
>>
>> Thanks for reviewing!
>
> Don't know, I'm not familiar with this at all. You need to figure out if
> this failure is critical enough to exit, and also it makes sense to return
> hr as is, not E_FAIL.
>
I don't know what I'm talking about either, but at the very least
you'd be leaking "obj".
Re: [PATCH 4/7] msvcp90: Added char_traits implementation (try3)
(Forgot to cc: wine-devel). On 07/21/2010 11:10 AM, Piotr Caban wrote: +void CDECL MSVCP_char_trauts_short_assign(unsigned short *ch, ^ I guess his should have been "MSVCP_char_traits_short_assign" -- Cheers, Paul.
Re: wined3d: Add Nvidia 8800GTX detection
On 21 July 2010 05:08, Roderick Colenbrander wrote: > I think 'select_card_*' should just return the pci device id and the > default amount of video memory should be stored in lets say the driver > version table (a different name for the table might make sense). It Yeah, this should be based on the card id, like the description string. You can probably also do much of the gl_renderer matching based on a table. Ultimately you may want to move it out of the source code completely, into a file, or perhaps the registry. The card db could be updated independent of Wine itself then, though at that point you'll have to start worrying about compatibility between Wine versions. Also note that while accurately detecting the total amount of video memory is nice, GetAvailableTextureMem() is probably at least as important.
Re: [1\4]wined3d: Extend IWineD3D_GetAdapterDisplayMode with an extra paramater to pass back some extra adapter info.
On 20 July 2010 23:25, Louis Lenders wrote:
> +struct wined3d_adapter_info_ex
> +{
> +WINED3DSCANLINEORDERING ScanLineOrdering;
> +WINED3DDISPLAYROTATION Rotation;
> +};
You can at least add the scanline ordering to WINED3DDISPLAYMODE, it
doesn't need to be compatible with D3DDISPLAYMODE. I guess the reason
the rotation is separate in d3d9ex is because it doesn't make much
sense for enumerations like e.g. EnumAdapterModesEx(), so keeping that
one separate makes sense. I also think the wined3d call should simply
retrieve all info, d3d9ex can discard it again if it feels like it.
Re: [PATCH 4/4] wined3d: Use a more consistent name for the normalized texrect "extension".
On 20 July 2010 22:05, Stefan Dösinger wrote: > > Am 20.07.2010 um 18:51 schrieb Henri Verbeet: >> - || gl_info->supported[WINE_NORMALIZED_TEXRECT]) >> + || gl_info->supported[WINED3D_GL_NORMALIZED_TEXRECT]) > I understand the WINE->WINED3D part - it's a wined3d specific thing, nothing > wine global. But why did you add GL to the name? > Consistency with the enum name, and WINED3D_GL_EXT_NONE, WINED3D_GL_EXT_COUNT and WINED3D_GL_VERSION_2_0.
Re: [PATCH 4/7] msvcp90: Added char_traits implementation (try2)
On 07/21/10 10:14, Alexandre Julliard wrote:
Piotr Caban writes:
+/* ?not_...@?$char_traits@g...@std@@sag...@z */
+unsigned short CDECL MSVCP_char_traits_short_not_eof(const unsigned short *in)
+{
+return (*in==0 ? !0 : *in);
+}
Aren't you supposed to return 0 for eof?
eof should be equal to -1, this function should return 0 if *in==-1.
I've sent fixed version of this patch.
Re: [7/8] msi/tests: Double null-terminate a REG_MULTI_SZ string.
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=3642
Your paranoid android.
=== W7PROX64 (32 bit msi) ===
msi.c:2129: Test failed: Expected {199806F7-4914-4AD4-A534-621BD19AB132}, got
prod
msi.c:2147: Test failed: Expected {199806F7-4914-4AD4-A534-621BD19AB132}, got
prod
msi.c:2162: Test failed: Expected {199806F7-4914-4AD4-A534-621BD19AB132}, got
prod
msi.c:2177: Test failed: Expected {199806F7-4914-4AD4-A534-621BD19AB132}, got
prod
msi.c:2195: Test failed: Expected {B88234A0-3235-44D6-9896-5C2F4FECBCA3}, got
prod
msi.c:2224: Test failed: Expected {199806F7-4914-4AD4-A534-621BD19AB132}, got
prod
msi.c:2242: Test failed: Expected {199806F7-4914-4AD4-A534-621BD19AB132}, got
prod
msi.c:2257: Test failed: Expected {199806F7-4914-4AD4-A534-621BD19AB132}, got
prod
msi.c:2272: Test failed: Expected {199806F7-4914-4AD4-A534-621BD19AB132}, got
prod
msi.c:2290: Test failed: Expected {B88234A0-3235-44D6-9896-5C2F4FECBCA3}, got
prod
msi.c:2371: Test failed: Expected {B7AD5430-68AC-40AC-A2B7-AC3921BEC0BB}, got
msi.c:2377: Test failed: Expected {B7AD5430-68AC-40AC-A2B7-AC3921BEC0BB}, got
msi.c:2401: Test failed: Expected {B7AD5430-68AC-40AC-A2B7-AC3921BEC0BB} or
{585F89C0-75DE-4B38-8A34-5B7E4D13554C}, got
msi.c:2408: Test failed: Expected {B7AD5430-68AC-40AC-A2B7-AC3921BEC0BB} or
{585F89C0-75DE-4B38-8A34-5B7E4D13554C}, got
msi.c:2442: Test failed: Expected {B7AD5430-68AC-40AC-A2B7-AC3921BEC0BB}, got
msi.c:2471: Test failed: Expected {B7AD5430-68AC-40AC-A2B7-AC3921BEC0BB} or
{585F89C0-75DE-4B38-8A34-5B7E4D13554C}, got
msi.c:2478: Test failed: Expected {B7AD5430-68AC-40AC-A2B7-AC3921BEC0BB} or
{585F89C0-75DE-4B38-8A34-5B7E4D13554C}, got
msi.c:7467: Test failed: Expected "{C3232306-263D-4B13-8407-D7D348E8AAAC}", got
"C:\winetest\\winetest.msi"
msi.c:7536: Test failed: Expected "{C3232306-263D-4B13-8407-D7D348E8AAAC}", got
"C:\winetest\\winetest.msi"
msi.c:7603: Test failed: Expected "{C3232306-263D-4B13-8407-D7D348E8AAAC}", got
"C:\winetest\\winetest.msi"
msi.c:7827: Test failed: Expected "{3E071142-9810-482F-A3BC-307835CE5064}", got
"apple"
msi.c:7829: Test failed: Expected "{AFCF83EE-1910-4D2B-9431-E5D213087128}", got
"banana"
msi.c:7888: Test failed: Expected "{AFCF83EE-1910-4D2B-9431-E5D213087128}", got
"banana"
msi.c:7906: Test failed: Expected "{3E071142-9810-482F-A3BC-307835CE5064}", got
"apple"
msi.c:7924: Test failed: Expected "{3E071142-9810-482F-A3BC-307835CE5064}", got
"apple"
msi.c:7926: Test failed: Expected "{AFCF83EE-1910-4D2B-9431-E5D213087128}", got
"banana"
msi.c:7942: Test failed: Expected "{3E071142-9810-482F-A3BC-307835CE5064}", got
"apple"
msi.c:7944: Test failed: Expected "{AFCF83EE-1910-4D2B-9431-E5D213087128}", got
"banana"
msi.c:7961: Test failed: Expected "{3E071142-9810-482F-A3BC-307835CE5064}", got
"apple"
msi.c:7963: Test failed: Expected "{AFCF83EE-1910-4D2B-9431-E5D213087128}", got
"banana"
msi.c:7982: Test failed: Expected "{3E071142-9810-482F-A3BC-307835CE5064}", got
"apple"
msi.c:7984: Test failed: Expected "{AFCF83EE-1910-4D2B-9431-E5D213087128}", got
"banana"
msi.c:8001: Test failed: Expected "{3E071142-9810-482F-A3BC-307835CE5064}", got
"apple"
msi.c:8003: Test failed: Expected "{AFCF83EE-1910-4D2B-9431-E5D213087128}", got
"banana"
msi.c:8119: Test failed: Expected "{3E071142-9810-482F-A3BC-307835CE5064}", got
"apple"
msi.c:8121: Test failed: Expected "{AFCF83EE-1910-4D2B-9431-E5D213087128}", got
"banana"
msi.c:8166: Test failed: Expected "{3E071142-9810-482F-A3BC-307835CE5064}", got
"apple"
msi.c:8168: Test failed: Expected "{AFCF83EE-1910-4D2B-9431-E5D213087128}", got
"banana"
msi.c:8192: Test failed: Expected "{3E071142-9810-482F-A3BC-307835CE5064}", got
"apple"
msi.c:8194: Test failed: Expected "{AFCF83EE-1910-4D2B-9431-E5D213087128}", got
"banana"
msi.c:7827: Test failed: Expected "{C6C5E819-A8C9-472A-A6C4-0B25C4BE950C}", got
"apple"
msi.c:7829: Test failed: Expected "{19FD8C6F-AF94-4735-B9F4-CB6E80553C15}", got
"banana"
msi.c:7888: Test failed: Expected "{19FD8C6F-AF94-4735-B9F4-CB6E80553C15}", got
"banana"
msi.c:7906: Test failed: Expected "{C6C5E819-A8C9-472A-A6C4-0B25C4BE950C}", got
"apple"
msi.c:7924: Test failed: Expected "{C6C5E819-A8C9-472A-A6C4-0B25C4BE950C}", got
"apple"
msi.c:7926: Test failed: Expected "{19FD8C6F-AF94-4735-B9F4-CB6E80553C15}", got
"banana"
msi.c:7942: Test failed: Expected "{C6C5E819-A8C9-472A-A6C4-0B25C4BE950C}", got
"apple"
msi.c:7944: Test failed: Expected "{19FD8C6F-AF94-4735-B9F4-CB6E80553C15}", got
"banana"
msi.c:7961: Test failed: Expected "{C6C5E819-A8C9-472A-A6C4-0B25C4BE950C}", got
"apple"
msi.c:7963: Test failed: Expected "{19FD8C6F-AF94-4735-B9F4-CB6E80553C15}", got
"banana"
msi.c:7982: Test failed: Expected "{C6C5E819-A8C9-472A-A6C4-0B25C4BE950C}", got
"apple"
m
Re: [3/8] msi: Move the component enabled check into the standard actions.
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=3641 Your paranoid android. === WXPPROSP3 (32 bit install) === Timeout === W2K8SE (32 bit install) === Timeout === W7PROX64 (32 bit install) === install.c:5409: Test failed: Expected "C:\Program Files (x86)\msitest\maximus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" install.c:5428: Test failed: Expected "01\msitest\augustus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" install.c:5453: Test failed: Expected "C:\Program Files (x86)\msitest\maximus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" install.c:5472: Test failed: Expected "01\msitest\augustus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" === W7PROX64 (64 bit install) === install.c:5654: Test failed: Expected ERROR_SUCCESS, got 2 install.c:5656: Test failed: Key doesn't exist or wrong type install.c:5657: Test failed: Key doesn't exist or wrong type install.c:5658: Test failed: Key doesn't exist or wrong type install.c:5659: Test failed: Key doesn't exist or wrong type install.c:5660: Test failed: Key doesn't exist or wrong type install.c:5661: Test failed: Key doesn't exist or wrong type install.c:5662: Test failed: Key doesn't exist or wrong type install.c:5663: Test failed: Key doesn't exist or wrong type install.c:5664: Test failed: Key doesn't exist or wrong type install.c:5665: Test failed: Key doesn't exist or wrong type install.c:5666: Test failed: Key doesn't exist or wrong type install.c:5667: Test failed: Key doesn't exist or wrong type install.c:5668: Test failed: Key doesn't exist or wrong type install.c:5669: Test failed: Key doesn't exist or wrong type install.c:5670: Test failed: Key doesn't exist or wrong type install.c:5671: Test failed: Key doesn't exist or wrong type install.c:5672: Test failed: Key doesn't exist or wrong type install.c:5673: Test failed: Key doesn't exist or wrong type install.c:5674: Test failed: Key doesn't exist or wrong type install.c:5675: Test failed: Key doesn't exist or wrong type install.c:5676: Test failed: Key doesn't exist or wrong type install.c:5677: Test failed: Key doesn't exist or wrong type install.c:5680: Test failed: Key doesn't exist or wrong type install.c:5729: Test failed: Expected ERROR_SUCCESS, got 2 install.c:5731: Test failed: Key doesn't exist or wrong type install.c:5732: Test failed: Key doesn't exist or wrong type install.c:5733: Test failed: Key doesn't exist or wrong type install.c:5734: Test failed: Key doesn't exist or wrong type install.c:5735: Test failed: Key doesn't exist or wrong type install.c:5736: Test failed: Key doesn't exist or wrong type install.c:5737: Test failed: Key doesn't exist or wrong type install.c:5738: Test failed: Key doesn't exist or wrong type install.c:5739: Test failed: Key doesn't exist or wrong type install.c:5740: Test failed: Key doesn't exist or wrong type install.c:5741: Test failed: Key doesn't exist or wrong type install.c:5742: Test failed: Key doesn't exist or wrong type install.c:5743: Test failed: Key doesn't exist or wrong type install.c:5744: Test failed: Key doesn't exist or wrong type install.c:5745: Test failed: Key doesn't exist or wrong type install.c:5746: Test failed: Key doesn't exist or wrong type install.c:5747: Test failed: Key doesn't exist or wrong type install.c:5748: Test failed: Key doesn't exist or wrong type install.c:5749: Test failed: Key doesn't exist or wrong type install.c:5750: Test failed: Key doesn't exist or wrong type install.c:5751: Test failed: Key doesn't exist or wrong type install.c:5752: Test failed: Key doesn't exist or wrong type install.c:5755: Test failed: Key doesn't exist or wrong type install.c:5781: Test failed: Expected ERROR_SUCCESS, got 2 install.c:5783: Test failed: Key doesn't exist or wrong type install.c:5784: Test failed: Key doesn't exist or wrong type install.c:5785: Test failed: Key doesn't exist or wrong type install.c:5786: Test failed: Key doesn't exist or wrong type install.c:5787: Test failed: Key doesn't exist or wrong type install.c:5788: Test failed: Key doesn't exist or wrong type install.c:5789: Test failed: Key doesn't exist or wrong type install.c:5790: Test failed: Key doesn't exist or wrong type install.c:5791: Test failed: Key doesn't exist or wrong type install.c:5792: Test failed: Key doesn't exist or wrong type install.c:5793: Test failed: Key doesn't exist or wrong type install.c:5794: Test failed: Key doesn't exist or wrong t
Re: [PATCH 4/7] msvcp90: Added char_traits implementation (try2)
Piotr Caban writes:
> +/* ?not_...@?$char_traits@g...@std@@sag...@z */
> +unsigned short CDECL MSVCP_char_traits_short_not_eof(const unsigned short
> *in)
> +{
> +return (*in==0 ? !0 : *in);
> +}
Aren't you supposed to return 0 for eof?
--
Alexandre Julliard
julli...@winehq.org
Re: dmusic: remove unused variable
On 7/21/2010 11:16, Austin English wrote:
On Wed, Jul 21, 2010 at 12:41 AM, Nikolay Sivov wrote:
On 7/21/2010 08:31, Austin English wrote:
HRESULT WINAPI DMUSIC_CreateDirectMusicPortImpl (LPCGUID lpcGUID, LPVOID
*ppobj, LPUNKNOWN pUnkOuter, LPDMUS_PORTPARAMS pPortParams, LPDMUS_PORTCAPS
pPortCaps) {
IDirectMusicPortImpl *obj;
- HRESULT hr = E_FAIL;
UINT j;
TRACE("(%p,%p,%p)\n", lpcGUID, ppobj, pUnkOuter);
@@ -381,7 +380,6 @@ HRESULT WINAPI DMUSIC_CreateDirectMusicPortImpl
(LPCGUID lpcGUID, LPVOID *ppobj,
obj->caps = *pPortCaps;
obj->pDirectSound = NULL;
obj->pLatencyClock = NULL;
- hr = DMUSIC_CreateReferenceClockImpl(&IID_IReferenceClock,
(LPVOID*)&obj->pLatencyClock, NULL);
if(0)
{
I doubt you could remove a call here. And probably return value should be
used to exit earlier on a failure.
Hm, good point. How's this?
diff --git a/dlls/dmusic/port.c b/dlls/dmusic/port.c
index 021f1e2..23fa1b8 100644
--- a/dlls/dmusic/port.c
+++ b/dlls/dmusic/port.c
@@ -382,7 +382,8 @@ HRESULT WINAPI DMUSIC_CreateDirectMusicPortImpl
(LPCGUID lpcGUID, LPVOID *ppobj,
obj->pDirectSound = NULL;
obj->pLatencyClock = NULL;
hr = DMUSIC_CreateReferenceClockImpl(&IID_IReferenceClock,
(LPVOID*)&obj->pLatencyClock, NULL);
-
+if(hr != S_OK)
+return E_FAIL;
if(0)
{
if (pPortParams->dwValidParams& DMUS_PORTPARAMS_CHANNELGROUPS) {
Thanks for reviewing!
Don't know, I'm not familiar with this at all. You need to figure out if
this failure is critical enough to exit, and also it makes sense to
return hr as is, not E_FAIL.
Re: dmusic: remove unused variable
On Wed, Jul 21, 2010 at 12:41 AM, Nikolay Sivov wrote:
> On 7/21/2010 08:31, Austin English wrote:
>>
>> HRESULT WINAPI DMUSIC_CreateDirectMusicPortImpl (LPCGUID lpcGUID, LPVOID
>> *ppobj, LPUNKNOWN pUnkOuter, LPDMUS_PORTPARAMS pPortParams, LPDMUS_PORTCAPS
>> pPortCaps) {
>> IDirectMusicPortImpl *obj;
>> - HRESULT hr = E_FAIL;
>> UINT j;
>>
>> TRACE("(%p,%p,%p)\n", lpcGUID, ppobj, pUnkOuter);
>> @@ -381,7 +380,6 @@ HRESULT WINAPI DMUSIC_CreateDirectMusicPortImpl
>> (LPCGUID lpcGUID, LPVOID *ppobj,
>> obj->caps = *pPortCaps;
>> obj->pDirectSound = NULL;
>> obj->pLatencyClock = NULL;
>> - hr = DMUSIC_CreateReferenceClockImpl(&IID_IReferenceClock,
>> (LPVOID*)&obj->pLatencyClock, NULL);
>>
>> if(0)
>> {
>
> I doubt you could remove a call here. And probably return value should be
> used to exit earlier on a failure.
Hm, good point. How's this?
diff --git a/dlls/dmusic/port.c b/dlls/dmusic/port.c
index 021f1e2..23fa1b8 100644
--- a/dlls/dmusic/port.c
+++ b/dlls/dmusic/port.c
@@ -382,7 +382,8 @@ HRESULT WINAPI DMUSIC_CreateDirectMusicPortImpl
(LPCGUID lpcGUID, LPVOID *ppobj,
obj->pDirectSound = NULL;
obj->pLatencyClock = NULL;
hr = DMUSIC_CreateReferenceClockImpl(&IID_IReferenceClock,
(LPVOID*)&obj->pLatencyClock, NULL);
-
+if(hr != S_OK)
+return E_FAIL;
if(0)
{
if (pPortParams->dwValidParams & DMUS_PORTPARAMS_CHANNELGROUPS) {
Thanks for reviewing!
--
-Austin
