This question already has answers here:
How to write hello world in assembly under Windows?
(9 answers)
Closed 8 years ago.
The little time I became interested in atraz assembly. Nasm first started with Linux ... I did some basic stuff, but wanted to do in Windows. Hence googled a bit and saw some things for Dos. But depended on emulators. I want to program for Windows 8 64-bit Intel, but everything I search for Windows redirects to Dos ...
In linux to do is interrupt int 80h, int 21h in Dos, Windows I have no idea how to get a code!
One Hello World and an assembler has helped ...
You might want to take a look at this tutorial.
include '%fasminc%/win32ax.inc'
.code
start:
invoke MessageBox,HWND_DESKTOP,"Hello World!","Win32 Assembly",MB_OK
invoke ExitProcess,0
.end start
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I really need some help here. I've been searching online for about 2 days now and can't seem to find an answer to the problems that I got.
I downloaded nasm and installed it it seems to work but I can't seem to find any example code that works on windows 64bit (it would be awesome if you could make a simple hello world example for me or something).
(And how to compile it)
How would I turn the .o file into a .exe?
How would I accesses the screen or gpu memory (I think) to print stuff on the screen (like some sort of console application)?
There a a few things to consider when programming in assembly using NASM under Windows:
NASM is just an assembler
A linker is needed to create an executable.
Windows API are implemented as a user space library.
The library is not entirely in user space, some functions cross the boundary, but the interface to the application is a set of DLL, most notably: kernel32.dll, user32.dll and so on.
Windows' executables can have different subsystems.
Among the others the IMAGE_SUBSYSTEM_WINDOWS_GUI and IMAGE_SUBSYSTEM_WINDOWS_CUI are the most used, the former being used by applications that create windows and the latter by applications that use a console1.
The linker takes to COFF object (.obj) file generated by the assembler, takes a set of library definitions (.lib) and perform these important steps:
It resolves the call to external functions found in the object file.
A function marked as external is meant to be found in one of the library definition, the linker then fixes the call instruction to point to a location where the address of the function will be found at run-time.
It add the dependency libraries to the final executable.
This is done with the help of the PE file format, basically if F if found on the library L then L is added to the dependencies list along with a location where to write the address of F.
The loader will do the rest.
The linking is actually more complex than that.
It is also responsible for setting the various PE flags and settings, including the subsytem and the entrypoint.
To write an executable using NASM with need:
A linker.
The set of library definitions.
These can be found in the Windows SDK2.
The linker we will use in this example is the Microsoft LINK linker.
As #CodyGray pointed out in its comment (quoting because I'm lazy):
The Windows 7 version of the SDK that you linked does include all of the build tools. The Windows 8 SDK changed and no longer ships with the command-line build tools, forcing you to download a Visual Studio package
Once we have the tools, we can start programming.
We will use WriteFile to write a string to the standard output (like we would in Linux assembly).
The handler to the standard output must be retrieved with GetStdHandle though.
In Windows you can exit a process with a ret even with no CRT (C run-time) linked (i.e. in a bare process).
I won't explain the Window 64 ABI nor the trickery of programming in 64-bit.
BITS 64
DEFAULT REL ;RIP relative addressing by default
GLOBAL main ;Main must be visible to the linker
;Function the linker will look for in other modules (libs or objs)
EXTERN WriteFile
EXTERN GetStdHandle
STD_OUTPUT_HANDLE EQU -11
SECTION .data
strHelloWorld db "Hello world!", 13, 10, 0
lenHelloWorld dd $-strHelloWorld
hOut dd 0 ;Will store STDOUT handler
SECTION .text
main:
sub rsp, 30h ;20h (Home space) + 10h (params)
;Get STDOUT handler (Handler are 32-bit values)
mov ecx, STD_OUTPUT_HANDLE
call GetStdHandle
mov DWORD [hOut], eax ;Useless as now, for future reuse
;Write strHelloWorld to STDOUT
mov ecx, eax
lea rdx, [strHelloWorld]
mov r8d, DWORD [lenHelloWorld]
xor r9, r9
mov QWORD [rsp+20h], r9
call WriteFile
add rsp, 30h
ret
To create an executable from this source, we first assemble it into a 64-bit object file:
nasm -fwin64 hello.asm -o hello.obj
then we link it against the kernel32 library (the only one we need):
link /MACHINE:X64 /SUBSYSTEM:CONSOLE /OUT:hello.exe /NODEFAULTLIB /ENTRY:main kernel32.lib hello.obj
the CLI switches are pretty straightforward, NODEFAULTLIB avoid linking with MSVCVRXX.lib, the Microsoft CRT.
Those are the minimal switches necessary to build an executable in this example.
I assume you are smart enough to fix the path issues when issuing the commands above, particularly you can tell link where to find the lib files.
For this example I just copied them from the SDK installation folder.
As proposed in other answers, you can use other assemblers that may came with a linker.
Another possible developing environment is to use gcc (either inside cygwin or as mingw) to perform the linker step.
1 In this case Windows automatically create a console for the application and set the standard handlers appropriately. GUI application can recreate the console too (or more than one), so IMAGE_SUBSYSTEM_WINDOWS_GUI must be intended as "No console by default".
2 The version linked is the first Google result, invest more time in finding a suitable version. Also, I'm not sure if there is a linker in the Windows SDK or you need to download a Visual Studio instead.
Download Flat Assembler.(Download->flat assembler for windows)
http://flatassembler.net/
Extract zip.
Goto 'examples/win64/pe64demo/'
open 'pe64demo.exe'
(source code is in 'pe64demo.asm')
I was trying to make my program accept input without the user having to press enter, so I tried the following:
mov ah,01h
int 21h
But it just crashes my program over an unhandled exception. This seems to be the way to do it according to much that I have read, so why isn't it working for me?
Now, I am fairly new to this language so I still do not exactly understand the process of how this piece of code works, so I would also appreciate what the logic is behind accepting input by pressing enter and accepting input without the user having to press enter.
MY OS is Windows, by the way.
Your code looks like MS-DOS-era assembly. VS2010 doesn't support generating DOS executables, and modern versions of Windows (the 64-bit kind) don't support running them, either. Looks like you were going by some old book or site, one that was written in late 80'es-early 90's. Back at that time, assembly was way more relevant and marketable as a job skill. Not so much these days, although some assembly knowledge won't hurt.
Decide what do you want to learn. If you want to learn modern assembly (and target Windows), get some recent guidance. The techniques are quite different, and int21h isn't among them :) If you're indeed after DOS-era assembly, set up a DOS virtual machine with DOSBox, and find some old free assembler. Visual Studio 2010 won't help you here. The latest version of Visual C++ that generated 16-bit executables was v1.5x.
Specifically why does your program crash. Int21h was how MS-DOS exposed its applciation program interface (API). Windows doesn't support it for Windows executables - there are other ways of invoking the API. When you assemble with Visual Studio 2010, you end up with a Windows executable, not a DOS one, and there's no option to generate a DOS one. As for the Windows executables, they're not supposed to invoke interrupts at all - that's a crash condition.
You need to obtain a tool set that can generate 16 MS-DOS programs. These should run on DOSBOX, or on a Virtual PC with MS-DOS installed on it. Microsoft included 16 bit tool sets up to Visual C / C++ 1.52, but Visual C / C++ 4.0 and 4.1 also contain the 1.52 16 bit tool set. The older version of the compilers would be named Microsoft C 8.xx or earlier version. I don't know if any the early versions of Visual Studio (2002 or 2003) include the 16 bit tool set.
Use the linker version 5.60 to generate 16-bit DOS applications. You can get this from:
http://download.microsoft.com/download/vc15/Update/1/WIN98/EN-US/Lnk563.exe
Dirk
I am trying to learn assembly language in my spare time to help me in my role as a developer using high level languages.
I have followed the NASM tutorial here: http://leto.net/writing/nasm.php.
I am able to create and run a simple program that prints HelloWorld to the screen. I am confused by the following paragraph in the link above:
mov eax,5 ; the syscall number for open()
So where do find out all of the semantics for all of the various system calls?
Well first, the numbers are listed in asm/unistd.h in Linux, and sys/syscall.h
in the *BSD's
I assume that this means that: if there is a 5 in the eax register, then it is a system call for open. Are the rest of the system calls documented somewhere?
I am using NASM on a Windows 7 PC.
List of Windows API calls
If and when you use NASM on Linux,
http://asm.sourceforge.net/syscall.html#1
http://syscalls.kernelgrok.com/
This question already has answers here:
int 13h in windows protected mode?
(4 answers)
Closed 8 years ago.
I am trying to read the FAT using Int 13H of but its Failing as I run the program. It flashes a message "Access Denied " though I am working in the Administration Domain Can any one answer me the reason and solution for it
Thanking You
Gaurav
Use the CreateFile API for Win32 as detailed in this article:
http://support.microsoft.com/kb/100027
Note in Windows Vista direct disk access is restricted further:
http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx
I need to create an executable from the next assembly code:
.MODEL SMALL
.DATA
TEXT DB 'Hello world!$'
.CODE
.STACK 20
.STARTUP
MOV AX, #DATA
MOV DS, AX
MOV AH, 9
MOV BL, 02H
INT 10H
MOV Dx, OFFSET TEXT
INT 21H
MOV AH, 4CH
INT 21H
END
It works with Turbo Assembler (tasm.exe), but I don't want to continue working with it, because it doesn't run in Windows 7.
Thanks.
If there is an ongoing need to develop MSDOS programs, run a 16-bit environment like DOSBOX. That way tasm.exe—one of the finest assemblers of its day—can also run, along with your program, and the tools that go with tasm—Turbo Debugger, Turbo Linker, and Turbo C.
You could also install Windows XP or Windows 98 over Windows 7, as a multi-boot alongside it, or in a virtual machine hosted by Windows 7. Either way, you'd then have the ability to run MSDOS programs without hassle.
As Greg Hewgill mentioned, major rearchitecting of the program is needed for it to run in a 32-bit (or greater) environment.
use Microsoft macro assembler (MASM)
You could try NASM or MASM, but your source will likely need minor changes to work with those.
Your code as given is suitable for 16-bit DOS systems. To use a modern assembler, you will have to modify your code to work in a 32-bit environment, which may be a nontrivial process. All the code you've given so far will need to be rewritten.
I recommend NASM as it is an active, well supported project.
GNU Assembler