Simple window at 2.5k.
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
OPTION DOTNAME
option casemap:none
include \masm64\include\temphls.inc
include \masm64\include\win64.inc
include \masm64\include\kernel32.inc
include \masm64\include\user32.inc
includelib \masm64\lib\kernel32.lib
includelib \masm64\lib\user32.lib
OPTION PROLOGUE:rbpFramePrologue
OPTION EPILOGUE:rbpFrameEpilogue
.const
wcex label WNDCLASSEX
cbSize dd sizeof WNDCLASSEX
style dd 0
lpfnWndProc dq offset WndProc
cbClsExtra dd 0
cbWndExtra dd 0
hInstance dq 100400000h
hIcon dq 10003h
hCursor dq 10003h
hbrBackground dq COLOR_WINDOW
lpszMenuName dq 0
lpszClassName dq offset ClassName
hIconSm dq 10003h
ClassName db "Vasily Window Class",0
AppName db "Vasily's Window Example",0
.code
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
WinMain proc <12> ;parmarea 12*8 bytes
LOCAL msg:MSG
invoke RegisterClassEx,&wcex ; addr wcex
mov r10d,CW_USEDEFAULT
invoke CreateWindowEx,0,addr ClassName,addr AppName,WS_OVERLAPPEDWINDOW or WS_VISIBLE,\
dptr CW_USEDEFAULT,dptr CW_USEDEFAULT,dptr CW_USEDEFAULT,dptr CW_USEDEFAULT,\
0,0,hInstance,0
lea rdi,msg
jmp gmsg
lpst:
invoke TranslateMessage,rdi
invoke DispatchMessage,rdi
gmsg:
invoke GetMessage,rdi,0,0,0
test rax, rax
jnz lpst
invoke ExitProcess,[rdi][MSG.wParam]
WinMain endp
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
WndProc proc <4> hWnd:QWORD,uMsg:QWORD,wParam:WPARAM,lParam:LPARAM
.if edx==WM_DESTROY
invoke PostQuitMessage,NULL
.else
leavef
jmp DefWindowProc
.endif
xor eax,eax
ret
WndProc endp
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
end
Attached a converter for Vasily's include files, from plain text with garbage comments to Unicode readable e.g. by RichMasm. Just drag an inc file over the exe.
With the new RichMasm version, Vasily's window example builds just fine, the only change needed is
OPTION DOTNAME ; OPT_Assembler ml64
OPTION CASEMAP:NONE ; OPT_DebugL /entry:WinMainBtw is there no way to teach ML64 where the entry point is? Does it always need a linker option??
EDIT: Found it...
Why does 64-bit MASM not accept an entry point address on the END directive? (https://social.msdn.microsoft.com/Forums/vstudio/en-US/2107f634-1152-4a85-ae48-0d580aaf3f02/why-does-64bit-masm-not-accept-an-entry-point-address-on-the-end-directive?forum=vcgeneral)
QuoteIn 32-bit MASM, the END directive optionally allows us to set the entry point by specifying an address ( http://msdn.microsoft.com/en-us/library/vstudio/wxy1fb5k(v=vs.120).aspx ). But in 64-bit MASM, placing an address after the END directive is treated as a syntax error. I don't see any documentation on this difference, but I have experienced it and have seen a few mentions of it by others.
Of course, we can work around this behavior by specifying the entry point for the linker (Project Properties | Configuration Properties | Linker | Advanced | Entry Point). But this approach means that, if the name of the entry point changes in the source code, it has to be changed also in the linker options.
My question is: Why is the ability to specify an entry point on the END directive not present in ml64? I'm sure there must be a good reason. I'm very interested in knowing why.
Interesting, the M$ MSFT asks the customer to get help from the Masm32 forum :lol:
QuoteMore about MASM, you can also get help from MASM Forum for more suggestions.
That's an interesting conversation jj. I ran into that anomaly a year ago, when running ML64 and JWasm together, and worked around it without clearly realizing it was yet another example of crippling ML64 for no reason. Read that exchange to see what's wrong with M$. First an incredibly over-paid child who knows nothing at all about the issue tries to fob off an experienced programmer by telling him to study X64 architecture and consult the masm32 forum. Then she kicks it upstairs to senior personnel - making, what, a quarter million a year at least? And they give the curious programmer a boilerplate message to open a support case. Even M$ employees have absolutely no possibility to get such info from ML64 project - although it would help if they knew what assembler was. If they understood it as well as they understand back-dating stock options they might be of some use.
I need a bumper sticker "Nuke Redmond"