On Jul 22, 2012, at 6:12 AM, "Stuart" <stugol@gmx.com> wrote:

> On Sunday, 22 July 2012 at 07:01:50 UTC, Walter Bright wrote:
>> This is a very old issue. To be compatible with the output of the Microsoft C compiler, the Windows calling convention is:
>> 
>>   _name@nn
>> 
>> but somehow Microsoft left off the _ and @nn in the DLLs. Hence, part of the whole reason for the import libraries is then to provide a mapping of _name@nn => name.
>> 
>> I have no idea who made this decision and why, but we're stuck with it.
> 
> Okay, but if you had a keyword - say, "extern(rawC)" - that did no mangling whatsoever, then I could run implib without manually editing every single damn line in every Microsoft .def file by hand!!! Surely that's a good idea?
> 
> I don't know why implib is ignoring the /s switch, but it is. My .lib file doesn't have underscores, and there doesn't seem to be much I can do about it. Do I need a different version of implib or something? Shouldn't the /s switch add underscores to everything?

I think there's definitely some use in being able to specify a symbol name as a string, both for aliasing external symbols and overriding name mangling of internal symbols.

On 2012-07-22 15:12, Stuart wrote:

> I don't know why implib is ignoring the /s switch, but it is. My .lib
> file doesn't have underscores, and there doesn't seem to be much I can
> do about it. Do I need a different version of implib or something?
> Shouldn't the /s switch add underscores to everything?

I used it a couple of weeks ago and it worked.

-- 
/Jacob Carlborg

On 7/22/2012 6:12 AM, Stuart wrote:
> Okay, but if you had a keyword - say, "extern(rawC)" - that did no mangling
> whatsoever, then I could run implib without manually editing every single damn
> line in every Microsoft .def file by hand!!! Surely that's a good idea?

I agree, it's a pain, and a pointless one at that.

> I don't know why implib is ignoring the /s switch, but it is. My .lib file
> doesn't have underscores, and there doesn't seem to be much I can do about it.
> Do I need a different version of implib or something? Shouldn't the /s switch
> add underscores to everything?

There's no magical way for implib to figure out what the nn in @nn must be.

On Monday, 23 July 2012 at 06:28:56 UTC, Jacob Carlborg wrote:
> On 2012-07-22 15:12, Stuart wrote:
>
>> I don't know why implib is ignoring the /s switch, but it is.
>
> I used it a couple of weeks ago and it worked.

Oh, well, I guess that makes it alright, huh? I guess I must just be an idiot, or hallucinating, yeah?

Alternatively, you could take my word for it when I say it ain't working, and offer some kind of constructive advice.

On Monday, 23 July 2012 at 06:44:22 UTC, Walter Bright wrote:
> On 7/22/2012 6:12 AM, Stuart wrote:
>> Okay, but if you had a keyword - say, "extern(rawC)" - that did no mangling
>> whatsoever, then I could run implib without manually editing every single damn
>> line in every Microsoft .def file by hand!!! Surely that's a good idea?
>
> I agree, it's a pain, and a pointless one at that.
>
>> I don't know why implib is ignoring the /s switch, but it is. My .lib file
>> doesn't have underscores, and there doesn't seem to be much I can do about it.
>> Do I need a different version of implib or something? Shouldn't the /s switch
>> add underscores to everything?
>
> There's no magical way for implib to figure out what the nn in @nn must be.

Granted, but IMPLIB IS NOT PREFIXING THE NAMES WITH AN UNDERSCORE, even when used with the /s switch. Hello? Houston? Am I getting through?

In any case, adding support for importing unmangled function names in D would help in these cases; and also allow us to import unmangled functions that were exported from C using the "extern C" instruction in C++.

Correct me if I'm wrong, but isn't it only C++ that does mangling? As I recall, straight C doesn't support overloading and doesn't mangle names. Therefore, I reckon your "extern (C)" instruction ought instead to be written "extern (C++)", and a new "extern (C)" should be introduced that does no name mangling. Alternatively, I may be wrong, but even so, a non-mangling keyword would be helpful. And surely it wouldn't be difficult to implement?

"Stuart" <stugol@gmx.com> wrote in message news:hcrszoaeyauztrlpifgu@forum.dlang.org...
> Correct me if I'm wrong, but isn't it only C++ that does mangling?

You're wrong.

On Monday, 23 July 2012 at 14:08:39 UTC, Daniel Murphy wrote:
> "Stuart" <stugol@gmx.com> wrote in message
> news:hcrszoaeyauztrlpifgu@forum.dlang.org...
>> Correct me if I'm wrong, but isn't it only C++ that does mangling?
>
> You're wrong.

Fair enough. But there are still times when we need a version of "export" that doesn't mangle.

On Monday, 23 July 2012 at 17:25:43 UTC, Stuart wrote:
> Fair enough. But there are still times when we need a version of "export" that doesn't mangle.

No. This is even impossible to do with some compiler backends. For example, LLVM on OS X automatically appends an underscore to the beginning of symbol names, because every C function has an »extra« underscore at the beginning there.

David

On Monday, 23 July 2012 at 17:28:38 UTC, David Nadlinger wrote:
> On Monday, 23 July 2012 at 17:25:43 UTC, Stuart wrote:
>> Fair enough. But there are still times when we need a version of "export" that doesn't mangle.
>
> No. This is even impossible to do with some compiler backends. For example, LLVM on OS X automatically appends an underscore to the beginning of symbol names, because every C function has an »extra« underscore at the beginning there.

I mean for importing. The functions in shlwapi.lib don't have underscores. We ought to have some kind of syntax for importing them without faffing about with .def files. Surely it must be possible?

On Monday, 23 July 2012 at 20:57:37 UTC, Stuart wrote:
> On Monday, 23 July 2012 at 17:28:38 UTC, David Nadlinger wrote:
>> On Monday, 23 July 2012 at 17:25:43 UTC, Stuart wrote:
>>> Fair enough. But there are still times when we need a version of "export" that doesn't mangle.
>>
>> No. This is even impossible to do with some compiler backends. For example, LLVM on OS X automatically appends an underscore to the beginning of symbol names, because every C function has an »extra« underscore at the beginning there.
>
> I mean for importing. The functions in shlwapi.lib don't have underscores. We ought to have some kind of syntax for importing them without faffing about with .def files. Surely it must be possible?

Hi Stuart.

If you have the Windows SDK you can run

coffimplib "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\shlwapi.lib" C:\D\dmd2\windows\lib\shlwapi.lib

We could run coffimplib on *.lib from the Windows SDK and include the resulting OMF libraries on the dmd.zip package. I don't know if it is 'legal'.