It seems to me that the MinGW tools are pretty much the best and only hope if you are going to abandon OMF and OptLink.

Implementing new object/link tools for existing formats from scratch is far too much work.  You can also forget about creating a whole new object format from scratch.  If you're going to replace OptLink it needs to be with something that exists and is standard.

But there's not a whole lot out there in terms of free code for object file and library manipulation.  There's OpenWatcom, which also suffers from being OMF-based, and apparently has more bugs than D's current tools, and then there's MinGW, which works with MS PE-COFF.

Personally, I don't see why on Windows you'd want to use anything other than Microsoft's format.  Especially now that you can get their latest C++ compiler for free.  Intel's super-optimized compiler is also compatible with this format.  Probably others are as well.

Other than the GPL license, it seems like the MinGW tools have everything one could hope for.  Is the license the only real problem?

Also -- one thing that I'm not sure about:  Would there be any difference between the current GDC and a hypothetical DMD that used PE-COFF and MinGW bintools?

--bb

Bill Baxter wrote:
> It seems to me that the MinGW tools are pretty much the best and only hope if you are going to abandon OMF and OptLink.

Yesterday, there were strong claims made about the DM Win32 obj-format (OMF) being compatible with a number of different linkers. I'm surprised it is so hard to track one down?

> 
> Implementing new object/link tools for existing formats from scratch is far too much work.  You can also forget about creating a whole new object format from scratch.  If you're going to replace OptLink it needs to be with something that exists and is standard.
> 
> But there's not a whole lot out there in terms of free code for object file and library manipulation.  There's OpenWatcom, which also suffers from being OMF-based, and apparently has more bugs than D's current tools, and then there's MinGW, which works with MS PE-COFF.

The one that I used was 4 years old. I've not tried the more recent version of OpenWatcom ... has anyone else?

> 
> Personally, I don't see why on Windows you'd want to use anything other than Microsoft's format.  Especially now that you can get their latest C++ compiler for free.  Intel's super-optimized compiler is also compatible with this format.  Probably others are as well.

Very true. One big question (that's been asked several times before) is "how does DM expect to support 64-bit on Win32"? Perhaps OMF will have to be dumped one way or another?

> 
> Other than the GPL license, it seems like the MinGW tools have everything one could hope for.  Is the license the only real problem?

Is it 64-bit compliant?

> 
> Also -- one thing that I'm not sure about:  Would there be any difference between the current GDC and a hypothetical DMD that used PE-COFF and MinGW bintools?
> 
> --bb

kris wrote:
> Bill Baxter wrote:
>> It seems to me that the MinGW tools are pretty much the best and only hope if you are going to abandon OMF and OptLink.
> 
> Yesterday, there were strong claims made about the DM Win32 obj-format (OMF) being compatible with a number of different linkers. I'm surprised it is so hard to track one down?

Perhaps not so surprising given the age of the OMF format.  DMC/DMD are the only compilers I know of that still use it.

>> Personally, I don't see why on Windows you'd want to use anything other than Microsoft's format.  Especially now that you can get their latest C++ compiler for free.  Intel's super-optimized compiler is also compatible with this format.  Probably others are as well.
> 
> Very true. One big question (that's been asked several times before) is "how does DM expect to support 64-bit on Win32"? Perhaps OMF will have to be dumped one way or another?

I suspect it will, but that's more a hunch than an authoritative claim.

>> Other than the GPL license, it seems like the MinGW tools have everything one could hope for.  Is the license the only real problem?
> 
> Is it 64-bit compliant?

I think the license may turn out to be more of an issue as far as DMD is concerned.  Why work to generate code for an object file format you don't have the software to link?  Or is it perhaps not a tremendous amount of work (which seems unlikely) and the format could be specified via a compiler flag?


Sean

By the way, this may be a pertinent link:

http://support.microsoft.com/kb/888328

Sean Kelly wrote:
> By the way, this may be a pertinent link:
> 
> http://support.microsoft.com/kb/888328

That's only talking about the format for debug symbols so I'm not sure how relevant it is.
It also only says you can't *build* objects with COFF debug info, but it doesn't say whether MS tool still support *debugging* programs with embedded COFF debug info.

kris wrote:
> Bill Baxter wrote:
>> It seems to me that the MinGW tools are pretty much the best and only hope if you are going to abandon OMF and OptLink.
> 
> Yesterday, there were strong claims made about the DM Win32 obj-format (OMF) being compatible with a number of different linkers. I'm surprised it is so hard to track one down?

There were some other tools I saw that use OMF format.  Actually alink can use both.  And the OpenWatcom tools are using it too.  But aside from OpenWatcom I didn't notice any *currently supported* tools using OMF as their main format.   Most of the OMF-using links were to things for generating 16-bit or MS-DOS compatible programs.  Maybe MS-DOS support is still important in the embedded world, though?

>> Other than the GPL license, it seems like the MinGW tools have everything one could hope for.  Is the license the only real problem?
> 
> Is it 64-bit compliant?

http://www.mingw.org/mingwfaq.shtml#faq-what
Says it "will be eventually".

I think too many people use MinGW for 64-bit to remain unsupported.
Actually there may be a patch or something floating around because a search for mingw64 turns up lots of hits.

--bb

On Fri, 23 Feb 2007 09:36:09 +0900, Bill Baxter wrote:

> It seems to me that the MinGW tools are pretty much the best and only hope if you are going to abandon OMF and OptLink.
> 
> Implementing new object/link tools for existing formats from scratch is far too much work.  You can also forget about creating a whole new object format from scratch.  If you're going to replace OptLink it needs to be with something that exists and is standard.
> 
> But there's not a whole lot out there in terms of free code for object file and library manipulation.  There's OpenWatcom, which also suffers from being OMF-based, and apparently has more bugs than D's current tools, and then there's MinGW, which works with MS PE-COFF.
> 
> Personally, I don't see why on Windows you'd want to use anything other than Microsoft's format.  Especially now that you can get their latest C++ compiler for free.  Intel's super-optimized compiler is also compatible with this format.  Probably others are as well.
> 
> Other than the GPL license, it seems like the MinGW tools have everything one could hope for.  Is the license the only real problem?
> 
> Also -- one thing that I'm not sure about:  Would there be any difference between the current GDC and a hypothetical DMD that used PE-COFF and MinGW bintools?
> 
> --bb


Between OpenWatcom and Mingw, we at least have something to think about. MingW particularly is not going away anytime soon and has a large developer base.

This should be investigated. Of course, it's all rather futile if dmd doesn't commit to outputting files in a compatible format for these tools.

-JJR

Bill Baxter wrote:
> It also only says you can't *build* objects with COFF debug info, but it doesn't say whether MS tool still support *debugging* programs with embedded COFF debug info.

Support for debugging embedded debug symbols is kind of broken in new MS debuggers. It's like they crippled that support while updating the software. The debugger reads the symbols and you can see them, but it doesn't find the source line corresponding to an address, so you can't use it.

But isn't this about the linker, anyway? As long as the linker copies embedded debug symbols from COFF files correctly to the executable, there shouldn't be a problem.

Jascha Wetzel wrote:
> Bill Baxter wrote:
>> It also only says you can't *build* objects with COFF debug info, but it
>> doesn't say whether MS tool still support *debugging* programs with
>> embedded COFF debug info.
> 
> Support for debugging embedded debug symbols is kind of broken in new MS
> debuggers. It's like they crippled that support while updating the
> software. The debugger reads the symbols and you can see them, but it
> doesn't find the source line corresponding to an address, so you can't
> use it.
> 
> But isn't this about the linker, anyway? As long as the linker copies
> embedded debug symbols from COFF files correctly to the executable,
> there shouldn't be a problem.

Ah, good point.  I only brought this up because a switch to COFF is seen as a universally good thing, but if this "new" object format isn't even supported by MS debuggers any more, then it still may be an issue for Win32 development.  But I suppose it's pointless trying to chase changing MS standards.  There are other linkers and debuggers out there anyway.


Sean