First program

[mihail]

Just wanted to get my first "hello World" going with NASM on a x 86 32 bit machine running Widows 7. Shameful enough - don't know how to load it, or where the loader is. I tried to to -o in com file but I need a x64 machine for it. So, what exactly do I need to load the .o file into the memory and run the program and keep going??
Thanks,
Mihail

[MJaoune]

I tried to to -o in com file but I need a x64 machine for it.

What do you mean you need a x64 machine, you only need an 64 bit machine to run a program that you have created using 64 bit programming.

NASM doesn't link, it compiles and assembles, if you want an object file to be an executable, then you can use any linker you have (e.g ALink, ld,etc..), but if you mean you want a binary file, then you can use -f bin command in nasm, please notice that -o doesn't change the program's format, -f changes the format not -o, -o only changes the name of the program.

Note: .com is a DOS executable

Best,
Mahmoud

[mihail]

I ran:
nasm -f bin -o hello.com hello.asm
got the com file that I cannot run - "hello.com is not compatible with the version of Windows you are running" running Windows 7 on a system type - 64 bit OS.

[Keith Kanios]

I ran:
nasm -f bin -o hello.com hello.asm
got the com file that I cannot run - "hello.com is not compatible with the version of Windows you are running" running Windows 7 on a system type - 64 bit OS.

While this is feasible in 32-bit Windows, mostly because the x86 architecture is designed to allow it -- and much like the design of 32-bit Compatibility Mode allows 32-bit programs to run within 64-bit Long Mode -- Microsoft has "opted out" of continuing support for direct execution of 16-bit (i.e. DOS) programs in 64-bit Windows.

In short, use DOSBox instead. Otherwise, switch to 32-bit examples, use -f win32 instead of -f bin to output an object file, and grab a linker such as GoLink to link that file into a full-fledged Windows executable.

[mihail]

thanks Keith! Downloaded DosBox, mounted my drive but when running the com either dos box is gone or the cursor flickers for ever with nothing showing up.
 mov si, msg

print:
lodsb
cmp al, 0
je halt

mov ah, 0Eh
int 10h
jmp print

halt:
hlt

msg db "Hello, world!", 0

times 510-($-$$) nop
dw 0AA55h
My hello.asm file as above.

[Frank Kotler]

If your Windows version claims it won't run a .com file, it probably won't. Your options are to install an emulator - "dosbox" is popular:

http://www.dosbox.com/wiki/Releases

That should allow you to run your example, and all the other examples of .com files you'll find scattered around. This is about the only reason to try to run .com files - lots of examples!

The other option is to find source code suitable for a "first program" for Windows - either 32-bit or 64-bit "should" work on your system. 32-bit examples should be easier to find, but you might want to "bite the bullet" and learn Windows 64-bit programming, since that's probably where you'll end up eventually.

It's a tradeoff. There's very little point in "learning dos" these days. It's obsolete. But it offers a fairly gentle introduction to assembly language. 32-bit Windows is (IMO) a little harder to learn - that is, harder to understand what you're actually doing. There should be examples easily found... although I can't come up with any at the moment(!)... 32-bit Windows is going to be similarly "obsolete" some day, I suppose. 64-bit would be the most "modern" system to learn, but tutorials and examples are harder to find, and are apt to assume that you already know assembly language...

Okay, here's a 32-bit Windows example:

http://forum.nasm.us/index.php?topic=762.msg2396;topicseen#msg2396

This claims to offer a "gentle introduction" to 64-bit assembly:

http://www.x86-64.org/documentation.html

(... although it assumes that you know 32-bit Gas well...)

Here's another tutorial for 64-bit, with some example code:

http://www.vikaskumar.org/amd64/index.htm

(... although the examples are for Linux - uses Yasm, not Nasm, but those should be "just the same")

I think if I were you, I'd install "dosbox" and see how it goes from there!

...
[Edit] well, I see you tried that. Your code isn't quite right for a dos .com file... Try:

Code: [Select]

org 100h ; where dos will load us

mov dx, msg
mov ah, 9
int 21h

ret

msg db "hello world$"

Best,
Frank

[MJaoune]

It's a tradeoff. There's very little point in "learning dos" these days.

Well it is good for creating Operating Systems, isn't it? But creating an OS is for advanced programmers not for someone that creates a normal Win32 GUI or similar.

Best ,
Mahmoud

[Keith Kanios]

It's a tradeoff. There's very little point in "learning dos" these days.

Well it is good for creating Operating Systems, isn't it?

It is subtle, but notable, that 16-bit Real Mode, the BIOS and DOS are three different systems/concepts.

16-bit Real Mode and the [PC] BIOS would be relevant to OS development, mostly for bootstrapping, basic memory detection, etc.

However, DOS almost has an irrelevant or negative value with respect to OS development, as it teaches you obsolete concepts that you must then unlearn... unless, of course, you are specifically developing a DOS-like clone, or you wish to exercise discipline with respect to memory management techniques.

DOS would also be an OK base system to build up confidence about various low-level constructs, in terms of debugging, but the concept of virtual machines, e.g. Bochs, has made that rather irrelevant as well. Anything as relatively simple as DOS, is easily handled by modern emulators which also have the added benefit of a more rapid development/test cycle.

[MJaoune]

It is subtle, but notable, that 16-bit Real Mode, the BIOS and DOS are three different systems/concepts.

16-bit Real Mode and the [PC] BIOS would be relevant to OS development, mostly for bootstrapping, basic memory detection, etc.

However, DOS almost has an irrelevant or negative value with respect to OS development, as it teaches you obsolete concepts that you must then unlearn... unless, of course, you are specifically developing a DOS-like clone, or you wish to exercise discipline with respect to memory management techniques.

DOS would also be an OK base system to build up confidence about various low-level constructs, in terms of debugging, but the concept of virtual machines, e.g. Bochs, has made that rather irrelevant as well. Anything as relatively simple as DOS, is easily handled by modern emulators which also have the added benefit of a more rapid development/test cycle.

I totally agree, the only thing that needs dos programming in creating OS, is to make DOS boot to the operating system and intialize the devices (they can be intialized in the OS also). Since the bios boots the DOS, then we only have to program the DOS not the bios.

[mihail]

Thanks Keith! I got it running with the DosBox, I worked with DOS although I never did assembly programming. One again, appreciate your help!! More questions to come!!

[Keith Kanios]

I totally agree, the only thing that needs dos programming in creating OS, is to make DOS boot to the operating system and intialize the devices (they can be intialized in the OS also). Since the bios boots the DOS, then we only have to program the DOS not the bios.

Again, dealing with DOS is one step too far... 16-bit Real Mode > BIOS > DOS.

There is no desirable reason to deal with actual DOS for booting, unless you are attempting something like loadlin, as it is an obsolete abstraction layer... where-as the BIOS has been relevant for decades.

I would also go as far to say that you explicitly DO NOT want DOS or any other non Firmware-related [operating] system to initialize any devices for you.

[Keith Kanios]

Thanks Keith! I got it running with the DosBox, I worked with DOS although I never did assembly programming. One again, appreciate your help!! More questions to come!!

Good to hear.