2007.3.27 [CAB的限制和解决方案]

.cab文件是CE-based设备上的唯一可识别的安装文件。正由于这个唯一,从而引出了很多安装部署的问题。最常见的一个就是.cab的打包文件数量的限制(1024个)。如果多于这个数的话,就会在命令行中使用Cabwiz.exe的时候返回错误。
不过我们的确也可以走一个弯路去解决这个问题,比如建立一个文件层次,在一个.cab当中打包进其他的多个.cab。但是需要注意!如果这个.cab已经在设备上安装过了,那该怎么办?
每个.cab安装包都可以有一个.dll和它联系在一起。这个dll按照规定需要暴露4个interface:Install_Init,Install_Exit,Uninstall_Init,Uninstall_Exit。而这个dll就是我们在.cab project property当中常见的CE setup dll。我们可以让它在cab安装过程中执行一些额外的功能。解压.cab释放所有的子.cab之后,Install_Exit中建立一个loop,以此调用shellExecute,进行子.cab的安装过程。
 

2007.3.25 [Getting started with FastCGI]

[Wade Himo: Understanding FastCGI Settings for IIS 5.1 & 6]
For more information see link:
 
什么是CGI?Comon Gateway Interface!为应用程序开发人员提供了与Web Server交互的能力。每一个版本的IIS都对CGI有着很好的支持。CGI规范的内容,简单来说,就是Server接收到了request,然后它创建一个新的Process去处理这个请求;对于新的Process,stdin被重定向并且用来接收来自Client的request;stdout也被重定向并且用来向client写回数据。此外,command line和环境变量被用来提供CGI进程的信息。
 
CGI之上的问题:为了处理每一个CGI的请求,都会导致一个新的Process,spinning up,doing work,shutting down。对于一个light weight process creation的os来说,性能会受限于doing work这个部分;对于一个os是expensive operation来说的话,doing work这个部分会让这个系统崩溃掉。所以,“This is the reason that CGI flourishes on our main competition running on a Unix-based platform, but is not recommended on IIS.
 
什么是ISAPI?Internet Server Application Programming Interface!运行于Web Server Process的内部。当新的request到达时,不会去创建新的进程。取而代之的是,Web Server会加载.dll到自己的process,并调用他的入口函数。“Instead, the web server calls an entry point in a dll that is loaded into the web server process. ”。ISAPI可以启用线程模型来提高性能。
 
什么是FastCGI?为什么我们需要它?“Basically, we need FastCGI due to the existence of popular CGI-based development platforms”。PHP很早之前就已经被IIS所支持了,通过CGI和ISAPI来实现。但是这两种实现都只是一种折中!CGI的实现会受到进程创建特性的限制;而ISAPI由于运行在多线程的进程中,PHP实现本身是线程安全的,但是很多对他的扩展并不是这样子的,这对服务器的稳定会造成隐患。
 
FastCGI提供了对性能和稳定保障的解决方案。为此,FastCGI保留几乎所有的原始CGI(包括非多线程的环境),但是它允许CGI的宿主进程,在request处理完成之后保留该进程,并使之被重用。
 
So what does my ISAPI background have to do with FastCGI在IIS 7中的PHP handler和后台的ISAPI并没有联系。这是应为IIS 7提供了许多全新的强大的API,用来host各种不同俄平台。对于早期版本的IIS没有这样丰富的API,所以FastCGI是运行在ISAPI之上的。
 
FastCGI可以被分成以下几个部分: Applications, the Application Manager, and various code to support the FastCGI protocol。为了能够同时处理多个request,FastCGI handler使用到了进程池(process pool/application)。有许多进程池的属性将需要被进行适当的配置,如:进程池中进程的个数,一个进程中可以被接收的request的数量。FastCGI handler也支持多进程池!因为可能同时会有多个种类的FastCGI运行在服务器上面(PHP和Ruby),也可能一个服务器上会有多个站点。Multiple process pools由application manager来进行管理。
 
最后,需要将FastCGI handler加载进IIS,这样才能让到达的request被路由到其之上。IIS 7和之前的版本有着很大的不同。在IIS 5.1和6.0之中,我们使用“script maps”将特定的文件扩展名映射到处理它的ISAPI上。除此之外,我们可以指定,只有当对应于请求的文件存在的时候,该请求才会被处理。这是出于安全考虑的一种设置方案,但是在很多情况下,我们希望我们的url并没有其下对应的物理文件。
 
包含FastCGI handler的ISAPI extension是fcgiext.dll。如果要FastCGI handler处理php,就要把.php映射到.fcgiext.dll上;如果要处理Ruby,就映射.rb。我们也可以使用“wildcard script map”来让所有的request都由fcgiext.dll来处理。
 
Posted in IIS

2007.3.22 [getting started with CEMAPI – 1st]

[读书笔记 from developer.com Mastering CEMAPI]
.Net CF 尽管已经发展到了2.0,但是就我个人而言,它所提供的功能还是相当差~~劲的。就拿对Mobile Outlook的访问来说,支持的并不是很完全,很多我们想要的功能interface还是没有提供出来(只能用来发发邮件,发发短信。汗~)。最大的遗憾就是我们不能轻易的访问msgbase当中存储的信息数据。因此研究古老而又强大的Microsoft CE MAPI是相当有必要的。
从PPC 2002开始,Microsoft改变了移动设备上的Message存储模型,丢弃了MsgStore,使用CEMAPI。
那么,什么是CEMAPI呢?引用eVC当中的话
"Windows CE Message Application Programming Interface is for mobile devices, what MAPI is for Computers. CEMAPI provides a set of classes, interfaces, functions, and other data types to facilitate the development of messaging applications for mobile devices"
To be continued…

2007.3.20 [关于.Net CF 1.0 到 2.0的迁移问题]

Q:如果用Visual Studio 2005开发的基于.Net CF 1.0的项目需要迁移到2.0的话该怎么处理?
A:很简单,用文本编辑工具打开project文件(e.g.,C#项目为.csproj文件),修改当中<TargetFrameworkVersion>的值就可以了。自己修改dll的引用是不行的,因为项目属性仍然没有改变,是基于过去的版本的,所以编译也无法通过。
 
Note: Visual Studio IDE 会自动为我们更换Reference当中的.dll 的引用至2.0的版本。如果部分.dll是自己手工添加的,那么需要Remove之后,重新再Add进去。在迁移过程中,需要关闭项目中的UI Designer,否则迁移完毕后,Designer会无法正常显示(主要原因是.Net CF 1.0和2.0中很多控件的成员、属性的名称不同)。
 
[补:感谢Yi-Lun Luo为我提供的帮助]