How to disassemble an EXE file?

[Binarus]

Hi all,

I'd like to know how to disassemble an EXE file using the OpenWatcom tools.

Background:

I am working on a big DOS 16-bit project (C, C++ and ASM mixed), and from time to time, I'd like to check the assembly code which has been generated. Notably, I am interested in seeing the right (final) values of segments and offsets when looking at the code which the compiler produces from my inline assembly.

I know that I can disassemble the object files, but that wouldn't help since I can't see the final addresses then. For that, I would have to disassemble the final executable. Currently, I am regularly transferring the executable from my Windows development box to the target system and then use the debugger under DOS to see what I want. But that is very time consuming and uncomfortable.

I did not find any way to use the OpenWatcom debuggers from within my development system. The debuggers always threw error messages which said something like that it couldn't use the whole screen, and then it was terminated.

So, I am looking for a way for disassembling or debugging the executable (not the object files) on my development box. Is this possible?

Thank you very much,

Binarus

[Frank Beythien]

Post by Binarus
Hi all,
I'd like to know how to disassemble an EXE file using the OpenWatcom tools.
I am working on a big DOS 16-bit project (C, C++ and ASM mixed), and
from time to time, I'd like to check the assembly code which has been
generated. Notably, I am interested in seeing the right (final) values
of segments and offsets when looking at the code which the compiler
produces from my inline assembly.
I know that I can disassemble the object files, but that wouldn't help
since I can't see the final addresses then. For that, I would have to
disassemble the final executable. Currently, I am regularly transferring
the executable from my Windows development box to the target system and
then use the debugger under DOS to see what I want. But that is very
time consuming and uncomfortable.
I did not find any way to use the OpenWatcom debuggers from within my
development system. The debuggers always threw error messages which said
something like that it couldn't use the whole screen, and then it was
terminated.
So, I am looking for a way for disassembling or debugging the executable
(not the object files) on my development box. Is this possible?
Thank you very much,
Binarus

Perhaps WDUMP does part of what you want.
Did you look into remote debugging?

CU
Frank

[Marty Stanquist]

Also, check the linkmap file (*.map) in your debug directory. This has the
group and segment information.

Marty

[Johann Klammer]

Post by Marty Stanquist
Also, check the linkmap file (*.map) in your debug directory. This has
the group and segment information.
Marty

The problem there, is that the segments are still symbolic, and the
loader will relocate stuff...
Had tried to find out load addresses myself recently, to verify if I
could massage the compiler into generating (more or less) position
independent code for mixed real/protected mode interrupt handling...
I ended up dumping the 16 bit code from inside the executable using
printf() et al.

[Binarus]

The problem there, is that the segments are still symbolic, and the loader will relocate stuff...
Had tried to find out load addresses myself recently, to verify if I could massage the compiler into generating (more or less) position independent code for mixed real/protected mode interrupt handling...
I ended up dumping the 16 bit code from inside the executable using printf() et al.

Johann, thanks for the input.

Yes, the loader relocates, but on the other hand, the segments and offsets of every identifier in the EXE must be unambiguous in the first place. I don't need to know the absolute addresses (as you seem to need), but I'd like to see assembly code which is self-contained and complete. I'm not interested in what the loader does.

At least I can see what I want if I use the debugger, but this is a pain in my case ...

Regards,

Binarus

[Binarus]

Also, check the linkmap file (*.map) in your debug directory. This has the group and segment information.
Marty

Marty, thanks for the hint. But that would not help me either since I would like to read assembler code from the final executable with segments and offsets fixed-up.

Regards,

Binarus

[Binarus]

Post by Frank Beythien

Post by Binarus
I'd like to know how to disassemble an EXE file using the OpenWatcom tools.

Perhaps WDUMP does part of what you want.
Did you look into remote debugging?

Frank, thank you very much for your suggestions.

While WDUMP did not serve my purposes (I'd like to see the complete assembly code with correct (fixed-up) addresses), I didn't think about remote debugging yet.

The problem is that the target system is some distance away from the place where development happens, so I would have to find a method for transferring the EXE file from the development system to the target system and the starting the debugger on the target system. Since the target runs under DOS, that might be difficult or even impossible since DOS doesn't provide something like SSH or telnet service.

Nevertheless, the suggestion is interesting. I'll put some hours into trying to find a way to remotely execute commands under DOS and to transfer files via TCP/IP to the DOS target system.

Regards,

Binarus

[Frank Beythien]

Post by Binarus

Post by Frank Beythien

Post by Binarus
I'd like to know how to disassemble an EXE file using the OpenWatcom tools.

Perhaps WDUMP does part of what you want.
Did you look into remote debugging?

Frank, thank you very much for your suggestions.
While WDUMP did not serve my purposes (I'd like to see the complete
assembly code with correct (fixed-up) addresses), I didn't think about
remote debugging yet.
The problem is that the target system is some distance away from the
place where development happens, so I would have to find a method for
transferring the EXE file from the development system to the target
system and the starting the debugger on the target system. Since the
target runs under DOS, that might be difficult or even impossible since
DOS doesn't provide something like SSH or telnet service.

For remote debugging, the debugger runs locally (development system).
Only a small part is needed on the target.

Post by Binarus
Nevertheless, the suggestion is interesting. I'll put some hours into
trying to find a way to remotely execute commands under DOS and to
transfer files via TCP/IP to the DOS target system.

If you have a TCP/IP connection, wd.exe can transfer your .exe to the
target via the /download option.
See wd.hlp remote debugging.

CU
Frank

[Binarus]

Post by Frank Beythien

Post by Binarus

Post by Frank Beythien

Post by Binarus
I'd like to know how to disassemble an EXE file using the OpenWatcom tools.

Perhaps WDUMP does part of what you want.
Did you look into remote debugging?

Frank, thank you very much for your suggestions.
While WDUMP did not serve my purposes (I'd like to see the complete
assembly code with correct (fixed-up) addresses), I didn't think about
remote debugging yet.
The problem is that the target system is some distance away from the
place where development happens, so I would have to find a method for
transferring the EXE file from the development system to the target
system and the starting the debugger on the target system. Since the
target runs under DOS, that might be difficult or even impossible since
DOS doesn't provide something like SSH or telnet service.

For remote debugging, the debugger runs locally (development system).
Only a small part is needed on the target.

Post by Binarus
Nevertheless, the suggestion is interesting. I'll put some hours into
trying to find a way to remotely execute commands under DOS and to
transfer files via TCP/IP to the DOS target system.

If you have a TCP/IP connection, wd.exe can transfer your .exe to the
target via the /download option.
See wd.hlp remote debugging.
CU
Frank

Frank, thank you very much again.

If I got you right, I would start a small debug server on the target system and let it run all the time. Then I could download new software to the target system and start it there with the help of the debug server. Is this right?

Probably it would be difficult to make the debug server run with the kind of network we have on the DOS box. We have set up the Microsoft SMB client over TCP/IP there, meaning that there is no standardized packet driver. Until now, I have used it to download new revisions of the software from my development box (the target system was acting as a client).

In the meanwhile, I have tried Wilton's suggestion, and that's it! Exactly what I needed - it even works with the windows version of the debugger. But for sure I will keep your suggestions in mind; they are very interesting and helpful, and I think I will use them for other cases (currently developing more than one DOS project ...).

Regards,

Peter

[Frank Beythien]

Am 15.03.2013 12:19, schrieb Binarus:

[...]

Post by Binarus
Frank, thank you very much again.
If I got you right, I would start a small debug server on the target
system and let it run all the time. Then I could download new software
to the target system and start it there with the help of the debug
server. Is this right?

Read the chapter on remote debugging in the debugger guide.
You'll find how to use parallel, serial, TCP/IP, (pipes not for DOS,
IIRC) connections between development and target system.
And how to start the existing debug server on the target.

CU
Frank

[Wilton Helm]

You can use the VDM to run the code in a Dos Box under Windows. Not knowing
what all it does, it is quite possible it won't run, but it should load and
you can then look at assembly listing in the debugger. The fixups will be
different, but you can see whether it is being done as you expected. I've
done this with x86 code that was intended for a dedicated hardware
environment (that didn't even have an OS). Sometimes I will compile one
module or a few functions for DOS, with appropriate wrappers, stubs, etc.
and actually run them in a Dos box, with or without the debugger. Then take
the knowledge gained back to the original embedded code.

Wilton

[Binarus]

Post by Wilton Helm
You can use the VDM to run the code in a Dos Box under Windows. Not knowing
what all it does, it is quite possible it won't run, but it should load and
you can then look at assembly listing in the debugger. The fixups will be
different, but you can see whether it is being done as you expected. I've
done this with x86 code that was intended for a dedicated hardware
environment (that didn't even have an OS). Sometimes I will compile one
module or a few functions for DOS, with appropriate wrappers, stubs, etc.
and actually run them in a Dos box, with or without the debugger. Then take
the knowledge gained back to the original embedded code.
Wilton

Wilton, thank you VERY much for this hint! I am completely excited about it. I didn't hear anything about VDM yet, but it only took me a few minutes to locate it in the OpenWatcom directory structure and to load my software and view correct segments and offsets. Finally! That's a BIG time saver for me.

Two remarks, though:

1) I have to make sure that I actually don't run my software. It does a lot of hardware related things, and my development system crashes if I accidentally run it from within the debugger and can only be revived by switching off and on. But that is not a problem since I don't need to run the software; I just need to jump to certain functions and see the assembly code wit segments and offsets.

2) Is there any chance to see the opcodes in the assembly windows? I am very happy with what I could achieve thanks to your tip, but sometimes seeing the opcode would be the icing on the cake.

Regards,

Binarus

[Uwe Schmelich]

[--snip--]

Post by Binarus
2) Is there any chance to see the opcodes in the assembly windows? I am
very happy with what I could achieve thanks to your tip, but sometimes
seeing the opcode would be the icing on the cake.
Regards,
Binarus

I'm afraid that the 'solution' here, besides modifying the wd-sources is to
double-click on the address to get a memory window with the opcode-bytes.

[Kevin Rhoads]

Post by Binarus
1) I have to make sure that I actually don't run my software.

Microsoft VPC is "free" (i.e., no $ cost).

VPC will boot FreeDOS, RxDOS, OpenDOS (i.e., DRDOS 7.x) as well as
MS-DOS and IBM PC-DOS.

And, although it claims no support, it will mount 360k disk images and
boot from them as well as 720k, 1200k and 1440k disk images -- I have
gotten DOS 2.0 disk images to boot in VPC.

You can do a lot of DOS stuff that either won't work or is dangerous in
a virtual machine.

HTH
Kevin

[Binarus]

Post by Kevin Rhoads

Post by Binarus
1) I have to make sure that I actually don't run my software.

Microsoft VPC is "free" (i.e., no $ cost).
You can do a lot of DOS stuff that either won't work or is dangerous in
a virtual machine.

Kevin, thank you very much for caring about the problem. I'll remember what you wrote when I need to run other software on my development box.

For the software in question, running it in a VM would be impossible with any of the current virtual machines, including VirtualPC, because it is a realtime application, and it does a lot of dirty things like putting the processor in "unreal" mode, using 3 GB of RAM without an extender, using 32-bit registers and 32-bit transfers to the RAM, directly manipulating the chipset of the target system (ICH4) which differs from that of the development box, disabling most interrupts and installing own interrupt handlers for the remaining ones, manipulating APICs and MSRs, and controlling custom PCI hardware (4 Atmel AVR processors, an FPGA, and 16 axes, each with two position measurement systems, power regulation, DIO and so on).

Best regards,

Binarus

[Thorsten Schott]

Hi, Binarus!

Did you ever heared about a tool with the name "Ida Pro"!?

www.hex-rays.com/products/ida/index.shtml

There is one version for free! But the full product is much more
powerful and has support for more different file-formats than the free
version.

It's a very powerful tool!

Even the "CCC Hamburg" (Chaos Computer Club) is using it and they could,
for example, find and identify the "Bundes Trojaner" with help of it! ;-)

Thorsten