www.digitalmars.com         C & C++   DMDScript  

c++.windows.32-bits - how to import a usable lib?

reply "danny" <danny bj.col.com.cn> writes:
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?
Jul 20 2001
parent reply "Walter" <walter digitalmars.com> writes:
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?
Jul 20 2001
next sibling parent "danny" <danny bj.col.com.cn> writes:
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




 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




 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?
Jul 20 2001
prev sibling parent reply reiter nomadics.com (Mac Reiter) writes:
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?
Jan 28 2002
parent reply "Walter" <walter digitalmars.com> writes:
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







the ones Microsoft stripped the  n suffix off of. For those, which are







the system dll's, we have them and can forward them to you (they're on







CD anyway). Or, you can build them with IMPLIB and a module definition







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?
Jan 28 2002
parent reply reiter nomadics.com (Mac Reiter) writes:
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
Jan 29 2002
parent "Walter" <walter digitalmars.com> writes:
"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!
Jan 30 2002