[ros-dev] GDI_TABLE_ENTRY structure

[Timo Kreuzer]

I think it's more like this:

typedef struct _GDI_TABLE_ENTRY
{
    PVOID KernelData;
    SHORT ProcessId;   Process Id is here, bit 0x01 for locking
    SHORT Count:16;   Count number of refs. -> does this even exists on XP+???
explains why the count shows 1 -> 3 most of the time. -> I have vever seen anything other than 0 here on xp
    SHORT  nUpper;     should match the upper half of the handle.
    CHAR   ObjectType; example-> 0x0401,   // not all memdc, dc =1, etc,,,
    CHAR   Flags;           --> 0x04 is here, set if memdc, sometimes~. 0x01 is also set sometimes for kernel objects
    PVOID UserData;
} GDI_TABLE_ENTRY, *PGDI_TABLE_ENTRY;

Yuan says: "On Windows 2000, the nCount field is always zero. That is to say, it is not 
used. But on Windows NT4.0, it is used for certain GDI objects."

As we are currently using
    CurrentProcessId = PsGetCurrentProcessId();
    LockedProcessId = (HANDLE)((ULONG_PTR)CurrentProcessId | 0x1);

and
        (void)InterlockedExchangePointer(&Entry->ProcessId,
CurrentProcessId);

we should probably use HANDLE or ULONG for ProcessId

We should check how all this is on a 64 bit system, that might give us
some more hints...

Timo

James Tabor schrieb:
> Hi!
> Sorry for the delay here,,,
>
> This is what we know to be correct sofar. The "Book" section 3.4
> GdiTableCell structure is not necessarily correct.
>
> typedef struct _GDI_TABLE_ENTRY
> {
>     PVOID KernelData;
>     SHORT Count:15;   Count number of refs.
>     SHORT Lock:1;        Does set if locked by process. It also
> explains why the count shows 1 -> 3 most of the time.
>     SHORT ProcessId;   Process Id is here.
>     SHORT  nUpper;     should match the upper half of the handle.
>     CHAR   ObjectType; example-> 0x0401,   // not all memdc, dc =1, etc,,,
>     CHAR   Flags;           --> 0x04 is here, set if memdc, sometimes~.
>     PVOID UserData;
> } GDI_TABLE_ENTRY, *PGDI_TABLE_ENTRY;
>
> Thanks,
> James
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20071214/8c922095/attachment.html