VirtualBox、VMware Fusion、Parallels Desktop 三款虛擬機器對 USB 裝置支援的經驗

目前 Mac 上有三款虛擬機器軟體，開放原始碼（對很多人來說這只代表免費）的 VirtualBox，最早在 Mac 上推出的 Parallels Desktop，以及老牌的 VMware Fusion。

這三套各有優缺，VirtualBox 是免費的，但是我覺得在恢復系統的速度上有點慢，另外詭異的中文翻譯也讓人不舒服。Parallels Desktop 有不少絢麗的功能，恢復系統的速度也很快，但是對比於 VMware Fusion，感覺程式比較不穩定一些。VMware Fusion 功能比起 Parallels Desktop 稍微樸實些，但是硬碟檔可以跟 Windows、Linux 上的共用。

這三套基本上都有支援外接 USB 裝置，例如隨身碟、鍵盤、WebATM 讀卡機，對內建 iSight 的支援也都有了，不過我因為 case 需要，要接的 USB 裝置很罕見，所以今天把三套都試了一下。

我要接的 USB 裝置是 Agilent 的 GPIB 接頭，是工業用儀器的專屬連接界面，型號是 82357A。這個裝置在三個虛擬機器中都可以正常安裝驅動程式，但是後續的使用上還是有些差異。

• 在 VirtualBox 中，會在掃描連接的裝置時卡住，我用的 VirtualBox 版本是 3.0.4，下次用 3.0.6 試試看好了，但我想結果應該不會改變。
• Parallels Desktop 下則是在安裝驅動程式時系統會卡住，需要等待一段時間，但是一旦裝好 driver，使用上一切正常，連接儀器也都沒有問題。
• VMware Fusion 則是最順利的，安裝 driver 很快很正常，連接的儀器也都正常抓到使用。

總結來說，我想 VMware Fusion 對於 USB 的支援可能是比較完整的，不過應該很少人會像我一樣用到這種奇怪的裝置，所以假如你只是想要挑選一套虛擬機器來用，這篇文章寫的其實不用太列入考慮 :)

後記：其實 VMware Fusion 我用起來還是有個麻煩的地方，就是他共享資料夾的名稱中居然會擺個 .host 這樣的字串，讓我用 Dev-cpp 時沒辦法直接在共享資料夾中編譯程式，Parallels Desktop 與 VirtualBox 都沒有這問題。不過會在 Mac 上用虛擬機器跑 Windows，然後在 Windows 中用 Dev-cpp 開發工業用監測程式的人，應該沒有幾個吧...

Mac OSX 10.5 在偏好設定面板裡面的錯誤

講錯誤好像有點嚴重，但是卻是很礙眼的問題，請看下面兩張圖，有看到問題所在嗎？

單獨放兩張圖應該是看不出來的，但是看看下面這張截圖應該就很明顯了當切換電池/電源轉換器的頁面時，你會發現文字的位置有差異，看起來實在是相當的不舒服啊...

10.4 裡面並沒有這種情況，而目前 10.6 又推出在即，我想這個問題應該是不會修改了。

更改 Xcode 範本的 __MyCompanyName__ 這個變數

用 Xcode 產生的原始碼，都會在檔頭加入版權宣告，雖然作者名字會自己抓到，不過用了這麼久，一直沒找到在哪設定 __MyCompanyName__。

前兩天窮極無聊 Google 了一下，原來在 Xcode 裡面不能設定，要用終端機直接改 plist 設定值...

在終端機輸入以下指令：

defaults write com.apple.Xcode PBXCustomTemplateMacroDefinitions -dict ORGANIZATIONNAME "Your_Name_Here“

然後重開 Xcode 就可以了。

用 Objective-C 從二進位檔案（binary file）中讀入數值的 byte order 問題

要從二進位檔案中讀入數值，其中一個會遇到的問題就是 Little-endian 和 Big-endian，這和 CPU 的種類有關。Intel 系列的 x86 CPU 使用的是 Little-endian，而 PowerPC、ARM 等的 CPU 則是採用 Big-endian。endian 不同的問題，在以前 PPC 的時代算是相當重要，後來改用 Intel CPU 之後重要性就下降了許多，不過現在因為 iPhone 採用的 ARM 又是 Big-endian，所以這問題的重要性又大幅提升了，尤其許多新手設計師，之前可能根本沒碰過非 Intel 的平台，根本沒考慮過這問題，於是寫出來的程式就會讀到一堆詭異的數字。

首先我們要先界定 endian 的問題會影響到哪些資料型別。所謂 endian 不同，是因為高低位元在記憶體中表示的方式不同而造成的，Little-endian 將高位元放在記憶體位址較大的地方，Big-endian 則反之。舉例來說，0x00112233 這個 16 進位的數字，在 Little-endian 的機器上，在記憶體中呈現的是 33 22 11 00，而在 Big-endian 的機器上則呈現 00 11 22 33。因此，假如把在 Little-endian 機器上寫入的二進位檔拿給 Big-endian 的機器讀取，讀出來的數字就會出錯。

從這邊我們可以發現，要發生 endian 的問題，首先資料型別必須用超過 2 個 byte 來儲存才有可能，因此只用一個 byte 儲存的型別，例如 char，就沒有 endian 的問題。

至於 int、long 之類的整數型別，可以用 CFSwap[type][Big/Littile/Host]To[Big/Littile/Host] 系列函式來轉換。其中的 type 可能是 Int16、Int32 等等。使用方法如下：

int littleEndian = 1234;
int hostEndian = CFSwapInt16LittleToHost(littleEndian);

那麼 hostEndian 的變數值就是採用目前機器上的 endian 順序的 int。

不過浮點數就沒這麼輕鬆了。我們在前面的例子中還是用 int 來存放 littleEndian，因為就算 byte order 不對了，但它仍然是個 valid 的 integer，不過浮點數的每個 bit 有它不同的意義，因此一旦 byte order 解譯錯誤，它就可能變成 invalid float，導致程式直接當掉。

為了解決這個問題，Objective-C 中用了一個與 byte order 無關的資料結構來儲存這個資料，定義如下：

struct CFSwappedFloat32 {
uint32_t v;
};
typedef struct CFSwappedFloat32 CFSwappedFloat32;

可以看到，這個結構中就只有一個 data，uint32_t，Objective-C 就是用它來儲存這個 float 的資料（當然，此時系統並不會把它當成一個 float）。接下來的處理方式就是，將這個 uint32_t 裡面的 byte 頭尾互換位置，然後將這 32 個 bit（4 個 byte）轉化成 float。而這就是 CFConvertFloat32SwappedToHost 這個函式在作的事。整個的用法可以用以下的例子表示：

CFSwappedFloat32 littleFloat;
long buffer;
float hostFloat;

fread(&buffer, sizeof(long), 1, fp);
littleFloat.v = buffer;
hostFloat = CFConvertFloat32SwappedToHost(littleFloat);

當然，其中的 fread 可以用 memcpy、NSData 的 byte method 等等取代，只要把握住一個原則：「 CFSwappedFloat32 的內部是用 uint32_t 來儲存這個待轉換的 float」即可。

NSNumber 與 NSInteger

在 Mac OSX 10.5 中新增加了 NSInteger 這個東西，但是這下就會跟 NSNumber 搞混，到底要用哪個？

基本上，NSInteger（以及類似的 NSUInteger）是為了解決在 32-bit/64-bit CPU 架構下，int 長度不同的問題，它的定義如下：

#if __LP64__ || NS_BUILD_32_LIKE_64
typedef long NSInteger;
typedef unsigned long NSUInteger;
#else
typedef int NSInteger;
typedef unsigned int NSUInteger;
#endif

也就是說，NSInteger 只是用 typedef 包裝過的 int/long，它是個基本資料型別（data type）。

NSNumber 則是個不折不扣的 Objective-C 類別，因此這兩者的使用時機就很明顯了，當你要把 integer 放到 Obj-C 的集合，例如 NSArray/NSSet 時，請用 NSNumber，不然其他的時候用 NSInteger 就好了。

iPod Shuffle - Small talk

Apple 推出 iPod Shuffle 三代已經一段時間了，功能外觀不再贅述，雖然它的語音功能好像真的蠻好玩的，只是老是要聽人聲慢慢念，還是覺得有點麻煩。我比較感興趣的反倒是它的標語 "Small talk"。

看到 Small talk，實在沒辦法讓我不連想到那個程式語言 - Smalltalk。

Smalltalk 是世界上第二個物件導向程式語言，在 1970 年代就開發出來，後來也影響了眾多的語言，著名的包括 Java、Ruby 等，但是對 Mac 開發者來說，最重要的應該就是 Objective-C 了，而 Obj-C 也是唯一保留了 Smalltalk 那特殊的 [object method] 語法的語言。因此雖然我沒寫過 Smalltalk，但是聽到這個標語還是不禁會心一笑，這是我開始用 Apple 產品以來，第一次感受到 Apple 與工程師這麼接近的一次（或許這也只是 Apple 一次美麗的錯誤？）

不過台灣的網頁在第一次出現的時候，把標語定為 "輕小說"，結果在 OIKOS 上被圍剿，說 iPod 跟小說根本沒關係，牛頭不對馬嘴。過了幾天就看到台灣把標語換成與香港一樣的 "輕身細語"，老實說，這樣有比較好嗎？我反倒覺得輕小說三個字更有輕飄飄的感覺，而把 "輕" "小" "說" 三個字拆開來看，則更符合這次的功能特色，就翻譯上也比較貼近英文的標語 Small talk。"輕身細語" 光聽根本感受不到它的體積小，因為太容易與原來的成語 "輕聲細語" 直接聯想在一起。

只是，即使是 "輕小說"，還是沒辦法傳達那個隱藏的聯想，Objective-C 的老前輩，Smalltalk。

iPhone Simulator 在 PPC 平台上執行 OpenGL ES 的顏色怪異問題

最近在寫 iPhone 上的 OpenGL 程式，不過雖然 Xcode 中就有提供 OpenGL 的樣版，但是因為對 OpenGL 不熟，看得不是很懂。

雖然後來自己改了裡面的程式碼，也畫出了東西，但是在 Simulator 中執行時整個就是怪，首先是顏色全部跑掉了，一般設定顏色的順序是 RGBA，但是在 Simulator 中顏色的順序居然變成了 GRAB，所以畫出來的顏色整個就是怪。

這感覺就很像是 byte-order 採用 little-endien 和 big-endien 所造成的問題，後來 Google 了一下，果然也有人遇到一模一樣的問題，據他所說，其他的 CocoaTouch 部份都可以正常運作，就只有 OpenGL 的部份會出錯。

我想這個出錯的原因應該是因為 OpenGL ES 裡面不能用 glBegin()/glEnd()，然後個別指定 vertex 資訊的這種用法，必須把 vertex 和 normal、color 等資料存成陣列，用 glDrawArray()/glDrawElement() 的方式一次丟給顯示晶片處理，而應該是 simulator 把陣列丟給顯示晶片時造成的 byte-order 問題。目前確定顏色會出問題，不知道 normal 和 vertex 陣列會不會也跟著出問題...

而 iPhone SDK on PPC 是不被官方所支援的平台，我看這個 bug 的修復應該是遙遙無期了...

為何要支援 Mac 與 Linux？

今天看到一篇標題為 Why you should support Mac OS X and Linux?，真是一語道盡我對支援 Mac OS X 與 Linux 的看法，這些看法我之前也跟一些業主談過，但是卻沒有業主聽得進去，但是以後我就有 case 可以 support 我的看法了。

來看看 Lugaru 這個遊戲在各平台上的銷售比例：
你可以發現多支援 Mac OS X 和 Linux，你的銷售數字比單純支援 Windows 提升了大約 122%！這是多麼誇張的數字！各位業主，你們要提升銷售額 122% 要花多少心力？更重要的是，你的心力，講的更清楚些，你的錢！花下去了就確定能提升 122% 嗎？

我下面列出文章作者歸納出的五點原因，詳細內容就請自己去看吧。

1. It’s good to be a big fish in a small pond (寧為雞首，毋為牛後)
   
2. More platforms means more opportunities (更多的平台代表更多的機會)
   
3. Vocal minorities (少數發聲)
   
4. You can’t choose your evangelists (你無法選擇你的傳道者)
   
5. You can’t choose your power users (你無法選擇你的主力客戶)

我想這篇文章會是我以後跟業主談話時的一大佐證。