Re: [Mingw-users] MSVC DLL to LIB Problem

[Wu Y. <ad...@ne...>]

Zac Corbet wrote:

> Hello,
> 
> This might seem like a very newbie question, and that is because it
> is. I just started using MinGW and have never really worked with DLLs
> much either prior to this.  I have searched the archive and the FAQ
> and documentation for help on this issue and haven't found anything
> to solve my problem.  So if the answer is out there somewhere, I just
> missed it, so please be patient.  So here is my problem:
> 
> I am taking a program someone wrote in Linux w/ GCC and trying to put
> it into a program/system for Windows.  This is what I was told to do,
> don't ask me why they would want to do it.  Well, I got MinGW
> installed so that I could compile the program properly in Windows.
> Now the next step is writing the wrappers to allow this program to
> interact with the larger system.
> 
> My problem is that the API I was given is in DLLs and the only thing 
> that I have received are the DLLs.  No LIB or DEF files or anything 
> else, just the DLLs.  So, in order to get it to work with MinGW code,

Was this DLL created by your company? If so, definitely you should be 
able to ask them for the DEF file.

> it is my understanding that I need to get the lib file out of it.  So
> checking the FAQs on the MinGW site, I tried using pexports to get a
> def file out of it.  The problem is, the def file comes out empty.
> 
> $ pexports -v FRAMES2_DataSet.dll ;    .text: RVA: 00001000, File
> offset: 00001000 ;   .rdata: RVA: 0000a000, File offset: 0000a000 ;
> .data: RVA: 0000c000, File offset: 0000c000 ;   .reloc: RVA:
> 0000e000, File offset: 0000d000
> 
> This lead me to try the program called DUMPBIN and got the following:
> 
> 
> Microsoft (R) COFF/PE Dumper Version 7.10.2240.8 Copyright (C)
                                        ^^^^^^^^^^^
This line and the result from pexports implies that maybe MSVC 7.1 has 
changed the DLL format a little. It is probable that MinGW has not been 
fully tested with it (the FAQ and my article are about MSVC 6).

> Microsoft Corporation.  All rights reserved.
> 
> 
> Dump of file FRAMES2_DataSet.dll
> 
> File Type: DLL
> 
> Summary
> 
> 2000 .data 2000 .rdata 1000 .reloc 9000 .text
> 
> 
> But, when I ran DUMPBIN checking for the IMPORTS instead of EXPORTS,
> I got a full list of functions matching what I should have in this

This is definitely the problem and make my above statements invalid. You 
should check for EXPORTS only. EXPORTS are what is implemented in the 
DLL for others to use, while IMPORTS are what the DLL needs. From the 
IMPORTS information you can also see which DLL provides the 
implementation. E.g.

Dump of file PCDLIB32.DLL

File Type: DLL

   Section contains the following imports:

     KERNEL32.dll
               10046188 Import Address Table
               10046058 Import Name Table
                      0 time date stamp
                      0 Index of first forwarder reference

                   17  CloseHandle
                  145  GlobalHandle
                  ...

This shows that PCDLIB32.DLL needs KERNEL32.dll to provide CloseHandle 
etc. in order to work. If "dumpbin /exports FRAMES2_DataSet.dll" shows 
nothing, I doubt even MSVC programs can work with it.

> library based on the documentation of the API.  Maybe I am just being
> rather stupid about DLLs in general, since I don't really know much
> about them at all, but this is confusing me.  Given just a DLL, how
> can I go about using it in a MinGW program to create wrappers?  I
> hope someone can help me figure out my problem.

Aaron has mentioned the basic means of creating DEF file yourself. Some 
more hints follows:

1. This sed command might help you create the list of exported names (if 
the DLL is OK):

    dumpbin /exports FRAMES2_DataSet.dll |
sed -n "s/^ *[[:digit:]]\+ *[[:xdigit:]]\+ [[:xdigit:]]
\+ \([[:alnum:]_]\)/\1/p"

(Join 3 lines into one with no extra space between them.)

2. Every method mentioned here does not work for C++ interfaces.

3. You might be unlucky if "managed code" or other Microsoft-specific 
stuff is used in the DLL.

Best regards,

Wu Yongwei