Ok, I'm on a role... But this is the only real place for anything nasm specific that I can get decent answers to. Thanks everyone for that.

According to
http://msdn2.microsoft.com/en-us/library/aa379630(VS.85).aspx - TOKEN_PRIVILEGES
http://msdn2.microsoft.com/en-us/library/aa489493.aspx - LUID_AND_ATTRIBUTES
TOKEN_PRIVILEGES looks to be setup as:

masm syntax
  Luid dd ?
  Attributes dd ?

  PrivilegeCount dd ?
  Privileges LUID_AND_ATTRIBUTES<> ?

which would make sizeof(TOKEN_PRIVILEGES) = dd + dd +dd or 12
while (nagoa+.inc or win32n.inc) both define Privileges as a pointer. which would make it dd + dd + dd + dd or 16

if the TOKEN_PRIVILEGES structure on msdn had an & before Privileges then it would be a pointer.

any idea if it is supposed to be 12 or 16?
Posted on 2008-02-03 22:55:32 by jakor
alignment might play a part.. microsoft like aligning some of their structs...
easiest way would be to debug it using both 'formats' u mentioned and see
which one returns the right result...
Posted on 2008-02-04 01:14:51 by evlncrn8
The member of is not a 32-bit value. It is 64-bits. The size of the TOKEN_PRIVILEGES structure is 16 bytes. You are calculating sizeof(dd) for which is 4 but you have to calculate 8 since is 8 bytes long. So 12+4 (extra 4 bytes for the member) which makes the structure 16 bytes.

  TLargeInteger = Int64;
  _LUID_AND_ATTRIBUTES = packed record
    Luid: TLargeInteger;
    Attributes: DWORD;

    PrivilegeCount: DWORD;
    Privileges: array[0..0] of _LUID_AND_ATTRIBUTES;

Note the definition of the member above. It is of type TLargeInteger which itself is a 64-bit Integer.

Hope that helps.
Posted on 2008-02-04 04:52:38 by XCHG
Yes it helps a little, i didn't realize it was a qword and when i looked back LUID was really pLUID but the problem I'm seeing is whoever wrote this include file probably used pointers intead of the actual data.... I'll look into it and see. I've almost got enough code written to debug this part =p
Posted on 2008-02-04 12:56:17 by jakor