COM本身的原理是比较简单的，但是在他基础上实现的应用却是相当麻烦，自动化、ActiveX、COM+，通过简单的基础理论变换出无穷的应用，microsoft的工程师把宏应用到了极致，每种应用都伴随着一堆DYN_和IMP_宏，让人看得好生郁闷。若非专职于相应技术的开发，学习这些理论基础，实在是一件很痛苦的事情。所以，我决定暂停《COM原理与应用》的学习。
COM除了给了我全新的对于接口、组件的认识，并且叹服于MICROSOFT的宏伟工程的同时，最重要的是，使我对软件复用有了新的认识。COM通过接口的方式，屏蔽了进程内和进程外的组件调用的差异，通过STUFF和PROXY对象，使得在网络上复用组件成为可能，这使我不得不想到我们的DA板卡驱动层，若是用COM实现驱动层的接口，就可以在局域网内共享驱动层接口，就可以在局域网内实现一台主机控制多台打标机、编辑软件与驱动层分离等功能吗？
当然，若是能够将软件做成WEB版本的，通过浏览器访问标记机，WEB本地编辑好标记内容以后，直接将标记内容上传给远程标记机进行打标，这样也是可以实现上述两个功能，而且这样的情况下，标记机的控制PC可以做的很简单，可以很好的控制成本。
总之，我认为信息化技术、自动化技术在标记环境中的应用，会是一个趋势，WEB技术会在工业领域大显身手，探讨WEB技术在标记软件上的应用，是很有意义的一件事情。
COM印象记（续）
总的来说，我觉得COM的实现与ps的插件机制有很多底层机制是非常相似的，最近下到一套solidgraph的源码，它实现了很多非常酷的技术，包括：
1. 2d/3d绘制、属性设置
2. 组合功能
3. 插件机制
4. .net风格对话框
5. lua脚本语言控制
6. 强焊而熟练的opengl渲染
所有代码基于mfc开发，特别适于我来学习。如果有时间，一定尝试用com来实现一个最小的插件系统。
COM印象记
《From CPP to COM》，虽然只是一个很小的册子，但是深入浅出，把COM的实现从C++函数逐步推进到COM实例。短短1天时间，不太可能对COM有准确把握，只是把自己的理解写下来。
1. 什么是interface？
interface是COM中一个很重要的概念，那么它到底是什么呢？是一个对象的指针，还是类的成员函数指针？在传统C++中，interface总是与function相关的，在COM中也是如此吗？我们看一段代码：
|
很有启发的一段话
……，每个人，从出生到死亡，都在忙碌的找寻对手，从一个战场到另一个战场，累积胜利多的人，最大的奖赏，是从容。
回来了，一切还是那么熟悉
从H3组回到DSP，地点变了，人也变了，要做的事情也变了，但DSP没有变，DSP/BIOS也没有变，呵呵，最后还能到南一楼走一遭，也算是圆满了。
从H3组回到DSP，突然发现对一些东西有了更清晰的理解，上层软件、DSP程序、CPLD，注意力逐渐关注到可扩展性、通用性、稳定性。
这支队伍是一支全新的，有实力的队伍，如何把他们的实力转换成实在的战斗力，就看后面的努力了。
函数调用过程中堆栈运行情况
最近看到很多资料，都是关于堆栈的，忍不住想亲自对函数调用过程中的堆栈运行情况探个究竟，下面待我细细剖来！
操作系统：windows xp
编译器：vc 6.0 sp2
程序编译版本：debug，注意：release版本生成的程序与debug版本相差甚大，但大致原理相同，因此release版本的堆栈运行情况不在本文关注范围内。
首先看看《Computer Systems》一书中关于函数调用的描述：
IA32 programs make use of the program stack to support procedure calls. The stack is used to pass procedure arguments, to store return information, to save registers for later restoration, and for local storage. The portion of the stack allocated for a single procedure call is called a stack frame. Figure 3.16 diagrams the general structure of a stack frame. The topmost stack frame is delimited by two pointers, with register %ebp serving as the frame pointer, and register %esp serving as the stack pointer. The stack pointer can move while the procedure is executing, and hence most information is accessed relative to the frame pointer.
Suppose procedure P (the caller) calls procedure Q (the callee). The arguments to Q are contained within the stack frame for P. In addition, when P calls Q, the return address within P where the program should resume execution when it returns from Q is pushed on the stack, forming the end of P’s stack frame. The stack frame for Q starts with the saved value of the frame pointer (i.e., %ebp). followed by copies of any other saved register values.
Procedure Q also uses the stack for any local variables that cannot be stored in registers. This can occur for the following reasons:
1. There are not enough registers to hold all of the local data.
2. Some of the local variables are arrays or structures and hence must be accessed by array or structure references.
3. The address operator ‘&’ is applied to one of the local variables, and hence we must be able to generate an address for it.
Finally, Q will use the stack frame for storing arguments to any procedures it calls.
As described earlier, the stack grows toward lower addresses and the stack pointer %esp points to the top element of the stack. Data can be stored on and retrieved from the stack using the pushl and popl instructions. Space for data with no specified initial value can be allocated on the stack by simply decrementing the stack pointer by an appropriate amount. Similarly, space can be deallocated by incrementing the stack pointer.
下面进入测试过程，我的测试代码如下：
#include
void test(int i)
{
char output[8];
strcpy(output, "abcdefg");
}
int main()
{
test(10);
return 0;
}
|
|
回家，是一个轮回
上次是凌晨2：30的火车回家，今天下火车，正好是凌晨2：30，一个不大不小的巧合，一个轮回。从宁静的家乡，到宁静的校园，中间经历了几多喧嚣和烦躁。被亲情和传统牵引着的一个巨大的人流，在中国大地上进行着乾坤大挪移，火车，汽车，车车爆满；公路，铁路，路路塞车。从株洲到武汉，只有区区5个小时的车程，但繁乱的票务机制、肮脏的服务设施，使人疲惫。
我切身体会到了老三不回家过年的原因了，在亲情的召唤和现实的艰难之间痛苦抉择，理想与现实之间的差距使得决择变得艰难。不管作何选择，其实都合情理。
一个轮回，回去时兴奋，回来时已经平静，最后一个学期还要我继续努力，在团队留下更多东西。
娃哈哈，准备回家咯，_
嘿嘿
回去睡觉
闹钟定到晚上12：00
醒来后直接去火车站
带着连续3天未洗的身子
带着连续穿了15天的外套
带着一堆不想带去南京
也不想扔掉的
积累了快6年的
装了两箱的
衣服、书、玩具、军训时候的军帽
回家
享受家的温馨
享受没有压力的春节
享受学生时代的最后一个春节
吃饭、睡觉、聚会、打牌
打球、飚车、喝酒
追忆儿时的恣睢
享受亲情的欢乐
创造爱情的甜蜜
回味哥们儿的情谊
爸爸、妈妈、姐姐、宝贝仔
铁哥们、老相好（传说中的）
开心
开心过头了
发现写出来的
居然有点那种味道
难道
这就是
传说中的现代诗？
哈哈哈哈哈哈哈哈哈哈
如果我是嘉铭老总，我该怎么做？
犹豫了很久，最终还是把这个贴子公布出来，非常不成熟的想法，^_^
DA板卡项目结束这么久，产品还迟迟没有出来，不得不说，我们错过了时机。
正所谓攘外必须安内，如果我是嘉铭老总，我首先会反思公司内部的问题：调试的问题、芯片采购的问题、产品化监管的问题。尤其是产品化监管的问题，DA板卡项目结题以来，一直没有一个专门的实权人物专门负责产品化，导致进度不紧不慢，芯片购买也几度出现问题。我们是不是没有把正确的人放在正确的位置上？我们的员工素质是否能够胜任高速、高精度板卡的要求？我们的生产线（比如：芯片购买、设备使用）是不是要做些调整？一个产品从它的研发到最后大规模产品化，需要走一段很长的路，在这条路上，需要的不仅仅是乙方研发人员的投入，更需要公司的技术人员、焊接工人、采购人员的通力配合，尤其是技术人员，要增强他们的素质，一定要有人懂设计原理，要有人看得懂代码，要保证一定的解决技术问题的能力，要清楚地理解现有技术的优点和缺点。并且，要在公司体制上体现产品研发、产品试制和产品化三者的联系和区别，要对产品的这三个阶段进行明确的定义，并且保证相应的人员配置，制定严格的时间点，安排专人进行监管，一个强大的公司，必须要有强大的体制作为保证，嘉铭公司以前没有遇到过迫切的产品化需求，在产品化的人员和注意力投入上还有欠缺，一人多职现象，很容易催生责任不明、时间投入不够、进度拖沓等问题。
其次，我会反思整个产品战略。DA板卡结题后，为什么不能马上产品化？是不是与上层软件没有做出来有关？上层软件做完以后，为什么要等灰度图像项目做完以后才把产品化提上很高的优先级？既然当初的定位就是控制灯泵浦，那6月份上层软件做出来以后，就应该可以产品化了。再把时间提前一点，2004年12月份做完中间层以后，到2005年12月份DA板卡结题这段时间内，我们做了什么呢？为什么没有考虑利用这段时间完成上层软件呢？所以，以后做每个项目，都要好好的整理产品战略，到底这个项目要放在哪个点？如何最大程度上节约时间？如何避免做完软件等硬件，做完硬件又等软件的情况。以前我们津津乐道的是我们将一个项目分成若干个小项目完成，这样的确有利于项目的监管，但这样必然会出现各个项目之间的接口、时序、磨合的问题；昨天张总说一次性签一个2年的项目，将软件和硬件全部来一次重构，这很可能造成项目监管不力、进度把握不足，过长的开发周期，也可能导致设计方案的过时、无法跟随市场变化等现象，影响项目的质量。这就又走向了另一个极端。我觉得，将一个大系统划分成几个子项目是正确的选择，但必须有一个统筹的安排，必须控制好时序，什么时候可以出产品，这个产品将具备哪些特性等问题应该好好考虑。这种规划，至少要考虑到2年以后的事情。Dian团队已经积累了很多经验和教训，在振镜控制系统开发领域已经入门了，应该及时的利用好Dian团队老队员，协同嘉铭有经验的研发、市场人员（尤其是市场人员），把双方近几年的产品开发时序做一个规划。这样就既可以保证单个项目成功，又可以保证项目平滑衔接，及时产品化。
最后，如果我是嘉铭老总，我会大力支持上层软件重构计划，但更会把注意力放在高速灰度图像打标、飞行打标、彩色打标等技术上，因为这些技术是重要而且紧急的事情，而上层软件重构是重要，但不太紧急的事情。这些技术的实现，将有利于上层软件重构，因为这些技术可能引入的新特性、新设计要求可以减少上层软件重构的风险和难度。当然，目前最重要最紧急的事情，就是DA板卡的产品化。
还有一些不成熟的建议：作为嘉铭老总，我会转变“做出来的东西就一定要马上产品化”的短视思维，支持Dian团队做一些前瞻性、预研性的技术探索。研发的最终目标是产品化，但产品化不能成为唯一结果，研发必然带有一定的风险性。Dian团队已经积累了很多振镜控制系统开发领域的经验和教训，对于这个行业，也逐渐有了自己的认识，他们有能力做好很多事情。
H.323与SIP
粗浅的认识：H.323和SIP同为语音通信协议，但H.323不仅考虑分组交换网，还考虑了PSTN等电路交换网，因此协议族本身包含了处理两者区别的内容，H.323协议族也被设计得很复杂，内容相当多。相比之下，SIP协议架构在分组交换网上，因此需要考虑的情况比较简单，协议也就比较简单。VOIP之初，电信网自身不太发达，PSTN占比重比较大，因此H.323协议较有市场，但是随着分组交换网的发展，尤其是NGN的发展，PSTN逐渐融合到分组交换网中，因此SIP开始以其简单、易于实现等优点显示出威力。