32 bit addressing in DOS.

[guyenMasm]

OK, I have a project to produce file that does the PCI enumeration in DOS.
In my understanding, Mentor told me that the 32-bit general registers (EAX, EBX etc.) will be needed in real-mode.
I have a quite a bit of an experience in 16-bit programming but it got me confused.

When using the 32-bit register addressing w/o going to Protected mode, should I still use the link16.exe (Iczelion link563)???
My guess is yes, because my code involving the 32-bit register still compiles with .386 directive and compiling with link.exe (the one that comes with MASM32 installation) throws out the error:
"seg ref in fixup record." -> error converting to COFF format"

I also wonder what kind of debugger could be used for this (32bit addressing in real mode.) The most promising one I have with me is GRDB.exe similar to debug.exe from windows, except it shows the content of extended registers.

I have ollydbg but this doesn't seem to correctly disassembly exec-s linked by link16.exe. Does it mean ollydbg is for win32? Correct me if it is wrong.

However, when using GRDB debugger I noticed that for every statement involving extended register (i.e. mov eax, DATA) , there is
an instruction mov [bx+si], al which following that statement. Can someone explain me about it?

Is there any other good debugger that can correctly disassemble the  instruction using 32-bit reg-s in real mode? Thanks!

[sinsi]

When using the 32-bit register addressing w/o going to Protected mode, should I still use the link16.exe (Iczelion link563)???

Yes - the linker doesn't care what code/data is in the .OBJ but later linkers can't create a DOS .EXE

I also wonder what kind of debugger could be used for this (32bit addressing in real mode.)

With DOS/Windows DEBUG.EXE, you can still use T (trace) but can't use R to look at 32-bit registers.
I have a copy of DR-DOS's DEBUG.EXE from 10 years ago but I'm not sure if I can post it here...
      DEBUG R1.40    Program debugger
      Copyright (c) 1985,1996 caldera, Inc.  All rights reserved.

I've never seen the GRDB debugger, but with the normal DEBUG.EXE, if you have code like

Code Select Expand

    mov eax,DGROUP
it actually comes out like

Code Select Expand

    DB 66h            ;this tells the (real mode) CPU that a 32-bit destination is next
    mov ax,DGROUP
    DW some_number    ;this is usually 00 00 which disassembles to "add [bx+si],al"

One important thing to remember when using 32-bit code in 16-bit land is to put the .386 after the model e.g.

Code Select Expand

model small,farstack
.386

Finally, have fun with the PCI stuff - it's...fun :bg

[japheth]

With DOS/Windows DEBUG.EXE, you can still use T (trace) but can't use R to look at 32-bit registers.
I have a copy of DR-DOS's DEBUG.EXE from 10 years ago but I'm not sure if I can post it here...
      DEBUG R1.40    Program debugger
      Copyright (c) 1985,1996 caldera, Inc.  All rights reserved.

try this:

http://www.japheth.de/Download/debug103.zip

[MichaelW]

guyenMasm,

Using 32-bit registers in a 16-bit real-mode program is no problem. The "16-bit" term refers to 16-bit addressing, meaning primarily that offset addresses are 16-bit values. This is the norm for real-mode programs. Do you actually need 32-bit addressing?

Japheth,

Thank you for posting the debug103 package and for the improvements you have made to it. I have been using a binary from 1997 that was a little short on features, and I have never seen the source.

[guyenMasm]

thanks for all
I actually found the solution. Putting .386 and using USE16 in code segment solved the problem.
I had a guy telling me that as soon as i put .386 in my code meaning of USE16 and USE32 switches place.
In other words, putting .386 and use16 tells that the 32-bit addressing mode desired.
Oddly enough, it worked with GRDB!. Yeah
for every instruction involving 32-bit registers, i noticed that 66h was in front of it.
Alas, my employer will not let me use the simplified segment statements like .small .large etc.

[MichaelW]

The segment word size is determined by the position of a .386 or later processor directive relative to the model directive. See "Setting Segment Word Sizes (80386/486 Only)" here.

[BytePtr]

I have ollydbg but this doesn't seem to correctly disassembly exec-s linked by link16.exe. Does it mean ollydbg is for win32? Correct me if it is wrong.

Yes, OllyDbg is only for 32bit apps. For debugging use: Turbo Debugger or SoftICE for 16bit apps.
For just disassembling use: HIEW or W32Dasm

[anana]

this subject is very interesting for me ,because i have done some research about
method by which we can programming 32bit program using debug.exe( small program that
comes with windows) what i want to do is to load eax with the address of function that is found
in some windows dll then transfere the execution into this address , i dont know if it is possible
to do so with debug.exe or not
code that i want to execute is:
db 66h
db 67h
mov eax,0x00012345
jump eax


can you help me in my task

[anana]

why till now htere is no answer?
it seems that i did some error ......please correct me
don't leave me alone :'(

[japheth]

> why till now htere is no answer?

Because noone understands your question I presume.

Anyway, you cannot jump/call a proc in a windows.dll from debug.exe. Because

1. in debug.exe, "you" are in real-mode, and the dll code runs in protected-mode
2. the windows dll most likely is in a different address context

[anana]

thanks for your reply

i know that debug is working in real mode

but what your debug that is in previous reply which  can use protected mode registers

and what is the role of overriding prefix 66h &67h

thanks

[anana]

sorry i forget

where can i find detailed explanation how to shift from real to protected mode and vesa versa

please help me

[anana]

oooh :'(
No one want to help me??????? :'(

[Tedd]

www.intel.com/products/processor/manuals/

"Volume 3: System Programming Guide"

You should at least browse the whole thing and read most of the sections that look useful, otherwise you'll find your computer crashing very often with no indication why :bdg
Specifically, you'll want to look for "Mode Switching" which gives full details of switching to protected mode, and back to real-mode.

[japheth]

Hi,

I realized just now that you asked me a question about debug.com. Sorry for the delay:

> but what your debug that is in previous reply which  can use protected mode registers

yes, there is a version (DEBUGX) which can debug DPMI applications. But you still cannon call a windows dll from a DOS DPMI application. They both run in protected-mode, that's true, but in different address spaces.

> where can i find detailed explanation how to shift from real to protected mode and vesa versa

please be aware that code in a Windows DOS box does *not* run in real-mode, in runs in v86-mode. So all the huge text about mode switching found in the intel manuals most likely doesn't apply for your case/problem.