I am using Visual Studio Community 2019 as ide to code ml64 projects. Current project is Stack problem posted here (http://masm32.com/board/index.php?PHPSESSID=hkrbcdjv0p8bu25cq1pmm04f02&topic=8840.0).
Now I will try to replace masm with uasm. I downloaded uasm249_x64.zip and installed it.
Building my project with masm, generates no errors and no warnings.
I changed the custom build to uasm and item type to uasm. I did not make any changes to the code.
Building with uasm generated "Error MSB3721 The command "uasm.exe /c -win64 -Zp8 /nologo /Zi /Fo"x64\Debug\Source.obj" /W2 /coff Source.asm" exited with code 1. uasm.targets line 49".
So I took an example from the uasm download
option casemap:none
includelib kernel32.lib
includelib user32.lib
externdef MessageBoxA : near
externdef ExitProcess : near
.data
text db 'Hello world!', 0
caption db 'Hello x86-64', 0
.code
OPTION PROC:NONE
main proc
sub rsp, 28h ; space for 4 arguments + 16byte aligned stack
xor r9d, r9d ; 4. argument: r9d = uType = 0
lea r8, [caption] ; 3. argument: r8 = caption
lea rdx, [text] ; 2. argument: edx = window text
xor rcx, rcx ; 1. argument: rcx = hWnd = NULL
call MessageBoxA
xor ecx, ecx ; ecx = exit code
call ExitProcess
main endp
end
Building this code generates same error (MSB3721 The command "uasm.exe /c -win64 -Zp8 /nologo /Zi /Fo"x64\Debug\Project1.obj" /W2 /coff Project1.asm" exited with code 1. uasm.targets line 49).
With masm, after commenting out line "OPTION PROC:NONE", build is successful and the program works. I can also comment out the two libs.
Does anyone have suggestions on what is missing?
I get it running with a few changes and only one commandline option: -win64
option casemap:none
includelib \masm32\lib64\kernel32.lib
includelib \masm32\lib64\user32.lib
externdef MessageBoxA : near
externdef ExitProcess : near
.data
text db 'Hello world!', 0
caption db 'Hello x86-64', 0
.code
OPTION PROC:NONE
start proc
sub rsp, 28h ; space for 4 arguments + 16byte aligned stack
xor r9d, r9d ; 4. argument: r9d = uType = 0
lea r8, [caption] ; 3. argument: r8 = caption
lea rdx, [text] ; 2. argument: edx = window text
xor rcx, rcx ; 1. argument: rcx = hWnd = NULL
call MessageBoxA
xor ecx, ecx ; ecx = exit code
call ExitProcess
start endp
end
MASM is simpler and more reliable.
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
include \masm32\include64\masm64rt.inc
.code
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
entry_point proc
rcall MessageBox,0,"MASM64 Pure and Simple"," UI Template",MB_OK
rcall ExitProcess,0
entry_point endp
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
end
comment #
.text:0000000140001000 C8800000 enter 0x80, 0x0
.text:0000000140001004 4883EC60 sub rsp, 0x60
.text:0000000140001008 49C7C100000000 mov r9, 0x0
.text:000000014000100f 4C8B0557100000 mov r8, qword ptr [0x14000206d]
.text:0000000140001016 488B157A100000 mov rdx, qword ptr [0x140002097]
.text:000000014000101d 4833C9 xor rcx, rcx
.text:0000000140001020 FF15E6100000 call qword ptr [MessageBoxA]
.text:0000000140001026 4833C9 xor rcx, rcx
.text:0000000140001029 FF15CD100000 call qword ptr [ExitProcess]
#
Thank you,
OK, I stick to masm.
Hi, minor28
; GUI #
include d:\masm64\include\win64a.inc
.data
MsgCaption db "Uncle Remus tales#2: MessageBox",0
MsgBoxText db "Win64 Assembly is Great!",0
.code
WinMain proc
push rsp
invoke MessageBox, NULL, &MsgBoxText, &MsgCaption, MB_OK
invoke RtlExitUserProcess,NULL
WinMain endp
end
.text:00000000'00400200: 54 push rsp
.text:00000000'00400201: 33C9 xor ecx,ecx
.text:00000000'00400203: 488D1546000000 lea rdx,[000400250]
.text:00000000'0040020A: 4C8D051F000000 lea r8,[000400230]
.text:00000000'00400211: 4533C9 xor r9d,r9d
.text:00000000'00400214: FF154E000000 call MessageBoxA
.text:00000000'0040021A: 33C9 xor ecx,ecx
.text:00000000'0040021C: FF154E000000 call RtlExitUserProcess
I appreciate your answers and I have no doubt that the uasm example is written correctly. What I wondered was why VS not can build uasm but masm. I guess it's because VS is MS and masm is MS. VS as an ide for masm64 works just fine. I have written some extensions to better fit to assembly.
Previously, when I coded in masm32, I basically only used the built-in macros invoke, .if, .while etc and some custom macros of my own. Now Invoke works well but .if which is important for readability I think does not work so well in VS. Therefore, I thought I would try uasm.
Greetings
minor28
Hi minor28,
The .IF macro is defined in the macros64.inc file which is an important component of the Masm64 package. To get the latest release :
http://masm32.com/board/index.php?topic=8557.0
The problem with masm64 against uasm64 is the lack of support to macros such as .IF/.ENDIF, and more things such as stack management which is done automatically. Things that UASM adds and that makes more friendly to develop huge projects. If you're a top assembly programmer, you wont have problems with masm64, but anyway, UASM64 is a great tool to start with assembly language programming. I have a lot of projects written in assembly language (MASM32) and thanks to UASM64, most of them are ported without any problem. That's why I think it's a great tool with great possibilities. Althought, some times it's quite time consuming to debug software because the lack of support to some features in the debugging format.
Nice day!
Guille
in the masm64. invoke macro,. if macro,. while macro,. repeat macro is as good as the pseudo command in the masm32. I applied them without any problems.
Quote from: stevenxie on October 30, 2020, 06:47:00 PM
in the masm64. invoke macro,. if macro,. while macro,. repeat macro is as good as the pseudo command in the masm32. I applied them without any problems.
Yes, but, because you're using the MASM64 SDK instead of the MASM64 which comes with Visual Studio. :)
MASM64 doesn't support that "pseudo commands" by default.
Quote from: DebugBSD on October 30, 2020, 06:53:48 PM
Quote from: stevenxie on October 30, 2020, 06:47:00 PM
in the masm64. invoke macro,. if macro,. while macro,. repeat macro is as good as the pseudo command in the masm32. I applied them without any problems.
Yes, but, because you're using the MASM64 SDK instead of the MASM64 which comes with Visual Studio. :)
MASM64 doesn't support that "pseudo commands" by default.
Ml64.exe is the macro assembler, its ancient preprocessor, can weave extremely colorful functional code. The masters, such as Mr. steve hutchesson and Mr. vassily, are also skilled in this, and in the masm64sdk for us to achieve the same advanced grammatical functions as ml.exe. For nothing else, just because masm is Microsoft's macro assembly processor. Macro!!
Hi DebugBSD,
The Masm64 SDK provides powerful macros, so the high-level constructs should not be a problem. It's the same with Fasm, the HLL elements are defined in include files :
macro stdcall proc,[arg] ; directly call STDCALL procedure
{ common
if ~ arg eq
reverse
pushd arg
common
end if
call proc }
macro invoke proc,[arg] ; indirectly call STDCALL procedure
{ common
if ~ arg eq
reverse
pushd arg
common
end if
call [proc] }
Quote from: Vortex on October 30, 2020, 07:13:08 PM
Hi DebugBSD,
The Masm64 SDK provides powerful macros, so the high-level constructs should not be a problem. It's the same with Fasm, the HLL elements are defined in include files :
macro stdcall proc,[arg] ; directly call STDCALL procedure
{ common
if ~ arg eq
reverse
pushd arg
common
end if
call proc }
macro invoke proc,[arg] ; indirectly call STDCALL procedure
{ common
if ~ arg eq
reverse
pushd arg
common
end if
call [proc] }
Yes, I knew that.
When I said that MASM64 had a lack of support to such macros, I was talking about the problem that minor28 had building his program into Visual Studio. That's why UASM64 is a great tool. Because, the tool adds such things automatically instead of delegating that to the MASM SDK. It's obvoius that if you want more features, you have two main options: 1) Use the SDK; 2) Create such features yourself.
MASM has long had the option of writing its own macros, the 1990 version had them and the notation has remained much the same for 30 years. They are no joy to write, the pre-processor is buggy but with enough patience you can do a vast number of things with them. The so called MASM compatible Watcom derivatives have tried to emulate the MASM pre-processor with varying degrees of success.
The win with a terse pig like 64 bit MASM is that you are not at the mercy of a compiler/assembler author and have considerable freedom with procedure design, stackframe layouts and not having to try and twiddle the stack for procedure entry and exit. It takes work but you get considerable freedom without the hassle.