Author Topic: Win32 Nasm Newbie Needs Help  (Read 17007 times)

nobody

  • Guest
Win32 Nasm Newbie Needs Help
« on: April 03, 2008, 09:59:04 AM »
Hello all,
I am learning AsM for quite a while.
I also bought a book and everything but that book was for Dos.
So, that didnt work.
So after googling and reading tutorials I found out that I should use the NASM assembler.
NASM was Linux and Windows so that should be alright.

I did also found the following code:

org 100h;Init Line? :S
mov dx,msg;Here I move the Labal to the register dx.
mov ah,0x9;Is this the Print line? And why is that?

int 0x21;Go into Dos Mode or whatever..?

mov ah,0x4c;Does he quit here?

int 0x21;Exit Dos Mode??

msg db 'Hello World!$';A label msg with a db that has Hello World


And I did put down the comments.
The comments are what I think that it does.
Since well for some reason all the tutorials I find, well just do not work..

I also learned that if you want to make a Win32 EXE that you'll need a linker.
So I also have Alink. with Win32.lib
But well I just want to learn ASM, for Windows and Linux.
I want to know why I move the hex value 4C into the register AH.
So, well who can tell me this?

Thanks,

Cheers,
Robin

nobody

  • Guest
Re: Win32 Nasm Newbie Needs Help
« Reply #1 on: April 03, 2008, 12:13:56 PM »
Ralf Brown!!!

http://www.ctyme.com/rbrown.htm

Your comments are pretty much right. int 21h is the main "dos services interrupt", and it does different things, depending on what's in ah. 9 prints a $-terminated string, with its offset in dx. 4Ch exits back to the command prompt.

That's for dos - should work under Windows - in a dos subsystem ("fake dos"). If it appears not to be working, it may be that the Window is closing instead of "exit to command prompt" (or Vista?). You could stick:

mov ah, 0
int 16h

Right after the first int 21h. That's a bios interrupt which waits for a key. Gives you time to admire your masterpiece. :) Very useful for graphics programs, where you want to "clean up" - switch back into text mode - but not until you've looked at your graphics...

But you don't want to spend *too* much time learning dos - not much "commercial potential" these days. For Windows, you "push" parameters on the stack, and "call" the API. I think there are some simple examples with Alink. For more on which APIs and what parameters - ask Micro$oft!

For Linux, int 80h is the "main OS services interrupt". Subfunctions go in eax, not al - other parameters in ebx, ecx, edx, esi, edi... and ebp in newer kernels. There's no real equivalent to int 21h/9 - print a '$'-terminated string - but eax=4 is "write to file". ebx takes the file handle - returned by "open"... or STDIN (0), STDOUT (1), STDERR (2) are open and available for us to use. ecx takes the address of the buffer to write from, and edx the number of bytes to write. We will, of course, need to exit (in *any* program - "push 0", "call ExitProcess" for 'doze). For Linux, eax=1 is "sys_exit". Like so:

; nasm -f elf hw.asm (makes hw.o)
; ld -o hw hw.o (makes hw)
; ./hw (say hi)

; we need to tell ld about our entrypoint!
; you'd need this in Windows, too
; for a dos .com file "org 100h"

global _start

section .text
_start:
mov eax, 4  ; __NR_write
mov ebx, 1  ; stdout
mov ecx, msg  ; buffer
mov edx, msg_len  ; length
int 80h  ; ask the OS to do it

mov eax,1  ; __NR_exit
int 80h  ; buh-bye!

section .data
msg db 'Hello, world',0Ah
msg_len equ $-msg

We can get into something more complicated if you tell us what you want to do...

Best,
Frank

nobody

  • Guest
Re: Win32 Nasm Newbie Needs Help
« Reply #2 on: April 03, 2008, 05:53:19 PM »
Ah, well but WHY is:
mov ah, 0
int 16h

that?

I dont see the logics.
Is there maybe a cheatsheet or something that shows me why:
mov dx,msg;Here I move the Labal to the register dx.
mov ah,0x9;Is this the Print line? And why is that?
int 0x21;Go into Dos Mode or whatever..?
mov ah,0x4c;Does he quit here?
int 0x21;Exit Dos Mode??

Do that?

Why??
Ah, thanks already this did explain a lot already ;)

nobody

  • Guest
Re: Win32 Nasm Newbie Needs Help
« Reply #3 on: April 03, 2008, 07:48:21 PM »
Ahhhh... there really isn't any "logic" to it, except maybe "that's the way CP/M did it". (If dos wasn't "stolen" from CP/M, it was "heavily influenced".) The "cheat sheet" you're looking for is "Ralf Brown's Interrupt List". I gave you a link to an online version (D.J. Delorie's got one, too - delorie.com someplace...). From memory, http://www.pobox.com/~ralf will get you to the download site. Or just google for "Ralf Brown's Interrupt List"... or just "RBIL". Big download, but there's a *lot* of information - dos and bios interrupts are only the beginning! You'll probably want it, even if you don't spend much time with dos...

http://home.comcast.net/~fbkotler

is lame as hell, and needs to be updated, but the "clueless newbie's guide" might interest you - I think you've got most of it figured out already. There's an online version of the instruction set reference from the (old) Nasm Manual, too. You might want to check out "int", for example. "Go into dos mode or whatever" isn't a bad comment in this case, but there's a bit more to "int" than that. The int 16h I showed you isn't a "dos interrupt", but a "bios interrupt" - they work about the same, for our purposes. Besides int 21h, which is the "main" one, there are other "dos interrupts". One of my favorites is int 29h - prints al, period.

mov al, 'X'
int 29h
ret

That's a complete program - doesn't even need the "org 100h". Try it!

There *is* logic (we hope) to the code you write, but when it comes to calling the OS... I suppose it must have seemed "logical" to the author of the OS, but to us "it is what it is".

This isn't limited to dos. Windows has OpenFile, ReadFile, WriteFile, CloseHandle. Why not CloseFile? 'Cause that's not the way Uncle Bill wrote it!

The Linux syscalls, go, staring from zero, obsolete, exit, fork, open, read, write, close... "exit" first makes sense - we always have to do that. Why is "fork", next? Maybe it was the first thing Linus wrote, after "exit". (completely different numbers for 64-bit Linux, BTW)

We just have to play along...

Best,
Frank