Re: ddraw: make some driver info not const
On Mon, 05 Dec 2005 12:07:32 +0100, you wrote:
>
>You can't return from inside a __TRY block.
I did not know. Here is the next attempt:
Changelog:
dlls/ddraw : main.c, Makefile.in
Catch access violations when calling the DirectDrawEnumerateProc.
Rein.
--- wine/dlls/ddraw/main.c 2005-08-09 15:31:06.0 +0200
+++ mywine/dlls/ddraw/main.c2005-12-05 13:40:34.0 +0100
@@ -39,6 +39,8 @@
#include "winnls.h"
#include "winerror.h"
#include "wingdi.h"
+#include "wine/exception.h"
+#include "excpt.h"
#include "ddraw.h"
#include "d3d.h"
@@ -62,6 +64,14 @@ void (*wine_tsx11_unlock_ptr)(void) = NU
WINE_DEFAULT_DEBUG_CHANNEL(ddraw);
+/* filter for page-fault exceptions */
+static WINE_EXCEPTION_FILTER(page_fault)
+{
+if (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION)
+return EXCEPTION_EXECUTE_HANDLER;
+return EXCEPTION_CONTINUE_SEARCH;
+}
+
/**/
typedef struct {
@@ -180,6 +190,8 @@ HRESULT WINAPI DirectDrawEnumerateExA(
LPDDENUMCALLBACKEXA lpCallback, LPVOID lpContext, DWORD dwFlags)
{
int i;
+HRESULT retval = DD_OK;
+BOOL stop = FALSE;
TRACE("(%p,%p, %08lx)\n", lpCallback, lpContext, dwFlags);
if (TRACE_ON(ddraw)) {
@@ -201,12 +213,22 @@ HRESULT WINAPI DirectDrawEnumerateExA(
/* We have to pass NULL from the primary display device.
* RoadRage chapter 6's enumeration routine expects it. */
+__TRY
+{
if (!lpCallback((DDRAW_default_driver == i) ? NULL
:(LPGUID)&DDRAW_drivers[i]->info->guidDeviceIdentifier,
(LPSTR)DDRAW_drivers[i]->info->szDescription,
(LPSTR)DDRAW_drivers[i]->info->szDriver,
lpContext, 0))
- return DD_OK;
+stop = TRUE;
+}
+__EXCEPT(page_fault)
+{
+retval = E_INVALIDARG;
+stop = TRUE;
+}
+__ENDTRY
+if( stop) return retval;
}
/* Unsupported flags */
--- wine/dlls/ddraw/Makefile.in 2005-06-07 12:10:50.0 +0200
+++ mywine/dlls/ddraw/Makefile.in 2005-12-04 11:26:37.0 +0100
@@ -4,7 +4,7 @@ SRCDIR= @srcdir@
VPATH = @srcdir@
MODULE= ddraw.dll
IMPORTLIB = libddraw.$(IMPLIBEXT)
-IMPORTS = ole32 user32 gdi32 advapi32 kernel32
+IMPORTS = ole32 user32 gdi32 advapi32 kernel32 ntdll
EXTRAINCL = @X_CFLAGS@
EXTRALIBS = -ldxguid -luuid @X_LIBS@ @X_PRE_LIBS@ @XLIB@ @X_EXTRA_LIBS@
Re: ddraw: make some driver info not const
Rein Klazes <[EMAIL PROTECTED]> writes:
> +__TRY
> +{
> if (!lpCallback((DDRAW_default_driver == i) ? NULL
> :(LPGUID)&DDRAW_drivers[i]->info->guidDeviceIdentifier,
> (LPSTR)DDRAW_drivers[i]->info->szDescription,
> (LPSTR)DDRAW_drivers[i]->info->szDriver,
> lpContext, 0))
> return DD_OK;
You can't return from inside a __TRY block.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: ddraw: make some driver info not const
On Sat, 3 Dec 2005 09:44:07 +0100, you wrote:
>> This is wrong. No user program should modify our internal data. I think
>> you need to copy this data into heap before passing it to the app. You
>> should make simple test to check if the data returned on windows is
>> within heap or not.
>
>Yeah, I agree with Vitaliy here... We were alread hit multiple times by this
>bug in other cases: Wine should never send to the application actual private
>data as many games expect to use these values to do actual processing.
OK, I have tested this under Windows. The data is protected and the
access violation is handled by DirectDrawEnumerate:
Changelog:
dlls/ddraw : main.c, Makefile.in
Catch access violations when calling the DirectDrawEnumerateProc.
Rein.
--- wine/dlls/ddraw/main.c 2005-08-09 15:31:06.0 +0200
+++ mywine/dlls/ddraw/main.c2005-12-04 11:48:47.0 +0100
@@ -39,6 +39,8 @@
#include "winnls.h"
#include "winerror.h"
#include "wingdi.h"
+#include "wine/exception.h"
+#include "excpt.h"
#include "ddraw.h"
#include "d3d.h"
@@ -62,6 +64,14 @@ void (*wine_tsx11_unlock_ptr)(void) = NU
WINE_DEFAULT_DEBUG_CHANNEL(ddraw);
+/* filter for page-fault exceptions */
+static WINE_EXCEPTION_FILTER(page_fault)
+{
+if (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION)
+return EXCEPTION_EXECUTE_HANDLER;
+return EXCEPTION_CONTINUE_SEARCH;
+}
+
/**/
typedef struct {
@@ -201,12 +211,20 @@ HRESULT WINAPI DirectDrawEnumerateExA(
/* We have to pass NULL from the primary display device.
* RoadRage chapter 6's enumeration routine expects it. */
+__TRY
+{
if (!lpCallback((DDRAW_default_driver == i) ? NULL
:(LPGUID)&DDRAW_drivers[i]->info->guidDeviceIdentifier,
(LPSTR)DDRAW_drivers[i]->info->szDescription,
(LPSTR)DDRAW_drivers[i]->info->szDriver,
lpContext, 0))
return DD_OK;
+}
+__EXCEPT(page_fault)
+{
+return E_INVALIDARG;
+}
+__ENDTRY
}
/* Unsupported flags */
--- wine/dlls/ddraw/Makefile.in 2005-06-07 12:10:50.0 +0200
+++ mywine/dlls/ddraw/Makefile.in 2005-12-04 11:26:37.0 +0100
@@ -4,7 +4,7 @@ SRCDIR= @srcdir@
VPATH = @srcdir@
MODULE= ddraw.dll
IMPORTLIB = libddraw.$(IMPLIBEXT)
-IMPORTS = ole32 user32 gdi32 advapi32 kernel32
+IMPORTS = ole32 user32 gdi32 advapi32 kernel32 ntdll
EXTRAINCL = @X_CFLAGS@
EXTRALIBS = -ldxguid -luuid @X_LIBS@ @X_PRE_LIBS@ @XLIB@ @X_EXTRA_LIBS@
Re: ddraw: make some driver info not const
On Fri, Dec 02, 2005 at 12:11:34PM -0700, Vitaliy Margolen wrote: > Friday, December 2, 2005, 11:46:39 AM, Rein Klazes wrote: > > Hi, > [skip] > > Making this information not const makes the application proceed further. > > > Changelog: > > dlls/ddraw : ddraw_hal.c, ddraw_user.c > > Make some driver info not const, some applications want to modify it. > > This is wrong. No user program should modify our internal data. I think > you need to copy this data into heap before passing it to the app. You > should make simple test to check if the data returned on windows is > within heap or not. Yeah, I agree with Vitaliy here... We were alread hit multiple times by this bug in other cases: Wine should never send to the application actual private data as many games expect to use these values to do actual processing. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: ddraw: make some driver info not const
Friday, December 2, 2005, 11:46:39 AM, Rein Klazes wrote: > Hi, [skip] > Making this information not const makes the application proceed further. > Changelog: > dlls/ddraw: ddraw_hal.c, ddraw_user.c > Make some driver info not const, some applications want to modify it. This is wrong. No user program should modify our internal data. I think you need to copy this data into heap before passing it to the app. You should make simple test to check if the data returned on windows is within heap or not. Vitaliy
