In your pinned post "Current build of the 64 bit MASM SDK", you say-
QuoteYou 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.
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.
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):** 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: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:
Thanks.
Now that I have ml64.exe I thought I'd try the memreg routine Hutch uploaded. I get the following errors-
\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?
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.
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.
Quote from: hutch-- on August 04, 2018, 12:02:48 PM.... 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.
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.
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.
:biggrin:
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.
Hi jimg,
Here is how I got ml64.exe. Following this installation order :
Quote
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
ml64.exe
Microsoft (R) Macro Assembler (x64) Version 10.00.40219.01
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 :
QuoteWhen compiling x64 code, what's the difference between "x86_amd64" and "amd64"?
QuoteThe 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.
Quotex64 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
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.
Thanks guys :biggrin:
Hutch- I also had to comment out lines 16474 and 16475
;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?
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.
Hi jimg,
QuoteIs 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.
I am glad I looked at this thread. I had one of the slower versions of ML64, for 64 bit host, etc. Which is part of the reason I was going to abandon the idea of writing 64 bit code. Now I have a better version (the one mentioned above 454,752 bytes), much faster assmebly times. I wonder what kind of spyware they put in the 'slow' versions to make it so slow?
I did notice though, that there are files missing that are on hutch's list. (from 1033 folder), I only have clui.dll, linkui.dll and pgoui.dll in my 1033 folder. from x86 host/x64. I have other versions, and I finally got the missing files from where, I forget. Do the other files necessarily have to be the same version as ML6 and LINK ?
I have 14.13.26128 bin and 14.14.26428 bin folders. Both of them have only those three files in \hostx86\x64\1033
What I have put together is this:
Directory of masm32\bin64
08/01/2018 06:34 PM <DIR> .
08/01/2018 06:34 PM <DIR> ..
08/01/2018 06:34 PM <DIR> 1033
07/24/2018 03:59 PM 54,376 cvtres.exe
07/24/2018 03:59 PM 27,232 dumpbin.exe
07/24/2018 03:59 PM 27,240 editbin.exe
07/24/2018 03:59 PM 27,240 lib.exe
07/24/2018 03:59 PM 1,431,656 link.exe
07/24/2018 03:59 PM 409 link.exe.config
08/19/2017 08:47 PM 623 Microsoft_File_List.txt
07/24/2018 03:59 PM 454,752 ml64.exe
07/24/2018 03:59 PM 141,992 msobj140.dll
07/24/2018 03:59 PM 319,632 mspdb140.dll
07/24/2018 03:59 PM 1,376,872 mspdbcmf.exe
07/24/2018 03:59 PM 631,448 mspdbcore.dll
07/24/2018 03:59 PM 187,008 mspdbsrv.exe
07/24/2018 03:59 PM 605,328 mspdbst.dll
07/24/2018 03:59 PM 2,416,792 mspft140.dll
07/24/2018 03:59 PM 1,332,384 msvcdis140.dll
07/24/2018 03:59 PM 462,120 msvcp140.dll
03/21/2015 11:26 AM 79,360 polib.exe
03/21/2015 11:28 AM 152,576 polink.exe
03/21/2015 11:48 AM 176,128 porc64.dll
03/21/2015 11:48 AM 48,640 porc64.exe
11/19/2015 11:56 AM 75,968 RC.Exe
11/19/2015 11:55 AM 435,904 RcDll.Dll
23 File(s) 10,465,680 bytes
3 Dir(s) 39,047,102,464 bytes free
Directory of \masm32\bin64\1033
08/01/2018 06:34 PM <DIR> .
08/01/2018 06:34 PM <DIR> ..
07/24/2018 03:59 PM 23,704 bscmakeui.dll
07/24/2018 03:59 PM 540,952 clui.dll
07/24/2018 03:59 PM 20,624 cvtresui.dll
07/24/2018 03:59 PM 92,296 linkui.dll
07/24/2018 03:59 PM 23,720 LocalESPCui.dll
07/24/2018 03:59 PM 22,176 mspdbcmfui.dll
07/24/2018 03:59 PM 90,784 mspft140ui.dll
07/24/2018 03:59 PM 26,264 pgort140ui.dll
07/24/2018 03:59 PM 34,440 pgoui.dll
9 File(s) 874,960 bytes
2 Dir(s) 39,047,102,464 bytes free
preventing the install ::)
I have a clean install of Windows 7 planned for later at some point, and will try again installing the Runtimes for Windows 7.
ROFL :greensml: I found a backup of a clean unmodifed (other than some settings) version of Windows 7 - 64 bit I though I deleted it.
I proceeded to download Palemoon portable (cant go to M$ site with old IE) and I downloaded and installed VCRuntime2015 without a hitch.
So now I have a working Masm32/64 setup on my Windows 7. I don't have to deal with WIndows 10. :icon_mrgreen:
So everything here is all okay now. :biggrin:
Now all I have to do i trsnsfer all of my crap from the other Win 7 install, so I can use that space for better purposes now. :icon_confused:
You can make to available the missing files in masm64 SDK. I think no one should to spend time and internet downloading that software monstrosity that is VS.
There is only 1 problem with that suggestion, copyright.
Quote
Microsoft (R) Macro Assembler (x64) Version 14.10.24930.0
Copyright (C) Microsoft Corporation. All rights reserved.
VisualCppTools (https://visualcpp.myget.org/feed/dailymsvc/package/nuget/VisualCppTools.Community.Daily.VS2017Layout)
The link does not work.
It downloads if you go down the page and use the direct link, only 853 megabytes. :P
Quote from: TimoVJL on September 27, 2018, 02:05:37 AM
VisualCppTools (https://visualcpp.myget.org/feed/dailymsvc/package/nuget/VisualCppTools.Community.Daily.VS2017Layout)
On the web link is very old version, new release 14.15.26726 contains bug fixes :t
I just finished downloading it and get a file named,
VisualCppTools.Community.Daily.VS2017Layout.14.14.26423-Pre.nupkg
Don't know what opens it.
It's a zip-package.
7-Zip
I just downloaded vs2017 at 1.13 gigabytes, this is where you find the smaller ml64.exe.
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.15.26726\bin\Hostx86\x64>
27/09/2018 03:06 AM 452,296 ml64.exe
1 File(s) 452,296 bytes
0 Dir(s) 48,594,296,832 bytes free
Quote from: LiaoMi on September 27, 2018, 02:54:13 AMnew release 14.15.26726 contains bug fixes
You mean they removed some features...?
:biggrin:
What features, its just as bad mannered as the last one.
Microsoft (R) Macro Assembler (x64) Version 14.15.26730.0
Copyright (C) Microsoft Corporation. All rights reserved.
The latest linker has a problem with a DLL, went back to the older 2017 version.
Quote from: jj2007 on September 27, 2018, 04:02:15 AM
Quote from: LiaoMi on September 27, 2018, 02:54:13 AMnew release 14.15.26726 contains bug fixes
You mean they removed some features...?
:biggrin: :biggrin: :biggrin: :eusa_clap:
Quote from: hutch-- on September 27, 2018, 04:14:03 AM
[/tt]
The latest linker has a problem with a DLL
Is it a serious bug? Something important?
It was looking for a DLL mspdb140.dll which I found a couple of versions but it still did not work.
Quote from: hutch-- on September 27, 2018, 05:02:30 AM
It was looking for a DLL mspdb140.dll which I found a couple of versions but it still did not work.
:biggrin: the same thing happened to me, probably you took files from folders /x86/x64 or /x64/x86/, previous versions in the same way require a mythical mspdb140.dll library. You need to use the versions located in other folders /x64/x64 or /x86/x86/ :t