Using the Masm64 SDK with UAsm

[jj2007]

Given that, compared to ML64, UAsm is by far the better assembler (HLL features, speed), it would be nice to use it with Hutch' libraries. But the hurdles are high - here is a snippet that assembles with UAsm, links with link.exe and runs fine:

Code Select Expand

include \Masm64\UAsmJJ\masm64rt_JJ.inc ; *** modified version ***
.data
txHello db "Hello World", 13, 10, 0
.code
entry_point proc
Local pContent:QWORD, ticks:QWORD
  StdOut PROTO :QWORD
  invoke StdOut, addr txHello
  ; lea rax, main
  if 1 ; works fine
xor ecx, ecx
call ExitProcess
  else
; Kernel32.inc
; externdef __imp_ExitProcess:PPROC
; ExitProcess equ <__imp_ExitProcess>
; ExitProcess PROTO :QWORD
; error: INVOKE requires prototype for procedure
invoke ExitProcess, 0                        ; terminate process
  endif
entry_point endp
end

[zedd151]

Sound more like a Uasm issue, rather than a Masm64 SDK issue. 

[jj2007]

Many of the macros that Hutch coded for the Masm64 SDK were workarounds for the absence of high level constructs in ML64, such as .if ... .endif, .Repeat ... .Until etc.

That includes the invoke macro. Unfortunately, it's not a good simulation of the real thing. The PROTOs won't work as they should. Hutch used to "redefine the problem" by saying that UAsm wasn't compatible with ML64, or by saying that we were stuck in 20th Century thinking.

Truth is that a real invoke macro checks if the number and type of arguments are correct. The JBasic jinvoke macro does that, the Masm64 SDK invoke macro doesn't.

The Masm64 SDK library (\Masm64\lib64\*.lib) is absolutely usable. The include files and the sources in \Masm64\m64lib\*.asm are, to put it mildly, problematic.

[zedd151]

Does this mean that you would want to help make the Masm64 SDK more compatible with uasm?
Uasm is under continuous development, maybe any changes to the masm64 SDK would be broken (uasm compatibility) by subsequent changes in Uasm.
Perhaps get in touch with johnsa or habran to reach your goal?

[jj2007]

UAsm is remarkably stable (in contrast to AsmC). The problem is that we have
a) a modern, stable assembler without a proper library
b) a proper library tailored to an assembler that really, really sucks.

Combining the better parts of the two is the best option to get 64-bit Assembly off the ground.

Btw it's not my top priority: I have JBasic for dual 64-/32-bit coding. It works fine for my needs. However, knowing how sensitive some of the guys here react to BASIC syntax, I doubt that it is a solution for the forum.

Code Select Expand

include \Masm32\MasmBasic\Res\JBasic.inc ; ## console demo, builds in 32- or 64-bit mode with UAsm, ML, AsmC ##
Init ; OPT_64 1 ; put 0 for 32 bit, 1 for 64 bit assembly
  PrintLine Chr$("This program was assembled with ", @AsmUsed$(1), " in ", jbit$, "-bit format.")
  Print ComCtl32$("It uses common controls version %i.%i\n") ; see EndOfCode below
  Open "I", #1, "SkelDualConsole.asc"
  Print Str$("The source (in rtf format) is %i bytes short\n", rv(GetFileSize, rax, 0))
  Close #1
  jinvoke MessageBox, 0, Chr$("JBasic is fantastic"), Chr$("Hello"), MB_OK or MB_SETFOREGROUND
EndOfCode XP ; remove the XP if you don't use UAsm
; activate your favourite debugger by eliminating the x, then insert int 3 somewhere in your code and hit F6
OxPT_DebPath \Masm32\Dbg32Xyz.exe ; default is \Masm32\OllyDbg\ollydbg.exe
OxPT_DebPath64 \Masm64\arkdasm\arkDasm.exe
OxPT_DebPath64 \Masm64\x64Dbg\release\x64\x64dbg.exe ; 64-bit Olly-style debugger
OPT_Assembler ML ; choose your assembler; if it's ML, make sure you got the right versions; some are really buggy
OxPT_Assembler AsmC ; Nidud

Code Select Expand

This program was assembled with UAsm64 in 64-bit format.
It uses common controls version 6.16
The source (in rtf format) is 7216 bytes short

Code Select Expand

This program was assembled with ml64 in 64-bit format.
It uses common controls version 6.16
The source (in rtf format) is 7216 bytes short

Code Select Expand

This program was assembled with ML in 32-bit format.
It uses common controls version 6.16
The source (in rtf format) is 7216 bytes short

Code Select Expand

This program was assembled with UAsm64 in 32-bit format.
It uses common controls version 6.16
The source (in rtf format) is 7216 bytes short

[zedd151]

Okay. Seems a workable solution combining the best of both worlds, but may break existing source codes.
Perhaps best to wait for some input by other Uasm/Masm64 SDK users...

[HSE]

The PROTOs won't work as they should.

The PROTOs won't work because are not there!

[jj2007]

You are right, there is this stuff:

Code Select Expand

externdef __imp_ExitProcess:PPROC
ExitProcess equ <__imp_ExitProcess>

Afterwards, you can't use ExitProcess PROTO :DWORD any more, so UAsm can't use its good invoke

Which means in practice I must rewrite most of the include files. Feasible but a major nuisance. However, since that concerns mostly the WinAPI PROTOs, I could imagine that the UAsm crew has done it already

[Vortex]

Hi Jochen,

WinInc contains all the function prototypes :

https://www.terraspace.co.uk/uasm.html#p9

WinInc is a set of include files for Masm, UASM, JWasm or PoAsm created by h2incx.
It contains all includes required to build Win32 and Win64 applications or dlls.

[jj2007]

I've checked which of the 191 (!) Masm64 SDK functions are used in \Masm64\macros64\macros64.inc:

Code Select Expand

1       arrev            used in ssortd
2       CloseMMF         used in DBend
3       CmdParser        used in CmdBegin
4       cmd_tail         used in cmdtail
5       CreateMMF        used in DBbegin
6       divi             used in fpdiv
7       ErrOut           used in errout  errout
8       execute          used in ssortd  exec  exec
9       font_handle      used in GetFontHandle
10      line             used in conout  conoutpt  GetFontHandle  UnderlineFont
11      load_file        used in loadfile
12      ltok             used in CmdBegin
13      rawssort         used in ssorta  ssortd
14      re_alloc         used in realloc
15      RunUrl           used in url
16      save_file        used in savefile
17      winshell         used in shell
18      StdIn            used in coninpt
19      StdOut           used in stdout  stdout  ccout  print
20      szappend         used in cat$  cat$  cat$  cat$
21      szCmp            used in .case$  .casei$
22      szCmpi           used in .casei$
23      szCopy           used in cst  DBout
24      szLeft           used in left$
25      szLen            used in len
26      szLower          used in lcase$
27      szLtrim          used in ltrim$
28      szMono           used in mono$
29      szmulticat       used in mcat
30      szRemove         used in remove$
31      szRep            used in rep$
32      szRight          used in right$
33      szRtrim          used in rtrim$
34      szSpace          used in space$
35      szTrim           used in trim$
36      szUpper          used in hex$  ucase$
37      underline_font   used in UnderlineFont
38      wait_key         used in waitkey
Only 20% are being used in macros. So far, I haven't seen documentation on how to use the others.

Project attached, and sorry, this is MasmBasic because it's pretty complex.

[zedd151]

I've checked which of the 191 (!) Masm64 SDK functions are used in \Masm64\macros64\macros64.inc:
... ... ...
Only 20% are being used in macros.

Would probably be a good idea to see if any of the remainder are used in any of the executables within the SDK, including examples, the 64 bit editors, tEditor plugins, etc. Not a trivial task, to be sure.

So far, I haven't seen documentation on how to use the others.

I did notice a .doc file in there. I don't have a program to look at that, possibly some 'help' (to be later incorporated into a help file) for some of the yet undocumented functions in there?

Also, some of the functions might just be posted here on the forum with explanation of what they do, etc. possibly with a 'test piece' using it.
These are all just suggestions, btw.
hutch-- was usually very good at explaining what his functions do, so I would be surprised if nothing can be found in the way of at least a brief description. Another possibility is that it is just 'missing' from the hutch file package... and unavailable at this time.

[jj2007]

I did notice a .doc file in there.

Where?

I found this in \Masm64\RtfHelp

[zedd151]

I did notice a .doc file in there.

Where?

I found this in \Masm64\RtfHelp

This, its for MS Word RTF specs apparently. Sorry about that.

"Word2007RTFSpec9.doc" in "masm64_tools" directory, so probably of no use here. I forgot the name of the file, but remembered the extension only.

[zedd151]

Sound more like a Uasm issue, rather than a Masm64 SDK issue. 

In hutch's own words, regarding the Masm64 SDK and uasm ...
https://masm32.com/board/index.php?msg=87375

> the new SDK are written in a way that they can't work with Uasm.

the new SDK are written in a way that they work with MASM.

Other assemblers using MASM resources has been going on since the start of the MASM32 sdk, i guess this latest incarnation is much the same.

I think John has done great work but I am fascinated by the lack of support by its user base when what is needed is a group of users who write their own library and macros.

I just stumbled across this today, and it felt appropriate to post it here.

[jj2007]

I think John has done great work but I am fascinated by the lack of support by its user base when what is needed is a group of users who write their own library and macros.

Judging by the interest in this thread (and any other related to the Masm64 SDK), we might conclude that investing work in the SDK is not worth it.

I will modify RichMasm so that it assembles most (perhaps all) sources in \Masm64\Examples\ - but that's probably my last investment in the Masm64 SDK. If I feel an urgent desire to code in 64-bit land, I have JBasic. It produces shorter and better code.