我想问一下TLB文件的问题，谢谢

[officecn]

好象COM类的DLL文件有时候会有一个TLB文件（类型文件）
我觉得有DLL文件就够了，还要TLB文件做什么呢？什么情况下必须用TLB文件？
TLB文件是怎么生成的？VB可以么？

[officecn]

难道CSDN没高手？

[射天狼]

DLL是动态链接库
TLB是静态链接库!!

[射天狼]

我们为什么使用静态链接？
(向Plasmatic致谢，本文建立在他贴在LFS邮件列表的一篇文章基础之上。)

当写程序的时候，我们不用每次都把所有的函数重写，比如处理内核、硬件、文件等等的函数，具有一些共性。所以这些函数就保存在库文件中，供你下次写程序时使用。glibc，你后面将安装的，就是这样一个大的库文件，包含了所有基本函数供程序使用，比如打开文件，在屏幕上打印信息，从使用者得到反馈。当编译程序的时候，这些库的代码被链接到程序中，以便程序使用库提供的函数。

然而，这些库文件有可能非常大(比如libc.a经常有2.5MB大)，你可能不希望在每个程序中包含一份拷贝。只要设想一下你的简单命令(比如ls)竟要附加2.5MB的库！ 所以，我们不是把库作为程序的真正部份(也就是静态链接)，而是把库存成单独的文件，当程序需要的时候再把它装载上来。这就是我们所说的动态链接，因为根据程序的需要，库动态地装载和卸载。

所以，现在我们有一个1KB的文件和一个2.5MB的文件，但是我们还没有节省空间。动态链接的真正优点是每个库我们只需要一份拷贝。如果ls和rm都要使用同样的库，那么我们就不需要两份拷贝，因为它们都能从同一个库文件中得到所要的函数。即使在内存中，这两个程序也共享同样的代码，而不是装载两份一样的代码到内存中。所以我们不仅节约了硬盘空间，还节约了宝贵的内存。

如果动态链接节约了这么多空间，那么在这一章里我们为什么要用静态链接呢？这是因为当你使用chroot命令(在下一章里将说到)进入你崭新(但是还不完整)的LFS系统，这些动态链接的库将不能使用，因为它们放在你的老目录树中(比如/usr/lib)，这样的目录在你的LFS目录树中($LFS)是不能存取的。

所以为了你的新程序能在chroot的环境下运行，你就要用静态链接来编译它们，于是--enable-static-link，--disable-shared, 和-static标志在整个第五章中都要使用。一旦到了第六章，我们要做的第一件事就是重新编译glibc。做好后，我们将重新编译所有第五章的程序，但这次将用动态链接，所以最终我们能够节约空间。

这就是你必须使用那些怪异的 -static 标志的原因。如果你试图不用静态链接来编译本章的程序(千万不要这样)，当你用chroot进入新系统时，你就会看到不幸的事(程序不能运行)。

[fuanwei]

知道了吧

[officecn]

呵呵，谢谢。
但是使用VB进行开发，引用WORD时也是用的TLB文件，
我并不需要远程启动WORD呀。这怎么解释？

[sogno]

在同一台计算机上得话，引用TLB和DLL没什么不同

DLL里组件的实现是不会编译进客户代码的，否则COM就失去意义了

[officecn]

OK

[officecn]

说了半天只字没提COM

[sogno]

“DLL是动态链接库 TLB是静态链接库!!”

这种说法是不正确的，Lib才是静态链接库

可以把TLB的作用类比C/C++的头文件

当你的project需要使用lib/dll(这里指标准的win32dll)里的对象/函数，你就需要引用相应的头文件，否则编译器无法生成正确的占位符，也就不能把你写的程序跟lib/dll正确得链接起来。

TLB的作用就类似于头文件，它描述了COM组件里的枚举、对象、方法的签名，可以说是.net里元数据的雏形，在编译时，vb会把它编入客户端程序，这样客户端就可以正确的使用COM组件，早期的Dll Hell问题就是被这种方式部分地解决了

[sogno]

TLB是组件服务的接口
而DLL包含了接口和实现
有些情况下，比如客户方需要远程调用，那么在客户机上部署dll是没有意义的，因为dll所需的环境在服务器上，而客户只需要dll里的接口定义部分，这个时候tlb就派上用场了
看一下vb ide里主菜单的project->xxx properties->component选项页上的Remote Server选项，当勾中Remote Server Files，vb在编译生成activex dll/activex exe的同时生成tlb文件