How a program accesses functions

How a program accesses functions

  • Comments 12

Hi, I’m Alan Chan and I am a developer on the Visual C++ libraries team.  We all know that a library is a collection of functions.  However, how does a program actually “access” these functions under the covers? 

Essentially, there are 3 different ways that a function can be made available for the program to use: inline, statically linked and dynamically linked.

For "inline functions", this is just as it sound. The definition and implementation is in the header and is inlined into the user's code.  We provide implementation of the function in textual C++ code format for the user.  When they compile with our headers, the compiler will turn the code into the asm instructions and inline them in the user's code.  A prime example of this is STL and marshalling; almost everything is header based.

For "statically linked functions ", we declare the function in our headers, but we ship our implementation in a binary format in the form of static lib (*.lib file) or object file (*.obj files).  When the user compiles with our header, it generates a "weak" link to the function symbol.  During link time, the linker will search for the symbol in our static lib and find the binary implementation.  The linker then takes binary implementation and mixes it with the user's code into an executable.  Therefore, this function exists in the user binary image and doesn't depend on our DLLs.  

For "dynamically linked function", this is also as what it sounds like.  The function exists in the DLL.  We only have a declaration in our headers and the definition is in a binary format in the DLL.  Similar to the previous type, during compilation, the compiler will generate a weak link to the function symbol.  When the program links, it will find the function symbol in the import lib.  However, instead of finding the full implementation of the function, it will find a “reference” to the DLL.  The linker will generate a list of these imported functions (or better known as import address tables or IAT) in the portable executable (PE) header of the executable. At load time, the Windows loader will read this table, load the DLL, and write the actual memory address of these functions into a table.  This step is usually called “binding.”  Afterwards, when the executable tries to call an imported function, it will look at this table and jump to address inside the DLL and execute that.






  • PingBack from

  • Alan,

    I am going to assume something. Are you new to C++? I'm sorry to sound offensive, but this article is a mish-mash of badly formulated ideas.

    A program doesn't 'access' functions. It is part of the compiler/linker to generate this information.

    I'm struggling to understand what it is you've talked about here. You've rolled compiler/linker issues in with PE/import tables, which are completely different things. I would love to see a series of articles which introduce and discuss (at length) these things. I seriously hope no new/intermediate developer comes across this link.

    Also, I've never called the DLL load process 'Binding'. Sure, you guys in MS might. The rest of the world doesn't.

  • Really?

    'Binding' sounds pretty well agreed on to me.

  • Please don't always be an ANTI-MS guy.  I think this post is simple and clear.

    p.s. i'm not ms guy :).

  • Alan's given us a brief, good and easy-to-understand explanation on how program accesses function in library.

  • cmroanirgo -

    Alan is definitely not "new to C++" and while maybe he's no Shakespeare, and his post isn't very expansive, this is a good summary of the ways user code (by user I mean you guys ;)) gets at our library code when you call a function ("access" if you will).  It's a very library-centric view in that it looks at what we normally think about in our team (Visual C++ libraries) when looking at how our users access our functionality, but it's a simple, short and easy to understand explanation.  I guess the other topic this post could have covered would be virtual vs non-virtual vs inline within a single binary - v-tables and the like - but I think that's the sort of thing you probably learn in your 200 level classes in college.  

    Anyway, just wanted to pipe in to confirm what others like Fried, Hooyoo and Steven Yong are saying and confirm that Alan's no n00b :).

    Ben Anderson

    Visual C++ Libraries Team

  • Seems like quite a well written explanation to me. He mixes compile/link/load terminology because that's what the article is summarising, how library function calls get translated into executable code.

    I liked it anyway! :)

  • I also liked it.  I think this post provides a good high-level overview of the C++ library functions.

  • Alan's given us a brief, good and easy-to-understand explanation on how program accesses function in library.

    I also liked it.  I think this post provides a good high-level overview of the C++ library functions

  • I'm sorry all. After re-reading my comments I find that they are particularly harsh.

    I humbly apologize.

    Hooyoo. I have been using VC since the early 90's. I'm not anti MS.

    Dave. I agree....but I would love to see these articles re-written in multiple stages, simply to clarify what the compiler/linker is doing vs what is going on with DLL (and Delay-load) DLLs.

    Alan, again humble apologies. I think a nerve was hit when you described a function as being "accessed". My (incredible) bad.

  • I would like to learn more about import libs. I know gcc doesn't need them and i've used DLLs directly (without import libs) from Delphi too.

    Why are they needed? When can i avoid using them and why would i choose not to do so?

  • ikk:

    There is a difference in the way Linux shared libraries work from Windows DLLs. If you look at a Windows build of GCC, like mingw, you will notice that it actually requires import libraries to link to a DLL.

    Delphi, Visual Basic, C# and other programming languages like this don't require import libraries because their runtime libraries or your program deal with this. One of the first things you have to do is declare the function and where it is externally. You don't need to do this with the main Win32 api in Delphi since Borland gives you a module which handles this, but when accessing a function from a dll in Delphi without this you use something like

    procedure DllProc; external 'mydll.dll'

    this does the decleration and then the libraries do the rest.

    In C/C++ import libraries are not needed but they help automate the process of calling the functions from a DLL. Since C/C++ doesn't have a runtime library system the way that other languages do then things like this makes it easier. Accessing DLLs in Windows is done through a combination of LoadLibrary and GetProcAddress, so instead of requiring a large amount of these calls, just linking with an import library can reduce things by a lot and make your code a lot easier to read.

    Using the import library does one thing for C/C++ that you would possibly take for granted, and it enables you to call a function in the DLL just as the function name without doing anything else. Otherwise you will have to get into the fun of function pointers and more.

    But to answer your question. You use them in C/C++ when you want to access DLLs. There are some cases where you can't, but those are advanced programming techniques so it is best not to think about that.

Page 1 of 1 (12 items)