Home/ Questions/Q 8387631
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T18:15:58+00:00

I used Loadlibrary and Getprocaddress to link some of the WinApis for runtime linking.

  • 0

I used Loadlibrary and Getprocaddress to link some of the WinApis for runtime linking. It works fine, as expected.

But for some Apis I just used -ldllname as the compiler option. The same option gives linker error for some APIs, and needs the dll to be loaded.

Is there any particular difference in this, that is some particular APIs need runtime linking and other APIs will work with -ldllname option?? How to clasify APIs of these kind?

Update: What I observed is the APIs supporting UNICODE and ANSI i.e.,
The API which is suffixed with “W” and “A” , get resolved with static
linking itself? Am I correct? Correct me if I am wrong!

why some APIs need Run time linking and others get resolved with Static
linking itself(-l option)? Any reason for this?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I used Loadlibrary

    That would be an example of taking an implicit dependency on a DLL. LoadLibrary is a function that’s exported by kernel32.dll, a Windows api DLL. It actually exists in two versions, LoadLibraryA and LoadLibraryW. Respectively the non-Unicode and the Unicode version of the function. You’ll get one or the other, depending on whether you have the UNICODE macro #defined when you compile.

    So that’s the exact opposite of dynamically linking an export with GetProcAddress, you must tell the linker that your program has a dependency on kernel32 with the -l option. And at runtime the DLL automatically gets loaded before your own code starts running.

    Having an implicit dependency on operating system DLLs is quite normal. And unavoidable, you can never dynamically link kernel32.dll, that would be a chicken-and-egg problem.

    • 0