静态库和动态库的区别

静态库：在编译的时候加载生成目标文件，在运行时不用加载库，在运行时对库没有依赖性。
动态库：在目标文件运行时加载，手动加载，且对库有依赖性。

两者区别：
一，静态库的使用需要：
1 包含一个对应的头文件告知编译器lib文件里面的具体内容
2 设置lib文件允许编译器去查找已经编译好的二进制代码

二，动态库的使用：
程序运行时需要加载动态库，对动态库有依赖性，需要手动加入动态库

三，依赖性：
静态链接表示静态性，在编译链接之后， lib库中需要的资源已经在可执行程序中了， 也就是静态存在，没有依赖性了
动态，就是实时性，在运行的时候载入需要的资源，那么必须在运行的时候提供 需要的 动态库，有依赖性， 运行时候没有找到库就不能运行了

四，区别：
简单讲，静态库就是直接将需要的代码连接进可执行程序；动态库就是在需要调用其中的函数时，根据函数映射表找到该函数然后调入堆栈执行。
做成静态库可执行文件本身比较大，但不必附带动态库
做成动态库可执行文件本身比较小，但需要附带动态库

五：
首先纠正所谓“静态连接就是把需要的库函数放进你的exe之中”的说法。在真实世界中，有三个概念：Use static libary, static linked DLL, dynamic linked DLL.
多数人混淆了static libary 和 static linked DLL的概念，当然他们有似是而非的“相似之处”，比如都用到.lib，下面具体说明。
使用静态库(Use static libary)是把.lib和其他.obj一起build在目标文件中，目标文件可以是.exe,也可以是.dll或.oxc等。一般情况下，可以根本就没有“对应的”.dll 文件，如C Run Time(CRT)库。一个例子就是，写一个main(){}，build出来并不是只有几个字节，当然有人会说那还有exe文件头呢？是，即使加上文件头的尺寸，build出的执行文件仍然“莫名的大”。实际上那多出来的部分就是CRT静态库。姑且可以把静态库.lib理解成外部程序的obj文件比较合理，它包含了函数的实现。
下面再谈static linked DLL 和 dynamic linked DLL又如何？
静态链接 (static linked DLL)从操作上在VC的Project|Settings...|Link (tab)|General (category)|Object/library modules 中设置和添加。比如要使用SDK中的PropertySheet() API, 就要在这里添加 comctl32.lib，然后再调用的源程序中#include <prsht.h> , 使用的地方直接调用PropertySheet()。当程序.exe启动时，系统会把对应comctl32.dll加载进来。作为DLL的静态引入库的.lib不包含函数的实现，只包含用于系统加载的信息，如对应的DLL名称，函数歧视地只在对应的DLL中的便宜等等。相比动态链接而言，静态链接是很简单的。
动态链接是使用LoadLibrary()/GetProcessAddress()和FreeLibrary(),详见下面的例子。

{
typedef BOOL (WINAPI *LPFNSHELLEXECUTEEX)(LPSHELLEXECUTEINFO);

hShell32Dll = LoadLibrary(TEXT( "SHELL32.DLL "));
if (!hShell32Dll) { goto End; }

lpfnShellExecuteEx = (LPFNSHELLEXECUTEEX)GetProcAddress(hShell32Dll,
API_NAME(ShellExecuteEx));
if (!lpfnShellExecuteEx) { goto End; }

...
fOk = (*lpfnShellExecuteEx)(pShellExecuteInfo);
...
End:
if (hShell32Dll) {
FreeLibrary(hShell32Dll);
}
lpfnShellExecuteEx = NULL;
...
}
有人会想，动态链接这样麻烦，为什么还要用呢？这里有一个技术问题，对这个问题的解决直接导致了动态加载的需求。问题是有些DLL只在某个Windows版本中存在，或某个API只在某些Windows版本中被加入指定的DLL。当你使用静态链接的.exe试图在不支持的Windows版本上运行时，系统会弹出系统对话框提示某某.dll无法加载或无法定位某某API的消息，然后就中止.exe的运行。像这样因为个别功能的实现依赖于某个DLL，当这个DLL不可用时导致整个.exe无法运行是不明智的。避免这样的结局只有用动态链接。