Walter Bright wrote:
> "Todor Totev" <umbra.tenebris@list.ru> wrote in message news:op.s2jo0pu7ihwmk4@todor-1-xp.sanbolic.local...
> 
>>Carlos, I tried to present a problem where I have a real-world problem and
>>a valid programme to solve it which is not well handled by the existing
>>Dmd infrastructure.
> 
> 
> I appreciate your long and detailed post illustrating the difficulties you're having, and how you got around them. Your concerns are real, and we need to address them.
> 
> 
>>I really can't explain why I missed the debugger related pages.
> 
> 
> The problem with newer Windbg's from Microsoft is that it can no longer read Microsoft codeview debug information. The old Windbg does work with codeview debug data, it does see local variables in D and D class members. It comes on the Digital Mars CD.
> 
> 
>>I still miss the ability to conviniently use existing lib files but will
>>look at build and try to patch it so it starts speaking the language of
>>Watcom's wlink.
> 
> 
> Writing a utility to convert Microsoft's dll import libraries to a module definition file, which can then be fed through implib to create an OMF import library, wouldn't be hard. It just takes someone to sit down and do it. Want to take a stab at it?
> 
> 
> 

Eric's DDL is the place to start probably. Check it out at dsource.org

It all revolves about resources available. Go start a company, hire 200 employees and soon (in a year or 2) you will have a perfect working environment with IDE, debugger etc. Or maybe not.

And then we shall see who will pay for it. Did you pay for your MSVC? I haven't - i have mine from the MS university support programme. I wouldn't be able to afford it myself. And don't let fool yourself my MS giving from time to time limited working versions of their software: in the long run, they have to pay their deveopment costs. The situation is not much different in the world of free software: it is being developed by companies with large commercial interest - sometimes it just makes more sense to improve a free product for everyone than to license a commercial one. If not for Apple, IBM and many other giants, there would be no GCC, no Gnome, no KDE, no high-performance free unix clones. Free software would not have evolved to be an alternative to commercial software in many areas it has become.

So saying "MSVC is so much better" is cynical at best. Also, consider: did you have your first MSVC programme running within minutes? Did you find the documentation, the header files at once? Did you know what every element of an IDE does by just looking at it for the first time?

-eye

Ilya Minkov wrote:

> And then we shall see who will pay for it. Did you pay for your MSVC? I haven't - i have mine from the MS university support programme. I wouldn't be able to afford it myself. And don't let fool yourself my MS giving from time to time limited working versions of their software: in the long run, they have to pay their deveopment costs.

> -eye

MS don't do this to earn money on the development software itself, it is all a part of the strategy to tie the developers into creating software for Windows. The more exclusive Windows software, the more money to MS. It is their absurdly huge income from Windows, Office and different server products that fund the development of hugely productive tools. Now, I think I recently heard that such type of tools (highly productive 4th generation stuff) makes the developer less aware of issues related to code quality, and even reuse, that these tools in theory should support. I certainly know that these tools hide quite a lot of the details that interest _me_, and unless you are a wizz at the tool itself, it becomes quite troublesome to debug problems in the toolchain.

And I suppose this is offtopic...

Lars Ivar Igesund

"Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:dp8qkr$3tt$1@digitaldaemon.com...
> Ilya Minkov wrote:
>
> > And then we shall see who will pay for it. Did you pay for your MSVC? I haven't - i have mine from the MS university support programme. I wouldn't be able to afford it myself. And don't let fool yourself my MS giving from time to time limited working versions of their software: in the long run, they have to pay their deveopment costs.
>
> > -eye
>
> MS don't do this to earn money on the development software itself, it is
all
> a part of the strategy to tie the developers into creating software for Windows. The more exclusive Windows software, the more money to MS. It is their absurdly huge income from Windows, Office and different server products that fund the development of hugely productive tools. Now, I
think
> I recently heard that such type of tools (highly productive 4th generation stuff) makes the developer less aware of issues related to code quality, and even reuse, that these tools in theory should support. I certainly
know
> that these tools hide quite a lot of the details that interest _me_, and unless you are a wizz at the tool itself, it becomes quite troublesome to debug problems in the toolchain.
>
> And I suppose this is offtopic...

Not at all. Interesting, apposite, and, to the best of my understanding, correct. :-)

Matthew wrote:
> "Lars Ivar Igesund" <larsivar@igesund.net> wrote in message

[...]

>>I recently heard that such type of tools (highly productive 4th generation
>>stuff) makes the developer less aware of issues related to code quality,
>>and even reuse, that these tools in theory should support. I certainly know
>>that these tools hide quite a lot of the details that interest _me_, and
>>unless you are a wizz at the tool itself, it becomes quite troublesome to
>>debug problems in the toolchain.
>>
>>And I suppose this is offtopic...
> 
> Not at all. Interesting, apposite, and, to the best of my understanding,
> correct. :-)

While drifting offtopic, i recalled a recent essay by Charles Petzold, who has been writing popular books on Windows programming back when i was a kid poking around on a ZX-Spectrum clone.

http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.html

-i.

"Todor Totev" <umbra.tenebris@list.ru> wrote in message news:op.s2f8okolihwmk4@todor-1-xp.sanbolic.local...
>   2.2. The libraries included are old. Outdated. Unusable to me. And I
> even
>        didn't try to use Transactional NTFS functions from Vista beta
> WDK/SDK.
>        Plain old, boring Windows 2000/XP functions (5 years old, mind
> this)
>        are nowhere to be seen. Functions like FindFirstVolumeMountPoint
>        or GetVolumePathNamesForVolumeName.
>   2.3. No out-of-box support for lib files coming with SDK/DDK/IFS/WDK.
>   2.4. No implib functionality so I cannot create up-to date lib files
>        from the dll files.

This problem is now resolved with the coffimplib utility.

Maybe I am wrong, but I understand that:
-implib/coffimplib are required to generate a .lib file from a .dll to be linked
with dmd generated code.
I wanted to ask if would be possible to directly integrate this into the linker,
so one could directly pass the .dll in command line. Maybe something like this:
http://www.jorgon.freeserve.co.uk/#linker
So, if .lib can be generated from .dll to be linked with, why use .lib at all?

F



In article <dpc8b3$29li$1@digitaldaemon.com>, Walter Bright says...
>
>"Todor Totev" <umbra.tenebris@list.ru> wrote in message news:op.s2f8okolihwmk4@todor-1-xp.sanbolic.local...
>>   2.2. The libraries included are old. Outdated. Unusable to me. And I
>> even
>>        didn't try to use Transactional NTFS functions from Vista beta
>> WDK/SDK.
>>        Plain old, boring Windows 2000/XP functions (5 years old, mind
>> this)
>>        are nowhere to be seen. Functions like FindFirstVolumeMountPoint
>>        or GetVolumePathNamesForVolumeName.
>>   2.3. No out-of-box support for lib files coming with SDK/DDK/IFS/WDK.
>>   2.4. No implib functionality so I cannot create up-to date lib files
>>        from the dll files.
>
>This problem is now resolved with the coffimplib utility.
>
>

"F" <F_member@pathlink.com> wrote in message news:dpeeth$mvs$1@digitaldaemon.com...
> Maybe I am wrong, but I understand that:
> -implib/coffimplib are required to generate a .lib file from a .dll to be
> linked
> with dmd generated code.
> I wanted to ask if would be possible to directly integrate this into the
> linker,
> so one could directly pass the .dll in command line. Maybe something like
> this:
> http://www.jorgon.freeserve.co.uk/#linker
> So, if .lib can be generated from .dll to be linked with, why use .lib at
> all?

Good question. The answer is that Microsoft set up the system dlls with names that *DO NOT MATCH* the names generated by the C compiler. Yes, you heard that right! So, simply scanning the system dlls does not give enough information.

The import library provides a translation between the 'internal name' and the 'external name'. The former is missing from the dll's.

Walter Bright wrote:
> "F" <F_member@pathlink.com> wrote in message news:dpeeth$mvs$1@digitaldaemon.com...
> 
>>Maybe I am wrong, but I understand that:
>>-implib/coffimplib are required to generate a .lib file from a .dll to be linked
>>with dmd generated code.
>>I wanted to ask if would be possible to directly integrate this into the linker,
>>so one could directly pass the .dll in command line. Maybe something like this:
>>http://www.jorgon.freeserve.co.uk/#linker
>>So, if .lib can be generated from .dll to be linked with, why use .lib at all?
> 
> 
> Good question. The answer is that Microsoft set up the system dlls with names that *DO NOT MATCH* the names generated by the C compiler. Yes, you heard that right! 

Heard what now? =P

> So, simply scanning the system dlls does not give enough information.
> 
> The import library provides a translation between the 'internal name' and the 'external name'. The former is missing from the dll's. 
> 

That is seriously messed up.

Walter Bright wrote:
>>So, if .lib can be generated from .dll to be linked with, why use .lib at all?
> 
> Good question. The answer is that Microsoft set up the system dlls with names that *DO NOT MATCH* the names generated by the C compiler. Yes, you heard that right! So, simply scanning the system dlls does not give enough information.
> 
> The import library provides a translation between the 'internal name' and the 'external name'. The former is missing from the dll's. 

This is one of the (rare) cases where I prefer the original VB solution: specify the external name as a alias when defining the function. So that the names are in a human-readable header file, instead of yet another complex binary file format.

The thing I really don't understand is why Microsoft changed the definition of __declspec(export) with extern "C" in VC++ so that it didn't disable name mangling. When they first introduced __declspec(export), you could create DLLs that didn't need DEF files or implibs. It was fabulous. With the next compiler release, it was back to the Bad Old Days. I think that was the release where they removed 80-bit reals, too.

They've made some really strange decisions over the years. I wonder if internal politics are involved.