Optlink is on github

[Daniel Murphy]

"Walter Bright" <newshound2 at digitalmars.com> wrote in message 
news:khb5d7$1cfd$1 at digitalmars.com...
> 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've never worked on assembly that didn't use standard calling conventions, 
so I don't know how difficult it is.

>
>> 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.
>

Makes sense.  I have no idea how big the dmd/dmc/msc subset that would need 
to be supported is.

>
>>> 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.
>

Good, but does the code still increase the difficulty in porting?

And even once it's in C, optlink will probably never be more than a 
win32/omf linker.