Author Topic: WinInc209 in win64  (Read 884 times)

six_L

  • Member
  • **
  • Posts: 132
WinInc209 in win64
« on: November 30, 2017, 01:09:18 PM »
hWnd:qword, uMsg:dword, wParam:qword, lParam:qword
invoke WriteConsole,hStdOut,inBuf,dwBytesRead,addr dwBytesWrite,NULL
still uses dword?

johnsa

  • Member
  • ****
  • Posts: 680
    • Uasm
Re: WinInc209 in win64
« Reply #1 on: November 30, 2017, 08:15:37 PM »
Are you referring to the prototype for WndProc under x64 ?

six_L

  • Member
  • **
  • Posts: 132
Re: WinInc209 in win64
« Reply #2 on: December 01, 2017, 03:28:34 AM »
hi,johnsa
thanks your response.
Quote
Are 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.

johnsa

  • Member
  • ****
  • Posts: 680
    • Uasm
Re: WinInc209 in win64
« Reply #3 on: December 02, 2017, 01:10:10 AM »
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

  • Member
  • **
  • Posts: 132
Re: WinInc209 in win64
« Reply #4 on: December 04, 2017, 02:43:51 AM »
Quote
UMSG == UINT is still a dword under x64
please to see the h264vid.asm
ml64.exe passed.

nidud

  • Member
  • *****
  • Posts: 1506
    • https://github.com/nidud/asmc
Re: WinInc209 in win64
« Reply #5 on: December 04, 2017, 03:25:21 AM »
Could be you just being pig-headed thought.

six_L

  • Member
  • **
  • Posts: 132
Re: WinInc209 in win64
« Reply #6 on: December 04, 2017, 04:51:19 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.

nidud

  • Member
  • *****
  • Posts: 1506
    • https://github.com/nidud/asmc
Re: WinInc209 in win64
« Reply #7 on: December 04, 2017, 05:23:53 AM »
 :biggrin:

Apparently.
 
The source you link to wrap all arguments up to QWORD size to simplify declaration of imported API functions regardless of size actually used.

Example:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms632680(v=vs.85).aspx
Quote
HWND WINAPI CreateWindowEx(
  _In_     DWORD     dwExStyle,
  _In_opt_ LPCTSTR   lpClassName,
  _In_opt_ LPCTSTR   lpWindowName,
  _In_     DWORD     dwStyle,
  _In_     int       x,
  _In_     int       y,
  _In_     int       nWidth,
  _In_     int       nHeight,
  _In_opt_ HWND      hWndParent,
  _In_opt_ HMENU     hMenu,
  _In_opt_ HINSTANCE hInstance,
  _In_opt_ LPVOID    lpParam
);

winuser.inc
Code: [Select]
;HWND
CreateWindowExA proto WINAPI \
     dwExStyle: DWORD,
   lpClassName: LPCSTR,
  lpWindowName: LPCSTR,
       dwStyle: DWORD,
     X: SINT,
     Y: SINT,
nWidth: SINT,
       nHeight: SINT,
    hWndParent: HWND,
hMenu: HMENU,
     hInstance: HINSTANCE,
       lpParam: LPVOID

Code: [Select]
    CreateWindowEx(
0,
"WndClass",
"Window",
        WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
0,
0,
hInstance,
        0)

Code: [Select]
0000001C                    *   invoke CreateWindowExA, 0, addr DS0000, addr DS0001, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, 0, 0, hInstance, 0
0000001C  B900000000        *    mov ecx, 0
00000021  488D1500000000    *    lea rdx, DS0000
00000028  4C8D0500000000    *    lea r8, DS0001
0000002F  41B90000CE00      *    mov r9d, WS_OVERLAPPEDWINDOW
00000035  C744242000000080  *    mov dword ptr [rsp+32], CW_USEDEFAULT
0000003D  C744242800000080  *    mov dword ptr [rsp+40], CW_USEDEFAULT
00000045  C744243000000080  *    mov dword ptr [rsp+48], CW_USEDEFAULT
0000004D  C744243800000080  *    mov dword ptr [rsp+56], CW_USEDEFAULT
00000055  48C744244000000000*    mov qword ptr [rsp+64], 0
0000005E  48C744244800000000*    mov qword ptr [rsp+72], 0
00000067  488B4510          *    mov rax, hInstance
0000006B  4889442450        *    mov [rsp+80], rax
00000070  48C744245800000000*    mov qword ptr [rsp+88], 0
00000079  E800000000        *    call CreateWindowExA

Another type of declaration:
Code: [Select]
externdef __imp_CreateWindowExA:PPROC
CreateWindowExA equ <__imp_CreateWindowExA>
  IFNDEF __UNICODE__
    CreateWindowEx equ <__imp_CreateWindowExA>
  ENDIF

So now all arguments are QWORD's
Code: [Select]
0000001C                    *   invoke @CreateWindowEx, 0, addr DS0000, addr DS0001, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, 0, 0, hInstance, 0
0000001C  48C7C100000000    *    mov rcx, 0
00000023  488D1500000000    *    lea rdx, DS0000
0000002A  4C8D0500000000    *    lea r8, DS0001
00000031  49C7C10000CE00    *    mov r9, WS_OVERLAPPEDWINDOW
00000038  48C744242000000080*    mov qword ptr [rsp+32], CW_USEDEFAULT
00000041  48C744242800000080*    mov qword ptr [rsp+40], CW_USEDEFAULT
0000004A  48C744243000000080*    mov qword ptr [rsp+48], CW_USEDEFAULT
00000053  48C744243800000080*    mov qword ptr [rsp+56], CW_USEDEFAULT
0000005C  48C744244000000000*    mov qword ptr [rsp+64], 0
00000065  48C744244800000000*    mov qword ptr [rsp+72], 0
0000006E  488B4510          *    mov rax, hInstance
00000072  4889442450        *    mov [rsp+80], rax
00000077  48C744245800000000*    mov qword ptr [rsp+88], 0
00000080  E800000000        *    call @CreateWindowEx

You can't really mix these two.

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 5427
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: WinInc209 in win64
« Reply #8 on: December 04, 2017, 10:37:29 AM »
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.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin: