On 3/7/2013 2:25 PM, Daniel Murphy wrote:
That's not what I meant. I mean that when trying to work out what the
assembly does, having real stack frames and a consistent calling convention
could be more useful than knowing the label names and having out of date
comments.
I've done some disassembly of real programs. It is a LOT harder than dealing
with Optlink. Really, it's terribly difficult. Having the symbolic names, a
logical organization, and even out of date comments, are a huge help.
I don't expect res and def support are anywhere near that complicated. Same
goes for most of the command line switches. (I have read through the list,
but it's possible I'm being overconfident here)
The major problem is the lack of a test suite for those things.
However, Optlink does bring considerable value to any linker replacement
project, in that embedded in it is an enormous amount of lore about all
those twinkie little things that matter, and how things really need to
work.
Optlink also has a lot of support for dead file formats/memory models and an
insanely convoluted code base. Like you said, porting to C doesn't escape
this.
In my work converting Optlink to C, I dropped support for the false compile time
conditionals. There's no rationale for building a real mode optlink executable.
There's also no reason to support building OS/2 executables anymore, etc.
