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?
![Smiley :)](http://forum.nasm.us/Smileys/default/smiley.gif)
)...
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