Which ml64.exe?

[jimg]

In your pinned post "Current build of the 64 bit MASM SDK", you say-

You still need to add the Microsoft binaries which would typically be from an installation of vs2017 or from an earlier version for Win7 64. In the bin64 directory there is a file called "Microsoft_File_List.txt" which shows the files you need. The list is from the current version of Visual Studio 2017 version and if this is the version you have, use the ML64 from the "x86_amd64" directory that is 402,584 bytes in size.

So I thought I'd give it a try.  When I installed MS C++, I got two ml64.exe's as you said above, however they were in the "bin\Hostx64\x64" and "bin\Hostx86\x64" folders.  Both are version 14.14.26433, one is 454,752 bytes and the other  is 597,608 bytes.  Based on the "x86_amd64" comment above, I assume you want the one in in Hostx86 folder.  Most of the rest of the files listed in "Microsoft_File_List.txt" only exist in the Hostx64 folder however.

[hutch--]

Jim,

Use the smaller one, there is something broken in the larger one that has a bad lag before it runs. The smaller one works fine.

[jj2007]

Some versions have serious problems, like being extremely (!) slow or spitting out garbled error messages, like this (14.00.24210.0, 9 June 2016, 581776 bytes; the source builds fine with other ML64 versions):

Code Select Expand

** 64-bit assembly **
\Masm32\MasmBasic\Res\JBasic.inc(413)ed size
\Masm32\MasmBasic\Res\JBasic.inc(413) : error A2013:.MODEL must precede this di\Masm32\MasmBasic\Res\JBasic.inc(414)ed size
\Masm32\MasmBasic\Res\JBasic.inc(414) : error A2034:must be in segmen\Masm32\MasmBasic\Res\JBasic.inc(415)ed size
\Masm32\MasmBasic\Res\JBasic.inc(415) : error A2013:.MODEL must precede this dit be in s\Masm32\MasmBasic\Res\JBasic.inc(416)ed size
\Masm32\MasmBasic\Res\JBasic.inc(416) : error A2034:must be in segmen\Masm32\MasmBasic\Res\JBasic.inc(417)ed size
\Masm32\MasmBasic\Res\JBasic.inc(417) : error A2034:must be in segmen\Masm32\MasmBasic\Res\JBasic.inc(418)ed size
\Masm32\MasmBasic\Res\JBasic.inc(418) : error A2013:.MODEL must precede this dit be in s
***********
ASCII build
***********

\Masm32\MasmBasic\Res\DualWin.inc(78)ed size
\Masm32\MasmBasic\Res\DualWin.inc(78) : error A2119:language type must be sp

The same snippet builds fine with version 14.00.24210.0 of 9 June 2016, 528528 bytes, but it takes over 16 seconds.
It also builds fine with version 14.00.24210.0 of 9 June 2016, 402584 bytes, and takes only 0.8 seconds.

14.00.23026.0 produces garbage, but 10.00.30319.01 of 19 March 2010 and 14.10.24930.0 of 21 February 17 look OK.

Normally, I use 10.00.30319.01 of 19 March 2010 because it's faster than 14.10.24930.0 (600 ms for the snippet instead of 630; for comparison: UAsm needs 400ms, AsmC 390), but note that every now and then it produces the error A2044:invalid character in file. Don't panic, just hit the build button again.

The snippet:

Code Select Expand

include \Masm32\MasmBasic\Res\JBasic.inc ; ## builds in 32- or 64-bit mode with ML, AsmC, JWasm, HJWasm ##
Init ; OPT_64 1 ; put 0 for 32 bit, 1 for 64 bit assembly
  MsgBox 0, "Wow, it works!!!!", "Hi", MB_OK or MB_SETFOREGROUND
EndOfCode

Have fun :lol:

[jimg]

Thanks.
Now that I have ml64.exe I thought I'd try the memreg routine Hutch uploaded.  I get the following errors-

Code Select Expand

\masm32\include64\win64.inc(12787) : error A2008:syntax error : lpThis
\masm32\include64\win64.inc(12789) : error A2008:syntax error : lpThis
\masm32\include64\win64.inc(12791) : error A2008:syntax error : lpThis
\masm32\include64\win64.inc(16474) : error A2008:syntax error : ExceptionInfo
memreg.asm(41) : error A2008:syntax error : rsi
memreg.asm(43) : error A2008:syntax error : SaveRegs
memreg.asm(117) : error A2008:syntax error : RestoreRegs
P

The win64.inc file is 785887 bytes long.  Is this the right one?

[hutch--]

Jim,

What are you trying to build (the code). You cannot mix and match this stuff, other assemblers are not compatible with 64 bit MASM. I have posted the latest macro file that will solve some of your error messages but I don't know how you have built the rest.

You need the libraries, include files and the macro file to build this stuff and it is not compatible with any of the other assemblers, the format is from Microsoft in terms of object modules, libraries and include files, the macro file is written using the ML64 pre-processor and would not be compatible with any other assembler.

Now that you have the right version of ML64, make sure you use the 64 bit linker from the same source.

[hutch--]

JJ,

I am not sure what the pile of garbage you posted is about apart from being misleading noise dragging in other assemblers. Build the posted ML64 MASM code with the right tools and it builds and runs correctly.

[zedd151]

.... the right version of ML64, make sure you use the 64 bit linker from the same source...

what about polink, included in \buildx64\bin64? I have been experimenting trying out 64 bit code, and was wondering about that.

[hutch--]

Polink works fine and its useful to have around as it builds slightly smaller than Microsoft LINK. In Jim's case where he has downloaded the VS files, he can use the 64 bit version of LINK that comes in the VS stuff. I would always recommend downloading Pelles C as it is very well written and Pelle's tools are very up to date technically.

[jimg]

Clearly I have yet once again irritated you with my ignorance.

The source was exactly the files you uploaded in the mem_reg test.

I have uploaded them here, along with the output of the dos window as results.txt

The only changes I made were in the makeit.bat file, I commented out the echo,off and the link.

The errors are strictly assembling and have nothing to do with link.

I also added a full directory of the brand new masm32 I installed on my R: drive and to which I added all the new stuff I could find on the forum.  I don't really expect you to slog thru the directory output, but it's there just in case as dir.txt

In the mean time, I will just await the next full release of masm32 with the 64-bit changes you have made since the last release rather than trying to construct it from bits and pieces.

Sorry to try your patience, 70 wasn't too bad, but 71 has been a real bitch.

[hutch--]

 

Jim,

No irritation, just trying to make sure you have all of the bits. The problem is the project is a work in progress so things will keep changing, mainly by addition of extra bits. The macro file is changing the most as I add bits to it, the most recent was the USING SaveRegs and RestoreRegs and I have just finished an .IF single line macros which I have not added yet.

Seems like you have the right version of ML64, LINK from the same source and have built the libraries and include files, get the latest macro file and replace the earlier one with it and the most recent code that uses the latest capacity should build OK. The problems will only be the missing bits.

LATER : I have just looked at the lines in the win64.inc file and it appears to be COM related so just to test it, I commented the COM stuff out and everything still builds OK.

Try using the latest macro file and if that does not solve the problem comment out this block of code in the file.

; REFIID TYPEDEF PTR IID
; PPVOID   TYPEDEF PTR PVOID
; LPTHIS   TYPEDEF PVOID
; QueryInterfaceProto   TYPEDEF PROTO lpThis:LPTHIS,iid:REFIID,ppvObject:PPVOID
; QUERYPROC         TYPEDEF PTR QueryInterfaceProto
; AddRefProto         TYPEDEF PROTO lpThis:LPTHIS
; ADDPROC         TYPEDEF PTR AddRefProto
; ReleaseProto      TYPEDEF PROTO lpThis:LPTHIS
; RELEASEPROC         TYPEDEF PTR AddRefProto
;
;   IUnknown STRUCT
;     QueryInterface QUERYPROC ?
;     Addref   ADDPROC   ?
;     Release   RELEASEPROC ?
;   IUnknown ENDS

I had to untangle a mountain of include data like this to get rid of the typedefs and much of the files content apart from what had been copied from the 32 bit windows.inc was a tangled mess of typedefs that had to be fixed so you could build reliable code.

[Vortex]

Hi jimg,

Here is how I got ml64.exe. Following this installation order :

VS2010 C++ Express
SDK 7.1
VS2010 SP1
SP1 Compiler patch KB2519277

https://stackoverflow.com/questions/8044385/64-bit-build-on-microsoft-visual-c-express-2010/8334985

Code Select Expand

ml64.exe
Microsoft (R) Macro Assembler (x64) Version 10.00.40219.01


Code Select Expand

21.02.2011  20:53            35.664 cvtres.exe
14.03.2011  19:55            14.160 dumpbin.exe
14.03.2011  19:55            14.160 editbin.exe
14.03.2011  19:55            14.152 lib.exe
21.02.2011  19:03           851.272 link.exe
18.02.2011  15:01               377 link.exe.config
21.02.2011  20:53           363.336 ml64.exe
14.03.2011  19:55           241.488 mspdb100.dll


About x86_amd64 :

When compiling x64 code, what's the difference between "x86_amd64" and "amd64"?

The native and cross-compiler will both generate the same machine code. You will however gain some benefits by running a native 64-bit compiler process on a 64-bit workstation (larger registers, larger memory space, etc...).

The native compiler will only run on an 64-bit copy of Windows, so if your workstation is 32-bit this compiler won't even run.

The cross-compiler is meant to run on x86 machines even though it will run on a 64-bit copy of Windows via WoW; however, there is no reason to do this.

x64 on x86 (x64 cross-compiler)
Allows you to create output files for x64. This version of cl.exe runs as a 32-bit process, native on an x86 machine and under WOW64 on a 64-bit Widows operating system.

x64 on x64
Allows you to create output files for x64. This version of cl.exe runs as a native process on an x64 machine.

https://stackoverflow.com/questions/3508173/when-compiling-x64-code-whats-the-difference-between-x86-amd64-and-amd64

[Vortex]

Hi jimg,

Using the setup above and Hutch's latest macros64.inc file dating 30 July 2018, I can assemble and link your memreg example.

[jimg]

Thanks guys

Hutch-  I also had to comment out lines 16474 and 16475

Code Select Expand

;VectoredHandler TYPEDEF PROTO C ExceptionInfo:PEXCEPTION_POINTERS
;PVECTORED_EXCEPTION_HANDLER TYPEDEF PTR VectoredHandler

and then everything worked.  Thanks for your patience.

Vortex-
Is the 2010 version going to be okay moving forward?  I would love to have someone say this is the one we are using.  Is there a history file somewhere showing the differences between the versions of ml64.exe?

[hutch--]

Jim,

Its the OS version that determines which version you use. The VS version you downloaded appears to be for Win10 64 bit and if that is what you are using, it should be OK. The easiest way to test if the version works is to run it from the command line with the normal "/?" and if it starts and does not squark about some missing DLL, then it will be fine. Do the same with the LINK.EXE version you have.

[Vortex]

Hi jimg,

Is the 2010 version going to be okay moving forward?  I would love to have someone say this is the one we are using.  Is there a history file somewhere showing the differences between the versions of ml64.exe?

To be honest, I don't know what are the advantages of using ml64.exe supplied with VS 2015\2017 but the version coming with VS2010 works fine with Hutch's masm64 setup.