NASM compile into a executable file on windows such as ".com"

[Charell King]

NASM compile into a executable file on windows system such as ".com" and I run the file, appear a window box:
it reads "C:\WINDOWS/system32\cmd.exe-sum
            NTVDM CPU appear invalid instrutions
            CS:0000 IP:0077 OP:f0 37 05 0e 02 "
who can help me?

[MJaoune]

Make sure you have seperated the Segments in a right way, then check the registers. Just to know .com is a dos file.
NTVDM is the CPU's name when executing in the Process tab in the Task Manager

[Frank Kotler]

I think we may need more information, Charell. Such as: which Windows version? (some of 'em - 64-bit systems - won't run a .com file! ) And what did you do to create the .com file? (post the code, if it's not too long, and tell us what command-line you gave Nasm)

The "CS:0000" is a clue. Zero is an "invalid descriptor" in protected mode, and a "valid", but highly unlikely, value in real mode (including V86 mode). "Ecstatic" recently posted a similar problem, cause by trying to use int 80h (a "Linux thing") in Windows. I suspect that you got "CS:0000" by trying to use an interrupt which is not supported by your OS, too - but there may be other reasons for it...

Try this code:

Code: [Select]

org 100h

mov dx, msg
mov ah, 9
int 21h

ret

msg db "hello, world!$"

Assemble that with:

Code: [Select]

nasm -f bin -o myfile.com myfile.asm

(replacing "myfile" with whatever you named it, of course!) See if that works, or does the same thing, or what... I would "expect" a more useful error message if your OS won't run a .com file, but maybe not...

The most important thing in learning assembly language is "Don't give up!"

Best,
Frank

[MJaoune]

The most important thing in learning assembly language is "Don't give up!" Smiley

Yup I totally agree Frank, it is a Low-level language that is very deep to the hardware roots, it needs much intelligence and cleverness than any other programming language.

Charell King, if you need anything in assembly, you can ask anyone here, trust me they helped me climb the Assembly ladder.

Thanks Frank

Best,
Mahmoud

Edit: Inappropriate content removed by forum moderation.

[JoeCoder]

I don't think assembler/assembly is harder than other languages, it depends on the person. Some people like me like to think in many very small steps because it gives us the control to build things up they way we think they should be built. Some people like to work in specific problem domains (math, GUI, etc.) and don't want to deal with bits and bytes because that has nothing to do with their view of the solution. It's just personality and what problem you are trying to solve. One thing we can all agree, with assembler/assembly you really must know your OS and hardware closely to get anything done.

[MJaoune]

Well.. If you want to compare it to C or C++ for example:

The comparison is checking if something equals something then do something:

C++:

Code: [Select]

if ((s == 1)) return 0;
Assembly (Intel Syntax):

Code: [Select]

cmp eax,1
je Dosomething
Dosomething:
mov eax,0
push 0
popa
end
ret
Well it is not easier than other languages, it needs more work in my opinion.

Do you know other languages besides Assembly?

[Bryant Keller]

C++:

Code: [Select]

if ((s == 1)) return 0;
Assembly (Intel Syntax):

Code: [Select]

cmp eax,1
je Dosomething
Dosomething:
mov eax,0
push 0
popa
end
ret

Um, I think you got your program flow a bit mixed up there. Try this instead

Code: [Select]

cmp eax, 1
jne .end_if
   mov eax, 0
   leave
   ret
.end_if:

Well it is not easier than other languages, it needs more work in my opinion.

Do you know other languages besides Assembly?

I've been repeatedly quoted saying this by some of the people I've mentored (apparently it's one of my "catch phrases"), that aside I'm going to say it again.

Assembly is the simplest of all programming languages. It's that simplicity that people tend to find difficult.

Compared to complex languages like C/C++ which have thousands of functions, hundreds of syntactical elements (keywords, directives, and other tokens), and a very ridged "type" system, all of which the programmer must become familiar with to be proficient in the use of the language; Assembly language tends to have, at most, a few hundred opcodes and a handful of directives the user must become familiar with to accomplish any task. Yes, this statistic gets extended when you start adding in all the various features like FPU, SSE, XMM, etc but still not on the level of many high level languages. The part that makes most novices fearful of Assembly language IS the simplicity of the language. Because the language more or less forces you to implement your code 1 step at a time whereas in C/C++ you can use abstract expressions and let the compiler deal with optimizing concepts like algebraic simplification and the various memory layouts and calling conventions used by system API that you're using.

[Charell King]

Thank you. I think it may be caused by OS, I find a code which is programed with NASM on linux, but I think NASM is highly implanted on all kinds of OS, I compile it successfully into obj on windows xp with nasm, but I download a tool "alink", make it into "exe", then run it , it appears above problems. I am very grateful that many masters care about my problem, thanks. 

[Charell King]

I have a doubt that an interrupt instruction is only connected with cpu's sort (intel, amd, and so on). why is it connected with a os? who can explain it ?

[JoeCoder]

Well.. If you want to compare it to C or C++ for example:

First of all there are things that can be done in assembler/assembly that can't be done in any other language. The opposite is not true 

Do you know other languages besides Assembly?

Yes. I use assembler for my job but over the years I have learned and used many other languages, just not nearly as much as I have worked with assembler. Like I said if I had to do math or GUI for a living (OMG please NO!!!!) I wouldn't be using assembler, but for what I do, assembler is the best choice. Each language is a tool and some things are hard in some languages and easier in other languages. If one language was the easiest and had no other tradeoffs everybody would use that language and nothing else. All depends on your problem domain, your platform, your budget etc.

[JoeCoder]

I have a doubt that an interrupt instruction is only connected with cpu's sort (intel, amd, and so on). why is it connected with a os? who can explain it ?

I don't get your question 100% but hardware and software work together. The OS can't do anything the hardware doesn't support. So, most interrupt mechanisms are combinations of software and hardware working together to provide the desired result.

[Frank Kotler]

Well...! Thanks for the compliment, Mahmoud! I don't know any language but asm "well", but I can blunder along in C (I find it harder than asm). I agree with the folks who say that assembler is "simple". What makes it "hard" is that you need to know a lot of "simple" things all at once! This question is a good example of that (see how I got back on-topic? )...

The "int" instruction (not to be confused with C's "int"eger!) is inherent to the CPU. It is, in a way, similar to the "call" instruction - it goes off and executes some other routine, and then returns and continues from where it was. The "int" instruction finds the "other routine" to run from a "table" of addresses. Something else - BIOS or your OS - needs to provide the code for the routine, and put its address in this "table" (Interrupt Vector Table in real mode, Interrupt Descriptor Table in protected mode).

When the computer first boots, the CPU is in 16-bit real mode. A few BIOS interrupts are installed, but that's all. If we load dos, it provides several more routines, and puts their addresses in the "IVT" - mostly under int 21h, but there are others. If we load Linux, it provides some routines (different, but with similar purposes, mostly), and puts their addresses in the "IDT" (we've switched to protected mode now) - under int 80h. If we load Windows, there are interrupts installed, but for practical purposes we can't use 'em. Instead, we interact with the OS via the "call" instruction. Windows provides a very "rich" set of routines, compared to either int 21h or int 80h. (Whether this makes it harder or easier to use is a matter of opinion, I guess!)

Both the BIOS interrupts and int 21h (and other dos interrupts) are 16-bit code, and won't work once we've switched to 32-bit protected mode. Windows - older versions - provide a workaround for this, in the form of "virtual x86 mode". Essentially, it provides a "fake 16-bit machine" for our use, so dos programs can still be run. But in "long mode" (64-bit), V86 mode is no longer available, so dos code won't work except in an emulator - "dosbox", for example.

I think Windows XP will run a .com file (or a 16-bit .exe) okay, but no addresses have been put in the table for int 80h, so that isn't going to work. We could, I suppose, install some code at int 80h, but it would probably be much easier to use int 21h or a Windows API to do roughly the same thing. What subfunction of int 80h were you trying to use?

Best,
Frank

[MJaoune]

Well...! Thanks for the compliment, Mahmoud!

Well, it is also a truth, don't you remember all the topics I posted that you solved for me?

Compared to complex languages like C/C++ which have thousands of functions, hundreds of syntactical elements (keywords, directives, and other tokens)

Well if they measure difficulty of programming language by functions, then yes ASM is not harder. But I meant that ASM needs much more computer knowledge to be learned, C++ can be learned by anyone, even normal people that work with database.

I don't know any language but asm "well"

But you have MASTERED IT!!! Mastering a single language is better than knowing the basics of all languages.

Best,
Mahmoud

[Frank Kotler]

I appreciate your confidence, Mahmoud, but that's incorrect. I'm an "experienced beginner" (getting to be quite a lot of experience), but I have by no means "mastered" assembly language! I barely know how to use the FPU, and xmm/mmx/sse is a complete mystery to me! There's a whole lot of it to learn!

And, FWIW, I don't "get" C++ at all. To be sure, I haven't really studied it. I have some C++ code - using the "XCB" library code (an alternative to Xlib, for Linux) - which I was trying to help a guy figure out. The disassembled code appears to "push" (it doesn't really "push" - gcc has used "mov [esp + ???], ???" instead) a parameter that doesn't show in the source code. When the library function returns, the secret parameter has apparently been removed with a "ret 4", despite the rest of it being "caller cleans up stack". Some, but not all, of the library routines do this. One of these days, I'll run it by you "C++ gurus" and see if you can help me figure out what's going on. But not in this thread...

We want to get Charell set up with some kind of file that'll run on Windows xp. Maybe a .com file, maybe an .exe - either for dos or Windows - and some kind of "path forward" from there. We get few enough people trying to learn assembly language - we don't want anyone getting discouraged! Any progress on that?

Best,
Frank

[Keith Kanios]

And, FWIW, I don't "get" C++ at all.

Don't feel bad, most C++ programmers don't either.

I recommend looking at the D Programming Language for an example of a high-level and object oriented language that didn't suffer from design-by-corporate/industry-committee syndrome. Point-in-case, data type sizes are clearly defined in D, unlike C/C++ where they can be potentially ambiguous.