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.



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

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 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
parent 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
prev sibling next 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 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.

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.

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

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.

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

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 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
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 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 next sibling parent 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
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 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.

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




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


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




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


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

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

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


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
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
prev sibling next sibling parent 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
prev sibling next 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 next sibling 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 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling 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 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
prev sibling next 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 next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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.

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
prev sibling next sibling parent 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.

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
prev sibling next sibling 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 next sibling 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.

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


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 next sibling 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 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