Dynamic Link Library (DLL) Interview Questions & Answers

Question 1. What Is Dll And What Are Their Usages And Advantages?

Answer :

Dynamic Link library or DLL in short are the extensions of applications. We often have common code between many applications and thus we put this common section of the code in an extension executable called DLL. The term DLL is very popular in Windows. However they are also present in Linux and Unix and known as Shared Libraries. Shared Libraries often come with extensions like.so or .ko. System side DLLs are also present along with Operating System kernel in the form of device drivers. They are the extensions of Operating Systems works in the same principle.

In the past when Microsoft Disk Operating System (MS DOS) was used as operating system, executables were the only binary running in the memory and any common code like C library were linked as static code. The main disadvantages were:

1. Additional executable code adds executable storage size as well as runtime memory requirement,
2. Executable uses C library code which is available at the time of build or compilation. There is no way to use latest C library during execution. It needs to be rebuild/recompile with latest C runtime every time a new C library version released,
3. In multitasking system where more than one task is running, there is no concept of using one instance of common executable while using static linking. It does not ensure only one version of C library is running in the system. Also it overloads memory requirement of each running task.

Dynamic linking resolves all the shortcomings of static linking. They come with the following advantages:

1. No additional requirement of memory at runtime or disk storage as a common binary file will be there,
2. All the application or clients will be using one single version of the common code provided by the DLL,
3. Operating system loads only one instance of the DLL when the first application/client loads it then for the every subsequent application it shares the memory pages of the DLL with their process address space. Thus there is no unnecessary memory overload in the system.

Question 2. What Are The Sections In A Dll Executable/binary?

Answer :

Every DLLs are regular PE executable in windows or ELF binary in Linux. Thus it has sections like CODE/.TEXT, .DATA,.BSS etc. 

• CODE/.TEXT - section contains executable hex code.
• .DATA - section contains global/static data values.
• .BSS - section is for un-initialized global/static values 

There are also two major section of a DLL executable. They are import section and export section.

• Import section(.idata): Defines the list of symbols/functions it imports from an external executables/modules.
• Export Section(.edata): Defines the list of symbols/functions that DLL itself exposes to external world to use.

Any executable in windows follows PE/COFF portable executable and common object format. These formats defines how code area, data area and other areas will be arranged. 

There are several tools available to see the various sections of a PE executable. Some of the well known tools are PE Viewer, PE Explorer etc.

Question 3. Where Should We Store Dlls ?

Answer :

Current application path is the default path of any dependent DLL(s). Thus DLL should reside in the same directory as the application executable.

However there is some system specific locations for storing operating system shared DLLs.

Windows:

• %systemroot%
• %systemroot%system
• %systemroot%system32
• %systemroot%system32drivers

Linux:

• /lib
• /lib/modules
• /usr/local/lib

The last location where we can place our DLLs are the directories in the system and or user PATH environment variable. 

Question 4. Who Loads And Links The Dlls?

Answer :

Windows and Linux both has PE/ELF binary loader to load executable and modules. 

A loader in OS loads executable/extension when creating a process or when an application explicitly calls LoadLibrary() or LoadModule() to load a particular executable. 

A loader loads any executable in the following steps.

1. Find the executable in current/system/in path variable
2. If not found through error
3. If found check for signature of executable (say check signature of ELF ) for validity
4. Load the code and data section in application/system address space.
5. Links the imported symbols of the application with the exported symbols of the DLL.

Question 5. How Many Types Of Linking Are There?

Answer :

There are two main categories of linking - Static Linking and Dynamic Linking.

Static Linking - In this type of linking, linker links the actual code of the library direct into the code section of the executable.

Example: Linking C and Graphics library in Turbo C++ for MS DOS.

Linking an application with a archive contains .obj files.

Dynamic Linking - Dynamic linking does not link the actual code of the external functions. Instead it prepares a list of imported functions in .idata section and a stub code which actually jumps to the external function by address.

Again Dynamic Linking can be divided into two category

Implicit Dynamic Linking and Explicit Dynamic Linking.

Implicit Dynamic Linking - Links the code with the import library using .idata section mechanism. At the time of application launching all the dependent DLLs should be loaded to start execution. Also when application ends execution all the dependent DLLs are getting unloaded.

Explicit Dynamic Linking - This linking does not require any .IMPORT section to list the function entries. It is done at runtime. User calls the Win32 API LoadLibrary() to load a particular DLL from a specific path on the demand basis at runtime. Thus there is no requirement for the DLL to be loaded at the startup time. Also DLL can be unloaded after the use with FreeLibrary() call.

Question 6. What Is Implicit And Explicit Linking In Dynamic Loading?

Answer :

Implicit Dynamic Linking or loading: When application or client uses its import table to link the external symbol/functions, it is called implicit linking. In implicit linking application use prototype header and import library to link an external symbol.

Example: Suppose we have a third party math library and add() is a function/interface we are using in our application.

Then the following steps are needed

1. include the math.h where add() prototype is there as a import function for compilation,
2. include math.lib for linking.
3. place math.dll DLL at the path of our application.

Explicit Dynamic Linking/Loading: When application does not link the external symbol by import library rather it loads the DLL at runtime. It does the same mechanism as operating system does during loading of the implicit linked DLL calls.

This is done by using Win32 APIs like:

• LoadLibrary() - loads and links a input library form the DLL path, or current path,
• GetProcAddress() - finds the symbol/function address by its name for a loaded DLL
• FreeLibrary() - unloads the loaded DLL instance

Question 7. How Functions Are Imported And Exported In A Module?

Answer :

Importing functions - Importing a function from other module is done by placing the function entry in function list of .IDATA section. MS VC++ compiler has specific keyword __declspec(dllimport) to import a function or variable from an external module.

Syntax:

Functions: __declspec(dllimport) ;
Variables: __declspec(dllimport) ;

Example:

__declspec(dllimport) int extrn_var;
__declspec(dllimport) int Function1(int a);

Exporting functions - Exporting a function from a module is done by placing the function entry in function list of .EDATA section. MS VC++ compiler has specific keyword __declspec(dllexport) to export a function or variable from a module.

Syntax:

Functions: __declspec(dllexport) ;
Variables: __declspec(dllexport) ;

Example:

__declspec(dllexport) int extrn_var;
__declspec(dllexport) int Function1(int a);

Question 8. How Can I Export A Function From A Module?

Answer :

Exporting a function from a module is done by placing the function entry in function list of .EDATA section. MS VC++ compiler has specific keyword

_declspec(dllexport) to export a function or variable from a module.

Syntax:

Functions: __declspec(dllexport) <function prototype>;
Variables: __declspec(dllexport) <type definition>;

Example:

__declspec(dllexport) int extrn_var;
__declspec(dllexport) int Function1(int a);

The second method of exporting a method from a module is done by placing function name in a .def file in EXPORTS section. We have a later section export a function without __declspec(dllexport) keyword to discuss this in details.

Question 9. What Are Afx Extension Class And Extension Dlls?

Answer :

Regular DLLs allows us to use MFC in the exported functions, but they do not require that the calling application should also use MFC. Thus regular DLL can be easily used in programs developed in other Windows programming languages like Visual Basic or Delphi. A big restriction of regular DLL is that it cannot export C++ classes. This restriction has been lifted in an Extension DLL. In an Extension DLL we can export classes. This forces the client application to be MFC application. The client can construct object of the exported class or derive classes from it. An extension DLL should meet two requirements:

1. An extension DLL dynamically links to the code in the MFC DLL. Hence an extension DLL requires that the client program be dynamically linked to the MFC library.
2. Both the client program and the extension DLL be synchronized to the same version of the MFC DLLs.

Example:

Class AFX_EXT_CLASS CMyAboutBox: public CDialog
{
  Public : void ShowDialog(void);
};

Question 10. How We Use Dynamic Linking In Linux? Give Example?

Answer :

Linux like Windows also supports all the linking of Windows. We shall discuss all the topics one by one briefly.

Static Linking:

Let us consider math.c file. We want to make it as a static library.

First we compile it with position independent flag on(-fPIC). This is needed for dynamic/static linking.

$cc -fPIC -c math.c

Now make a archive or static lib with the object file.

$ar rc libmath.a math.o

To use this static library in a application we need to do the following steps:

1. compile the application code (place math.h in include folder)
   $cc -c app.c -Iinclude -o app.o
2. Link with static library math.a
   $ld app.o libmath.a -o app
3. Run the application
   $./app

Implicit Dynamic Linking:

Let us consider once again math.c file for dynamic linking. We want to make it as a dynamic library. First we compile it with position independent flag on(-fPIC). This is needed for dynamic/static linking.

$cc -fPIC -c math.c

Now make a shared library with the object file.

$cc -shared libmath.so math.o

To use this shared library in a application we need to do the following steps:

1. compile the application code (place math.h in include folder)
   $cc -c app.c -Iinclude -o app.o
2. Link with import library math.lib
   $ld app.o -lmath -o app
3. Copy the libmath.so in lib path or current path and run the application
   $./app

Explicit Dynamic Linking:

Let us consider once again math.c file for explicit linking. The steps for creating a shared library are same as that of implicit linking. 

First we compile it with position independent flag on(-fPIC). This is needed for dynamic/static linking.

$cc -fPIC -c math.c

Now make a shared library with the object file.

$cc -shared libmath.so math.o

To use this shared library in a application we need to load the library then find the function pointer address, invoke the function, and at last unload the library.

Linux provides some dynamic link library APIs to achieve this. Her are some useful frequently use APIs:

• dlopen() - loads a dynamic link binary
• dlsym() - returns the function pointer if found the function entry
• dlclose() - unloads the dynamic link binary

Sample code:

#include
typedef int (add_func) (int a, int b);
void *lib_handle = NULL;
add_func * add;
int main (int argc, char *argv[])
{
  lib_handle = (void *)dlopen("libmath.so", RTLD_LAZY); 
  if(lib_handle) 
  { 
    add = dlsym(lib_handle, "add");
    if(lib_func)
    {
      printf("1 + 2 = %d", add(1, 2));
    }
    else
    {
      printf("Function entry not found in DLL");
    }
    dlclose(lib_handle);
  }
  else
  {
    printf("Unable to open DLL");
  }
}

Question 11. What Is Resource Dll? When And How We Can Use It?

Answer :

Resource DLL are those which contains recourse related to binary and no source code. Resource DLL can contain the followings

1. Accelerators
2. Bitmaps
3. Icons
4. Cursors
5. Menus
6. Dialogs
7. HTMLS
8. String Tables
9. Toolbars
10. Versions

Resource DLL can holds resources that can be shared between many applications and thus minimizes the size of each applications.

Resource DLLs are loaded using LoadLibrary() and the with MFC API AfxSetResourceHandle() we set the loaded resource DLL instance as our current resource instance. All the call of loading a resource line LoadIcon() etc. will now be loaded from the resource DLL.

Necessary MFC APIs:

• HINSTANCE AFXAPI AfxGetResourceHandle() - Returns the current loaded resource handle.
• void AFXAPI AfxSetResourceHandle(HINSTANCE hInstResource) - Sets the new resource handle for the MFC Application.

Question 12. How Do I Port My 16-bit Dll To A Win32 Dll?

Answer :

If you have built 16-bit DLLs for Windows 3.x, you should find that building 32-bit DLLs is more convenient. Visual C++ offers more direct support, which can save you several steps in DLL creation.