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!
QuoteWhen 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
QuoteI 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
mov eax,DGROUPit actually comes out like
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.
model small,farstack
.386Finally, have fun with the PCI stuff - it's...fun :bg
Quote
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
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.
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.
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 (http://webster.cs.ucr.edu/Page_TechDocs/MASMDoc/ProgrammersGuide/Chap_02.htm).
Quote from: guyenMasm on February 11, 2007, 10:03:06 PM
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
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
why till now htere is no answer?
it seems that i did some error ......please correct me
don't leave me alone :'(
> 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
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
sorry i forget
where can i find detailed explanation how to shift from real to protected mode and vesa versa
please help me
oooh :'(
No one want to help me??????? :'(
www.intel.com/products/processor/manuals/ (http://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.
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.
thanx
i am very happy for your reply :bg
you clarify for me the most important thing htat i am looking for
i know that the dos box runing in (v86)
and it use the api to perform it's function
but do you think that i can't shift from it to protected mode and then to real mode?
i read the section of shifting mode in the sys. progr. guide before
but i was think that this section can be applicated on dos box.
thanx for your help
is there any method to shift from mode to mode using debug.exe?????
Hi,
> but do you think that i can't shift from it to protected mode and then to real mode?
Not in a windows DOS box. That's because to switch to real-mode your code must run in protected-mode ring 0, which is not accessible for applications in windows XP.
> is there any method to shift from mode to mode using debug.exe?
No, debugx.exe never changes modes by itself. It's deliberately kept as simple as possible.
Well, assuming DEBUG is running in real mode there actually is a method (of shifting to protected mode), but it would be so difficult and time consuming that it would not be worth doing IMO.
thanx again
i can use the command 'e' in debug to enter hexa code into the memory then i can use the command 'r' to run this code ; if this code is the code of shifting do you think that it will not work??
if so; that means the killing of my project!!!!
what i was think to do is :
when a programmer came to a computer without any tools( no compiler, no linker)
and he want to achieve some task,can he use the above method to do what he want
i mean calling tha api from debug.exe
this is all the story :8)
thanx for you
from now i will stop my research in this subject it seems impossibl :'(e