看到一篇文章，觉得比较有指导意义，译过来，希望给大家有些帮助，能力有限，有错误的地方还望大家指出来。共同学习，共同进步。

原文地址：
https://brewx.qualcomm.com/bws/content/gi/common/appseng/en/knowledgebase/docs/extensions.htm

1 简介：
扩展类可以扩充BREW的功能，通常来说，扩展类都是以动态的形式存在并且以OTA方式提供下载，然而在某些情况下，OEM制造商会在他们的设备中添加了一些静态的扩展类，例如：OEM制造商经常会给BREW标准接口类IAddrBook添加许多额外的功能，他们通常会创建自己的IAddrBook接口，并且把新增的额外功能提供给开发者。

2 静态 VS 动态
静态扩展类通常是被包含在OEM制造商的SW版本中，不由第三方开发者提供。从另外一个角度看来，动态扩展则是由OTA方式下载。移动应用和它所需要的扩展类是同时被下载到手机上的（除非手机上已经存在了所需的扩展类），通过MIF文件提供的依存列表信息把所需要的扩展类下载到手机当中。每一个动态扩展都会有一个相关联的引用计数，该引用计数负责监视手机上所有应用对于该扩展类的依赖关系，如果引用计数减少到0，则该扩展类将被从手机内存中移除。静态扩展则不是，它没有引用计数，也永远不会被从手机上删除。

3 特性
扩展类不包含权限设置，它的权限级别继承于父应用，例如：如果某应用使用了一个具有文件操作功能的扩展类，那么该应用就是扩展类的父应用，除非父应用的MIF文件中设置了允许文件操作的权限，否则该扩展类的所有文件操作都会失败，这一点对于扩展来开发人员来说十分重要。
与权限级别相似的是，扩展类中所有对于文件的操作都是通过父应用的上下文来执行的，如此来看，对于父应用不可见的文件，扩展类也是无法操作的。
扩展类即可以是保护类型也可以是未保护类型。对于保护类型来说，如果父应用的MIF文件中的依存关系列表中有显示罗列出该扩展类，那么父应用就可以创建并使用它，反之，则不行；对于非保护类型则可以被所有应用使用，不用考虑该应用是否明确声明了依存关系，这样的扩展类通常被加上一个MIME类型的标记，应用只需要通过外壳查找目标MIME类型的句柄，就可以使用它的功能了。

4 MIF文件
扩展类和应用一样需要MIF文件，然而，他们却在根本上有所不同。首先，一个扩展类的MIF文件不需要定义一个applet，只需要在MIF编辑器的"Externsions"标签栏中的"Exported Classes"中设置其class ID即可。保护类型的属性也在该标签栏中设置。
如果一个应用的运行以来与一个扩展类，那么在该应用的MIF文件中必须把扩展类的class ID设置为依赖，如果没有此类依赖关系，该扩展类将不会在下载应用的时候被一同下载，当该应用运行的时候就会失败。如果扩展类是可选的，就可以不用添加依存关系，然而应用必须能够处理扩展类不存在的情况。

5 声明扩展类的结构体
第一步，开发扩展类首先需要声明虚函数表。
typedef struct IDemoExtension IDemoExtension;
AEEINTERFACE(IDemoExtension)
{
        INHERIT_IQueryInterface(IDemoExtension);
        int (*DisplayTime)(IDemoExtension *po);
        int (*DisplayDate)(IDemoExtension *po);
};

第一行声明了一个IDemoExtension的结构体，该结构体是一个apple结构体，将会返回给正在初始化的应用，其中的宏AEEINTERFACE声明了一个扩展类的虚函数表，从上面的声明看出，虚函数表中有5个函数。BREW的每一个接口类都定义了一个类似于上面定义中的宏INHERIT_XXX，用它来把已继承的函数添加到已存在的函数表中，至少，BREW强烈推荐如上例所示，从IQueryInterface派生而来。宏INHERIT_IQueryInterface添加三个函数到函数表中：AddRef, Release, QueryInterface。我们的例子中添加了DisplayTime和DisplayData两个函数。
下一步我们定义宏来索引我们函数表中的函数
#define IDEMOEXTENSION_AddRef(p)
 AEEGETPVTBL((p),IExtensionCls)->AddRef((p))
#define IDEMOEXTENSION_Release(p)
    AEEGETPVTBL((p),IExtensionCls)->Release((p))
#define IDEMOEXTENSION_QueryInterface(p)
    AEEGETPVTBL((p),IExtensionCls)-> QueryInterface((p),(clsid),(pp))
#define IDEMOEXTENSION_DisplayTime(p)
 AEEGETPVTBL((p),IDemoExtension)->DisplayTime((p))
#define IDEMOEXTENSION_DisplayDate(p)
 AEEGETPVTBL((p),IDemoExtension)->DisplayDate((p))
上面的宏可以供父应用来调用扩展类的函数，宏AEEGETPVTBL能准确地指向函数表，并能方便的调用到函数表中的函数，需要注意的是AEEGETPVTBL是同AEEINTERFACE配合起来使用的，我们一旦声明好虚函数表，那么就应该定义扩展类结构体了。

以上代码的第一行把虚函数表插入了扩展类的结构体定义之中，虚函数表必须总是被定义成为结构体的第一个成员，m_nRefs变量也必须在结构体定义中声明，一个扩展类在应用中将会数次被引用，这个变量用来保存在应用中被引用的总次数，AddRef和Release函数是用来对该变量进行增减操作的，一旦m_nRefs变为0，该扩展类就会释放所有占用的资源。结构体中接下来的三个成员是扩展类的可选成员，可以在扩展类中添加任何所需要的成员变量。
6 定义函数
定义的第一个函数必须是AEEClsCreateInstance，REW总是调用该函数来创建该class的接口，下面的代码表明了普遍实现的方法。
int AEEClsCreateInstance(AEECLSID ClsId, IShell *pIShell,
       IModule *po, void **ppObj)
{
   *ppObj = NULL;
   if( ClsId == AEECLSID_MYEXTENSION) {
  return MyExtension_New(sizeof(IDemoExtension), pIShell, po,
           (IModule **)ppObj);
   }
   return EFAILED;
}
我们的函数首先会检查由BREW传入的参数class ID，如果检查通过了，函数就尝试创建和初始化需要的资源。

int MyExtension_New(int16 nSize, IShell *pIShell, IModule* pIModule,
                                                   IModule ** ppMod) {
   IDemoExtension*            pMe = NULL;
   VTBL(IDemoExtension) *     modFuncs;
   if( !ppMod || !pIShell || !pIModule )
      return EFAILED;
   *ppMod = NULL;
   // Allocate memory for the ExtensionCls object
   if( nSize < sizeof(IDemoExtension) )
      nSize += sizeof(IDemoExtension);
   // Allocate the module's struct and initialize it. Note that the
   // modules and apps must not have any static data.
   // Hence, we need to allocate the vtbl as well.
   if( (pMe = (IDemoExtension*)MALLOC(nSize +                                      
                              sizeof(VTBL(IDemoExtension)))) == NULL )
      return ENOMEMORY;
   modFuncs = (VTBL(IDemoExtension)*)((byte *)pMe + nSize);
   //Initialize individual entries in the VTBL
   modFuncs->AddRef              = MyExtension_AddRef;
   modFuncs->Release             = MyExtension_Release;
   modFuncs->QueryInterface      = MyExtension_QueryInterace;
   modFuncs->DisplayTime         = MyExtension_DisplayTime;
   modFuncs->DisplayDate         = MyExtension_DisplayDate;
   // initialize the vtable
   INIT_VTBL(pMe, IModule, *modFuncs);
   // initialize the data members
   pMe->m_nRefs      = 1;
   pMe->m_pIShell    = pIShell;
   pMe->m_pIModule   = pIModule;
   // Add References and get IDisplay
   ISHELL_AddRef(pIShell);
   IMODULE_AddRef(pIModule);
   // Create an instance of the IDisplay
   if( ISHELL_CreateInstance(pIShell, AEECLSID_DISPLAY,
                         (void **)&pMe->m_pIDisplay) != SUCCESS )
      return EFAILED;
   // Set the pointer in the parameter
   *ppMod = (IModule*)pMe;
   return AEE_SUCCESS;
}

AddRef, Release和QueryInterface是从IQI接口继承过来的，AddRef负责增加引用计数的数值。

static uint32 MyExtension_AddRef(IDemoExtension* pMe) {
   // Increment reference count
   return ++(pMe->m_nRefs);
}

Release函数负责减少引用计数的数值，当引用计数的值变为0的时候，该实例就会从内存中被释放掉。

static uint32 MyExtension_Release(IDemoExtension* pMe) {
   // Decrement reference count
   if( --pMe->m_nRefs != 0 )
      return pMe->m_nRefs;

   // Ref count is zero.  Release memory associated with this object.
   if( pMe->m_pIDisplay )
      IDISPLAY_Release(pMe->m_pIDisplay);

   // Release interfaces
   ISHELL_Release(pMe->m_pIShell);
   IMODULE_Release(pMe->m_pIModule);
   //Free the object itself
   FREE_VTBL(pMe, IModule);
   FREE( pMe );
   return 0;
}

我们最后一个需要定义的函数就是QueryInterface，这个函数返回一个与扩展类相关联的接口，IWeb接口就是一个例子，当一个应用使用该接口完成一个网页请求的时候，底层的一个TCP套接字被创建，为了能够直接控制这个套接字，应用可以通过调用IWeb_QueryInterface函数，传递参数AEECLSID_SOCKET(AEECLSID_SOCKPORT在BREW3.x中)，来获得这个接口，该函数将返回一个指针，下面是QueryInterface的一个具体实现。

static int MyExtension_QueryInterface(IDemoExtension* me,
                               AEECLSID class, void** ppo) {
   switch (class) {
      case AEECLSID_QUERYINTERFACE:
      case AEECLSID_MYEXTENSION:
      case AEECLSID_BASE:
         *ppo = me;
         MyExtension_AddRef(me);
         return SUCCESS;
      case AEECLSID_DISPLAY:
         *ppo = me->m_pIDisplay;
          return SUCCESS;
      default:
         *ppo = NULL;
         return ECLASSNOTSUPPORT;
   }
}

7 静态扩展类

上面介绍的这个例子也可以用来创建静态扩展类，然而静态扩展类可以作为全局变量，有了这个特性，下面的代码可以为静态扩展类构造虚函数表。

static const AEEVTBL(IDemoExtension) gvtIDemoExtension = {
   MyExtension_AddRef,
   MyExtension_Release,
   MyExtension_QueryInterface,
   MyExtension_DisplayTime,
   MyExtension_DisplayDate,
};

以上的代码被放置在函数之外，通常是在一个头文件中，初始化扩展类可以简单的用一行代码搞定。

pMe->pvt = &gvtIDemoExtension;

上面的代码初始化了整个虚函数表，不必对于虚函数表中每个函数都初始化一次，然而上面的代码仅对静态扩展类是有效的，一个动态扩展类的地址是在运行时确定的（于之不同的是，静态扩展类的地址是在编译时确定的），因此，虚函数表必须在运行时声明。

8 关于宏
强烈推荐在以上例子中所使用到的宏，然而在BREW中还有许多其他的可以用来创建扩展类的宏。其中很多宏被包含近来是为了向后的兼容性，一些宏例如：QINTERFACE, GET_PVTBL和DECLARE_IBASE都是十分令人气馁的，他们应该分别被AEEINTERFACE, AEEGETPVTBL和INHERIT_IQueryInterface替代。

9 使用扩展类
扩展类可以像标准的BREW APIs一样被创建和释放，每个函数都可以通过头文件的宏定义来调用，同BREW APIs一样，在编译调用扩展类函数的应用的时候需要包含其头文件，下面的例子叙述了如何在应用中调用扩展类的函数。

if(ISHELL_CreateInstance(pMe->a.m_pIShell, AEECLSID_MYEXTENSION,
              (void **) (&(pMe->pIDemoExtension))) != SUCCESS ) {  
   return FALSE;
}

IDEMOEXTENSION_DisplayTime(pMe->pIDemoExtension);
if(pMe->pIDemoExtension) {
   IDEMOEXTENSION_Release(pMe->pIDemoExtension);
   pMe->pIDemoExtension = NULL;
}

10 通过MIME类型使用扩展类
扩展类可以把其自身注册为一个MIME类型的句柄，它的注册最好通过MIF编辑器来完成。

上面提及的例子展示了一个扩展类注册为MYTIME句柄，MIME类型的注册允许在运行时解决class ID的问题，应用可以通过ISHELL_GetHandler函数找到一个MIME类型的class ID，整个函数会遍历所有的MIF文件，寻找以MIME类型方式注册的class ID。
下面这个例子阐述了一段能创建和显示多种不同格式文件的代码，在此例中，有一个抽象类IReader，一个扩展类可以扩充它的接口来显示多种格式的文件。

// An Application will call this function when it intends to
// open a file
void DisplayFile(MyApp* pMe, char* mime, char* file) {
   AEECLSID myClass;
   // This call will create a handler for MYPDF, MYDOC, or
   // MYXML depending on mime
   myClass = ISHELL_GetHandler(pMe->pIShell, AEECLSID_APP, mime);
   // Create necessary Interface
   ISHELL_CreateInstance(pMe->pIShell, myClass, &pMe->pIReader);

   // Ishell Createinstance
   // Each extension implements DisplayFile, The virtual
   // table will point to the correct corresponding function
   // call.  We are ignoring error checking
   IREADER_DisplayFile(pMe->pIReader, file);
}

DisplayFile是一个被所有扩展类实现的扩充IReader的接口，虚函数表在创建扩展类的时候被初始化，这样就使IREADER_DisplayFile可以索引正确的函数来显示文件。

11 更多信息
BREW 2.x 察看AEE.h
BREW 3.x 察看AEEInterface.h

--2006.1.11

1、关于AEEINTERFACE。

typedef struct _ISample ISample;

AEEINTERFACE(ISample)
{
    INHERIT_IQueryInterface(ISample);

    // add your fun...
    void (* Fun)(ISample* po);
};

struct ISample
{
    const AEEVTBL(ISample)       *pvt;

    // add your var...
    uint32                      m_uRef;
};

宏INHERIT_IQueryInterface的含义是：从基接口IBase继承它的几个关键函数指针AddRef, Rlease, QueryInterface
这样，就很简单的构造出了一个基于AEEINTERFACE的ISample接口，你可以在Fun函数指针后面添加你所需要的函数指针，在m_uRef后面添加你所需要的成员变量，然后用面向对象的眼睛去观察它，那么他就是个类了，虽然他之前放的是个struct。
还有，如果你比较勤快，或者你想模仿一下BREW平台的那些库函数，又或者你不想让别人知道你到底用了哪些成员，你就可以用宏来定义你的那些成员函数，就像BREW平台那样：
#define  ISAMPLE_Fun(p)  AEEGETPVTBL(p, ISample)->Fun((p))
这样，是不是比较cool，不过也有画蛇添足的功能。

2、关于QINTERFACE
example中mediaplayer的源代码实在是比较经典，所以就拿里头的IWindow作为例子吧

typedef struct _IWindow  IWindow;

QINTERFACE(IWindow)
{
   void     (*Enable)(IWindow * po, boolean bEnable);
   void     (*Redraw)(IWindow * po);
   boolean  (*HandleEvent)(IWindow * po, AEEEvent eCode, uint16 wParam, uint32 dwParam);
   void     (*Delete)(IWindow * po);

   // add your fun in base struct
};

#define INHERIT_CWindow(iname) \
   DECLARE_VTBL(iname) \
   CMediaPlayer * m_pOwner; \
   IShell *       m_pIShell; \
   IDisplay *     m_pIDisplay; \
   flg            m_bActive:1
   // add your var in base struct

struct CWindow
{
   INHERIT_CWindow(IWindow);
};

struct CMainWin
{
   INHERIT_CWindow(IWindow);

   IImage *       m_pLogo;
   AEERect        m_rectLogo;
   IMenuCtl *     m_pMainMenu;
   flg            m_bAbout:1;
   // add your var in sub struct
};

IWindow就是一个结构体，所有成员都是函数指针，因此也可以称它为接口。INHERIT_CWindow这个宏很重要，继承都靠它了。你可以在上面标注的地方，给基类添加你的数据成员和成员函数。那么当数据成员和成员函数合并，就构成为了CWindow基类。很明显CMainWin是从CWindow派生出来的，如果最好只添加数据成员，如果添加成员函数，就会暴露和成员函数同级的数据成员，那么封装性就会降低了。

如果你还是想模仿BREW平台，那么可以这么写：
#define IWINDOW_HandleEvent(p, e, w, dw)  GET_PVTBL(p, IWindow)->HandleEvent(p, e, w, dw)

在这个应用里头，注意两个宏：DECLARE_VTBL和GET_PVTBL。
还可以注意一下IWINDOW_HandleEvent这个函数，对于不同的CWindow，就对应不同的XXX_HandleEvent，那么不同的窗体就会体现不同的行为。

大概也就这么多，不过到底是C语言的模拟，很难达到C++面向对象那么完善，不过对于简单的手机应用开发，已经能够胜任了，如果还想研究更加深入的东西，可以读一读高通平台的内部代码。

      看《COM技术内幕》，看到一个关于提到objbase.h的文件，于是上里头找找看，有没有些有价值的东西，可是一看发现，写了几个月的c了，还有关键字不认识的，它就是#pragma，上网找了篇资料，贴出来，以后查也方便。

      在所有的预处理指令中，#Pragma 指令可能是最复杂的了，它的作用是设定编译器的状态或者是指示编译器完成一些特定的动作。#pragma指令对每个编译器给出了一个方法,在保持与C和C++语言完全兼容的情况下,给出主机或操作系统专有的特征。依据定义,编译指示是机器或操作系统专有的,且对于每个编译器都是不同的。 
其格式一般为:    #Pragma Para 
    其中Para 为参数，下面来看一些常用的参数。 

    (1)message 参数。 Message 参数是我最喜欢的一个参数，它能够在编译信息输出窗 
口中输出相应的信息，这对于源代码信息的控制是非常重要的。其使用方法为： 
       #Pragma message(“消息文本”) 
       当编译器遇到这条指令时就在编译输出窗口中将消息文本打印出来。 
    当我们在程序中定义了许多宏来控制源代码版本的时候，我们自己有可能都会忘记有没有正确的设置这些宏，此时我们可以用这条指令在编译的时候就进行检查。假设我们希望判断自己有没有在源代码的什么地方定义了_X86这个宏可以用下面的方法 
       #ifdef _X86 
       #Pragma message(“_X86 macro activated!”) 
       #endif 
       当我们定义了_X86这个宏以后，应用程序在编译时就会在编译输出窗口里显示“_ 
X86 macro activated!”。我们就不会因为不记得自己定义的一些特定的宏而抓耳挠腮了 
。 
   
   (2)另一个使用得比较多的pragma参数是code_seg。格式如： 
      #pragma code_seg( ["section-name"[,"section-class"] ] ) 
      它能够设置程序中函数代码存放的代码段，当我们开发驱动程序的时候就会使用到它。 

   (3) #pragma once (比较常用） 
      只要在头文件的最开始加入这条指令就能够保证头文件被编译一次，这条指令实际上在VC6中就已经有了，但是考虑到兼容性并没有太多的使用它。 
   
   (4) #pragma hdrstop表示预编译头文件到此为止，后面的头文件不进行预编译。BCB可以预编译头文件以加快链接的速度，但如果所有头文件都进行预编译又可能占太多磁盘空间，所以使用这个选项排除一些头文件。  
     有时单元之间有依赖关系，比如单元A依赖单元B，所以单元B要先于单元A编译。你可以用#pragma startup指定编译优先级，如果使用了#pragma package(smart_init) ，BCB就会根据优先级的大小先后编译。  
   
   (5) #pragma resource "*.dfm"表示把*.dfm文件中的资源加入工程。 *.dfm中包括窗体 
外观的定义。  
    
   (6) #pragma warning( disable : 4507 34; once : 4385; error : 164 ) 
      等价于： 
      #pragma warning(disable:4507 34)  // 不显示4507和34号警告信息 
      #pragma warning(once:4385)        // 4385号警告信息仅报告一次 
      #pragma warning(error:164)        // 把164号警告信息作为一个错误。 
      同时这个pragma warning 也支持如下格式： 
      #pragma warning( push [ ,n ] ) 
      #pragma warning( pop ) 
      这里n代表一个警告等级(1---4)。 
      #pragma warning( push )保存所有警告信息的现有的警告状态。 
      #pragma warning( push, n)保存所有警告信息的现有的警告状态，并且把全局警告 
等级设定为n。  
      #pragma warning( pop )向栈中弹出最后一个警告信息，在入栈和出栈之间所作的 
一切改动取消。例如： 
      #pragma warning( push ) 
      #pragma warning( disable : 4705 ) 
      #pragma warning( disable : 4706 ) 
      #pragma warning( disable : 4707 ) 
      //....... 
      #pragma warning( pop )  
      在这段代码的最后，重新保存所有的警告信息(包括4705，4706和4707)。 
    （7）pragma comment(...)   //objbase.h里头用的最多的就是这个用来导入COM的一些基础库
       该指令将一个注释记录放入一个对象文件或可执行文件中。 
      常用的lib关键字，可以帮我们连入一个库文件。 
 
 
每个编译程序可以用#pragma指令激活或终止该编译程序支持的一些编译功能。例如，对循环优化功能： 
#pragma loop_opt(on)      // 激活 
#pragma loop_opt(off)  // 终止 
有时，程序中会有些函数会使编译器发出你熟知而想忽略的警告，如“Parameter xxx is never used in function xxx”，可以这样： 
#pragma warn —100      // Turn off the warning message for warning #100 
int insert_record(REC *r) 
{ /* function body */ } 
#pragma warn +100            // Turn the warning message for warning #100 back on 
函数会产生一条有唯一特征码100的警告信息，如此可暂时终止该警告。 
每个编译器对#pragma的实现不同，在一个编译器中有效在别的编译器中几乎无效。可从编译器的文档中查看。 

(备注：此文提到的AEEINTERFACE是跟BREW平台相关的)

仔细阅读了Qinix的《基于COM思想实现AEEINTERFACE》，彻底被作者折服，作者用极其简单的方法给大家阐述了AEEINTERFACE的实现方式。
不过由于作者在文中，及其文后附带的代码中，对于BREW平台所自带的宏，没有展开，给阅读代码带来了一定困难，于是我把它们展开，在这个过程中，又遇到了一些问题，经过仔细思考，得到一些不成熟的答案，拿出来跟大家分享、讨论一下。

BREW平台里头有一些比较复杂的宏，关于文中所遇到的宏，列表如下：

#define AEEINTERFACE(iname) \
           typedef struct AEEVTBL(iname) AEEVTBL(iname); \
           struct AEEVTBL(iname)

#define AEEVTBL(iname) iname##Vtbl

#define INHERIT_IQueryInterface(iname) \
   INHERIT_IBase(iname); \
   int (*QueryInterface)(iname *, AEECLSID, void **)

#define INHERIT_IBase(iname) \
  uint32  (*AddRef)         (iname*);\
  uint32  (*Release)        (iname*)

因此，关于IICAT的定义，可以分解为：
AEEINTERFACE(IICat)
{
    INHERIT_IQueryInterface(IICat);
    void (*IgnoreMaster)(IICat* po);
};

-->>

typedef struct IICatVtbl IICatVtbl;
struct IICatVtbl
{
 /** INHERIT_IQueryInterface **/

 /** INHERIT_IBase **/
 uint32  (*AddRef) (IICat*);
 uint32  (*Release) (IICat*);
 /** end-INHERIT_IBase **/

 int (*QueryInterface)(IICat *, AEECLSID, void **)
 /** end-INHERIT_IQueryInterface **/

    void (*IgnoreMaster)(IICat* po);
};

关于CICat的定义，可以分解为：
struct CICat
{
    const AEEVTBL(IICat)       *pvt;
    uint32                      m_uRef;
    IShell                     *m_pIShell;  
    ICat*                       m_pCat;             
};

-->>

struct CICat
{
    const IICatVtbl  *pvt;
    uint32                      m_uRef;
    IShell                      *m_pIShell;  
    ICat*                       m_pCat;             
};

关于接口函数：
#define AEEGETPVTBL(p,iname)  (*((AEEVTBL(iname) **)((void *)p)))

#define IICAT_AddRef(p)                                   AEEGETPVTBL(p,IICat)->AddRef((p))
#define IICAT_Release(p)                                  AEEGETPVTBL(p,IICat)->Release((p))
#define IICAT_QueryInterface(p,i,o)                       AEEGETPVTBL(p,IICat)->QueryInterface((p),(i),(o))
#define IICAT_IgnoreMaster(p)                             AEEGETPVTBL(p,IICat)->IgnoreMaster((p)) 

例如：IICAT_AddRef(IICAT)
就是 (*((IICATVtbl **)((void *)IICAT)))->AddRef((IICAT))

关键的几个结构体：CCAT, CICat

当程序运行的时候，ISHELL_CreateInstance会根据CLSID调用IICat_New函数，该函数创建CICat结构体对象，在创建的过程中，首先创建类CCAT的实例，指针赋值给m_pCat，然后会给pvt指针赋值（也就是那个static const gvtIICat），最后分别给m_uRef和m_pIShell赋值。

通过以上的步骤，你分别拥有了CCAT和CICat的实例，那么你就可以通过调用那些以IICAT_开头的函数来完成你需要的功能了，不过接口函数中肯定都回有CICat的实例作为参数，因为你实际调用就是CICat结构体中的函数。

比如说你调用IICAT_IgnoreMaster(p)函数，它实际上是调用的CICat->IgnoreMaster(p)，它又实际上是调用的CCAT->IgnoreMaster(p)。

在阅读的时候遇到过两个疑问，现在得到一些不成熟的解释：

1、文中对类、结构体都进行了精巧的设计，那么可以说，这是C和C++混合在一起的，开始一直不明白，这样的代码，如何在纯C的环境下编译通过，因为C是不支持C++的么，后来想通了，正是由于BREW平台是基于COM机制的封装，对于最终客户来说，他所能接触到的就是以下这些函数：IICAT_AddRef、IICAT_Release、IICAT_QueryInterface、IICAT_IgnoreMaster、IICat_New。他们只需要调用这些函数，来完成自己的功能，而无须理解其中的实现，无须控制其中的成员变量，而这样些实现，都是编译成二进制代码（比如dll文件），不需要开发人员再次编译。这样就充分体现了COM机制的优越性。

2、在研读的过程中，发现了一个这样的语句
typedef struct _IICat IICat;

觉得很奇怪，作者并没有给出IICat的具体实现，但是IICat却实实在在的存在于代码中间。经过仔细察看，发现原来那些函数把IICat作为传入参数，可是在函数中，对于这个参数的处理，使强制转换为CICat类型，这样，才能去访问CICat中IICatVtbl的那些函数指针。
这么看来，其实IICat是个假的，什么都不是的结构体，他只是CICat的代言人而已，真正干活的是CICat。（感觉有点《鼠胆龙威》里头的张学友和李连杰，呵呵）。

开始一直不明白，大家都提到对于IICatVtbl在结构体中定义的位置，必须放在所有结构体成员的第一位，不然，就无法定位到IICatVtbl中的函数指针。现在，我猜是，由于从IICat转换到CICat，经过了类型转换，其实两者并不是一个类型，但是由于IICatVtbl位于结构体定义的第一位，那么IICat指针所指向的位置也就是IICatVtbl中指针所指向的位置，这样就能保证顺利的访问IICatVtbl中的函数指针。

非常感谢Qinix 斑竹写出了这么好的文章，让大家能从中学习到不少知识，对于文章的理解，还是不够透彻，如果有说得不对的地方，希望大家指正。

我们如果正常定一个函数

void fun(void)
{
 int tmp;

 // same operation
 // ...
}

如果我们调用fun函数，那么程序会在动态数据区的栈里头为局部变量申请空间，然后执行相关的代码，进行操作。
当fun函数执行完毕，tmp变量就会出栈，不复存在。

但是如果我们进行如下的操作：

int* global_tmp = NULL;

void fun()
{
 int tmp;

 tmp = 1;
 printf("tmp addr is : 0x%08x\n", &tmp);

 if (NULL == global_tmp) 
 {
  global_tmp = &tmp;
 } else
 {
  (*global_tmp)++;
 }

 printf("global_tmp addr is : 0x%08x\n", global_tmp);
 printf("global_tmp addr'addr is : 0x%08x\n", &global_tmp);
}

多次调用fun函数，

我发现，存放global_tmp指针的地址，是在编译的时候就确定的，在静态/全局数据区，如果你在fun函数中，给global_tmp赋值，那么global_tmp会指向堆中的一个地址，那么他会一直保存这个地址，直至程序结束退出。但是实际对于fun函数，每次调用，里头的变量都回在栈中分配空间，而随着fun函数的退出，这些空间也会被释放，那么实际上global_tmp就指向了一个未知的值。

所以，对于global_tmp这样的全局指针，所以指向的地址，应该是在堆空间中。

      简单的说，BREW就是一个应用运行环境，安装和支持BREW的手机，用户可以实现下载游戏、应用软件、GPS定位、无线购物等几十种数据服务。

      早就在网上听闻BREW的恶名，今日尝试，果然名不虚传。

      回调机制。简直无法忍受BREW的回调机制，每次跟踪程序，总是会跳到莫名其妙的地方，自己写的还算好，起码能找到，如果是改别人的程序，简直是不可能的，说不定哪个地方就跳到一个神奇的、你想都想不到的地方去了。每次面对VC蹦出来的弹出框，我都想把电脑砸了。

      有了回调机制，于是函数指针开始满天飞。注册一个回调函数，说不定就蹦到哪个文件，哪个旮旯地方，一副超级不友好的界面。

      承认，是我C基础不好，还是特怀念过去J2ME的时代。确实，J2ME慢，不过现在手机上的破CPU上，也不用指望其他程序能跑多快，而且，快慢也不关我的事，让用户去忍受去吧。

（8）  制作完RAID磁盘分区后，由于做成一个RAID分区的两个物理磁盘分区大小不可能完全一样，一般都会偏小，因此要重新调整文件系统的大小。以/dev/md0为例，需要执行以下命令：

(rescue)#  e2fsck  -f  /dev/md0

(rescue)#  resize2fs  /dev/md0

对其他的RAID磁盘分区也执行同样的命令，然后你就可以重新启动机器了，如果顺利的话，机器就运行在RAID1状态下了。

（9）  收尾工作，你可能希望机器可以从任何一快硬盘启动，因为如果主硬盘出故障，只需要重新启动，就可以继续提供服务，因此，你必须在辅硬盘上把启动程序grub重新安装一遍。

在使用了RAID磁盘分区后，只要是对该类分区进行的数据写操作，数据会被写到两块硬盘的对应分区上，两块硬盘保持同步更新。这样就保证了数据的安全性，也无需经常备份数据了。制作过程中使用的是一块空余硬盘，RAID1的实现是系统提供的软件方式，节省了RAID卡的开销，以最小的成本实现了我们的目标。

在选择RAID1方式的时候，一直担心它的效率问题，RAID1只提供数据冗余备份，RAID0能提供较高的数据访问速度，如果选择实现RAID0+1的话，至少需要4块硬盘。成本将大大提高。在制作完RAID1后，马上进行了磁盘读些测验，分析性能。

进行磁盘性能测验是使用Linux自带的工具hdparm。该命令的测试原理是往磁盘分区上反复读写大量数据，并计算时间，以此来测试磁盘性能。在系统下执行该命令，则可以得到硬盘数据读写的测验结果。实验数据见表5：

[root@panda ~]# hdparm -Tt /dev/sda1

/dev/sda1:

 Timing cached reads:   696 MB in  2.01 seconds = 346.67 MB/sec

 Timing buffered disk reads:  154 MB in  3.01 seconds =  51.10 MB/sec

[root@panda ~]# hdparm -Tt /dev/sdb1

/dev/sdb1:

 Timing cached reads:   796 MB in  2.01 seconds = 396.28 MB/sec

 Timing buffered disk reads:  146 MB in  3.03 seconds =  48.21 MB/sec

[root@panda ~]# hdparm -Tt /dev/md0

/dev/md0:

 Timing cached reads:   824 MB in  2.01 seconds = 410.22 MB/sec

 Timing buffered disk reads:  130 MB in  3.00 seconds =  43.31 MB/sec

表5 硬盘性能测验数据

从上表的实验数据看出，第一行数据是对主硬盘性能测验的数据，从硬盘cache读写数据的速度是346.67 MB/sec，从硬盘盘面上读写数据的速度是51.10 MB/sec；第二行是对辅硬盘性能测验的数据，从硬盘cache读写数据的速度是396.28 MB/sec，从硬盘盘面上读写数据的速度是48.21 MB/sec；第三行是对RAID磁盘分区性能测验的数据，从cache读写数据的速度是410.22 MB/sec，从盘面读写数据的速度是43.31 MB/sec。可以看出从cache读写数据的速度有所提高，从盘面读写数据的速度有所下降。总的来说，差距不是太大，在可以接受的范围内。