Optlink is on github
Walter Bright
newshound2 at digitalmars.com
Thu Mar 7 14:47:03 PST 2013
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.
More information about the Digitalmars-d
mailing list