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