This article is mainly compiled, and it is used to using friends who write code with VC.
Why use NASM?
It is not conducive to the transformation of the code. Plus the VC's support speed for the new instruction set (3D now!, XMM, etc.) is not enough, it is very inconvenient, so we tend to use external compilation. If you Familiar with MASM or TASM, you don't have to replace it, otherwise the cloud is recommended NASM. NASM and its documents can be downloaded in http://www.web-sites.co.uk/nasm. Best to read the documentation before use. It will only emphasize some key points, but add some omissions, not the full repertoire. NASM supports a variety of latest instruction sets, with considerable macro language support. You will get a more flexible use space than the VC's Inline ASM.
Choose a good programming environment
The editing environment of the NASM is fully feasible, just add Nasm.exe to the Tools-> Customize-> Tools. This is not described in detail here. Yunfeng recommends the compact editor. You You can specify the color of various keywords. The grammar files you made by Yunfeng are here, and it is still not complete. Many NASM's macro statement has not been added, and some of them have been made. So readers will be modified as appropriate. The method of adding EditPlus is to add a syntax file in Tools-> Preferences-> Files-> Syntax. EditPlus supports Output window information capture, add Nasm.exe in Tools-> Preferences-> Tools-> User Tools, and select Capture Output is ok. Of course, if you want to make a separate Win32 / PE file, not compiling into OBJ for VC Link, then you need a link program. It is best to use the Makefile.
How to compile OBJ for VC connection
NASM supports a variety of output formats, although the VC is known as the COFF format used, but actually distins. In addition to the output Coff format, NASM also supports the target file format of the VC, called Win32. I am in the User Tools of Editplus Set up
-i i: / nasm / include / -f win32-$ (filenamenoext) .Obj $ (filename)
Note: The -i here is the path to the header file to add the compiled OBJ. In the project of the VC. In general, the target file has three segments, respectively, respectively, respectively.
The TEXT segment places the code, which is read-only and can run segment DATA segment to place static data. This data is readable. This segment is readable, but it cannot be run. BSS segment placed dynamic data, these data is not put Entering the EXE file, the space assigned after the EXE file is loaded into the memory. A simple program framework is like this:
[BITS 32] [section .text] Global _func _func:; here is written here [section .data] [section .Data] [section .bss] Here, use Global declares a function FUNC that can be called by C (a C function has one Underline prefix) _func: is the entry of this function. Want to use the func in the corresponding C code, you also need to use the extern declaration of FUNC is an external function. If you use it in C , you will need to explain the function to C call mode, method Is the extentn "c" {}
Parameter incoming and processing
The parameter processing of the function is related to its call mode. The default call mode of C is _cdel call mode, and the C non-static member function uses _thiscall, the method of processing stack of various call mode, can check in MSDN The arrival. Write Inline ASM may rarely involve these, but it must be clear here.
WIN32 program with pure compilation
Write Win32 / PE EXE under Win32, I recommend using Borland's OBJ format, because the API in the DLL is easier. But you need to pay attention to some points: NASM default segment is use6, and must be used under Win32 Use 32, and must specify the type of segment. So you must write such a line on the source file header: [section .text class = code use32] [section .data class = data use32] [section .bss class = bss USE32]% define __Sect__ borland's OBJ file can specify the starting tag (..Start), can generally be written as this: [section .text] ..Start Winmain: Your code will start running from Winmain here. And C is different, your Lord There is no parameter incoming, so you have to get the necessary parameters. For example: push dword 0 call getModuleHandle; get Hinstance to get the instance handle (to eax). Exit program can not use RET directly, because your program is a process and not a function, it is necessary to call: push dword 0; ExitProcess call GetModuleHandle above the exit code is kernel32.dll in the API: GetModuleHandleA, it is necessary to declare exported in the assembler source code: import GetModuleHandle kernel32.dll GetModuleHandleA extern GetModuleHandle addition EXITPROCESS is also like this: Import EXITPROCESS KERNEL32.DLL EXTERN EXITPROCESS IMPORT Please refer to NASM documentation.
Good at using NASM powerful macro
This is a section that should be very rich, but the time is limited, only a simple example, defines the following macro:
% Imacro Callapi 1- *% Define %% API% 1% Rotate -1% REP% 0-1% Rotate -1 Push DWORD% 2% endRep call %% API% endmacro then, if you need to call MessageBox, you can write
Callapi Messagebox, [HWND], LPTEXT, LPCAP, 0
HWnd is a global variable saved window handle, of course, 0 lptext is a string pointer of the text. LPCAP is the title string of MessageBox. In addition, I have done a lot such as handle the function parameters, protect stack, etc. Conveniently used macro, It will not be listed here. I hope that I will lead to my head. I can let more friends like Nasm
