10月31日 19点。
Youtube又能直连了。
看来这是第一个被解除双层墙封锁的外站，看来我那预言果真有效。很多洋人上网唯一乐趣也就是youtube了，封了明年狗林匹克就会挨批评了。但是这绝对不是上次封yahoo那样看上去纯属错误，而是故意所为 （挨打原因是第十七件大事或是某著名活佛领某奖，这不明）
当然想在搜索结果中翻页，还是不可能。

对于这个所谓“微软PlayFX音效”我一直觉得很奇怪。今天我上洋网一搜索，觉得越来越奇怪了。
首先，Microsoft.com首页上搜索，居然完全找不到任何关于此项技术的结果！难道这技术在中国国内公开称之为微软技术，在国外就是某某商业秘密云云了？为什么这个PlayFX，M$只license给rockchip这样异军突起的新SoC公司，而不放在自己的Zune上呢？

上英文Google搜索，前三页基本都是关于某种JWC（国内的所谓“京华”）MP4使用了此项技术的结果，还有一些不相干的用户名。到了第三页以后，铺天盖地的全是中文的和使用了此rockchip芯片相关的MP3的广告文和相关评测，没有找到提到这种技术的真正细节的文章。把搜索范围限制在英文网页，搜索结果少了大概95%，而且越往后翻页结果越不相关，基本上找不到什么关于音效增强技术的搜索结果。



难道rockchip和M$有某种秘密关系？总之我搞不懂微软为什么只给rockchip这种技术。又或是这纯粹是rockchip拉着微软大旗、Vista来吸引眼球？那可就没人知道了。

10月23日，下午4点。
C:\mplayer>tracert yksoft1.blogspot.com

Tracing route to blogspot.l.google.com [72.14.207.191]
over a maximum of 30 hops:

1 12 ms 19 ms 16 ms *.*.*.*
2 1 ms 1 ms 1 ms 10.0.0.5
3 * * * Request timed out.
4 5 1 ms 1 ms 1 ms 222.247.29.109
6 1 ms 1 ms 1 ms 61.187.255.25
7 1 ms 1 ms 1 ms 61.137.0.53
8 * 6 ms 6 ms 202.97.42.209
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 ^C
看来好日子不会长久。某大会结束后，上代势力仍然很强大，当然在这个和谐大国不管什么势力在台上，都没法把这堵7年（从geocities开始是9年）的墙给自己拆毁。民轮组织，还有能够发出不同声音的地方，想上者自然能上，但总会有障碍。 C:\mplayer>

为了搞清楚是什么程序或者服务造成这个问题，我打开了我的两个工具：IceSword和ProcessMonitor（这两个经常手工杀毒的肯定至少用过）。

先开IceSword，选中监视进线程创建，运行那个问题安装包。很快我就发现，有一个svchost进程和一个叫consent.exe的进程异常活跃。

 

(注意其中那个lsm.exe不是特殊程序而是相当于XP/2003的winlogon.exe和部分lsass功能的程序)。

consent.exe是在复制文件一段时间后才真正运行的。如果在它出现到UAC窗口出现之间的一段时间把这个进程结束掉，什么错误都不会发生，而那个临时文件已经消失了。为了继续调查，我设置了几下ProcessExplorer的规则。

证明那个服务在疯狂读取原文件并复制到%windir%\temp下，consent只是读那个临时文件而已。知道了那个svchost.exe的pid，也就容易弄清楚那个服务到底是何方神圣了。很快就通过IceSword查找到这个svchost的模块里有mmcss.dll(那个造成放声音减网速的MMCSS服务)，BITS.dll(Windows Update的那个背景传输服务)等等东西，看上去都是属于那netsvcs组。进一步查看，反复尝试对这个组的各服务进行操作，发现有一个怎么也结束不掉(无响应)的服务──AppInfo。这是这个服务的说明:

辅助管理权限?和UAC的功能一样!难道是它?因为这个服务结束不掉(不管是用MMC，用net stop还是sc stop都无响应)，只好先将其设置为禁用，再结束掉它的母svchost.exe。

再次运行那个安装包，结果……

果然。现在这个服务无法启动，任何要求UAC提升权限的东西都无法启动了，那个临时文件也根本没有被创建。但是为什么要求吞食硬盘空间的却是这个作为UAC功能之核心的服务呢?

我可以粗略分析出UAC对于一个安装包/自解压EXE文件是如何工作的:

(1)Win32 API Winexec函数运行该程序

(2)检测安装包的文件名和属性中的信息，发现一些特征如关键词"setup""install"一类或者在应用程序兼容性数据库(我目前发现它存在在%windir%\apppatch下的三个.sdb文件中)发现相关项或者在应用程序的内嵌/外挂manifest中发现特殊要求(如icesword.exe)

(3)Appinfo服务复制这个文件到%windir%\temp下

(4)consent程序检验这个临时文件的数字签名等信息，负责弹出UAC确认窗口

(5)如果选允许，consent以自身的高权限运行原.exe文件并退出

(6)appinfo服务检测到consent退出，删除临时文件

用伪代码可以这么描述

WinExec(string filename)   /*这里的filename指完整路径名*/

{

bool issecure;

issecure=SecCheck(filename));

if(!issecure)

{

UAC(filename);

return 0;

}                  /*(2)*/

execFile(filename);

}

UAC(string filename)

{

string tempfilename;

string consentline="consent.exe -v origfile= ";

strcat(tempfilename, Getenvironmentstrings("Windir"));

strcat(tempfilename, "\Temp");

strcat(tempfilename, tempNamegenerate(GetNamefromFullpath(filename)));/*生成临时文件的完整路径名*/

Copyfile(filename, tempfilename); /*(3)*/

strcat(consentline, filename);

strcat(consentline, " tempfile= ");

strcat(consentline, tempfilename);

execFile(consentline, suspendwhenrunning); /*(4)(5)*/

deleteFile(tempfilename);/*(6)*/

}

我发现这个问题，就是发生在第二步。第二步失败后并没有跳到第6步。微软要做个权宜之计的修正，只需要把

Copyfile(filename, tempfilename); 这里改成if(!Copyfile(filename, tempfilename)){deleteFile(tempfilename);return 0;}就没问题了；不过为什么一定要复制文件到系统目录呢?

你有见过验证一个可执行文件的数字签名还需要把这个文件拷到系统盘的临时目录的OS吗？开了UAC的Windows Vista就是一个！

今天试图在Vista下运行一个500多M的大安装包，结果系统盘（F区）空间只有300多M。结果，运行了之后硬盘响了半天，愣是没看到那可爱又可恨的UAC提示，反而出来个对话框说“磁盘空间不足”。结果一看，F区没空间了。Windows Explorer自己的“磁盘清理”功能一弄，系统日志一清，各浏览器缓存一清，只清空出大概200兆空间。到处找了半天，找到了F:\Windows\temp——所谓“全局”临时目录下躺着个300多兆的临时文件。winhex打开一对比，结果此文件就是那个安装包的截断版本。

我做了个小实验。把F盘再腾出几百兆空间，再次运行那个安装程序。

硬盘又一阵稀里哗啦的狂响。20秒后，在UAC窗口闪烁在任务栏的时候，怪物也出现在了temp目录中：

切换到UAC窗口，随手点“取消”。这时候这个临时文件也突然消失了。再试了个别的安装程序（日文WPS2007 Beta安装包），结果也差不多，文件还是被复制到了F:\windows\temp下。

那如果系统盘的空间不足会怎样呢？再测试一下。。

结果。硬盘空间一下就被吃光，出现了那个“磁盘空间不足”的窗口。

具有讽刺意义的是，这个被截断的临时文件，默认还是TrustedInstaller组权限下的东西，你想删掉它，还要再过一次UAC。

这可以算是Vista的一个严重BUG了。验证数字签名，有必要放到自己的领地里来吗？当磁盘空间不足的时候，也没有进行任何的防护措施，最后出错后那临时文件也摆在那里了。

10月19日 约20:00
突然发现这一晚我的Space连接超时了。起初怀疑被墙，但是使用某些国外代理软件，很多Space都仍然无法访问。我的是其一，20分钟前就算是Windows Live Writer等微软官方Space也都无法访问。我估计要么Spaces服务受到强大攻击（可能性看上去不大），或者是部分服务器处于下线状态。我使用Mobile Spaces能够正常访问我的空间和大部分无法通过主站访问的空间，但有些还是出现了“Service Unavailable”提示。
到21:00，基本上使用代理软件的访问恢复正常。
Downtime怎么选在这个时候？或是某大事的影响到了国外？不得而知了。

C:\Documents and Settings\yksoft1>tracert www.youtube.com
Tracing route to www.youtube.com [208.65.153.251]
over a maximum of 30 hops:

1 1 ms 3 ms 1 ms *.*.*.*
2 1 ms 1 ms 1 ms 10.0.0.5
3 * * * Request timed out.
4 5 1 ms 1 ms 1 ms 222.247.29.109
6 7 3 ms 3 ms 3 ms 61.137.0.133
8 10 ms 10 ms 10 ms 202.97.40.49
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * ^C

当你看到第8步之后，你会认为什么呢？
202.97.40.49是在主干网上。。
只有一个原因，就是Youtube被第一层盾了。

使用另一个DNS的结果
D:\Users\Administrator>tracert www.youtube.com

通过最多 30 个跃点跟踪
到 www.youtube.com [208.65.153.253] 的路由:

1 2 ms 2 ms 2 ms *.*.*.*
2 1 ms 2 ms 2 ms 10.0.0.5
3 * * * 请求超时。
4 5 1 ms 2 ms 2 ms 222.247.29.69
6 1 ms 1 ms 1 ms 61.187.255.69
7 4 ms 4 ms 4 ms 61.137.0.229
8 11 ms 11 ms 11 ms 202.97.40.253
9 * * * 请求超时。
10 * * * 请求超时。
11 * * * 请求超时。
12 * * * 请求超时。
13 * * * 请求超时。
14 * * * 请求超时。
15 ^C
D:\Users\Administrator>

其他两个地方的结果：
Tracing route to www.youtube.com [208.65.153.251]
over a maximum of 30 hops:
1 * * * Request timed out.
2 41 ms 46 ms 31 ms 218.68.252.97
3 46 ms 46 ms 46 ms 218.68.251.161
4 42 ms 46 ms 46 ms 202.99.66.153
5 46 ms 46 ms 42 ms 219.158.5.90
6 41 ms 46 ms 46 ms 219.158.4.189
7 78 ms 73 ms 73 ms 219.158.4.190
8 219.158.3.222 reports: Destination host unreachable.
Trace complete.
Tracing route to www.youtube.com [208.65.153.253]
over a maximum of 30 hops:
1 <1 ms <1 ms 1 ms 219.239.202.1
2 6 ms 6 ms 5 ms 219.238.109.254
3 1 ms 1 ms <1 ms 219.239.249.17
4 * 1 ms 1 ms 202.99.57.49
5 5 ms 6 ms 6 ms 221.239.18.133
6 4 ms 3 ms 4 ms 221.239.7.49
7 4 ms * 4 ms 221.238.222.213
8 202.97.34.229 reports: Destination host unreachable.
Trace complete.

1     *        *        *     Request timed out.
2    <1 ms    <1 ms    <1 ms  59.151.56.225
3   114 ms    69 ms    65 ms  59.151.58.77
4    16 ms    18 ms    29 ms  59.151.58.5
5    56 ms    76 ms    61 ms  211.151.224.75
6    18 ms    13 ms    22 ms  211.151.224.17
7    13 ms     4 ms     5 ms  219.142.8.25
8    39 ms    25 ms    18 ms  bj141-130-113.bjtelecom.net [219.141.130.113]
9    62 ms    61 ms    48 ms  202.97.37.26
10    40 ms    32 ms    39 ms  218.105.4.158
11     *        *        *     Request timed out.
12     *        *        *     Request timed out.
13     *        *        *     Request timed out.
14     *        *        *     Request timed out.
15     *        *        *     Request timed out.
16     *        *        *     Request timed out.
17     *        *        *     Request timed out.
18     *        *        *     Request timed out.
19     *        *        *     Request timed out.
20     *        *        *     Request timed out.
21

为什么国外网站一出中文版，就如此多灾多难呢？难道是blogger的暂时解除换来的是youtube的Orz呢？明年狗林匹克的时候大量洋人要来，youtube估计他们有天大胆子都不敢继续盾。

 
Update 10.18 12:53: http://www.google.com/search?hl=en&q=www.youtube.com&btnG=Google+Search
哈哈。不仅是第一层，还是第二层。可惜我还不是最快的~

看来，微软的人目前还在拼命debug、修改Firefox版和其他浏览器版的模版和脚本。不过IE版却很缓和地更新过来了（我的IE6、IE7这几天上Space没出现过任何错误。IE优先没问题，不过让别的浏览器用户等上好几天，那还是有点过不去。

http://hi.baidu.com
据说从10月4日开始，腾讯QQ和TM中，带有这个URL的地址无法被发送出去。
绝大多数人都认为这是腾讯的反竞争手段，意图以此打击百度空间（据说还包括网易博客）。据我10月10日测试，这种情况已经不存在（至少在我使用的 QQ2007Beta1 "K"版和TM2007Beta1中）。其实我认为这并不是什么反竞争手段，而只是最近这两个国内大型blog空间被发现XSS漏洞导致有人在其上挂马并在QQ中发送带马地址，导致大量用户投诉，整个域名均被腾讯所谓的“安全”系统所屏蔽。屏蔽“2的6次方”、“Wheelgong”相关的关键词，屏蔽一些常见的挂马站地址，当然无可厚非，不过这次也许只是腾讯的安全部门忙中出错，把事情搞大了。
另外，似乎Windows Live Spaces的代码在Mozilla1.8.0下又出错了。发不出文章。唉。

我打开SeaMonkey 2.0a1，哈哈，编辑器没了~但是文章总算能发出去了。
打开Firefox 2.0（Mozilla 1.8.1）没问题。难道M$真这么懒惰？
M$啊M$。你只认Firefox，不认Gecko（什么SeaMonkey、Camino、K-Meleon，Spaces都会以那套默认framework代码输出（还有为IE和Firefox特别准备的两套），该当何罪？

由于国内关于QuickTime的资料很少，我直到最近才发现QuickTime的这个功能。但是实际运用状况却非常不理想。
使用的具体方法很简单（Windows下）：把.sf2格式的音色库复制到Program Files\Quicktime\QTSystem（版本7）或者Windows\System32\QTSystem（版本3-版本6）。(Mac下复制到Library/Audio/Sounds/Banks下）然后打开QuickTime偏好设置，在“音乐合成器”中就应该能看到音色库的名称。选中它，就能够加载此音色库用于Quicktime合成器。

但是据我的测试，我发现实用性不高。最初的问题是这个合成器实在太老、自身性能就很低（发音数、效果）；而且它只能真正支持全部GM音色的音色库，GS的音色库根本不能完善的支持，甚至会导致很多GM音色出现问题；效率不高，70多兆的库就能让它在Core Duo T2300下不能正常实时合成；新版本的sf2格式完全不支持；当然还有Quicktime Windows多年改不了的Player硬编码为22KHz输出的毛病，只能导出或者用iTunes来听。
当然，QuickTime至少是可以免费合法使用的东西。不要对它要求很高

当初我在RC2时就测试了Roland Virtual SoundCanvas 3.23这个著名但古老的软波表软件，但是当时它安装后无法正常运行。而且我在Vista系统中也有一点重要发现，那就是在声音控制面板中找不到和MIDI有关的任何选项！难道微软认为他们从Win3.1时代就支持的MCI MIDI已经彻底过时？所有用MIDI的人都去用支持DXi、VSTi的软件了？至于Windows自己的那个GS合成器，音色库win98SE开始就万年不变，不能完整支持GM和SC-88的扩展，很多老MIDI的游戏都会出现或大或小的问题。
不过看了这篇文章http://www.pp-express.info/Vista_MIDI/vista_midi.htm之后，我真是茅塞顿开。原来在Vista上安装调试VSC竟然是这么简单！因为很多人不懂日文，我把其中的步骤简单解释一下。
当然，最基本的要求是你不能使用64位OS！

1、关闭UAC（不用解释怎么关闭了吧），将VSC（需要是版本3.2以上）的安装程序设置为Windows XP SP2兼容模式（这点也不用解释了吧。。）
2、运行安装程序，在选择安装目录时，千万不要选择默认目录（这可能是整个问题的最大根源！），应该将其安装在一个User组就具有完全读写权限的目录中。
3、重新启动系统。如果没有出现错误窗口，任务栏中出现VSC图标，安装就是正常的。双击VSC图标，随意用自带播放器播放几个MIDI文件，进入控制面板对VSC进行设置，设备建议不使用DirectSound（使用DirectSound会有很大的延迟），第一个选项卡的延迟设定尽量调小（能用Vista的机器把这个调低也没关系了）。
4、打开UAC，重新启动。如果此时启动后出现错误提示，那么前面肯定有步骤不对。如果正常，此时应该重新做第三步设置（UAC状态下，程序写入的注册表位置是虚拟化的）。
5、此时在可以自己选择MIDI输出的各应用程序中，VSC应该已经可以正常工作了。如果一直无法运行，甚至出现蓝屏、死机等严重错误现象，那么就可能是硬件驱动不兼容，这种情况没法解决（Sigmatel HD Audio集成声卡、AMD双核笔记本平台都可能与这个软波表不兼容）。
6、但是此时在使用系统默认MIDI输出的程序（如WMP、Falcom的游戏）中，系统仍然会调用系统自带MIDI。此时需要通过修改注册表来修改默认MIDI输出，但这样明显过于麻烦。有些人已经为解决这个问题专门写了控制面板小程序。我使用的是Putzlowitschs Vista MIDI-Mapper（来自http://putzlowitsch.de/2007/08/07/sichtwechsel/）。它可以在系统自带MIDI和VSC之间切换默认的MIDI输出。
这是最后的结果：

最后要提一点，无论如何设置，VSC for MCI是一个古董级的程序（2001年最后更新），所以我不保证它在现代的机器上的可用性。

首先庆祝一下本国国庆日。

今天我的一个空间（http://yksoft1.blogspot.com/）竟然可以直接连接通，而不是和以前一样连接超时。
在这个急需强大的和谐力量的时段（第十七件大事临近、离某和谐盛会只有11个月不到），怎么可能轻易打开城门放入这条怪兽呢？估计重新关门打狗、把它踢出墙外只是时间问题。

Update 10月2日上午11点：果然就和上次八一解封Wiki一样。放一天风。这就是网络为政策服务的突出表现。，