February 25, 2007
On Sun, 25 Feb 2007 18:38:34 +0100, Frits van Bommel wrote:

> John Reimer wrote:
>> On Sun, 25 Feb 2007 15:08:56 +0100, Jascha Wetzel wrote:
>> 
>>> Bill Baxter wrote:
>>>> Thinking about it, it might actually seem like a better deal if you said it was $15 for coff2omf and obj2asm, and the rest of the stuff is thrown in for free.  As it is the web page seems to imply that coff2omf is about equal to chmod in terms of programming effort and is contributing equally to the cost.
>>> or let's say you support walter's multi-year effort for D by buying the
>>> package, no matter it's content. i'd buy a megabyte of white noise for
>>> that matter ;)
>>> but i found that EUP's grep tool is even more useful than white noise...
>> 
>> Right.  Oh and I forgot about the grep tool.  It is good! :)
> 
> Why are you so excited about DM's grep?
> Is it much better than the GNU version?[1]
> Because that one is available for free, even on Windows.
>  From http://www.digitalmars.com/ctg/grep.html, the only features
> mentioned that the GNU version doesn't (or at least that I don't know
> how to turn on) are -v (verbose, woohoo ;) ), and wide character
> searching. That last one may be useful for some people, but AFAIK I
> don't even have any text files with wide characters on my computer.
> 
> Unless, of course, you're being sarcastic.
> 
> 
> 
> [1]: I can understand it being more useful than white noise ;).


Um?  Excited?  I was just being positive, not excited. :)  There aren't a whole lot of tools in the small package in which I'm interested.  But I'm willing to agree when I see one that was useful?  Am I not allowed to show such interest? :)

Sure grep is available for free elsewhere.  Have a look at my other post. But most other packages have fairly hefty dependencies before you get to have your favourite free tool. :)  I'm willing to put up with those dependencies, but not everyone is likely willing to go full-out linux layer just to get some grep functionality.

Is the GNU version standalone on windows?  Then you have a valid argument.

-JJR
February 25, 2007
Jascha Wetzel wrote:
> Bill Baxter wrote:
>> Thinking about it, it might actually seem like a better deal if you said
>> it was $15 for coff2omf and obj2asm, and the rest of the stuff is thrown
>> in for free.  As it is the web page seems to imply that coff2omf is
>> about equal to chmod in terms of programming effort and is contributing
>> equally to the cost.
> 
> or let's say you support walter's multi-year effort for D by buying the
> package, no matter it's content. i'd buy a megabyte of white noise for
> that matter ;)
> but i found that EUP's grep tool is even more useful than white noise...

Yeh, I might find that sort of argument persuasive too.  :-)

There's a guy who put a ton of effort into making another project I use into something very solid.  Though it's open source, he decided to make the documentation he wrote for it be non-free.  So I bought it, even though I didn't really need it that much, because the guy said documentation sales would help him out and encourage his effort.  I also contributed to buying the guy and his family a ski vacation as a thanks for the effort.  However, the DM website doesn't anywhere say I should buy the EUP because Walter's a great guy and he puts tons of time into D and making it free for everybody, and that buying it will help support and encourage him to continue work on D.

I'd be willing to contribute similarly to D.  But as far as I know Walter's never asked for such a thing (which is where I cooked up my theory that Walter must have made a small fortune from the Zortech compiler and now he's living in a mansion somewhere on the outskirts of Seattle, working full time on D as an alternative to early retirement just to keep from getting bored.)

--bb
February 25, 2007
On Sun, 25 Feb 2007 10:58:30 +0100, Lars Ivar Igesund wrote:

> Walter Bright wrote:
> 
>> John Reimer wrote:
>>> On Sat, 24 Feb 2007 22:33:11 -0800, Walter Bright wrote:
>>> 
>>>> Why does Mingw do coff on Win32, while the gcc tools everywhere else do elf? This makes no sense to me.
>>> 
>>> 
>>> It seems that elf is an object /and/ executable format, so it requires support from the OS somehow.
>> 
>> If you don't want to take my word for it, ok, but object files output from C, C++, and D compilers are not executable - not on Windows or Linux.
> 
> Actually it is possible to dynamically link static ELF object files, although it is highly impractical and very slow. As I'm sure you know, on all OS'es using ELF, ELF is used for all stages, static object files, relocatable object files, shared object files (.so and thus a shared library) and executables. The difference is in which sections are present and in some cases, what content they have.
> 
> I think it is a good idea to have the same (and actually fairly short) spec for all these formats, it makes it easier to understand a larger portion of this part of the system in depth. I also believe the executables and shared objects are considered to be very efficient, and so it is likely that there has been a compromise on behalf of static object files, making them somewhat more complex.
>



Thanks for clarifying, larsivi.  That all makes very good sense.

-JJR
February 25, 2007
torhu wrote:
> Walter Bright wrote:
>> Bill Baxter wrote:
>>> Or if it is then maybe Walter should provide a web-based coff2omf service.  $2 a pop, and if it doesn't work you don't pay.  Or something like that.  I might give that a try.  :-)
>>
>> It's only $15. And I've been known to give refunds to people it didn't work for, even though I think each of the utilities in the EUP are easily worth $15 by themselves. OBJ2ASM in particular!
> 
> In the case of the D version of AllegroGL, I need a free tool that I can point people to.  Otherwise, it's not an option to use coff2omf.  A free library can't depend on people obtaining non-free tools.  Even if I could provide the needed binaries for linking with, it's a dead end, because anyone supposed to take over maintenance after me would need to buy coff2omf too.  Which isn't going to happen.
> 
> 
> But I guess making AllegroGL compile to a dll is the better solution in the long run, since it doesn't depend on compiling to a specific version of the coff format.

Probably so.  I notice that Allegro itself has a lot of language bindings.  Like PyAllegro for python LuAllegro for lua etc.  Python at least needs you to make a dll in the end in order to load any C code as a module, so someone may have done some work that you can leverage already.

--bb
February 25, 2007
John Reimer wrote:
> On Sun, 25 Feb 2007 18:38:34 +0100, Frits van Bommel wrote:
> 
>> John Reimer wrote:
>>> On Sun, 25 Feb 2007 15:08:56 +0100, Jascha Wetzel wrote:
>>>
>>>> Bill Baxter wrote:
>>>>> Thinking about it, it might actually seem like a better deal if you said
>>>>> it was $15 for coff2omf and obj2asm, and the rest of the stuff is thrown
>>>>> in for free.  As it is the web page seems to imply that coff2omf is
>>>>> about equal to chmod in terms of programming effort and is contributing
>>>>> equally to the cost.
>>>> or let's say you support walter's multi-year effort for D by buying the
>>>> package, no matter it's content. i'd buy a megabyte of white noise for
>>>> that matter ;)
>>>> but i found that EUP's grep tool is even more useful than white noise...
>>> Right.  Oh and I forgot about the grep tool.  It is good! :)
>> Why are you so excited about DM's grep?
>> Is it much better than the GNU version?[1]
>> Because that one is available for free, even on Windows.
>>  From http://www.digitalmars.com/ctg/grep.html, the only features mentioned that the GNU version doesn't (or at least that I don't know how to turn on) are -v (verbose, woohoo ;) ), and wide character searching. That last one may be useful for some people, but AFAIK I don't even have any text files with wide characters on my computer.
>>
>> Unless, of course, you're being sarcastic.
>>
>>
>>
>> [1]: I can understand it being more useful than white noise ;).
> 
> 
> Um?  Excited?  I was just being positive, not excited. :)  There aren't a
> whole lot of tools in the small package in which I'm interested.  But I'm
> willing to agree when I see one that was useful?  Am I not allowed to show
> such interest? :)
> 
> Sure grep is available for free elsewhere.  Have a look at my other post. But most other packages have fairly hefty dependencies before you get to
> have your favourite free tool. :)  I'm willing to put up with those
> dependencies, but not everyone is likely willing to go full-out linux layer
> just to get some grep functionality.
> 
> Is the GNU version standalone on windows?  Then you have a valid argument.

I don't know about the one Frits mentioned, but the one at the link I posted is.

"""
Here are some ports of common GNU utilities to native Win32. In this context, native means the executables do only depend on the Microsoft C-runtime (msvcrt.dll) and not an emulation layer like that provided by Cygwin  tools.
"""
      -- http://unxutils.sourceforge.net/


--bb
February 25, 2007
John Reimer wrote:
> On Sun, 25 Feb 2007 10:48:36 +0100, Frits van Bommel wrote:
> 
>> John Reimer wrote:
>>> On Sat, 24 Feb 2007 22:33:11 -0800, Walter Bright wrote:
>>>
>>>> Why does Mingw do coff on Win32, while the gcc tools everywhere else do elf? This makes no sense to me.
>>>
>>> It seems that elf is an object /and/ executable format, so it requires
>>> support from the OS somehow.  
>> Only if you use the executable format. I don't see any reason it couldn't be used as an object format (unless PE executables need information ELF has no way to represent).
> 
> Okay, thanks.  That clarifies things a little.  So elf must have two
> formats in one,

Actually, there are _three_ types.

There are relocatable files (typically named *.o) that can be linked together to create the other formats.

Then there are executable files that are "suitable for execution", i.e. programs. Typically named without file extension.

And lastly, there are shared object files, that can be either further linked with other shared object files and relocatable files, or dynamically loaded at runtime.
These are typically used for dynamic libraries (the second use mentioned), like DLLs are on Windows. They're typically named *.so or *.so.*, with the last asterisk containing a version number (e.g. libc.so.6 or libreadline.so.5.1).

> and the object elf format is not dependentant on the elf
> executable format?

The formats are very similar, and described in the same standard, but AFAIK they don't actually depend on each other.

The header contains a field that defines which type it is (there are also defined values for 'core' files (produced on crash) and processor-specific formats, but their contents aren't specified.

Some of the differences between the formats that _are_ defined are slight differences in the meanings of some fields (e.g. absolute vs. relative addresses) and the fact that some entities are optional for some formats. For example, relocatable files don't need to have a program header.

> So really it comes down to whether the elf object
> format can embed in a PE?

Yes, pretty much.

> Further, for elf shared libraries, I assume
> having an appropriate dynamic linker is still important.

Maybe DDL can help here. Or a bit of other (standard?) library support.

> Strangely finding information  like this online is extremely difficult.

About ELF or about linking it to PE?

There's plenty of information about ELF available. Just google for "executable linkable format" instead of "ELF", since Google isn't case-sensitive ;)

There might be no info about linking ELF to PE, but that could just be because nobody has been crazy enough to try it yet :P.

> All I know is that there was a project (several years ago ~1999) that provided a elf-linker/loader for NT which now has fallen into
> non-existance: it was called cross-elf.

I never heard of that project, but if it was around 1999 that doesn't surprise me.

>>> Whereas coff is merely an object format and PE appears to be windows
>>> executable format.
>>>
>>> That may be the reason that mingw went coff instead, even it it isn't
>>> compatible with MS coff objects.
>> IIRC mingw is compatible with *some* MS .lib files. It may be just import libraries, and/or just C libraries.
>> I remember there being *-msvc and *-mingw .libs for one library (I think it was Allegro or SDL or some such) where the difference was _what they were compiled with_, not _what they could be used with_. In fact, IIRC it was recommended to use the *-msvc libs even for mingw...
> 
> Yes, this might be possible, but I'm not sure how it works, since I read
> online somewhere that mingw uses a different naming convention for its
> coff as well as other small changes (dss).  Maybe the mingw linker (ld)
> understands more than its own coff variation, however.  That
> makes mingw look even better in my eyes.  I know mingw ld.exe supports a
> whole bunch of other linker formats including elf -- huge bonus.  The only
> one it doesn't support is OMF! :)

Are you sure mingw ld supports ELF?
I'm pretty sure I've gotten "PE operation on non-PE file" or some such error multiple times when I accidentally used mingw ld to link ELF objects. (I was cross-compiling)
If it _can_ already support ELF objects to PE executable, that's news to me. But I haven't tried it lately, so it may just have been fixed.
February 25, 2007
John Reimer wrote:
> On Sun, 25 Feb 2007 18:28:04 +0100, Frits van Bommel wrote:
> 
>> Julio César Carrascal Urquijo wrote:
>>> Also, I think this change will adversely affect DDL (http://dsource.org/projects/ddl/) since it loads the .obj files and links them directly into the application.
>> DDL already supports ELF (as well as COFF/PE). I can't find any mention on the site that this feature is not available on Windows.
> 
> Where, oh where is Pragma?  He could tell us... :)
> 
> Or I may just go try it out...

What I meant was "I'm pretty sure it works already :)".
I don't see any reason why it wouldn't work, but if there was one I'm pretty sure it would be noted on the site. Instead, there's mention of the possibility of OS-independent dynamic libraries.
February 25, 2007
torhu wrote:
> Bill Baxter wrote:
>> There are number of free sources for unix-like tools for windows. There's Cygwin, of course.  Then there's also http://unxutils.sourceforge.net/ .
> 
> More complete and up to date set of tools here:
> 
> http://gnuwin32.sourceforge.net/

Nice.  Thanks for the link.  It does look more up-to-date.

I wish they had separate download packages for the exes and development libraries.

--bb
February 25, 2007
John Reimer wrote:
> On Mon, 26 Feb 2007 02:27:26 +0900, Bill Baxter wrote:
> 
>> There are number of free sources for unix-like tools for windows. There's Cygwin, of course.  Then there's also http://unxutils.sourceforge.net/ .
> 
> Yes, I know.  In fact, you don't even need to get cygwin to get grep.  You
> can use MSYS instead, which I prefer.
> 
> But for those that don't want to download all the extras or go anywhere
> near the unix compatibility layers, having access to a tool that
> just works on the current OS without dependencies is a feature. :)  

The link he posted doesn't use Cygwin. That project compiled native .exes for several traditional Unix utilities, depending only on msvcrt.dll (distributed with windows).
Apparently the .zip containing them is a dead link now, though. It used to be a quite compact download with lots of stand-alone utils though. I just re-zipped my install on another computer and it was only 137k.
February 25, 2007
On Mon, 26 Feb 2007 03:09:51 +0900, Bill Baxter wrote:

> John Reimer wrote:
>> On Sun, 25 Feb 2007 18:38:34 +0100, Frits van Bommel wrote:
>> 
>>> John Reimer wrote:
>>>> On Sun, 25 Feb 2007 15:08:56 +0100, Jascha Wetzel wrote:
>>>>
>>>>> Bill Baxter wrote:
>>>>>> Thinking about it, it might actually seem like a better deal if you said it was $15 for coff2omf and obj2asm, and the rest of the stuff is thrown in for free.  As it is the web page seems to imply that coff2omf is about equal to chmod in terms of programming effort and is contributing equally to the cost.
>>>>> or let's say you support walter's multi-year effort for D by buying the
>>>>> package, no matter it's content. i'd buy a megabyte of white noise for
>>>>> that matter ;)
>>>>> but i found that EUP's grep tool is even more useful than white noise...
>>>> Right.  Oh and I forgot about the grep tool.  It is good! :)
>>> Why are you so excited about DM's grep?
>>> Is it much better than the GNU version?[1]
>>> Because that one is available for free, even on Windows.
>>>  From http://www.digitalmars.com/ctg/grep.html, the only features
>>> mentioned that the GNU version doesn't (or at least that I don't know
>>> how to turn on) are -v (verbose, woohoo ;) ), and wide character
>>> searching. That last one may be useful for some people, but AFAIK I
>>> don't even have any text files with wide characters on my computer.
>>>
>>> Unless, of course, you're being sarcastic.
>>>
>>>
>>>
>>> [1]: I can understand it being more useful than white noise ;).
>> 
>> 
>> Um?  Excited?  I was just being positive, not excited. :)  There aren't a whole lot of tools in the small package in which I'm interested.  But I'm willing to agree when I see one that was useful?  Am I not allowed to show such interest? :)
>> 
>> Sure grep is available for free elsewhere.  Have a look at my other post. But most other packages have fairly hefty dependencies before you get to have your favourite free tool. :)  I'm willing to put up with those dependencies, but not everyone is likely willing to go full-out linux layer just to get some grep functionality.
>> 
>> Is the GNU version standalone on windows?  Then you have a valid argument.
> 
> I don't know about the one Frits mentioned, but the one at the link I posted is.
> 
> """
> Here are some ports of common GNU utilities to native Win32. In this
> context, native means the executables do only depend on the Microsoft
> C-runtime (msvcrt.dll) and not an emulation layer like that provided by
> Cygwin  tools.
> """
>        -- http://unxutils.sourceforge.net/
> 
> 
> --bb


Yeah, sorry.  I seem to have missed that.  I just saw cygwin and a link in your last post and ended up missing this.

My apologies.

-JJR