Thx
I verify it
I hope it is last miste from my side
here is what I found in dxg when I Play with BASEOBJECT
 
struct _BASEOBJECT
{
    HANDLE hHmgr;
    ULONG ulShareCount;
    LONG cExclusiveLock;
    PW32THREAD Tid;
    ULONG BaseFlags;
} DD_BASEOBJECT, *PDD_BASEOBJECT, *POBJ;
 
only diffent is Tid and BaseFlags was need change place, aganst the version that alex posted
----- Original Message -----
From: Alex Ionescu
To: ReactOS Development List
Sent: Sunday, December 30, 2007 4:18 PM
Subject: Re: [ros-dev] About GDIOBJHDR header changes

There is no DD_BASEOBJECT, the cExclusiveLock really is at +0x08, I've verified in the disassembly as well as with WinDBG.


On 30-Dec-07, at 10:00 AM, Magnus Olsen wrote:

Hi
I try verify some stuff, the _BASEOBJECT does not match for dxg
I want it be in this order.
 
 struct DD_BASEOBJECT
 {
    HANDLE hHmgr; // Handle for this object
    LONG cExclusiveLock; // lock with InterlockedIncrement or not
    ULONG ulShareCount; 
    PW32THREAD Tid;   // contain which thread it belong to, PsGetCurrentThread()
    ULONG BaseFlags;    
 } *POBJ;
----- Original Message -----
Sent: Sunday, December 30, 2007 2:52 PM
Subject: Re: [ros-dev] About GDIOBJHDR header changes

Both Timo and Magnus are half-right, half-wrong, and are confused by no less then three different structures that come into play. The fact that Feng's book is outdated doesn't help much! Greatlord's reversing of the DdHmgLock function was also completely busted, further confusing matters.

So here's my attempt to clear things up.

Let's begin with the GDI Base Object, which is a header at the top of every GDI Object. The structure is called _BASEOBJECT (what you refer to as "GDIOBJHDR") and is defined as follows:

struct _BASEOBJECT
{
    HANDLE hHmgr;
    ULONG ulShareCount;
    LONG cExclusiveLock;
    ULONG BaseFlags;
    PW32THREAD Tid;
};

The pointer to a _BASEOBJECT is known as a POBJ.

Now, how to get to this object? Well, dxg and win32k.sys now both implement different Hmhr's (Handle Managers).

In Win32K land, the handles come from gpentHmgr, and each handle is indexed from it. The resulting structure is called an _ENTRY, and is defined as follows:

struct _ENTRY
{
    union
    {     
        POBJ pobj;
        HANDLE hFree;
    };
    union
    {
         ULONG ulObj;
         struct
         {
                USHORT Count:15;
                USHORT Lock:1;
                HANDLE Pid;
         };
    } ObjectOwner;
    USHORT FullUnique;
    UCHAR Objt;
    UCHAR Flags;
    PVOID pUser;
};

DXG uses a DDENTRY structure, which is similar. Handles are indexed from gpentDdHmgr.

What Greatlord hadn't noticed while reversing is that part of the code was dealing with the DD_ENTRY object, and part of it was dereferencing the first member of DD_ENTRY, which is the pObj (and was now dealing with the _BASEOBJECT).

Objt is where the object type is defined -- you already seem to know the Win32K Objects. Here are the DXG objects:

DD_MOTIONCOMP_TYPE
DD_VIDEOPORT_TYPE
D3D_HANDLE_TYPE
DD_SURFACE_TYPE
DD_DIRECTDRAW_TYPE
DD_DEF_TYPE.

So how exactly then does DdHmgrLock work? Quite similarly to HmgrLock:

POBJ
FASTCALL
DdHmgLock(HDD_OBJ DdHandle,
          UCHAR ObjectType,
          BOOLEAN LockOwned)
{
    POBJ Object = NULL;
    PDD_ENTRY Entry;
    ULONG Index;

    //
    // Acquire the DirectX Handle Manager Lock
    //
    if (!LockOwned) DdHmgAcquireHmgrSemaphore();

    //
    // Get the handle index and validate it
    //
    Index = DdHandle & 0x1FFFFF;
    if (Index < gcMaxDdHmgr)
    {
        //
        // Get the entry
        //
        Entry = gpentDdHmgr[Index];
        
        //
        // Validate the owner
        //
        if ((Entry->ObjectOwner.Pid = PsGetCurrentProcessId() & 0xFFFFFFFC) ||
            !(Entry->ObjectOwner.Pid))
        {
            //
            // Validate the object type
            //
            if (Entry->Objt == ObjectType)
            {
                //
                // Validate the handle type
                //
                if (Entry->FullUnique == ((DdHandle >> 21) & 0x7FF))
                {
                    //
                    // Get the GDI Object
                    //
                    Object = DdEntry->pObj;
                    
                    //
                    // Make sure we can lock it
                    //
                    if (!(Object->cExclusiveLock) ||
                        (Object->Tid == (PW32THREAD)PsGetCurrentThread()))
                    {
                        //
                        // Acquire the lock
                        //
                        InterlockedIncrement(&Object->cExclusiveLock);
                        Object->Tid = (PW32THREAD)PsGetCurrentThread();
                    }
                    else
                    {
                        //
                        // Already locked by someone else
                        //
                        Object = NULL;
                    }
                }
            }
        }
    }
    
    //
    // Release the lock
    //
    if (!LockOwned) DdHmgReleaseHmgrSemaphore();
    
    //
    // Return the object
    //
    return Object;
}


I am looking forward to compatible Hmgr implementation in win32k!

Any questions?

On 30-Dec-07, at 7:02 AM, Magnus Olsen wrote:

 
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 -----
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 -----
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
_______________________________________________
Ros-dev mailing list

Best regards,
Alex Ionescu



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

Best regards,
Alex Ionescu

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