(Windows)想用iTunes 7.5？不想装新版本Quicktime？这样就行。

在苹果官方论坛上，许多人都发现了Quicktime 7.2及以上版本在部分nVidia 8系列显示卡的新版驱动下存在严重兼容问题（Quicktime播放器花屏甚至直接出现缓冲区溢出而出错退出）、对某些主板的SATA RAID的兼容问题等严重问题。想用iPhone？想用新一代iPod系列？必须用iTunes7.4以上。但是用7.4，一般的安装方式都会自动安装上 QT7.2，导致不兼容的系统配置下当场出现兼容性问题（如iTunes打开之后自动关闭甚至导致蓝屏等等）。今天iTunes 7.5出来，qt升级到了7.3，但是据我从苹果官方论坛找到的一些报告来看（如http: //discussions.apple.com/thread.jspa?threadID=1221598&tstart=0、http: //discussions.apple.com/thread.jspa?threadID=1222039&tstart=0、），这个新版本并不是十分完美，仍然在很多系统配置下出现了严重问题。
我虽然没有任何新一代iPod和iPhone，但也想先试试这个新版本的iTunes。为了测试，我在下完7.5安装程序这个50多兆的怪物之后，准备做点小小的tweak。
我原使用的iTunes 是版本7.2，Quicktime版本是7.1.6。从http: //www.apple.com/support/downloads/quicktime716forwindows.html下载Quicktime 7.1.6的独立安装包，用WinRAR解压缩出其中的Quicktime.MSI，备用。
运行iTunes安装程序，直到出现第一个画面。此时，在资源管理器中进入当前用户的临时目录（可直接输入%temp%进入），找到一个形式如 ixp000.tmp的目录（iTunes安装包为Windows Installer的IExpress自解压包，%temp%\ixpxxx.tmp是其默认解压到的目录）。进入它，你就能看到 Quicktime.msi（Quicktime7.3）、iTunes.msi、Apple Mobile Device.msi（iPhone和iPod touch支持）、Apple software update.msi等几个MSI安装包。现在你应该想到了，把Quicktime.msi替换成刚才备用的那个7.1.6的，就能实现目的——装上 itunes 7.5 而不装Quicktime 7.3 的目的。（当然前提是你的老Quicktime已经是7.1.6，不然独立安装包和集成安装包之间的区别，我还不知道怎么对付呢。如果已经是7.1.6， Windows Installer根本不会继续运行7.1.6的安装脚本。）我这样测试，当然取得了成功。


其实iTunes因为是使用一种兼容型的Objective C编译器编译，因此体积确实偏大。但是可以通过移除一些不需要的语言资源来达到减小体积的目的。这些语言资源文件在C:\Program Files\iTunes\iTunes.Resources及几个类似形式的目录中，移除其中除en.lproj（英文）、zh-CN.lproj（简体中文）、ja.lproj（日本语）之外不用的语言即可。这样，几乎可以减少iTunes目录的一半体积（30多兆啊）。当然因为Windows Installer的那个自效验，原来Windows Installer建立的快捷方式就不要再用了，不然运行就会试图把这些语言文件修复回来。。
如果不需要支持iPhone或者iPod touch，也可以在“添加/删除程序”里把Apple Mobile Device删除（10多M），不会影响iTunes 7.5的正常运行和其它各种iPod的使用。你可以看到，我已经删除了。

对模拟器最强的挑战：PC98用 Windows 95

Windows 95是一个不属于PC98的年代的OS。但是后期的NEC确实让它能够运行在PC9821上。然而，让它在模拟器上运行仍然几乎是个不可能的任务。
我经过多次实验，在Anex86+Anexx21 v2.78上最终将其运行成功。
最初我安装后无法启动，将DIPSW2-8（GDC频率）设置为开（5MHz），进入安全模式后将显示模式修改为640*480*256色，重启后启动成功。


启动成功。因为Anex86的bug（扩展内存不能超过14M）整个系统的内存都过少，而且由于9821GDC模拟效率超低，并且Anex86的SASI控制器根本不被Windows95支持（只能使用MS-DOS兼容方式），导致整个系统运行速度很慢。

Windows Vista UAC的一处严重的愚蠢设计（之二）

为了搞清楚是什么程序或者服务造成这个问题，我打开了我的两个工具：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;}就没问题了；不过为什么一定要复制文件到系统目录呢?

Windows Vista UAC的一处严重的愚蠢设计

你有见过验证一个可执行文件的数字签名还需要把这个文件拷到系统盘的临时目录的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了。验证数字签名，有必要放到自己的领地里来吗？当磁盘空间不足的时候，也没有进行任何的防护措施，最后出错后那临时文件也摆在那里了。

Youtube，墙的新牺牲品

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>

1 * * * Request timed out.
2 <1>

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

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

在Windows Vista 系统使用软波表软件 VSC-88 v3.23的办法

当初我在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竟然是这么简单！因为很多人不懂日文，我把其中的步骤简单解释一下。

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

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

是blogger换服务器ISP了，还是已经进了城门了？

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

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


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

Update again 10月16日 下午5点半 第十七件大事正在进行中，城门似乎又打开了一点。可以直接访问这里。