现有如下环境：两台WEB服务器，服务器A和服务器B，分别拥有2个独立的公网IP。服务器A上准备安装反向代理，并且要保留服务器A上原有的IIS服务。反向代理在绑定在80端口，通过服务器A的80端口可以访问服务器A和服务器B上的WEB服务。现有如下两种解决方案：
1、服务器A上，将SquidNT运行在80端口，WEB服务运行在81端口。但是这样会导致WEB服务器Redirect的时候暴露真实端口影响正常访问。当访问http://target/path，会跳转成http://target:81/path/。
2、将Squid和IIS分别绑定到不同的IP，Squid运行在公网IP上，IIS站点运行在127.0.0.1上。但是IIS5.0有个BUG，就是不管你设置站点绑定到什么IP，他都会抢先占绑定所有的IP地址。所以必须让Squid先于IIS运行，先于IIS运行在127.0.0.1:80上。
现在采用第二种方案，并通过修改注册表将Squid设置为IIS的Dependence服务，使得Squid先于IIS启动。

打开配置文件Squid.conf，进行下面的设置：

httpd_accel_host virtual  #因为要代理多个WEB服务器，所以开启虚拟主机功能
httpd_accel_port 80
httpd_accel_with_proxy off  #关闭正常代理功能
httpd_accel_uses_host_header on

http_port 61.121.xxx.60：80  #反向代理监听端口，帮定到公网IP
icp_port 0    #关闭icp
htcp_port 0    #关闭htcp
snmp_port 0    #关闭snmp
hosts_file c:/squid/etc/hosts.conf #设置hosts文件进行方向代理的域名解析

hosts.conf格式如下：

IP1 DNSName1
IP2 DNSName2

问题原因：Machine Debug Manager服务被禁用

解决方法：
1、开启Machine Debug Manager服务
2、运行“dcomcnfg.exe”，在应用程序一栏中找到“Machine Debug Manager”，打开属性，切换到到“位置”选项卡，取消“在这台计算机上运行应用程序”。
3、关闭DCOM。设置注册表“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole”下键“EnableDCOM”值为“N”

首先要保证MSN Messenger工具—选项—常规中的“连接到Internet时允许自动登录”和“当我登陆到windows时自动运行Messenger”处于uncheck状态。然后

[消除打开IE时自动启动MSN Messenger的方法]
键名：[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\
{FB5F1910-F110-11d2-BB9E-00C04F795683}]
方法：选择此键，右键，改名为
-{FB5F1910-F110-11d2-BB9E-00C04F795683}
即加一个\’-\’，反之则恢复

[消除登陆hotmail就自动启动MSN Messenger的方法]
打开注册表，定位到
HKEY_CLASSES_ROOT\\CLSID\\{4F07F79F-087F-42cf-8B36-7A88D06088E9}\\InprocServer32
把msgsc.dll改名为hidemsgsc.dll

[消除打开OE时就自动启动MSN Messenger的方法1]
1.在Outlook Express里设置：工具—选项—其他，不选“自动登录MSN messenger”
2.注册表中搜索{FB7199AB-79BF-11D2-8D94-0000F875C541} , 将里面的LocalServer32键值清空。

[消除打开OE时就自动启动MSN Messenger的方法2]
键名：[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Outlook Express]
健值名：Hide Messenger（没有则新建之）
类性：REG_DWORD （其值为DWORD）
值：2=启用

在BCB中，使用了__closure关键字扩展了标准C++，从而实现了委托：

typedef void __fastcall (__closure *FCallBack)(int);

class CDelegate
{
public:
    void __fastcall Callback(int param)
    {
        ShowMessage("Call Times: "+String(param));
        return;
    }
};

class CTest
{
public:
    FCallBack pcallback;
    CTest()
    {
        CDelegate delegate;
        pcallback=delegate.Callback;
        for(int i=0;i<10;i++){pcallback(i);}
    };
};

然而，在标准C++中不支持委托，只提供成员函数指针(member function pointers)。这个东西用起来繁琐，写出来的代码猥琐：

class CCallBack
{
public:
    void Callback(int param)
    {
        printf("Call Times: %d\n",param);
        return;
    }
};

typedef void (CCallBack::*FCallback)(int);

class CTest
{
public:
    FCallback pcallback;
    CTest()
    {
        CCallBack cb;
        pcallback=&(CCallBack::Callback);             //比较：delegate.Callback;
        for(int i=0;i<10;i++){(cb.*pcallback)(i);}    //比较：pcallback(i);
    }
};

使用"__closure"关键字，没有对象类型的限制；而使用成员函数指针必须在声明时就确定对象类型。换句话说，成员函数指针不支持透明调用。其实，实现成员函数的透明调用的汇编代码十分简单。来看看BCB的"__closure"是如何实现的。先来猜猜下面代码用BCB编译后的运行结果：

#include <stdio.h>

void (__closure *p)(int);

int main(int argc, char* argv[])
{
    printf("%d\n",sizeof(p));
    return 0;
}

该代码的功能是打印一个“闭包(closure)指针”的大小。结果是什么？是8。出乎意料么？看来这并不是一个普通的指针。那多出来的4字节究竟储存了什么？在解释这个问题前，先要说说对象成员函数是如何调用的。众所周知，普通函数调用，如__stdcall,__cdecl等，是先将参数逐一压入堆栈，然后使用call指令条转到目标函数中执行。而C++中调用对象成员函数采用__thiscall调用方式，先将参数逐一压入堆栈，然后将对象的this指针放入ecx寄存器，最后在调用call指令。所以调用一个对象的成员函数不但要知道成员函数的地址，还要知道对象的地址。描述闭包指针内存布局的C伪代码如下：

//执行闭包指针的赋值语句时会填充这个结构
typedef struct{
    void *ptr_this;    //存放对象的this指针
    void *ptr_mfunc;   //存放成员函数的地址
}PTR_CLOSURE;

知道了原理，就可以用标准C++模拟这个实现。只需要用两个变量来分别保存代理对象的地址和代理对象回调函数的地址就可以了。然后用内嵌汇编代码来模拟__thiscall调用。不过在实际操作中碰到了一点问题：编译器死活也不让我得到成员函数的地址，似乎只可以将成员函数地址赋值给成员函数函数指针。无论是用(void*)强制转换，还是xxxx_cast转换，都无法将成员函数地址赋值给一个void*类型的变量。最后，不得不采取了一些非常常规段才达到目的：

#include <stdio.h>

class CDelegate
{
public:
    void Callback(int param)    //回调函数
    {
        printf("this:0x%08X – param:%d\n",this,param);
        return;
    }
};

class CTest
{
private:
    void *pObjs;        //指向代理对象的指针
    void *pCallback;    //指向代理对象回调函数的指针
    void Delegate(int param){
        void* tmp1=pObjs;
        void* tmp2=pCallback;
        __asm{
            push ecx        ;保存this指针
            push param      ;压入回调函数的参数
            mov  ecx,tmp1   ;放入pObjs的this指针
            call tmp2       ;调用CDelegate的成员函数
            //add  esp,4    (*注)
            pop  ecx        ;恢复this指针
        }
    };
public:
    CTest()
    {
        pObjs=new CDelegate;
        typedef void (CDelegate::*FCallback)(int);
        (FCallback&)pCallback=&CDelegate::Callback;    //利用引用来强制类型转换
        for(int i=0;i<10;i++){
            Delegate(i);    //试试效果
        }
    };
};

CTest test;
int main()
{
    return(0);
}

(*注)：在John Robbins的《应用程序调试技术》一书中，将__thiscall调用描述为“调用者平衡堆栈”，而我实际调试下来却发现是“调用对象平衡堆栈”。所以不需要"add  esp,4"操作。

用上面的代码能实现高效的委托，但是也存在一个致命的弱点——它不支持多重继承的代理类。也就是说，CDelegate中的Callback成员函数必须是由该类自己实现，或是从别的类中单一继承的。究竟为什么会产生这个问题还必须从C++的对象模型说起。

对于VC编译器，一个对象的所占内存是由虚函数表指针和非静态成员变量组成的。成员函数通过对象的this指针加上偏移量来访问成员变量。当一个类被继承时，编译器会将基类和派生类所占的内存空间合并。问题就此产生了：基类的成员函数并不知道他已经被继承，仍旧使用原来的偏移量。当一个类被单一继承时，编译器童过将基类对象放在派生类对象的首部来解决这个问题。这么一来，基类的成员函数仍旧能够使用原来的偏移量来访问基类对象的成员变量。但如果是多重继承的话，必然会有一个基类对象的偏移量会发生改变。例如：

class A{
    int ma;
};
class B{
    int mb;
    void funcb();
};
void B::funcb(){mb=1;}
class C:public A,public B{
    … …
};

在这种情况下，编译器只能将A放在C的首部，而B只能跟在A的后面了。这么一来，派生类C的成员函数funcb就不能通过原来的this指针加偏移量来访问成员变量mb了。如果有如下调用：

C cobj;
cobj->funcb();

编译器会自动修正this指针，使得传递的this指针指向cobj中正好是B对象的位置。也就是说，此时在funcb内部的this指针不指向cobj的首地址，而是指向cobj的内部，准确的说是cobj首地址偏移一个sizeof(A)的位置。不单单是多重继承，虚继承也会碰到类似的问题。

对于BCB的闭包指针，编译器会修正存放在PTR_CLOSURE结构中的this指针。但是在我们实现的代码中，this指针只是死板地指向对象的首地址。如果我们在写代码的时候去手工修正它显然是愚蠢的。我们只好保证代理类不是多重继承或是虚继承的，至少要保证用于回调成员函数不是从别的基类中多重继承来的。毕竟，MFC中的类也不支持多重继承的，那就将究着用吧。

几天前看到CSDN上有人问起这个问题。原贴见:http://community.csdn.net/Expert/TopicView.asp?id=3875259。因为我最近也在学习C++，所以对这个问题产生了兴趣。在这篇文章中，我会对该贴中提出的一些错误方法进行逐一分析，并给出解决这个问题的一点建议。

正如该贴中的有些回答所提到的那样——指针delete后，最好将它赋值为NULL。这样方便在以后通过检查该指针来确定对象是否已经析构。但在某些情况下，我们会将会将一个对象的地址赋于多个指针变量。这样一来，在delete对象时，很难做到将所有指向该对象的指针全部赋值为NULL。

首先，有人提出用IsBad*系列的Debug API来判断指针指向的内存是否可读写。当然，这种方法是不可行的。C++对象的内存是分配在栈或者堆中的。不管何种情况下，栈内存永远是可读写的。而在系统堆中分配的内存的一个特性就是无法直接干预内存分页的提交和回收。也既是说，用new操作符分配的内存，即使delete后，也无法预料该内存是否被系统回收，它仅仅被系统标记为未使用而已。所以IsBad*系列API是无法判断某指针指向的对象是否已经被析构。

有人又提出了使用使用C++的错误处理来处理异常。这也是不可行的。除非该对象包含虚函数，并且你调用了虚函数，才有可能发生异常。而在大多数情况下，使用一个被析构的对象并不会发生异常。但是你的代码会影响到程序中的其他的数据，最终导致程序的运行结果异常。

还有人提出了如下的方法：

class cfoo
{
public bool isValid()
{
    if (this != NULL)
        return true;
    else
        return false;
}
}

这种方法显然是可笑的。此人估计是个新手（当然，我也是新手）。对象内部的this指针时由调用者决定的。调用者在调用成员函数前，会将当前对象的地址保存到ECX寄存器。成员函数内部便使用ECX寄存器中保存的值来作为this指针的值。下面的代码也许可以让你更深刻得理解：

#include <stdio.h>

class ctest
{
public:
 void PrintThisPtr();
};

void ctest::PrintThisPtr()
{
 printf(“0x%08X\n”,this);
}

int main()
{
 ctest *p=(ctest*)0×12345678;
 p->PrintThisPtr(); //It will print “0×12345678″
 /*————————
 这句代码的汇编形式为：
 mov ecx, 12345678H
 call ctest::PrintThisPtr
 ————————–*/
 return 0;
}

最后又有人提出了一个方法：

class foo
{
public:
   foo():m_Valid(TRUE){}
   ~foo(){m_Valid = FALSE;}
   BOOL IsValid()
   {
      try
      {
         if(m_Valid)
            return TRUE;
         else
            return FALSE;
      }
      catch(…)
      {
         return FALSE;
      }
   }

private:
   BOOL m_Valid;
};

可惜，这个方法仍旧不可行。在一个对象被析构后，该对象原先占用的内存就被标识为未使用（堆和栈的做法是不一样的）。在程序运行一段时间后，原先的这块内存会被一些无法预见的数据所覆盖，m_Valid的值也无法保证其正确性。后来，提出该方法的人又改进了代码：给m_Valid赋一个特殊的值，比如0xEFEFEFEF。这仅仅是一个讨巧的办法，你也许可以在混乱编程大赛中使用该方法，但是你不能在正式的工程中使用这个方法。这个方法无法保证100%不出问题。一个最容易想到的反例就是：在这块内存中，又分配了一个新的foo对象，新对象的m_Valid成员和旧对象的重合。

经过前面的分析，能够得到一个结论：C++对象的指针指向的仅仅是块普通的内存区域，和C语言中的结构体没有什么区别。所以，要判断一个指针指向的对象是否已经被析构必须借助于不依赖对象的外部标记才能实现。一个经常使用的方法就是双重指针。直接指向对象的指针仅有一个，引用对象必须使用一个指向该指针的双重指针。当对象析构时，将那个直接指向对象的指针赋值为NULL。其他的双重指针就可以根据这个指针的值来判断对象是否被析构。

#include <stdio.h>

class CTest{
public:
    int m;
};

int main()
{
CTest *handle=new CTest;
CTest** p1=&handle;
CTest** p2=&handle;
CTest** p3=&handle;
delete handle;
handle=NULL;
if(NULL!=handle)
{
(*p1)->m=100;
(*p2)->m=200;
(*p3)->m=300;
}else{
printf(“对象已经析构”);
}
return 0;
}

这个直接指向对象的指针在此处就起到了句柄的作用。还有一种方法：

#include <stdio.h>

class CTest{
public:
    CTest(bool *pIsValid)
    {
        *pIsValid=true;
        m_pIsValid=pIsValid;
    };
    ~CTest()
    {
        *m_pIsValid=false;
    }; 
private:
    bool *m_pIsValid;
};

bool IsValid;

int main()
{
 CTest *ptr=new CTest(&IsValid);
 delete ptr;
 
 if(IsValid)
 {
  printf(“对象还存在”);
 }else{
  printf(“对象已经析构”);
 }
 return 0;
}

每创建一个对象，必须有一个IsValid对应。如果要动态创建多个对象的话，IsValid也需要动态创建，并且IsValid的生存时间必须大于它标示的对象。但是IsValid的生存时间也不能是永久的，这样就产生内存泄漏了。

不管采用什么方法，必须依靠外部标示来表示对象的生存期，而且要尊循以下原则：每个对象必须与唯一的外部标示对应；每个外部标示也对应唯一的对象；外部标示的生存时间必须大于对象的生存时间；当确定不再需要查询对象的生存期时，应当释放外部标示。如果情况复杂的话，最好实现句柄表来查询。

#include <stdio.h>
#define HT_LEN 256
class foo
{
public:
 foo(){};
 ~foo(){};
 void print(){printf(“%d\n”,m);};
 int m;
};

typedef struct
{
 unsigned int handle;
 foo *ptr;
} HTABLE;

HTABLE g_HandleTable[HT_LEN];
unsigned int g_MaxHandle;

foo* GetObject(unsigned int handle)
{
 int i;
 for(i=0;i<HT_LEN;i++)
 {
  if(handle==g_HandleTable[i].handle)
   return g_HandleTable[i].ptr;
 }return NULL;
}

bool DeleteObject(unsigned int handle)
{
 int i;
 for(i=0;i<HT_LEN;i++)
 {
  if(handle==g_HandleTable[i].handle)
  {
   delete g_HandleTable[i].ptr;
   g_HandleTable[i].handle=0;
   g_HandleTable[i].ptr=NULL;
   return true;
  }
 }return false;
}

unsigned int CreateObject()
{
 int i;
 for(i=0;i<HT_LEN;i++)
 {
  if(0==g_HandleTable[i].handle)
  {
   g_HandleTable[i].ptr=new foo;
   g_HandleTable[i].handle=++g_MaxHandle;
   return g_HandleTable[i].handle;
  }
 }return 0;
}

int main()
{
 unsigned int hfoo=CreateObject();
 foo *p=GetObject(hfoo);
 if(NULL!=p)
 {
  p->m=100;
  p->print();
  printf(“HANDLE VALUE:%d\n”,hfoo);
 }else{
  printf(“对象不存在”);
 }
 DeleteObject(hfoo);
 return 0;
}

以上代码还比较简陋，还可以慢慢完善。

void function(int *pval)
{
 *pval=100;
 //pval=100;先不考虑此处类型转换的错误
 //该代码只能改变堆栈中临时指针变量的地址，而不能改变指针指向对象的值
}

int main()
{
 int x=200;
 function(&x);
 return 0;
}

为了能透明地使用指针来访问变量，C++中引入了“引用”的概念：

void function(int &refval)
{
 refval=100;
}

int main()
{
 int x=200;
 function(x);
 //当然，如下调用也可以。但这样做就失去引入”引用”的原本意义了
 int &refx=x;
 function(refx);
 return 0;
}

这样一来，只要改一下函数声明，就可以在源代码的级别上实现指针访问和一般访问的一致性。可以把“引用”想象成一个不需要“*”操作符就可以访问变量的指针。上面的代码的C语言形式的伪代码：

void function(int *refal)
{
 *refval=100;
}

int main()
{
 int x=200;
 int *refx=&x;
 function(&x);
 function(refx);
 return 0;
}

根据函数的声明，C++编译器在遇到“function (x);”语句时，会自动转换成“function(&x);”形式的二进制代码。

来看“int **pp”和“int *&rp”区别。前者是一个指向指针的指针；后者是一个指针的引用。如果这样看不明白的话，变换一下就清楚了：

typedef int * LPINT;
LPINT *pp;
LPINT &rp;

下面这两个函数的二进制代码是一致的：

void function1(int **p)
{
 **p=100;
 *p=NULL;
}

void function2(int *&ref)
{
 *ref=100;
 ref=NULL;
}

在调用function1或function2时，编译器编译的二进制代码都将传递一个双重指针。

“引用”仅仅是为了给重载操作符提供了方便之门，其本质和指针是没有区别的。

]]> http://blog.donews.com/tabris17/archive/2005/03/20/307601.aspx/feed 0 http://blog.donews.com/tabris17/archive/2005/03/05/295686.aspx http://blog.donews.com/tabris17/archive/2005/03/05/295686.aspx#comments Sat, 05 Mar 2005 15:12:00 +0000 四不象 http://blog.donews.com/tabris17/archive/2005/03/05/295686.aspx 有时，我为了编译仅有一个源文件的C/C++代码，不得不建立一个VC的工程，工程编译后会生成一堆文件，我不需要搞得如此庞大。后来我改用命令行编译，但是我需要输入冗长的参数来编译。为了一劳永逸地解决这个问题，我就试着将我常用的EditPlus设置为编译器的IDE。

只要修改一下VC安装目录下的”C:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.BAT”文件，然后在EditPlus的“用户配置工具”中“添加工具”就可以了。

“VCVARS32.BAT”这个批处理文件的作用是设置编译器的环境变量，将该文件复制到EditPlus的安装目录下，在文件末尾添加如下命令：

@echo on
@cl %1 /ML /GX /O2 /D “WIN32″ /D “NDEBUG” /D “_CONSOLE” /D “_MBCS” /link “kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /incremental:no /machine:I386″

如果你还要生成asm中间代码的话可以在此处添加”/Fa”参数。

在EditPlus中添加一个用户工具，名叫“C/C++ 编译”。设置“命令”为”C:\Program Files\EditPlus 2\VCVARS32.BAT”，这个文件就是刚才修改过的VCVARS32.BAT文件。然后设置“参数”为”$(FilePath)”；“初始目录”为”$(FileDir)”即可。现在只要在EditPlus中按下Ctrl+1（如果没有设置其他用户工具的话）就可以编译C/C++了。

不过VC编译器默认编译的EXE的”Subsystem”是”console”。如果要编译windows程序，必须在源代码中添加：

#pragma comment(linker,”/subsystem:windows”)

现在编译后仅仅生成一个obj和一个exe文件。好了，这个世界清静多了。