how do static import libraries actually work?

One thing I've never really understood are import libraries for DLLs
on Windows.

For example, let's say that I use a function from user32.dll in my
code. Without linking to user32.lib in VS I get a link error, so I
link to user32.lib and all is well.

I guess what I don't understand is how this jives with static linking
and dynamic linking.

>From what I understand, static linking is when you take object code
and just plop it into your binary.

Dynamic linking (on windows at least) is when you call LoadLibray()
and then GetProcAddress() and then make your call on a function
pointer.

What happens when you statically link to a DLL import library (i.e.
user32.lib)?

Does the import library object code contain implicit calls to
LoadLibray() and GetProcAddress that are performed on your behalf?

What's actually happening?

-Thx

Carl
Thu May 31 13:15:07 CDT 2007


<kilik3000@gmail.com> wrote in message
news:1180634705.788856.237880@p77g2000hsh.googlegroups.com...
> One thing I've never really understood are import libraries for DLLs
> on Windows.
>
> For example, let's say that I use a function from user32.dll in my
> code. Without linking to user32.lib in VS I get a link error, so I
> link to user32.lib and all is well.
>
> I guess what I don't understand is how this jives with static linking
> and dynamic linking.
>
>>From what I understand, static linking is when you take object code
> and just plop it into your binary.
>
> Dynamic linking (on windows at least) is when you call LoadLibray()
> and then GetProcAddress() and then make your call on a function
> pointer.
>
> What happens when you statically link to a DLL import library (i.e.
> user32.lib)?

The linker creases DLL Import Descriptors in the linked image. The OS
loader uses those import descriptors to load the referenced DLL(s).

>
> Does the import library object code contain implicit calls to
> LoadLibray() and GetProcAddress that are performed on your behalf?

No, just data that's used by the OS Loader. If you use "Delay Loading",
then the linker does actually inject code that calls
LoadLibrary/GetProcAddress when any of the imported functions is called the
first time. After loading the DLL, the injected code overwrites the hook
code to jump directly to the loaded code.

Try doing dumpbin /all on a few different kinds of files (.OBJ, .LIB, .DLL,
.EXE) to see what's inside. Warning - the output from dumpbin /all will be
HUGE (there are lots of options to dump less - use dumpbin /? to find out
about them).

-cd

kilik3000
Thu May 31 13:36:48 CDT 2007

On May 31, 2:15 pm, "Carl Daniel [VC++ MVP]"
<cpdaniel_remove_this_and_nos...@mvps.org.nospam> wrote:
> <kilik3...@gmail.com> wrote in message
>
> news:1180634705.788856.237880@p77g2000hsh.googlegroups.com...
>
>
>
> > One thing I've never really understood are import libraries for DLLs
> > on Windows.
>
> > For example, let's say that I use a function from user32.dll in my
> > code. Without linking to user32.lib in VS I get a link error, so I
> > link to user32.lib and all is well.
>
> > I guess what I don't understand is how this jives with static linking
> > and dynamic linking.
>
> >>From what I understand, static linking is when you take object code
> > and just plop it into your binary.
>
> > Dynamic linking (on windows at least) is when you call LoadLibray()
> > and then GetProcAddress() and then make your call on a function
> > pointer.
>
> > What happens when you statically link to a DLL import library (i.e.
> > user32.lib)?
>
> The linker creases DLL Import Descriptors in the linked image. The OS
> loader uses those import descriptors to load the referenced DLL(s).
>
>
>
> > Does the import library object code contain implicit calls to
> > LoadLibray() and GetProcAddress that are performed on your behalf?
>
> No, just data that's used by the OS Loader. If you use "Delay Loading",
> then the linker does actually inject code that calls
> LoadLibrary/GetProcAddress when any of the imported functions is called the
> first time. After loading the DLL, the injected code overwrites the hook
> code to jump directly to the loaded code.
>
> Try doing dumpbin /all on a few different kinds of files (.OBJ, .LIB, .DLL,
> .EXE) to see what's inside. Warning - the output from dumpbin /all will be
> HUGE (there are lots of options to dump less - use dumpbin /? to find out
> about them).
>
> -cd

Thanks for the response.

Where can I learn more about the OS Loader? This seems to be default
case.

kilik3000
Thu May 31 14:24:28 CDT 2007

On May 31, 2:36 pm, kilik3...@gmail.com wrote:
> On May 31, 2:15 pm, "Carl Daniel [VC++ MVP]"
>
>
>
> <cpdaniel_remove_this_and_nos...@mvps.org.nospam> wrote:
> > <kilik3...@gmail.com> wrote in message
>
> >news:1180634705.788856.237880@p77g2000hsh.googlegroups.com...
>
> > > One thing I've never really understood are import libraries for DLLs
> > > on Windows.
>
> > > For example, let's say that I use a function from user32.dll in my
> > > code. Without linking to user32.lib in VS I get a link error, so I
> > > link to user32.lib and all is well.
>
> > > I guess what I don't understand is how this jives with static linking
> > > and dynamic linking.
>
> > >>From what I understand, static linking is when you take object code
> > > and just plop it into your binary.
>
> > > Dynamic linking (on windows at least) is when you call LoadLibray()
> > > and then GetProcAddress() and then make your call on a function
> > > pointer.
>
> > > What happens when you statically link to a DLL import library (i.e.
> > > user32.lib)?
>
> > The linker creases DLL Import Descriptors in the linked image. The OS
> > loader uses those import descriptors to load the referenced DLL(s).
>
> > > Does the import library object code contain implicit calls to
> > > LoadLibray() and GetProcAddress that are performed on your behalf?
>
> > No, just data that's used by the OS Loader. If you use "Delay Loading",
> > then the linker does actually inject code that calls
> > LoadLibrary/GetProcAddress when any of the imported functions is called the
> > first time. After loading the DLL, the injected code overwrites the hook
> > code to jump directly to the loaded code.
>
> > Try doing dumpbin /all on a few different kinds of files (.OBJ, .LIB, .DLL,
> > .EXE) to see what's inside. Warning - the output from dumpbin /all will be
> > HUGE (there are lots of options to dump less - use dumpbin /? to find out
> > about them).
>
> > -cd
>
> Thanks for the response.
>
> Where can I learn more about the OS Loader? This seems to be default
> case.

Anyone have any links to docs that explain dumpbin output?

-Thx

Carl
Thu May 31 14:32:33 CDT 2007

<kilik3000@gmail.com> wrote in message
news:1180639468.253365.227500@q66g2000hsg.googlegroups.com...
> Anyone have any links to docs that explain dumpbin output?

For much of the output, you need to be familiar with the PE file format that
Windows uses. The PE file format is documented - I don't have a link handy,
but do a bit of googling and you'll find it.

-cd

Tim
Fri Jun 01 01:29:41 CDT 2007

kilik3000@gmail.com wrote:
>
>One thing I've never really understood are import libraries for DLLs
>on Windows.
>
>For example, let's say that I use a function from user32.dll in my
>code. Without linking to user32.lib in VS I get a link error, so I
>link to user32.lib and all is well.
>
>I guess what I don't understand is how this jives with static linking
>and dynamic linking.
>
>From what I understand, static linking is when you take object code
>and just plop it into your binary.
>
>Dynamic linking (on windows at least) is when you call LoadLibray()
>and then GetProcAddress() and then make your call on a function
>pointer.
>
>What happens when you statically link to a DLL import library (i.e.
>user32.lib)?
>
>Does the import library object code contain implicit calls to
>LoadLibray() and GetProcAddress that are performed on your behalf?

It is kind of an interesting process. The object file produced by the
compiler just calls, for example, CreateWindowA. The object file doesn't
know where that entry point will come from, it relies on the linker to fix
it.

In this particular case, the CreateWindowA entry point will be found in
user32.lib. But the library entry for CreateWindowA doesn't actually
contain any code. Instead, it contains a special linker table that says
"this entry point is found in CreateWindowA in user32.dll". The linker
creates an entry in the import descriptor table in the resulting
executable.

Although it is most common for the library entry point name to match the
DLL entry point name, and it is also most common for all of the imports in
a single library to point to a single DLL, neither is required. I could
create an import library called xxx.lib that contained an entry for
MyEntryPoint that points to YourEntryPoint in zzz.dll.

When the executable is loaded, the OS loader runs through the import
descriptor table, loads all of the DLLs that are mentioned, and fixes up
the addresses.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Bruno
Fri Jun 01 02:16:13 CDT 2007

> Where can I learn more about the OS Loader? This seems to be default
> case.

http://msmvps.com/blogs/vandooren/archive/2006/10/08/What-every-programmer-should-know-about-DLL-loading.aspx

As far as I know, the articles I link to are the only public documentation
about the DLL loader, apart from what is documented in MSDN in the
LoadLibraryEx and DllMain topics.


--
Kind regards,
Bruno van Dooren MVP - VC++
http://msmvps.com/blogs/vanDooren
bruno_nos_pam_van_dooren@hotmail.com

John
Fri Jun 01 05:42:00 CDT 2007

Hi Tim Roberts,

Thank you.

"I could create an import library called xxx.lib that contained an entry
for
MyEntryPoint that points to YourEntryPoint in zzz.dll. " - How?

--
Thanks & Regards,
John.


"Tim Roberts" wrote:

> kilik3000@gmail.com wrote:
> >
> >One thing I've never really understood are import libraries for DLLs
> >on Windows.
> >
> >For example, let's say that I use a function from user32.dll in my
> >code. Without linking to user32.lib in VS I get a link error, so I
> >link to user32.lib and all is well.
> >
> >I guess what I don't understand is how this jives with static linking
> >and dynamic linking.
> >
> >From what I understand, static linking is when you take object code
> >and just plop it into your binary.
> >
> >Dynamic linking (on windows at least) is when you call LoadLibray()
> >and then GetProcAddress() and then make your call on a function
> >pointer.
> >
> >What happens when you statically link to a DLL import library (i.e.
> >user32.lib)?
> >
> >Does the import library object code contain implicit calls to
> >LoadLibray() and GetProcAddress that are performed on your behalf?
>
> It is kind of an interesting process. The object file produced by the
> compiler just calls, for example, CreateWindowA. The object file doesn't
> know where that entry point will come from, it relies on the linker to fix
> it.
>
> In this particular case, the CreateWindowA entry point will be found in
> user32.lib. But the library entry for CreateWindowA doesn't actually
> contain any code. Instead, it contains a special linker table that says
> "this entry point is found in CreateWindowA in user32.dll". The linker
> creates an entry in the import descriptor table in the resulting
> executable.
>
> Although it is most common for the library entry point name to match the
> DLL entry point name, and it is also most common for all of the imports in
> a single library to point to a single DLL, neither is required. I could
> create an import library called xxx.lib that contained an entry for
> MyEntryPoint that points to YourEntryPoint in zzz.dll.
>
> When the executable is loaded, the OS loader runs through the import
> descriptor table, loads all of the DLLs that are mentioned, and fixes up
> the addresses.
> --
> Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc.
>

Tim
Sat Jun 02 20:06:58 CDT 2007

John <John@discussions.microsoft.com> wrote:
>
> Thank you.
>
> "I could create an import library called xxx.lib that contained an entry
>for MyEntryPoint that points to YourEntryPoint in zzz.dll. " - How?

You would probably have to create the library by hand. The import library
format allows this, but I don't think any of the standard tools will
actually create such a thing.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.