1

One would hope that using assembly in Microsoft Visual C++ 2017 would be almost as easy (for those like me who have been writing assembly for over 50 years) as C/C++. These hopes have been dashed.

The help I find online says to Right click on your project’s name and choose “Build Dependencies” then “Build Customizations…”. Or “Project->(right click)->Build Dependencies->Build Customizations...->(check) masm” which is a non-starter because Project->(right click)->Build Dependencies is not an offered choice.

My code assembles from ml64 after removing a few items that masm requires to know the target processor type. And FWIW it appears that extern "C" void myAsmFunc(unsigned int*); requires ‘public _myAsmFunc’. I find that added under bar annoying.

So how do I get not just this particular .asm to assemble but define a general rule for all ml64 assembly code? (It would be nice to enable masm for 32-bit targets. But that’s not what I’m asking.)

πάντα ῥεῖ
  • 1
  • 13
  • 116
  • 190
user3029680
  • 35
  • 1
  • 5
  • It is only a non-starter because you have done something wrong.I hope you aren't right mouse clicking the "project" pulldown menu at the top. The "project" is the name of the project under the solutions explorer tab. – Michael Petch Jan 26 '19 at 01:31
  • I have placed a screen shot of my VS 2017 (it is pretty much the same process since VS 2010) where I have right mouse clicked the project name `ConsoleApplication6` in the Solutions explorer on the left: https://imgur.com/a/VAx8LP3 . `Build Dependencies` is about a 3rd of the way down on that menu. – Michael Petch Jan 26 '19 at 01:36
  • 1
    In your assembly code you can define your functions with `proc C` (ie: `myproc proc C` and it will add the underscores for you. If generating 32-bit code you can place `.model flat, C` at the top. All PROC statements by default will be PROC C.using that directive. – Michael Petch Jan 26 '19 at 01:41
  • 1
    @MichaelPetch - I deleted my prior comment. I'll delete this one later. – rcgldr Jan 26 '19 at 02:08
  • 1
    Possible duplicates: [Compiling assembly in Visual Studio](//stackoverflow.com/q/4548763) / [How can I make a pure assembly project in Visual Studio?](//stackoverflow.com/q/2718239) / [Assembly programming - WinAsm vs Visual Studio 2017](//stackoverflow.com/a/52803496). The last one has screenshots of a walk-through. I don't use Windows or Visual Studio, so I'm not going to close this as a duplicate of any of those; I'll leave that choice for people who can check or test the answers better. (@MichaelPetch, are any of those any good?) – Peter Cordes Jan 27 '19 at 04:30
  • 1
    @PeterCordes :I was originally considering https://stackoverflow.com/questions/52796300/assembly-programming-winasm-vs-visual-studio-2017/52803496#52803496 however this question does also ask about the underscore issue as well. I didn't find a link for that which I liked. I was hoping the OP would get back to us. – Michael Petch Jan 27 '19 at 04:35
  • @MichaelPetch: That's kind of a bonus question about C name mangling. But I guess you or I could post an answer about that, and just link an existing answer for the how-to-use-VS2017 part, instead of closing this as a dup. But that's why the one question per question rule exists: so that questions can be marked duplicates. – Peter Cordes Jan 27 '19 at 04:40
  • @user: if you don't like the leading-underscore convention, use an OS like Linux that doesn't do it. (And has a nicer IMO x86-64 calling convention.) If you want to use Windows or OS X, you have to follow their name-mangling rules, or use a C/C++ compiler that lets you specify the asm name for a function / variable. (Like in GNU C++, `extern "C" int foo(void) asm("real_symbol_name_for_foo");`, supported by all the major x86 compilers except MSVC.) I find leading-`_` annoying, too, and I forget what reasoning if any I've read for it existing. But it's part of the ABI so we're stuck with it. – Peter Cordes Jan 27 '19 at 04:42
  • @PeterCordes : I don't see the point of muddying the waters. This guy wants to generate Win PE programs in MSVC. He's concerned about the Windows ABI. Suggesting moving to another OS is not very helpful advice. This is a Windows question. The underscores were used to denote external linkage to avoid conflict with any runtime language support. As had been pointed out how you define the PROC statements in MASM can hide the underscore issue and allow the assembler to deal with it automagically. With x86-64 the underscores don't apply. – Michael Petch Jan 27 '19 at 05:27
  • @MichaelPetch: It was supposed to be a slightly tongue-in-cheek way of saying that since they presumably *don't* want to change OSes, they're stuck with underscores. (But also to point out that it's a per-platform design decision, not inherent to asm.) I hadn't realized that MASM could hide the need to write leading underscores explicitly. (But honestly that sounds more confusing than helpful unless you do something so asm callers can use `call myproc` instead of `call _myproc`. Does `import _printf as printf` syntax (if that's right) work for `_myproc as myproc` in the same file? – Peter Cordes Jan 27 '19 at 05:56
  • 1
    You'd use the PROTO directive to declare prrintf external and use the default calling convention specified with model. eg: `printf proto:VARARG` with `.model flat,C` at the top will do the proper name mangling. You can override the default language/calling convention with something like `printf proto STDCALL:VARARG`. If you use `EXTERN printf:PROC` no mangling would occur so you'd have to use `EXTERN _printf:PROC` – Michael Petch Jan 27 '19 at 07:29

1 Answers1

0

Rather than take the default, I manually entered the command line stuff. First I create an empty project, then add existing item, the assembly source file(s). Then in the project window for each .asm source file I right click on the name, then right click on properties, general, set excluded from build to no. Then click on custom build tool (you may have to enable this), general, and then the following, using x64.asm as an example source file name.

command line for debug build:
    ml64 /c /Fo$(OutDir)\x64.obj x64.asm
outputs:
    $(OutDir)\x64.obj

command line for release build:  (the only difference is no /c)
    ml64 /Fo$(OutDir)\x64.obj x64.asm
outputs:
    $(OutDir)\x64.obj

For 32 bit builds, use ml instead of ml64.

rcgldr
  • 27,407
  • 3
  • 36
  • 61