as above,
if we know how to import a dll to lib,
we can do more things than just get a CD
and download updates.

Who can tell us how to do it?

Implib'ing the dll will work for most. The only ones it won't work for are the ones Microsoft stripped the @n suffix off of. For those, which are only the system dll's, we have them and can forward them to you (they're on the CD anyway). Or, you can build them with IMPLIB and a module definition file.

danny wrote in message <9j9ccg$1mlh$1@digitaldaemon.com>...
>as above,
>if we know how to import a dll to lib,
>we can do more things than just get a CD
>and download updates.
>
>Who can tell us how to do it?
>
>

Thanks for reply.
And can you send me a copy of gdi32.lib to this addr:
ningyuan@21cn.com.
and it is very kind of you if you can include this file
into next downloadable version.

> Implib'ing the dll will work for most. The only ones it won't work for are the ones Microsoft stripped the @n suffix off of. For those, which are
only
> the system dll's, we have them and can forward them to you (they're on the CD anyway). Or, you can build them with IMPLIB and a module definition
file.
>
> danny wrote in message <9j9ccg$1mlh$1@digitaldaemon.com>...
> >as above,
> >if we know how to import a dll to lib,
> >we can do more things than just get a CD
> >and download updates.
> >
> >Who can tell us how to do it?
> >
> >
>
>

I realize that this is an extremely old thread, as things go, but I have recently run into the same problem with a less standard DLL.  In particular, I am trying to use GLUT for some simple OpenGL programming.  I have glut32.dll and even an MSVC ready glut32.lib, but the names do not have the @n suffix.

While it might be possible to ask you to generate a usable .LIB for me to download, I will just need to do it again at some point in the future when my GLUT 3.7beta DLLs become GLUT 3.7release DLLs (and so on for 3.8, etc).  This does not seem especially reasonable.

Worse, if I were to suggest using DMC at work, I would need to deal with the fact that we use various third party DLLs as well as in-house DLLs.  The in-house DLLs tend to be components of device drivers, and are not easily portable between compilers.  We might not have sufficient rights on the third-party DLLs to ship them to you for .LIB creation.

Possible workarounds that I can think of:
1. Modify IMPLIB to add the @n suffix -- may not be possible if DLL
does not include sufficient function parameter information, or if
IMPLIB source code is not available to you.

2. Provide an OPTLINK switch that will allow a second lookup pass for unrecognized symbols -- in the second pass it could strip any @n suffix from the symbol and see if it can find the resulting symbol.

3. Provide a compiler pragma that would allow signalling that some functions should not be mangled with the @n suffix.  This would need to work like the 'extern "C" { ... }' system so that it could be wrapped around an #include line, like this:

#pragma MangleWithStackDepth(off)
#include <GL/glut.h>
#pragma MangleWithStackDepth(on)

The problem with this is that the compiler must then somehow remember this when it later encounters the symbols that were declared in the #include.  Not being a compiler writer myself, and not being privy to the DMC++ internals, I have no idea how easy/hard this would be.


My personal preference is for the first option (IMPLIB modification) if it is at all possible.  That solution would allow users to "fix" the problem once and only once when they import the DLL.  The other two options require a fix each time a difficult DLL needs to be used. This is hardly crippling, though you might want to reference the "How-to" in the linker error message, since the solution would be less than immediately obvious...   If the first option is not viable, I would probably vote for option 3, since it is both more explicit and removes the need for two-pass linking.

Any hopes of one of the above changes occurring in the near future?
Waiting hopefully,
Mac


On Fri, 20 Jul 2001 08:22:17 -0700, "Walter" <walter@digitalmars.com> wrote:

>Implib'ing the dll will work for most. The only ones it won't work for are the ones Microsoft stripped the @n suffix off of. For those, which are only the system dll's, we have them and can forward them to you (they're on the CD anyway). Or, you can build them with IMPLIB and a module definition file.
>
>danny wrote in message <9j9ccg$1mlh$1@digitaldaemon.com>...
>>as above,
>>if we know how to import a dll to lib,
>>we can do more things than just get a CD
>>and download updates.
>>
>>Who can tell us how to do it?
>>
>>
>
>

The problem is not stripping off the @n, the problem is adding it back on when the tools have no way of knowing what value to use for n. Modifying implib will not help because implib cannot add information it does not have.

The solution is tedious - make a .def file that equates the @n version with the no-suffix version, and run implib on that. What the @n should be can be determined by writing a simple C test source that calls each function, compile it, and run libunres on it to get all the unresolved names.

It's a mystery to me why Microsoft defined stdcall as having an @n suffix, but stripped the suffix out of the system DLLs. This causes endless problems that didn't have to be.

"Mac Reiter" <reiter@nomadics.com> wrote in message news:3c55b348.339592227@news.digitalmars.com...
> I realize that this is an extremely old thread, as things go, but I have recently run into the same problem with a less standard DLL.  In particular, I am trying to use GLUT for some simple OpenGL programming.  I have glut32.dll and even an MSVC ready glut32.lib, but the names do not have the @n suffix.
>
> While it might be possible to ask you to generate a usable .LIB for me to download, I will just need to do it again at some point in the future when my GLUT 3.7beta DLLs become GLUT 3.7release DLLs (and so on for 3.8, etc).  This does not seem especially reasonable.
>
> Worse, if I were to suggest using DMC at work, I would need to deal with the fact that we use various third party DLLs as well as in-house DLLs.  The in-house DLLs tend to be components of device drivers, and are not easily portable between compilers.  We might not have sufficient rights on the third-party DLLs to ship them to you for .LIB creation.
>
> Possible workarounds that I can think of:
> 1. Modify IMPLIB to add the @n suffix -- may not be possible if DLL
> does not include sufficient function parameter information, or if
> IMPLIB source code is not available to you.
>
> 2. Provide an OPTLINK switch that will allow a second lookup pass for unrecognized symbols -- in the second pass it could strip any @n suffix from the symbol and see if it can find the resulting symbol.
>
> 3. Provide a compiler pragma that would allow signalling that some functions should not be mangled with the @n suffix.  This would need to work like the 'extern "C" { ... }' system so that it could be wrapped around an #include line, like this:
>
> #pragma MangleWithStackDepth(off)
> #include <GL/glut.h>
> #pragma MangleWithStackDepth(on)
>
> The problem with this is that the compiler must then somehow remember this when it later encounters the symbols that were declared in the #include.  Not being a compiler writer myself, and not being privy to the DMC++ internals, I have no idea how easy/hard this would be.
>
>
> My personal preference is for the first option (IMPLIB modification) if it is at all possible.  That solution would allow users to "fix" the problem once and only once when they import the DLL.  The other two options require a fix each time a difficult DLL needs to be used. This is hardly crippling, though you might want to reference the "How-to" in the linker error message, since the solution would be less than immediately obvious...   If the first option is not viable, I would probably vote for option 3, since it is both more explicit and removes the need for two-pass linking.
>
> Any hopes of one of the above changes occurring in the near future?
> Waiting hopefully,
> Mac
>
>
> On Fri, 20 Jul 2001 08:22:17 -0700, "Walter" <walter@digitalmars.com> wrote:
>
> >Implib'ing the dll will work for most. The only ones it won't work for
are
> >the ones Microsoft stripped the @n suffix off of. For those, which are
only
> >the system dll's, we have them and can forward them to you (they're on
the
> >CD anyway). Or, you can build them with IMPLIB and a module definition
file.
> >
> >danny wrote in message <9j9ccg$1mlh$1@digitaldaemon.com>...
> >>as above,
> >>if we know how to import a dll to lib,
> >>we can do more things than just get a CD
> >>and download updates.
> >>
> >>Who can tell us how to do it?
> >>
> >>
> >
> >
>

On Mon, 28 Jan 2002 16:48:34 -0800, "Walter" <walter@digitalmars.com> wrote:

>The problem is not stripping off the @n, the problem is adding it back on when the tools have no way of knowing what value to use for n. Modifying implib will not help because implib cannot add information it does not have.
>
>The solution is tedious - make a .def file that equates the @n version with

[clip]

After reading various other posts here, I tried something that Jan mentioned (that had not worked for the original poster, but fortunately did work for me) -- COFF2OMF.  The DLL I was trying to use came with an MSVC-oriented .LIB file, which seemed to work just fine after running COFF2OMF on it.

It might be worthwhile to add a page to the "Compiler & Tools Guide" html pages mentioning COFF2OMF.  Currently the only tool mentioned for bringing in 3rd part stuff is IMPLIB.  If COFF2OMF had been there, I probably would have stumbled across it in my search for conversion tools.

Now that I can link, I have encountered a variety of other problems, but they don't fit this thread, so I will post them to the appropriate sub-groups

Mac

"Mac Reiter" <reiter@nomadics.com> wrote in message news:3c56cee5.412196777@news.digitalmars.com...
> It might be worthwhile to add a page to the "Compiler & Tools Guide" html pages mentioning COFF2OMF.  Currently the only tool mentioned for bringing in 3rd part stuff is IMPLIB.  If COFF2OMF had been there, I probably would have stumbled across it in my search for conversion tools.

Good idea. Done!