1、com不是位置透明吗？那DCOM干吗要客户断端入服务器机器名字呢？
2、我看书上说，DCOM控件一定是进程外服务器，即是个独立的可执行程序，
那么书上又说，要运行远程机器上的dll服务器，就要创建代理进程，那么
远程上的dll就不算是DCOM控件吗？是否自相矛盾？
3、假设本地服务器有多个客户，这些客户属于不同的进程，那么该服务器对象
在内存中是只有一个还是和客户数一样多？
4、如果DCOM控件一定得是exe可执行程序，那么如果有来自N台不同机器的客户
同时调用该服务器，那么服务器机子上会运行几个该DCOM的进程？
5、COM不是要对客户端透明吗？那就是只要客户只需知道其接口即可调用其功能，
那么干吗要求客户知道其套间线程这些细节呢？
还有很多，反正感觉这COM并不象电脑城里买来的声卡，插上就能用，要求用户
知道其很多细节最后,想再问一下,.net都出来了，现在学com到底有什么用啊?感觉很多人这方面
花费太多的时间，市面上com的书几乎没有了,有也是2000年以前的书,说明这项
技术已经逐渐淡出市场了，现在学习有什么用呢?
2）这个问题我也不清楚，但是你有更好的选择，com+
3)取决于你怎么做。你可以写单实例com对象，但是通常这比较危险
4）一个进程，但是还是建议用com+
5)客户端透明不是指与套间无关巴，如果你的客户程序使用了不同类型的套间，仍然可以调用，但是会有跨套间的开销。
com的确很难，如果你是新手，还是学.net巴，老手精通了com，看其他的编程总有一种从难到易的感觉，很爽。com会用于要求性能搞的地方，至少.net目前性能还不够好。com+是可以过渡到.net的一种中间件技术。
2. 进程外服务不表示COM组件必须是EXE文件。如果是DLL的话，你可以指定一个代理(surrogate而不是指proxy)，或者用系统提供的代理dllhost.exe
3. 进程内服务和客户在同一个进程内；进程外的服务器尽量使用同一个进程，除非安全性不一致。如果是Service形态，则只能有一个进程内有COM服务。
4. 参考3
5. 你不知道apartment照样可以调用COM。问题是好的设计者会考虑apartment来提高效率。COM的确是一个比较老的技术，但至少目前还有很多人在开发COM。将来基于COM的开发肯定会减少，但至少很成一段时间内还不会被淘汰。就像到现在还有人在用汇编一样。
2、一般来说DCOM组件是独立的进程外服务器，进程代理只是为使已有进程内服务器能够提供分布式服务而提出的一种兼容机制，新的DCOM组件开发时应避免使用。
3、4、组件的激活是单实例还是多实例，是单进程还是多进程，是单机唯一还是网络唯一都是服务器端激活特性，都有相应的实现方法，可以根据具体需要调整。
5、客户不需要知道组件服务器的套间特性，但要指出组件实例（或代理）应存在于什么套间中，这与服务器的套间特性无关，而服务器会根据自身的套间特性来满足客户的要求。COM技术已是昨日黄花，或者说随着开发和应用技术的进步而蜕变，但并不是没用了。再者技术的成熟和应用的成熟是有时间差的，所以还是有一定的学习价值的。