Java：サロゲート文字を考慮して1文字ずつ配列に格納したい

確かめずに、ソラで書いてるんだけど、

    String str = "𩸽が𩹉を𠮟る。";
    List<String> strList = str.codePoints()
                          .mapToObj(cp -> String.valueOf(Character.toChars(cp)))
                          .collect(Collections.toList());

こんな感じだっけ？

近況報告

仕事

バグを発見しても、資料を作り資料のレビューを、プログラムなんてしたことのない人に説明して、納得させられないと、資料の作り直し無限地獄で、いつまで経ってもバグの修正ができないイカれた世界から、残業のないシンプルなプログラマーだけをしていれば良い世界に転生したのは、去年の１月。
既に、１年が経っていますが、マジで残業をしたのはその間に１回のみ。
休日出勤って何？な世界で幸せに暮らしています。
あるんです、そんな世界。＼(^o^)／
自分が思っている以上に大切に扱ってくれるし。
職業プログラマーな世界に転職してから、今が一番幸せかも...。

私生活

主にフリーソフトプログラマだったのは、既に何年も過去になっちゃいましたね。
今は、読書かNetflixが私生活の自由時間を占めていますので、コンテンツを作る側から消費する側になっていまいました。
作るといえば、土日や祝日には料理を作って家族に貢献はしていますよ。
読書は、職場でのスマホの持ち込みができないので、紙の本となっていますので、学生時代からのSFな小説を再読したり、新しく買ったりと。
昔はSFな小説といえばハヤカワ(水色)だったのですが、今時は創元(ラベンダー)なんですね。 ラノベは紙の本で買うと物理的に(心理的にも)部屋に置けないので、電子書籍で買うことがほとんどです。色々割引で買えますしね。
仕事でJavaしかしていないので。Javaはフリーソフトを書くには不向きな言語だと思いますので。Java自体のノウハウは非常に貯まるので誰かに言いたいくらいではありますが、仕事先は、インターネットから隔離された世界です。守秘義務との摺合せも面倒ですし。あしからず。

マイカー

中古のザ・ビートルに乗り換えたのは、去年の夏からだから８ヶ月になります。何が良かったかと言えば、燃費ですね。まぁ、通勤に使っていないせいもありますが、２ヶ月に１回くらいしかガソリンを入れなくて良い。満タンから８００ｋｍくらい走れますし。
ニュービートルと一緒で、ドライブは楽しいしぃ〜みたいな。
休日にしか乗らないから、黄砂とかクモの巣に悩まされています。

通勤

先に書いたとおり、マイカー通勤ではなく電車でGoなので、通勤中にスマホで読書ができます。行きは学生が一緒で混むので、ヘッドホン(イヤホンと言うのか？)で音楽オンリーですが。
今はコロナの影響で学生が乗ってこなくなったので、比較的空いていて通勤が楽です。

コロナ

もともと出不精なので、精神上は何も影響がないが、職場でマスク必須だし、通勤が電車なのでマスクを絶対しておきたいが、使い捨てのマスクが手に入らないのが、苦痛と言えば苦痛になるのかしら。
職場でタオル生地のマスクが支給されたんだけど、これでコロナから身を守れるのかが微妙〜。でも、無いよりは...。通気が良すぎてメガネが曇らないのが良いところ。

そろそろ夕方の犬の散歩の時間だ。それでは、また。

こんにちは、ザ・ビートル

前車であるニュービートルと、新しくマイカーとなったザ・ビートルとを比べて、足りないところ、それは一輪挿し花瓶。
ニュービートルには、標準装備として一輪挿しがありましたが、ザ・ビートルには付いていません。
後付けの純正品らしきものも存在しているようですが、限定品であったらしく、今は欠品となっており入手は困難です。
代わりとなる一輪挿しを探しましたが、なかなか良いモノがなく...。

ニュービートルの一輪挿しを、ペンスタンドの代わりにして、ペンを挿している人が居る、という話を思い出し、だったら、一輪挿しではなく、ペンホルダーではどうだろうか？と探すこと数分。
ありました。

タブレット用スタイラスペンを、タブレットに貼り付けるタイプのケース。
早速、ザ・ビートルに取り付けてみました。
いい感じです。

さよなら、ニュービートル

2001年式のニュービートルに乗って18年。

最後のニュービートル乗りになるまでニュービートルに乗り続ける。

と言い続けていましたが、さすがに維持費が掛かりすぎることが理由で、手放すことにしました。
車内のプラスチック部品が壊れまくり、ドアの取っ手が破損しています。
ドアの取っ手を修理するには、ドアの内張全体を取り換える必要があり、片側20万円するそうです。両方だと40万円。
それ以外にも、運転席側のドアのロックが、時々開かなくなったりして不便なので、修理をすると6万円。
サスもヘタって、後ろから見るとネガティブ・キャンバーになっていて、タイヤの内側だけが減っており、このままだと車検を通らない。
バッテリーも弱っていて、車検時に交換するべき状態。
バッテリーを格納するケースもプラスチックゆえにボロボロ。
ヘッドライトのクリア部分も、飴色になっており、交換なら10万円～20万円コース。
ハッチバックのゴムパッキンもボロボロだし。
ボンネットの塗面の剥がれもひどく、全塗装も考えていたものの、古い車ゆえになかなか全塗装をしてくれる業者が見つからず。

あれ？これだけ車検までに必要なら、それだけでザ・ビートルの中古が買えるのでは？
近所の中古車屋さんで、ザ・ビートルの相場を見ると、前期型だと150万円程度。
そうだ！ザ・ビートルの中古に乗り換えよう。ザ・ビートルなら、トラブルがあったとしても、自動車税も、維持費もニュービートルよりも安いだろう？

そう考えたのはお盆前。
そして昨日、ブラックのザ・ビートルが納車されました！！＼(^o^)／
納車の前日には、乾式７速ＤＳＧのリコールが発表され、巷の乾式７速ＤＳＧはすぐ壊れて無茶金食い虫、という評判が故に中古車市場でＶＷ車が割と安かったのも頷けます。
リコール修理だから、今後ＤＳＧの件は安心だし。
乗った感じは、良いよ～！
ずっと前に試乗した１．２リッター７速ＤＳＧのゴルフと同じく、低速でサクサク変速していき、排気量のわりに野太い排気音をさせるし、振動少ないし、剛性あるし、見た目マッシブだし。


ガンダムで例えると、グフからゲルググに乗り換えたようなものでしょうか？
連邦と後１０年は戦えそうです。

『もはやマイナーブラウザの域に？ Firefoxのシェアがついに10％を切り一桁台に突入へ』に思う

ここの記事より

　これはNetmarketshare社が発表したもので、それまでシェアが10％台で推移していたFirefoxのシェアが2018年5月についに大台を割り、9.92％になったというもの。1年前、2017年6月の段階では12.53％のシェアがあったことを考えると、かなりの勢いで割合が減少しており、2017年11月リリースの「Firefox Quantum」で古いアドオンがサポートされなくなったことが、少なからず影響しているものとみられる。

マルチなOSで動作し、それぞれの設定を別の環境に引き継げるFirefoxは、昔から愛用しています。
また、痒いところに手が届くアドオンが素晴らしく、Chromeが現れた後でもずっとFirefoxを利用していました。
しかし、Quantumになってアドオンの互換性を捨てた事で、Firefoxを使い続ける意味が無くなってしまいました。
愛用していたアドオンが使えないから。
これにつきます。
ブラウザの速度が速くなったからと言われても、互換性を捨てたブラウザを使い続けられない。

 今は、Waterfoxを愛用しています。(^_^;)

互換性を捨てて良いことがあった例って過去に何かあったかしら？

Visual Basicが、.Net Frameworkベースで再構築化され、C#などのマルチプラットフォーム言語の一つとなった代わりに、Visual Basic 6.0との互換性を捨てた事により、Visual Basic 6.0ベースのアプリのほとんどは、アップグレードされず、Windows 10の時代になっても、Visual Basic 6.0のアプリケーションは生き続け、Visual Basic 6.0のランタイムは、OSに標準でインストールされ続けられる。
Visual Basic 6.0の後継のVisual Basic .netは、Windows 10ではサポートされていない。

インテルがサーバー用に新しく開発した、アイテニウムは、x86の後継として64ビットCPUとして開発された、x86との互換性を捨てて新しい命令セットで動作し、x86のアプリケーションは、エミュレーション上で動作させる。
その後AMDがAMD64という後方互換性を残した64ビットCPUアーキテクチャーを発表すると、インテルまでがそちらのアーキテクチャーのCPUを開発し、アイテニウムは無かったことになってしまった。

ソニーのプレイステーションからプレイステーション２は、ソフトウェアの上位互換性があり、セガのサターンとドリームキャストはゲームソフトの互換性がなかった。

カセットビデオの方式であるβには、画質を向上させるために、いくつもの規格があり、おおよその上位互換性が保たれはしたが、S-VHSでの互換性の高さを維持したVHS規格に敗北した。

互換性を捨てて、まったく新しい方式を採用するにあたって、得るものがいかに大きくても、今まで使っていたユーザーからは、後継機ではなく全くの新製品と同じものに見える。
今まで他の新製品に見向きもしなかった忠実なユーザーが、互換性を捨てた後継機に乗り換えるだろうか？
ユーザーは製品そのものに忠実だったのを、ブランドに忠実だから、互換性を捨てても得るメリットの大きさで納得させられる、と誤解してしまったのではないだろうか？

互換性の維持とは、それほどに重要な事なのだと思う。

20年前を思い出す

ずいぶん前に、メールでVB De FilMtnのバグ報告があり、バグの修正をしていてふと気が付いたのですが、VB De FilMtn Version 0.10という最初のバージョンが公開されたのは、1998年の9月だったそうです。(ドキュメントより)
記憶では、0.10が公開されるずいぶん前から作っていたので、20年以上前から同じソースを弄繰り回していたことになります。
これ、よく考えると凄い事だよね？

まずは、Visual Basic 6.0のアプリケーション実行環境が20年間存在する件
これは、Microsoftの後方互換性が素晴らしい事だと思います。Windows 10で、x64環境でもVisual Basic 6なアプリケーションが動くのは凄い！OSにランタイムが最初からインストールされているもんねぇ～。開発環境も、仮想環境でx86なWindowsであれば、普通に動くし。Visual Studio 6がいくらしたか忘れちゃったし、高かったことしか覚えていないけど、これは元が取れているね。

次に、VB De FilMtnを20年後もメンテナンスしている件
作っていた本人は、きっと20年先もメンテナンスし続けるぞ！とは思っていなかった、というか考えてもいなかった。プログラムの需要が20年後もあるとは...。

最後に、VB De FilMtnを後方開発ツールで移行していない件
ごめんなさい。新しいVisual Studioの新しいバージョンが出るたびに、挑戦し続けているんだけど、途中で飽きちゃうんだよね。
自分の中で、今動いているプログラムをリプレースするモチベーションとか、時間とかなかなか確保できないしぃ～みたいなぁ～。
べ、別に新山(へろぱ)が、VB6でしか開発ができないってわけじゃないんだからねっ！

あの時の自分にあって、今無いものは、趣味的プログラムに時間を割り当てる能力、なのか？
今の時代、プログラミングで自分の時間を使わなくても、色んな消費コンテンツが溢れていますもんね。
ラノベを読んだり、Netfrixでアニメを観たり、ガンプラ作ったり。

20年前を思い出すと、ちょうど子供が生まれる前、結婚したてだったと思います。パソコン通信由来のネット友達と、メーリングリストで、VB De FilMtnのβ開発でいろいろやり取りしていたなぁとか。
まだ、新婚だったので結婚前の生活のリズムが生きていた。
職業もプログラマーじゃなかったし、今ほど消費コンテンツが溢れていなかったので、パソコンで何をやるかといえば、プログラムくらいしか自分にやれることはなかった。
マシンも非力でハードディスクの容量も1GBも無かったし、Windows 98だったし、ネットのインフラはISDNだったし、ビデオのメディアはレーザーディスクとVHSだったし、クルマはレガシイだったし、携帯電話持ってなかったし。

（次回に続く）＜続きません

復活の

まいど、というか久しぶりです。(^^ゞ

メインのマシンとして使っているPCは、ThinkPad E450とMac mini(mid 2011)なのですが、ThinkPad E450のハードディスクというか、ハイブリッド・ハードディスクがある日突然に故障しまして、OSが起動しなくなりました。

まぁ、Mac miniがあるので、日常生活には差し支えがありませんでしたが、Windowsアプリの開発なんかは、仮想環境でやらざるを得ず、なかなか腰を落ち着けて開発をするという気分じゃありませんでした。

仕事の方も、某所常駐での開発作業が思った以上にグダグダ具だくさんで、帰って飯食って風呂入って寝るくらいしか時間がなくて...。
春の決算ボーナスを手に入れたので、動かなくなっていたThinkPad E450を復活させて、マイ・パソコン１台っきりという心細い状態から脱出することにしました。

ハードディスクの換装です。

幸いなことに、故障したときにハードディスクが何処に設置されていて、どうすれば取り替えることができるのかは調査済みでした。

底面のネジを数個外してフタを開けて、ハードディスクを固定しているネジを外せば、簡単にハードディスクを取り外すことができます。

どうせなら、ハードディスクではなくSSDにしてやろうと考え、アマゾンで今どきのSSDの500GBの値段を調査すると、だいたい1.5万程度。えっ、もうこんなに安い値段なの？ポチッ。速攻で購入してしまいました。機種とか特に調査せず、有名所のメーカーです。

数日後、アマゾンから送られてきたSSDをThinkPad E450に換装してみました。BIOSの設定を変更しないとOSのインストールがうまくいかないことに気がつくまで、何度も再起動を繰り返す羽目になりましたが、それ以外は特に問題もなく。

それにしても、起動も終了もバカッ速！！ハードディスクは、クライアントPCには不要で、NASなどのファイルサーバー用にしか必要ないのでは？！と思うくらいです。
OSインストール後に、故障前の環境に持っていくのに数日かかりました。いろんなアプリがこの１年の間にバージョンアップしていたり、後継のアプリになっていたり、Windows 10自体がバージョンアップされていたり。

そんなわけで、故障前の状態に戻ったので、開発もバリバリ行けるよ！と思ったのですが、１年間コンテンツ消費者生活を送っていたので、なかなか開発作業に専念できません。

Netfrixでアニメを観たり、スマホでラノベを読んだり。
職業で開発をしているので、プライベートの開発欲があまり発生しないのも原因のひとつなのかなと思います。

VB De FilMtnでバグ報告をしていただいた人には申し訳ございません。プログラム自体の修正は１行で終わりましたが、ヘルプやらドキュメントの変更が面倒でもう少し時間がかかります。

Puchi Puchi jQuery plugin

概要

jQueryは、JavaScriptをさらに便利に使うフレームワークですが、そのプラグインでプチプチを作成してみました。 このプラグインを使用することにより、ご自分のサイトのページにプチプチが簡単に設置できます。

使用方法

jQueryのプラグインなので、jQueryを導入しなければ話が始まりません。
htmlのヘッダ部分で、jQueryを読み込ませてからjquery.puchi.jsを読み込ませます。

<script src="./js/jquery-1.7.1.min.js"></script>
<script src="./js/jquery.puchi.js"></script>

えっ？jQueryを知らない？ネットで調べてください。(^^ゞ

プチプチを表示したいdivタグを定義します。

<div id="puchiTest" style="height: 480px; width: 640px;">
</div>

このdivタグに対して、createPuchiメソッドを呼び出すと、divタグ内にプチプチが生成されます。

<script type="text/javascript">
$(function(){
    $('#puchiTest').createPuchi();
});
</script>

プチプチの描画にはHTML5のCanvasの機能を使用していますので、古いInternet Explorerでは動かないかもしれません。 そういった対策には、 HTML5業界ではよく知られている、excanvasを使用すれば使えるようになるようです。 「それ何？」って？自分で調べてください。(^^ゞ

<!--[if IE]>
  <script type="text/javascript" src="./js/excanvas.compiled.js"></script>
<![endif]-->

って感じです。
実は、マウス左ボタンのダブルクリックで、プチプチの絞る動作を行えます。
しかしながら、iPadやiPhoneのダブルタップでは、うまく動作しないかもしれません。
そんな時は、この業界では有名な、jquery.ui.touch.jsを読みこませるだけでうまくいくかもしれません。 iPadやiPhoneを持っていないので、本当に大丈夫かどうかは未確認です。(^^ゞ

<script src="./js/jquery.ui.touch.js"></script>

まぁ、こんな感じです。(^_^;)

オプション

サイズについては、以下の様に設定できます。

$('#puchiTest1').createPuchi({
    size : 1
});

$('#puchiTest2').createPuchi({
    size : 0
});

デフォルトは、「1(大きいプチプチ)」です。

オプション	説明	デフォルト値
size	プチプチのサイズ	1
backColor	プチプチの背景色を設定します。	残念ながらプチプチの色は白固定ですが、背景色を少しイジるとそれっぽい色のプチプチが楽しめるかもしれません。 透明度も指定すると更に雰囲気が出ます。 'rgba(192,192,192,0.7)'
cursor	プチプチの上のマウスカーソルを設定します。	'pointer'
sound	プチプチの音をさせるかさせないかの設定をすることができます。	true

まぁ、jQueryで作成されているので、ソースを見れば何をやっているか分かりますよね。(^_^;)

仕様

アプリケーション版のプチプチの仕様を引き継いでいますので、以下の様な仕様です。
実物のプチプチを忠実にエミュレーションするためにあえてそうなっています。

• プチプチを潰した時に音が出る確率は、1/6です。
• 端っこで見切れているプチプチは潰れません。(既に潰れているので)
• 絞った時に全部は潰れません。
• 絞った時に一定数のプチプチが潰れないと、絞った音がしません。

ライセンス

MIT
jQueryの世界では、一番一般的なライセンスにしておきます。

設置例

プチプチ on Web

ダウンロード

jquery.puchi.zipのダウンロード (58KB)

UnAceV2J.DLL

ACE Compression SoftwareのUnAceV2.DLLを使用して、共通アーカイバ仕様APIを実装したDLLです。対応アプリケーションから呼び出されます。

概要

ACE書庫を解凍するためにACE Compression Softwareが提供するUnAceV2.DLLは、慣れればアプリケーションから使えない事はないが、日本人の開発者には使い慣れた共通アーカイバ仕様のAPIの方が使いやすいと思うので、ラッパDLLを作成してみました。
ちなみに、世間には同様のコンセプトのラッパDLLが存在しますが、いつまで待っても進捗しないので、自アプリでACE書庫展開を実現するには自分で作るしか！と思い作成を開始し、予想通り先にリリースしてしまいました。

UnAceV2J.DLLがやっている事

UnAceV2.DLLで多用されているコールバックなAPIをクラス内に実装し、結果出力を内部変数に保持し、共通アーカイバ仕様APIの戻り値に加工します。

インストール方法

同梱されたUnAceV2.DLLまたは、 ACE Compression Softwareから取得したUnAceV2.DLLと、このUnAceV2J.DLLをWindowsのシステムディレクトリに置いてください。

アンインストール方法

インストール時にコピーしたファイルを削除してください。

使用方法

UnAceV2J.DLLに対応したアプリケーションを使ってください。
UnAceV2J.DLL は、共通アーカイバ仕様DLLのAPI仕様のほとんどを満たしている完成品です。(バグがあったらごめんなさい)アプリケーションから使用するための必要最低限の API は実装されています。
APIの使用方法に関しては、書庫付属のドキュメントを参照してください。

履歴

バージョン	日付	項目
0.01	2004/11/30	最初のバージョン。
0.02	2004/12/25	偽Unace32.dll機能を実装。ネイティブなUnAceV2J.DLL内APIをコールするラッパAPIで、UnAceV2J.DLLをUnace32.dllとリネームすると、Unace32.dllを利用するアプリケーションから使える...かも。 「l」コマンドの場合は、パス情報を出力しないようにした。(これが実用的かどうかは別として、UnAce32.exeの仕様に合わせるということで) Unlha()の仕様に倣い、UnAce()の時に、引数の_hwndに ::EnableWindow(_hwnd, FALSE) するようにした。 UnAceV2.DLLを同梱。 ソース添付。
0.03	2004/12/28	UnAceFindFirst, UnAceFindNextでの書庫内データ取得時に最後のファイルが取得できないバグの修正。
0.04	2005/05/17	storedメソッドで圧縮されたファイルをUnAceGetMethodで取得できないバグの修正。
0.05	2006/02/25	ファイルが列挙されない事があるバグを修正した。
0.06	2010/05/27	Visual Studio 2005でリビルド。 UnAceV2.DLLはVer2.6のものを同梱。
0.07	2010/07/04	Visual Studio 2010でリビルド。
0.08	2010/08/08	Visual Studio 2010 のMFCをスタティックリンクするとDLLのサイズが巨大になるので、MFCをやめてATL/WTLを使用するようにソースを修正。 レスポンスファイルの両端が「"」で囲まれている場合に対応。
0.09	2016/03/29	Visual Studio 2015 でリビルド。サポートサイトのURLとメールアドレスを変更。

『指定外の場所へファイルが展開されてしまう脆弱性』の問題の対応

『指定外の場所へファイルが展開されてしまう脆弱性』の問題というのが書庫を展開するDLLやアプリケーション側で対応されたりしていますが、後発の UnAceV2J.DLLでは、0.01から対応済みで、コマンドラインオプションで明示的に「--ea0」としない限り「..」を含んだファイルはユーザの許可無しに展開されません。詳しくは、UnAceV2CMD.txtの「--ea」オプションを参照してください。

ACE 書庫作成機能について

ACE 書庫からの展開機能に関しては、フリーソフトとして UnAceV2.DLL が提供されていますが、圧縮機能に関しては別DLLで有料となっており、私自身レジストするほど ACE 書庫の魅力を感じないので、対応する予定はありません。
同様のコンセプトで、同じくACE書庫を扱える某DLLが、将来に ActiveAce対応するらしいです。また、某所にて ActiveAce に対応した Ace32.DLL というものもあるらしいです。どちらの場合も、シェアウェアである ActiveAceを利用するため、試用期間が過ぎての利用は、ActiveAce のレジストをする必要がありますね...。既に過去の話題で、現実には何も実現していません。

ダウンロード

unacev2j009.zip (227k)

SL for Win32 Console

概要

UNIX系のファイルリストを表示するコマンドとして、lsがありますが、たまに打ち間違えてslとかやっちゃうと蒸気機関車がコンソールを横切るってのがあります。
従来の sl コマンドを Windows で動かすには、Cygwin などの擬似UNIX環境が必要で、敷居が高かったので Win32 用に移植をしてみました。
せっかくなので、x64用の実行ファイルもビルドしてみました。(x64フォルダ内に格納)
ただ、そのまま動かすだけではつまらないので、SE(効果音)も付けてみました。
sオプションでSEを抑制できます。(デフォルトで再生)
画面を横切るSLの勇姿をじっくり見たい人の為に、速度調節オプションも追加しています。(-1〜-9:デフォルトは-2)
SE(効果音)について SLの音を公開しているサイト「Ｅ127野村の鉄道音のページ」の管理人であるＥ127野村様に許可を頂き、プログラムのリソースに格納しています。

動作環境

Windows 10 または、Windows 11のコンソール環境。(x64も含む。)
Windows 10未満の動作確認は行っていません。
今バージョンは、Visual Studio 2022 C/C++ランタイムライブラリもスタティックリンクしてビルドしたので、バイナリ単体で動作するはずです。
ライセンスについて オリジナルがソースで公開されており、サイトにも特にライセンスに関して触れられていません。
ですが、本ソフトウェアは、オリジナルに順規します。
新山(へろぱ)自身の著作権は放棄します。
curses.h以下のソースについては、Public Domain cursesのソースを流用しました。
ソースについて 基本的にオリジナルの作者様のソースを元に、Visual Studio 2022 C/C++でコンパイルするようにしただけなので、積極的に公開しようとは考えていませんが、『どうしてもソースが欲しい！』という人が多いようでしたら、公開する事にします。(今までに「ソースが欲しい」と言ってきた人は1人しか居ません。)

関連リンク

ご意見ご要望がございましたら、このページのコメント欄へ

豊田正史とslコマンド(Masashi Toyoda and SL command)

オリジナルのソースがこのサイトで公開されています。

Ｅ127野村の鉄道音のページ

SLをはじめ、すばらしい鉄道音が公開されています。リソースとしての再配布の許可を頂き、ありがとうございます。
ダウンロード
sl_3.03.04_win32_x64_colsole.zip (588KB)

VB De FilMtn

概要

NEC PC-9800シリーズ用のFILMTN(テキスト版)をエミュレーションするプログラムです。またオリジナルの機能を引き継いでいますので、ファイラーとしても機能します。 (^_^;)

このプログラムのウリは、

1. あくまでもPC-9800版のFILMTN(テキスト版)をエミュレーションしているので、PC-9800系のマシンからの移行がスムーズ。もちろんAT互換機でも快適です。
2. 極力１つのウィンドウで表示するようになってるので、１つのウィンドウだけのスペースがあれば良い。
3. インストールされたディレクトリ以外にデータファイルを作らない。(勝手にルートディレクトリにファイルを作成しない。)
4. キー操作だけで快適にファイル操作ができる(というか、キーボードでないと操作できない。)ので、ノートパソコンでも快適。
5. フォントを変えてV-Text気分。(PC-9800シリーズユーザーは憧れましたよね？)
6. LHMTNの機能も内蔵しているので、シームレスにファイルが扱える。別々に作るよりは効率がよいし、ファイルサイズも小さくなってるはず。
7. 圧縮ファイルに関しては、現時点で公開されているCommon Archive Projectの多くのDLLに対応してます。
8. フリーソフトであるのでレジストしなくても自由に使える。(でも無保証。)
9. ソースも公開しているので、自由に改造が出来る。(社内用に機能を制限したり、オリジナルなキーアサインも可能。機能を追加して、宇宙最強のファイラーにも仕立てられる...かも。)
10. Visual Basicアプリにつきものの、ActiveX コントロールのバージョンの違いで動作しない、とかは、APIを直接コールしているので無い。配布ファイルも小さくて済む。(でもVisual Basicのランタイムモジュールは巨大ですが...。)

既にWindowsには有名なFILMTN, LHMTN移植アプリが複数存在するようですが、仕様(FILMTN, LHMTNの移植に対する方向性とか)に馴染めないので、このプログラムを作成しました。一度ＶＢでファイラーというものを作ってみたかったし。決してレジストが勿体無いとかの理由ではないです。 (^^ゞ

前の会社でNEC PC-9800シリーズを使用してDOSアプリ(なんとN88BASIC製アプリ)で仕事をしていたのですが、1998年度からWindows 95で仕事をすることになったので、急遽Windows 95用のFILMTNをでっち上げました。私以外の人はFILMTNの使用方法しかパソコン操作を教えてなかったので...。 (^_^;)

なお、オリジナル版の作者であるＫ．Ｉｓｈｉｄａ（石田　健仁）氏には、了承を得ました。

動作環境

マシン

日本語版 Windows NT4.0/2000/XP/Vista/7/8/8.1/10が動作するAT互換機。

ＯＳ

日本語版 Windows NT4.0/2000/XP/Vista/7/8/8.1/10 および、Microsoft Internet Explorer 4.0以上がインストールされている環境。

具体的に書くと、SHLWAPI.DLLのバージョンが4.7以上、HTMLヘルプ1.1形式が表示できる環境。
今時のOSであれば問題なく動くんじゃないかな？

履歴

バージョン	日付	項目
0.59まで		いろいろありました...。
0.60	2010/09/21	VBDeFM.Exe Unicode(UTF-16)対応。 当然のことながら、サロゲートペアを含む文字のファイル名に対応しています。 Unicode対応をすることにより、Windows 9x系OSサポートを打ち切ります。 タイムスタンプの変更ダイアログに「作成日時に合わせる」「更新日時に合わせる」ボタンを追加。 テラバイト級ハードディスクで、サイズ表示時に単位を「テラバイト」と全角カタカナで表示され表示が崩れる問題を修正。 UnLha32.DLLによるLZH圧縮ファイルのUnicode対応。
0.61	2010/11/18	VBDeFM.Exe 単独のファイルを「P」キー押下して表示されるウィンドウのタイトルがUnicode文字の場合化ける問題を修正。 内蔵ビュアーのテキスト表示が、文字コードに関係なく表示できるように改善。 ファイル名の表示方法が「自動」になっていた場合に、カレントディレクトリの移動を行った直後のアクティブなファイル表示が乱れる問題を修正。(前バージョンで入り込んだバグ) ディレクトリ名がUnicode文字の場合に移動できない問題を修正。 Unicodeファイル名のタイムスタンプの変更ができるように改善。 「K」キー押下によるディレクトリの作成の動作改善。
0.62	2010/12/05	VBDeFM.Exe, FMCust.Exe 起動時にSetDllDirectory("")を行い、意図しないDLLのロードが行われないように修正。
0.63	2011/02/19	VBDeFM.Exe 7-zip32.DLLによる7Z圧縮ファイル、ZIP圧縮ファイルのUnicode対応。 Tar32.DLLによるXZ形式・LZMA形式の操作に対応。 ファイルのサイズが0のときに、内蔵ビュアーがエラーとなっていたのを修正 UnIso32.DLLによるISOファイルの操作に対応。 FMCust.DLL Tar32.DLLによるXZ形式・LZMA形式の操作に対応。 7-zip32.DLLによるZIP圧縮ファイルのメソッドを追加。 EzExt.Ini いくつかの再定義。
0.64	2011/02/28	VBDeFM.Exe カレントディレクトリをルートにしたときに、ディレクトリ表示が見えなくなっていたのを修正。
0.65	2013/01/03	VBDeFM.Exe カレントディレクトリをUNCパスのディレクトリへ移動できないバグの修正。(Ver 0.6x系からのバグ) ZIP書庫内のファイルを指定して展開する場合で、7-zip32.dllを使用するオプションが有効の場合、展開先に展開されないバグの修正。(Ver 0.63からのバグ) ZIP書庫内のファイルを削除する場合で、7-zip32.dllを使用する場合にエラーで削除できない問題を回避。 「Lzhファイルの場合、リムーバブルドライブの時はテンポラリディレクトリに解凍後移動する」オプションを廃止。 Windows 8への対応 FMCust.DLL Windows 8への対応(ダイアログの文字列表示が切れる対応)
0.66	2013/08/04	VBDeFM.Exe ディレクトリの存在しないドライブでのツリー表示でルートが表示されない、コピー・移動ができないバグを修正。
0.67	2014/01/04	VBDeFM.Exe Windows 8.1対応。 FMCust.DLL Windows 8.1対応。
0.68	2016/03/21	VBDeFM.Exe Windows 10対応。 FMCust.DLL Windows 10対応。
0.69	2016/12/25	ミニマム版での注意点のドキュメントを追加 VBDeFM.Exe IDE内動作でのサイド・バイ・サイドDLLについての挙動の調節(実行中の動作は変わらないです。) EzExt.DLL デバッグ時のメッセージボックスが表示されるバグの修正 既知のバグ
0.70	2018/06/03	一画面で収まるテキストを内蔵ビュアーで表示してPgDnや Shift + Homeなどの行移動を行うとエラーが発生するバグを 修正。

既知のバグ

特に無いと思いますが、発見した場合ご連絡していただけると対処できるかもしれません。

ダウンロード

vbdfm70m.zip	実行ファイルのみのセット	(798KB)
vbdfm70s.zip	ソースのみのセット	(837KB)
vbdfm70f.zip	セットアッププログラムを含んだセット	(1,579KB)

フルセット版にはVisual Basic 6.0のランタイムが付属しています。
残念ながらVisual Basic 5.0とVisual Basic 6.0の開発環境は共存できません。ただし、アプリケーションは共存できるようです。

ユーザーからは、Visual Basic 5.0のアプリもVisual Basic 6.0のアプリも問題なく使えるようです。

ミニマム版は旧バージョンからバージョンアップする場合にご利用ください。
Visual Basic 5.0でコンパイルする時には、VBDeFMVB5.VBPを読み込みます。

---

VB De FilMtn 0.69リリース

前回のブログエントリの予告通り、VB De FilMtnの最新版をリリースしました。
なんか、添付のEzExt.DLLの動きがおかしかったですね。ごめんなさい、このバージョンはきっと正しく動作するはずです。

さて、年末って忙しいですね。
先ほど年賀状を印刷し終わりました。これからポストへ投函です。
年賀状の準備はずっと前からできていたんですけどね。我が家の画伯(息子)に、今年の年賀状のデザイン画を発注しまして。
何故、今まで放置していたかというと、ただの思い付きが悪かっただけなんですよ。
やり始めると数時間で終わるのですけど...。

本日から、消防団の夜警が始まります。２４時まで詰所で待機です。待機中に事件が起こらないことを願いながら、詰所で待機しています。

偽UnZip32.DLLをリリース

前回の投稿の通り、偽UnZip32.DLLをリリースしました。
現状に困ってない人は、このリリースのDLLに入れ替える必要はないと思います。
これから、インストールしてみようと思った奇特な方は、最新のものをどうぞ。

ドキュメントの修正をしていて、履歴を見ると、前回のリリースからかなり時間が経っていることに気が付きました。その間、何をしていたのでしょうね。俺は。(^^ゞ
転職はしていないのですが、職場が５回変わったかな。いわゆる常駐先と言われる作業場。
どこも前任者がプロジェクトを抜ける事情があって、そこに代打や代走のように急きょあてがわれる要員として。
あてにされるというのは、やはり嬉しいのですが、あてにし過ぎです。ほかに要員は居ないのかと！
最初は、物凄く働く時間だけが長くて、会議が深夜だったりで生活リズムがバラバラで、とても趣味のプログラミングというような状態ではなかった。
その職場が激務のせいだと思うのだけど、そのあと十二指腸潰瘍で入院しましたもの。
その次は、自社で開発をしていたのですが、これは割と楽しかった。まぁ、さっきも話しましたが、入院はしたのですが。
そして、最もつらかった次の職場、通勤がマイカーで片道２２ｋｍ。
ニュービートルだと、１か月に２回の給油ですよ。通勤なので混雑するので運転はストレス以外の何物でもありませんでした。
仕事自体は、難しくなくて楽だったのですけど、通勤時間と通勤そのものがつらかった。
今も、それくらい通勤に時間とコストをかけている方、大変ですね、同情します。(^_^;)
で、そこが終わって、そろそろ自社の若い衆を鍛えてくれ！とか言われて、自社に戻ったものの、某所の要員が退職することになったので、帰社１か月で急遽代役として某所に。それが今の常駐先ですが、去年の１２月中からなので、ちょうど１年が過ぎたところです。
最初に書いた、時間がやたらと拘束される職場と同じ会社なのですが、部署が違うだけでこんなに楽とは！
特に、通勤が楽。自宅の最寄りのJR駅から職場最寄りのJR駅で、ほとんどドア・ツゥー・ドア。片道２０００歩以内。毎日ほぼ定時。
そりゃ、趣味のプログラミングでも復活させようか！って気持ちにもなるはずです。
やたらと、通勤距離が長かった職場のころに比べると、今は休みの日のお買い物に車を使うくらいなので、１か月に３０００円くらいガソリンを入れる(満タン入れない)で充分ですからね。ガソリン代が高いとか安い以前の問題です。(^_^;)

さて、次のリリースは、VB De FilMtnです。
実はもう準備していますが、そろそろ寝るので。(^^ゞ

Info-Zip製 UnZip32.DLLをbzip2対応でビルドする

Info-Zip製 UnZip32.DLLの最新のバージョンは、6.10bのようです。
ドキュメントを眺めてみると、deflate64メソッド以外にも、bzip2メソッドの展開のサポートも追加されているようです。

6.10bはβ版で、しばらくすると正式版をリリースするぜ！(意訳)

とありますが、正式バージョンはもう何年もリリースされていません。
前回のブログのエントリで、偽UnZip32.DLLもバージョンアップするよ。って書いてしまったので、Info-Zip製 UnZip32.DLLが手元でビルドできるかを確認してみました。
というのは、

偽UnZip32.DLL = Info-Zip製 UnZip32.DLL + 独自ソース

なので、Info-Zip製のUnZip32.DLLが無いとお話が始まらないからです。

用意するもの

Microsoft Visual Studio Community 2015 Update 3

フリーソフトプログラマには、必須の開発ツールですよね。

Info-Zip製 UnZipのソース

ここあたりから、unzip610b.zipをダウンロードします。

bzip2のソース

ここから、bzip2-1.0.6.tar.gzをダウンロードします。

ビルド環境の構築方法

1. Microsoft Visual Studio Community 2015 Update 3をインストールする。
2. unzip610b.zipを作業ディレクトリに展開する。
3. bzip2-1.0.6.tar.gzを作業ディレクトリに展開する。
4. 3.を展開して得られたソース一式を、2.で展開したunzipのソース配下のbzip2配下にコピーする。
5. unzip610b\windll\vc8\unzip32.sln をVisual Studio Community 2015で読み込ませる。vc8用のプロジェクトなので、プロジェクトのアップデートを行う。
6. ソリューション エクスプローラから、プロジェクト「c_dll_ex」と「unz32dll」以外を削除する。(今回は不要だから)
7. スタートアップ プロジェクトは「c_dll_ex」に設定する。
8. ソリューションにunzip610b\win32\vc8\bz2lib.vcproj プロジェクトをソリューションに追加する。変換されてソリューションに追加される。
9. global.h内の「# include "bzlib.h"」を「# include "bzip2/bzlib.h」に修正する。
10. ソリューションのプロパティ＞共通プロパティ＞プロジェクトの依存関係　のプロジェクト「unz32dll」の依存先をbz2libにする。
11. unz32dll プロパティ＞構成プロパティ＞C/C++＞プリプロセッサ＞プリプロセッサの定義に「USE_BZIP2」を追加する。
12. unz32dll プロパティ＞構成プロパティ＞リンカー＞入力 の追加の依存ファイルに、「bz2lib」でビルドされるbzip2.libをフルパスで追加する。(マクロを使うと簡単に表記できるかもね。)
13. ソリューションのリビルドを行い、ビルドをする。

うまくビルドできれば、unzip610b\windll\vc8\Debug\appに、unzip32.dllとそのdllを使うテストプログラムであるuzexampl.exeがあるはずです。
ワーニングがチョットばかし出ますが、致命的ではないので気にしない気にしない。(^_^;)
bzip2メソッドでzipしたファイルを同ディレクトリにコピーします。
コマンドプロンプトで、同ディレクトリにカレントディレクトリに移動して、

uzexampl.exe bzip_method.zip

みたいにすると、展開できるようにビルドできたことが確認できます。
コマンドプロンプトで、そのディレクトリに移動して、

偽Zip32J.DLL新バージョンリリース

偽Zip32J.DLL Version 0.37.0.10(10)をへろぱ的サイトにてリリースしました。
前のバージョンから新しい機能はありません。
この通り、サイトを移動したので添付のドキュメントを修正したのと、Visual Studio 2015 C/C++でリビルドしなおしただけです。
いやぁ、前のバージョンから６年以上経っていますよ。今回、６年ぶりくらいに自分の書いたソースを見直したのですが、...中々ですね！(^^ゞ
というか、今書くとしてもきっと同じコードになるはず。
進歩がないというか...。
自分の書いたコードなのに、ちょっと感心したのが、丁寧さと規模。今、これだけの規模のコードを一から書けるのか？今は、読書がメインの趣味になっているので、プライベートでこんなにコードに向かい合えるのか？
そんなことも思いました。

偽UnZip32.DLLも近日中にアップデートする予定です。

標準出力を取り込むC/C++なプログラムがReadFileで戻らない場合は

ネットで検索すると、いい感じのサンプルがいくらでもあって、そのロジックを流用して、何かしらのコマンドを実行させ、標準出力を名前なしパイプで取り込んで、何かしらの処理をするパターン、よくありますよね。
powershellで実行した標準出力を取り込んで、何かの情報を自アプリで参考にしたい場合、C/C++アプリでは、上記のロジックを使おうと思いますよね。
でも、ReadFileのところでだんまりとなって、CreateProcessで開いたコマンドプロンプトのウィンドウを閉じないと先に進めない。
何故なんだろう？どうしてなんだろう？（外国人の日本語による弁論大会風に）

powershell実行時には、CreateProcessの引数にセットするSTARTUPINFO構造体のhStdInputは、セットせずにNULLにすれば良いみたい。
どうせ、そんなプログラムには、入力処理なんてないのだから。(暴言)

powershellと言えば、コマンドプロンプトから実行すると、ちゃんと出力できているんだけど、上記のようなプログラムからCreatePorcessすると、コマンドが失敗することがあります。
これって、32ビットプロセスからpowershellをキックすると、32ビットなpowershellがキックされて、必要なコマンドが見つからないパターンですよね。
32ビットアプリから、64ビットなpowershellをキックしたいなら、%WINDIR%\sysnativeディレクトリのcmd.exe経由でキックすると良い。
%WINDIR%\sysnativeディレクトリは、現実には存在しないが、32ビットプロセスから見た64ビット用のSYSTEM32ディレクトリのアリエスだそうです。

C:\Windows\sysnative\cmd.exe /c powershell.exe Get-Command

みたいな感じです。

MFC CFileDialogでカスタマイズ・ダイアログが使えない？

そんなことはない。
古いVisual Studioのプロジェクトを保守しようとして、ディレクトリの選択ダイアログの代わりに、カスタマイズ・ダイアログが使われているパターンに出くわしたとします。
古いプロジェクトを、今時のVisual Studioで更新して、実行してみるとカスタマイズが出来ないって事を経験したことがありませんか？
ディレクトリの選択ダイアログに書き直してしまいたいけど、そこまで既存のソースを弄りたくないとか、弄れる時間がないとか、弄れる権限がないとか...。

　MSDNのCFileDialogの説明によると、

Windows Vista の CFileDialog の外観と機能は、以前のバージョンの Windows から変更されています。 既定の CFileDialog は、コードを変更しなくても、プログラムが Windows Vista でコンパイルおよび実行されると、自動的に新しい Windows Vista スタイルを使用するようになっています。 この自動更新機能を手動でオーバーライドする場合は、コンストラクターで bVistaStyle パラメーターを使用します。 この自動更新機能が適用されないのは、カスタマイズしたダイアログ ボックスです。 カスタマイズしたダイアログ ボックスは、新しいスタイルに変換されません。

とあります。
この文章から読み取りにくい情報ではありますが、つまり、コンストラクタのbVistaStyleをFALSEでコンストラクタを呼び出すようにすれば、カスタマイズ・ダイアログは、ちゃんと表示されるはずです。

という情報が、なかなかネットになかったので。
MFCをやっている人の絶対数が減ってるだろうし、インターネットで自分から情報を公開しようとする人も少なくなっているようだし、結局はMSDNなどの一次情報から自分のやりたい事を紐解く作業が必要になってくるのかな、面倒くさい...。

.NET Framework 4.6.2 でPathTooLongExceptionが回避できるのか？

.NET Framework 4.6.2で、MAX_PATH(260)の制限が取り払われたよ～！
というニュースをあちこちで見て、『ほぅ～、どれどれ』と、プログラムを書いてみるものの、全然思い通りにならない。
マジでMAX_PATH越えを実装しているのか？！
と、途方に暮れて数週間。
こんなサイト(開発関係者のブログ？)を発見。

.NET 4.6.2 and long paths on Windows 10

英語の苦手な、ネイティブ・ドイツ人の私には、なかなかよく分からないのだが、どうやら、

• Windows 10 Anniversary Update以降のOSのみに対応
• ローカル・グループ・ポリシーで、Enable Win32 long pathをOnにしなければならない
• .NETアプリの設定ファイルApp.configにLongPath動作を有効にする設定が必要

という条件が揃わないと駄目らしい。使えねぇ～！

一応、同じような事で困っているかもしれない人のために、詳細情報を。

Windows 10 Anniversary Update以降のOSのみに対応

Windows 8は、.NET Framework 4.6.2は対象外としても、Windows 8.1やWindows 7はまだ現役でバリバリ使われているOSなのに。
実は、ちゃんと裏を取っていません。「いや、Windows 7で動くぜっ！」とか反論がある人は、コメントをよろしくお願いします。

m(_ _)m

ローカル・グループ・ポリシーで、Enable Win32 long pathをOnにしなければならない

 デフォルトでOffになっているって事は、既存のアプリがMAX_PATHを前提に作られているから、互換性のために無効になっているのだと思われます。
Windows 10 Homeでは、グループ・ポリシー・エディタって無いじゃん？と思ったら、先に紹介したサイトでも同じようなコメントが付いていて、レジストリエディタで値をいじると良いよ、的アドバイスがあります。

おそらく、OSの再起動が必要じゃないかと思います。
この件も、試行錯誤の上、そうしないと動かなかったって事なんですけど、「Windows 10 Anniversary Updateじゃないけど、動くぜ！」と反論のある方はコメントにてお願いします。

.NETアプリの設定ファイルApp.configにLongPath動作を有効にする設定が必要

これも、紹介したサイトに情報がありますけど、こんな感じになるはずです。

後、以降錯誤をして気が付いたのですが、System.IO.Directory.CreateDirectoryで作れるディレクトリ名の長さは、やはり制限があって、一つにつき246文字とMAX_PATHよりもさらに小さい長さでしか作れない。もちろん、200文字ずつ３つのフォルダを組み合わせてだったら、合計文字列としてMAX_PATH越えはOKのようです。
 MAX_PATH越えの確認をするプログラムで、まずはディレクトリから作ろうと普通は考えるので、この見えない制限で結構ハマるんじゃないかな？私だけか？

それにしても、今回の件もなのですが、日本語の情報って少ない。
というか、開発者のブログではなく、Microsoftの.NET Frameworkのサイトの情報に、ちゃんと書いてよ！
紹介サイトの人のブログのコメント欄でしか情報が分からないって、おかしいじゃん！
フリーソフトじゃないんだから。天下のMicrosoftのミドルウェアソフトなんでしょ？！
とか、思いました。
そして、品質はともかく、AlphaFSの方が良く無くない？とか思いました。

LHA Library for javaをC#から使う

jLHA(LHA Library for Java)は、LHA書庫を扱えるJavaのライブラリです。素晴らしい！
でも、.NETで使えないものか？

使えるのです。
IKVM.NETは、.NET Framework上で動作するJava VMです。このプロダクトの一つに、Javaのjarファイルを.NETのEXEまたはDLLに変換してくれるikvmcがあります。
まずは、LHA Library for Javaをjarにします。サイトで配布しているのは、Javaのソースなので、Eclipseでソース一式を読み込ませて、Exportでjarファイルを作成します。
そのjarファイルをIKVM.NETサイトからダウンロードしたikvmbin-7.2.4630.5.zipを展開したディレクトリ配下のbinディレクトリにコピーします。
コマンド プロンプトを開き、先ほどのbinディレクトリに移動します。

C:\Users\heropa\ikvmbin-7.2.4630.5\bin>ikvmc -target:library -platform:anycpu jlha-lib.jar
IKVM.NET Compiler version 7.2.4630.5
Copyright (C) 2002-2012 Jeroen Frijters
http://www.ikvm.net/

note IKVMC0002: Output file is "jlha-lib.dll"

これで、.NETで使用できるDLLが作成されます。
.NETでの参照設定には、上記DLLとIKVM.OpenJDK.Core.dllを加えます。
C#のソースは、こんな感じ。

using jp.gr.java_conf.dangan.util.lha;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace jlha_lib_test
{
    class Program
    {
        static void Main(string[] args)
        {
            LhaFile lha = new LhaFile("C:\\Users\\heropa\\Downloads\\cldx\\jack020.lzh");
            LhaHeader[] headers = lha.getEntries();
            foreach(LhaHeader h in headers)
            {
                Console.WriteLine("Path:{0}", h.getPath());
                Console.WriteLine("CompressedSize:{0}", h.getCompressedSize());
                Console.WriteLine("OriginalSize:{0}", h.getOriginalSize());
                Console.WriteLine("LastModified:{0}", javadateToString(h.getLastModified()));
                Console.WriteLine("Method:{0}", h.getCompressMethod());
                Console.WriteLine("CRC:{0:X}", h.getCRC());
                Console.WriteLine("----------");
            }
            Console.ReadKey();
        }

        private static string javadateToString(java.util.Date javaDate)
        {
            DateTime date = new DateTime(javaDate.getYear() + 1900,
                                         javaDate.getMonth() + 1,
                                         javaDate.getDate(),
                                         javaDate.getHours(),
                                         javaDate.getMinutes(),
                                         javaDate.getSeconds());


            return date.ToLongDateString() + " " + date.ToLongTimeString();
        }
    }
}

Javaのクラスが所々混じって変な感じです。
getLastModifiedメソッドが返すjava.util.Dateは、年が1900年ほど足りないようです...。
java.util.Date.getMonthメソッドは、0始まりなので、DateTimeとは、1ズレるんですよね、javaってなんでこんな仕様なんだろう？って思うことがしばしば...。
出力は、こんな感じ。

Path:Jack32.dll
CompressedSize:37473
OriginalSize:75264
LastModified:2002年06月01日 18:08:04
Method:-lh5-
CRC:AE67
----------
Path:Jack32.lib
CompressedSize:1079
OriginalSize:4986
LastModified:2002年06月01日 18:08:02
Method:-lh5-
CRC:2BA1
----------
Path:JackApi.h
CompressedSize:5320
OriginalSize:19339
LastModified:2001年11月02日 21:42:08
Method:-lh5-
CRC:88AB
----------
Path:Api.txt
CompressedSize:2959
OriginalSize:11284
LastModified:2002年06月01日 18:05:48
Method:-lh5-
CRC:429E
----------
Path:Command.txt
CompressedSize:2058
OriginalSize:5789
LastModified:2002年06月01日 18:05:52
Method:-lh5-
CRC:D4AE
----------
Path:Jack32.txt
CompressedSize:4282
OriginalSize:10277
LastModified:2002年06月01日 18:07:06
Method:-lh5-
CRC:B231
----------

わざわざこんな事をしなくても、WindowsにはUnLHA32.DLLがあるじゃないか！
ごもっともです。
ただ、IKVM経由でjLHAを使うってことは、64bit版アプリを簡単に作れるってことなんですよね？！
暑いから試してないけど。

(^_^;)

車輪の再発明について思ったこと

プログラマにとって、車輪の再発明は駄目なことではないし、無駄でもない。
けど、その車輪が使えるものなら、使わないと損だよね。

車輪(ライブラリとかソリューション)の再発明をしてしまう理由とは、

1. 車輪を自分で作りたかったから。
2. その車輪の存在を知らなかった。
3. その車輪に欠陥が多くて使えないから。
4. ライセンスで使えないから。

順番には意図は無いです。
1. と3. はどんどんやるべきだと思う。2. は、できるだけ避けたい。そのためには、事前の技術調査が必要なんだと思う。
4. なんだけど、再利用が制限されるライセンスって困る。個人的には、MITライセンス的なものが嬉しい。

車輪の再発明が悪でないと思うのは、多様性がある方が色々いいんじゃないかと思うんですよ。
例えば、なんたらFileUploadの脆弱性で、そのライブラリを使っているプロダクトが軒並み脆弱性の影響を受ける、とか...。
H・G・ウェルズの宇宙戦争の火星人のよう。