Windows API differences 32/64-bit

[sinsi]

Are there any Windows API calls with a different count of arguments between 32- and 64-bit? Logic says no, but never assume...

[hutch--]

Not that I have seen but that is no guarantee. Usual irritations are argument sizes, with some structures that have DWORD members that have to be called in 64 bit ABI, the invoke I have done handles that but you can put it in a 32 register then use the 64 bit register to manually call the API.

[jj2007]

Check the header files for WIN64 near WINAPI - here is one (irrelevant) example where a switch changes an include file:

Code Select Expand

#if defined(_WIN64)
#include <pshpack8.h>
#else
#include <pshpack4.h>
#endif

And take a thorough look at the SetWindowLongPtr debate. So far, I never found differences, and my "dual" sources all build fine in both modes. If C/C++ compilers can build their executables with one set of header files, then you can certainly do the same with a macro assembler. My \Masm32\MasmBasic\Res\DualWin.inc could be a source of inspiration ;)

[sinsi]

Yeah, my thought is to have one set of includes. Cheers.

[hutch--]

C has always done that, you can build a win3.0 window written in pure C in Win64. In 64 bit MASM it has its own set of API headers and the earlier include files are not compatible with 64 bit MASM so there is no loss in them being different.

64 bit MASM includes look like this.

externdef __imp_AddAtomA:PPROC
AddAtomA equ <__imp_AddAtomA>
  IFNDEF __UNICODE__
    AddAtom equ <__imp_AddAtomA>
  ENDIF

externdef __imp_AddAtomW:PPROC
AddAtomW equ <__imp_AddAtomW>
  IFDEF __UNICODE__
    AddAtom equ <__imp_AddAtomW>
  ENDIF

externdef __imp_AddConsoleAliasA:PPROC
AddConsoleAliasA equ <__imp_AddConsoleAliasA>
  IFNDEF __UNICODE__
    AddConsoleAlias equ <__imp_AddConsoleAliasA>
  ENDIF