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:
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
Sound more like a Uasm issue, rather than a Masm64 SDK issue. :wink2:
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.
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?
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.
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
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
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
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
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
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...
Quote from: jj2007 on July 13, 2023, 11:23:13 PM
The PROTOs won't work as they should.
:biggrin: The PROTOs won't work because are not there!
You are right, there is this stuff:
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 :sad:
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 :rolleyes:
Hi Jochen,
WinInc contains all the function prototypes :
https://www.terraspace.co.uk/uasm.html#p9
QuoteWinInc 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.
I've checked which of the 191 (!) Masm64 SDK functions are used in \Masm64\macros64\macros64.inc:
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 (http://masm32.com/board/index.php?topic=94.0) because it's pretty complex.
Quote from: jj2007 on September 18, 2023, 10:54:39 PMI'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.
QuoteSo 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.
Quote from: zedd151 on September 19, 2023, 12:11:56 AMI did notice a .doc file in there.
Where?
I found this in \Masm64\RtfHelp
Quote from: jj2007 on September 19, 2023, 12:25:50 AMQuote from: zedd151 on September 19, 2023, 12:11:56 AMI 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.
Quote from: zedd151 on July 13, 2023, 08:57:26 PMSound more like a Uasm issue, rather than a Masm64 SDK issue. :wink2:
In hutch's own words, regarding the Masm64 SDK and uasm ...
https://masm32.com/board/index.php?msg=87375
Quote from: hutch-- on July 20, 2019, 11:18:18 AM:biggrin:
> 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.
Quote from: hutch-- on July 20, 2019, 11:18:18 AMI 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.
Quote from: jj2007 on September 23, 2023, 12:52:27 AMI will modify RichMasm so that it assembles most (perhaps all) sources in \Masm64\Examples\
Done: MasmBasic & RichMasm were updated (http://masm32.com/board/index.php?topic=94.0): Now most if not all sources in...
\Masm32\Examples
\Masm64\Examples
... will assemble & link out of the box just by hitting F6 in RichMasm. No individual batch file is needed, since the IDE will autodetect if:
a) resources are needed
and
b) if it's a console or GUI application.
Please let me know if you find an example does
not build flawlessly.