其实上面的问题是存在于自从IIS6开始，Microsoft在执行由perl.exe命令行所解析的perl程序时，默认的目录不再是该程序文件所在的目录，所以MovableType 3.2所采用的相对目录的方法，在Windows 2003 + IIS6之上，完全失效，只给出了下面的错误信息：
CGI Error
The specified CGI application misbehaved by not returning a complete set of HTTP headers.
所以，如果你的服务器，采用的是Windows 2003 + IIS6，而且你的MovableType没有安装在服务器的根目录下的，Perl解释器，又是用的Perl.exe命令的话，就要采用修改MovableType3.2源文件的办法，来升级了。这个方法对于那些租用，借用服务器的人来说适用。
现在有第二个方法，来自于一笑的大迁移，Win 2003下安装Movable Type。这个方法不错，前提是必须拥有管理员权限，我就可以，现在我就是采用他的方法，可以不必修改源文件。。
其实这篇文章的重点不再这里，我想要讲的是对于perl文件，一般采用两种方法，一种perl.exe命令行方式，一种是perlis.dll的ISAPI方式。都有优缺点，很多文章都只是介绍如何设置perl.exe命令行方式来解释perl的。
很少提到ISAPI方式。
首先看看Activeperl的官方文档：
Why should I use Perl for ISAPI rather than Perl for Win32 (perl.exe)?一笑讲的是perl isapi的兼容性好。不错，还有其它。
The short answer is: it's faster. The long answer gets kind of technical, but it goes like this:The main advantage of PerlIS over perl.exe is that PerlIS runs as a DLL in the web server's process space. Because Win32 platforms set up a protected memory space for each process that is started, there's a lot of overhead in starting a new process or program. Passing scripts to an interpreter, such as perl.exe, requires starting a new process for every script, which gets expensive in terms of system resources.
DLLs, on the other hand, don't need their own process space; they use the space of the process that calls them. They don't require nearly as much overhead to start, and once loaded they stay loaded until the calling process ends. PerlIS therefore runs Perl scripts with a quicker turn-around time than perl.exe.
Extra care should be taken when you write PerlIS applications. It is difficult to crash the web server using CGI, but because the PerlIS DLL runs in the process space of the server, your web server is more susceptible to crashes and hangs caused by programming errors.
上文讲的是Perl ISAPI速度快，采用了服务器的共享内存空间，就算是许多连接也只是使用一个共享的内存空间，那么就有一个漏洞存在，一旦一个程序被破坏，或者程序写的不好，一旦崩溃会造成整个服务器的崩溃。
使用Perl.exe则是采用进程的方式，一个连接就是一个独立的内存空间，就算崩溃了，也不会影响到服务器上其他的程序。
这样比较，如果连接数少的话，两种方式占用内存相差不多，如果访问连接数大的话，那么采用perl.exe方式使用的内存会更大。
总之，其实两种方式都有优劣，就看服务器管理员侧重的重点是哪边了。