November 5, 2026
MOD_EMUP - analysis
The purpose of this essay is to examine the idea of writing my
own program to aid the analysis of DOS executables.
Language and gui framework
It would be nice for this to be portable, and to run on Apple silicon.
For several reasons, C is the most likely language.
I want to use some large blocks of existing open source code.
One is the disassembler in Nasm.
There may be a better disassembler than Nasm.
The other is an x86 emulator, as used by dosbox-X.
This code needs to be examined to ensure that it is C and not C++.
(Apparently dosbox-X is C++ code).
The other consideration is the GUI toolkit.
I want to avoid coding in C++, though perhaps it would
be possible to mix C and C++ code in some civilized way
for the sole purpose of writing an access layer in C++.
See the end of this page where I examine this in more detail.
Functionality
I want to turn a disassembled listing into a hyperlink activated
viewer like binary ninja. It should be possible to click on any
address and just go there, or see what is defined there.
A simple translation of subroutine calls would be a beneficial
start to writing a decompiler. If a decompiler became a goal,
it could decompile to some kind of "meta-language" that would
sort of be C-like.
A table of address to name translations should be possible for
both code and data references. This should be "off to the side".
Any such embellishment by names should be table driven, the key
idea being that there is always freedom to change this program
and the way it renders things without having to abandon any
annotation or naming.
Output
Currently I use vim and edit/annotate a disassembly listing.
This annotated listing is my "final product".
I could use this proposed program alongside of vim,
but it would be much nicer to work entirely within
this new program. This would require the ability to
add "comments" as both blocks and on single lines.
These would need to be stored "off to the side" as
already mentioned.
Emulation
It would be a great help to be able to single step the code and
have a register display. It should be possible to load registers
and then single step (or run to a breakpoint). This is where
leveraging existing code, probably from dosbox-X would be of
great value.
Ghidra
Before going down this road too far, it would be worth looking at Ghidra.
I tend to view Ghidra as a huge sluggish Java monster, but I could be wrong.
Toolkits
It is indeed possible to call C++ code from C.
There are existing methodologies for doing so, involving
the "extern C" linkage specification in the C++ code.
Given this, I can develop my own glue layer and write
my code in C. (This also pertains to the emulator in dosbox-X).
Note that it may be beneficial to organize the program in such
a way that different GUI toolkits could be used without a
massive tangle of code to deal with.
Some options:
- Qt -- C++
- wxWidgets -- C++
- GTK -- C
I have essentially no concern about portability to Windows, though
most choices would make that possible. Getting GTK to work on Mac
involves some extra hassles, but it is the recommended option if I
want to code in C.
I was curious what binary ninja uses, and when I went looking for the
executable in my linux install, I found that it comes bundled with
a bunch of libQt6 libraries, such as:
libQt6Widgets.so.6
Binary Ninja for Apple Silicon is available (version 6.0) and I should
download and try the free version. And see if it continues to use Qt
on the Mac. I'll note that their cloud version supports all binaries,
but only the PE file format. My files are the old MZ format, not PE,
but perhaps a converter exists -- but we are wandering far afield.
Have any comments? Questions?
Drop me a line!
Tom's Electronics pages / tom@mmto.org