我要在UNIX下实现COM组件的运行环境！！！

[xiaobinliu]

不好意思，不用这样题目，您大概不会来，既然来了，您大概不会生气吧？

本帖子主题：
如何在UNIX下实现COM组件的运行环境的小“讨论”

----欢迎C++,COM,UNIX高手----

至于如何用代码实现，那是非常复杂的工程，我们不谈
至于是否有现存的这样的项目进行，我们可以参考他们的做法，但是不做仔细转研
这个讨论侧重从头开始建立这样一个COM运行环境，在UNIX上面我们需要做些什么。

为了好说，好记，把这个讨论的主题起个名字:COMX

起头：
COMX的功能：
1 不需要考虑兼容Windows下面的既有dll
2 不需要兼容COM组件规范
3 自己实现一个组件二进制借口规范
4 在UNIX上面写其他C++程序，
1 可以初始化COM环境调用他人编写的COMX组件
2 可以把自己的代码实现成COMX组件

望集思广益

[xiaobinliu]

在一个动态库中封装一个，或者若干个类是很容易做到的

在COMX run time中 动态的根据 类ID调用 动态库中的函数也是可以做到的，那么继续考虑

comx run time 到底做什么？
1 维护COMX内存中的二进制代码
2 简化客户程序的编写，一些访问comx组件的共用代码在这里实现
3 根据客户传入的COMX组件ID寻找到实际的COMX组件文件

comx run time不做什么？
1 必须有comx组件完成的功能
2 客户程序完成的功能

comx架构中包含的主题？就是：
1 comx 服务器实现一些普通的动态库不实现的函数，把自己主动地告诉世界
2 一个comx run time 可以访问到的数据库，保存comx服务器的所以信息
3 一个comx服务器注册程序，根据comx服务器中实现的一些函数把comx服务器告诉世界
的一些信息写入到comx run time数据库中，供查阅。
4 comx run time

有了这些就够了
1 所有可爱的程序员按照comx规范实现自己的comx服务器，
2 然后通过注册程序告诉世界，让别人可以知道他的comx服务器，
3 然后一个想使用comx服务器的lazy程序员通过一个到处可以下载到的comx run time
并且安装在系统上，通过comx run time迅速的使用comx服务器，如果他不lazy，可以
自己来写代码直接根据comx服务器提供出来的细节访问comx服务器。


comx组件除了实现客户想要的，还需要向comx run time提供什么？
1 客户不关心的，但是必须实现的
2 自己包含的类的信息
3 注册程序调用的函数
4 comx run time调用的函数
5 返回自己所包含的所有接口的指针

[xiaobinliu]

一个comx服务器就象这样
DllMain();初始化，从内存中移除等功能
DllRegister();
DllUnregister();
DllGetClassObject(char * ClsID);根据ClsID通过(IUnkown *)p->Queryinterface(ClsID)得到其内包含的对象指针

class IUnknown{
private:
int refcount;
public:
virtual AddRefcount();
virtual Release();
virtual QueryInterface(char * ClsID);
}

class ComXObject:IUnknown{
public:
void * Shout();
}

这里使用C++的对象模型，我们应该实现comx可以理解的comx自己的对象模型。

[myasuka1978]

UP

[xiaobinliu]

当使用上面的架构的时候，comx组件内部实现的任何一个类,都需要自己实现自己的
AddRefcount();
Release();
QueryInterface();

然后要在DllGetClassObject()；中加入相应的入口，DllGetClassObject函数的实现就象
这样：
DllGetClassObject(const CLSID& clsid)
{
switch (clsid) {
case "FirstComxObject" :
FirstComxObject *p = new FirstComxObject;
p->QueryInterface(iid);
return(p);
case "":
/*
其它类
*/
}
}

[xiaobinliu]

重新定义COMX的功能：
1 提高二进制代码的被重用能力
2 二进制代码可以自己暴露自己的内部消息，
包括：版本，组件名字，组件ID，内含类，每一个类的接口信息（接口名，接口ID，
接口方法，接口属性）
3 相关的功能尽可能兼容COM规范，以便将来有可能的扩充以全部做到和COM规范的兼容，
兼容是指：可以通过不同平台上面API的模拟层运行代码
4 COMX客户可以按照COMX提供的相应规范实现自己的COMX组件
5 COMX客户可以不必需要组件的头文件（详细的机器可以识别定义），
而只需要或者甚至不需要组件的说明书使用COMX组件
6 COMX客户在只知道组件名字的情况下就可以使用在本机的COMX组件
7 (保留扩充功能)COMX客户可以根据组件名字和组件所在服务器计算机的IP地址访问远程
COMX组件

[hongbo_liu]

gz

[xiaobinliu]

我发现需要从三个方面来考虑COMX规范的实现
1 COMX运行环境的规格和实现
运行环境被COMX客户程序编译动态的或者静态的连接到自己，就是说客户程序可以使用非
COMX组件的使用方法使用COMX运行环境

2 COMX服务器的规格和实现

3 COMX客户程序如何发现和使用COMX服务器相关信息的规格


对 （3 如何实现COM接口？）的重新思考
原来思考：
要实现COM接口，就是说在2的注释中使用comobject这个指针访问组件的方法，而且comx运行环境能够根据一个ProgID找到COMX组件的物理位置（继续思考3：根据ProgID找到.SO的位置，然后动态载入内存）,动态的加载了某一个so文件以后，根据CLASSID找到相关类的(问题求解1：是否有这样机制支持)二进制代码入口点，boot，然后调入内存，返回COMX对象的指针，如果能够顺利地实现这样的问题，那么就可以顺利的实现COMX接口。余下的问题就是使用
这个指针了。

重新补充思考：
一个COMX组件应该能够被：
1 COMX运行环境能够根据一个组件标识符找到COMX组件的物理位置
2 能够根据类标识符找到二进制代码的地址，然后调入内存，返回COMX对象的指针
3 COMX运行环境应该能够根据内存中的COMX对象状态决定COMX对象的销毁和管理
4 COMX组件所使用的数据类型应该和客户所使用的数据类型能够匹配
5 确定COMX客户访问COMX服务器的方法
void * comobject=comruntime.newComObject("LIB.CLASSNAME");
//开始使用COMX组件对象
comobject->Shout();
comobject->Destroy(); //确定不再需要这个指针，

[pacman2000]

redhat里面有一个叫ibcs(intel binary compatible standard)的包，不知道会不会对你有所帮助。

[xiaobinliu]

我发现我的能力还是有限，难道com就是把DLL中的export函数加上一层包装？
dll是这样：
export int hello();
export int shout();

变换成COM是这样：
export queryinterface();{hello(); shout();}

如果是这样，实现COMX意义何在

[xiaobinliu]

pacman2000(pacman)：

intel binary compatible standard 完成什么功能？

[MackedNice]

我不知道COM的实现机制。。。
我帮你UP。。。。
UP。。。。。。。。。

[Wolf0403]

Microsoft 很“恰好”地让 VC 产生的对象内存分布和 COM 要求的一样。。。这保证了 COM 在 VC 编译器中的二进制兼容。
Unix 下编译器种类繁多，是不是都可以这样做还是个问题。 COM 的本质是二进制兼容，而 C++ 标准不保证二进制兼容。也许用 C 自己实现会更方便一点？

[xiaobinliu]

谈到这里，如果希望实现一个UNIX下面的各种语言都兼容的二进制COMX组件对象模型，有必要
在COMX运行环境中下功夫。

[tlping]

关注：）

[icenl]

up

[MarkDong]

我觉得现在讨论关注点集中在ProgID怎么映射到一个.so，但是其实这个并不是关键的。我觉得关键是怎么支持RPC机制，不仅是本地的RPC，还包括远程的RPC。这就要考虑调用的参数以及调用的结果如何打包、解包及传送的问题，我觉得才是更关键的问题。

对于这个问题，可以参考ACE中的那个CORBA环境

[xiaobinliu]

现在讨论的东西还是最底层的东西，这个架构建好以后，再开始考虑远程的问题，逐步把架构分析明了

[xiaobinliu]

我觉得逐步深入的路径是

1 本地C++能访问的COMX （c++对象模型的COMX）
2 本地其他编译语言能访问的COMX (建立一个COMX对象模型)
3 本地script能够访问的COMX (双接口)
4 支持参数打包等功能的，支持RPC，甚至或者是soap协议，远程COMX
5 开始考虑对象池
6 开始考虑事务，安全机制，加密等等功能
7 其它更加高级的功能

[caowk]

可以参考XPCOM这个项目（国外的）。
是一个跨平台的COM项目。

[flyingbugs]

关注ing.