Re: user32: Do not allow a change of capture if the currently capture window is a menu unless explicitly specified
On 01/07/2010 03:33 AM, Peter Dons Tychsen wrote: +/* check that SetCapture fails for another window and that it does not touch the error code */ +set_cap_wnd = SetCapture(hWnd); +err = GetLastError(); +ok(!set_cap_wnd, "ReleaseCapture should have failed!\n"); +ok(err == ERROR_SUCCESS, "Bad error-code from SetCapture. got %08X expected %08X\n", err, 0); + +/* check that ReleaseCapture fails and does not touch the error code */ +status = ReleaseCapture(); +err = GetLastError(); +ok(!status, "ReleaseCapture should have failed!\n"); +ok(err == ERROR_SUCCESS, "Bad error-code from ReleaseCapture. got %08X expected %08X\n", err, 0); Hi Peter, The comment says 'does not touch the error code' but the tests don't actually prove this. In general when we try to get a true hold of the last error to see if it changed we set it first, f.e. "SetLastError(0xdeadbeef)". -- Cheers, Paul.
Re: gdi32: Use the LOGFONT charset field on OEM font creation
On Tuesday 05 January 2010 17:08:52 Dmitry Timoshkov wrote: > "Ilya Shpigor" wrote: > > Some explanation for this patch: > > > > The fsCsb is bitfield that is used as boolean value. If this is false the > > DEFAULT_CHARSET is using and the real charset is choosen through the > > current ANSI codepage. But this is mistake in case of the OEM charset. > > A real fix would be to add "Terminal" font to Wine. If the "Terminal" font will be changed in test to "Tahoma" this still be failed. Are you sure what the current behavior of the WineEngCreateFontInstance is correct? When the user create logical font with OEM charset the GetTextCharset function will be always return ANSI independently of font name. This conversions occurs because of the current logic WineEngCreateFontInstance. Can there be a solution for the already existed fonts? -- Best regards, Ilya Shpigor.
Re: FIXMEs in DllCanUnloadNow and friends (and how to handle them)
Reece Dunn wrote: > Hi, > > As a result of the "Wine FIXME Report 2009 Aug - Dec" thread, I > created the following to hunt for DllCanUnloadNow calls that were > marked as being FIXME stubs: > Thank you for the patch, Reece. James McKenzie
Re: mlang: [RESEND] Print a FIXME only for unused parameter (Wine FIXME Report)
On Wed, Jan 6, 2010 at 3:28 PM, Detlef Riekenberg wrote:
> According to MSDN, both parameter are unused and must be 0/NULL
> A FIXME for every call is useless
>
> (there is no PATCH 1/2, so a resend without that prefix)
>
> --
> By by ... Detlef
>
>
> ---
> dlls/mlang/mlang.c | 8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c
> index 49f0605..9abe124 100644
> --- a/dlls/mlang/mlang.c
> +++ b/dlls/mlang/mlang.c
> @@ -3007,9 +3007,6 @@ exit:
> return hr;
> }
>
> -/*
> - * TODO: handle dwFlag and lpFallBack
> -*/
> static HRESULT WINAPI fnIMultiLanguage2_ConvertStringToUnicodeEx(
> IMultiLanguage3* iface,
> DWORD* pdwMode,
> @@ -3021,7 +3018,10 @@ static HRESULT WINAPI
> fnIMultiLanguage2_ConvertStringToUnicodeEx(
> DWORD dwFlag,
> WCHAR* lpFallBack)
> {
> - FIXME("\n");
> + if (dwFlag || (lpFallBack != NULL))
> + FIXME("Ignoring dwFlag (0x%x/%d) and lpFallBack (%p)\n",
> + dwFlag, dwFlag, lpFallBack);
> +
if (dwFlag || lpFallBack)
seems to be simpler and easier to read.
--
James Hawkins
New Icon set
Hi Joel When I read your preview page in Firefox, the lens for print preview in idb_std_small.bmp is to large. You can't detect the printer behind the lens. (LCD Resolution here is 1400x1050) As an Idea for an improvement, the print preview menu icon in Firefox is readable: The lens is a bit smaller but more important, the inner circle of the lens is transparent. Thanks for your artwork. -- By by ... Detlef ___ Preisknaller: WEB.DE DSL Flatrate für nur 16,99 Euro/mtl.! http://produkte.web.de/go/02/
Re: Wine FIXME Report 2009 Aug - Dec
On Wednesday 06 January 2010 17:49:12 Kai Blin wrote: > I'll send a patch. I see Wolfram beat me to it. :) Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
On Wed, Jan 6, 2010 at 7:21 AM, Alexandre Julliard wrote: > Crashing is the best behavior. Adding parameter checks all over the > place only hides bugs. I keep forgetting that crashing is good sometimes :-)
Re: Wine FIXME Report 2009 Aug - Dec
On Wednesday 06 January 2010 01:02:04 Reece Dunn wrote:
> 2010/1/5 Michael Stefaniuc :
> > 2040 | 36 | ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c109
>
> 0xc109 is NT_STATUS_MESSAGE_NOT_FOUND according to
> http://lists.samba.org/archive/jcifs/2004-February/003038.html.
>
> Interestingly, in dlls/ntdll/tests/error.c, there is already an entry
> for STATUS_MESSAGE_NOT_FOUND, so I am not sure where this fixme is
> originating (older version of wine?):
> 511 cmp(STATUS_MESSAGE_NOT_FOUND,
> ERROR_MR_MID_NOT_FOUND);
Nope, that fixme is still in the code. To quote from dlls/ntdll/error.c:
while (table->start)
{
if (status < table->start) break;
if (status < table->end)
{
DWORD ret = table->table[status - table->start];
if (ret == ERROR_MR_MID_NOT_FOUND) FIXME( "no mapping for %08x\n",
status );
^^^
return ret;
}
table++;
}
So there's an explicit test for the STATUS_MESSAGE_NOT_FOUND mapping, as
that's also used for a "No mapping found" return in the mapping table. It
looks like it'd make sense to change that if check to
if (ret == ERROR_MR_MID_NOT_FOUND && status != STATUS_MESSAGE_NOT_FOUND)
FIXME(...);
I'll send a patch.
Cheers,
Kai
--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developerhttp://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
Dan Kegel writes: > AJ wrote: >> Marcus Meissner writes: >>> buffer and size need to be either 0 at the same time or not, >>> otherwise this breaks up. Windows is inconsistent (either crashes >>> or returns invalids), so we can just add checking. >> >>If Windows crashes we don't need extra checks. Just tell Coverity that >>crashing is allowed here. > > If later versions of Windows return INVALID_PARAMETER, > wouldn't it be ok for Wine to do so rather than crashing? > In other words, isn't it ok to emulate the 'best' behaved > version of windows in cases like this, rather than the 'worst'? Crashing is the best behavior. Adding parameter checks all over the place only hides bugs. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
On 01/06/2010 04:03 PM, Dan Kegel wrote: AJ wrote: Marcus Meissner writes: buffer and size need to be either 0 at the same time or not, otherwise this breaks up. Windows is inconsistent (either crashes or returns invalids), so we can just add checking. If Windows crashes we don't need extra checks. Just tell Coverity that crashing is allowed here. If later versions of Windows return INVALID_PARAMETER, wouldn't it be ok for Wine to do so rather than crashing? In other words, isn't it ok to emulate the 'best' behaved version of windows in cases like this, rather than the 'worst'? I could agree with that in general. This particular one crashes on all of the boxes at winetestbot though: https://winetestbot.geldorp.nl/JobDetails.pl?Key=254 One unfortunate thing is of course that we would have a hard time fixing tests on boxes that would crash whereas newer ones don't. -- Cheers, Paul.
Re: [PATCH] Don't generate FIXME warnings for DllCanUnloadNow.
2010/1/6 Maarten Lankhorst : > Hi Reece, > > Reece Dunn schreef: >> >> NOTE: Some of the DllCanUnloadNow functions always return S_OK. I >> intend to address that in a separate patch once I have investigated >> whether the DLLs implement COM objects or not. >> > > When a dll is first implemented it probably returns S_OK since no interfaces > were used yet, but some programs just depended on the dll being present. > However the FIXME should not be removed then, since if it does implement > interfaces and it gets freed while in use this can be a serious crash. I'd > rather have that message then as a red flag for investigation. Returning > nothing in case of S_FALSE is fine though, but a TRACE() would still be nice > there just in case. Ok. I'll keep the FIXMEs for the ones that return S_OK and convert the others to TRACE. Thanks, - Reece
re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
AJ wrote: > Marcus Meissner writes: >> buffer and size need to be either 0 at the same time or not, >> otherwise this breaks up. Windows is inconsistent (either crashes >> or returns invalids), so we can just add checking. > >If Windows crashes we don't need extra checks. Just tell Coverity that >crashing is allowed here. If later versions of Windows return INVALID_PARAMETER, wouldn't it be ok for Wine to do so rather than crashing? In other words, isn't it ok to emulate the 'best' behaved version of windows in cases like this, rather than the 'worst'?
Re: [PATCH] Don't generate FIXME warnings for DllCanUnloadNow.
Hi Reece, Reece Dunn schreef: NOTE: Some of the DllCanUnloadNow functions always return S_OK. I intend to address that in a separate patch once I have investigated whether the DLLs implement COM objects or not. When a dll is first implemented it probably returns S_OK since no interfaces were used yet, but some programs just depended on the dll being present. However the FIXME should not be removed then, since if it does implement interfaces and it gets freed while in use this can be a serious crash. I'd rather have that message then as a red flag for investigation. Returning nothing in case of S_FALSE is fine though, but a TRACE() would still be nice there just in case. Cheers, Maarten.
Re: The (Casual) Game Support Report in Wine (Jan 2009)
2010/1/6 David Gerard : > whoops, sending to list as well! > > 2010/1/5 Reece Dunn : > >> 2/ the major issues appear to be in the application launchers used >> by different game providers (most of which are in the current wine >> implementation of the IE browser ActiveX control); > > Curious question: you tested with IE6, how do things work if you > install IE7? Any better? If you read down into the comments on the various game vendors (e.g. Big Fish Games), I noted that with IE7 installed via winetricks, the game launcher crashes. I have not done any extensive investigation/analysis at this point (maybe for the February report :)). >From experience: - Wine/Gecko will display some pages and work with some vendors, but not all - IE6 works - IE7 crashes when used as an ActiveX component (but works as a browser via iexplore) - IE8 does not work (even as a browser) when using the IE7 recipe See the original report for comments on what works with each vendor. - Reece
Fwd: The (Casual) Game Support Report in Wine (Jan 2009)
whoops, sending to list as well! -- Forwarded message -- From: David Gerard Date: 2010/1/6 Subject: Re: The (Casual) Game Support Report in Wine (Jan 2009) To: Reece Dunn 2010/1/5 Reece Dunn : > 2/ the major issues appear to be in the application launchers used > by different game providers (most of which are in the current wine > implementation of the IE browser ActiveX control); Curious question: you tested with IE6, how do things work if you install IE7? Any better? (I installed IE7 with winetricks to see if I could get the ActiveX control for our work VPN going. It didn't work, and I didn't expect it to - it uses ActiveX to completely take over and try to secure a Windows installation, and I think it just recoiled in horror when it found itself in Wine on Linux - but I routinely use it now to check website rendering. It's really horrible. But useful.) - d.
Re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
On 01/06/2010 01:59 PM, Marcus Meissner wrote: diff --git a/dlls/kernel32/tests/profile.c b/dlls/kernel32/tests/profile.c index e3f7156..8e64e73 100644 --- a/dlls/kernel32/tests/profile.c +++ b/dlls/kernel32/tests/profile.c @@ -266,6 +266,10 @@ static void test_profile_sections_names(void) WriteFile( h, content, sizeof(content),&count, NULL); CloseHandle( h); +ret = GetPrivateProfileSectionNames( NULL, 2, testfile3); +ok (ret == 0, "NULL buf but non-0 size, expected error\n"); +ret = GetPrivateProfileSectionNames( buf, 29, NULL); +ok (ret == 0, "NULL filename, expected error\n"); /* Test with sufficiently large buffer */ memset(buf, 0xc, sizeof(buf)); ret = GetPrivateProfileSectionNamesA( buf, 29, testfile3 ); Just crosscompiled for you, but winetestbot accepts patches these days ;) -- Cheers, Paul.
Re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
On 01/06/2010 01:59 PM, Marcus Meissner wrote: diff --git a/dlls/kernel32/tests/profile.c b/dlls/kernel32/tests/profile.c index e3f7156..8e64e73 100644 --- a/dlls/kernel32/tests/profile.c +++ b/dlls/kernel32/tests/profile.c @@ -266,6 +266,10 @@ static void test_profile_sections_names(void) WriteFile( h, content, sizeof(content),&count, NULL); CloseHandle( h); +ret = GetPrivateProfileSectionNames( NULL, 2, testfile3); +ok (ret == 0, "NULL buf but non-0 size, expected error\n"); +ret = GetPrivateProfileSectionNames( buf, 29, NULL); +ok (ret == 0, "NULL filename, expected error\n"); /* Test with sufficiently large buffer */ memset(buf, 0xc, sizeof(buf)); ret = GetPrivateProfileSectionNamesA( buf, 29, testfile3 ); Looks like it crashes on most OS versions: https://winetestbot.geldorp.nl/JobDetails.pl?Key=254 -- Cheers, Paul.
Re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
On Wed, Jan 06, 2010 at 01:34:28PM +0100, Alexandre Julliard wrote: > Marcus Meissner writes: > > > buffer and size need to be either 0 at the same time or not, > > otherwise this breaks up. Windows is inconsistent (either crashes > > or returns invalids), so we can just add checking. > > If Windows crashes we don't need extra checks. Just tell Coverity that > crashing is allowed here. I can't really say without a testcase. Could someone please run this test under some Windows versions? (Have not setup a Win32 buildenv :/) Ciao, Marcus diff --git a/dlls/kernel32/tests/profile.c b/dlls/kernel32/tests/profile.c index e3f7156..8e64e73 100644 --- a/dlls/kernel32/tests/profile.c +++ b/dlls/kernel32/tests/profile.c @@ -266,6 +266,10 @@ static void test_profile_sections_names(void) WriteFile( h, content, sizeof(content), &count, NULL); CloseHandle( h); +ret = GetPrivateProfileSectionNames( NULL, 2, testfile3); +ok (ret == 0, "NULL buf but non-0 size, expected error\n"); +ret = GetPrivateProfileSectionNames( buf, 29, NULL); +ok (ret == 0, "NULL filename, expected error\n"); /* Test with sufficiently large buffer */ memset(buf, 0xc, sizeof(buf)); ret = GetPrivateProfileSectionNamesA( buf, 29, testfile3 );
Re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
Marcus Meissner writes: > buffer and size need to be either 0 at the same time or not, > otherwise this breaks up. Windows is inconsistent (either crashes > or returns invalids), so we can just add checking. If Windows crashes we don't need extra checks. Just tell Coverity that crashing is allowed here. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
On 01/06/2010 01:26 PM, Marcus Meissner wrote:
+if (!RtlCreateUnicodeStringFromAsciiz(&filenameW, filename)) {
+SetLastError(ERROR_OUTOFMEMORY);
+return 0;
+}
Aren't you leaking bufferW here?
--
Cheers,
Paul.
Re: [4/5] WineD3D: Implement manual fencing with GL_APPLE_flush_buffer_range
2010/1/5 Stefan Dösinger :
> After the discussion on IRC I wasn't quite sure what you intended with
> wined3d_event_query_wait(), but maybe it was something like this:
>
More something along the lines of the attached patch, actually. There
are of course some intermediate steps.
diff --git a/dlls/wined3d/query.c b/dlls/wined3d/query.c
index 1280a3b..fd146ba 100644
--- a/dlls/wined3d/query.c
+++ b/dlls/wined3d/query.c
@@ -31,7 +31,126 @@
*/
WINE_DEFAULT_DEBUG_CHANNEL(d3d);
-#define GLINFO_LOCATION This->device->adapter->gl_info
+#define GLINFO_LOCATION (*gl_info)
+
+void wined3d_event_query_set(struct wined3d_event_query *query, const struct
wined3d_context *context)
+{
+const struct wined3d_gl_info *gl_info = context->gl_info;
+
+if (query->context != context)
+{
+ERR("Query was allocated in a different context, or not at all.\n");
+return;
+}
+
+ENTER_GL();
+
+if (gl_info->supported[APPLE_FENCE])
+{
+GL_EXTCALL(glSetFenceAPPLE(query->id));
+checkGLcall("glSetFenceAPPLE");
+}
+else if (gl_info->supported[NV_FENCE])
+{
+GL_EXTCALL(glSetFenceNV(query->id, GL_ALL_COMPLETED_NV));
+checkGLcall("glSetFenceNV");
+}
+
+LEAVE_GL();
+}
+
+BOOL wined3d_event_query_test(struct wined3d_event_query *query,
IWineD3DDeviceImpl *device)
+{
+const struct wined3d_gl_info *gl_info;
+struct wined3d_context *context;
+BOOL ret;
+
+if (!query->context)
+{
+TRACE("Query not started, returning TRUE.\n");
+return TRUE;
+}
+
+if (query->context->tid != GetCurrentThreadId())
+{
+FIXME("Wrong thread, returning FALSE.\n");
+return FALSE;
+}
+
+context = context_acquire(device, query->context->current_rt,
CTXUSAGE_RESOURCELOAD);
+gl_info = context->gl_info;
+
+ENTER_GL();
+
+if (gl_info->supported[APPLE_FENCE])
+{
+ret = GL_EXTCALL(glTestFenceAPPLE(query->id));
+checkGLcall("glTestFenceAPPLE");
+}
+else if (gl_info->supported[NV_FENCE])
+{
+ret = GL_EXTCALL(glTestFenceNV(query->id));
+checkGLcall("glTestFenceNV");
+}
+else
+{
+ERR("Query shouldn't exist.\n");
+ret = FALSE;
+}
+
+LEAVE_GL();
+
+context_release(context);
+
+return ret;
+}
+
+void wined3d_event_query_wait(struct wined3d_event_query *query,
IWineD3DDeviceImpl *device)
+{
+const struct wined3d_gl_info *gl_info;
+struct wined3d_context *context;
+
+if (!query->context)
+{
+TRACE("Query not started, returning.\n");
+return;
+}
+
+if (query->context->tid != GetCurrentThreadId())
+{
+FIXME("Wrong thread, falling back to wglFinish().\n");
+/* We can also end all other event queries here. */
+wine_wglFinish();
+return;
+}
+
+context = context_acquire(device, query->context->current_rt,
CTXUSAGE_RESOURCELOAD);
+gl_info = context->gl_info;
+
+ENTER_GL();
+
+if (gl_info->supported[APPLE_FENCE])
+{
+GL_EXTCALL(glFinishFenceAPPLE(query->id));
+checkGLcall("glFinishFenceAPPLE");
+}
+else if (gl_info->supported[NV_FENCE])
+{
+GL_EXTCALL(glFinishFenceNV(query->id));
+checkGLcall("glFinishFenceNV");
+}
+else
+{
+ERR("Query shouldn't exist, falling back to wglFinish().\n");
+/* We can also end all other event queries here. */
+wine_wglFinish();
+return;
+}
+
+LEAVE_GL();
+
+context_release(context);
+}
/* ***
IWineD3DQuery IUnknown parts follow
@@ -341,53 +460,13 @@ static HRESULT WINAPI
IWineD3DOcclusionQueryImpl_GetData(IWineD3DQuery* iface,
static HRESULT WINAPI IWineD3DEventQueryImpl_GetData(IWineD3DQuery* iface,
void* pData, DWORD dwSize, DWORD dwGetDataFlags) {
IWineD3DQueryImpl *This = (IWineD3DQueryImpl *) iface;
struct wined3d_event_query *query = This->extendedData;
-struct wined3d_context *context;
BOOL *data = pData;
TRACE("(%p) : type D3DQUERY_EVENT, pData %p, dwSize %#x, dwGetDataFlags
%#x\n", This, pData, dwSize, dwGetDataFlags);
if (!pData || !dwSize) return S_OK;
-if (!query->context)
-{
-TRACE("Query not started, returning TRUE.\n");
-*data = TRUE;
-
-return S_OK;
-}
-
-if (query->context->tid != GetCurrentThreadId())
-{
-/* See comment in IWineD3DQuery::Issue, event query codeblock */
-FIXME("Wrong thread, reporting GPU idle.\n");
-*data = TRUE;
-
-return S_OK;
-}
-
-context = context_acquire(This->device, query->context->current_rt,
CTXUSAGE_RESOURCELOAD);
-
-ENTER_GL();
-
-if (context->gl_info->supported[APPLE_FENCE])
-{
-*data = GL_EXTCALL(glTestFenceAPPLE(query->id));
-checkGLcall("glTestFenceAPPLE");
-}
-else if (context->gl_info->supported[NV_FENCE])
-{
-*data = GL_EXTCALL(glT
Re: Wine FIXME Report 2009 Aug - Dec
On Wed, Jan 6, 2010 at 2:45 AM, Vincent Povirk
wrote:
> It might be interesting to select for err:module:import_dll lines,
> which are (sometimes) missing dll's.
>
>> 77 | 99 | ole:CoGetClassObject no class object
>> {9a5ea990-3034-4d6f-9128-01f3c61022bc} could be created for context 0x1
>> 75 | 98 | ole:CoGetClassObject class
>> {9a5ea990-3034-4d6f-9128-01f3c61022bc} not registered
>
> Regedit tells me this is "GameExplorer class", in gameux.dll.
>
> I assume this is the class id for IGameExplorer interface documented
> here:
> http://msdn.microsoft.com/en-us/library/microsoft.directx_sdk.igameexplorer.igameexplorer%28VS.85%29.aspx
>
> Searching for that class id in google gives me the impression that
> it's not a problem when it comes up. This makes sense, given that it's
> a vista-only API. Still, it's a surprise to me how widespread the use
> of that class apparently is.
It's a good surprise: Wine has gotten to the point where many people
are trying to use it to play the latest games :-).
Re: gdi32: Use the LOGFONT charset field on OEM font creation
Ilya Shpigor wrote: > If the "Terminal" font will be changed in test to "Tahoma" this still be > failed. > > Are you sure what the current behavior of the WineEngCreateFontInstance is > correct? When the user create logical font with OEM charset the > GetTextCharset function will be always return ANSI independently of font > name. This conversions occurs because of the current logic > WineEngCreateFontInstance. This needs more testing. Obviously testing with a non-existant bitmap OEM font is not enough. -- Dmitry.
Re: [PATCH] wined3d: Do not try to use not available texture stages in set_tex_op_nvr
2010/1/5 Christian Costa :
> Here it is. The fixme message is :
> fixme:d3d:set_tex_op_nvrc > GL_INVALID_ENUM (0x500) from
> set_tex_op_nvrc() @ nvidia_texture_shader.c / 460
>
Looks like the context creation code invalidates those states simply
because they exist. Does the attached patch make the errors go away?
diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c
index adb426b..10fa94f 100644
--- a/dlls/wined3d/state.c
+++ b/dlls/wined3d/state.c
@@ -5733,6 +5733,7 @@ HRESULT compile_state_table(struct StateEntry
*StateTable, APPLYSTATEFUNC **dev_
APPLYSTATEFUNC multistate_funcs[STATE_HIGHEST + 1][3];
const struct StateEntryTemplate *cur;
BOOL set[STATE_HIGHEST + 1];
+unsigned int start, last;
memset(multistate_funcs, 0, sizeof(multistate_funcs));
@@ -5824,6 +5825,14 @@ HRESULT compile_state_table(struct StateEntry
*StateTable, APPLYSTATEFUNC **dev_
}
}
+start = STATE_TEXTURESTAGE(gl_info->limits.texture_stages, 0);
+last = STATE_TEXTURESTAGE(MAX_TEXTURES - 1, WINED3D_HIGHEST_TEXTURE_STATE);
+for (i = start; i <= last; ++i)
+{
+StateTable[i].representative = 0;
+StateTable[i].apply = state_undefined;
+}
+
return WINED3D_OK;
out_of_mem:
Re: The (Casual) Game Support Report in Wine (Jan 2009)
Reece Dunn a écrit : 2010/1/6 Christian Costa : Reece Dunn a écrit : 1/ the games themselves tend to work very well (and have done for a long while now thanks to the great work CodeWeavers did in getting DirectDraw and Direct3D working); While you are at in, you can also thanks people that worked in this area in their spare time. I didn't mean to slight the non-CodeWeavers contributers (like you) to wine and DirectDraw/Direct3D -- everyone has done (and continues to do) amazing work. So thank you all. Everyone who has worked on wine in one form or other (be it in implementing functionality, fixing bugs, fixing tests, triaging bugs, testing applications and filing useful bug reports, translating, working on the artwork, performing cleanups and simplifying the code, addressing valgrind/coverity issues, ...) have helped to make wine what it is today. - Reece Seems it was misleading. I just wanted to point out that there was a pretty correct implementation of direct3D and ddraw up to d3d8 before CodeWeavers decided to focus on games. That said this is very nice what has been achieved recently in this area by current d3d developpers. But we shouldn't forget either that these are also all small contributions in all different areas that help games work correctly. So thanks to all of you and why I'm at it I wish you a happy new year ! A+ Christian
Re: ole32/tests: remove a test, as it fails or hangs on Vista+
On 01/05/2010 08:05 PM, André Hentschel wrote: vista and 2k8: fails w7:timeout --- dlls/ole32/tests/clipboard.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/dlls/ole32/tests/clipboard.c b/dlls/ole32/tests/clipboard.c index 626d244..4a9e234 100644 --- a/dlls/ole32/tests/clipboard.c +++ b/dlls/ole32/tests/clipboard.c @@ -1186,6 +1186,7 @@ static void test_flushed_getdata(void) "got %08x\n", hr); if(SUCCEEDED(hr)) ReleaseStgMedium(&med); +#if 0 /* broken on Vista+ */ InitFormatEtc(fmt, cf_another, 0x); memset(&dm, 0, sizeof(dm)); dm.dmSize = sizeof(dm); @@ -1204,6 +1205,7 @@ static void test_flushed_getdata(void) ok(hr == S_OK, "got %08x\n", hr); ok(med.tymed == TYMED_ISTORAGE, "got %x\n", med.tymed); if(SUCCEEDED(hr)) ReleaseStgMedium(&med); +#endif HeapFree(GetProcessHeap(), 0, fmt.ptd); The test doesn't fail or hang on all Vista+ boxes though. There have been several attempts to fix these failures but I'm not sure just removing them is the best option. Apart from that I think "if (0)" is preferred over "#if 0". -- Cheers, Paul.
Re: The (Casual) Game Support Report in Wine (Jan 2009)
2010/1/6 Christian Costa : > Reece Dunn a écrit : >> >> 1/ the games themselves tend to work very well (and have done for a >> long while now thanks to the great work CodeWeavers did in getting >> DirectDraw and Direct3D working); > > While you are at in, you can also thanks people that worked in this area in > their spare time. I didn't mean to slight the non-CodeWeavers contributers (like you) to wine and DirectDraw/Direct3D -- everyone has done (and continues to do) amazing work. So thank you all. Everyone who has worked on wine in one form or other (be it in implementing functionality, fixing bugs, fixing tests, triaging bugs, testing applications and filing useful bug reports, translating, working on the artwork, performing cleanups and simplifying the code, addressing valgrind/coverity issues, ...) have helped to make wine what it is today. - Reece
Re: The (Casual) Game Support Report in Wine (Jan 2009)
Reece Dunn a écrit : 1/ the games themselves tend to work very well (and have done for a long while now thanks to the great work CodeWeavers did in getting DirectDraw and Direct3D working); While you are at in, you can also thanks people that worked in this area in their spare time. A+
