Thread: dllimport

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    dllimport

    Hello everyone,


    For dllimport KB from Microsoft,

    http://support.microsoft.com/kb/132044/en-us

    It is mentioned,

    --------------------
    If 'func1' exists in another DLL, the linker can't resolve this directly because it has no way of knowing what the address of 'func1' is.
    --------------------

    My question is, if we are using implicit linking, the address of import function should be in the import library (.lib file) of the DLL and since the import library is as an input parameter to linker, the linker should know the address at link time?


    thanks in advance,
    George

  2. #2
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    No, the import library contains stubs that forward to the DLL function. Otherwise, you couldn't replace the DLL if you're doing implicit linking, defeating one of the important advantages of DLLs.

    Take a look at this:
    http://blogs.msdn.com/oldnewthing/ar...27/680250.aspx
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  3. #3
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Hi CornedBee,


    The page looks good and informative, but it contains information about various version of system of the following topics.

    To understand your points and have a common reference, it is appreciated if you could point out which of the following items do you refer?

    How were DLL functions exported in 16-bit Windows?
    How were DLL functions imported in 16-bit Windows?
    How are DLL functions exported in 32-bit Windows?
    Exported functions that are really forwarders
    Rethinking the way DLL exports are resolved for 32-bit Windows
    Calling an imported function, the naive way
    How a less naive compiler calls an imported function
    Issues related to forcing a stub to be created for an imported function
    What happens when you get dllimport wrong?
    Names in the import library are decorated for a reason
    The dangers of dllexport (bonus posting from a few years ago)

    Quote Originally Posted by CornedBee View Post
    No, the import library contains stubs that forward to the DLL function. Otherwise, you couldn't replace the DLL if you're doing implicit linking, defeating one of the important advantages of DLLs.

    Take a look at this:
    http://blogs.msdn.com/oldnewthing/ar...27/680250.aspx

    regards,
    George

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    All of them. The articles are all part of a series that offers valuable information about dynamic linking.

    But the specific answer to your question is found in articles 5 through 7.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #5
    Registered User
    Join Date
    Mar 2005
    Location
    Mountaintop, Pa
    Posts
    1,058
    Read this MSDN article. Specifically....

    It's interesting to note that in Microsoft-produced PE files, the import table is not something wholly synthesized by the linker. All the pieces necessary to call a function in another DLL reside in an import library. When you link a DLL, the library manager (LIB32.EXE or LIB.EXE) scans the OBJ files being linked and creates an import library. This import library is completely different from the import libraries used by 16-bit NE file linkers. The import library that the 32-bit LIB produces has a .text section and several .idata$ sections. The .text section in the import library contains the JMP DWORD PTR [XXXXXXXX] thunk, which has a name stored for it in the OBJ's symbol table. The name of the symbol is identical to the name of the function being exported by the DLL (for example, _Dispatch_Message@4). One of the .idata$ sections in the import library contains the DWORD that the thunk dereferences through. Another of the .idata$ sections has a space for the hint ordinal followed by the imported function's name. These two fields make up an IMAGE_IMPORT_BY_NAME structure. When you later link a PE file that uses the import library, the import library's sections are added to the list of sections from your OBJs that the linker needs to process. Since the thunk in the import library has the same name as the function being imported, the linker assumes the thunk is really the imported function, and fixes up calls to the imported function to point at the thunk. The thunk in the import library is essentially "seen" as the imported function.

    Besides providing the code portion of an imported function thunk, the import library provides the pieces of the PE file's .idata section (or import table). These pieces come from the various .idata$ sections that the library manager put into the import library. In short, the linker doesn't really know the differences between imported functions and functions that appear in a different OBJ file. The linker just follows its preset rules for building and combining sections, and everything falls into place naturally.

  6. #6
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    After reading them, I have a question for a normal function call, what assembly code will be generated by the compiler? I can not imagine what the compiler will generate, which the link does not need modify later.

    http://blogs.msdn.com/oldnewthing/ar...21/673830.aspx
    --------------------
    But the linker can't rewrite the code generated by the compiler. What's a linker to do?
    --------------------

    Quote Originally Posted by CornedBee View Post
    All of them. The articles are all part of a series that offers valuable information about dynamic linking.

    But the specific answer to your question is found in articles 5 through 7.

    regards,
    George


    Thanks BobS0327,


    Good reference. I am confused about when and what will generate the import library (.lib),

    --------------------
    When you link a DLL, the library manager (LIB32.EXE or LIB.EXE) scans the OBJ files being linked and creates an import library.
    --------------------

    Suppose we build a DLL called Foo.dll, the import library foo.lib is generated when we build the DLL. So, the import library is generated and input to the linker of the EXE, why in the quoted article, you mentioned "When you link a DLL, the library manager (LIB32.EXE or LIB.EXE) scans the OBJ files being linked and creates an import library."? Seems in the article, import library (.lib) is generated when we linking the foo.dll to the EXE?

    Quote Originally Posted by BobS0327 View Post
    Read this MSDN article. Specifically....

    regards,
    George

  7. #7
    Registered User
    Join Date
    Mar 2005
    Location
    Mountaintop, Pa
    Posts
    1,058
    Good reference. I am confused about when and what will generate the import library (.lib),
    The linker creates the import lib as indicated in this article.

  8. #8
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks BobS0327,


    I take some time today to learn this article, it seems only chapter Libraries and chapter Creating the Imports Table cover the import library and it does not contain the content/format of the import library.

    I am interested in the content/format of the import library and especially interested in how the JMP statement is represented as mentioned in the article,

    --------------------
    From the COFF symbol table at the end of Figure 3, you can see that _ActivateKeyboardLayout@8 resolves to this JMP instruction in the .text section. Thus, the linker hooks up your CALL to ActivateKeyboardLayout to the JMP instruction in the .text section of the import library's OBJ.
    --------------------

    Quote Originally Posted by BobS0327 View Post
    The linker creates the import lib as indicated in this article.

    regards,
    George

  9. #9
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by George2 View Post
    After reading them, I have a question for a normal function call, what assembly code will be generated by the compiler? I can not imagine what the compiler will generate, which the link does not need modify later.
    As you know, the compiler does not generate assembly. That's the linker's job. The compiler simply parses it into a format readably by the linker which then sees a call to an address must be done and looks up that address and, in this case, would find it in the .lib file of the dll. Thus the linker generates a call instruction to the stub in the imported function thunk.


    Good reference. I am confused about when and what will generate the import library (.lib),

    --------------------
    When you link a DLL, the library manager (LIB32.EXE or LIB.EXE) scans the OBJ files being linked and creates an import library.
    --------------------

    Suppose we build a DLL called Foo.dll, the import library foo.lib is generated when we build the DLL. So, the import library is generated and input to the linker of the EXE, why in the quoted article, you mentioned "When you link a DLL, the library manager (LIB32.EXE or LIB.EXE) scans the OBJ files being linked and creates an import library."? Seems in the article, import library (.lib) is generated when we linking the foo.dll to the EXE?
    When you create, when you link a DLL, you get a .lib file from which the linker can import the function thunks.
    However, the library manager does not create any file. It generates proper jump instructions from the function thunks to the proper addresses for the functions in the DLL when loaded into the process memory.
    Makes sense?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #10
    Registered User
    Join Date
    Mar 2005
    Location
    Mountaintop, Pa
    Posts
    1,058
    I am interested in the content/format of the import library
    Format specs are here

  11. #11
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Elysia,


    1.

    For this of your concern, I have written my further concern into another thread because I think it is more appropriate to be a separate topic,

    http://cboard.cprogramming.com/showthread.php?t=99232

    It is appreciated if you could comment.

    Quote Originally Posted by Elysia View Post
    As you know, the compiler does not generate assembly. That's the linker's job. The compiler simply parses it into a format readably by the linker which then sees a call to an address must be done and looks up that address and, in this case, would find it in the .lib file of the dll. Thus the linker generates a call instruction to the stub in the imported function thunk.
    2.

    Quote Originally Posted by Elysia View Post
    When you create, when you link a DLL, you get a .lib file from which the linker can import the function thunks.
    However, the library manager does not create any file. It generates proper jump instructions from the function thunks to the proper addresses for the functions in the DLL when loaded into the process memory.
    Makes sense?
    Yes, thanks.


    regards,
    George


    Thanks BobS0327,


    Good knowledge!

    Quote Originally Posted by BobS0327 View Post
    Format specs are here

    regards,
    George

  12. #12
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Quote Originally Posted by George2 View Post
    After reading them, I have a question for a normal function call, what assembly code will be generated by the compiler? I can not imagine what the compiler will generate, which the link does not need modify later.

    http://blogs.msdn.com/oldnewthing/ar...21/673830.aspx
    --------------------
    But the linker can't rewrite the code generated by the compiler. What's a linker to do?
    --------------------
    Raymond isn't very precise. The linker absolutely can modify the code generated by the compiler - it has to. What it cannot do (typically) is modify the code in a way that changes anything important, like opcodes or the position of the opcodes (local jumps would get messed up).
    However, all it has to do to resolve a generated external function call is replace an address placeholder with an actual address, which is safe and simple.


    Quote Originally Posted by Elysia View Post
    As you know, the compiler does not generate assembly.
    Huh?

    In the traditional compilation model, the compiler generates assembly, then the assembler generates object code, and the linker links that together, replacing external references on the way.
    Microsoft's compiler typically skips the assembly step and produces object code directly.
    If, and only if, you enable whole-program optimization, the compiler will instead generate some rather high-level representation of the compilation unit, which the linker then takes, combines with that of all other compilation units, optimizes and finally creates code for. But that's the exception, not the rule.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  13. #13
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by CornedBee View Post
    Huh?

    In the traditional compilation model, the compiler generates assembly, then the assembler generates object code, and the linker links that together, replacing external references on the way.
    Microsoft's compiler typically skips the assembly step and produces object code directly.
    If, and only if, you enable whole-program optimization, the compiler will instead generate some rather high-level representation of the compilation unit, which the linker then takes, combines with that of all other compilation units, optimizes and finally creates code for. But that's the exception, not the rule.
    I was under the wrong impression that the linker generated the assembly only and not the compiler. In other words, my bad.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #14
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    Let us come back to the original question, about address of DLL exported function. :-)

    1.Inside DLL

    For the DLL itself, in its build process, it has to decide the address of each function in the result binary file (.dll), right? I think each exported function in the dll biinary file has a definite absolute address, which is based on the default load base address of the DLL, right?

    2. Inside EXE

    For the EXE, which utilizes the DLL, since there may be DLL rebase, which changes the base load address of the DLL into EXE process space, the address of the exported function of the DLL is not known until EXE load time and the final rebased address of the exported function of the DLL is put into the IAT of EXE.
    In other words, the same function of the DLL, may have different address in different EXEs, which loads the DLL into related process space of EXE.
    So, all the places where invokes the dllexported function, will use a function pointer to point to the IAT entry of the related dllexported function to form a indirection level function call. No address of DLL exported function is known and written to the EXE binary until load time address fix-up.

    My understanding of (1) and (2) correct? Any comments?

    Quote Originally Posted by CornedBee View Post
    Raymond isn't very precise. The linker absolutely can modify the code generated by the compiler - it has to. What it cannot do (typically) is modify the code in a way that changes anything important, like opcodes or the position of the opcodes (local jumps would get messed up).
    However, all it has to do to resolve a generated external function call is replace an address placeholder with an actual address, which is safe and simple.



    Huh?

    In the traditional compilation model, the compiler generates assembly, then the assembler generates object code, and the linker links that together, replacing external references on the way.
    Microsoft's compiler typically skips the assembly step and produces object code directly.
    If, and only if, you enable whole-program optimization, the compiler will instead generate some rather high-level representation of the compilation unit, which the linker then takes, combines with that of all other compilation units, optimizes and finally creates code for. But that's the exception, not the rule.

    regards,
    George
    Last edited by George2; 02-23-2008 at 01:35 AM.

  15. #15
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Yes, that's correct.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 3
    Last Post: 07-19-2008, 03:12 PM
  2. dllimport function not allowed
    By steve1_rm in forum C++ Programming
    Replies: 5
    Last Post: 03-11-2008, 03:33 AM
  3. DLL Wrapper
    By vampirekiss in forum C Programming
    Replies: 4
    Last Post: 01-08-2008, 10:24 AM
  4. Using DllImport with C# and C
    By CompiledMonkey in forum C# Programming
    Replies: 1
    Last Post: 08-18-2005, 05:12 AM
  5. Importing a class with dllimport
    By mepaco in forum C++ Programming
    Replies: 6
    Last Post: 08-21-2002, 08:18 AM