freewrap55をTcl/Tk8.4.7でコンパイルしました。なおこのサイトはwikiに移行中なので、ダウンロードは下のURLからアクセスしてください。
freewrapで日本語
ソースを追いかけていて、コードがきれいになったという以外にあまり大きな変更点も無かったし、winicoが無くても全然問題無く使えているので、5.5ベースの今のままで別にいいじゃんという感じです。それにサイズが小さい方がいいので。期待してた人ごめんなさい。
サイズ縮小とか考えてモチベーションが下がってきたのですが、動くところまでは出来てますのでオリジナルの5.61のソースに対するパッチだけ出しておきます。
freewrap561src_jp.patch.zip
他のプログラムを書くのに夢中になってるあいだに出てたみたいです。しかし弱りましたなあ・・・。ナニが弱ったかというと、このバージョンから全てのエンコーディングが付くようになったそうで、400Kもサイズが増えていることですよ。どうしたもんでしょうか・・・。パスの問題はまだ残ってるみたいなので追いかけないといけませんが、サイズを減らすために日本語環境以外のエンコーディングを消すという方法はぶっちゃけどうなんでしょうか。
ちなみに変更点は、１全エンコーディング追加 ２WINICO復活 ３ZIPと融合 4暗号化できなくなった 5TCL/TK8.4.6でコンパイルてな感じです。ちなみのちなみですが、ソースをDLしてw2kでmakeしたらZIP関連でリンクエラーになるんですけど・・・。勘違いでした（汗）
8.4.6でコンパイルしました。それ以外で変更点はありません。
freewrapGUI_20040304.zip(2.8M)
プログラム
freewrapGUI_20040211.zip(2.8M)
ソース
freewrap_jp_20040211.zip(90K)
試行錯誤したコードの残骸とかそのままなんですけど・・・。いいよね・・・？今までソースを置いてなかったのは、こういうのを綺麗に整理したりコメントを（英語で）分かりやすく書いたり、変更箇所を明示したコメントを(英語で）書き直したりするのがとてもめんどくさいからだったんで、これで勘弁してください・・・。つーかmakefile汚すぎ。
freewrap_jp_src20040209.zip(90K)
いまさらなのですが、韓国の人からソースくれとコメントされてたのに気が付いたので、ソースを準備してます。気が付かなくて一週間放置してたので、呆れてしまってもう見てないかもしれませんが・・・。
freewrapはファイルをラップするのにzipを使ってるのですが、zip圧縮するときのパス名
zip -9 test.zip hogehoge/日本語/test.tcl
のように日本語名がパスに含まれていた時にアクセスできませんでした。というのは大抵の圧縮ツールはパス名をchar配列として受け取ったのをそのまま格納するので、shiftjis環境で圧縮された場合はshiftjisのまま、euc-jp環境で圧縮された場合はeuc-jpのままのパス名を保存しています。
こういう問題を今までデフォルトのエンコーディングをWindowsの日本語環境に合わせることで対応してきたのですが、ラップする環境と実行する環境が特定の同一環境でないといかんという所が気に食わないので少し変えました。今までfreewrapでやってたエンコード処理をOS（というかWIN32API）でするように変更したので今までcp932が必須だったのが、必須ではなくなりました。cp932でファイルを開いたり書いたりする場合には必要なので、今のとこデフォルトでラップしてますが、いずれ無くすかもしれません。ついでに他言語環境でも動くかも？環境が無いからよくわかりませんが・・・。
それからGUIを無駄にi18n化しました。英語が小学生レベルで恥ずかしい笑
freewrapGUI_20040205.zip(2.5M)
ファイルサイズがでかくなってますが、これはGUIじゃないfreewrapも添付することにしたためです。
freewrapで作った実行ファイルには幾つか欠点があります。ひとつはサイズがデカイと言う事で、もうひとつはアイコンを変えられないということです。プログラムの顔であり、作者の魂でもある（？）アイコンを変更できないのはアレである。というわけで、その欠点を補うべく改造をほどこしました。というよりmakeの処理の幾つかを切り出してるだけですが・・・。
アイコンとバージョン情報を変更できます。また、upxで圧縮できるオプションを付けました。圧縮すると、1.8Mくらいだった実行ファイルが0.8Mくらいになります。
あと、それにともなってパラメーターが増えて色々めんどくさいのでGUI化しました。
スクリーンショット
freewrapGUI_20040120.zip(1.7M)
ちゅーわけで、tclIOUtil.cを最新にしてコンパイルしたらとりあえず無問題でした。
freewrap_jp_20031217.lzh
スタックトレースを何度か繰り返しているうちに、Tcl_FSAccess内で扱うpathObjPtr->internalRep.otherValuePtrの先が異常な値に書き換えられているということがわかりました。それでFsPathのnormPathPtrにファイル名、cwdPtrにディレクトリ名が格納されているようで、このメモリを監視しとけばとりあえずバグを特定できそうです。
と、思ってたらつい先ほどsourcefogeからメールが・・・。ファイルシステムでメモリリークっぽいバグをモニターしていたからなんですが、[ 839519 ] last cwd objPtr not releasedうーん、やっぱりそうなのかな・・・と。
と再びsourcefogeを見ると次のバグが追加されていました。
Tcl 8.4.5 cores with freewrap, mktclapp
やっぱり当たってたのか。しかし同じタイミングで出てくるとは。もう少しfreewrapのコンパイルに取り組むのを遅くすればよかった・・・。時間が無駄になってしまった・・・。
できないっ！！ファイルの新規作成でメモリリークっぽいエラーがでるっ！！
・・・さっそく8.4.5でコンパイルしなおしてみたんですが、うまく動きません・・・。問題の個所は
if {[catch {open $dest w} fout]} {
・・・
}
という単純なもので、openすると$destのファイルが無いとか言われるか、何も言わないで落ちるかです。今回のパッチリリースでfile join コマンドに手が入ったので、その辺が問題なのでしょう。事実、$destはfile joinで作ってて、そこを別のコードで置き換えると問題が無いので、当たってると思います。ただwishで実行すると問題が無いので、freewrapのリンクの仕方か、コンパイラオプションに問題があるのか、それともやっぱりtclのバグなのかなんかだと思いますが（まだよくわからない）、しばらくバグを探してみようと思います。
sourceコマンドは常にISO8859-1エンコーディングを使ってファイルを読み込むので、Tclは半角文字 ( ユニコードにおいて00ページまでに位置する ) としてファイル内の各バイトを扱います。その結果 、Tcl文字列は予想される日本語の文字を認識するのではなく、その代りに本来の文字列の各バイトと対応するLatin-1文字の列として処理してしまいます。と書かれています。これはこちらの方が8.4.1のマニュアルを日本語訳されたものです。それから8.4.4のマニュアルでは常にISO8859-1が用いられるという部分が、常にcurrent system encodingを用いるという風に書き直されています。freewrapは8.4.1なんで、そのあたりが問題なのかよくわかりませんが、大体この辺が問題なのは間違いないです。最初はエンコードごとになんとかしようと思ってましたが、めんどくさくなってラップ時にリテラル表現に変換するようにしました。
