我們某些系統是使用古老的 Delphi3 開發的, 所以.... 不支援 unicode 也是正常的. 就算在資料庫中加上了 nchar/nvarchar 的欄位, 還是無法正常的顯示 (其實連存取都有點麻煩, 因為 BDE 不支援 unicode, 要動些手腳才可以). (閱讀全文)

這是一個以 EzBuilder 為範本改寫的軟體. 主要是為了支援 unicode 的檔案名稱. (閱讀全文)

原本有些小程式是使用 php 寫的 script 來跑, 不過... 由於 php 一直沒有支援 unicode (Windows wide string, 官方是說要等 PHP 6, 不過看起來不知道還要多久), 在處理 unicode 的檔案名稱時就會有問題, 所以... 還是需要自己寫些小程式來處理. (閱讀全文)

最近因為有些程式所在的環境, 對外連線有些麻煩, 所以... 就想加上 proxy 的支援, 而目前最常用的 proxy, 大概就是 SOCKS5 或 HTTP Proxy 了.

一般 php 的程式, 對於 socket 的處理, 通常都是使用 fsockopen() 來處理. 而上頭兩類的 proxy, 都是在一開始連線時, 處理一些 handshake 的動作之後, 就不用再做任何處理了, 後續的動作與你直接連線都一樣. 所以... 我們只要寫一個 function, 用來取代 fsockopen(), 就可以簡單的加上 proxy 的支援了. (閱讀全文)

由於在 msys 中碰到的 make freeze 問題, 所以就將開發的環境由 msys 轉到 cygwin 來使用了. (閱讀全文)

最近因為要更新所用的 TDM64-GCC 中的 mingw64-runtime-crt (有些 function 在最近的版本才有), 結果, 玩著玩著就自己 build 起 mingw64 用的 gcc 4.7.2 來了 (這中間也有些心得, 有空再說) .

結果, 在 build gcc 的過程 (使用 MSYS 環境), 使用 make -jN 來加速編譯的速度時, 發現常常跑到一半, make 就停住了 (不過仍佔用不少 CPU 時間), 每次都要 kill 之後再重跑. (閱讀全文)

最近開始用 C# 寫 .Net 的程式, 發現就寫程式的方便性來說, 比起直接用 C/C++ 寫要方便許多. 所以... 原本有些為了方便, 使用 php 來寫的 script, 也都順便改用 C# 來寫. (閱讀全文)

新版的 Delphi 應該不用這麼麻煩, 據說只要直接在 AnsiString, WideString, UTF8String 之間 assign 時就會自動幫你做轉換 (沒用過, 不知道是不是真的這樣就可以).

不過... 還在用 Delphi 3/5, 所以... 只好自己來轉:

unit util_utf8;
 
interface
 
uses Windows;
 
type
  UTF8String = AnsiString;
 
  function AnsiToWide(const S: AnsiString): WideString;
  function WideToUTF8(const WS: WideString): UTF8String;
  function AnsiToUTF8(const S: AnsiString): UTF8String;
  function UTF8ToWide(const US: UTF8String): WideString;
  function WideToAnsi(const WS: WideString): AnsiString;
  function UTF8ToAnsi(const S: UTF8String): AnsiString;
 
implementation
 
function AnsiToWide(const S: AnsiString): WideString;
var len: integer;
    ws: WideString;
begin
Result:='';
if (Length(S) = 0) then
  exit;
len:=MultiByteToWideChar(CP_ACP, 0, PChar(s), -1, nil, 0);
SetLength(ws, len);
MultiByteToWideChar(CP_ACP, 0, PChar(s), -1, PWideChar(ws), len);
Result:=ws;
end;
 
function WideToUTF8(const WS: WideString): UTF8String;
var len: integer;
    us: UTF8String;
begin
Result:='';
if (Length(WS) = 0) then
  exit;
len:=WideCharToMultiByte(CP_UTF8, 0, PWideChar(WS), -1, nil, 0, nil, nil);
SetLength(us, len);
WideCharToMultiByte(CP_UTF8, 0, PWideChar(WS), -1, PChar(us), len, nil, nil);
Result:=us;
end;
 
function AnsiToUTF8(const S: AnsiString): UTF8String;
begin
Result:=WideToUTF8(AnsiToWide(S));
end;
 
function UTF8ToWide(const US: UTF8String): WideString;
var len: integer;
    ws: WideString;
begin
Result:='';
if (Length(US) = 0) then
  exit;
len:=MultiByteToWideChar(CP_UTF8, 0, PChar(US), -1, nil, 0);
SetLength(ws, len);
MultiByteToWideChar(CP_UTF8, 0, PChar(US), -1, PWideChar(ws), len);
Result:=ws;
end;
 
function WideToAnsi(const WS: WideString): AnsiString;
var len: integer;
    s: AnsiString;
begin
Result:='';
if (Length(WS) = 0) then
  exit;
len:=WideCharToMultiByte(CP_ACP, 0, PWideChar(WS), -1, nil, 0, nil, nil);
SetLength(s, len);
WideCharToMultiByte(CP_ACP, 0, PWideChar(WS), -1, PChar(s), len, nil, nil);
Result:=s;
end;
 
function UTF8ToAnsi(const S: UTF8String): AnsiString;
begin
Result:=WideToAnsi(UTF8ToWide(S));
end;
 
end.

就是直接使用 win32 的 API 來處理.

PS. 舊的 VCL 只支援 Ansi, 所以... WideString 與 UTF8String (定義與 AnsiString 相同) 並沒有辦法正確的在 VCL 中顯示.

最近試著在 Delphi 中產生 QR-Code, 找到了 zint 這東西, 也找到有人針對 zint.dll 做的 Delphi  模組. 不過... 適用的 Delphi 版本是在 D10 之後, 我們用的 D3 與 D5 (沒錯了, 很老了) 都無法直接用. (閱讀全文)

看來以前沒有人用 phpmsnclass 這東西在 big-endian 的機器上頭.... 直到昨天有人問我他在登入時一直出現 911 的錯誤, 加了一些除錯訊息之後, 終於發現 pack() 的結果與在 x86/x64 上的結果不一樣. 造成 login 所需要的 BLOB 資料運算錯誤.

因為我只有 x86 的機器, 所以... 自然都用 little-endian 的方式來處理, 所以 pack() 傳入的參數是 'L' (依據 machine 來決定 unsigned long 的儲存方式)... 不過, 在 big-endian 結果就不同了.

所以我們應該在這地方使用 'V' (用 little-endian 的方式處理 unsigned long) 才處理, 這樣不管在 little-endian 或 big-endian 的機器都可以正常使用.

有需要的, 請自行到 Google code 去抓 r61 或之後的版本.

更新 phpmsnclass 版本為 1.11. (閱讀全文)

雖然 wget 的 source tarball 裡頭, 有包含 windows 的支援, 不過... 似乎不能正常的編譯. 所以做了一些修正, 讓 mingw32/mingw64 可以正常的編譯. (閱讀全文)

雖然 ftp client 這東西, 似乎沒什麼必要特地使用 64 位元的版本, 不過.... 還是弄了一個 FileZilla win64 的版本來試看看. (閱讀全文)

最近試著用 mingw64 (其實是用 TDM64-GCC) 來產生 win64 版本的 FileZilla, 不過.... 弄了兩三天, 雖然可以產生 filezilla.exe, 不過一執行就會出現 0x000007b 的錯誤.

用 google 找了一下, 發現這問題通常發生在 64 位元的執行檔, 少了某些 DLL 或使用到某些 32 位元的 DLL 所造成的.

不過.... 我用 Process Explorer 查看了一下所產生的 filezilla.exe 的執行狀態, 並沒有發現有用到 32 位元的 DLL, 且用 dumpbin 或 objdump 查看, 也沒有發現有少那些 DLL.

最後看到了這篇文章,  發現除了 DLL 外, 在 resource 的產生上頭, 也可能會有產生這類混用的情形. 果然在 filezilla 的 windows_manifest.xml 裡頭, 發現 processorArchitecture 是設成 x86, 所以產生的 resource 會是給 win32 使用的, 在製成 win64 的程式時, 一執行就會有 0x000007b 的錯誤.

把 processorArchitecture 改成 * 或 amd64 (建議用 * 就可以, 這樣可以 win32/win64 通用), 果然產生的檔案就可以正常的執行了.

更新 phpmsnclass 版本為 1.10. (閱讀全文)

前一陣子在製作 i8000 的 rom 時, 有利用 bsdiff 來產生比較小的 patch 檔案, 這樣子有些小差異的大檔案, 就可以用一個大檔案加上一些小小的 patch 檔案來取代. 可以節省不少空間.

不過後來幾次, 在 Windows 下執行 bsdiff 指令時, 常常跑一陣子後, 程式就結束, 並沒有產生任何 patch 的檔案, 也沒有任何的錯誤訊息. 在找不出原因時, 就試著把相關檔案丟到 linux 上去處理, 結果.... 試了好幾台機器, 都是一樣的結果. 後來終於在某一台主機上頭, 可以正常處理 (不過.... 似乎也看不出為什麼就這台可以, 其他的不行).

最近比較空閒, 就試著在 VC 裡頭用 debug mode 來跑, 最後好像有出現 stack overflow 的訊息. 看了一下 source code, 這程式是利用遞迴的方式來處理, 所以, 當檔案比較大的時候, 在某些情形下, 可以會造成遞迴次數過多, 而每次函數在呼叫時, 內部的變數是用 stack 來處理, 所以, 次數過多的確可能會造成 stack overflow.

VC 預設的 stack 大小為 1MB, 我們可以利用 /STACK 來指定所要的大小, 在這個程式上, 我設成 /STACK:1000000000 就可以處理我目前所有的檔案 (多數在 100-200MB).

S2U2 對於 SPB Weather 的支援只有到 1.x 的版本. 而 SPB 的討論區裡頭雖然有說到要支援 S2U2, 不過... 也不知道什麼時候才會支援. 所以... 我就動手寫了這個小程式來使用.

檔案放在 http://www.teatime.com.tw/~tommy/files/SPBW2S2U2.7z 　

首先... 你的 S2U2 必須在天氣插件那兒設定為 UserWeather, 然後執行 SPBW2S2U2.exe 就可以了. 你可以把 SPBW2S2U2.exe 放到 Windows\啟動 的目錄下, 每次開機自動執行就可以. 如果要離開程式, 只要再執行一次就可以.

程式只在 Samsung i8000 的 Windows Mobile 6.1 中測試過, 不保證不會有問題. 用的人自己小心吧, 本人對使用本程式造成的任何損失均不負責.

程式碼附在裡頭, 要修改的可以自行修改. 至於授權方式? 就當是 public domain 的東西吧, 本人放棄所有權利, 你高興怎麼用這程式或程式碼都可以. 

至於 SPBW2S2U2 的參數, 是放在 HKCU\Software\TeaTime\SPBW2S2U2 底下:

Debug (DWORD):
預設值為 0.
如果是非 0 的值, 會產生 \SPBW2S2U2_log.txt 的記錄檔, 以方便除錯.

UseCelsius (DWORD):
預設值為 1.
0 表示使用華氏, 非 0 表示使用攝氏.

DeleteCacheFile (DWORD):
預設值為 1.
非 0 的值會在讀取 SPB Weather 2 的 Cache 檔案後, 把該檔案刪除.

WaitAfterChanged (DWORD):
預設值為 10.
在偵測到 SPB Weather 2 的 Cache 目錄有更改時, 要暫停的秒數.

CheckInterval (DWORD):
預設值為 0.
如果你的 SPB Weather 2 並不會自動更新 (好像沒有執行時就不會自動更新?), 可以利用這個參數, 讓 SPBW2S2U2 自動透過 internet 去讀取資料來更新 (必須在已經有 internet 連線的情況下). SPBW2S2U2 會在這個設定的秒數之後, 檢查是否有網路連線, 然後去更新資料.

CheckConnectionTimeout (DWORD):
預設值為 5.
檢查是否有 internet 連線的秒數.

更新一下程式, 修正無法刪除自動抓取的暫存檔案所造成自動更新只有第一次有作用的問題.
之前有抓過的請自己重抓吧.

更新一下程式, 自動更新時, 強迫系統重新抓取檔案, 不要使用快取的資料.
之前有抓過的請自己重抓吧.

如果需要 .cab 的安裝檔, 可以到這兒抓: http://www.teatime.com.tw/~tommy/files/SPBW2S2U2.CAB

最近換了一隻 Windows Mobile 的手機, 發現來電鈴聲會延遲3秒才開始響起. 雖然網路上有找到一些文章, 只要去修改 HKCU\ControlPanel\Sounds\RingTone0\Script 的值, 把裡頭的 w3 移除就可以. 不過... 每次修改設定就必需要再修改一次. 所以... 就動手寫了這個小程式來處理.

檔案放在 http://www.teatime.com.tw/~tommy/files/RingDelayRemover.7z

只要把 RingDelayRemover.exe 放到 Windows\啟動 的目錄下, 每次開機自動執行就可以. 如果要離開程式, 只要再執行一次就可以.

這個程式只是用來監看上頭的 key 值, 如果有任何更改就會把 w3 (只要是 wN 都會移除) 移除, 就不用每次都要手動去改了.

程式只在 Samsung i8000 的 Windows Mobile 6.1 中測試過, 不保證不會有問題. 用的人自己小心吧, 本人對使用本程式造成的任何損失均不負責.

程式碼附在裡頭, 要修改的可以自行修改. 至於授權方式? 就當是 public domain 的東西吧, 本人放棄所有權利, 你高興怎麼用這程式或程式碼都可以.

似乎由 7/21 開始, MS 的 server 伺服有些更改, 在 MSNP15 的使用上, 並不會在 USR 指令登入之後送出 SBS 的指令, 這會造成 phpmsnclass 在登入後等待 SBS 的指令而無後續的動作.

所以目前把程式修改一下, 直接在 USR 回應後就處理後續的動作, 不再依靠 SBS 指令處理.

改了之後看起來是正常了. 有使用的朋友, 請更新到 r38 或之後的版本.

在之前有提過有人寫了一個 FPDF UTF-8 簡繁中文支援的方案 (作者不是我), 不過, 有使用者反應會造成 AliasNbPages 沒有作用. 剛剛 trace 了一下, 發現在 chinese-unicode.php 裡頭, 就直接把字串轉成 unicode 內碼的十六進位字串了, 所以後來原本的 FPDF 在轉換 AliasNbPages 這個變數時, 自然不會有任何的作用.

舉例來說, 一般內定的 AliasNbPages 是用 {nb} 這個字串, 會變成 007b006e0062007d 的內容, 而在原本的 FPDF 依然是找 {nb}, 自然不會轉換. 因此我們需要針對 chinese-unicode.php 來特別處理這個部份.

你可以在 chinese-unicode.php 的 function PDF_Unicode() 之後,  加上一個 function Uni_putpages() 如下:

function Uni_putpages()
{
    if(!empty($this->AliasNbPages)) {
        //Replace number of pages
 
        // find the pages alias already converted to hex string
        $search = '';
        $len = strlen($this->AliasNbPages);
        for ($i = 0; $i < $len; $i++)
            $search .= sprintf("%04x", ord($this->AliasNbPages[$i]));
 
        // replace the pages alias with page number (hex format)
        $replace = '';
        $total_pages = ''.$this->page.'';
        $len = strlen($total_pages);
        for ($i = 0; $i < $len; $i++)
            $replace .= sprintf("%04x", ord($total_pages[$i]));
 
        // replace it now
        for ($n = 1; $n <= $this->page; $n++)
            $this->pages[$n] = str_replace($search, $replace, $this->pages[$n]);
    }
}

然後在使用時, 在最後產生 PDF 之前, 記得呼叫這個 function, 如:

$pdf->Uni_putpages();
$pdf->Output();

這樣子應該就可以把頁數轉換出來了.

不過這樣子的處理, 並不保證那個轉換不會造成別的問題. 以內定的 {nb} 來說, 因為只是單純比對 007b006e0062007d 來轉換, 雖然機率不大, 還是有可能會轉錯的. 如果有碰到, 還想避免這個問題, 可以考慮弄個比較複雜的 alias 來使用吧.

更新 phpmsnclass 版本為 1.9. (閱讀全文)

在經過之前所提過的修正之後, 的確可以在 Excel 的欄位中正確的使用 unicode 了. 不過最近在 Study-Area 有人提到 Worksheet 的名稱與列印的 Header 與 Footer 都不能使用 unicode. 試了一下, 果然不能正確使用. (閱讀全文)

一般來說, 我們在使用 php 去檢查使用者的帳號密碼時, 都是直接用該組帳號密碼去執行 ldap_bind() 的動作, 如果成功的話, 表示密碼是對的, 如果失敗的話, 表示密碼是錯的. (唯一的例外是... 如果密碼是空字串, 也會成功, 所以用這個方法要先檢查密碼是不是空的) 如:

if ($password !== '' && ldap_bind($id, "uid=$user,dc=example,dc=com", $password))
    echo "password correct!\n";
else
    echo "wrong password!\n";

但是, 如果要修改密碼時, 又該如何呢? 我們可以用下面的方式:

if (ldap_mod_replace($id, "uid=$username,dc=example,dc=com", 
        array('userpassword' => "{MD5}".base64_encode(pack("H*",md5($newpass)))
    echo "succeded\n";
else
    echo "failed";

就是先用該使用者 (或有權限改密碼的帳號) bind 之後, 去更改 userpassword 這個屬性. 使用 md5 的方式去設定密碼.

在上一篇文章提到了一些在 Dialogic 上頭使用 ISDN 要注意的事項. 不過原本用來測試的平台是用 Windows, 最近系統要上線使用前, 為了方便起見, 我們還是決定轉到 Linux 上頭使用. (閱讀全文)

更新 phpmsnclass 版本為 1.8.  (閱讀全文)