News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

WinInc209 in win64

Started by six_L, November 30, 2017, 01:09:18 PM

Previous topic - Next topic

six_L

hWnd:qword, uMsg:dword, wParam:qword, lParam:qword
invoke WriteConsole,hStdOut,inBuf,dwBytesRead,addr dwBytesWrite,NULL
still uses dword?
Say you, Say me, Say the codes together for ever.

johnsa

Are you referring to the prototype for WndProc under x64 ?

six_L

hi,johnsa
thanks your response.
QuoteAre you referring to the prototype for WndProc under x64 ?
yes.
the uasm245_x64 is a good Assembler. but there are some errors in the inc files.
Say you, Say me, Say the codes together for ever.

johnsa

WndProc definition is:

LRESULT CALLBACK WindowProc(
  _In_ HWND   hwnd,
  _In_ UINT   uMsg,
  _In_ WPARAM wParam,
  _In_ LPARAM lParam
);

HWND == Handle == PVOID == Pointer == QWORD
UMSG == UINT is still a dword under x64
WPARAM and LPARAM == UINT_PTR == pointer = QWORD

So I believe that is correct.

six_L

QuoteUMSG == UINT is still a dword under x64
please to see the h264vid.asm
ml64.exe passed.
Say you, Say me, Say the codes together for ever.

nidud

#5
deleted

six_L

Quote from: nidud on December 04, 2017, 03:25:21 AM
Could be you just being pig-headed thought.
as far as you like,i would be willing to any thought which include the pig-headed thought.
Say you, Say me, Say the codes together for ever.

nidud

#7
deleted

hutch--

Among the many advantages of not needing prototypes apart from the reduction of clutter is that you are free of twiddling data sizes when calling API and similar external functions as the Microsoft win64 ABI passes arguments in 8 byte slots. Take for example a RECT structure in 64 bit that is still defined as 4 x DWORD members which you plonk directly into MoveWindow() without having to change the data size. MoveWindow() will comfortably accept either DWORD or QWORD sized arguments. With a 64 bit (8 byte) location, you can write a BYTE, WORD, DWORD or QWORD to it and that value in any of the 64 bit and smaller data sizes will all end up at the same location on the stack (if you are using a stack frame with its shadow space).

About the only time you have to do more is when you need to modify a DWORD value from a source like GetClientRect() and then put it into a QWORD location as in MoveWindow(). Here you simply write the values you want to modify into 32 bit registers, do the mods then save it back to a 32 bit variable and place it in the argument list of the API function. Compiler may be burdened with all of this clunky junk but an assembler should be free of clutter like this as it only slows development time and introduces more bugs than it fixes.