不過自從進了utf8時代，screen就一直有兩行bind key的指令：
bind b encoding big5 utf8
bind u encoding utf8 utf8

老實說這樣不是很方便，因為其實開BBS或某些Big5程式，固定的動作就是要先c-a c, c-a b
當初希望說能bind一個key是可以直接create big5 or utf8 window，結果找不到這功能，也就不了了之了。

每天c-a b、c-a u這樣按啊按的，其實也很煩，不過想說沒辦法，就算了

結果今天在某地方突然討論起screenrc
嗯，好像可以在screenrc裡面就先開好幾個視窗，並設定它們各自的encoding
好像也不錯，不過我沒有習慣開著很多個screen視窗…不是很適合我

後來又有人說了，他不想要bind key

不想要bind key那就命令列啦
screen可以在screen窗中shell打screen [num]開一個新的窗到該編號
那其它的指令應該也行吧…看著看著就看到screen -X，可以用shell命令列直接執行screen的指令….

這麼好用怎麼以前沒發現啊…orz

所以我連ptt的指令就可以改成screen -X title ptt; screen -X encoding big5; ssh -l bbs ptt.cc
做成alias，既可以換title，又可以換encoding，又連上了，也不會限定在幾號視窗

果然…人是有盲點的orzorz

RDS的raw data throughput為1187.5bit/s，一個封包是104bit/s，一秒鐘大約可以傳11.4個封包。一個封包扣除checksum後的有效資料是64bit，而扣除header之後的payload為32~40bits。這樣有多快？換算成一般的單位就是0.0456KB/s。

這麼慢的傳輸，可以做什麼呢？可以做的事很多，RDS定義了0A/0B一直到15A/15B共32種不同的應用。我們只挑幾個比較常見(其實是我只玩過這幾個)的來介紹：
PS(Program Service): 電台名稱，一共八個字元
AF(Alternative frequency): 替換頻率，在長途移動的時候可以自動幫你跳頻
RT(Radiotext): 電報訊息，最多可以到64個字元，一般會用來顯示目前的音樂名稱
CT(Clock-time and date): 包含日期、時間、時區，每分鐘發送一次。精度在+-0.1秒。
TMC(Traffic Message Channel): 即時路況
另外還有像ODA(Open Data Application)，基本上你愛怎麼定義裡面的東西都不會有人管你。

目前在台北可以收得到PS的電台有
1. 警廣 94.3 = RDSIOT12
2. 警廣104.9 = RDSIOT11(前幾個月104.9收不到，原因不明)
3. ICRT 100.7 = ICRT(前幾個月看，是FM100.7)
4. 漢聲 106.5 = V.H.B.N.
漢聲都一直很容易收到，而警廣次之，ICRT通常要等很久，有時候訊號不佳就根本收不到。

AF不曉得狀況，像94.3他就只有一個94.3而沒有第二個頻率可選，而且「聽說」台灣有些電台RDS會亂送，結果車用音響導致頻率亂跳。
RT目前沒看到有人用的，再來TMC方面，目前有兩個系統，一是警廣(Garmin有在用)，二是台北之音、ICRT、亞洲廣播網、雲嘉電台(Mio)，不過除了ICRT以外好像只有專心在送TMC。

最後要提的是CT(校時)，看起來只有漢聲有發。它的格式還滿特殊的，因為日期是Julian date，所以要用一串我根本看不懂的公式(註)去轉出來。再來會有UTC時刻和時區，就可以算出目前的時間。前兩天寫了手機上的FM校時程式(不必和我要，這個沒辦法通用所有的手機)。只要聽漢聲電台就會自動校正手機的時間，還滿好玩的:D

補充一下，五月份來到上海出差，發現上海這邊也收得到三台FM RDS電台資訊。有91.4(顯示SH91.4)、101.7(顯示101.7)、107.7(顯示SHANGHAI)。

根據測試，三個電台都有打開RDS校時的功能，不過和台灣漢聲的精準度(誤差在一秒以內)相比，只能算是聊勝於無，91.4/101.7和正確時間有二十秒左右的差異，而107.7的校時資訊則根本就是大錯特錯，比UTC+8快110分鐘左右，這…還不如不開對吧？

註：
Julian data的公式…我數學不好看嘸
//Convert Julian date to standard time
//EN50067:1998 Annex G
int Y, M, D, K;
Y = (int)(((double)jul_date - 15078.2)/365.25);
M = (int)(((jul_date - 14956.1)-(int)(Y*365.25))/30.6001);
D = jul_date - 14956 - (int)(Y*365.25) - (int)(M * 30.6001);
if ((M == 14)||(M == 15)) K=1; else K=0;
Y = Y + K + 1900;
M = M - 1 - (K*12);

因為以前的歷史，本來它是沒什麼期待的，不過憑序號從網下載、安裝之後，發現其實它比我想得好多了。我自己也是軟體工程師，從安裝程式開始，到輸入法選項裡面，許許多多過去我一直很想要的功能，就可以看得出來這並不是只把它改成win7可以用而已，而是有花心思下去做的東西。

另外因為本身從事Windows Mobile手機設計的關係，買Windows版就送一個WM版輸入法，可以說非常貼心，在手機上面使用也覺得還算滿順暢的(和注音比…XD)。

沒什麼好挑的，雖然設定完成之後其實你就忘記這套軟體了。不過好用的軟體就是你每天都會自然而然地用它，而不會有強烈的存在感。WinRAR是這樣、HyperSnapDX是這樣，嘸蝦米輸入法7.0也是這樣。

目前嘸蝦米還有提供線上購買版本，我是希望有用到的人可以支持一下購買正版或更新舊版，讓行易公司可以撐久一點，這樣我們才有後續版本的嘸蝦米輸入法可以使用。

這問題Assign到我身上，由於這並不是我的project，對MFC程式不熟，更別提PE，摸不清楚頭緒的情形下，花了一整個星期的時間才找到問題所在。

一開始先花一天porting到VS 2005環境，結果是徒勞無功，後來在PE 2.0上用windbg trace，發現是DLL not found的問題，只是因為PE 2.0可能缺某些元件，所以不會跳出錯誤訊息。如此一來也就不容易曉得是什麼dll找不到。

由於對Windows Loader/dependency這方面並不了解，就猜想是程式用到的dll/library有問題，然後一個一個拔掉，拔光了發現沒作用，後來才曉得可以使用Visual Studio中的dumpbin /dependents來觀看一個程式需要哪些dll library，再比對PE 2.0中有哪些檔案，終於抓到是缺oledlg.dll這個dll。

但是程式本身並沒有用到oledlg.lib，於是用了一些方法找到，是MFC會去使用它(dynamic link MFC的話不會有問題，但是要求是一定要static link)。

當場就想說頭大了，如果是MFC要用到的，我該怎麼解決？oledlg.lib是default library，而且除了PE 2.0之外所有版本Windows都有內含，說不定根本無法除掉它的dependency。(而且對我們IHV而言，是不能要求客戶去改他們的PE Image，也不能在程式中亂附Microsoft的元件。)

不過測試過我自己寫的其它小程式，卻又可以執行，所以可能是MFC裡面某個特定功能才會導致。

後來就開了MFC source想要直接看使用oledlg的那點，但是程式執行時並不會hit breakpoint那一點。

無奈之下只好花時間把程式一塊一塊慢慢砍掉，砍到最後剩一點點皮，才發現原來是ActiveX control的關係。實際上程式本身並沒有用到ActiveX，但是因為Wizard預設會去init它，所以就還是會link到。

結論而言就是把AfxEnableControlContainer();砍掉即可，就這麼簡單一行，但是不懂就很難找。而且還好只有這一個地方用到，要是有好幾個地方用到，就得整個程序重來好幾遍了…orz。

這應該是滿容易遇到的問題，但是可能懂的人覺得簡單就都沒人記吧，都搜尋不到，這邊記下來說不定之後就幫到人了…

所以我們也常常array == &array[0]，array+2 == &array[2]這樣換著用。但是上次朋友拿了一份看起來覺得有問題的程式碼。他是&array和&array[i]這樣混著用。

&array直覺會覺得這不是變成指標的指標？但是實際上程式是ok的。於是拿Visual C++實際寫sample trace看看，發現int array[]的話，array和&array的值是會一樣的。也就是說這是array和pointer不同的一個重大特性。問了認識的人很少人知道，可能沒真正K過C spec的人也很少會曉得。

不過這種寫法(&array)在The C Programming Language並沒有提到，K&R也只用’array’。說實在這種東西有趣歸有趣，還滿令人困擾的，所以還是別用吧。