"Walter Bright" <[email protected]> wrote in message news:[email protected]... > 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.
