I forget to say this

EDD_SURFACE DxLock expect it is always value 2 in Type

other wise the lock will fail.

here is some of my code it is part of DxLock lock process I am working on.

here is the code I am working on and some rethinking how GDIOBJHDR
can look like.

Some rethinking why not ?

typedef struct _GDIOBJHDR
{
HGDIOBJ hHmgr;

    union {
                struct {
                                WORD count;
                          };
                struct {
                                WORD type;
                          } u;
              DWORD Entry;
            }

ULONG cExcLock;
ULONG Tid;
}GDIOBJHDR, PGDIOBJHDR;

DWORD
STDCALL
DxLock(HANDLE hSurface, PDD_LOCKDATA puLockData, HDC hdcClip)
{
DD_LOCKDATA LockData;
PEDD_SURFACE pSurface;

    _SEH_TRY
    {
        ProbeForRead(puLockData, sizeof(DD_LOCKDATA), 1);
        RtlCopyMemory(&LockData,puLockData, sizeof(DD_LOCKDATA));
    }
    _SEH_HANDLE
    {
        _SEH_YIELD(return DDERR_GENERIC);
    }
    _SEH_END;

    pSurface = DdHmgLock(hSurface,2,0);

.......

}

LPVOID
STDCALL
DdHmgLock(HANDLE hObject, WORD GdiObjectType, BOOL AcqurieHmgrSemaphoreAndRelease )
{
    PGDIOBJHDR pObjhdr = NULL;
    PVOID pRetObjhdr = NULL;
    DWORD position = hObject & 0x1FFFFF;

    /* check see if we need Acqurie Hmgr Semaphore */
    if ( !AcqurieHmgrSemaphoreAndRelease )
    {
        DdHmgAcquireHmgrSemaphore();
    }

/* Check see if position we are in range, gcMaxDdHmgr is our counter how many object we got */

    if ( position < gcMaxDdHmgr )
    {
        /* Get our Gdi Object */
        pObjhdr = (LPBYTE)gpentDdHmgr + (position * sizeof(GDIOBJHDR) );

        /* Vaildate if we got the object type we wanted */
        if ( ( pObjhdr->Type == GdiObjectType ) &&
             (( pObjhdr->Entry) == (((DWORD)hObject >> 21) & 0x7FF) ) &&
             (pObjhdr->cExcLock) &&
             (pObjhdr->Tid != PsGetCurrentThread() ) )
        {
            InterlockedIncrement(pObjhdr->cExcLock);
            pObjhdr->Tid = PsGetCurrentThread();
            pRetObjhdr = (PVOID) pObjhdr;
        }
    }

    /* check see if we need release Hmgr Semaphore */
    if ( !AcqurieHmgrSemaphoreAndRelease )
    {
        DdHmgReleaseHmgrSemaphore();
    }

return pRetObjhdr;
}

Original Message -----

From: Magnus Olsen

To: ReactOS Development List

Sent: Sunday, December 30, 2007 12:07 PM

Subject: Re: [ros-dev] About GDIOBJHDR header changes

Hi Jim and Timo
I base it on how dxg.sys acts when it lock a

dx object.

rember that DWORD store data diffent

the 2 we see it should be the type

rember that the byte order for DWORD is

casted it mean if it got 2 it is store in the higher part

see memory layout

memory layout

---------------------------------

| WORD 00 | bit 0-15 |
---------------------------------

| WORD 01 | bit 16-31 |
---------------------------------

word 01 and word 00 are swaped when it display as DWORD, in DWORD the word 01 will become bit 0-15, word 00 will become bit 16-31

that expain the value 0,1,2,3 we see in PVOID Entry. if we split it. we will see value 0,1,2,3,4 in Type amd count is often 0.

I have no clude yet what diffent type it exists.

the count is often set to 0

and the type is set to 0, 1, 2, 3 and so on.

Still any unclear why I think it we should Split PVOID into two diffent members ?

----- Original Message -----
From: Timo Kreuzer

To: ReactOS Development List

Sent: Sunday, December 30, 2007 4:24 AM

Subject: Re: [ros-dev] About GDIOBJHDR header changes

James Tabor schrieb:
Hi!

  
typedef struct _GDIOBJHDR
{
    HGDIOBJ     hHmgr;
    PVOID       unknownCount;
    ULONG       cExcLock;
    ULONG       Tid;
}GDIOBJHDR, PGDIOBJHDR;

    
I thought PVOID unknownCount was PVOID pEntry which is the pointer
back to the handle table entry. That could have changed since this is
based on Yuan book and w2k. Remember too, that DxDD handles are
different and handled outside normal DC's.
  
Yuan says it's pEntry, I came to the conclusion it's probably a counter, because it's values are small like 1,2,3..0x200
see http://www.reactos.org/wiki/index.php/Techwiki/win32k/GDIOBJHDR
Has probably changed from 2k to xp.
I agree, DX objects might be different, maybe they have a different header structure, I have never looked at DX object memory, so I don't know how they look...
I just can say that all GDI objects I have dumped the memory of, don't have a type field there, it's always been 0.

Timo

_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev