Thread: hpl me plzzzz
View Single Post
Old Nov 13th, 2005, 2:37 PM   #39
lectricpharaoh
Caffeinated Neural Net
 
lectricpharaoh's Avatar
 
Join Date: Jun 2005
Location: Dry west coast of Canada
Posts: 1,049
Rep Power: 5 lectricpharaoh will become famous soon enough
Quote:
Originally Posted by ASMvsC++
Sorry everyone for my mistakes ,dont argue any more please

Thanks electric Pharaoh and everyone

electricParaoh ! I have some more question please
1)So a program contains all 32 bit opcode can run in realmode not only P mode?
Because I think 32 bit opcode just can run in Pmode not real mode
---------------------------------
2) Some compiler like GCC (some kinda DGJPP -or somethin like that) ,It compiler a program to 32 bit code and run in protected mode by some funtion in souce program like enter_protetcdmode32() ...or go_32dmpi_.... something like that I dont remeber exactly.
Like Pharaoh said "If this is the case with your program, it will be executing in protected mode"
So why some compiler like that provide some func to enter pmode while it already in pmode when it excute wherther I used some func "enterpmode... or enter 32 dmpi " or not ?
That is because DJGPP uses DPMI (DOS Protected-Mode Interface). This is a way of making 32-bit DOS executables. To manage this, you need two things. First is a DPMI host. If you're running pure DOS (ie, not inside a Windows 'DOS box'), you will need a program to do this, such as DOS4GW or PMODE/W. If you're running a DOS box under Windows, then you'll already have a DPMI host available. The second thing you need is a program written to use the DPMI interface; this is your actual application, often referred to as a 'DPMI client'.

When you have a DPMI application, it starts out in real mode (note that although I say 'real mode', most environments actually use V86 mode, but it doesn't really matter). After it starts, it swtiches to protected mode, provided a DPMI host is available. Once this switch is done, your program runs mostly in protected mode, but for certain tasks (like opening, closing, reading from, and writing to files), it needs to call DOS. Since DOS runs in real mode, this requires a mode switch to real mode, making the DOS call, and then switching back to pmode. In some cases, you'll need to make this switch more than once. For example, imagine you set up a 4-megabyte buffer, and want to fill it with data from a file. In your C/C++ code, you make a simple function call, passing it the address of the buffer, and a FILE pointer or other file handle thingy. What goes on underneath is more complicated: for each 64k chunk of the file, your program needs to set up the real mode registers, set up a memory buffer in the first megabyte of memory, call the DPMI host to do the mode switch, make the DOS call, switch back to pmode, and then copy from the real-mode buffer to your actual buffer.

It's been a while since I've done any ASM coding. However, 'move' isn't a valid mnemonic, and I'm pretty sure you're assembling it wrong. You're specifying .OBJ format output, but naming it as an executable. That's akin to me renaming FILE.DOC to FILE.EXE and trying to run it. It's just not going to work.

Remember that there are three 'stages' of code: source, object, and executable. NASM usually generates object code as output, not executable code. The only exception is when generating raw binary code, and if you do this, your program will not contain any 'relocation information' (see below). This means that all memory references are fixed, and also implies that your program must exist entirely within a single (usually 64k) segment. DOS .COM programs behave this way, but DOS .EXE programs do not. Some .SYS or .BIN files might also be plain binary images, but don't count on it.

A bit more on relocation: when a program is compiled or assembled from source to object code, most memory references contain 'fixup information'. This is used by the linker to combine segments from various object modules (including libraries you link in at build time). Several logical segments may, and often do, become one physical segment in the final executable. To do this, the linker needs to adjust the interim addresses of code and data to arrive at the final addresses; it then uses these to generate the final executable file. This is a very simplified description, but hopefully you get the idea.

As to the actual code, like I said, it's been a while. I would suggest you get a book on DOS programming; you can probably find one at your local library, even if they have an outdated computer section (seeing as how DOS is not exactly bleeding edge). Another thing to look for is Ralf Brown's Interrupt List. This will detail all those interrupt functions, like DOS and BIOS calls and a bunch of other stuff. Most of the DOS stuff is INT 21H, and most of the BIOS stuff is INT 10H (if I remember right).

Once you've done that, you should try a simple .COM file. I won't tell you what to write, but there are some things you need to do. From memory, you will need to do the following:

Use the ORG directive to set the origin to 100H (256 decimal). This is because .COM programs use the first 256 bytes of the program's address space to store the 'program segment prefix'. Don't worry about what this is for now, just remember you need to do it.

Set the stack pointer. Typically you will do this by reserving a number of bytes after all your code and data, and setting the stack to the end of this block (you can use a label for this). Be sure you allocate enough; in a 'hello world' program, it doesn't really matter, but in a program that actually does stuff, be sure you won't overflow your stack space. You could even set SP to the end of the segment; this would give you lots of space.

Set the entry point; I think you use the ..start directive for this.

Terminate your program correctly. I believe it's INT 21H, AH = 4CH, AL = error level (make this zero for successful completion).
__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick
lectricpharaoh is offline   Reply With Quote