On Tue, Apr 19, 2005 at 08:37:30PM +0200, Alexandre Julliard wrote:
> Actually you have the same problem with the GDI lock, this is going to
> be more tricky to solve...
Duh! One way to do it is to not hold the lock while we call the
handler. Which I think we need to do anyway, as app handlers are
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> On Tue, Apr 19, 2005 at 01:13:12PM +0200, Alexandre Julliard wrote:
> > You can't hold the critsection when adding the handler since this will
> > grab the vectored_handlers critsection, and thus acquire the sections
> > in the reverse order of what
On Tue, Apr 19, 2005 at 01:13:12PM +0200, Alexandre Julliard wrote:
> You can't hold the critsection when adding the handler since this will
> grab the vectored_handlers critsection, and thus acquire the sections
> in the reverse order of what happens when the handler is called.
Good point, I have
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> +EnterCriticalSection(&dibs_cs);
> +LIST_FOR_EACH( ptr, &dibs_list )
> +{
> +physBitmap = LIST_ENTRY( ptr, X_PHYSBITMAP, entry );
> +if (physBitmap->base > addr) break;
If you want to short-circuit the search this way yo
On Mon, Apr 18, 2005 at 10:46:10PM +0900, Dmitry Timoshkov wrote:
> Here is a largely simplified source ripped from one of my very old projects
> which loads a TGA file and shows it using a DIB section. A sample TGA file
> is included.
Thank you Dmitry. It didn't test the fault handler directly, b
"Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> Right, I realized that after sending the email about making the data
> field a pointer to physBitmap. Compiles, but not tested, as I don't
> have a DIB using app.
Here is a largely simplified source ripped from one of my very old projects
which load
On Mon, Apr 18, 2005 at 01:06:23PM +0200, Alexandre Julliard wrote:
> Sure, the general idea is fine. You actually don't need a mem_area
> structure at all, you can store that directly in the phys bitmap. Also
> it would be nice to only set the handler when a DIB is allocated, not
> at startup.
Ri
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Yeah, and on second thought even this "mem_area" is too general because
> they are build specifically for DIBs. I should rename them dib_area,
> and instead of "void *data", I should have "X_PHYSBITMAP *physBitmap".
>
> But I'd like to hear
On Mon, Apr 18, 2005 at 12:29:07AM +0900, Dmitry Timoshkov wrote:
> "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
>
> > +struct mem_area
> > +{
> > +struct list entry; /* Entry in global mem area list */
> > +const void *base;/* Base address */
> > +UINT size
"Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> +struct mem_area
> +{
> +struct list entry; /* Entry in global mem area list */
> +const void *base;/* Base address */
> +UINT size;/* Size in bytes */
> +void *data;/* Data associate
On Sun, Apr 17, 2005 at 08:44:57AM -0500, Rob Shearman wrote:
> Why don't you free area here?
Details, details. But if you insist ... :)
Index: dlls/ntdll/ntdll.spec
===
RCS file: /var/cvs/wine/dlls/ntdll/ntdll.spec,v
retrieving rev
Dimitrie O. Paun wrote:
On Thu, Apr 14, 2005 at 03:05:36PM +0200, Alexandre Julliard wrote:
Actually it should be possible to handle the fault using a vectored
handler, without requiring internal functions at all.
Completely untested (what do people use to test DIB handling?),
but it compil
On Thu, Apr 14, 2005 at 03:05:36PM +0200, Alexandre Julliard wrote:
> Actually it should be possible to handle the fault using a vectored
> handler, without requiring internal functions at all.
Completely untested (what do people use to test DIB handling?),
but it compiles. Is something like this
Eric Pouech <[EMAIL PROTECTED]> writes:
> If you suppose no app would ever set its own vectored handler at the
> beginnnig of the vector...
> One could argue that no well behaved application should do it, but well...
That would only be a problem if the app tries to handle the
exception. I think t
Alexandre Julliard a écrit :
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
I guess this has no chance of going away until we have a DIB engine,
which is not even on the horizon.
Actually it should be possible to handle the fault using a vectored
handler, without requiring internal functions at a
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> I guess this has no chance of going away until we have a DIB engine,
> which is not even on the horizon.
Actually it should be possible to handle the fault using a vectored
handler, without requiring internal functions at all.
--
Alexandre Jullia
16 matches
Mail list logo
