hWnd:qword, uMsg:dword, wParam:qword, lParam:qword
invoke WriteConsole,hStdOut,inBuf,dwBytesRead,addr dwBytesWrite,NULL
still uses dword?
Are you referring to the prototype for WndProc under x64 ?
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.
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.
QuoteUMSG == UINT is still a dword under x64
please to see the h264vid.asm (http://masm32.com/board/index.php?topic=6714.msg71849#new)
ml64.exe passed.
deleted
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.
deleted
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.