DaWei

I was lucky. When the micro came along, nothing that is done with them now was being done. Someone had to come up with all that stuff, and there weren't enough of us to go around. Obviously, much of what we did was on the cutting edge. It was ALL cutting edge. We designed our own hardware. Common peripherals were new inventions. It was a blast. Ink-jet printers were in 6-foot racks and sprayed a stream that was peturbed by an electric field. It's easy to say (it couldn't actually be otherwise): I had a machine somewhere, of some kind, that touched the life of nearly any average U.S. citizen you cared to point at, whether they knew it or not.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

lectricpharaoh

First, the term 'DOS box', when applied to current Windows machines, is often inacurate. Usually, it is not a DOS box at all, but a Windows 'console program'. These are regular Win32 programs that happen to start with a console window attached, and usually do not open any 'normal' (ie GUI) windows. However, you can open a console from a Windows GUI program, and use the entire Win32 API from a console program.

If this is the case with your program, it will be executing in protected mode, as normal. If it actually is a DOS program, it will almost certainly be running in V86 mode (which is actually a subset of protected mode), whether you're running it under Windows or not. Even DOS memory managers like EMM386 would run the CPU in V86 mode, and if you're using DPMI or a similar technology, you'll be running in V86 mode as well.

Lastly, even if you're not running in protected or V86 mode, you can still assemble (and usually execute) 32-bit instructions. All that happens is a prefix byte is generated to switch from 16-bit mode to 32-bit mode for the current instruction. In fact, if you look at the opcodes for most 16-bit instructions that have a 32-bit counterpart, they are the same; the CPU uses the current CPU mode and the presence/absence of override bytes to determine the 'size' of the instruction. Actually, two override bytes can be generated for any given instruction- one to override the operand size, as when using a 32-bit register, and another to override the address size, as when accessing a 32-bit segment. In fact, this latter allowed the 'flat mode' DOS trick used by certain programs, where the CPU was switched to p-mode, the segment limits on some/all of DS, ES, FS, and GS were set to greater than 64k, and then the CPU was switched back to real mode. The CPU would not load segment limits in real mode when segment registers were changed, allowing you to use address-size override bytes to access the whole of memory in real mode. Needless to say, this sort of hack was frowned upon for most real-world code, and impossible under p-mode, anyways, but it was used nonetheless.

The point of all this is you can't tell what mode you're in simply by what instructions are generated. Most, if not all, modern operating systems will be running so-called real mode programs in V86 mode, since switching between V86 and p-mode is (I believe) faster than between real mode and p-mode, as well as because V86 allows for things such as paging and privilege levels that simply are not supported under real mode.

__________________
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

ASMvsC++

Sorry everyone for my mistakes ,dont argue any more plz

Thx electric Pharaoh and everyone

electricParaoh ! I have some more question plzz
1)So a program contains all 32 bit opcode can run in realmode not only P mode??
Coz 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 dun 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 ??
---------------------------------
3) I wrote some code in NASM like this

when I complied : nasm -f obj ex1.asm -o ex1.exe
and no erro warning
but when I excuted it ,it halt the system
I tried to look for some code in Nasm and compile it and run

but cause error ,it sutdown DOs Console and show the error message in the message box of windows ,said that instruction error and give some address of memory
so let me ask you why??
and can u write me a simple example in nasm ?,coz NASM document I read have no "full example" except some code snippet ,I try to find some more on net but I just found some thing like the code I showed above
-------------------------------------------
4) I read some document about DPMI 1.0
and it said to enter p.mode we call 2FH func and int 1687h
and the return value in ES and DI
and it said ES contains realmode segment of DMPI host data
and it give a snippet code to enter p mode


I try to search and find me some understanding about this but...
I wanna ask :
- Why do this code allocate memory for DMPI private data?? It just allocate some memory and that's it ,no effect??? see???

- when it make a call to enter p mode : call modesw
why we must call this ??
Does it setup some segment descriptor or selector ,or some thing like that

- when we in protect mode by calling call modesw ,what is in TR ( task resgister) , a selector to TSS ???

Thx

tempest

I'll help you when your post is formatted in a way that shows atleast an attempt to now say: Thanks and not "Thx"; Please and not "plzz"; You and not "u"... and also we read the first question mark there is no need for three...

__________________

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 ?
---------------------------------
3) I wrote some code in NASM like this

when I complied : nasm -f obj ex1.asm -o ex1.exe
and no erro warning
but when I excuted it ,it halt the system
I tried to look for some code in Nasm and compile it and run

but cause error ,it sutdown DOs Console and show the error message in the message box of windows ,said that instruction error and give some address of memory
so let me ask you why?
and can you write me a simple example in nasm ?,since NASM document I read have no "full example" except some code snippet ,I try to find some more on net but I just found some thing like the code I showed above
-------------------------------------------
4) I read some document about DPMI 1.0
and it said to enter p.mode we call 2FH func and int 1687h
and the return value in ES and DI
and it said ES contains realmode segment of DMPI host data
and it give a snippet code to enter p.mode


I try to search and find me some understanding about this but...
I wanna ask :
- Why do this code allocate memory for DMPI private data? It just allocate some memory and that's it ,no effect? see?

- when it make a call to enter p mode : call modesw
why we must call this ?
Does it setup some segment descriptor or selector ,or some thing like that

- when we in protect mode by calling call modesw ,what is in TR ( task resgister) , a selector to TSS ?

Thanks

Ok I edited !if it still has something that make you unpleasant but you still understand please pass it

Mjordan2nd

Sorry, I was a bit late ro read. Deleted upon request.

__________________
"Every gun that is made, every warship launched, every rocket signifies, in the final sense, a theft from those who hunger and are not fed, from those who are cold and are not clothed. The world in arms is not spending money alone. It is spending the sweat of its laborers, the genius of its scientists, the hopes of its children." - Dwight D. Eisenhower

ASMvsC++

Where's electricpharaoh ?

DaWei

I think he has a life. Probably didn't realize he's on call .

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

lectricpharaoh

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