决定把cme的控制中心移植到windows平台

08年时把控制中心放在linux平台的原因是，由于当时自己手动写socekt通讯，很是不稳定，后来09年发现ICE这个利器之后，通讯就不成问题了，因为ICE支持多平台多语言。

去年又想把控制中心放置到windows平台，因为好多用户要测试的话，人家很讨厌还要再装个linux系统或者虚拟机，而且大多数人不动linux命令，因此而不太喜欢这种部署方式。

有一句话我觉得是软件开发人员应该谨记的:

    我们不能因为什么平台环境开发方便而把软件开发成在这种平台运行的系统，而是应该以市场和客户喜欢，通用的运行环境为最终目标。

比如你在电脑上运行，测试手机软件相对于在手机上更方便些，你就不能因此而对客户说，我们的软件只喜欢电脑主机。。。。显然这样很搞笑的。

经过了昨天和前天三十六小时的黑暗生活，看了别人公司的代码框架和代码，虽然感觉比我自己的差，但是它们的最终目标很明确，客户端和server端都是windows，这就适用了大多数的用户。

   接着说去年想把控制中心放到windows那件事，后来因为mysql的开发接口VC6玩不转，需要vs2003-vs2008的一个版本，后来想了想，client是VC6的ICE开发的，这样整个客户端都需要升级到vs2005来做，未免大动干戈。加上后来mysql在vs2005上用mysql++进行访问的情况下也不是很稳定，就一怒之下放弃了windows平台上控制中心的开发。

   过去的两天深切被别人的windows平台理念所触动，想下，还是花点时间把控制中心移植到windows平台吧。首先大方向要对，问题一个个解决吧。

  事实上经过一个上午零星的测试，发现移植工作并不是多大难题。

  由于msgServer是基于ICE的，本机IPC是我用封装的多平台内存池实现的，很快msgServer就完成了移植，测试也没问题了。

  唯一要注意的就是一些API在windows平台上和linux平台上的命名和调用差别，比如二进制打开文件，

windows平台上的第二个参数需要会这样写

flag = O_WRONLY|O_CREAT|O_TRUNC | O_BINARY;

而linux的open本来就是二进制的

因此写法如下:

flag = O_WRONLY|O_CREAT|O_TRUNC

这些都是需要注意的。

还要做的工作有:

1) dbserver通过vs2005移植到windowsxp上，还采用libmysql++的方式访问库。

2)想办法对cmdserver进行通讯和访问库的分离，但是这样又会降低命令结果执行返回的时效性。

3)控制台程序怎么在后台运行，不能一直跑个黑屏啊，我勒个去···