Do you people think it might work if all of us MASM64 users humbly request Microsoft to release a MASM64 development kit (without having to download Visual Studio)?
Also, since the masm32.com website now also hosts the MASM64 SDK, can that website be renamed to masmsdk.com?
I would not hold your breath getting a sensible response from Microsoft. Years ago I tried and it was like swimming up a waterfall. I own the MASM32.com domain name but long ago someone registered the MASM64.com domain name and after they stopped paying for it, it lapsed to the registrar and to buy it would cost a fortune.
MASM32.com is well known and most people can find it where a new domain name would not be easily found so I have not gone the route of registering the MASMSDK domain name.
The 64 bit version SDK is basically an add on to the 32 bit version so it can use the rest of the support facilities. If I had access at the Microsoft binaries ML64, LINK RC etc .... It could be made into a turnkey environment like the 32 bit version but the difficulties make that option unviable.
I think your idea is a good one but I doubt it could be put into place.
What could be done to get you access to the Microsoft binaries you mentioned plus anything else (other than documentation)?
Would you need some kind of express permission from Microsoft to build the bundle?
I am digging through a bunch of Microsoft Technical Support forums and one of them seems to be accepting requests to enhancements, features and other miscellaneous stuff like what we are discussing here right now towards improving the experience of developing under Microsoft platforms (going forward, only).
Do consider thinking and building a list of what's needed to help you build that turnkey environment, but for 64-bit versions (typically without WOW) and I'll do my best to get things moving on the Microsoft front.
What would make it possible is the specific binaries, ML64, LINK, RC and a couple of the stubs that run off LINK. To make a turnkey SDK you must have permission to redistribute those binaries. You don't need their libraries or include files as the ones constructed from other sources are better and more efficient. I did it long ago with the 32 bit version in OZ where I live but over time Microsoft have become a lot harder to deal with.
Okay, I have initiated communique with Microsoft. If the 64-bit components support thing works out, I have 3 requests off you;
- make the SDK really minimal, nothing except the essentials, not even all those graphical code editors, help files or examples (keep them as separate downloads),
- purchase "masmsdk.com" and issue an auto-redirect from "masm32.com",
- if you must include an editor then please develop a MASM64 syntax-highlighting code-editor which works only at the text-console like old-time "edit.com".
Hope you consider. :smiley:
:biggrin:
I have had many suggestions over a 20 year period regarding editors, make it like Notepad, make it like the Borland IDE, make it like the VC IDE, make it like UltraEdit etc .... Editors (IDEs) are like girlfriends, most have their own taste, I supply my own because I can which means the SDK is not dependent on external sources. Anyone who wants to use an alternative editor can do so.
A stripped down bare binary collection is not an SDK, over 20 years practice tells you a lot about what delivers the most success for the most people, tools that work, reliable clear library support, decent documentation and a place to ask questions and most of all, a very clear licence that garrantees that the SDK will remain copyright true freeware without ever being beholding to any other interest.
To your 3 requests the answer is no, no and no.
Quote from: Mayuresh Kathe on July 19, 2019, 02:13:14 PM
(without having to download Visual Studio)?
Hi new member. There's no need to download Visual Studio, just look for the buildtools. You will get a nice command line interface to ml64, link and all its friends...I have checked and the VS 2019 version also gives you this nice option, just the build tools not the bloated ide. If you have problems finding the link just tell me. :icon_idea:
Masm is ok up to version 10 or so, later versions have all sorts of problems, see Discovering the mysteries of MASM features (http://masm32.com/board/index.php?topic=7491.0)
UAsm (http://www.terraspace.co.uk/uasm.html#p2) is practically bug free and 3 to 5 times faster than MASM, but unfortunately the 64-bit macros of the new SDK are written in a way that they can't work with Uasm. My advice: stick with 32-bit code :tongue:
Quote from: jj2007 on July 20, 2019, 06:15:02 AM
UAsm (http://www.terraspace.co.uk/uasm.html#p2) is practically bug free and 3 to 5 times faster than MASM, but unfortunately the 64-bit macros of the new SDK are written in a way that they can't work with Uasm. My advice: stick with 32-bit code :tongue:
Hi jj2007,
new macros work fine under uasm, just need a little correction :azn:
: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 think we shouldn't be talking in the post made by fearless in the gallery recently about assemblers, so i want to say here that ml64 it has been a great assembler, haven't giving me any kind of problem and you can have it by donwloading the buildtools from microsoft, without the bloated VS IDE :icon_idea:. If you like assembly i think you will love to write 64 bits code... :azn: :thup: Anyway this doesn't mean that other assemblers aren't good or even better (i haven't tried others), you should choose your favorite, that's all. I believe that if for some reason one assembler disappears you should not have to many troubles going with other. Porting all your code from one to another will be a PITA (maybe/probably), but starting new projects shouldn't be. I prefer ml64 because i think it has the best support, but because i'm familiar with it too, since 16 bits development. :icon_idea:
Quote from: felipe on July 20, 2019, 02:37:15 AM
Quote from: Mayuresh Kathe on July 19, 2019, 02:13:14 PM
(without having to download Visual Studio)?
Hi new member. There's no need to download Visual Studio, just look for the buildtools. You will get a nice command line interface to ml64, link and all its friends...I have checked and the VS 2019 version also gives you this nice option, just the build tools not the bloated ide. If you have problems finding the link just tell me. :icon_idea:
Yes Felipe, I would like to have acess to the build tools only.
Can you please help me by providing the link?
Thanks.
Build Tools for Visual Studio 2019 (https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2019)
QuoteThis is taking longer than we expected ...
:skrewy:
QuoteTotal space required
1.72 GB
minimum 1.12 GB
new dll: tbbmalloc.dll
Here you have a direct link for the donwload of the lastest build tools version: https://visualstudio.microsoft.com/es/thank-you-downloading-visual-studio/?sku=BuildTools&rel=16# (https://visualstudio.microsoft.com/es/thank-you-downloading-visual-studio/?sku=BuildTools&rel=16#) If it dosen't work check the link provided by timo, You should see the link for donwloading the build tools there under the section "Tools for Visual Studio 2019" in the bottom of the page. The donwload is 1.3MB size. The installation may take a little, but it totally worth the effort. Also you may think this installation will try to install Visual Studio, but it will not (check "manually" while installing anyway all, don't trust on "default" settings, just in case). You will end up with 4 (at least the 2017 version) command prompts that sets ml64, link, rc and other good friends (including ml, link and other friends of x86 version of the tools), with the environment variables set for you, for every of the command sessions that you start with the tools. I hope you undestand what i just say (sorry my english) if not, then just ask and search. :thup:
Then is up to you if you choose to assemble and link using the command prompt (as i do) or you can put the tools you need in the bin64 folder of masm64. I have there the tools too, but i prefer to use the command line. Also i think qeditor uses by default the polink, which afaik makes smallest executables (and of course you can change the qeditor default selection of tools). But i like to use link and the command prompts. This is far better than using Visual Studio (my personal opinion). I guess others here like Visual Studio because has a debugger, but i like to debug my programs using x64dbg. :azn:
Quote from: felipe on July 30, 2019, 01:44:05 AMThe donwload is 1.3MB size. The installation may take a little
These 1.3 MB are probably just the downloader, which pulls the gigabytes then. Correct me if I'm wrong.
Maybe 1.3 GB ?
bare working compilers + linkers are about 45 MB.
those could copy to USB stick to keep other systems clean of other M$ junk.
6.9 Gb. True Tools are less than 1Gb.
Quote from: jj2007 on July 30, 2019, 07:32:47 AM
Quote from: felipe on July 30, 2019, 01:44:05 AMThe donwload is 1.3MB size. The installation may take a little
These 1.3 MB are probably just the downloader, which pulls the gigabytes then. Correct me if I'm wrong.
Of course is only the downloader (probably is compressed somehow). I'm not correcting you my friend, i'm confirming your suspicious :winking:. But the final gigas used are much less than VS GBs. The build tools folder on my windows 8.1 is 1.08 GB.
O got the same effect, small initial app that then downloaded some gigabytes. Usual mountain of chyte but if you dig through the garbage you find the bin dir that contains the assembler linker and the rest of the useful toys. It is better than downloading the complete VS with the IDE, at least it did not mess up anything.
Here is patch files for USB stick or folder for tweaking:SET VSDIR=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx86\x86\
SET VSDIR2=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx86\x64\
IF NOT EXIST bin MD bin
IF NOT EXIST bin\1033 MD bin\1033
COPY "%VSDIR%cl.exe" bin
COPY "%VSDIR%c1.dll" bin
COPY "%VSDIR%c1xx.dll" bin
COPY "%VSDIR%c2.dll" bin
COPY "%VSDIR%cvtres.exe" bin
COPY "%VSDIR%dumpbin.exe" bin
COPY "%VSDIR%editbin.exe" bin
COPY "%VSDIR%lib.exe" bin
COPY "%VSDIR%link.exe" bin
COPY "%VSDIR%ml.exe" bin
COPY "%VSDIR2%ml64.exe" bin
COPY "%VSDIR%msobj140.dll" bin
COPY "%VSDIR%mspdb140.dll" bin
COPY "%VSDIR%mspdbcore.dll" bin
COPY "%VSDIR%msvcdis140.dll" bin
COPY "%VSDIR%msvcp140.dll" bin
COPY "%VSDIR%vcruntime140.dll" bin
COPY "%VSDIR%tbbmalloc.dll" bin
COPY "%VSDIR%1033\clui.dll" bin\1033
COPY "%VSDIR%1033\cvtresui.dll" bin\1033
COPY "%VSDIR%1033\linkui.dll" bin\1033
SET VSDIR=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\
IF NOT EXIST bin MD bin
IF NOT EXIST bin\x64 MD bin\x64
IF NOT EXIST bin\x64\1033 MD bin\x64\1033
COPY "%VSDIR%cl.exe" bin\x64
COPY "%VSDIR%c1.dll" bin\x64
COPY "%VSDIR%c1xx.dll" bin\x64
COPY "%VSDIR%c2.dll" bin\x64
COPY "%VSDIR%cvtres.exe" bin\x64
COPY "%VSDIR%dumpbin.exe" bin\x64
COPY "%VSDIR%editbin.exe" bin\x64
COPY "%VSDIR%lib.exe" bin\x64
COPY "%VSDIR%link.exe" bin\x64
COPY "%VSDIR%ml64.exe" bin\x64
COPY "%VSDIR%msobj140.dll" bin\x64
COPY "%VSDIR%mspdb140.dll" bin\x64
COPY "%VSDIR%mspdbcore.dll" bin\x64
COPY "%VSDIR%msvcdis140.dll" bin\x64
COPY "%VSDIR%msvcp140.dll" bin\x64
COPY "%VSDIR%vcruntime140.dll" bin\x64
COPY "%VSDIR%tbbmalloc.dll" bin\x64
COPY "%VSDIR%1033\clui.dll" bin\x64\1033
COPY "%VSDIR%1033\cvtresui.dll" bin\x64\1033
COPY "%VSDIR%1033\linkui.dll" bin\x64\1033
for ml, C and C++ compilers.
rc don't belong that package, as it's in WDK.
I have also noticed that tbbmalloc.dll is now required for link.exe to work (I don't think it even existed before).
So, what is the version number now? Does it still suffer from garbled messages and the "off by one byte" bug?
http://masm32.com/board/index.php?topic=7325.msg79884#msg79884
Quote from: jj2007 on July 30, 2019, 05:12:31 PM
So, what is the version number now? Does it still suffer from garbled messages and the "off by one byte" bug?
http://masm32.com/board/index.php?topic=7325.msg79884#msg79884
The version 14.22.27905
I think that bug is fixed.
Quote from: felipe on July 30, 2019, 08:41:56 AM
Quote from: jj2007 on July 30, 2019, 07:32:47 AM
Quote from: felipe on July 30, 2019, 01:44:05 AMThe donwload is 1.3MB size. The installation may take a little
These 1.3 MB are probably just the downloader, which pulls the gigabytes then. Correct me if I'm wrong.
Of course is only the downloader (probably is compressed somehow). I'm not correcting you my friend, i'm confirming your suspicious :winking:. But the final gigas used are much less than VS GBs. The build tools folder on my windows 8.1 is 1.08 GB.
but if you go all out to make a dx program you can skip lot of windows stuff,but the barebone skeleton program and a tiny d3d .dll on your system
what kind of paint program to make your sprites?
about that ml bug,isnt that a feature that lets you take a coffee break while assemble your program? :greenclp:
If someone just don't want to install it:
vs_buildtools__463640547.1541075615.exe --layout --add Microsoft.VisualStudio.Component.VC.Tools.x86.x64
700 MB download.
Examine with 7Zip
Microsoft.VisualCpp.Tools.HostX86.TargetX86,version=14.22.27905
Microsoft.VisualCpp.Tools.HostX86.TargetX86.Resources,version=14.22.27905,language=en-US
Microsoft.VisualCpp.Tools.HostX86.TargetX64,version=14.22.27905
Microsoft.VisualCpp.Tools.Hostx86.Targetx64.Resources,version=14.22.27905,language=en-US
EDIT: it is possible to download some files directly without install program.
Here is part of my batch file for setting up build tools for compiling c++ 64bit apps form normal command prompt.
James
REM 32 bit
REM SET XTYPE=x86
SET XTYPE=x64
IF EXIST C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvarsall.bat(
ECHO Using Visual Studio BuildTools 2019
CALL "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" %XTYPE%
GOTO got_tools
)
If I had unlimited time, I would try these packages. Since I don't have time, I'll stick with UAsm :tongue: