Re: ddraw: make some driver info not const

[Vitaliy Margolen]

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

ddraw: make some driver info not const

[Lionel Ulmer]

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

ddraw: make some driver info not const

[Rein Klazes]

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.

ddraw: make some driver info not const

[Alexandre Julliard]

Rein Klazes  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.

ddraw: make some driver info not const

[Rein Klazes]

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.