四月的天气忽冷忽热，和此刻不舒服的心情几乎相同。傍晚时分看落霞万里云起云落，日头慢慢落到高楼林立的背后，一天就这样过去了。四月的风啊，寒冷中带着一丝春的羞涩，很多没有这样的落寞情怀了。
整天面对电脑的方寸之地，已忘了外面是什么样子了。这世界，似乎已将我忘记。曾记否，杨柳依依，年少时光，今昔无言，只留一地黄花。虽然感事伤怀是一种坏习惯，但总归难免，就当是给心情一个假期，给生活一抹亮色吧。阿门.....
2006-04-18 20:07
整天面对电脑的方寸之地，已忘了外面是什么样子了。这世界，似乎已将我忘记。曾记否，杨柳依依，年少时光，今昔无言，只留一地黄花。虽然感事伤怀是一种坏习惯，但总归难免，就当是给心情一个假期，给生活一抹亮色吧。阿门.....
2006-04-18 20:07
FLTK，如同其名字所表达的：The Fast Light Tool Kit，一个轻量级的GUI开发库。但这轻量级并不代表功能的羸弱，相反，FLTK在具有基本的GUI功能之外，还拥有一些特殊的功能，比如跨平台、内置 OpenGL功能、速度更快、尺寸更小、协议宽松等。当然，缺点也是有的，比如对于复杂的界面构件支持不够，资源支持的不足等。但一个工具如果使用的好，取其长而去其短，自然可以飞花摘叶皆可伤人;P
我选择FLTK 的过程还是比较曲折的，当初做ARM下的GUI开发，选择的GUI库是MiniGUI，一个国内开发的界面库。当时还支持类unix平台，对 Windows的支持尚在开发中。由于需要寻找一些问题的解答，所以经常在其论坛上搜索，从而知道了还有microwindow、nano、 qtembedded等嵌入型GUI开发库，但当时没有太过注意。后来又开始转向WINCE平台的开发，这一搁就是２年。再后来终于要做跨平台的开发，对具有跨平台的GUI开发库开始注意起来。
一开始的选择是wxWidgets，但是研究了一段时间后发现不好解决的问题越来越多，终于放弃。最头疼的就是C++类的事件传递，wxWidgets内部使用的是一个类似MFC的方法，所有传递事件的类全部要从一个根类继承，这样就导致创建的类和wxWidgets绑定过甚，复用性大大降低，同时由于wxWidgets的目标不仅仅是GUI，造成其包含功能过多，其内部结构非常复杂，虽然是 OpenSource，但要若要修改其代码还是很困难的。综上所述，wxWidgets并不符合我的要求，从而被排除在外。
之后研究的QT，老牌的跨平台GUI开发库，工具很多，开发也很人性化，qtdesign很像Delphi的界面开发方式，代码带有强烈的linux风格，但是看看附带的库文件又实在让人有些泄气，尺寸大，发布麻烦。所以在试用了一段时间后还是放弃了。
在此期间，其实也看到过一些对FLTK的介绍，但大多数对其评价不高，也就没有注意。直到有一次偶然心血来潮，上http: //www.fltk.org看了一下，发现FLTK 似乎正对我的胃口，这才开始对其进行了深入的研究。经过一段时间的实际开发，个人觉得，对于跨平台和代码简洁而言，FLTK是再适合不过了。
FLTK的底层只提供一套完整的画点、画线功能，另外附带了字体的显示功能，但FLTK对字体的支持还很粗糙，尤其对于非英文字符集而言，后面我会详细说明。在基本的点、线功能基础上，FLTK完全自己实现了一套界面，比如Button、Label、Edit、Tab等，全部都是由基本的点线画出。看到这，可能你会觉得这实在是属于自己造轮子，吃力不讨好。诚然，如果你只针对一种平台开发，这样的做法不能带来多少好处，还造成学习时间的拉长。但若要针对多个平台开发，这样做的好处就很明显了。首先是移植容易，只要针对目标平台实现基本的点线功能就可以实现代码的移植，这可能是所有跨平台GUI库中最方便最直接的方案，目前FTLK支持MacOS、Windows、Linux(x-window)等平台，针对WinCE（主要是unicode的问题）和plam 的开发正在进行中。其次是保持了界面的一致性，虽然QT、GTK等开发库也具有这种功能，但是他们都需要一套基本库的支持，无法做到系统尺寸的优化，而对于FLTK而言，这却恰恰是他的优点和长项。最后是代码层次清楚、结构简单，由于大部分的工作就是基于底层的点线功能进行自绘，所有很多代码都是简洁明了，很少费话。
底层之上是一套以Fl_开头的类，代表了各种GUI构件，比如Fl_Window、Fl_Button、 Fl_Input等，使用起来很是容易。同时由于上面所说的，所有的界面构件都是画出来的，因此在熟悉了这种方式后，生成自己的构件也是很容易的，反正是画界面嘛，既然别人能做到，你也能做到，实在不行可以查阅源代码进行学习。这些界面类的共同特点是轻量型、都拥有一个draw()，只要在draw()里实现自己的绘画动作即可。
说到界面就不能不说其事件实现方式，对于FLTK而言，使用的是最直接的方法：while(1){}。这也是很多人批评FLTK原始的一个原因。但仔细想想，其实这是最直接的办法，不管是哪种平台，最终的事件方案不外乎是死循环和中断，中断的确具有很多好处，但只要while(1)能完成这部分的功能，那又有什么关系呢。每个界面类都有一个handle(int event)，只要继承这个成员函数，就可以在其中处理自己的事务。是不是很简单？同时由于这样的事件方式，造成FLTK的刷新速度很快，事件反应迅速，也算是个附带优点了。现在大多数的开发库都是采用OO方式的事件处理方式，但FLTK却采用了最原始的函数指针方式，也算是一个异类，这可能和FLTK的 ...
阅读全文...
我选择FLTK 的过程还是比较曲折的，当初做ARM下的GUI开发，选择的GUI库是MiniGUI，一个国内开发的界面库。当时还支持类unix平台，对 Windows的支持尚在开发中。由于需要寻找一些问题的解答，所以经常在其论坛上搜索，从而知道了还有microwindow、nano、 qtembedded等嵌入型GUI开发库，但当时没有太过注意。后来又开始转向WINCE平台的开发，这一搁就是２年。再后来终于要做跨平台的开发，对具有跨平台的GUI开发库开始注意起来。
一开始的选择是wxWidgets，但是研究了一段时间后发现不好解决的问题越来越多，终于放弃。最头疼的就是C++类的事件传递，wxWidgets内部使用的是一个类似MFC的方法，所有传递事件的类全部要从一个根类继承，这样就导致创建的类和wxWidgets绑定过甚，复用性大大降低，同时由于wxWidgets的目标不仅仅是GUI，造成其包含功能过多，其内部结构非常复杂，虽然是 OpenSource，但要若要修改其代码还是很困难的。综上所述，wxWidgets并不符合我的要求，从而被排除在外。
之后研究的QT，老牌的跨平台GUI开发库，工具很多，开发也很人性化，qtdesign很像Delphi的界面开发方式，代码带有强烈的linux风格，但是看看附带的库文件又实在让人有些泄气，尺寸大，发布麻烦。所以在试用了一段时间后还是放弃了。
在此期间，其实也看到过一些对FLTK的介绍，但大多数对其评价不高，也就没有注意。直到有一次偶然心血来潮，上http: //www.fltk.org看了一下，发现FLTK 似乎正对我的胃口，这才开始对其进行了深入的研究。经过一段时间的实际开发，个人觉得，对于跨平台和代码简洁而言，FLTK是再适合不过了。
FLTK的底层只提供一套完整的画点、画线功能，另外附带了字体的显示功能，但FLTK对字体的支持还很粗糙，尤其对于非英文字符集而言，后面我会详细说明。在基本的点、线功能基础上，FLTK完全自己实现了一套界面，比如Button、Label、Edit、Tab等，全部都是由基本的点线画出。看到这，可能你会觉得这实在是属于自己造轮子，吃力不讨好。诚然，如果你只针对一种平台开发，这样的做法不能带来多少好处，还造成学习时间的拉长。但若要针对多个平台开发，这样做的好处就很明显了。首先是移植容易，只要针对目标平台实现基本的点线功能就可以实现代码的移植，这可能是所有跨平台GUI库中最方便最直接的方案，目前FTLK支持MacOS、Windows、Linux(x-window)等平台，针对WinCE（主要是unicode的问题）和plam 的开发正在进行中。其次是保持了界面的一致性，虽然QT、GTK等开发库也具有这种功能，但是他们都需要一套基本库的支持，无法做到系统尺寸的优化，而对于FLTK而言，这却恰恰是他的优点和长项。最后是代码层次清楚、结构简单，由于大部分的工作就是基于底层的点线功能进行自绘，所有很多代码都是简洁明了，很少费话。
底层之上是一套以Fl_开头的类，代表了各种GUI构件，比如Fl_Window、Fl_Button、 Fl_Input等，使用起来很是容易。同时由于上面所说的，所有的界面构件都是画出来的，因此在熟悉了这种方式后，生成自己的构件也是很容易的，反正是画界面嘛，既然别人能做到，你也能做到，实在不行可以查阅源代码进行学习。这些界面类的共同特点是轻量型、都拥有一个draw()，只要在draw()里实现自己的绘画动作即可。
说到界面就不能不说其事件实现方式，对于FLTK而言，使用的是最直接的方法：while(1){}。这也是很多人批评FLTK原始的一个原因。但仔细想想，其实这是最直接的办法，不管是哪种平台，最终的事件方案不外乎是死循环和中断，中断的确具有很多好处，但只要while(1)能完成这部分的功能，那又有什么关系呢。每个界面类都有一个handle(int event)，只要继承这个成员函数，就可以在其中处理自己的事务。是不是很简单？同时由于这样的事件方式，造成FLTK的刷新速度很快，事件反应迅速，也算是个附带优点了。现在大多数的开发库都是采用OO方式的事件处理方式，但FLTK却采用了最原始的函数指针方式，也算是一个异类，这可能和FLTK的 ...
阅读全文...
老文档，放在这里做存档，希望这个blog能存活的久一点，以下为正文：
=============================================
项目基本结束，这个是其中系统裁减的一个总结文档，不知道有没有人感兴趣：)
=============================================
前言:
为了完成用户的需求，需制作一个完整的环境供AP运行，且存在一些约束条件。
关键字：
DOM Kernel Busybox X-Window Window-Manager Interbase nvidia cutdown
目标说明：
在一个64M的DOM(Disk on module)上建立可以运行完整的AP的环境
约束条件：
1、可利用的总空间为64M，由DOM提供，但实际可用空间只有53-59M，原因可能与设备文件和DOM本身有关，未确定
2、显卡为nvidia系列
3、kernel选用2.4.20，没有使用redhat自带的版本。采集卡的Driver目前还只能在2.4.20的kernel下编译，由于其移植性较差，已经开始考虑重新整理成可适合kernelversion大于2.4.25的所有kernel，参考bttv的最新实现
4、数据库选用interbase系列，目前使用的为firebird-1.5(firebird为interbase的开源实现，接口和interbase基本相同)。
5、其他附属的功能要求，在后面的文档中会有说明
制作流程：
某些部分的原理和实现没有办法写的很全面，但基本上会提供一些url的连接，供相关人员参考。基本上按照制作流程来写，前后相互牵连的部分不做特别说明。
一、Kernel的选择和编译：
由于driver的缘故，只能使用2.4.20的kernel。2.4.20和2.4.25都有对Driver做过尝试，其他版本的kernel没有试过，应该是可以的，尚未确认。在2.6的kernel上无法编译，目前确定的原因是makefile有问题，估计做一些相应的修改还是可以的，可参考 bttv的makefile(http://linux.bytesex.org/v4l2/bttv.html)。
回到kernel上来，基本上的编译原则是尽量减去不需要的部分，以及除了一些需要临时加载的Driver尽量不要出现module。由于上面所说的理由，DOM中使用的kernel为原始的2.4.20，可以从http://www.kernel.org下载，本文档的附加文件里也可以找到。
另外，由于需求的定义，系统启动时需要显示splash画面，所以kernel还需要加入bootsplash功能，这个功能是第三方提供的，作为补丁加入kernel。作法如下：
1、打内核补丁并编译内核
假设内核源文件安装在/usr/src/linux/。下载bootsplash 3.07(地址：ftp://ftp.suse.com)，然后：
yourbox:~ # cd /usr/src/linux
yourbox:/usr/src/linux # patch -p1 < /path/to/bootsplash-3.0.7-2.4.20-vanilla.diff
yourbox:/usr/src/linux #
配置内核，如make menuconfig或make xconfig，在”Console drivers” -> “Frame-Buffer support” 选择 “VESA VGA graphics console” 或其他与你的显卡相应的驱动。打开 “Use splash screen instead of boot logo”. 在 “Block Devices”中打开”Initial Ramdisk support”，保存配置并编译内核，将生成的内核拷到/boot 下，并修改lilo或grub的配置文件以使用新的内核来启动。
2、加入图片
下载并安装splash工具：ftp://ftp.suse.com/pub/people/
# cd ~/splash
# tar xvjf splashutils.tar.bz2
splashutils/
splashutils/Makefile
splashutils/splash.c
[..]
splashutils/ChangeLog
splashutils/COPYING
# cd splashutils
# make splash
gcc -Os -Wall -c -o splash.o splash.c gcc -Os -Wall -o splash splash.o
strip splash
# cp splash /sbin/
...
阅读全文...
=============================================
项目基本结束，这个是其中系统裁减的一个总结文档，不知道有没有人感兴趣：)
=============================================
前言:
为了完成用户的需求，需制作一个完整的环境供AP运行，且存在一些约束条件。
关键字：
DOM Kernel Busybox X-Window Window-Manager Interbase nvidia cutdown
目标说明：
在一个64M的DOM(Disk on module)上建立可以运行完整的AP的环境
约束条件：
1、可利用的总空间为64M，由DOM提供，但实际可用空间只有53-59M，原因可能与设备文件和DOM本身有关，未确定
2、显卡为nvidia系列
3、kernel选用2.4.20，没有使用redhat自带的版本。采集卡的Driver目前还只能在2.4.20的kernel下编译，由于其移植性较差，已经开始考虑重新整理成可适合kernelversion大于2.4.25的所有kernel，参考bttv的最新实现
4、数据库选用interbase系列，目前使用的为firebird-1.5(firebird为interbase的开源实现，接口和interbase基本相同)。
5、其他附属的功能要求，在后面的文档中会有说明
制作流程：
某些部分的原理和实现没有办法写的很全面，但基本上会提供一些url的连接，供相关人员参考。基本上按照制作流程来写，前后相互牵连的部分不做特别说明。
一、Kernel的选择和编译：
由于driver的缘故，只能使用2.4.20的kernel。2.4.20和2.4.25都有对Driver做过尝试，其他版本的kernel没有试过，应该是可以的，尚未确认。在2.6的kernel上无法编译，目前确定的原因是makefile有问题，估计做一些相应的修改还是可以的，可参考 bttv的makefile(http://linux.bytesex.org/v4l2/bttv.html)。
回到kernel上来，基本上的编译原则是尽量减去不需要的部分，以及除了一些需要临时加载的Driver尽量不要出现module。由于上面所说的理由，DOM中使用的kernel为原始的2.4.20，可以从http://www.kernel.org下载，本文档的附加文件里也可以找到。
另外，由于需求的定义，系统启动时需要显示splash画面，所以kernel还需要加入bootsplash功能，这个功能是第三方提供的，作为补丁加入kernel。作法如下：
1、打内核补丁并编译内核
假设内核源文件安装在/usr/src/linux/。下载bootsplash 3.07(地址：ftp://ftp.suse.com)，然后：
yourbox:~ # cd /usr/src/linux
yourbox:/usr/src/linux # patch -p1 < /path/to/bootsplash-3.0.7-2.4.20-vanilla.diff
yourbox:/usr/src/linux #
配置内核，如make menuconfig或make xconfig，在”Console drivers” -> “Frame-Buffer support” 选择 “VESA VGA graphics console” 或其他与你的显卡相应的驱动。打开 “Use splash screen instead of boot logo”. 在 “Block Devices”中打开”Initial Ramdisk support”，保存配置并编译内核，将生成的内核拷到/boot 下，并修改lilo或grub的配置文件以使用新的内核来启动。
2、加入图片
下载并安装splash工具：ftp://ftp.suse.com/pub/people/
# cd ~/splash
# tar xvjf splashutils.tar.bz2
splashutils/
splashutils/Makefile
splashutils/splash.c
[..]
splashutils/ChangeLog
splashutils/COPYING
# cd splashutils
# make splash
gcc -Os -Wall -c -o splash.o splash.c gcc -Os -Wall -o splash splash.o
strip splash
# cp splash /sbin/
...
阅读全文...
在x-window和windows下移动鼠标
[ 2006-04-16 10:15:50 | 作者: 痉挛的老鸨 ]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#ifdef WIN32
#include <windows.h>
#else
#include <unistd.h>
#include <X11/X.h>
#include <X11/Xlib.h>
#endif
int main(int argc, char* argv[])
{
char sx[10], sy[10];
int x, y;
if ( argc < 3 ) return 0;
strcpy(sx, argv[1]);
strcpy(sy, argv[2]);
x = atoi(sx);
y = atoi(sy);
#ifdef WIN32
SetCursorPos(x, y);
#else
Display *dpy;
Window rootwindow;
dpy = XOpenDisplay(NULL);
if ( ! dpy ) {
printf("Couldn't open Xdisplay.\n");
exit(1);
}
rootwindow = DefaultRootWindow(dpy);
...
阅读全文...
#include <stdlib.h>
#include <string.h>
#ifdef WIN32
#include <windows.h>
#else
#include <unistd.h>
#include <X11/X.h>
#include <X11/Xlib.h>
#endif
int main(int argc, char* argv[])
{
char sx[10], sy[10];
int x, y;
if ( argc < 3 ) return 0;
strcpy(sx, argv[1]);
strcpy(sy, argv[2]);
x = atoi(sx);
y = atoi(sy);
#ifdef WIN32
SetCursorPos(x, y);
#else
Display *dpy;
Window rootwindow;
dpy = XOpenDisplay(NULL);
if ( ! dpy ) {
printf("Couldn't open Xdisplay.\n");
exit(1);
}
rootwindow = DefaultRootWindow(dpy);
...
阅读全文...
做了4、5年的开发，大大小小的项目也做了不少，但以前都有一个致命的问题，不知不觉就会写出一个巨大的主程序出来，层次复杂，编码痛苦，调试困难。但似乎大家都认同这样的开发方式，虽然都知道界面和功能分离是好事情，但就是做不到。我自己也曾痛苦的思考过，但没有什么收效，似乎在Windows下的开发只能是这么痛苦。
一星期前买了<<unix编程艺术>>，这一周可谓改天换地，每天都在阅读和思考中度过，想必武侠小说中的武功大进也就是这个意思了。虽然书还没看完，但是有些话实在是不吐不快。
什么是界面？界面就是功能的子集。没有哪个界面能反映所有的功能，但是若没有界面，对于最终用户来说又是不可忍受的，无论如何都不能指望让一个门卫学会输入复杂的命令来完成工作，虽然最终用户也包括专业人士，但这世界上终究普通人更多。在这样的前提下，可以认为功能永远比界面更宽泛，更有适应性，而GUI更狭窄，更具有特殊性，所以将界面和功能进行分拆也就成为一种必然趋势。
但是如何分拆？在Windows的世界里，一个普遍观点就是DLL。DLL很好，但是还不够好，因为无法直接使用、调试以及升级，带来的问题远比好处多。另一种方法就是在代码级进行分层，比如GUI一层，功能一层，再用胶合层将二者整合。且不论胶合层的不可复用和调试困难，就一条，如何能做到GUI崩溃的时候却不影响功能的实现？以前我做过的项目都是这样处理的，直接的后果就是项目越到后期问题越多，代码越不接受变化。调试花费了大量的人力物力，收效却未必好，功能的一点点小修改就会造成代码里出现意大利面条。你可以说只要前期的小心规划和仔细架构就能避免这些问题，但是谁能准确预测未来？无论做怎样的努力，你也不能保证现在的功能永远不变，永远不变的恰恰就是变。如果不能保持实现的稳定性和较好的移植性，这样的项目下场一般都不太好。
说了这么多废话，还是赶紧进入正题。谈谈这一周来的心得体会！
首先，变化是渐进的，非突变式的。如果能将变化的所在约束在一个比较小的代码范围内，修改就不会成为噩梦。怎么约束？就一个要求：在保证完整性的条件下让每个模块包含的功能尽量单一和足够小。首先是保证完整性，不是代码足够短，包含的实现足够少就是完整，要达到完整，就要让模块的各个部分做到不可分割和无需添加，按照古人的说法，就是增一分则太多，减一分则太少。这个要求虽然看起来很好理解，其实并没有什么标准答案，每个人心里都有自己的回答，正所谓仁者见仁，智者见智。其次是单一化和小型化，一般来说，范围太大的东西会造成人脑覆盖不全，比如一个功能，如果牵扯的部分过多，就会造成从底层到中间层，再到上层，全部都要思考到，估计没有几个人能做到，即使做到了，将来的维护和修改也会变成噩梦。相反，只要功能的涉及面够窄，就很容易进行思考和修改，这个道理应该没有什么问题。
既然要保证模块单一、小型化和保证完整，也就意味着这个模块可以认为是一个完整而单独的程序，无需外围程序的支持就可以单独运行和测试。从而引出我的最重要的观点：尽量用多进程来分拆程序。在Windows的世界里，多进程似乎是天生被忽略和鄙视的，从unix的观点看，其主要原因是Windows的设计中对进程的快速创建支持不够，造成对多进程的天然排斥和害怕。但是换一个思路看，多进程也许是目前最好的架构方式。底层的功能分拆成各个进程单独运行，通过ipc和上层的GUI进行交互，胶合层薄了，移植性增强了，调试容易了，功能演进也不再成为噩梦。需求永远是渐变的，所以进程的渐变也就成为可控的行为。
多进程间的传递方式一般有这么几种：共享内存，管道(pipe)，信号，消息， socket。其中共享内存适宜于大量数据的即时传递，速度快，容量大。但使用共享内存时需要仔细考虑读写冲突问题，一般的解决办法是用全局锁，但是锁的存在必然会造成效率的下降，所以能不用锁就尽量不要用。pipe的速度和容量都没有共享内存好，但是用来传递命令和返回值还是很适合的。信号和消息的方式一般会和操作系统联系紧密，个人不太喜欢。最后是socket，对于异地交互而言，socket是目前很常用的手段，甚至本地进程间通讯也可以使用。但是由于和网络有关，所以同步性不好保证，需要辩证的使用。
说了这么多，举个例子说明一下。假设现在要做一套点菜软件供酒店使用，其基本功能包括人员管理，桌台管理，点菜管理，结账以及后台管理五个功能模块。按照单进程的方式就是将所有功能整合在一起，系统启动时加载所有的功能，一旦某个模块出现问题，则必须重新启动程序，而且各个模块之间很容易发生资源冲突和请求冲突。如果换成多进程方式，让我们看看有什么不同。首先是所有的功能最终目的地都是数据库，那么可以开发一个后台进程专门所有负责针对数据库的请求，通过pipe或者共享内存来接收命...
阅读全文...
一星期前买了<<unix编程艺术>>，这一周可谓改天换地，每天都在阅读和思考中度过，想必武侠小说中的武功大进也就是这个意思了。虽然书还没看完，但是有些话实在是不吐不快。
什么是界面？界面就是功能的子集。没有哪个界面能反映所有的功能，但是若没有界面，对于最终用户来说又是不可忍受的，无论如何都不能指望让一个门卫学会输入复杂的命令来完成工作，虽然最终用户也包括专业人士，但这世界上终究普通人更多。在这样的前提下，可以认为功能永远比界面更宽泛，更有适应性，而GUI更狭窄，更具有特殊性，所以将界面和功能进行分拆也就成为一种必然趋势。
但是如何分拆？在Windows的世界里，一个普遍观点就是DLL。DLL很好，但是还不够好，因为无法直接使用、调试以及升级，带来的问题远比好处多。另一种方法就是在代码级进行分层，比如GUI一层，功能一层，再用胶合层将二者整合。且不论胶合层的不可复用和调试困难，就一条，如何能做到GUI崩溃的时候却不影响功能的实现？以前我做过的项目都是这样处理的，直接的后果就是项目越到后期问题越多，代码越不接受变化。调试花费了大量的人力物力，收效却未必好，功能的一点点小修改就会造成代码里出现意大利面条。你可以说只要前期的小心规划和仔细架构就能避免这些问题，但是谁能准确预测未来？无论做怎样的努力，你也不能保证现在的功能永远不变，永远不变的恰恰就是变。如果不能保持实现的稳定性和较好的移植性，这样的项目下场一般都不太好。
说了这么多废话，还是赶紧进入正题。谈谈这一周来的心得体会！
首先，变化是渐进的，非突变式的。如果能将变化的所在约束在一个比较小的代码范围内，修改就不会成为噩梦。怎么约束？就一个要求：在保证完整性的条件下让每个模块包含的功能尽量单一和足够小。首先是保证完整性，不是代码足够短，包含的实现足够少就是完整，要达到完整，就要让模块的各个部分做到不可分割和无需添加，按照古人的说法，就是增一分则太多，减一分则太少。这个要求虽然看起来很好理解，其实并没有什么标准答案，每个人心里都有自己的回答，正所谓仁者见仁，智者见智。其次是单一化和小型化，一般来说，范围太大的东西会造成人脑覆盖不全，比如一个功能，如果牵扯的部分过多，就会造成从底层到中间层，再到上层，全部都要思考到，估计没有几个人能做到，即使做到了，将来的维护和修改也会变成噩梦。相反，只要功能的涉及面够窄，就很容易进行思考和修改，这个道理应该没有什么问题。
既然要保证模块单一、小型化和保证完整，也就意味着这个模块可以认为是一个完整而单独的程序，无需外围程序的支持就可以单独运行和测试。从而引出我的最重要的观点：尽量用多进程来分拆程序。在Windows的世界里，多进程似乎是天生被忽略和鄙视的，从unix的观点看，其主要原因是Windows的设计中对进程的快速创建支持不够，造成对多进程的天然排斥和害怕。但是换一个思路看，多进程也许是目前最好的架构方式。底层的功能分拆成各个进程单独运行，通过ipc和上层的GUI进行交互，胶合层薄了，移植性增强了，调试容易了，功能演进也不再成为噩梦。需求永远是渐变的，所以进程的渐变也就成为可控的行为。
多进程间的传递方式一般有这么几种：共享内存，管道(pipe)，信号，消息， socket。其中共享内存适宜于大量数据的即时传递，速度快，容量大。但使用共享内存时需要仔细考虑读写冲突问题，一般的解决办法是用全局锁，但是锁的存在必然会造成效率的下降，所以能不用锁就尽量不要用。pipe的速度和容量都没有共享内存好，但是用来传递命令和返回值还是很适合的。信号和消息的方式一般会和操作系统联系紧密，个人不太喜欢。最后是socket，对于异地交互而言，socket是目前很常用的手段，甚至本地进程间通讯也可以使用。但是由于和网络有关，所以同步性不好保证，需要辩证的使用。
说了这么多，举个例子说明一下。假设现在要做一套点菜软件供酒店使用，其基本功能包括人员管理，桌台管理，点菜管理，结账以及后台管理五个功能模块。按照单进程的方式就是将所有功能整合在一起，系统启动时加载所有的功能，一旦某个模块出现问题，则必须重新启动程序，而且各个模块之间很容易发生资源冲突和请求冲突。如果换成多进程方式，让我们看看有什么不同。首先是所有的功能最终目的地都是数据库，那么可以开发一个后台进程专门所有负责针对数据库的请求，通过pipe或者共享内存来接收命...
阅读全文...
这一两年，开源在国内势头猛烈，虽然还是雷声大雨点小，但关注总好过不关注。剔除一些不太热门的部分，开源在大多数人的心目中就是指linux及其平台下孕育出的相关软件。那就从这里开始我的一些废话。
开始接触linux是在96年，那时internet还属于新鲜概念，能用telnet上个bbs就能让人激动半天，更不要说ftp、bt、emule之类的玩艺，唯一能得到新软件的途径就是校门口卖盗版的。从某种意义上说，盗版在普及和深化计算机教育上还是有所贡献的。那时从门口买了一套rh的光盘，就开始在机器上开始折腾，但由于没有任何的帮助和获得帮助的途径，所以只是获得了对linux一些初步的认识。也正是因为rh，开始对操作系统感兴趣，也研究了一阵子minix，可惜没有坚持下去。
再次接触linux是在2003年，当时是进入一家台湾企业开发linux平台下的监控软件。由于当时要做一个基于x86的小型系统，os+ ...
阅读全文...
开始接触linux是在96年，那时internet还属于新鲜概念，能用telnet上个bbs就能让人激动半天，更不要说ftp、bt、emule之类的玩艺，唯一能得到新软件的途径就是校门口卖盗版的。从某种意义上说，盗版在普及和深化计算机教育上还是有所贡献的。那时从门口买了一套rh的光盘，就开始在机器上开始折腾，但由于没有任何的帮助和获得帮助的途径，所以只是获得了对linux一些初步的认识。也正是因为rh，开始对操作系统感兴趣，也研究了一阵子minix，可惜没有坚持下去。
再次接触linux是在2003年，当时是进入一家台湾企业开发linux平台下的监控软件。由于当时要做一个基于x86的小型系统，os+ ...
阅读全文...
1
