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

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

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

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

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.

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.

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

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.

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.

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