库可以通过修改工程文件里面的属性 ->配置属性 ->链接器 ->输入->附加依赖项来完成。但是能够找到所有的头文件反而需要一些技巧了。由于emule的代码中对于这些库的头文件的包含,在一定程度上限定了那些库的路径和emule的工程的路径的相对位置,因此需要把那些解压过的库的目录移到一些合适的地方,有时还需要给这些目录改个名称。
3. eMule源代码
学习心得(3):emule中最重要的几个基础设施
eMule中要读取的配置文件数量较多,每种配置文件都是自己定义的格式,为了方便读取和存储这些文件,eMule中有一个很重要的基础设施类来复制这些文件操作
,它能够很方便得处理一些常用数据类型的读写,并且带有一定的安全保护机制。这项基础设施在SafeFile.cpp和SafeFile.h中实现。在kademlia\io目录下有这项功能的另外一项实现。它们实现的功能基本上相似,但是kademlia\io目录下的版本实现的时候多了一个以Tag作为单位进行读写的功能。这些实现中和另外一项基础设施,那就是字符串转化密切相关。StringConversion.cpp和StringConversion.h是eMule中专门复制各类字符串转化的基础设施,什么Unicode啊,多字节流啊,或者是UTF-8之类的,在这里转化全部都不是
问题。关于字符串转化,个人推荐尽量使用Unicode的宽字符,这样可以最大程度得避免乱码。
SafeFile.cpp或者kademlia\io目录下的实现都有这样的特点,那就是把数据操作的行为和数据操作的对象分割开来。它们都定义了一个抽象的数据操作的基类(在SafeFile.cpp中是CFileDataIO,在kademlia目录下是DataIO.cpp实现的Kademlia::CDataIO),这个类中只负责实现在逻辑上操作一项数据的行为,例如,要读取出一个32位的整型,那么就是读出四个字节到一个整型数值的地址中,要读取或者写入其它类型的数据用的是类似的方法。但是这个类把物理上进行数据操作的方法全部都声明为纯虚函数,即读出多少个字节,写入多少个字节这样的。有了这样一个基类,就可以非常方便得在它上面进行重载,把这些纯虚函数定义为向某块内存中进行读写的操作,就能很方便得将较为复杂的数据序列化到一块连续的内存,而如果这些纯虚函数是向文件读写的操作,那么自然就可以很方便得用来读写各种格式比较奇怪的自己定义的配置文件了。
这些类要读取的数据对象通常有这些,各种整型,字符串,以及Tag类型。整型读写起来比较简单,从1个字节的,2个字节的到4个,8个或者16个字节类型的数据读写方法都比较类似。这里要稍微提一下16个字节的那种,16个字节是128位,是eMule中的Kad网的随机生成的ID的长度,也是eMule中
常用的MD4的hash算法生成的结果的长度。通常用来直接存取整个的这样的一个ID。在kademlia\utils目录下的UInt128.cpp实现了一个表示128位的整数的类,功能十分完善,可以进行一些算术操作,并且可以进行比较,这样为它以后作为key出现在hash表中打下了基础。仔细学习UInt128.cpp中的代码实现可以学到很多在编写这种自定义的数据对象类型时应该注意的问题。
数据操作中另外一项很重要的操作是字符串,总的原则是先写一个长度,再写内容。但是到具体的操作的时候就需要注意这些细节了,如长度是写4个字节还是两个字节,字符串的内容要不要用UTF-8进行编码。这些操作就需要
和StringConversion.cpp紧密合作了。其实后者的字符串转化函数很多也是调用ATL的相关函数,只是在外面再包上一层MFC的CString。
在kademlia\io\DataIO.cpp中实现的CDataIO中,还另外实现了按照Tag进行读写的功能。这在网络上交换共享文件的元信息非常重要,通常一个文件的元信息就可以分解成很多的Tag,如"文件名=xxx","文件长度=x