在用VS2022编译全功能版的时候我遇到了问题。虽然官方提供了nmake用的编译脚本，但是它跑起来总是报错，而且报错的地方在Windows SDK里面、而不是7z自己的代码。报的错误是C2279，出现在mapi.h头文件里、诸如“这个typedef地方不能写throw标识符”这样的东西。

网上搜索之后能找到的相关的东西不太多，有一个说法是C++标准的问题，现在的Windows SDK需要配合新版本的C++标准（C++17之类）才能正常使用。看了一下7zip源码里nmake脚本加的参数，也确实没有指定标准。

本来想试试换个旧版的Windows SDK行不行，一看要下载那么多东西……烦了，就没试。最后我的做法是，打开CPP下的Build.mk，找到定义 CFLAGS 的那一行，加个 /std:c++17。文件是只读的，要去掉只读属性才能保存。再编译会变成另外的错误，报异常规范不匹配。最简单的去掉警告视为错误（搜索，去掉-WX）可以编译通过。

另外我发现它没加链接时代码生成这样的优化，暂时不知道为什么。试着开了一下，用7zz b看跑分，和不开看不出区别。

第一次，是在前一家公司的时候，遇到一个应用场景，一个头文件需要同时在C和C++里用，里面存有一个成员函数的指针，和void*一起放在union里，是专门给C++用的；C的话这个地方就用条件编译语句换成单个void*。结果是我离开项目组之后，后面用到这段代码的人发现这个成员指针有的时候比void*大。但是那个时候已经不在组里了，也不知道具体那边应用场景是啥样，最后简单把void*替换成char[32]了事，更多的也没在意。

第二次，是在现在这家公司的时候，有个同事在某个头文件里定义的类里面包含了另一个类的成员函数指针，结果这个头文件在两个不同的cpp文件里包含，这个类的大小是不一样的……访问成员变量的时候偏移也不同，数据就坏了。但是cpp里头文件包含的顺序调换一下就能好……同事说是那个成员函数指针的大小会不同，不过那会儿工作有点忙，结果是没放在心上，后来就忘了这事儿了。

最后一次是网友Advance在代码开了最高警告级别的时候，有一个成员指针被报没有对齐到16字节边界，然后就怀疑这个指针的大小。我突然想起之前同事的代码在不同文件访问变量所用的偏移不同的事情，就打算简单调查一下。

最开始是想起了同事说的成员函数指针大小会比普通指针大的问题，到搜索引擎上搜了个微软msdn社区的帖子，有人提到什么样的情况成员函数指针是什么样的大小，帖子链接是：social.msdn.microsoft.com，里面大概是说，一个最基本的类，它的成员函数指针是4字节；如果这个类有多个基类，那么它的成员函数指针会变成8个字节，如果这个类有虚基类，那么它的成员函数指针是12字节。这个类如果都不知道是啥样的，只有声明没有定义，那么就是16字节。

看完了帖子，就说到这里。至于这8、12、16字节里面是啥样的，没有说。那就自己试一下吧……

4字节的情况

4字节的情况我觉得没啥好说的，和普通的函数指针一样。一定要说有区别的话，就是多送了一个参数：this指针。

8字节的情况

说是有多个基类的情况会变成8个字节，于是用下面这样的代码来试验，看看编译以后会成什么样

#include <stdio.h>

struct A { int a; void af() { printf("a=%d\n", a); } };
struct B { int b; void bf() { printf("b=%d\n", b); } };

struct C : public A, public B
{
    int c;
    void cf() { printf("c=%d\n", c); }
};

int main()
{
    C x;
    x.a = 1;
    x.b = 2;
    x.c = 3;
    void (C::*p1)() = &C::af;
    void (C::*p2)() = &C::bf;
    void (C::*p3)() = &C::cf;
    printf("%d\n", sizeof(p1));
    (x.*p1)();
    (x.*p2)();
    (x.*p3)();
}

看了一下编译后生成的代码，这8个字节里面，前4个字节是函数的地址，就和前一种情况——没有多个基类——的时候是一样的。至于后4个字节，是调用函数的时候送入的this指针的偏移。至于为什么要偏移，可以参考这篇博客。

上面的p1、p2、p3变量里，偏移分别是0、4、0。

大概就是这种感觉：

int main()
{
    C x;
    x.a = 1;
    x.b = 2;
    x.c = 3;
    union MemPtr {
        struct {
            void(*funcPtr)();
            int thisOffset;
        };
        void (C::*val)();
    } p;
    p.val = &C::bf;
    __asm {
        lea eax, p
        mov edx, MemPtr::thisOffset
        mov ecx, dword ptr [eax+edx]
        lea eax, x
        add ecx, eax
        lea eax, p
        mov edx, MemPtr::funcPtr
        mov eax, dword ptr [eax+edx]
        call eax
    }
}

简单解释一下，就是调用的时候，this=&x + p.thisOffset。

上面程序运行结果是b=2。

12字节的情况

多的不说，直接上测试代码

#include <stdio.h>

struct D {
    virtual ~D(){}
    int d;
    void df() { printf("d=%d\n", d); }
};

struct A : virtual public D { int a; void af() { printf("a=%d\n", a); } };
struct B : virtual public D { int b; void bf() { printf("b=%d\n", b); } };

struct C : public A, public B
{
    int c;
    void cf() { printf("c=%d\n", c); }
};

int main()
{
    C x;
    x.a = 1;
    x.b = 2;
    x.c = 3;
    x.d = 4;

    void (C::*p)() = &C::df;
    printf("%d\n", sizeof(p));
    (x.*p)();
}

因为对虚基类情况下对象在内存中的表示不熟，但是现在又太迟了，这个就以后再研究……先看它这个指针在干嘛。

这个12字节的指针，①最前面4字节放的是函数的地址，和4字节、8字节的情况一样；②中间4字节塞的东西是“虚表中的偏移”：有虚基类的情况，编译器会在虚表里面塞上这个虚基类的对象在当前对象中的偏移。因为可能会有多个这种虚基类，在调用成员函数指针的时候，this指针应该指向谁（换句话说也就是this指针要如何调整），是靠中间这4字节决定的。在上面例子中，就是从C*转换到D*的过程；③最后4字节存放的是this指针在这样调整之后，还要如何调整：在上面例子中因为D已经是最基本的类了，所以这里是0；但如果指向的是D的多个基类中其中一个的成员函数的指针，那么这里就不是0。

简单说就是这12字节，有8字节是说明this指针要怎么转换。

把上面的代码再弄复杂一点，比如

#include <stdio.h>
struct X { int x; void xf() { printf("x=%d\n", x); } };
struct Y { int y; void yf() { printf("y=%d\n", y); } };

struct D : public X, public Y { virtual ~D(){} int d; void df() { printf("d=%d\n", d); } };

struct A : virtual public D { int a; void af() { printf("a=%d\n", a); } };
struct B : virtual public D { int b; void bf() { printf("b=%d\n", b); } };

struct C : public A, public B
{
    int c;
    void cf() { printf("c=%d\n", c); }
};

int main()
{
    C x;
    x.x = -1;
    x.y = -2;
    x.a = 1;
    x.b = 2;
    x.c = 3;
    x.d = 4;

    void (C::*p)() = &C::xf;
    (x.*p)();
}

观察生成的代码就可以发现，这个p的后8个字节的数据是4和4。前一个数据代表取虚表中第4字节的偏移对this进行第一次调整，后一个数据代表在这之后继续像8个字节那种情况对this进行第二次调整。

16字节的情况

说实话，16字节的情况我自己已经看不出名堂来了。代码最终修改到

#include <stdio.h>

struct C;
void (C::*p)();

struct X { int x; void xf() { printf("x=%d\n", x); } };
struct Y { int y; void yf() { printf("y=%d\n", y); } };

struct D : public X, public Y { virtual ~D(){} int d; void df() { printf("d=%d\n", d); } };

struct A : virtual public D { int a; void af() { printf("a=%d\n", a); } };
struct B : virtual public D { int b; void bf() { printf("b=%d\n", b); } };

struct C : public A, public B
{
    int c;
    void cf() { printf("c=%d\n", c); }
};

int main()
{
    printf("%d\n", sizeof(p));
    C x;
    x.x = -1;
    x.y = -2;
    x.a = 1;
    x.b = 2;
    x.c = 3;
    x.d = 4;

    p = &C::xf;
    (x.*p)();
}

这种程度，比起前面可以看出就是多了个前置声明而已。和前面12字节的时候相比，生成的代码在前面12字节的基础上，往中间4字节和最后4字节的数据之间插入了一个4字节的整数0。但是在下面的代码里却没有用到这个0。

调用的地方代码变得复杂了，因为前置声明的缘故，这个指针不知道最后会被用到什么样的地方上面。于是调用这个指针的时候，代码会先判断这个指针的最后4个字节是不是0，如果是，就直接拿第二个4字节整数来对this做偏移然后调用函数；如果不是，就取虚表中这个位置上的数据去对this做偏移，然后再取成员函数指针里第二个4字节数据直接加到this上做第二次偏移，再然后调用函数。

至于指针中第三个4字节整数是干嘛用的，确实还没调查出来。凌晨2:40时间太晚了，明天还要上班，就不作大死了，下次有时间有精力再调查。

补充：生成的代码里没有用到这个0是因为在调用的地方，已经知道类的结构是什么样的、不需要这个0了。不然它4个4字节数据分别是函数地址、第一次this指针偏移调整、虚基类、虚基类之后的再一次this指针偏移调整。

同一个头文件里的类在不同CPP包含大小会不同的原因

说穿了其实很简单，一个类只有前置声明的时候，它的成员函数指针是16字节；但是如果某个CPP已经包含过这个“只有前置声明的类”的完整定义的时候，它的成员函数指针就是4或者8或者12字节。有的CPP包含了这个有类的完整定义的头文件，有的CPP却没有、只能看到前置声明。况且包含了完整定义头文件的CPP，可能是在声明这样的指针之前包含，也可能是在声明这样的指针之后包含，所以调换一下头文件顺序结果也会不一样。

那么这样的问题如何解决？网友featherwit给出了一个靠谱的方案：使用编译参数/vmg（其实之前那个MSDN社区的帖子里，那人似乎也提到过了，说加了这个参数就一定是12字节）。不过不知道为什么我试出来是加了这个参数以后就都是16字节，总之是统一大小了。

果然还是在意16字节的情况下第3个4字节整数存的到底是什么。
←已经补充了

因为在调用delete的时候，它会先调用对象的析构函数，然后释放对象所占的内存。在这种情况下我想到，按照堆的特性，从堆申请的一块空间在释放的时候，要把这个空间的首地址送进去，而不是送入这块空间中的其他的什么地址。但是如果一个类X继承了B1和B2（B1在前B2在后），那么用X*指向这个对象和用B2*指向这个对象，指针保存的地址是不同的。此时如果对着B2*来delete，那么会发生什么样的事情……于是有了下面这个简单的代码进行试验。

struct B1 { int a; };
struct B2 { int b; };
struct X : public B1, public B2 { int c; };

int main()
{
    X* x = new X();
    B2* b2 = x;
    delete b2;
}

转到反汇编之后，可以看到它就是把b2的地址送到delete里面去调用，果然崩掉了。

这段代码从字面上来一眼似乎看不出什么问题，仔细考虑以后想到，以前学C++的时候，有这么个说法，一个类如果要用来做基类，那么应该要有虚拟析构函数。于是就又有了下面这样的试验代码。

struct B1 { virtual ~B1(){} int a; };
struct B2 { virtual ~B2(){} int b; };
struct X : public B1, public B2 { int c; };

int main()
{
    X* x = new X();
    B2* b2 = x;
    delete b2;
}

加了虚拟析构函数之后，程序果然运行起来就不崩了。查看反汇编，会发现在delete b2的时候，它直接调用虚函数表里的B2析构函数的指针（在X对象里，B2虚表里的析构函数是X对象的），而这个函数里面的内容是把指针从B2偏移回来，变成X*类型，然后执行X的析构函数，析构函数的最后自带delete的调用，于是这样释放起来就没有问题了。

虚表里的析构函数不太一样，虚表里保存的析构函数指针的是执行了原来的析构函数之后还delete的。如果对象是栈上创建的，那么就是只调用原来的析构函数）。

其实这都很早以前做的实验了。然而为什么会突然想到这个问题呢？今天上班的时候，同事在试验这个东西，就是在对象里面把this指针打印出来，看看它到底是什么样的。比如下面这样的代码

#include <stdio.h>

struct B1 {
    virtual ~B1(){}
    int a;
};

struct B2 {
    virtual ~B2(){} 
    virtual void F() { printf("%p\n", this); }
    int b; 
};

struct X : public B1, public B2 {
    void F() override { printf("%p\n", this); }
    int c; 
};

int main()
{
    X* x = new X();
    B2* b2 = x;
    x->F();
    b2->F();
    delete b2;
}

只是在刚才实验的代码上做了少量修改。根据前文的结论，x和b2虽然指向的是同一个对象，但是里面存的地址是不同的。也就是说，在下面调用F的时候，送入的this指针参数是不同的（后面证明这个想法是错的）。但是运行的时候，这两条输出确实输出了同样的地址。这是怎么做到的呢？

这种调整不能是在b2->F()的时候做的。因为在编译期的时候，不知道这个b2指向的是什么对象，可能是X可能是B2，不能随便给指针做偏移、转类型。这样可以得出，那么也就是这个F调用的时候必须要能接受一个类型为B2的指针；但是前面x->F()调用的时候，送进去的是类型为X的指针（看了反汇编，这个说法是错的），但不管是B2*上调用还是X*上调用，F是同一个函数。这里面的矛盾，最直白的方法还是看反汇编了。

结果看了反汇编，才注意到刚才思考的时候漏掉的东西：虽说在执行b2->F()的时候不能给this指针做类型转换，因为不知道它真实的类型；但是对于X类型来说，它却可以不管三七二十一就让F执行的时候接受的this参数是B2类型的：因为能看到X类型的定义的地方，都知道这个F是从B2来的，又因为能调用F的地方，都是能看到X定义的地方，所以在调用F的地方是一定可以把X*转成B2*的。然后真正的B2对象的虚表里是不可能有X::F函数的，所以在这个函数里，就可以把接收到的this参数，从B2*转回X*。

这种实现方式，外面用X类型来调用F的时候，因为知道F是从B2来的，可以把this指针转成B2*再送入；外面用B2类型调用F的时候，因为F就是B2里声明的，那么直接让this类型为B*送入就成。因此，就可以不管调用者是通过X类型调用的F还是通过B2类型调用的F，执行出一样的结果。

所以前面想当然认为“送入的this指针是不同的”是不正确的。送进去的this指针，还真就是相同的，类型都是B2*。

不过WDK里面的东西并不完善，所以Windows SDK可能还是要准备一个。考虑到要把它当作VC6来处理，所以最新能用的也就是Platform SDK 2003 February。其实本来没打算装这个，因为WDK里面已经带了一套Windows的头文件和库，但是在编译boost的那个bjam的时候，发现WDK里面没有TlHlp32.h文件（当然前提是你已经把api、crt那些的文件夹都加到Include环境变量里了），于是知道它带的东西还是有少的，就装个SDK来补充一下。

安装SDK的时候也还遇到了问题。因为这个SDK版本比较老，它有x86和ia64两个setup.exe、setup64.exe但是却没有给amd64（x86-64）用的setup，于是无法启动安装程序。上网搜索解决方案是直接到文件夹里面去运行它的那些msi安装包来安装组件。那些msi在安装的时候会提示选择要安装的组件、要安装到什么文件夹的。

现在的Boost已经抛弃对VC6.0的支持了，网上找了一圈相关信息，能支持VC6的最新版本是1.34.1（也有说1.34.1的Regex编译起来有问题，1.33.1更容易搞定，不过我没试验过），那就找到这个指定版本下载来，解压。

然后boost解压之后需要一个bjam控制之后的编译过程，在boost\tools\jam\src里可以找到一个build.bat，用它来构建bjam.exe。如果只有WDK、并且在bat的参数指定了MSVC、环境变量指定了MSVCDir为WDK的文件夹（具体开build.bat进去看，很容易找到），就会出现前面说的找不到TlHlp32.h的事情。

接下来，前一篇博客 有提到WDK的编译器和msvcp60.dll配合有问题，编译器默认wchar_t就是wchar_t但是msvcp60认为它是unsigned short，于是在链接的时候出现符号链不上的问题。自己编译的时候还好办，知道/Zc:wchar_t，但是由别人编译的时候问题就有点麻烦，因为不知道怎么加。我研究了很久总之也没找到方法……不管怎么样，就算开-n的时候也能看到/Zc:wchar_t不过看不到/Zc:wchar_t。这样的命令行：
bjam stage release toolset=msvc-6.0 --with-regex runtime-link=shared link=static
最终开到boost\tools\build\v2\tools\msvc.jam文件里面，找到了/Zc:wchar_t，改成/Zc:wchar_t-，再编译，换了个错误，说swprintf函数什么什么不匹配。网上一搜，原来它有个BOOST_NO_SWPRINTF宏，索性就用上了。就是说把
/Zc:wchar_t
改成了
/Zc:wchar_t- /DBOOST_NO_SWPRINTF

再编译，终于能出lib文件了。

仔细查看这一行的上下文，可以发现它是在你编译器指定是VC6.0的时候加入的特定处理。但是，明明有一个<cxxflags>在上面，试了好几种命令行写法，最终也没能成功把参数通过命令行弄进去。

总之经过这样一搞，最终成功在WDK里用起Boost.regex了。顺便一说，测试的结果，因为regex引擎加入进去的关系，最终生成的可执行文件大小只比VC2010用自带regex、静态链接生成的可执行文件的大小小了60KB左右（原来180KB现在120KB）

程序本身是没有问题，因为我用VS2010编译器编译它就正常，而且还能运行，运行起来也没问题。仔细查看DDK编译器的报错信息，大概是

error LNK2019: unresolved external symbol "__declspec(dllimport) p
ublic: wchar_t& __thiscall std::basic_string<wchar_t,struct std::char_traits<wch
ar_t>,class std::allocator<wchar_t> >::operator[](unsigned int)" (__imp_??A?$bas
ic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@QAEAA_WI@Z) reference
d in function "public: bool __thiscall CSAORIInput::parseString(class std::basic
_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> >
 const &)" (?parseString@CSAORIInput@@QAE_NABV?$basic_string@_WU?$char_traits@_W
@std@@V?$allocator@_W@2@@std@@@Z)

这个样子的，目测意思是链接不上std::wstring。

感觉不应该啊，它不是支持宽字符字符串对象的吗。然后上网搜搜出了这么一个东西：

http://stackoverflow.com/questions/5988457/is-wchar-t-supported-in-c-wdk-stl-i-get-unresolved-external-symbols

感觉好坑……编译器和库不够匹配的结果吗。库用的是VC6.0里面的吧，但是因为编译器是新的，默认wchar_t是内置类型，而库并不是这样的，最终链不上。

最终加上了 /Zc:wchar_t- 参数，它就好了。

灵感很简单，在查看关于DLL调用方面的文章的时候，突然看到了一篇关于MinGW下制作lib文件之类内容的。因为我以前用过MinGW编译器，同样也搞过这个DLL导入的方面。于是就想起来当时用dlltool工具的时候，确实有看到它能够支持对导入名进行调整的参数。但是那个时候并没有对这方面有多少深入的研究，其实说白了就是没有理解那些参数实际想要表达的到底是什么意思。这下有了前面对VC下隐式调用DLL里函数的经验，一下子知道了那些到底是想表达什么，比如导入名中去掉prefix，或者kill掉后面的@nn，之类之类。

然后呢，前面在研究导入库格式的时候，看微软提供的那个规格说明文档，里面也有提到这方面的东西，比如去掉prefix或者kill掉后面的@nn之类。

说简单点，就是正常情况下比如写了一个这样的def文件

LIBRARY MyDLL
EXPORTS
  function
  dosomething

此时如果用lib.exe工具（其实就是link.exe /lib，因为WDK中没有lib.exe所以提一下）从这个def文件生成lib文件，那么这个lib文件将从DLL导入function和dosomething，同时向链接器提供_function和_dosomething。这样的话对于__cdecl方式导出的函数是没有问题的。但是如果DLL的导出符号仍然是function和dosomething，但是调用方式却是__stdcall，就会遇上了问题：如果function有一个int型参数，那么链接器将去寻找_function@4而不是_function，因为找不到符号，所以链接失败了。

如果DLL中导出的符号名是function@4，此时生成的lib就会从DLL导入function@4并向链接器提供_function@4，但是实际上以__stdcall方式调用，但是最后导出的时候不带@nn的情况是非常多的。最典型的情况就是Windows API。而且实话说吧因为@nn这样的实在不怎么好看，所以我自己写DLL的时候也会通过使用DEF文件的方式或者#pragma comment(linker, "/EXPORT:xxxxxx")这样的预编译语句让导出的函数不带如此的后缀。

于是这样需求就变得简单：让生成的导入库从DLL引入的时候是不带后缀的，但是向链接器提供的符号是带后缀的。

这并非不可能，调用Windows API的时候就是这样：Windows SDK里面那些LIB文件，就是实现这样的功能。对其格式进行研究，根本就是和普通的导入库一样。除了……呃，除了某些细节上的参数。

于是我的目的就是修改这些细节上的参数。Microsoft PE and COFF Specification里也提供了这方面的详细资料。

方法的话，遍历LIB文件中的每个member，LIB文件的格式可以从上面提到的资料中找到，不会太复杂。注意每个member的第一个字节似乎是对其到偶数边界的，没有对齐的用\n来补。在遍历的过程中分析前四个字节就知道这个member是不是声明了一个导入函数，如果是，根据导入的格式分析其头部信息，然后获得DLL名、函数名等。

在这个导入member的“头部信息”中，有关于导入名应该如何计算的属性。但是LIB.exe工具却没有这方面的参数可以调整，默认就是先前面给你加一个_下划线，然后方式是NoPrefix就是再把这个下划线去掉。也就是说，def文件中如果写的是function，那么它就先加一个下划线，变成_function，作为向链接器提供的符号。然后导入名生成方式是NoPrefix，也就是链接器在链接的时候会再从_function去掉前缀的下划线变回function作为从DLL导入的名。

这个导入名的计算方式有

IMPORT_ORDINAL：通过标号导入，此时不会计算导入名
IMPORT_NAME：原原本本的，和向链接器提供的符号保持一致
IMPORT_NAME_NOPREFIX：不带前缀的，LIB.EXE生成的就是这种。前缀是指?、@或者可选的下划线_
IMPORT_NAME_UNDECORATE：不带前缀并且只取@之前的部分，此时如果向链接器提供的符号名是_function@4，那么导入名就是function，也就是我们需要的。

有了这些资料，思路就非常清楚，比如有以下两个函数

__declspec(dllimport) int __stdcall add2(int, int);
__declspec(dllimport) int __stdcall add3(int, int, int);

然后DLL里的导出名分别是add2和add3而不是add2@8和add3@12，此时可以写这样一个DEF文件

LIBRARY doadd
EXPORTS
  add2@8
  add3@12

此时生成的lib文件中，向链接器提供的符号这一边已经是所需要的_add2@8和_add3@12了。然后这个时候要修正的是导入名计算方式，因为现在是IMPORT_NAME_NOPREFIX，要改成IMPORT_NAME_UNDECORATE才行。这个时候就要用十六进制编辑器来修改，但是手工做这种事情实在太麻烦，这种事情应该给程序去做。所以就写了个工具，来解决这种问题。

图片为修改一个函数的导入名计算方式后的截图。改完以后保存，就可以实现目的了。

这里给出这个自制工具的下载：（上传时间：2014年2月13日。工具有修改的话，这里可能不会同步更新。）

运行需要.net framework 2.0环境。修改完成后记得保存。

编译DLL的时候加了__declspec(dllexport)就能把符号导出，这是没问题的，也能生成一个导入库LIB，这个LIB用来以导入表的方式链接到DLL里的符号用。

但是在调用DLL里这些函数啊什么的时候，又有一个问题，就是写函数声明的时候，加__declspec(dllimport)也可以，不加也可以。经过对比研究，汇编级跟踪，大致弄明白是怎么一回事了。

使用__declspec(dllimport)声明的时候，生成的代码是 CALL [xxxxxxxx] 这样，其中的xxxxxxxx就是导入的符号在导入表中的地址，xxxxxxxx对应的符号是__imp__打头的那些。

如果不使用__declspec(dllimport)声明，那么生成的代码是 CALL xxxxxxxx这样的，其中xxxxxxxx指向的是一句 jmp [yyyyyyyy] 这样的代码，其中xxxxxxxx对应的符号是不带__imp__前缀的那些，yyyyyyyy是导入的符号在导入表中的位置。我推测这一句jmp（似乎俗称stub）是LIB文件中提供的代码。

也就是说在使用nasm编译一个obj来塞入LIB用来干点什么事的时候，对于__imp__系的符号，要用dd，放在.data节；对于不带__imp__前缀的符号，要用 jmp xxxxxxxx，放在.code节。

对了顺便说一下，如果是使用equ让它指向另外一个地址的话，我尝试的时候，让它指向extern的某个符号是失败的，最终会导致这个equ到另一个常量的符号没有导出，具体可见这篇博客。但是可以给它一个常量。

过程是这样子的，一天在百度知道上看到有人求助一段C++代码转成VB。我又不熟悉VB，于是就顺手给封装成DLL给了他。

然后提问者回复说，能不能给搞成能用CreateObject方式创建对象的那种方式来调用。这一看，应该要com吧？但是我不会写com。想着稍微掌握一点以后可能也能用到，就去找教学啥的稍微尝试一下。

主要参考的文章是 http://icodeguru.com/VC%26MFC/InsideAtl/ch02c.htm 和 http://www.codeguru.com/cpp/com-tech/activex/tutorials/article.php/c5567/Step-by-Step-COM-Tutorial.htm 这两篇。一开始是看后者，后面也看了前者，结合起来，大概理清一点思路了。

因为COM组件是面向对象的，所以要制作COM组件前，先确定要有什么类。具体百度知道上那个问题在这里 http://zhidao.baidu.com/question/551068312.html 。根据教学，写了一个idl文件，定义如下内容

import "unknwn.idl";

[
uuid(EB35191C-DCC7-49DA-BC10-A1E0E9CEECA8),
object,
helpstring("Get Hash code for 156542994")
]
interface IGetHash : IUnknown
{
HRESULT GetHash([in]BSTR szStr, [out,retval]LONG* pOut);
}

[
uuid(AB18183F-A79B-49E7-92E8-514A056B2FCB),
helpstring("Library for GetHash, by 156542994")
]
library MyGetHashLib
{
importlib("stdole32.tlb");
interface IGetHash;
}

里面的uuid是用软件生成的。写了这么一个gethash.idl以后，用midl工具处理一下，生成gethash_i.c, gethash.h, gethash.tlb等文件。

然后是类的编写，从IGetHash派生出CGetHash类，写上GetHash的实现，以及从IUnknown里面来的AddRef的实现、Release的实现、QueryInterface的实现。这些函数都是stdcall方式调用的。AddRef和Release的实现没什么好说，就是智能指针而已，在Release到0的时候要释放，delete this ←这样。

至于QueryInterface，它的意思是当前对象能不能转换成另一个接口的指针。因为我这个CGetHash的父类有IUnknown和IGetHash，所以当参数中指定的那个iid为IID_IUnknown和IID_IGetHash的时候，调用AddRef并给输出参数赋值，同时返回S_OK；否则就输出参数置0。

这样这个类就写出来了，不过还没办法用。COM组件用了工厂模式，要为这个类写一个工厂才行。于是从IClassFactory派生出一个CClassFactory，实现IUnknown的AddRef、Release、QueryInterface和实现IClassFactory的CreateInstance即可。其中CreateInstance的第一个参数pOuter，这个到底是COM的什么特性我还不知道，也没有用到，总之按照教学说的如果这个不是0就返回CLASS_E_NOAGGREGATION好了。然后CreateInstance里面的实现要偷懒一点，就直接创建出CGetHash对象，然后用它的QueryInterface把iid和pOut送进去，之后Release。因为如果参数符合，那么在QueryInterface里面会增加引用计数，Release的时候也就不会被删掉。这样CreateInstance也搞定了。LockServer是啥我不知道，看msdn上介绍似乎是什么lock了以后能更快还是啥的……总之直接返回S_OK。有说法是Lock的时候调用AddRef然后Unlock的时候调用Release就行。不过不太清楚……刚学

dll形式的COM的最重要接口DllGetClassObject，这个接口是用来获取工厂的。三个参数：clsid、iid和pOut。其中clsid代表类的id，就是刚刚那个CGetHash。也就是说不光是IGetHash要有id，这个CGetHash尽管不对外暴露但是也还是要有id。于是用id生成器给它生成一个id。到时候这个函数被回调的时候，比如VB里面用了CreateObject来创建它，clsid会送进来CLSID_CGetHash，iid会送进来IID_IClassFactory，判断好这个情况，其他时候丢个CLASS_E_CLASSNOTAVAILABLE就行。

至于那些Register和Unregister要写不写都行，写的话就你自己维护，不写的话就用户手工去改注册表或者什么的都可以，总之在HKEY_CLASS_ROOT里面添加一个代表你类的名字的键值比如MyGetHashLib.GetHash，在下面建立一个CLSID把你类（CGetHash）的id写进去，然后在HKEY_CLASS_ROOT的CLSID下面建一个你类的id为名的子键，下面创建一个ProgID一个InprocServer32，前者一样填MyGetHashLib.GetHash，后者填你dll的完整路径，大功告成

在VB里面添加引用之后就可以这么调用：

Dim a As IGetHash
Set a = CreateObject("MyGetHashLib.GetHash")
MsgBox Hex(a.GetHash("cc"))

比用Declare那个看起来是不是高端洋气了？w

把tlb文件内嵌进去的话，根据 http://support.microsoft.com/kb/122285/en-us 这篇文章的说法，资源id设1，类型typelib即可。不过这样就有一个疑问，因为xp style的时候也要求资源id设1……如果想同时都要的话不知道应该如何处理呢。

下载代码： gethashcom

之后我想了想，既然它都是通过QueryInterface来的，那么我只要在它Query的时候返回正确的接口就成了，现在既然这个类这么简单，那我把工厂和产品合起来也未尝不可。

于是出来了下面这个把IClassFactory和IGetHash合起来的版本

下载代码： gethashcom2

画了个示意图，希望能好懂一些。以后自己要是忘了也可以参考

DllCanUnloadNow最好也实现一下（本例中没有写这个……），目测判断这个dll创建出来的对象是不是全部已经全部没有引用了，如果是，那么就返回S_OK；不是，就返回S_FALSE

.net倒是很方便，直接控件拖拖拖，这个都给你实现了的。

但是sdk或者mfc里就比较麻烦。Tab控件上面的页面如果切换了，不是里面的内容要跟着变吗？但是tab控件不管里面的内容变，它只管发一个通知给你。怎么变你自己实现。于是最方便的方法就是弄很多子窗口，在切换的时候更换子窗口。

其实就是你先GetClientRect一下拿到它整个的矩形区域，然后TabCtrl_AdjustRect把这“整个”转换成“里面”。之后你去创建子窗口就可以了。

那个TabCtrl_AdjustRect说真的确实是早就看到了，但是它的说明看得半懂不懂。

msdn上有，不过临时去翻msdn挺麻烦的，因为没记住在哪个分类里面的话（汗

分类在Windows Desktop App Development——Windows Application UI Development——Windows Controls——Visual Styles——Enabling Visual Styles

然后若遇上网络很慢，要人命

首先是VC2005或以上的解决方法：

直接链接器参数搞起

"/manifestdependency:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'"

 

或者用#pragma加进去

#pragma comment(linker,""/manifestdependency:type='win32' \
name='Microsoft.Windows.Common-Controls' version='6.0.0.0' \
processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'"")

 

然后调用InitCommonControls();，链接到 ComCtl32.lib即可

但是msdn里面专门注明了要vs2005以上。大概以前版本不行吧。

然后就是用manifest清单文件的办法，是一个xml，以资源方式加入：

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*' />
    </dependentAssembly>
  </dependency>
</assembly>


 

资源类型是24（RT_MANIFEST），
资源id是1（CREATEPROCESS_MANIFEST_RESOURCE_ID）。不是1不知道行不行，也许可以。

然后调用InitCommonControls();，链接到 ComCtl32.lib即可

里面这些YourApplication啥的省略掉它就赫然不能启动了。略烦……不想写的时候就这么留着吗。

2014-1-2添加：链接器如果没有/MANIFEST:NO或者用了/MANIFEST的话，会生成一个manifest文件。如果前面用的是pragma方法，此时可以得到一个小得多的manifest文件。基于此，我把上面那个xml的内容简化成我得到的manifest文件的内容了，本来是例子里的，长不少。

vc6里加入这样的资源，按钮之类的也能出xp style了。目测MinGW GCC下应该也行。

2013-6-5补充：注意啊！不InitCommonControls它可能连对话框都不出来了！所以一定要这个啊！我今天解决的一个问题就是因为没有这个……