ptr

[jimg]

in win64.inc is the line
UINT_PTR        TYPEDEF PTR

in masm64, is that 32 or 64 bits?

I'm guessing that all PTR are 64 bit, which means

PUINT TYPEDEF PTR UINT

means it's a 64 bit pointer to a 32 bit value.

For this, Microsoft says
   PUINT is defined as
  typedef UINT *PUINT;
 which is clear as mud to me.

I'm also guessing this was not the correct place to post this.  Sorry, Hutch.

[fearless]

https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx

UINT_PTR

An unsigned INT_PTR.

This type is declared in BaseTsd.h as follows:
C++

#if defined(_WIN64)
 typedef unsigned __int64 UINT_PTR;
#else
 typedef unsigned int UINT_PTR;
#endif

INT_PTR

A signed integer type for pointer precision. Use when casting a pointer to an integer to perform pointer arithmetic.

This type is declared in BaseTsd.h as follows:
C++

#if defined(_WIN64)
 typedef __int64 INT_PTR;
#else
 typedef int INT_PTR;
#endif

so i would see that as a dword size in 32bit, qword size in 64bit

 

   

[jimg]

Thank you.   Your link was where I found the definition puint above.  Was I correct that it is a 64 bit address of a 32 bit value?

Which means UINT_PTR and PUINT are exactly the same thing, correct?

And another question while I'm here-

in win64.inc is
PSDWORD TYPEDEF PTR SDWORD
where PSDWORD is not in the link where the others were, but again, it's a 64 bit pointer to a signed dword this time, correct?

[jj2007]

it is a 64 bit address of a 32 bit value?

The important bit here is "Use when casting a pointer to an integer to perform pointer arithmetic". For example, you want to know how big your buffer is? Take the end, subtract the start. The result may be anything between zero and the address space. This type is meant for such calculations, and of course, it's 64 bit in 64-bit land, but it's not a pointer. It does not point to anything, it's just the difference between two pointers.

[hutch--]

Jim,

Basically in Win64 you use 64 bit integers in most instances with the exception of some structure members that can be 32 bit. Avoid mixed data sized where possible as it can make a mess of some code. In 64 bit Windows, all addresses are QWORD so if anything looks like a PTR or similar equates, they are QWORD in size. This keeps the world simple in most instances, just check the size of structure members.

[jimg]

The important bit here is "Use when casting a pointer to an integer to perform pointer arithmetic". For example, you want to know how big your buffer is? Take the end, subtract the start. The result may be anything between zero and the address space. This type is meant for such calculations, and of course, it's 64 bit in 64-bit land, but it's not a pointer. It does not point to anything, it's just the difference between two pointers.

Thank you.  I'm not trying to be difficult here.  At first I was just going to ignore your post but thought I had better reply since you briefly confused me greatly.
I just thought anything with PTR in it was a "pointer" by definition, and a pointer is just another name for an address.  When people say things like  "Use when casting a pointer to ..." it is unintelligible to me.  But in this case, I still think PUINT is just a Pointer to an Unsigned INTeger (i.e. 64 bit address of an unsigned 32 bit integer), and has nothing intrinsically to do with performing arithmetic.

[jimg]

Basically in Win64 you use 64 bit integers in most instances with the exception of some structure members that can be 32 bit. Avoid mixed data sized where possible as it can make a mess of some code. In 64 bit Windows, all addresses are QWORD so if anything looks like a PTR or similar equates, they are QWORD in size. This keeps the world simple in most instances, just check the size of structure members.

Thank you Hutch, this is exactly my assumptions, but I could easily have been wrong.

I'm working on a 32 bit program that will run on both 32bit and 64 bit windows.  It's the same old tired program (DIP) I've been working on occasionally for years.  So to send messages to the 64 bit program running the listview for the desktop, I need to get the structures correctly defined.  Everything is working except I'm not getting the correct icons using LVM_GETITEM, so I'm now trying LVN_GETDISPINFO.  To do that I need to define the structure NMLVDISPINFO and am struggling to get all the items in the correct places.

From win64.inc I got the following and modified them by adding 64 to the names and changing the type to qword or dword as needed by 32 bit-

Code: [Select]

NMHDR64 STRUCT
  hwndFrom    qword ? ;HWND ?
  idFrom      qword ? ;UINT_PTR ?
  _code       dword ? ;UINT ?
              dword ? ;UINT ?
NMHDR64 ENDS
LVITEM64 STRUCT
  imask      dword ? ;UINT ?
  iItem      SDWORD ?
  iSubItem   SDWORD ?
  state      dword ? ;UINT ?
  stateMask  dword ? ;UINT ?
             DWORD ?
  pszText    qword ? ;LPSTR ?
  cchTextMax SDWORD ?
  iImage     SDWORD ?
  lParam     qword ? ;LPARAM ?
  iIndent    SDWORD ?
  iGroupId   SDWORD ?
  cColumns   dword ? ;UINT ?    ;tile view columns
             DWORD ?
  puColumns  qword ? ;PUINT ?
  piColFmt   qword ? ;PSDWORD ?
  iGroup     SDWORD ?  ; // readonly. only valid for owner data.
             DWORD ?
LVITEM64 ENDS
NMLVDISPINFO64 STRUCT
  hdr   NMHDR64  <>
  item  LVITEM64  <>
NMLVDISPINFO64 ENDS

nmh NMLVDISPINFO64 <>

Still not having a lot of luck, but first step was to make sure I knew what oddball things like PUINT meant.
Thanks for your patience.  Sorry I put this in the wrong place, perhaps it should be in the 64 bit programming section?

[nidud]

deleted

[jimg]

As you see here INT_PTR is special.

It is not a pointer and PINT_PTR is not the same as PINT which points to a signed integer. INT_PTR is more like a signed version of size_t.

Which goes to making things even more confusing and obfuscated.  Why would anyone use a designation like INT_PTR to mean signed qword?
Ridiculous.

[nidud]

deleted

[hutch--]

It may be wise to keep this C++ crud out of here. Bottom line is an address in 64 bit IS 64 bit and registers do not distinguish between signed or unsigned, a 64 bit register is just that, a 64 bit hole to put data into. The whole reason why the 32 bit project MASM32 and this 64 bit version's use of assembler data sizes is to avoid the data size confusion that comes from higher level languages. The size_t variable is useful in distinguishing between ANSI and UNICODE text data but little else.

Look here for TYPEDEF madness.
http://masm32.com/board/index.php?topic=5705.msg60777#msg60777

[jimg]

Hutch-

Next question:
in win64.inc you defined NMHDR as

Code: [Select]

  NMHDR STRUCT
    hwndFrom    HWND ?
    idFrom      UINT_PTR ?
    _code       UINT ?
                UINT ?
  NMHDR ENDS
How did you know to add the extra unnamed UINT at the end.   The microsoft definition https://msdn.microsoft.com/en-us/library/windows/desktop/bb775514(v=vs.85).aspx doesn't have it.   I'm only concerned because it is embedded in the NMLVDISPINFO structure, and it would throw things off if I had done it from scratch, not knowing to do this.

[hutch--]

Jim,

To be honest, I forget, after the first few thousand modifications to that file, the individual details have long been left behind. The structure works fine.

      .case WM_NOTIFY
        mov r11, lParam
        mov rdx, (NMHDR PTR [r11]).hwndFrom