Assembly & Visual Studio

[Warlock]

I recently decide to learn Assembly programming Language.So I try to download Masm32.And what can I said is it is working well.But My computer have Visual Studio 2008 Professional.I know that VS 2008 SP1 comes with Masm 9.0.But I dunno how to create the assembly files in visual studio.Since this websites is Masm forums.I hope that someone with Visual Studio knowledge can guide me on how to create assembly file in visual studio.

Although I Know that Masm32 can create assembly language but I would like to use VS to give a try.

Thanks for your kind reply

[hutch--]

I am not a VS man, hate the IDE but the binaries with it are fine for building assembler files. ML, LINK ad RC from the current versions all work OK. VS has no include files for MASM so unless you want to create your own, you are stuck with the MASM32 includes and WINDOWS.INC. I think from memory you can also use the SDK libraries from it for API functions as well.

[GregL]

Warlock,

There's a tutorial for VS 2008 Express Edition here, it's oriented towards his book, but you can filter out the parts that matter. They really didn't have MASM programmers in mind when they designed Visual Studio. It can be done, but it's a bit clunky, so I prefer to use other editors and/or batch files. They have made a few improvements regarding MASM lately, like adding 'rules' for MASM to Visual Studio.

[edit] The MASM32 includes work fine in visual studio.

[baltoro]

I program C++ and use an older version of Visual Studio (2002 or 2003). And, I'm terrible at assembly programming, so I just create the assembly files in the MASM editor, and compile as a separate DLL, which I then link to my C++ program. This makes testing easier.
If you want to add the assembly code to your project in whatever higher language, Visual Studio won't compile it unless you instruct it to use the MASM compiler (by specifying a Custion Build Step in the Project properties Dialog).
Probably the best solution would be to compile your assembly code to an OBJ file, and include that in your Visual Studio Project. The linker should be able to put the whole thing together (although I haven't actually tried this). You won't find alot of information about this on the Internet.
You should read the documentation on Custom Build Steps: http://msdn.microsoft.com/en-us/library/e85wte0k(VS.80).aspx
This might help: http://msdn.microsoft.com/en-us/library/aa295848(VS.60).aspx
...And, this: http://msdn.microsoft.com/en-us/library/aa270978(VS.60).aspx

[hutch--]

Linking object modules is the trick but you have to prototype your asm functions and make sure you get the calling convention right in the prototype. Both C and MASM can use either C or STDCALL so just make sure they match.

[Warlock]

Thank you for all the reply in this thread.It is useful information that I get in the web.

Sorry for my late reply because I just busy on figuring how to program with assembly language.

For Grey Lyon.Thanks for your link.I have read the book recently(Forth edition).I even download his program to try.

Thanks to baltoro because providing the link...Helping a lot.

Thanks to hutch also for useful opinion.

I have successfully assemble sample program from Kip Irvine book.

Although it need lib file and inc file,which I have no idea how to create it.

Yes,baltoro...There is not much information that available in the internet...

[GregL]

Warlock,

You can get the Irvine include and library files here.

You can use the MASM32 includes and libraries in Visual Studio the same way.

[baltoro]

Warlock,    
I have Kip Irvine's book, myself,...and am using it as a reference. It has an awful lot of useless information (all the DOS 16-bit code, especially the handling of Interrupts, is disabled and wiil not run on Windows XP). Actually, the best source of assembly programming information is contained in the code for all the routines included in the MASM LIB. Read through those .asm files, you'll be amazed at how many really useful examples of functional techniques are available.

[GregL]

The 5th edition of the book (Assembly Language for Intel-Based Computers) is an improvement over the 4th edition.

Overall I think it's a pretty good book for MASM beginners.  It's awful damn expensive though.

[Warlock]

 Ya...Now learning assembly by referring to the source code. :lol :lol

[Todd]

I have just completed going through the process of creating a pure assembly language project using Microsoft Visual Studio Pro 2008. I have attached the project files which include all the source code and a more or less detailed instruction document. The procedures cover setting up the VS environment for assembly language as well as how to create your own code library and link it to your project. Please keep in mind that this is a first draft, and I am at the beginning of the learning curve in terms of doing assembly language in Windows. Therefore all comments are welcome.

I am finding that information and documentation on using lib sketchy and outdated. Microsoft's MSDN site has current information, once you find it. Hopefully, you will find the attached project files more helpful. My suggestion is to download the zip file to an empty directory and unzip it. That will create the project folders. Then drag and drop the project folders to where VS keeps all your projects - mine for example are in My Documents\Visual Studio 2008\Projects. This structure was created by default during the installation of VS 2008. I will also mention that these procedures should work okay with Visual Studio 2008 Express (it's free). I did not actually try that environment, but all the same menus and settings were available that I see and use in the pro version.

This thread also mentions some assembly language books, so I'll throw my 2-cents worth in - Kip Irvine's is not too bad. I have the 4th ed. from back in my 16 bit days. However, I just recently discovered a book I like much better - Introduction to Assembly Language Programming - by Sivarama P. Dandamudi. Mine is the third corrected edition, 2000. A while back I bought his book - Guide to Assembly Language Programming in Linux - published in 2005, and I find it to be excellent. And, as mentioned, I really like the one he wrote for the PC using MASM. The code samples throughout the book are not only instructive but useful. Another reasonable book is Richard Detmer's Introduction to 80x86 Assembly Language and Computer Architecture, published in 2010.

Assembly Language for Intel-Based Computers, Kip Irvine, 4th ed. comes with a CD that includes MASM 6.15 - ISBN 0130910139
Introduction to 80x86 Assembly Language and Computer Architecture, Richard Detmer, 2nd ed. ISBN 9780763772239
Introduction to Assembly Language Programming, 3rd printing (2000), Sivarama Dandamudi, ISBN 0387985301

Have fun!

~todd

[dedndave]

passing parameters in registers for library functions probably isn't the best way to go
you can make your routines look and act just like window API functions by passing parameters on the stack
the assembler helps a lot, in this regard
near the beginning of the program (you can put prototypes in a project include file if you like)

Code Select Expand

SomeFunc PROTO :LPSTR
then define the routine like this

Code Select Expand

SomeFunc PROC lpSting:LPSTR

        mov     edx,lpString
;
;
        ret

SomeFunc ENDP
the assembler will generate the prologue and epilogue code that sets up the stack frame and cleans up after
you may use more than one parameter on the PROC line (seperated by commas)

and (in ASM) use it like this

Code Select Expand

        INVOKE  SomeFunc,offset szString

my understanding of C programs is that they primarily look at the EAX register for results
if you want to return more than a single dword, pass the function a pointer to a structure, and fill it with the routine

EAX, ECX, and EDX are rarely preserved across win32 function calls
EBX, EBP, ESI, and EDI are preserved
also, if you set the direction flag, you should clear it when done
EBP is typically used by the assembler to establish the stack frame
the above routine will actually generate code that looks something like this

Code Select Expand

SomeFunc PROC lpSting:LPSTR

        push    ebp
        mov     ebp,esp
        mov     edx,[ebp+8]    ;lpString
;
;
        leave
        ret     4

SomeFunc ENDP
notice that the LEAVE and RET 4 are generated whenever you have a RET
not too bad, but it may be desirable to keep the number of RET's to a minimum

furthermore, the assembler will save registers for you

Code Select Expand

SomeFunc PROC USES EBX ESI EDI lpSting:LPSTR

        mov     edx,lpString
;
;
        ret

SomeFunc ENDP
will generate code like this

Code Select Expand

SomeFunc PROC USES EBX ESI EDI lpSting:LPSTR

        push    ebx
        push    esi
        push    edi
        push    ebp
        mov     ebp,esp
        mov     edx,[ebp+20]    ;lpString
;
;
        leave
        pop     edi
        pop     esi
        pop     ebx
        ret     4

SomeFunc ENDP
here, the epilogue code is a bit larger
now, you can see why we keep the number of RET instructions to a minimum - lol
i.e., we generally use the same RET to exit the routine by branching to it

in library modules, PROC's are public symbols by default
data defines are private by default, and may be made public by use of EXTERNDEF
in the old days, we used PUBLIC and EXTRN
newer assembler versions let you replace both of those with EXTERNDEF
there is a little example at the following link
http://www.masm32.com/board/index.php?topic=15480.0

these are all things that the books don't seem to mention  :bg

one final note
have a look at Hutch's StdOut routine (masm32\m32lib\stdout.asm)
you will notice that only a pointer to the string is passed - not the length
the routine gets the length of the string by calling StrLen
this may seem a little cluttered, at first glance
however, if you use the routine several times in a program, your code is what will be cluttered if you pass both the pointer and the length   :P

[Todd]

Dedndave,

You made really helpful comments! Using PROTO, INVOKE, and LEAVE are new to me. And, certainly part of the reason for getting back into assembly language after 30+ years is so I can move out of the stone age, at least a bit. I can't believe how rusty I've become. But no matter, I'm having some fun doing this again.

I am incorporating your suggestions, and I greatly appreciate your time and thoughtfulness in making your reply.

~todd

[dedndave]

a few years ago, i was in more-or-less the same place
i had written a lot of 16-bit assembler code in the past
difference is - i only had a light familiarity with C - back in the mid-80's
don't really care for C - but, i may have to learn more about it   :P

anyways - the INVOKE thing was new to me, as well
and - as for stack frames - i had always written my own, if i needed to
the older version of assembler (5.1) that i was used to may have supported INVOKE, but i wasn't aware of it - lol

if you look at books, like Kip's or Randy's, you'll see that they write 32-bit code using old 16-bit conventions
passing parms in register, preserving registers that aren't used to return values, etc - just like BIOS/DOS INT behaviour

LEAVE is the same as...

Code Select Expand

        mov     esp,ebp
        pop     ebp

as for returning values in ECX or EDX, i do it all the time
however, my routines are for use in assembler programs
in C programs, i don't think it would be very convenient

[hutch--]

Todd,

Like many of the older guys, my MASM code in the early 90s looked like a CodeView disassembly but with the advent of protected mode programming in 32 bit Windows where you are forced to use system API functions, the old style of code became very unwieldy and hard to read when you had to write large volumes of complex code as is common with Windows API code. The code splits into two types, system based API functions that are neither fast nor simple and bare mnemonic code which can be very fast when written correctly.

You effectively use the INVOKE and other pseudo high level constructs to handle the hacky high level code for Windows which is easily fast enough and certainly better than most compilers but you have pure mnemonic procedures that you write yourself where speed really matters. The normal integer instruction can deliver reasonably fast code while remaining compatible with the 486 era of hardware but as long as you detect the minimum hardware, you have far later and much faster XMM instructions for code tasks that are basically multimedia and similar. Over time various authors have written a reasonable amount of non-multimedia XMM code (SIMD instructions) and in at least some instances have produced very fast code, faster than the best integer instructions.

One thing you must be aware of with assembler coding for Windows, it must be Intel ABI compliant which means you must preserve the correct registers when you interact with the system. Without this the code is unreliable and while it may work on one version of Windows, it can and often does fail on another version. I have seen guys write code that does not do this once the registers have been preserved but any code higher up the call tree must also handle registers the same way which can be treacherously hard to keep track of. Ther is some virtue in dealing with registers correctly as it makes your code reliable across all 32 bit Windows versions and in the 32 bit subsystem in win64.