www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Request: make coff2omf free

reply torhu <fake address.dude> writes:
I'm working on translating headers for a C lib called allegroGL to D. 
The C lib isn't set up for building DLLs on windows, only libs for 
static linking.  So I'm stuck with mingw or msvc lib files that I can't 
link with my D objects.

Getting this library to compile to a DLL requires adapting the source, 
creating .def files, etc.  I'm not too keen on that.

So Mr. Bright: I'm wondering if you could make coff2omf available as 
part of the basic utility package, like implib already is.  I think it's 
fair to say that this is in the interest of encouraging adoptation of D. :)
Feb 24 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
torhu wrote:

 I'm working on translating headers for a C lib called allegroGL to D. 
 The C lib isn't set up for building DLLs on windows, only libs for 
 static linking.  So I'm stuck with mingw or msvc lib files that I can't 
 link with my D objects.
 
 Getting this library to compile to a DLL requires adapting the source, 
 creating .def files, etc.  I'm not too keen on that.
 
 So Mr. Bright: I'm wondering if you could make coff2omf available as 
 part of the basic utility package, like implib already is.  I think it's 
 fair to say that this is in the interest of encouraging adoptation of D. :)


Can't you just compile it with DMC? It shares the backend with DMD, so 
it should produce link-compatible output.
Feb 24 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
news:erpp6f$2cka$1 digitalmars.com...

 torhu wrote:

 I'm working on translating headers for a C lib called allegroGL to D. The 
 C lib isn't set up for building DLLs on windows, only libs for static 
 linking.  So I'm stuck with mingw or msvc lib files that I can't link 
 with my D objects.

 Getting this library to compile to a DLL requires adapting the source, 
 creating .def files, etc.  I'm not too keen on that.

 So Mr. Bright: I'm wondering if you could make coff2omf available as part 
 of the basic utility package, like implib already is.  I think it's fair 
 to say that this is in the interest of encouraging adoptation of D. :)


 Can't you just compile it with DMC? It shares the backend with DMD, so it 
 should produce link-compatible output.


Not all libraries come with source.  Yeah, you'll probably say "then you 
shouldn't use them" but that's just impractical.
Feb 24 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jarrett Billingsley wrote:

 "Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
 news:erpp6f$2cka$1 digitalmars.com...

 torhu wrote:

 I'm working on translating headers for a C lib called allegroGL to D. The 
 C lib isn't set up for building DLLs on windows, only libs for static 
 linking.  So I'm stuck with mingw or msvc lib files that I can't link 
 with my D objects.






[snip]

 Can't you just compile it with DMC? It shares the backend with DMD, so it 
 should produce link-compatible output.


 
 Not all libraries come with source.  Yeah, you'll probably say "then you 
 shouldn't use them" but that's just impractical. 


Actually, I wouldn't say that.

I however do happen to know Allegro _is_ open source, and assumed 
AllegroGL was as well. And as far as I cam tell I was right about that: 
http://allegrogl.sourceforge.net/
Anonymous SVN access is provided and it seem the sourceforge download 
page offers _only_ source downloads. So I'm not even sure where to get a 
binary static library without building it yourself, though there are 
usually unofficial binary packagers for such source-only libs.

Now I've just looked at the quickstart docs, and it doesn't seem to 
provide instructions for DMC. So if it doesn't compile on DMC that's a 
different story. All I asked was if torhu had looked into the possibility.
Feb 24 2007
prev sibling parent reply torhu <fake address.dude> writes:
Frits van Bommel wrote:
  > Can't you just compile it with DMC? It shares the backend with DMD, so

 it should produce link-compatible output.


That's was my first idea, and I converted the makefile.  But there's 
some preprocessor stuff too that needs adjusting.  At that point i 
started looking for easier solutions.  So it's not 'just' compiling with 
DMC, I'm afraid.  I wish it was.

C libraries tend to have complicated build setups, that involve multiple 
makefiles, scripts, and elaborate use of the preprocessor to adapt code 
to various compilers.  AllegroGL is no exception.
Feb 24 2007
parent Walter Bright <newshound digitalmars.com> writes:
torhu wrote:

 C libraries tend to have complicated build setups, that involve multiple 
 makefiles, scripts, and elaborate use of the preprocessor to adapt code 
 to various compilers.  AllegroGL is no exception.


I agree, and it often can be pretty challenging to get something 
downloaded off the net to actually compile because of this. It's one 
reason why D has much more restrictive version statements, etc.
Feb 24 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
torhu wrote:

 I'm working on translating headers for a C lib called allegroGL to D. 
 The C lib isn't set up for building DLLs on windows, only libs for 
 static linking.  So I'm stuck with mingw or msvc lib files that I can't 
 link with my D objects.
 
 Getting this library to compile to a DLL requires adapting the source, 
 creating .def files, etc.  I'm not too keen on that.
 
 So Mr. Bright: I'm wondering if you could make coff2omf available as 
 part of the basic utility package, like implib already is.  I think it's 
 fair to say that this is in the interest of encouraging adoptation of D. :)


I asked about coff2omf a while back and the response I got from someone 
on the newsgroup here was "it's hit or miss".  Apparently it doesn't 
always work.  Now maybe the gentleman telling me that was wrong, but I'm 
certainly not going to *pay* for it just to find out that it doesn't 
actually work.  And I think most people are in a situation like you 
where they have basically ONE library they want to convert ONE time, and 
  really no need for the rest of the things in the EUP.

So in short, I agree with you, it should be part of the bup.  I can't 
imagine it's making a huge revenue stream for Walter, anyway.

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

--bb
Feb 24 2007
next sibling parent John Reimer <terminal.node gmail.com> writes:
On Sun, 25 Feb 2007 06:14:19 +0900, Bill Baxter wrote:


 torhu wrote:

 I'm working on translating headers for a C lib called allegroGL to D. 
 The C lib isn't set up for building DLLs on windows, only libs for 
 static linking.  So I'm stuck with mingw or msvc lib files that I can't 
 link with my D objects.
 
 Getting this library to compile to a DLL requires adapting the source, 
 creating .def files, etc.  I'm not too keen on that.
 
 So Mr. Bright: I'm wondering if you could make coff2omf available as 
 part of the basic utility package, like implib already is.  I think it's 
 fair to say that this is in the interest of encouraging adoptation of D. :)


 
 I asked about coff2omf a while back and the response I got from someone 
 on the newsgroup here was "it's hit or miss".  Apparently it doesn't 
 always work.  Now maybe the gentleman telling me that was wrong, but I'm 
 certainly not going to *pay* for it just to find out that it doesn't 
 actually work.  And I think most people are in a situation like you 
 where they have basically ONE library they want to convert ONE time, and 
   really no need for the rest of the things in the EUP.
 
 So in short, I agree with you, it should be part of the bup.  I can't 
 imagine it's making a huge revenue stream for Walter, anyway.
 
 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.  :-)
 
 --bb



It's "hit and miss" precisely for the reason that Walter has said he
avoids moving to the coff format for his tools: coff versions and
variations seem to have added subtle incompatibilities with each other
over the years.  It's never as simple as using the coff2omf tool on an
object just because it claims to be "coff". Ever tried getting coff
objects from multiple vendors interoperating? It's not likely to work
either.

In the past, if you wanted to give coff2omf.exe a fighting chance with
understanding an unsupported MS coff object file, you had to find a
certain version of the MS linker to convert it for you with a
obscure switch (this linker was sometimes only found in a certain hard to
find MS SDK). Even then, it seems it was "hit and miss". In the end, it
seems the coff2omf tool is only useful for a certain version of MS coff
libraries/objects. And if it works, then you were just lucky.

-JJR
Feb 24 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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!
Feb 24 2007
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
On Sat, 24 Feb 2007 16:43:31 -0800, 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!



Personally, I would say that if a person finds it important to get
a library working with dmc/dmd, then it's worth investing in the
digitalmars tools to give it a shot -- specifically the whole dmc compiler
suite which is reasonably priced.

Otherwise, given all the problems a person can have developing on win32
(specifically while trying to work with old object formats), I'd
suggest moving to a unix type operating system instead where these kind of
problems don't exist.  Since the latter is not a practical solution, you
can also just use mingw -- not the best solution, but at least it's well
supported, and uses /a/ coff format.

-JJR

PS. I speak as one who bought the Digitalmars C/C++ compiler suite from
Walter a few years ago.  I have no complaints about the quality of
software, other than the feeling that some things are outdated.
Feb 24 2007
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
John Reimer wrote:

 Otherwise, given all the problems a person can have developing on win32
 (specifically while trying to work with old object formats), I'd
 suggest moving to a unix type operating system instead where these kind of
 problems don't exist.  Since the latter is not a practical solution, you
 can also just use mingw -- not the best solution, but at least it's well
 supported, and uses /a/ coff format.


One thing that Microsoft does is keep changing their omf format. It's a 
full time job just keeping up with that, that's why I gave it up. If I 
ever do update the entire omf toolchain, it'll be to ELF/Dwarf format, 
not because I like them (they are overly complicated) but because being 
ubiquitous on Linux it reduces my workload.


 PS. I speak as one who bought the Digitalmars C/C++ compiler suite from
 Walter a few years ago.  I have no complaints about the quality of
 software, other than the feeling that some things are outdated.


Some of the things are outdated. Before I got it, it was developed by a 
small army of very competent people. A few individuals, like Andrew 
Bushnell, who were former developers on it have helped me out with it, 
but it's largely been my own efforts on it, and I try to do what's most 
effective with my resources.
Feb 24 2007
next sibling parent reply =?UTF-8?B?SnVsaW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpv?= writes:
Walter Bright wrote:

 One thing that Microsoft does is keep changing their omf format. It's a 
 full time job just keeping up with that, that's why I gave it up. If I 
 ever do update the entire omf toolchain, it'll be to ELF/Dwarf format, 
 not because I like them (they are overly complicated) but because being 
 ubiquitous on Linux it reduces my workload.


Here's a random idea. Why not update the toolchain to support the COFF 
format that MinGW uses? Not Microsoft's, not Borland's. Lots of 
libraries support directly MinGW and it would help us a bit interfacing 
D code with C or even C++.

Of course the incompatibilities between the different libc and loaders 
will still be problems but those are workable if source is available.

What do you think, Walter? It's still too much work and not enough gain?

Thanks
Feb 24 2007
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Julio César Carrascal Urquijo" <jcesar phreaker.net> wrote in message 
news:erqs78$11vb$1 digitalmars.com...

 Here's a random idea. Why not update the toolchain to support the COFF 
 format that MinGW uses? Not Microsoft's, not Borland's. Lots of libraries 
 support directly MinGW and it would help us a bit interfacing D code with 
 C or even C++.


I'd really like that.  It would mean that D would be interoperable with gcc 
in all platforms.  That's a good standard to follow.  That, and just about 
anything would be better and more commonly supported than OMF.
Feb 24 2007
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Julio César Carrascal Urquijo wrote:

 Walter Bright wrote:

 One thing that Microsoft does is keep changing their omf format. It's 
 a full time job just keeping up with that, that's why I gave it up. If 
 I ever do update the entire omf toolchain, it'll be to ELF/Dwarf 
 format, not because I like them (they are overly complicated) but 
 because being ubiquitous on Linux it reduces my workload.


 
 Here's a random idea. Why not update the toolchain to support the COFF 
 format that MinGW uses? Not Microsoft's, not Borland's. Lots of 
 libraries support directly MinGW and it would help us a bit interfacing 
 D code with C or even C++.
 
 Of course the incompatibilities between the different libc and loaders 
 will still be problems but those are workable if source is available.
 
 What do you think, Walter? It's still too much work and not enough gain?


Since I have to support Elf anyway, it still leaves me supporting two 
formats.
Feb 24 2007
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
On Sat, 24 Feb 2007 21:00:55 -0800, Walter Bright wrote:


 Julio César Carrascal Urquijo wrote:

 Walter Bright wrote:

 One thing that Microsoft does is keep changing their omf format. It's 
 a full time job just keeping up with that, that's why I gave it up. If 
 I ever do update the entire omf toolchain, it'll be to ELF/Dwarf 
 format, not because I like them (they are overly complicated) but 
 because being ubiquitous on Linux it reduces my workload.


 
 Here's a random idea. Why not update the toolchain to support the COFF 
 format that MinGW uses? Not Microsoft's, not Borland's. Lots of 
 libraries support directly MinGW and it would help us a bit interfacing 
 D code with C or even C++.
 
 Of course the incompatibilities between the different libc and loaders 
 will still be problems but those are workable if source is available.
 
 What do you think, Walter? It's still too much work and not enough gain?


 
 Since I have to support Elf anyway, it still leaves me supporting two 
 formats.



I don't understand what you mean about supporting elf?  Supporting
elf is only applicable to linux and other OSes (or so I thought).  We're
talking about dmd on win32 here. There is no elf format for win32, or have
I misunderstood the whole situation? Can a elf format be made to work on
win32?  Even if it could, of what benefit is that for linking with the
current set of coff libraries available (mingw)? (sure, I'd love to see
elf at work on win32, but I doubt it will help much with the current
situation unless elf was use everywhere).

I believe Mingw uses a coff format. Interaction with that opens up a huge
expanse of available mingw libraries for linking with dmd/dmc.  Supporting
elf on win32 would do nothing for it here.

Maybe, I'm just misunderstanding you?

-JJR
Feb 24 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
John Reimer wrote:

 I don't understand what you mean about supporting elf?  Supporting
 elf is only applicable to linux and other OSes (or so I thought).


Right, but dmd does work on linux, and so must support Elf.


 We're
 talking about dmd on win32 here. There is no elf format for win32, or have
 I misunderstood the whole situation? Can a elf format be made to work on
 win32?


Yes. Elf (for object files, anyway) is not operating system dependent.


 Even if it could, of what benefit is that for linking with the
 current set of coff libraries available (mingw)? (sure, I'd love to see
 elf at work on win32, but I doubt it will help much with the current
 situation unless elf was use everywhere).
 
 I believe Mingw uses a coff format. Interaction with that opens up a huge
 expanse of available mingw libraries for linking with dmd/dmc.  Supporting
 elf on win32 would do nothing for it here.
 
 Maybe, I'm just misunderstanding you?


Why does Mingw do coff on Win32, while the gcc tools everywhere else do 
elf? This makes no sense to me.
Feb 24 2007
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
On Sat, 24 Feb 2007 22:33:11 -0800, Walter Bright wrote:


 John Reimer wrote:

 I don't understand what you mean about supporting elf?  Supporting
 elf is only applicable to linux and other OSes (or so I thought).


 
 Right, but dmd does work on linux, and so must support Elf.
 



Sure, Elf certainly needs to be supported in that context.



 We're
 talking about dmd on win32 here. There is no elf format for win32, or have
 I misunderstood the whole situation? Can a elf format be made to work on
 win32?


 
 Yes. Elf (for object files, anyway) is not operating system dependent.
 



I can see that this is true in theory only.  I don't recall
seeing any practical examples of it.



 Even if it could, of what benefit is that for linking with the
 current set of coff libraries available (mingw)? (sure, I'd love to see
 elf at work on win32, but I doubt it will help much with the current
 situation unless elf was use everywhere).
 
 I believe Mingw uses a coff format. Interaction with that opens up a huge
 expanse of available mingw libraries for linking with dmd/dmc.  Supporting
 elf on win32 would do nothing for it here.
 
 Maybe, I'm just misunderstanding you?


 
 Why does Mingw do coff on Win32, while the gcc tools everywhere else do 
 elf? This makes no sense to me.



GCC tools everywhere else are on OSes that have linkers and dynamic
linkers that are tuned for elf predominantly, I guess.  Windows doesn't
have a clue about it. :)

Honestly, I don't know for sure (and I'd love it if there were a way to
make elf work on windows). Given that the mingw naming convention for
symbols is different from VS coff, it doesn't appear that compatibility
with MS libs was a motivating factor for coff support. 

Does the Windows OS care about object format once a binary is linked into
an executable (ie, the OS exec loader)? Is there an instance where object
format might be of interest to the OS? On linux, I assume this is
certainly the case (dynamic linker). I don't know how it works on windows.
This goes beyond my level of knowledge.

-JJR
Feb 24 2007
parent Walter Bright <newshound digitalmars.com> writes:
John Reimer wrote:

 On Sat, 24 Feb 2007 22:33:11 -0800, Walter Bright wrote:

 Yes. Elf (for object files, anyway) is not operating system dependent.


 I can see that this is true in theory only.  I don't recall
 seeing any practical examples of it.


Having implemented an Elf object file generator and dumper, I can say 
that there aren't any OS dependencies in it.


 Does the Windows OS care about object format once a binary is linked into
 an executable (ie, the OS exec loader)?


It cannot because it never sees the obj file.


 Is there an instance where object
 format might be of interest to the OS?


It's the linker's job to create an exe file in the format recognized by 
the OS. Just like the OS never sees source code, it doesn't see object 
files either.
Feb 25 2007
prev sibling next sibling parent reply John Reimer <terminal.node gmail.com> writes:
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.  

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.

-JJR
Feb 24 2007
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.


 Whereas coff is merely an object format and PE appears to be windows
 executable format.


PE is similar to coff, but that doesn't mean you can run coff object files.


 That may be the reason that mingw went coff instead, even it it isn't
 compatible with MS coff objects.
Feb 25 2007
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Feb 25 2007
parent John Reimer <terminal.node gmail.com> writes:
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
Feb 25 2007
prev sibling parent John Reimer <terminal.node gmail.com> writes:
On Sun, 25 Feb 2007 01:26:12 -0800, 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.
 



Wait wait... I didn't mean to say that the elf files output by dmd are
directly executable, but elf files (if they are still considered
such) output by the linker stage are (dynamic or otherwise). :P  How much
does ld change these files?  I imagine they are in some class of elf format
after they go through the linker so that they can be considered
executable.  If the file format of the output file continues to be called
elf than elf effectively has an object and executable format.



 Whereas coff is merely an object format and PE appears to be windows
 executable format.


 
 PE is similar to coff, but that doesn't mean you can run coff object files.
 



Well no, I realize that I can't up and run an object.obj if I want to. :p

-JJR
Feb 25 2007
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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).


 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...
Feb 25 2007
parent reply John Reimer <terminal.node gmail.com> writes:
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, and the object elf format is not dependentant on the elf
executable format?  So really it comes down to whether the elf object
format can embed in a PE?  Further, for elf shared libraries, I assume
having an appropriate dynamic linker is still important.

Strangely finding information  like this online is extremely difficult. 
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.



 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! :)

-JJR
Feb 25 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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.
Feb 25 2007
parent John Reimer <terminal.node gmail.com> writes:
On Sun, 25 Feb 2007 19:27:00 +0100, Frits van Bommel wrote:
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?



About linking it to PE and about executing ELF on Windows..

 

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



Yes, I realize that.  I had no difficulty googling for ELF, thankyou.  
Fortunately, I've experienced Google enough to figure out how to use it. :P

 

 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.
 



Yes, this is the information that is very difficult to find.  But of more
interest, actually using ELF executables on windows (not embedded in PE)
would be of more interest to me.  I found very little information on that
beyond the cross-elf reference I mentioned in another post.  The reference
to that was made in another forum by a person asking a similar question as
mine. 


-JJR
Feb 25 2007
prev sibling parent Gregor Richards <Richards codu.org> writes:
Walter Bright wrote:

 Why does Mingw do coff on Win32, while the gcc tools everywhere else do 
 elf? This makes no sense to me.


BFD (the binary format library for binutils, the linker and utilities 
that GCC uses), supports at least: a.out, b.out, COFF, ECOFF, ELF32, 
ELF64, Mach-O, NLM32, PE, PEF, PEI, VAX, EVAX, and several other binary 
formats.

It uses whichever one is appropriate for the OS.

  - Gregor Richards
Feb 25 2007
prev sibling parent reply =?UTF-8?B?SnVsaW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpv?= writes:
Walter Bright wrote:

 Since I have to support Elf anyway, it still leaves me supporting two 
 formats.
 


I take from this that you plan on dumping OMF support on DMD for Windows 
and generate ELF .obj on both platforms. Right?

Wouldn't that defeat the purpose of:


 Uses Existing Tools

 D produces code in standard object file format, enabling the use of
 standard assemblers, linkers, debuggers, profilers, exe compressors,
 and other analyzers, as well as linking to code written in other
 languages.


http://www.digitalmars.com/d/overview.html

I haven't seen any linker / librarian on windows that support ELF.

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.
Feb 25 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Julio César Carrascal Urquijo wrote:

 Walter Bright wrote:

 Since I have to support Elf anyway, it still leaves me supporting two 
 formats.


 
 I take from this that you plan on dumping OMF support on DMD for Windows 
 and generate ELF .obj on both platforms. Right?
 
 Wouldn't that defeat the purpose of:
 
  > Uses Existing Tools
  >
  > D produces code in standard object file format, enabling the use of
  > standard assemblers, linkers, debuggers, profilers, exe compressors,
  > and other analyzers, as well as linking to code written in other
  > languages.
 
 http://www.digitalmars.com/d/overview.html
 
 I haven't seen any linker / librarian on windows that support ELF.


I have: Binutils (ld and friends) can easily be compiled on Windows with 
support for ELF.
Unfortunately, IIRC it can't support PE at the same time :(. It seems 
the MinGW patches break support for other file formats...


 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.
Feb 25 2007
parent reply John Reimer <terminal.node gmail.com> writes:
On Sun, 25 Feb 2007 18:28:04 +0100, Frits van Bommel wrote:


 Julio César Carrascal Urquijo wrote:

 Walter Bright wrote:

 Since I have to support Elf anyway, it still leaves me supporting two 
 formats.


 
 I take from this that you plan on dumping OMF support on DMD for Windows 
 and generate ELF .obj on both platforms. Right?
 
 Wouldn't that defeat the purpose of:
 
  > Uses Existing Tools
  >
  > D produces code in standard object file format, enabling the use of
  > standard assemblers, linkers, debuggers, profilers, exe compressors,
  > and other analyzers, as well as linking to code written in other
  > languages.
 
 http://www.digitalmars.com/d/overview.html
 
 I haven't seen any linker / librarian on windows that support ELF.


 
 I have: Binutils (ld and friends) can easily be compiled on Windows with 
 support for ELF.
 Unfortunately, IIRC it can't support PE at the same time :(. It seems 
 the MinGW patches break support for other file formats...
 



Yes, I noticed that ld.exe supported several formats.  I had not idea
whether it worked or not.  Thanks for clarifying :(.  Maybe there's a
deeper reason for why PE and elf can't work together?



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

-JJR
Feb 25 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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.
Feb 25 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Frits van Bommel wrote:

 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.


I'm certainly no expert but from what I do know, the container the code
is kept in is largely irrelevant.  All that really matters is that it's
for the right CPU (hopefully the one you're using) and that a few other
things are done the same way (like exceptions).

I think it's kind of like the difference between a text file stored in
an archive.  Whether you use ZIP, RAR or 7z is beside the point: it's
more important that the text file is in a language you understand :P

Finally, I believe the mention of OS-independent libraries was referring
to the possibility of writing shims that, providing the code was for the
right CPU, would resolve the other differences like exception handling.
 But then, I could be wrong :P

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Feb 25 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Daniel Keep wrote:

 
 I'm certainly no expert but from what I do know, the container the code
 is kept in is largely irrelevant.  All that really matters is that it's
 for the right CPU (hopefully the one you're using) and that a few other
 things are done the same way (like exceptions).
 
 I think it's kind of like the difference between a text file stored in
 an archive.  Whether you use ZIP, RAR or 7z is beside the point: it's
 more important that the text file is in a language you understand :P


Where do calling conventions fit into that picture?  Doesn't it vary 
from platform to platform which of caller or callee pushes and pops 
arguments, or if some number of them are passed by registers instead of 
stack?

--bb
Feb 25 2007
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Bill Baxter wrote:

 Daniel Keep wrote:

 I'm certainly no expert but from what I do know, the container the code
 is kept in is largely irrelevant.  All that really matters is that it's
 for the right CPU (hopefully the one you're using) and that a few other
 things are done the same way (like exceptions).

 I think it's kind of like the difference between a text file stored in
 an archive.  Whether you use ZIP, RAR or 7z is beside the point: it's
 more important that the text file is in a language you understand :P


 
 Where do calling conventions fit into that picture?  Doesn't it vary
 from platform to platform which of caller or callee pushes and pops
 arguments, or if some number of them are passed by registers instead of
 stack?
 
 --bb


Those are the sentence structure :P

Again, that's an issue with the generated code and it's also something
that would be *theoretically* possible to shim (like having an extern(C)
function that then calls your C++ functions).

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Feb 25 2007
prev sibling parent John Reimer <terminal.node gmail.com> writes:
On Mon, 26 Feb 2007 10:42:13 +1100, Daniel Keep wrote:


 I'm certainly no expert but from what I do know, the container the code
 is kept in is largely irrelevant.  All that really matters is that it's
 for the right CPU (hopefully the one you're using) and that a few other
 things are done the same way (like exceptions).
 
 I think it's kind of like the difference between a text file stored in
 an archive.  Whether you use ZIP, RAR or 7z is beside the point: it's
 more important that the text file is in a language you understand :P
 
 Finally, I believe the mention of OS-independent libraries was referring
 to the possibility of writing shims that, providing the code was for the
 right CPU, would resolve the other differences like exception handling.
  But then, I could be wrong :P
 
 	-- Daniel



Yes, well, one still needs the software to unzip the archives. :P

Following this analogy, windows doesn't have this for elf executables.

-JJR
Feb 25 2007
prev sibling parent John Reimer <terminal.node gmail.com> writes:
On Sat, 24 Feb 2007 21:27:38 -0500, Julio César Carrascal Urquijo wrote:


 Walter Bright wrote:

 One thing that Microsoft does is keep changing their omf format. It's a 
 full time job just keeping up with that, that's why I gave it up. If I 
 ever do update the entire omf toolchain, it'll be to ELF/Dwarf format, 
 not because I like them (they are overly complicated) but because being 
 ubiquitous on Linux it reduces my workload.


 
 Here's a random idea. Why not update the toolchain to support the COFF 
 format that MinGW uses? Not Microsoft's, not Borland's. Lots of 
 libraries support directly MinGW and it would help us a bit interfacing 
 D code with C or even C++.
 
 Of course the incompatibilities between the different libc and loaders 
 will still be problems but those are workable if source is available.
 
 What do you think, Walter? It's still too much work and not enough gain?
 
 Thanks



Yes, this is what was practically suggested concerning updating the dmd
tools in another thread.  Mingw, at least, seems to be the next major
player in a myriad of win32 projects.  Following mingw would be the best,
(and only, in my opinion) way of attempting to implement a coff format
for a toolset.  But then, for Walter, this may return to the problem of IP
tainting, which continues to be a thoroughly disappointing problem.
Hesitation in that area keeps driving home why having an opensource
frontend is insufficient.  Mingw GDC, naturally, is the next best thing
since it supplies us with the opportunity to use all the necessary tools
inherited from mingw.

Nonetheless, I really wish dmd and dmc internals were updated to interact
fully with the mingw toolset.  The library support there seems so
expansive (most opensource projects these days seem to support both Mingw
and MS VC++).

-JJR
Feb 24 2007
prev sibling parent reply janderson <askme me.com> writes:
Walter Bright wrote:

 John Reimer wrote:
 
 Some of the things are outdated. Before I got it, it was developed by a 
 small army of very competent people. A few individuals, like Andrew 
 Bushnell, who were former developers on it have helped me out with it, 
 but it's largely been my own efforts on it, and I try to do what's most 
 effective with my resources.


Just out of curiosity.

If you where to find a better solid revenue stream (not that I know of 
any) from DMD or DMC would you consider hiring people to help you out?

Also... how should I put this ... If you where suddenly unable to work 
on D anymore, do you have someone in mind who would be able to continue 
the development of D?

-Joel
Feb 24 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
janderson wrote:

 If you where to find a better solid revenue stream (not that I know of 
 any) from DMD or DMC would you consider hiring people to help you out?


Yes.


 Also... how should I put this ... If you where suddenly unable to work 
 on D anymore, do you have someone in mind who would be able to continue 
 the development of D?


While dmd is dependent on me, D is not, since gdc is fully open source.
Feb 24 2007
parent janderson <askme me.com> writes:
Walter Bright wrote:

 janderson wrote:

 If you where to find a better solid revenue stream (not that I know of 
 any) from DMD or DMC would you consider hiring people to help you out?


 
 Yes.
 

 Also... how should I put this ... If you where suddenly unable to work 
 on D anymore, do you have someone in mind who would be able to 
 continue the development of D?


 
 While dmd is dependent on me, D is not, since gdc is fully open source.


Its not like gdc could form a committee and take D in a different 
direction at the moment.  I think that's a good thing at the moment. 
The C++ committee takes forever to make any progress.

However I guess that would be an one option if this was to occur.

-Joel
Feb 24 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
John Reimer wrote:

 On Sat, 24 Feb 2007 16:43:31 -0800, 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!


 
 
 Personally, I would say that if a person finds it important to get
 a library working with dmc/dmd, then it's worth investing in the
 digitalmars tools to give it a shot -- specifically the whole dmc compiler
 suite which is reasonably priced.


It certainly is.  The only other compiler I know of with a comparable 
price is Coumeau, and Coumeau is a C-front compiler.


 PS. I speak as one who bought the Digitalmars C/C++ compiler suite from
 Walter a few years ago.  I have no complaints about the quality of
 software, other than the feeling that some things are outdated.


I've got a CD as well, and I use DMC now for everything that doesn't 
require serious debugging (for that, I still use VC 2005).  If DMC had a 
quality debugger available, I'd need nothing else on Windows.


Sean
Feb 24 2007
parent reply Tyler Knott <tywebmail mailcity.com> writes:
Sean Kelly wrote:

 I've got a CD as well, and I use DMC now for everything that doesn't 
 require serious debugging (for that, I still use VC 2005).  If DMC had a 
 quality debugger available, I'd need nothing else on Windows.


You could try using DDbg.  Although it's intended for use with D code, it
should also support C code that has CodeView 
debugging information (such as that generated by DMC).  You can also use it
with the CodeBlocks IDE with the GDB 
emulation frontend.
Feb 24 2007
parent John Reimer <terminal.node gmail.com> writes:
On Sat, 24 Feb 2007 22:31:12 -0600, Tyler Knott wrote:


 Sean Kelly wrote:

 I've got a CD as well, and I use DMC now for everything that doesn't 
 require serious debugging (for that, I still use VC 2005).  If DMC had a 
 quality debugger available, I'd need nothing else on Windows.


 
 You could try using DDbg.  Although it's intended for use with D code, it
should also support C code that has CodeView 
 debugging information (such as that generated by DMC).  You can also use it
with the CodeBlocks IDE with the GDB 
 emulation frontend.



On a side note, I decided to try CodeBlocks again and was very surpised at
the beauty of it.  Looks like D found itself a place within a promising
IDE. Wow!  I think I've found my D IDE for windows.

Now all they need to do is get the Linux version up to date and
we'll have one impressive cross-platform D IDE.  Add to that the new DDbg
and everything is set (no DDbg for linux, though, sadly).

-JJR
Feb 24 2007
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:erqm3h$2a3$1 digitalmars.com...

 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!


Why is that free with the Linux distro, though?  :(
Feb 24 2007
parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Jarrett Billingsley wrote:

 Why is that free with the Linux distro, though?  :( 


The same reason the Linux kernel is free on Linux and closed-source on 
Windows.
Feb 25 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Julio César Carrascal Urquijo wrote:

 Jarrett Billingsley wrote:

 Why is that free with the Linux distro, though?  :( 


 
 The same reason the Linux kernel is free on Linux and closed-source on 
 Windows.


The Linux kernel is closed-source on Windows? I don't think so. You may 
need a cross-compiler to compile it, but it's still open-source.
Feb 25 2007
parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Frits van Bommel wrote:

 Julio César Carrascal Urquijo wrote:

 Jarrett Billingsley wrote:

 Why is that free with the Linux distro, though?  :( 


 The same reason the Linux kernel is free on Linux and closed-source on 
 Windows.


 
 The Linux kernel is closed-source on Windows? I don't think so. You may 
 need a cross-compiler to compile it, but it's still open-source.


I'm sorry. I meant:

The same reason the Linux kernel is free and the Windows Kernel is 
closed-source.

Damn dyslexia. ;)
Feb 25 2007
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 
 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!


I'd agree with that.


Sean
Feb 24 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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!


Chmod?  Worth $15?  By itself?? C'mon.  :-)

As for OBJ2ASM, that one I can believe is worth every penny to someone 
who actually understands ASM.  But to me it's about as useful as a slide 
rule.  libunres and patchobj seem to be similar situations.

The rest of the utilities look to be either ports of Unix-like tools 
(that are available for free from various other sources),  or duplicates 
of tools that come with Visual Studio (dumpexe/dumpobj==dumpbin).  Or 
just obsolete (flpyimg? who uses floppies any more?).

So in the end the only thing left that's of any interest to me (and I 
suspect not just me) is coff2omf.

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.

But anyway, after hearing more about the impossibility of successfully 
groking all purportedly COFF lib files, it seems to me that making DLL's 
is the best approach.

--bb
Feb 24 2007
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
On Sun, 25 Feb 2007 14:58:18 +0900, Bill Baxter wrote:



 
 But anyway, after hearing more about the impossibility of successfully 
 groking all purportedly COFF lib files, it seems to me that making DLL's 
 is the best approach.
 
 --bb



That was my conclusion, even though win32 DLL's are a headache in there
own right compared to elf shared libraries of other platforms.  At least
DLL's can be accessed regardless of format (as long as they are C based).

-JJR
Feb 24 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
John Reimer wrote:

 That was my conclusion, even though win32 DLL's are a headache in there
 own right compared to elf shared libraries of other platforms.  At least
 DLL's can be accessed regardless of format (as long as they are C based).


Windows DLL's are in Windows PE format. The file format used for object 
files has no relationship to it.
Feb 24 2007
parent John Reimer <terminal.node gmail.com> writes:
On Sat, 24 Feb 2007 23:02:20 -0800, Walter Bright wrote:


 John Reimer wrote:

 That was my conclusion, even though win32 DLL's are a headache in there
 own right compared to elf shared libraries of other platforms.  At least
 DLL's can be accessed regardless of format (as long as they are C based).


 
 Windows DLL's are in Windows PE format. The file format used for object 
 files has no relationship to it.



I don't know the specifics, obviously, of what makes a dll tick.  But I did
know it did not matter one iota, because we can load the symbols easily
enough with system calls.  So the result is the same :).

-JJR
Feb 24 2007
prev sibling next sibling parent Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 Chmod?  Worth $15?  By itself?? C'mon.  :-)


LOL, maybe not that one! But I kept chmod on after the o.s. attrib 
command helpfully stopped supporting manipulation of some of the file 
attributes.


 As for OBJ2ASM, that one I can believe is worth every penny to someone 
 who actually understands ASM.  But to me it's about as useful as a slide 
 rule.


Obj2asm is a great way to learn assembler. Compile some trivial 
functions with -g, then run obj2asm on the output, which will show lines 
of code and the corresponding generated asm. It won't be long before you 
get the hang of it.


 libunres and patchobj seem to be similar situations.


Those are real handy when you need them, which is fairly rare. I wrote 
them because I had a need for them.


 The rest of the utilities look to be either ports of Unix-like tools 
 (that are available for free from various other sources),  or duplicates 
 of tools that come with Visual Studio (dumpexe/dumpobj==dumpbin).


Try dumpexe/dumpobj - I think you'll find they are much better than 
dumpbin. dumpobj, for example, is especially good at pretty-printing 
dwarf debug info. dumpobj will also pretty-print codeview info - try 
that one with any other tool!


 Or just obsolete (flpyimg? who uses floppies any more?).


I wrote flpyimg just recently in order to back up my (old) floppies that 
had systems on them, to a CD/DVD/hard disk. Just copying the floppies 
skips the system files. Some of my very old floppies are no longer 
readable, so I wanted backups of what I could. You can put a thousand 
floppies on a CD, so there's no issue with storage space.

I learned long ago to keep backups even of obsolete junk, because having 
that old stuff has kept my legal backside out of the fire more than 
once. (I've been accused multiple times of basing my software on ripped 
off code, and every time I've been able to dig up a version that 
*predates* the accuser's development of the product. In one case, I even 
managed to prove the accuser's engineers had based their software on 
stuff ripped off from *me*! That was fun watching their lawyer run away. 
I had one customer refuse to pay me for a big job, claiming that they 
had "rewritten the code from scratch" and so didn't owe. Old backups 
once again showed that their "from scratch" code was about 95% identical 
to what I shipped them.)

Another reason to back up those floppies now is that floppy drives are 
starting to get scarce, especially 5.25" ones.



 So in the end the only thing left that's of any interest to me (and I 
 suspect not just me) is coff2omf.


Most people who buy the EUP do it for coff2omf.


 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.


It's not about the programming effort, it's about the value in the 
programs. chmod is handy, for example, because it'll give you a 
directory listing including the system and hidden files. whereis also 
ignores those attributes when looking for files, which is nice because 
Windows is always trying to hide important files, like the outlook 
express mail files, which evidently you shouldn't be allowed to back up 
(why I switched to thunderbird mail).

whereis is a very useful utility <g>. You could duplicate it in an hour 
or two, but what's your time worth to you? I use diffdir a lot to do bit 
compares (including hidden and system files) when I build a new DMC++ 
master CD, to verify that only the files I expected to change changed 
(handy when there are thousands of files to deal with). diffdir is a 
lifesaver for that.


 But anyway, after hearing more about the impossibility of successfully 
 groking all purportedly COFF lib files, it seems to me that making DLL's 
 is the best approach.
Feb 24 2007
prev sibling parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
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...
Feb 25 2007
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
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! :)

-JJR
Feb 25 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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! :)


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

--bb
Feb 25 2007
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
On Mon, 26 Feb 2007 02:27:26 +0900, Bill Baxter 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! :)


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



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

-JJR
Feb 25 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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.
Feb 25 2007
parent reply Sean Kelly <sean f4.ca> writes:
Frits van Bommel wrote:

 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.


The download is still available, but the project seems to have been 
abandoned.  I switched to GnuWin32 recently and think it's much better, 
if a tad unwieldy.  An accompanying download app called GetGnuWin32 is 
the best way to deal with installing those tools.


Sean
Feb 25 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Sean Kelly wrote:

 Frits van Bommel wrote:

 John Reimer wrote:

 On Mon, 26 Feb 2007 02:27:26 +0900, Bill Baxter wrote:


 http://unxutils.sourceforge.net/ .








[snip]

 Apparently the .zip containing them is a dead link now, though.




[snip]

 
 The download is still available,


I just tried again:
---
Forbidden
You don't have permission to access /UnxUtils.zip on this server.

Apache/1.3.33 Server at unxutils.sourceforge.net Port 80
---
and:
---
Forbidden
You don't have permission to access /UnxUpdates.zip on this server.

Apache/1.3.33 Server at unxutils.sourceforge.net Port 80
---

And the downloads section of the project page at sourceforge is empty...


Not that I particularly care now that I'm running Linux.
Feb 25 2007
parent Sean Kelly <sean f4.ca> writes:
Frits van Bommel wrote:

 Sean Kelly wrote:

 Frits van Bommel wrote:

 John Reimer wrote:

 On Mon, 26 Feb 2007 02:27:26 +0900, Bill Baxter wrote:


 http://unxutils.sourceforge.net/ .








 [snip]

 Apparently the .zip containing them is a dead link now, though.




 [snip]

 The download is still available,


 
 I just tried again:
 ---
 Forbidden
 You don't have permission to access /UnxUtils.zip on this server.
 
 Apache/1.3.33 Server at unxutils.sourceforge.net Port 80


Ah well.  I haven't tried downloading this for a few months.  I guess 
the link has died since then.


Sean
Feb 25 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:

 Frits van Bommel wrote:

 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.




Too bad.  I downloaded it for the first time only a month or so ago.


 
 The download is still available, but the project seems to have been 
 abandoned.  


Yeh, last update is 2003.  But heck that's ok by me, grep and ls haven't 
changed all that much in the intervening 4 years.




 I switched to GnuWin32 recently and think it's much better, 
 if a tad unwieldy.  An accompanying download app called GetGnuWin32 is 
 the best way to deal with installing those tools.


I was hoping GetGnuWin32 was going to be a thing that let me click a box 
to select "Executables only", but it turns out it's just a batch script 
that wgets everything indiscriminately.

--bb
Feb 25 2007
parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:

 
 I was hoping GetGnuWin32 was going to be a thing that let me click a box 
 to select "Executables only", but it turns out it's just a batch script 
 that wgets everything indiscriminately.


Sadly, yes.  But once it's created the directory tree for you it's easy 
enough to just delete contrib, include, lib, etc.


Sean
Feb 25 2007
prev sibling parent reply torhu <fake address.dude> writes:
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/
Feb 25 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 25 2007
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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 ;).
Feb 25 2007
parent reply John Reimer <terminal.node gmail.com> writes:
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
Feb 25 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 25 2007
parent John Reimer <terminal.node gmail.com> writes:
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
Feb 25 2007
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 25 2007
prev sibling parent reply torhu <fake address.dude> writes:
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.
Feb 25 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 25 2007