The MASM Forum

Microsoft 64 bit MASM => MASM64 SDK => Topic started by: seasea on March 09, 2018, 01:14:26 AM

Title: Is the Microsoft's API manual in x64 exist ?
Post by: seasea on March 09, 2018, 01:14:26 AM
Hi, I have a question,for example , the API "CheckMenuItem()":
how can I know the Funciton's paramaters are all changed to QWORD ?
and the error return value is also changed to 0xFFFFFFFFFFFFFFFF?

Not same as MASM32, in MASM64 SDK files,  for example,  the API Functions in "user32.inc",  has no paramaters 。
And I can't find Microsoft's API manual in x64.

Thanks.

---------------------------------
    DWORD CheckMenuItem(
    HMENU hmenu,        // handle to menu
    UINT uIDCheckItem,  // menu item to check or uncheck
    UINT uCheck         // menu item flags
);
If the menu item does not exist, the return value is 0xFFFFFFFF

Title: Re: Is the Microsoft's API manual in x64 exist ?
Post by: jj2007 on March 09, 2018, 02:30:53 AM
The types are valid for x86 and x64, only that a few of them, HANDLE for example, are 64 bits. Most arguments are 32 bit even in x64; the obvious exception being pointers.
Title: Re: Is the Microsoft's API manual in x64 exist ?
Post by: User_1960 on March 09, 2018, 03:04:11 AM
Hello, seasea

Function's parameters are passed in 64-bit registers, so YOU have to change them to QWORD's, perhaps using MOVZX instruction.
Of course, HMENU is already 64-bit.

The following pages from Microsoft may help you:

Windows Data Types
https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.141%29.aspx

x64 Software Conventions
https://docs.microsoft.com/en-us/cpp/build/x64-software-conventions

UNIX Custom Application Migration Guide
Volume 3: Migrate Using Win32/Win64
Chapter 1: Introduction to Win32/Win64
https://technet.microsoft.com/en-us/library/bb496995.aspx

Regards,
TK
Title: Re: Is the Microsoft's API manual in x64 exist ?
Post by: hutch-- on March 09, 2018, 03:38:38 AM
In practice, most arguments are passed as 64 bit but where you must be careful is with structures, many of which are still 32 bit members and with many of them there is no need to change them. Any addressing MUST be in 64 bit as a 32 bit address does not have the address range. To understand how its done, you need to digest the complexity of the 64 bit Microsoft ABI complete with how 64 bit FASTCALL works.

The architecture is different from 32 bit as FASTCALL is the default calling convention. Microsoft recommended using a MACRO in MASM to handle the calling convention and this makes it usable where direct manual mnemonics are very difficult to manage due to the complexity of the calling convention.
Title: Re: Is the Microsoft's API manual in x64 exist ?
Post by: seasea on March 09, 2018, 02:26:53 PM
Thanks, jj2007,User_1960,and hutch--

Yes, MASM x32 document is complete,  is more convenient than MASM x64.

The structures in x64, some vars in structures are still 32 bit, some vars  changed  to 64 bit but names are still dwXXX,  so  strange , ha ha ha.
Title: Re: Is the Microsoft's API manual in x64 exist ?
Post by: jj2007 on March 09, 2018, 05:44:55 PM
Quote from: seasea on March 09, 2018, 02:26:53 PMsome vars  changed  to 64 bit but names are still dwXXX

Can you give an example?
Title: Re: Is the Microsoft's API manual in x64 exist ?
Post by: seasea on March 10, 2018, 01:18:42 AM
Quote from: jj2007 on March 09, 2018, 05:44:55 PM
Quote from: seasea on March 09, 2018, 02:26:53 PMsome vars  changed  to 64 bit but names are still dwXXX

Can you give an example?



Hi, jj2007, for example:

  MENUITEMINFO STRUCT
    cbSize          UINT ?
    fMask           UINT ?
    fType           UINT ?
    fState          UINT ?
    wID             UINT ?
                    DWORD ?
    hSubMenu        HMENU ?
    hbmpChecked     HBITMAP ?
    hbmpUnchecked   HBITMAP ?
    dwItemData      ULONG_PTR ?
    dwTypeData      LPTSTR ?

    cch             UINT ?
                    DWORD ?
    hbmpItem        HBITMAP ?
  MENUITEMINFO ENDS
Title: Re: Is the Microsoft's API manual in x64 exist ?
Post by: jj2007 on March 10, 2018, 01:51:20 AM
Yep, that's pretty clear :t