根據這篇 MSDN blog 的文章Optimization levels under Virtual PC, Virtual PC 預設是 User Mode (ring 3) 的 code 就直接以 CPU 來執行, 因此不需要指令集的模擬. 但是 kernel & driver 部分(ring 0)還是需要透過模擬. 而 User and kernel mode optimizations, 則是都透過虛擬化技巧完全由 CPU 執行. 因此在 Virtual PC for x86 上, 不管是前者或後者, 執行的速度都會比 PowerPC 快的原因, 畢竟 PowerPC 不能直接執行 x86 CISC 還是得透過模擬. 期待 native Virtual PC for Mac 在 Intel Core Duo 機器上, 執行速度也因為這個 migration 而加速許多.
但是 Virtual PC 慢的原因還有 Video 部分的原因, 畢竟用透過軟體模擬的畫面比不是直接硬體 IO, 況且模擬的顯示卡只有 S3 Trio. 因此經驗上在 x86 上裝 Virtual PC 跑 console linux, 用 gcc compile 跟 native OS 幾乎是 1:1 的速度, 而只要一跑 GUI, 而且是 32bit 模式, 畫面速度就會直直落.

Yahoo 拍賣上買的另外一隻新的 USB BT Adaptor，準備是給 windows 使用的，不過順便拿到 Mac OS X 上看看能不能使用。其實 Mac OS X 可以使用，但是不支援 Headset，可以連結到我的 SonyEricsson Z520i 沒問題。先前買給 iBook 用的是 SMC BT-10，這隻就可以使用 Headset。於是找一下差異在哪。99 元這隻的 USB BT Adaptor 是使用 SiliconWave 的晶片，SMC BT-10 是 Cambridge Silicon Radio 的晶片。把手機的 Headset 連線到電腦時，會看到 console 的 dmesg 有這些訊息：

[IOBluetoothSCOAudioDevice][start] 0×23d4c80 (IOService) [IOBluetoothSCOAudioDevice][initHardware] 0×23d4c80 [IOBluetoothSCOAudioDevice][createAudioEngine] [IOBluetoothSCOAudioEngine][init] [IOBluetoothSCOAudioEngine][initHardware] 0×1b41400 [IOBluetoothSCOAudioEngine][pauseAudioEngine] - numActiveClients = 0 - state = 0 - pendingPowerState = 1 [IOBluetoothSCOAudioEngine][createAudioStreams] sampleBuffer = 0xdd0c000 (0×3c00 bytes) [IOBluetoothSCOAudioEngine][initHardware] - done. [IOBluetoothSCOAudioEngine][init] [IOBluetoothSCOAudioEngine][initHardware] 0×1b41400 [IOBluetoothSCOAudioEngine][pauseAudioEngine] - numActiveClients = 0 - state = 0 - pendingPowerState = 1 [IOBluetoothSCOAudioEngine][createAudioStreams] sampleBuffer = 0xdd10000 (0×3c00 bytes) [IOBluetoothSCOAudioEngine][initHardware] - done. [IOBluetoothSCOAudioDevice][registerForDeviceNotification]

接著使用內建的 Bluetooth Explorer 把 Local Bluetooth Device Information 叫出來，Extended SCO 和 Transparent SCO 這兩個 Supported Hardware Features 都是黑色的字體。而 SiliconWave 的晶片，這兩個 Features 則都是灰色的，表示不支援。不過至於在 Windows 上是如何支援 headset，就不得而知。

完全符合自己預期的破解方式, 利用模擬的 BIOS 來載入 NT. 只是沒想到一點, 原來 Bochs 模擬器的 BIOS 和 VGA BIOS 就可以拿來改, 不需要自己寫模擬 real mode interrupts. Modern OS 都是 protected mode, 不論系統是 BIOS or EFI, OS 都是靠自己的 drivers 去驅動和使用硬體, 因此只要 OS kernel 和 drivers 能夠起來, BIOS 和 EFI 就都已經是過往雲煙. 除非是 windows 95/98/ME, 他的 dos box 還是真的 dos mode, 是利用 virtual 86 模式去跑, 故系統中還是會用到原本 real mode 的 bios interrupt services. 而 2000/XP/Vista 等等核心, console box 真的就是 console 而已, 不是 dos, 而 BIOS/EFI 大概只會在設定系統參數和作 boot loader 才使用吧. 另外比較奇怪的是 NT 開機的方式, 一定會在 C 的 primay partition 裝 NTLDR, 不論系統是裝在非 C 的其他空間, 還是會在 C 裝必要的東西, 而且還要透過傳統 MBR 的 bootloader 才能開機. 因此還得透過模擬 BIOS 去載入 MBR, MBR 去載入 NTLDR, NTLDR 才又從 real mode interrupt 去載入 kernel & drivers. 如果完全不用這個程序, 把 NTLDR 和相關 drivers (2000/XP 經由 Safe mode 可以看到 windows 載入哪些必要檔案後才進入啟動程序)直接就放在記憶體中開始執行, 應該就不用去模擬 BIOS, boot loader, 和 MBR 之後的 real mode 開機過程.

之前趁放假把 iTerm 的 patch 更新到 0.8.2，不過非常不幸的，原來 iTerm 網頁上的 source code tarball 沒有更新，還是舊的。忙了半天，結果等於白忙一場。這幾天趁有空把 iTerm 直接從 SourceForge 的 CVS server 直接 check out 出來改。陸陸續續把幾個需要 patch 的地方趁有空就補一下，目前應該沒有什麼問題吧，花點時間再試用看看。而且 iTerm 把一些 VT100Screen 的 data structure 做些小變動，還花了點時間在調整些微的 code。不過發現 XCode 還是在 2.1，之前抓的 XCode 2.2 沒有更新，現在還是要在重抓一次再來編譯 iTerm。
不過 Mac OS X 上的 FileMerge 算不錯用的工具，拿來比對 source code 和 merge 蠻方便的。這個工具算是從 NeXT 時代就有了，現在繼續沿用到 Mac OS X。當然在 Linux 上也有類似的東西，像是 meld，不過缺點就是要裝 python 和 gnome。Windows 上也有類似的東西，當然就是軟體與 $$ 的關係而已。
當然不可避免的，每個禮拜二就是該看 24 的時間。這禮拜一次播出兩集，本來蠻興奮的，至少少一次苦苦等待的感覺。不過看完之後卻是大大的落寞感，因為 CTU 被 comproised，Nerve gas 釋放到整棟大樓，除了幾個重要的人外，應該整個 CTU 都掛光了。這個都是討人厭的哈比人 Lynn 造成的，除了那一次在機場意外發現 Jack 的暗號用語外，其他時間都在拖油瓶。6:00pm~7:00pm 結尾就是 nerve gas 造成的大屠殺，最後連 Edgar 都來不及進入 sealed room，和 Chole 隔著玻璃對看，接著就倒下掛了，最後還給他來個 Slient Clock 紀念一下。畢竟 Edgar 也是大家看蠻久的角色，也是很重要的一員，竟然很出乎意料且遺憾地在這個時間點走了。
不過還是有點小 bugs，Nerve gas 是在約 6:43:09pm 的 clock tick 之後，搬上去通風口才被設定啟動，倒數 15 分鐘，不過到後來約 6:57:32pm 就散發出去了，有點太早的樣子。再來大家擠在完全 sealed room，毒氣進不來是沒錯，但是不少人擠在裡面會不會缺氧掛點。
ps: Wordpress.com Invitation 新增一枚，意者請 mail 。