the
Wine source tree:
* http://www.winehq.org/pipermail/wine-cvs/2005-January/013584.html
* http://www.winehq.org/pipermail/wine-cvs/2005-January/013623.html
Thanks for any assistance anyone may be able to provide.
Glenn.
On Thu, Sep 11, 2008 at 02:59:46PM -0400, Glenn Wurster wrote:
>
>
> >Not really, if the app handles the exception there's no reason it
> >would fail.
>
> And that's just what safedisc does so please don't change it because it
> appears to work and enough things it needs are broken already.
I'm not looking to change exception handling at the application level,
> > In short, because we're never going to be able to continue, so there's
> > no point on trying to pass because that's going to fail.
>
> Not really, if the app handles the exception there's no reason it
> would fail. Not passing the exception will break things like
> IsBadReadPtr.
Ok. My und
> > Changelog:
> >Don't pass on non-continuable exceptions.
>
> Why do you want to do that?
In short, because we're never going to be able to continue, so there's
no point on trying to pass because that's going to fail.
In long, because I've got another patch in the pipeline (it needs some
t
On Sat, Jul 23, 2005 at 10:22:09AM +0200, Alexandre Julliard wrote:
> Glenn Wurster <[EMAIL PROTECTED]> writes:
>
> > GDI is a very good example of the problem of throwing an exception
> > where the application never intended one to be thrown. If ESP is bad
> &
> The "real" DIB, used for GDI calls, is stored on X side but the DIB
> surface, used for direct access, is stored on Wine side and we need to
> keep them in sync by catching reads / writes to the DIB surface.
> We need to get rid of that seperation - either the DIB should be stored
> fully on X s
> Our current DIB implementation is an ugly hack. We need a real DIB
> implementation, either as a complete GDI engine in Wine or as an X11
> extension.
But is it the DIB implementation that is really at fault here or is it
the fact that we are adding extra exceptions and can't be sure what
the
I've been doing some debugging of the exception handler and have come
across a problem for which I'm not sure what the best solution is. It
involves an application using the ESP for something other than the
stack.
The current DIB code uses protection to detect when the application
modifies the DI
> I am experiencing a crash during startup of an application (The
> Rosetta Stone 2.0.7a) under Wine. I reported this earlier on
> wine-users and after some debugging was advised to move to this list.
> I am using the latest Wine I built from CVS, after first encountering
> this problem in the
> > I notice it's trying for 8 bit mode. I posted a patch a while ago to
> > do with palette colours that was not been accepted (I'm busy right now
> > but should get back to modifying it eventually). Try applying that
> > and see if it fixes the problem. I've attached it. Failing that, I'd
>
> Ok here's where I am at.. I get these errors when I just do wine program.exe
> err:wave:wodDsCreate DirectSound flag not set
> This sound card's driver does not support direct access
> The (slower) DirectSound HEL mode will be used instead.
> fixme:mmtime:timeBeginPeriod Stub; we set our timer
> I'm just a peon but wouldn't it be better for the ReactOS project if
> you put the code in gdi instead?
I tried that and sent a patch in, but it required a function prototype
change on every ExtTextOut driver function. It looked ulgy to me, and
(suprise) it was not accepted. If someone can gi
> I think that it should be the ExtTextOut's backend responsibility whether
> to use antialiasing or not, taking into account ANTIALIASED_QUALITY and
> CLEARTYPE_QUALITY value of the LOGFONT.lfQuality field.
Actually, we can not just look at the font for this. The issue is
that even though the f
> You shouldn't change the global antialias flag, this is ugly and it
> will most likely break the font caching. You have to add checks for a
> palette directly at the places that handle the anti-aliasing (and your
> palette check is wrong too, you shouldn't peek into the internals of
> the DC bitm
14 matches
Mail list logo
