64位指的是cpu通用寄存器的数据宽度是64位的。

1 static_cast

用法：static_cast < type-id > ( expression )    

该运算符把expression转换为type-id类型，但没有运行时类型检查来保证转换的安全性。它主要有如下几种用法：

①用于类层次结构中基类和子类之间指针或引用的转换。

  进行上行转换（把子类的指针或引用转换成基类表示）是安全的；

  进行下行转换（把基类指针或引用转换成子类表示）时，由于没有动态类型检查，所以是不安全的。

②用于基本数据类型之间的转换，如把int转换成char，把int转换成enum。这种转换的安全性也要开发人员来保证。

③把空指针转换成目标类型的空指针。

④把任何类型的表达式转换成void类型。

注意：static_cast不能转换掉expression的const、volitale、或者__unaligned属性。

2 dynamic_cast

用法：dynamic_cast < type-id > ( expression )

该运算符把expression转换成type-id类型的对象。Type-id必须是类的指针、类的引用或者void *；

如果type-id是类指针类型，那么expression也必须是一个指针，如果type-id是一个引用，那么expression也必须是一个引用。

dynamic_cast主要用于类层次间的上行转换和下行转换，还可以用于类之间的交叉转换。

在类层次间进行上行转换时，dynamic_cast和static_cast的效果是一样的；

在进行下行转换时，dynamic_cast具有类型检查的功能，比static_cast更安全。

class B{

public:

       int m_iNum;

       virtual void foo();

};

class D:public B{

    public:

       char *m_szName[100];

};

void func(B *pb){

    D *pd1 = static_cast<D *>(pb);

    D *pd2 = dynamic_cast<D *>(pb);

}

在上面的代码段中，如果pb指向一个D类型的对象，pd1和pd2是一样的，并且对这两个指针执行D类型的任何操作都是安全的；

但是，如果pb指向的是一个B类型的对象，那么pd1将是一个指向该对象的指针，对它进行D类型的操作将是不安全的（如访问m_szName），

而pd2将是一个空指针。

另外要注意：B要有虚函数，否则会编译出错；static_cast则没有这个限制。

这是由于运行时类型检查需要运行时类型信息，而这个信息存储在类的虚函数表（

关于虚函数表的概念，详细可见<Inside c++ object model>）中，只有定义了虚函数的类才有虚函数表，

没有定义虚函数的类是没有虚函数表的。

另外，dynamic_cast还支持交叉转换（cross cast）。如下代码所示。

class A{

public:

        int m_iNum;

        virtual void f(){}

};

class B:public A{

};

class D:public A{

};

void foo(){

    B *pb = new B;

    pb->m_iNum = 100;

    D *pd1 = static_cast<D *>(pb);    //compile error

    D *pd2 = dynamic_cast<D *>(pb); //pd2 is NULL

    delete pb;

}

在函数foo中，使用static_cast进行转换是不被允许的，将在编译时出错；而使用 dynamic_cast的转换则是允许的，结果是空指针。

3 reinterpret_cast

用法：reinterpret_cast<type-id> (expression)

type-id必须是一个指针、引用、算术类型、函数指针或者成员指针。

它可以把一个指针转换成一个整数，也可以把一个整数转换成一个指针（先把一个指针转换成一个整数，

在把该整数转换成原类型的指针，还可以得到原先的指针值）。

该运算符的用法比较多。

(static_cast .与. reinterpret_cast比较，见下面 )

4 const_cast

用法：const_cast<type_id> (expression)

该运算符用来修改类型的const或volatile属性。除了const 或volatile修饰之外， type_id和expression的类型是一样的。

常量指针被转化成非常量指针，并且仍然指向原来的对象；

常量引用被转换成非常量引用，并且仍然指向原来的对象；常量对象被转换成非常量对象。

Voiatile和const类试。举如下一例：

class B{

public:

     int m_iNum;

}

void foo(){

const B b1;

b1.m_iNum = 100;            //comile error

B b2 = const_cast<B>(b1);

b2. m_iNum = 200;           //fine

}

上面的代码编译时会报错，因为b1是一个常量对象，不能对它进行改变；

使用const_cast把它转换成一个常量对象，就可以对它的数据成员任意改变。注意：b1和b2是两个不同的对象。

== ===========================================

== dynamic_cast .vs. static_cast

== ===========================================

class B { ... };

class D : public B { ... };

void f(B* pb)

{

D* pd1 = dynamic_cast<D*>(pb);

D* pd2 = static_cast<D*>(pb);

}

If pb really points to an object of type D, then pd1 and pd2 will get the same value. They will also get the same value if pb == 0.

If pb points to an object of type B and not to the complete D class, then dynamic_cast will know enough to return zero. However, static_cast relies on the programmer’s assertion that pb points to an object of type D and simply returns a pointer to that supposed D object.

即dynamic_cast可用于继承体系中的向下转型，即将基类指针转换为派生类指针，比static_cast更严格更安全。dynamic_cast在执行效率上比static_cast要差一些，但static_cast在更宽上范围内可以完成映射，这种不加限制的映射伴随着不安全性。static_cast覆盖的变换类型除类层次的静态导航以外，还包括无映射变换、窄化变换(这种变换会导致对象切片,丢失信息)、用VOID*的强制变换、隐式类型变换等...

== ===========================================

== static_cast .vs. reinterpret_cast

== ================================================

reinterpret_cast是为了映射到一个完全不同类型的意思，这个关键词在我们需要把类型映射回原有类型时用到它。我们映射到的类型仅仅是为了故弄玄虚和其他目的，这是所有映射中最危险的。(这句话是C++编程思想中的原话)

static_cast 和 reinterpret_cast 操作符修改了操作数类型。它们不是互逆的； static_cast 在编译时使用类型信息执行转换，在转换执行必要的检测(诸如指针越界计算, 类型检查). 其操作数相对是安全的。另一方面；reinterpret_cast 仅仅是重新解释了给出的对象的比特模型而没有进行二进制转换， 例子如下：

int n=9; double d=static_cast < double > (n);

上面的例子中, 我们将一个变量从 int 转换到 double。 这些类型的二进制表达式是不同的。 要将整数 9 转换到 双精度整数 9，static_cast 需要正确地为双精度整数 d 补足比特位。其结果为 9.0。而reinterpret_cast 的行为却不同:

int n=9;

double d=reinterpret_cast<double & > (n);

这次, 结果有所不同. 在进行计算以后, d 包含无用值. 这是因为 reinterpret_cast 仅仅是复制 n 的比特位到 d, 没有进行必要的分析.

因此, 你需要谨慎使用 reinterpret_cast.

Wt(音同'witty')是一个C++库，用以开发交互性Web应用。

Wt的API以widget为中心，将桌面GUI APIs的良好测试模式引入Web开发。 Wt为开发者提供了几乎所有Web实现细节的抽象，其中包括事件处理、图像支持、优雅降级（或渐进增强）、及良好的URL处理。

与其他诸多基于页面的开发框架相比，Wt可以创建状态化的应用，同时实现了高度的交互性和可访问性；其交互性体现在Wt可以综合使用各种技术，如Ajax等；其可访问性体现在Wt可以使应用在必要的时候支持纯HTML浏览器；这些特性的获得充分利用了自动的优雅降级或渐进增强。

Wt库还自带了应用服务器程序，可配置为独立的Web服务器，当然也允许通过FastCGI连同其他Web服务器进行整合。

交互性、安全性、可访问性

基于页面的开发框架（如PHP、JSP/JSF、Ruby on Rails等）没有实现底层基础技术的抽象，这些技术包括HTML/XHTML、JavaScript、CSS、Ajax、Forms、DHTML 、SVG/VML/Canvas等。显然，基于页面的开发框架必须要求开发者随时熟悉和掌握这些基本技术，同时当浏览器不支持时，还要为应用的优雅降级负责。另外，如果应用采取早期HTML页面为中心的设计模式，开发者不仅要实现控制器以告诉用户如何从一个页面跳转到另一个页面，而且还要在采用一些高级Ajax技术时手工设计和维护客户端与服务器端的通讯。

另一方面，就算是纯粹的Ajax框架，也要求开发者通过繁杂的JavaScript编程来处理浏览器的怪异行为和客户端与服务器端间的安全通讯，这些处理任何人都不能跳过去不与理会。同时，这些应用通常不能符合可访问性的原则，也不能很好被搜索机器人索引到。

安全方面，生成HTML或填充HTML模版很容易导致安全问题，如跨站脚本（XSS） 和 跨站请求伪造（CSRF）；XSS问题一般由（疏忽）允许嵌入JavaScript代码引起， CSRF问题一般由（相信）Cookies（可）作为认证手段引起。作为开发者，这些安全问题将是很难避免的，因为我们有时需要允许用户插入自己的JavaScript 代码来实现某些功能，但开发框架本身却没提供给我们过滤机制。

相反，使用Wt来部署Web应用可以完全用C++来开发，Wt自动产生所必须的 HTML/XHTML、CSS、Javascript、CGI、SVG/VML/Canvas和Ajax代码；与此同时，代码的安全性和浏览器兼容性等问题都将转交给Wt。例如，在可能的情况下， Wt将最大限度的使用JavaScript和Ajax，但在Ajax功能受限时，Wt也能保证系统功能运行正常。其原理是Wt将先启用纯HTML/CGI应用，随后在可能的情况下渐进增强至Ajax应用。另外，Wt提供了内置的安全性考虑。

典型应用举隅：

• 由于Wt C++ Web应用服务器占用较小的物理空间，故而可以为嵌入式系统 提供基于Web的GUIs；
• Wt可以为需要整合现有C++库的应用提供基于Web的GUIs, 这些 应用可能包括科学上的或工程上的应用；
• Wt可以创建从现有C++桌面应用到Web的有效渠道；
• Wt还可以应用于一些高性能、复杂的Web应用，这样的应用 一般具有高度定制、充分利用Ajax的特点，同时具有完全的可访问性和较高的 搜索引擎优化(SEO)需求

使用Wt的其他好处

• 可以使用我们熟悉的桌面GUI模式开发Web应用；
• Wt为我们提供了广阔的widgets集，这些widgets可以在环境不支持 JavaScript的情况下照常工作（当然，如果支持则效果更佳）；
• 在Wt中客户端与服务器端的验证和事件处理采用同一规范；
• Wt允许开发者选择XHTML和CSS来进行布局和样式编辑；
• Wt可生成标准的、兼容的HTML或XHTML代码；
• Wt采用内联VML、内联SVG、HTML 5 画布或PNG可生成应用于Web的可移植的、 反锯齿的图像，当然这些图像还可以轻松渲染为PDF格式；
• Wt可以避免常见的安全问题，因为Wt拥有对表示层的完全控制，并能够主动 过滤掉处于活动状态的标签和属性；Wt同时实现了业务逻辑的隐藏，并 通过状态化的设计简化了认证机制；
• 基于Wt的应用的载入时间极短且占用带宽也很低，究其原因是Wt中这些特点 仅受限于页面显示的复杂程度，而不是应用程序自身的尺寸；Wt还实现了所有的 常用技巧和方法，以优化应用的快速反应，Wt几乎做到了针对所有浏览器的优化；
• Wt提供了服务器端初始的事件处理，即服务器推或Comet， 这部分API使用简单、稳定且在所有浏览器上均能实现；
• Wt在服务器部署上，既可以使用内置的httpd，又可以使用FastCGI/ISAPI， 当然前者实施起来更简便易行。

下面的表格是我整理的 BMP 文件头的格式。

方便大家查询。

Bmp 的文件头是 54 , 以下都是 24 bit,

如果 图像大小是 720 * 480 , 那么文件大小是 : 54 + 720 * 480 *3 很好理解 ,

如果 图像大小是 333 * 333 那么文件大小就不是 : 54 + 333 * 333 *3 了 , 奇怪么 ?,

   总算引出高人了，我就公布答案吧： 
   如果图像大小是 1*7  那么文件大小就是: 54 + 1*7*3 + 7*n 了,
   如果图像大小是 3*5  那么文件大小就是: 54 + 3*5*3 + 5*n 了,
   如果图像大小是 11*77  那么文件大小就是: 54 + 11*77*3 + 77*n 了,
   总之是如果width * high * 3  + high * n ！＝ 4的倍数， 那么文件大小就是 54 +  width * high * 3 + high*n  了。

   n的取值范围是 0 ～～3   直到算下来，size是4的倍数。




转自：http://www.cnitblog.com/dvb-dvb/archive/2009/07/06/59865.aspx

In Windows XP, Windows Server 2003, and earlier versions of the Windows operating system, all services run in the same session as the first user who logs on to the console.  This session is called Session 0. Running services and user applications together in Session 0 poses a security risk because services run at elevated privilege and therefore are targets for malicious agents who are looking for a means to elevate their own privilege level.

The Microsoft Windows Vista operating system mitigates this security risk by isolating services in Session 0 and making Session 0 non-interactive.  In Windows Vista (and Windows Longhorn Server), only system processes and services run in Session 0.  The user logs on to Session 1.  On Windows Longhorn Server, subsequent users log on to subsequent sessions (Session 2, Session 3 etc).  This means that services never run in the same session as users' applications and are therefore protected from attacks that originate in application code.

Specific examples of affected driver classes include:

• Printer drivers, which are loaded by the spooler service
• All drivers authored with the User Mode Driver Framework (UMDF), because these drivers are hosted by a process in Session 0

Application classes affected by this feature:

• Services that create a UI
• A service that tries to use window message functions such as SendMessage and PostMessage to communicate with an application
• Applications creating globally named objects

Sessions in Windows XP / 2003
OK - so we've already mentioned that Session 0 poses a security risk because services run at elevated privilege.  The first user on the console also runs in Session 0 - which provides the most common attack vector used to target unsuspecting users.

Sessions in Windows Vista
In Windows Vista, Session 0 is created for services and user-mode drivers.  Session 1 is created for the first user who logs in.  Applications for this user run in Session 1.

• Each time a user logs in, a session is created for that user
• Each session contains a collection of windows stations
• The only supported interactive window station is WinSta0, so each session gets one of these
• WinSta0 contains the keyboard, mouse, and display device
• Each window station can contain multiple desktops, which have logical display surfaces and can be used to manage windows
• Messages can only be sent between processes that are on the same desktop (the hook procedure of a process can also only receive messages intended for windows created on the same desktop)
• Only one desktop at a time is active
• There are several default desktops – default, WinLogon (secure), and screen-saver

OK - so what could this actually look like in a real world scenario?  Consider the following example - if a service belonging to an application generates a UI element in Session 0 - for example a dialog box waiting for the user to click "OK" or "Cancel", the application is now waiting on the service, and the UI is not displayed in the user session.  From the user perspective, the application appears to be hung, when in actual fact it is performing quite normally, and patiently waiting for a user response that the user cannot see!

As you can imagine - this presents a problem for users, administrators and developers.  However, there are some quick mitigating factors to consider.

• If the application's service uses a UI, a built-in mitigation in Windows Vista allows the user to interact with the Session 0 UI in a special desktop.  This will make the UI specific to the application available and not the entire Session 0 desktop.
• If the application creates globally named objects, then use the Windows XP compatibility mode to ensure that the application will continue to work with the Session 0 services.

When testing applications for compatibility with Windows Vista, consider the following test scenarios:

• Test and verify the application on Windows XP in a Terminal Server mode or a Fast User Switching (FUS) mode.  If the application works properly on Windows XP in these scenarios, then it is very likely to work under Windows Vista.
• Verify that the application functions properly after applying the Window XP compatibility mode, which contains mitigation for some of the Session 0 issues.
• Test the driver in Windows Vista to ensure that it runs properly.  If that is not possible, test the driver in Windows XP with FUS enabled and multiple users logged on.  If the driver works correctly for second and subsequent logged-on users, it is not likely to be affected by the Session 0 changes in Windows Vista.  The only issues that this test does not detect are those related to the absence of the video driver in Session 0 in Windows Vista.

Finally, you can leverage the following Windows Vista capability solutions:

• Use client or server mechanisms such as remote procedure call (RPC) or named pipes to communicate between services and applications.
• Use the WTSSendMessage function to create a simple message box on the user's desktop.  This allows the service to give the user a notification and request a simple response.
• For more complex UI, use the CreateProcessAsUser function to create a process in the user's session.
• Explicitly choose either the Local\ or Global\ namespace for any named objects, such as events or mapped memory, which the service makes available.

And that will do it for a quick look at how Session 0 isolation affects Application Compatibility in Windows Vista.  The links below contain more information on some of the concepts discussed above.  Until next time ...

  1 #include  < windows.h >
  2 #include  < stdio.h >
  3
  4 //  挂钩指定模块hMod对MessageBoxA的调用
  5 BOOL SetHook(HMODULE hMod);
  6 //  定义MessageBoxA函数原型
  7 typedef  int  (WINAPI  * PFNMESSAGEBOX)(HWND, LPCSTR, LPCSTR, UINT uType);
  8 //  保存MessageBoxA函数的真实地址
  9 PROC g_orgProc  =  (PROC)MessageBoxA;
 10
 11
 12 BOOL EnableDebugPrivilege() 
 13 { 
 14 BOOL fOk  =  FALSE; 
 15 HANDLE hToken; 
 16
 17 if  (OpenProcessToken(GetCurrentProcess(), 
 18        TOKEN_ADJUST_PRIVILEGES,  & hToken)) 
 19 { 
 20        TOKEN_PRIVILEGES tp;
 21        tp.PrivilegeCount  =   1 ; 
 22        LookupPrivilegeValue(NULL, SE_DEBUG_NAME,  & tp.Privileges[ 0 ].Luid); 
 23        tp.Privileges[ 0 ].Attributes  =  SE_PRIVILEGE_ENABLED; 
 24        AdjustTokenPrivileges(hToken, FALSE,  & tp,  sizeof (tp), NULL, NULL); 
 25        fOk  =  (GetLastError()  ==  ERROR_SUCCESS); 
 26        CloseHandle(hToken); 
 27 }  
 28 return  fOk;  // 提升成功返回TRUE，失败返回FALSE 
 29 }
 30
 31 void  main()
 32 {
 33 if (EnableDebugPrivilege())
 34 {
 35 //  调用原API函数
 36 ::MessageBox(NULL,  " 原函数 " ,  " Hook Api " ,  0 );
 37 //  挂钩后再调用
 38 SetHook(::GetModuleHandle(NULL));
 39 ::MessageBox(NULL,  " 原函数 " ,  " Hook Api " ,  0 );
 40 }
 41
 42 }
 43
 44 //  用于替换MessageBoxA的自定义函数
 45 int  WINAPI MyMessageBoxA(HWND hWnd, LPCSTR lpText, LPCSTR lpCaption, UINT uType)
 46 {
 47 return  ((PFNMESSAGEBOX)g_orgProc)(hWnd,  " Hook API Sucess! " ,  " OK " , uType);
 48 return   0 ;
 49 }
 50
 51 BOOL SetHook(HMODULE hMod)
 52 {
 53 IMAGE_DOS_HEADER *  pDosHeader  =  (IMAGE_DOS_HEADER * )hMod;
 54 IMAGE_OPTIONAL_HEADER  *  pOptHeader  =
 55 (IMAGE_OPTIONAL_HEADER  * )((BYTE * )hMod  +  pDosHeader -> e_lfanew  +   24 );
 56
 57 IMAGE_IMPORT_DESCRIPTOR *  pImportDesc  =  (IMAGE_IMPORT_DESCRIPTOR * )
 58 ((BYTE * )hMod  +  pOptHeader -> DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);
 59
 60 //  在导入表中查找user32.dll模块。因为MessageBoxA函数从user32.dll模块导出
 61 while (pImportDesc -> FirstThunk)
 62 {
 63 char *  pszDllName  =  ( char * )((BYTE * )hMod  +  pImportDesc -> Name);
 64 if (lstrcmpiA(pszDllName,  " user32.dll " )  ==   0 )
 65 {
 66 break ;
 67 }
 68 pImportDesc ++ ;
 69 }
 70
 71 if (pImportDesc -> FirstThunk)
 72 {
 73
 74 //  一个IMAGE_THUNK_DATA就是一个双字，它指定了一个导入函数
 75 //  调入地址表其实是IMAGE_THUNK_DATA结构的数组，也就是DWORD数组
 76 IMAGE_THUNK_DATA *  pThunk  =  (IMAGE_THUNK_DATA * )
 77 ((BYTE * )hMod  +  pImportDesc -> FirstThunk);
 78 while (pThunk -> u1.Function)
 79 {
 80 //  lpAddr指向的内存保存了函数的地址
 81 DWORD *  lpAddr  =  (DWORD * ) & (pThunk -> u1.Function);
 82 if ( * lpAddr  ==  (DWORD)g_orgProc)
 83 { 
 84 DWORD oldProc;
 85 BOOL VirSu = VirtualProtect(lpAddr, sizeof (DWORD),PAGE_READWRITE, & oldProc);
 86 if (VirSu == TRUE)
 87 {
 88 //  修改IAT表项，使其指向我们自定义的函数，相当于“*lpAddr = (DWORD)MyMessageBoxA;”
 89 DWORD *  lpNewProc  =  (DWORD * )MyMessageBoxA;
 90 ::WriteProcessMemory(::GetCurrentProcess(), 
 91 lpAddr,  & lpNewProc,  sizeof (DWORD), NULL);
 92 }
 93 else
 94 {
 95 MessageBox(NULL, " Error! " , " a " , 0 );
 96 }
 97 return  TRUE;
 98 }
 99 pThunk ++ ;
100 }
101 }
102 return  FALSE;
103 }

有个郁闷的问题，在2003sp1下，不管是提升进程权限还是修改内存包含属性都成功！debug版本能成功！release就他娘的死不成功！郁闷死，遍寻高手无着落，暂时等着先。。。

1 进程与进程通信

　　进程是装入内存并准备执行的程序，每个进程都有私有的虚拟地址空间，由代码、数据以及它可利用的系统资源(如文件、管道等)组成。多进程/多线程是Windows操作系统的一个基本特征。Microsoft Win32应用编程接口(Application Programming Interface, API)提供了大量支持应用程序间数据共享和交换的机制，这些机制行使的活动称为进程间通信(InterProcess Communication, IPC)，进程通信就是指不同进程间进行数据共享和数据交换。
　　正因为使用Win32 API进行进程通信方式有多种，如何选择恰当的通信方式就成为应用开发中的一个重要问题，下面本文将对Win32中进程通信的几种方法加以分析和比较。

2 进程通信方法

2.1 文件映射
　　文件映射(Memory-Mapped Files)能使进程把文件内容当作进程地址区间一块内存那样来对待。因此，进程不必使用文件I/O操作，只需简单的指针操作就可读取和修改文件的内容。
　　Win32 API允许多个进程访问同一文件映射对象，各个进程在它自己的地址空间里接收内存的指针。通过使用这些指针，不同进程就可以读或修改文件的内容，实现了对文件中数据的共享。
　　应用程序有三种方法来使多个进程共享一个文件映射对象。
　　(1)继承：第一个进程建立文件映射对象，它的子进程继承该对象的句柄。
　　(2)命名文件映射：第一个进程在建立文件映射对象时可以给该对象指定一个名字(可与文件名不同)。第二个进程可通过这个名字打开此文件映射对象。另外，第一个进程也可以通过一些其它IPC机制(有名管道、邮件槽等)把名字传给第二个进程。
　　(3)句柄复制：第一个进程建立文件映射对象，然后通过其它IPC机制(有名管道、邮件槽等)把对象句柄传递给第二个进程。第二个进程复制该句柄就取得对该文件映射对象的访问权限。
　　文件映射是在多个进程间共享数据的非常有效方法，有较好的安全性。但文件映射只能用于本地机器的进程之间，不能用于网络中，而开发者还必须控制进程间的同步。
2.2 共享内存
　　Win32 API中共享内存(Shared Memory)实际就是文件映射的一种特殊情况。进程在创建文件映射对象时用0xFFFFFFFF来代替文件句柄(HANDLE)，就表示了对应的文件映射对象是从操作系统页面文件访问内存，其它进程打开该文件映射对象就可以访问该内存块。由于共享内存是用文件映射实现的，所以它也有较好的安全性，也只能运行于同一计算机上的进程之间。
2.3 匿名管道
　　管道(Pipe)是一种具有两个端点的通信通道：有一端句柄的进程可以和有另一端句柄的进程通信。管道可以是单向－一端是只读的，另一端点是只写的；也可以是双向的一管道的两端点既可读也可写。
　　匿名管道(Anonymous Pipe)是 在父进程和子进程之间，或同一父进程的两个子进程之间传输数据的无名字的单向管道。通常由父进程创建管道，然后由要通信的子进程继承通道的读端点句柄或写 端点句柄，然后实现通信。父进程还可以建立两个或更多个继承匿名管道读和写句柄的子进程。这些子进程可以使用管道直接通信，不需要通过父进程。
　　匿名管道是单机上实现子进程标准I/O重定向的有效方法，它不能在网上使用，也不能用于两个不相关的进程之间。
2.4 命名管道
　　命名管道(Named Pipe)是服务器进程和一个或多个客户进程之间通信的单向或双向管道。不同于匿名管道的是命名管道可以在不相关的进程之间和不同计算机之间使用，服务器建立命名管道时给它指定一个名字，任何进程都可以通过该名字打开管道的另一端，根据给定的权限和服务器进程通信。
　　命名管道提供了相对简单的编程接口，使通过网络传输数据并不比同一计算机上两进程之间通信更困难，不过如果要同时和多个进程通信它就力不从心了。
2.5 邮件槽
　　邮件槽(Mailslots)提 供进程间单向通信能力，任何进程都能建立邮件槽成为邮件槽服务器。其它进程，称为邮件槽客户，可以通过邮件槽的名字给邮件槽服务器进程发送消息。进来的消 息一直放在邮件槽中，直到服务器进程读取它为止。一个进程既可以是邮件槽服务器也可以是邮件槽客户，因此可建立多个邮件槽实现进程间的双向通信。
　　通过邮件槽可以给本地计算机上的邮件槽、其它计算机上的邮件槽或指定网络区域中所有计算机上有同样名字的邮件槽发送消息。广播通信的消息长度不能超过400字节，非广播消息的长度则受邮件槽服务器指定的最大消息长度的限制。
　　邮件槽与命名管道相似，不过它传输数据是通过不可靠的数据报(如TCP/IP协议中的UDP包)完成的，一旦网络发生错误则无法保证消息正确地接收，而命名管道传输数据则是建立在可靠连接基础上的。不过邮件槽有简化的编程接口和给指定网络区域内的所有计算机广播消息的能力，所以邮件槽不失为应用程序发送和接收消息的另一种选择。
2.6 剪贴板
　　剪贴板(Clipped Board)实质是Win32 API中一组用来传输数据的函数和消息，为Windows应用程序之间进行数据共享提供了一个中介，Windows已建立的剪切(复制)－粘贴的机制为不同应用程序之间共享不同格式数据提供了一条捷径。当用户在应用程序中执行剪切或复制操作时，应用程序把选取的数据用一种或多种格式放在剪贴板上。然后任何其它应用程序都可以从剪贴板上拾取数据，从给定格式中选择适合自己的格式。
　　剪贴板是一个非常松散的交换媒介，可以支持任何数据格式，每一格式由一无符号整数标识，对标准(预定义)剪贴板格式，该值是Win32 API定义的常量；对非标准格式可以使用Register Clipboard Format函数注册为新的剪贴板格式。利用剪贴板进行交换的数据只需在数据格式上一致或都可以转化为某种格式就行。但剪贴板只能在基于Windows的程序中使用，不能在网络上使用。
2.7 动态数据交换
　　动态数据交换(DDE)是使用共享内存在应用程序之间进行数据交换的一种进程间通信形式。应用程序可以使用DDE进行一次性数据传输，也可以当出现新数据时，通过发送更新值在应用程序间动态交换数据。
　　DDE和剪贴板一样既支持标准数据格式(如文本、位图等)，又可以支持自己定义的数据格式。但它们的数据传输机制却不同，一个明显区别是剪贴板操作几乎总是用作对用户指定操作的一次性应答－如从菜单中选择Paste命令。尽管DDE也可以由用户启动，但它继续发挥作用一般不必用户进一步干预。DDE有三种数据交换方式：
　　(1) 冷链：数据交换是一次性数据传输，与剪贴板相同。
　　(2) 温链：当数据交换时服务器通知客户，然后客户必须请求新的数据。
　　(3) 热链：当数据交换时服务器自动给客户发送数据。
　　DDE交换可以发生在单机或网络中不同计算机的应用程序之间。开发者还可以定义定制的DDE数据格式进行应用程序之间特别目的IPC，它们有更紧密耦合的通信要求。大多数基于Windows的应用程序都支持DDE。
2.8 对象连接与嵌入
　　应用程序利用对象连接与嵌入(OLE)技术管理复合文档(由多种数据格式组成的文档)，OLE提供使某应用程序更容易调用其它应用程序进行数据编辑的服务。例如，OLE支持的字处理器可以嵌套电子表格，当用户要编辑电子表格时OLE库可自动启动电子表格编辑器。当用户退出电子表格编辑器时，该表格已在原始字处理器文档中得到更新。在这里电子表格编辑器变成了字处理器的扩展，而如果使用DDE，用户要显式地启动电子表格编辑器。
　　同DDE技术相同，大多数基于Windows的应用程序都支持OLE技术。
2.9 动态连接库
　　Win32动态连接库(DLL)中的全局数据可以被调用DLL的所有进程共享，这就又给进程间通信开辟了一条新的途径，当然访问时要注意同步问题。
　　虽然可以通过DLL进行进程间数据共享，但从数据安全的角度考虑，我们并不提倡这种方法，使用带有访问权限控制的共享内存的方法更好一些。
2.10 远程过程调用
　　Win32 API提供的远程过程调用(RPC)使应用程序可以使用远程调用函数，这使在网络上用RPC进行进程通信就像函数调用那样简单。RPC既可以在单机不同进程间使用也可以在网络中使用。
　　由于Win32 API提供的RPC服从OSF-DCE(Open Software Foundation Distributed Computing Environment)标准。所以通过Win32 API编写的RPC应用程序能与其它操作系统上支持DEC的RPC应用程序通信。使用RPC开发者可以建立高性能、紧密耦合的分布式应用程序。
2.11 NetBios函数
　　Win32 API提供NetBios函数用于处理低级网络控制，这主要是为IBM NetBios系统编写与Windows的接口。除非那些有特殊低级网络功能要求的应用程序，其它应用程序最好不要使用NetBios函数来进行进程间通信。
2.12 Sockets
　　Windows Sockets规范是以U.C.Berkeley大学BSD UNIX中流行的Socket接口为范例定义的一套Windows下的网络编程接口。除了Berkeley Socket原有的库函数以外，还扩展了一组针对Windows的函数，使程序员可以充分利用Windows的消息机制进行编程。
　　现在通过Sockets实现进程通信的网络应用越来越多，这主要的原因是Sockets的跨平台性要比其它IPC机制好得多，另外WinSock 2.0不仅支持TCP/IP协议，而且还支持其它协议(如IPX)。Sockets的唯一缺点是它支持的是底层通信操作，这使得在单机的进程间进行简单数据传递不太方便，这时使用下面将介绍的WM_COPYDATA消息将更合适些。
2.13 WM_COPYDATA消息
　　WM_COPYDATA是一种非常强大却鲜为人知的消息。当一个应用向另一个应用传送数据时，发送方只需使用调用SendMessage函数，参数是目的窗口的句柄、传递数据的起始地址、WM_COPYDATA消息。接收方只需像处理其它消息那样处理WM_COPY DATA消息，这样收发双方就实现了数据共享。
　　WM_COPYDATA是一种非常简单的方法，它在底层实际上是通过文件映射来实现的。它的缺点是灵活性不高，并且它只能用于Windows平台的单机环境下。

 说实话买正版的的确也没有那么多钱，今天才开始用photoshop的最新版本。

在网上搜了几个序列号，安装的时候能安装但是当你再次启动软件的时候，他就已经和adob官网进行了连接自动检测，可想而知，序列号就无效了。

   想用最新版怎么办，破解吧，在网上找到了好多种方法，什么关闭防火墙的cs4的联网，不过这个方法没有成功，可能是我的方法不对。不过下面的方法很实用。

  因为官方的软件权威性比较高所以要安装官方的不过超大800多兆。破解吧。也是借用别人的方法。

破解方法 

 管用. 本人亲身试过的
以下为摘抄内容:

序列号：
1330-1082-3503-2270-3738-6738
1330-1776-8671-6289-7706-2916
1330-1567-6599-8775-4155-3745

绝对能用！！！！

第一步：下载完软件，要先解压出来。

第二步：安装，到了输入注册码界面时，选试用30天的选项，不要输入注册码。安装界面是全中文的，安装完软件是英文的。

第三步：打开软件，会跳出输入注册码界面，使用上面的注册码，输入，点下一步，进软件。

第四步：先退出软件，找到C:\WINDOWS\system32\drivers\etc里面的hosts文件,去掉其只读的属性，双击打开，选用记事本打开，

输入127.0.0.1 activate.adobe.com（中间有个空格），保存，退出, 屏蔽adobe激活服务器。
还不放心，将下面全部网址添加进去.

将下列网址加入HOSt
127.0.0.1 activate.adobe.com
127.0.0.1 practivate.adobe.com
127.0.0.1 ereg.adobe.com
127.0.0.1 activate.wip3.adobe.com
127.0.0.1 wip3.adobe.com
127.0.0.1 3dns-3.adobe.com
127.0.0.1 3dns-2.adobe.com
127.0.0.1 adobe-dns.adobe.com
127.0.0.1 adobe-dns-2.adobe.com
127.0.0.1 adobe-dns-3.adobe.com
127.0.0.1 ereg.wip3.adobe.com
127.0.0.1 activate-sea.adobe.com
127.0.0.1 wwis-dubc1-vip60.adobe.com
127.0.0.1 activate-sjc0.adobe.com
第五步：再打开软件，ok。（若不进行第四步，再启动软件时，又会跳出激活界面）。

这个主要是为了屏蔽软件与官方服务器连接的啊，如果软件想连接的话就让它不要连接官方了，连接本机就可以了。避免再次出现激活界面的啊。

再依次打开 窗口->扩展功能->连接->小三角形 连接及脱机选项设置不连接网络

下载源代码

一、什么是Unicode

　　先从ASCII说起，ASCII是用来表示英文字符的一种编码规范。每个ASCII字符占用1个字节，因此，ASCII编码可以表示的最大字符数是255（00H—FFH）。其实，英文字符并没有那么多，一般只用前128个（00H—7FH，最高位为0），其中包括了控制字符、数字、大小写字母和其它一些符号。而最高位为1的另128个字符（80H—FFH）被称为“扩展ASCII”，一般用来存放英文的制表符、部分音标字符等等的一些其它符号。
　　这种字符编码规则显然用来处理英文没有什么问题。但是面对中文、阿拉伯文等复杂的文字，255个字符显然不够用。
于是，各个国家纷纷制定了自己的文字编码规范，其中中文的文字编码规范叫做“GB2312—80”，它是和ASCII兼容的一种编码规范，其实就是利用扩展ASCII没有真正标准化这一点，把一个中文字符用两个扩展ASCII字符来表示，以区分ASCII码部分。
　　但是这个方法有问题，最大的问题就是中文的文字编码和扩展ASCII码有重叠。而很多软件利用扩展ASCII码的英文制表符来画表格，这样的软件用到中文系统中，这些表格就会被误认作中文字符，出现乱码。
　　另外，由于各国和各地区都有自己的文字编码规则，它们互相冲突，这给各国和各地区交换信息带来了很大的麻烦。
要真正解决这个问题，不能从扩展ASCII的角度入手，而必须有一个全新的编码系统，这个系统要可以将中文、法文、德文……等等所有的文字统一起来考虑，为每一个文字都分配一个单独的编码。

于是，Unicode诞生了。

　　Unicode也是一种字符编码方法，它占用两个字节（0000H—FFFFH）,容纳65536个字符，这完全可以容纳全世界所有语言文字的编码。
在Unicode里，所有的字符被一视同仁，汉字不再使用“两个扩展ASCII”，而是使用“1个Unicode”，也就是说，所有的文字都按一个字符来处理，它们都有一个唯一的Unicode码。

二、使用Unicode编码的好处

　　使用Unicode编码可以使您的工程同时支持多种语言，使您的工程国际化。
　　另外，Windows NT是使用Unicode进行开发的，整个系统都是基于Unicode的。如果调用一个API函数并给它传递一个ANSI（ASCII字符集以及由此派生并兼容的字符集，如：GB2312，通常称为ANSI字符集）字符串，那么系统首先要将字符串转换成Unicode，然后将Unicode字符串传递给操作系统。如果希望函数返回ANSI字符串，系统就会首先将Unicode字符串转换成ANSI字符串，然后将结果返回给您的应用程序。进行这些字符串的转换需要占用系统的时间和内存。如果用Unicode来开发应用程序，就能够使您的应用程序更加有效地运行。

下面例举几个字符的编码以简单演示ANSI和Unicode的区别：

三、使用C++进行Unicode编程

　　对宽字符的支持其实是ANSI C标准的一部分，用以支持多字节表示一个字符。宽字符和Unicode并不完全等同，Unicode只是宽字符的一种编码方式。

1、宽字符的定义

　　在ANSI中，一个字符（char）的长度为一个字节（Byte）。使用Unicode时，一个字符占据一个字，C++在wchar.h头文件中定义了最基本的宽字符类型wchar_t：

typedef unsigned short wchar_t;

从这里我们可以清楚地看到，所谓的宽字符就是无符号短整数。

2、常量宽字符串

　　对C++程序员而言，构造字符串常量是一项经常性的工作。那么，如何构造宽字符字符串常量呢？很简单，只要在字符串常量前加上一个大写的L就可以了，比如：

wchar_t *str1=L" Hello";

这个L非常重要，只有带上它，编译器才知道你要将字符串存成一个字符一个字。还要注意，在L和字符串之间不能有空格。

3、宽字符串库函数

为了操作宽字符串，C++专门定义了一套函数，比如求宽字符串长度的函数是

size_t __cdel wchlen(const wchar_t*);

　　为什么要专门定义这些函数呢？最根本的原因是，ANSI下的字符串都是以’\0’来标识字符串尾的（Unicode字符串以“\0\0”结束），许多字符串函数的正确操作均是以此为基础进行。而我们知道，在宽字符的情况下，一个字符在内存中要占据一个字的空间，这就会使操作ANSI字符的字符串函数无法正确操作。以”Hello”字符串为例，在宽字符下，它的五个字符是：
0x0048 0x0065 0x006c 0x006c 0x006f
在内存中，实际的排列是：

48 00 65 00 6c 00 6c 00 6f 00

　　于是，ANSI字符串函数，如strlen，在碰到第一个48后的00时，就会认为字符串到尾了，用strlen对宽字符串求长度的结果就永远会是1！

4、用宏实现对ANSI和Unicode通用的编程

　　可见，C++有一整套的数据类型和函数实现Unicode编程，也就是说，您完全可以使用C++实现Unicode编程。
如果我们想要我们的程序有两个版本：ANSI版本和Unicode版本。当然，编写两套代码分别实现ANSI版本和Unicode版本完全是行得通的。但是，针对ANSI字符和Unicode字符维护两套代码是非常麻烦的事情。为了减轻编程的负担，C++定义了一系列的宏，帮助您实现对ANSI和Unicode的通用编程。
　　C++宏实现ANSI和Unicode的通用编程的本质是根据”_UNICODE”（注意，有下划线）定义与否，这些宏展开为ANSI或Unicode字符（字符串）。

如下是tchar.h头文件中部分代码摘抄：

#ifdef  _UNICODE
typedef wchar_t     TCHAR;
#define __T(x)      L##x
#define _T(x)       __T(x)
#else
#define __T(x)      x
typedef char            TCHAR;
#endif 

A、实现字符和常量字符串定义的宏我们只列出两个最常用的宏：

注意：
　　“##”是ANSI C标准的预处理语法，它叫做“粘贴符号”，表示将前面的L添加到宏参数上。也就是说，如果我们写_T(“Hello”)，展开后即为L“Hello”

B、实现字符串函数调用的宏

C++为字符串函数也定义了一系列宏，同样，我们只例举几个常用的宏：

四、使用Win32 API进行Unicode编程

Win32 API中定义了一些自己的字符数据类型。这些数据类型的定义在winnt.h头文件中。例如：

typedef char CHAR; 
typedef unsigned short WCHAR;    // wc,   16-bit UNICODE character 
typedef CONST CHAR *LPCSTR, *PCSTR; 

#ifdef  UNICODE 
typedef WCHAR TCHAR, *PTCHAR;
typedef LPWSTR LPTCH, PTCH;
typedef LPWSTR PTSTR, LPTSTR;
typedef LPCWSTR LPCTSTR;
#define __TEXT(quote) L##quote      // r_winnt
#else   /* UNICODE */               // r_winnt
typedef char TCHAR, *PTCHAR;
typedef LPSTR LPTCH, PTCH;
typedef LPSTR PTSTR, LPTSTR;
typedef LPCSTR LPCTSTR;
#define __TEXT(quote) quote         // r_winnt
#endif /* UNICODE */                // r_winnt

#ifdef UNICODE
#define SetWindowText  SetWindowTextW
#else
#define SetWindowText  SetWindowTextA
#endif // !UNICODE

五、VC++6.0中编写Unicode编码的应用程序

　　VC++ 6.0支持Unicode编程，但默认的是ANSI，所以开发人员只需要稍微改变一下编写代码的习惯便可以轻松编写支持UNICODE的应用程序。
　　使用VC++ 6.0进行Unicode编程主要做以下几项工作：

1、为工程添加UNICODE和_UNICODE预处理选项。

　　具体步骤：打开[工程]->[设置…]对话框，如图1所示，在C/C++标签对话框的“预处理程序定义”中去除_MBCS，加上_UNICODE,UNICODE。（注意中间用逗号隔开）改动后如图2：

图一

图二

　　在没有定义UNICODE和_UNICODE时，所有函数和类型都默认使用ANSI的版本；在定义了UNICODE和_UNICODE之后，所有的MFC类和Windows API都变成了宽字节版本了。

2、设置程序入口点

　　因为MFC应用程序有针对Unicode专用的程序入口点，我们要设置entry point。否则就会出现连接错误。
　　设置entry point的方法是：打开[工程]->[设置…]对话框，在Link页的Output类别的Entry Point里填上wWinMainCRTStartup。

图三

3、使用ANSI/Unicode通用数据类型

　　微软提供了一些ANSI和Unicode兼容的通用数据类型，我们最常用的数据类型有_T ，TCHAR，LPTSTR,LPCTSTR。
　　顺便说一下，LPCTSTR和const TCHAR*是完全等同的。其中L表示long指针，这是为了兼容Windows 3.1等16位操作系统遗留下来的，在Win32 中以及其它的32位操作系统中，long指针和near指针及far修饰符都是为了兼容的作用，没有实际意义。P（pointer）表示这是一个指针；C（const）表示是一个常量；T(_T宏)表示兼容ANSI和Unicode，STR（string）表示这个变量是一个字符串。综上可以看出，LPCTSTR表示一个指向常固定地址的可以根据一些宏定义改变语义的字符串。比如：

TCHAR* szText=_T(“Hello!”);
TCHAR szText[]=_T(“I Love You”);
LPCTSTR lpszText=_T(“大家好！”);

MessageBox(_T(“你好”));

　　其实，在上面的语句中，即使您不加_T宏，MessageBox函数也会自动把“你好”字符串进行强制转换。但我还是推荐您使用_T宏，以表示您有Unicode编码意识。

4、修改字符串运算问题

　　一些字符串操作函数需要获取字符串的字符数(sizeof(szBuffer)/sizeof(TCHAR))，而另一些函数可能需要获取字符串的字节数sizeof(szBuffer)。您应该注意该问题并仔细分析字符串操作函数，以确定能够得到正确的结果。
ANSI操作函数以str开头，如strcpy()，strcat()，strlen()；
Unicode操作函数以wcs开头，如wcscpy，wcscpy()，wcslen()；
ANSI/Unicode操作函数以_tcs开头 _tcscpy(C运行期库)；
ANSI/Unicode操作函数以lstr开头 lstrcpy(Windows函数)；
考虑ANSI和Unicode的兼容，我们需要使用以_tcs开头或lstr开头的通用字符串操作函数。

六、举个Unicode编程的例子

第一步：
　　打开VC++6.0，新建基于对话框的工程Unicode，主对话框IDD_UNICODE_DIALOG中加入一个按钮控件，双击该控件并添加该控件的响应函数：

void CUnicodeDlg::OnButton1() 
{
	TCHAR* str1=_T("ANSI和UNICODE编码试验");
	m_disp=str1;
	UpdateData(FALSE);
}

第二步：
　　打开“控制面板”，单击“日期、时间、语言和区域设置”选项，在“日期、时间、语言和区域设置”窗口中继续单击“区域和语言选项”选项，弹出“区域和语言选项”对话框。在该对话框中，单击“高级”标签，将“非Unicode的程序的语言”选项改为“日语”，单击“应用”按钮，如图四：

图四

弹出的对话框单击“是”，重新启动计算机使设置生效。
运行Unicode.exe程序并单击“Button1”按钮，看，静态文本框出现了乱码。

第三步：
　　改为Unicode编码环境编译该工程，生成Unicode.exe。再次运行Unicode.exe程序并单击“Button1”按钮。看到Unicode编码的优势了吧。

就说这些吧，祝您好运。

ANSI/Unicode字符和字符串
TChar.h是String.h的修改，用于创建ANSI/Unicode通用字符串。

Unicode字符串的每个字符都是16位的。

Win9x只支持ANSI；Win2000/XP/2003支持ANSI/Unicode；WinCE只支持Unicode
       附：有部分Unicode函数也可以在Win9X中使用，但可能会出现意想不到错误。

wchar_t是Unicode字符的数据类型。

所有的Unicode函数均以wcs开头，ANSI函数均以str开头；ANSI C规定C运行期库支持ANSI和Unicode
                                 ANSI                                                                              Unicode
       char   *strcat(char   *,   const   char   *)                           wchar_t   *wcscat(wchar_t   *,   const   wchar_t   *)
       char   *strchr(const   char * , int)                                   wchar_t    *wcschr(const   wchar_t   * , int)
       int   strcmp(const   char   *,    const   char   *)                int    wcscmp(const   wchar_t   *, const   wchar_t *)
       char *strcpy(char   *,   const   char   *)                           wchar_t   *wcscpy(wchar_t    *,   const   wchar_t    *)
       size_t   strlen(const   char   *)                                        wchar_t    wcslen(const   wchar_t   *)

L" wash " : 用于将ANSI字符串转换为Unicode字符串；
        _TEXT(" wash ")根据是否定义Unicode或_Unicode进行转换。
       附：_Unicode用于C运行库；Unicode用于Windows头文件。

ANSI/Unicode通用数据类型
                        Both（ANSI/Unicode）                    ANSI                       Unicode
                               LPCTSTR                                 LPCSTR                   LPCWSTR
                               LPTSTR                                    LPSTR                      LPWSTR
                               PCTSTR                                   PCSTR                      PCWSTR
                               PTSTR                                      PSTR                         PWSTR
                               TBYTE(TCHAR)                      CHAR                         WCHAR

在设计dll时最好提供ANSI和Unicode函数，ANSI函数只用于分配内存，将字符转换为Unicode字符，然后调用Unicode函数。

最好使用操作系统函数，少使用或不实用C运行期函数
        eg：操作系统字符串函数（shlWApi.h）
                StrCat(), StrChr(), StrCmp(), StrCpy()等
                注意它们区分大小写，也区分ANSI和Unicode版本
        附：ANSI版函数在原函数后加大写字母A
                Unicode函数在原函数后加大写字母W

成为符合ANSI和Unicode的函数
        • 将文本串视为字符数组，而不是c h a r s数组或字节数组。
        • 将通用数据类型（如T C H A R和P T S T R）用于文本字符和字符串。
        • 将显式数据类型（如B Y T E和P B Y T E）用于字节、字节指针和数据缓存。
        • 将T E X T宏用于原义字符和字符串。
        • 修改字符串运算问题 。
          如：sizeof(szBuffer) -> sizeof(szBuffer) / sizeof(TCHAR)
                  malloc(charNum) -> malloc(charNum * sizeof(TCHAR))    

对Unicode字符操作的函数还有：（也有ANSI和Unicode版本）
       lstrcat() , lstrcmp() / lstrcmpi()[ 它们在内部调用CompareString() ], lstrcpy(), lstrlen()
       这些是作为宏实现的。

          C运行期函数                                       windows函数
                  tolower()                                  PTSTR   CharLower(PTSTR   pszString)
                  toupper()                                 PTSTR   CharUpper(PTSTR   pszString)
                  isalpha()                                  BOOL   IsCharAlpha(TCHAR   ch)
                                                                   BOOL   ISCharAlphaNumeric(TCHAR   ch)
                  islower()                                  BOOL   IsCharLower(TCHAR   ch)
                  isupper()                                 BOOL   IsCharUpper(TCHAR   ch)
                  print()                                       wsprintf()
       转换Buffer：DWORD   CharLowerBuffer(PTSTR   pszString , DWORD cchString)
                              DWORD CharUpperBuffer(PTSTR   pszString , DWORD   cchString)
       也可转换单个字符，如：TCHAR   cLowerCaseChar = CharLower((PTSTR)szString[0])

确定字符是ANSI或Unicode
        BOOL   IsTextUnicode(
                     const   VOID   * pBuffer,   //input   buffer   to be   examined
                     int   cb,                               //size of input   buffer
                     LPINT   lpi                         //options
        )
       附：此函数在Win9x系统中，没有实现代码，始终返回FALSE

Unicode与ANSI之间的转换
        char   szA[40];
        wchar   szW[40];
        // Normal   sprintf : all   string   are   ANSI
        sprintf( szA , " %s " , " ANSI   str ");
        // Convert   Unicode   string   to ANSI
        sprintf(   szA,   " %S " ,   L" Unicode   str ");
        // Normal   swprintf : all string are unicode
        swprinf( szW , "%s" , L" Unicode   str ");
        // Convert   ANSI   String to Unicode
        swprinf( szW, L"%S" , "ANSI str");

        int   MultiByteToWideChar(
              UINT   uCodePage,                   //code page,   0
              DWORD   dwFlags,                   //character-type   options,   0
              PCSTR   pMultiByte,                  //source   string   Addr
              int   cchMultiByte,                       //source   string   byte length
              PWSTR   pWideCharStr,          //Dest string   Addr
              int   cchWideChar                      //Dest   string char   Nums
         )
        u C o d e P a g e参数用于标识一个与多字节字符串相关的代码页号。d w F l a g s参数用于设定另一个控件，它可以用重音符号之类的区分标记来影响字符。这些标志通常并不使用，在d w F l a g s参数中传递0。p M u l t i B y t e S t r参数用于设定要转换的字符串， c c h M u l t i B y t e参数用于指明该字符串的长度（按字节计算）。如果为c c h M u l t i B y t e参数传递- 1，那么该函数用于确定源字符串的长度。转换后产生的U n i c o d e版本字符串将被写入内存中的缓存，其地址由p Wi d e C h a r S t r参数指定。必须在c c h Wi d e C h a r参数中设定该缓存的最大值（以字符为计量单位）。如果调用M u l t i B y t e To Wi d e C h a r，给c c h Wi d e C h a r参数传递0，那么该参数将不执行字符串的转换，而是返回为使转换取得成功所需要的缓存的值。

     可以通过下列步骤将多字节字符串转换成U n i c o d e等价字符串：
     1) 调用M u l t i B y t e To Wi d e C h a r函数，为p Wi d e C h a r S t r参数传递N U L L，为c c h Wi d e C h a r参数传递0。
     2) 分配足够的内存块，用于存放转换后的U n i c o d e字符串。该内存块的大小由前面对M u l t B y t e To Wi d e C h a r的调用返回。
     3) 再次调用M u l t i B y t e To Wi d e C h a r，这次将缓存的地址作为p Wi d e C h a r S t r参数来传递，并传递第一次调用M u l t i B y t e To Wi d e C h a r时返回的缓存大小，作为c c h Wi d e c h a r参数。
     4) 使用转换后的字符串。
     5) 释放U n i c o d e字符串占用的内存块。

    int WideCharToMultiByte(
          UINT CodePage,                        // code page
          DWORD dwFlags,                      // performance and mapping flags
          LPCWSTR lpWideCharStr,      // wide-character string
          int cchWideChar,                       // number of chars in string
          LPSTR lpMultiByteStr,               // buffer for new string
          int cbMultiByte,                           // size of buffer
          LPCSTR lpDefaultChar,            // default for unmappable chars
          LPBOOL lpUsedDefaultChar   // set when default char used
     )

我们决定写这篇比较文章是因为我们期望更多的人能正确地询问我们为何他们要用Ice代替CORBA。对这个问题，我们通常的回答是：为什么不先自己试试使用 Ice呢？我们敢肯定，一旦你使用了Ice有一段时间，你就永远不会再想用回CORBA。请相信我们，很容易会喜欢上Ice，因为它优雅、简单，它的结构一致性，而且最后一点：至少它没有大量的特性和工具。

对于没有时间去试验Ice来了解它的人，这里有一些原因让我们相信Ice优于CORBA：

1、Completeness(完备性)
当我们说到完备性时，我们的意思是实际产品的完备性，而不是从来未被实现的标准的完备性。我们相信Ice比市场上任何单个CORBA更完备。你可以自己做一个检查：市场上有哪个CORBA产品提供了跟Ice可比较的特性？

2、Performance(性能)
由于具有CORBA所没有的结构优点，Ice具有突出的性能。Ice高效的协议、请求批量化、高效的事件分发都意味着Ice比CORBA ORB运行得更快，同时消耗更少的线路带宽。

3、No "Design by Committee"(非“委员会设计”)
Ice由一群专业的资深专家所设计。Ice没有设计成适合所有人的“万金油”。而CORBA则充斥着被具有特权的制定者加进到标准里的众多不切实际的特性，却又没有真正考虑到这些特性是否会被真正地实现。

通常，为了就CORBA标准达成一致的唯一方法就是将之前大量实现的特性放在一起，生硬地塞进标准里。这导致了标准越来越大，也越来越复杂，超出了实际的需要。这也意味着平台更大更慢，也因为复杂的API导致了难以使用。Ice提供的API集小得多，也更高效，比CORBA的API易于学习使用，并且功能并不少。

4、Slice
Slice，Ice的规范定义语言，比CORBA IDL更小、更简洁、更强大。Slice具有更少的语言结构，但却更灵活。例如，一个内建的字典类型提供直接快速访问数据结构，异常的继承允许更清晰地影射到支持异常处理的语言。同时，Slice抛弃了CORBA IDL不需要的复杂性，例如属性，inout参数，上下文和传值对象(Objects-by-Value)的复杂性。

5、Language Mappings(语言影射)
Ice支持到C++、Java、Python、PHP、C#和Visual Basic的语言影射。我们知道任何一个CORBA实现提供商都没有提供那么多的语言影射选择。

实际上大多数的CORBA提供商只提供C++和Java的影射，如果你想使用其它语言影射，你就要切换到不同的提供商的产品或使用没有实验支持的CORBA实现。

6、Persistence(持久性)
Slice并不单单是一个接口定义语言。它也可以用来描述Ice对象进行持久的属性，使得很容易写出支持对象持久的服务器端程序。

7、Metadata(元数据)
Slice支持可扩展的元数据设施，它允许Slice为实现应用程序相关的某些目的而使用元数据的标记。例如元数据可以用于定制不同于标准Java影射方式的影射来满足某些特定程序的要求。

8、No any Type(没有any数据类型)
Ice 没有CORBA里Any类型的等价数据类型。这对于CORBA用户来说可能感到很惊讶，因为Any数据类型在CORBA标准里被广泛地使用。但是，Any 数据类型是多余的：程序语言象Java和C++并没有Any数据类型，而且Any数据类型对分布式系统来说也不是属于一个良好的设计。Any数据类型通常用在两种情况下：一种是需要在系统的中介部分对接收到的数据直接进行传递，而不用关心数据的真实类型，例如CORBA的Event服务，另一种是用来作为 union(联合结构体)的一个等价物。

Ice可以通过发送和接收"blobs"的请求来满足第一种情况，Slice的类继承可以满足第二种情况。任何一种情况，Ice的程序都更高效，更加具有类型安全，更加容易设计和实现，而不会遇到使用CORBA Any数据类型时所具有的复杂性。

9、Ice Core(Ice的核心)
虽着时间的演化，CORBA的核心变得异常的复杂。一个初级的例子要在POA(CORBA的对象适配器)里面正确使用都需要很专业的知识，即使你只想支持一小部分的技术特性。Ice的对象适配器，在另一方面来说，更加简单、直观、也跟POA一样的功能强大：定义良好的API使得比POA开发一个可扩展的程序项目需要更少的工作。

10、Ice Protocol(Ice协议)
IIOP是CORBA的弱点之一，具有太多的设计缺陷。例如，没有缺少请求的封装来防止消息的分发。低效的对齐规则导致了多余的数据拷贝。数据的编码规则复杂，却没有带来相应的性能的提高，对象引用的编码异常复杂，妨碍了有效的的编码和在内存共享的执行。代码集的协商是在标准下达成，会遭遇到很多冲突。所有这些复杂性意味着IIOP很难实现，带来了互操作性和性能上的问题。Ice的协议是简单并且更加有效，它提供了一些IIOP没有提供的特性，例如数据压缩和批请求批量化。

11、Security(安全性)
安全性是CORBA的最大的一个难题。OMG已经通过了多个标准，但很多都没有被广泛地实现，CORBA的客户依然没有一个可工作的安全的ORBs。当设计 Ice时，和CORBA相比，安全性被认为是基本的特性。这就是Ice提供一个真正能运作的SSL实现的安全的防火墙的原因。

12、C++ Mapping(C++映射)
用 C++来使用CORBA非常困难。即使你是很有经验的C++开发者。CORBA的C++映射在内存管理和异常安全方面有很多的陷阱和缺陷。相较之下，Ice的C++映射非常简单和直观。它不会有因为错误而导致内存的泄漏。要记住的映射规则的数目比CORBA的C++映射少得多，而且Ice的C++ 映射是基于工业标准的STL。

14、Scalability(可伸缩性)
当你是一个专家时，CORBA是一种可伸缩性很好的技术。但采用Ice，任何人都可以写出高可伸缩性的应用。例如，Ice实现了一个持久化的逐出器，你可以使用它来很容易地处理上百万的对象，你所做的仅仅是在 Slice的定义里指定对象的数据，剩下的工作Ice一手包办：Ice运行库使用高速的数据库来自动加载和保存对象。

15、Versioning(版本化)
CORBA没有任何机制来支持对象状态的版本化。Freeze是Ice的持久服务，它允许持久数据在Slice的定义中改变时，很容易地进行数据库的移植。

16、Software Updates(软件更新)
IcePatch是一个允许你更行客户端软件的工具。它使用压缩来提高数据的传输，并使用校验值来保证一致性。CORBA完全没有提供一个在分布式环境来进行软件更新的机制。

17、Typed Event Service(类型化的事件服务)
CORBA有一个标准来提供类型化的事件服务，但很少甚至没有被实现。类型化的事件服务也有很多已知的问题，事实上它在真正环境的部署是不可用的。Ice从一开始就提供了类型化事件的服务。IceStorm是一个高效、类型化事件服务的实现，它支持事件联盟。

18、Facets(多接口)
CORBA支持继承，DCOM支持聚合。在过去，有很多关于那一种是更好的方法的争论。Ice以接口继承加上以多接口形式的聚合来同时支持这两种方式。Facets允许你在运行的时候用动态的聚合来扩展类型来替代静态的继承。

19、Asynchronous Messages(异步消息)
CORBA 支持异步消息调用(AMI)，但很少CORBA产品实现了AMI。Ice一开始就以简单和有效的方式支持AMI。Ice也支持异步消息分发(AMD)，这是CORBA里完全没有的东西。AMD等价于客户端的AMI，不过AMD是用在服务器端的。使用AMI，你可以发送了一个请求，然后在以后的一个事件收到服务器的结果时调用一个回调函数来处理返回的结果。而使用AMD，你可以将分发线程归还给Ice，并在结果已经准备好发送到客户端时再次调用分发线程。 AMI和AMD都能被连接起来，这允许你只消耗很少的资源就能构建高效的路由程序。

AMI和AMD对客户端和服务器端来说都是透明的。也就是，一个服务器程序不知道一个请求是否通过AMI调用发出的还是同步地调用发出的，客户端程序也不知道一个操作的调用在服务器端是通过AMD分发处理的还是同步地处理的。当需要使用AMI和AMD时，不用修改Slice。

结束语：

我们希望上面的解释能另你激发你对Ice的兴趣。如果你有任何的问题或解释，我们会邀请你加入我们的邮件列表。我们的目标是不断地改进Ice，因此你的反馈对我们来说是很有价值的。

                                                                                    gigaboy翻译完成于2005/7/4 3:02