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・ウェルズの宇宙戦争の火星人のよう。

Lha for Win32 Console作成開始

Lha for UNIX 1.14i のソースを元に、Win32用コンソールアプリケーションとして作成中。
とりあえず、リストの出力は、Win32っぽくなったでしょ？

UnLha32.DLLが開発を休止して久しいですが、如何お過ごしでしょうか？＞関係者の方々

(^_^;)

通勤にマイカーで片道20kmの常駐先から、JRで10分+徒歩5分の常駐先に移動となったので、ガソリン代貧乏から脱出することができて半年...。
就業時間も、ほぼ定時で帰れるのですが、夏の消防団小型ポンプ操法大会に向けての練習があり、なかなか趣味のプログラミングが捗りません...。

64bit版Windowsが16bitアプリのサポートをしなくなったので、MS-DOSコマンドとしてのLHA.EXEが動かなくなりました。
もう少し待っていれば、Ubuntuのコンソールアプリとして、Lha for UNIXなLhaが動くようになるのかもしれないですが、ちゃんとUnLha32.DLL互換なLzh書庫が作れるWin32コンソールアプリが欲しかったんだよぅ～！！
自分の為のアプリで、公開する予定はない。多分しない。そもそも、完成がいつになるか...。

ATL/WTLのソースを、Visual Studio 2015 でビルドしてWindows xpでエラーにならないようにする

マニアックな需要ですか？(^_^;)
新山(へろぱ)のホームページが、ホスティングしていたプロバイダーの都合で無くなってしまったので、やむなくGoogle siteに自作ソフトウェアを置いているのですが、中のドキュメントとかの見直しをしなければ、と暇なときにドキュメント直したりソースをビルドし直したりしています。

新山(へろぱ)的優先度として、窓の杜様にも転載されているUnAceV2J.DLLのドキュメントを直すとして、せっかくなのでDLL本体もVisual Studio 2015でビルドし直そうと考えた次第です。
 WTLを使用しているので、Visual Studio 2015に対応したWTL待ちでしたが、それもリリースされていますので問題なし。
Visual C/C++ 2015もWindows xpをターゲットとしてコンパイルできるようになっています。

なのに、Windows xpで動作確認すると、オートメーションエラーとかで予期せぬエラーとなり、呼び出したアプリごと終了してしまう。

困ったなぁ～、既存のバージョンのようにVisual Studio 2010でビルドしてお茶を濁すか～とか考えていたところで、こんなサイトを発見！

Visual Studio 2015 cannot produce an ATL Dll that successfully registers on Windows XP

つまり、ビルドオプションに「/Zc:threadSafeInit-」を追加すればOKOK!

車検、むっちゃ掛かった！

2001年式のニュービートル、今年で15年目。
ついさっき、車検の料金を払ってきたんだけど、むっちゃ高かった。

いや、車検自体の費用はいつもどおりなんだけど、整備費用がむっちゃ高かった。

作業内容・部品名名称	数量	単価	金額	技術料
エンジンオイル	4.0	1,600	6,400
オイルフィルター	1.0	1,700	1,700
ブレーキオイル	1.0	2,000	2,000	1,500
フロントディスクパッド	1.0	10,400	10,400	2,600
ステアリングラッツブーツ	2.0	1,900	3,800	6,100
ブーツバンド1	2.0	540	1,080
ブールバンド2	2.0	230	460
タイロッド	2.0	18,000	36,000	6,100
タイロッドエンド	2.0	7,200	14,400
タイミングベルト	1.0	8,400	8,400	26,800
タイミングテンショナーローラー	1.0	12,500	12,500
ウォーターポンプ	1.0	13,500	13,500
LLC	2.0	900	1,800
ロアアームブッシュ	2.0	4,000	8,000	21,200
ダイナモ(リビルド)	1.0	34,800	34,800	11,800
エアマスセンサー	1.0	8,000	8,000

こんな感じ。
これに、車検費用を含めて、30万円オーバー...。
まぁ、30万円でニュービートルは買えないから仕方が無いんだけど。

でも、クルマの調子は良くなった。
そうそう、新品の頃はこんなにエンジンレスポンス良かった！って思い出したくらい。
ハンドルを切るときに、途中でカクっとする変な感じも無くなっているし。
何よりも、ドアノブ内側の取っ手の取り付け部が折れてブラブラしていたのが、何気に直してくれているし。車内の清掃も完璧に綺麗だし。
これらの分の料金入ってないし。

顧客満足度100%です。素晴らしい！

.NETのPathTooLongExceptionを克服する

.NET Frameworkのファイルを扱うSystem.IO辺りのクラスのメソッドは、過去の経緯(Windows 9x系をサポートする.NET Framework 1.1からの正常進化のため？)により、MAX_PATH(260)バイト以上のファイルパスが扱えません。

これ、ファイラーや、ファイルを扱うツールとしては、致命的なんじゃないだろうか？
今時の大容量なハードディスクにファイルを保存すると、階層が深くなりがちだし。音楽ファイルなんて、データフォルダパス＞ジャンル＞アーティスト名＞アルバム名＞タイトル名なパスになるし。

Microsoftは、.NET Frameworkの中身を、UNICODEバージョンのAPIをコールするように書き換えるべき。 というニーズを汲み取ったライブラリが実は存在します。

AlphaFS

これをプロジェクトからの参照設定に加えるだけで、System.IO以下のクラス・メソッド類を置き換えることができるようになります。
VBなら、Importsをコンパイルスイッチで切り替えてやれば。

#If UseAlphFS Then
Imports Alphaleonis.Win32.Filesystem
#Else
Imports System.IO
#End If

こんな感じで。

.NET から IFileOperation を使う

IFileOperation インターフェースとは？

コピー、移動、名前の変更、作成、および進捗状況とエラーダイアログを提供するために、シェルの項目と同様の方法を公開したインターフェース。
従来の Windows API の SHFileOperation の機能を置き換えたもので、Windows Vista から実装されている機能だそうです。(https://msdn.microsoft.com/ja-jp/library/windows/desktop/bb775771%28v=vs.85%29.aspx)

SHFileOperation については、.NET Framework では Microsoft.VisualBasic.dll でラップされていて、Visual Basic では、My.Computew.FileSystem から呼び出すことができます。
しかし、SHFileOperation のすべての機能が使えるわけでもないし、痒い所に手が届かない感じ。

アンマネージドなコードで再実装するにしても、今さら Vista 以前の OS なんてサポートする必要なんてないから、IFileOperation で実装したほうが良いじゃん！

とか思って調べてみても、なかなか情報が集まらないが、やっと見つけたのでメモ。

MSDN マガジンのバックナンバーとダウンロード

2007年12月(December 2007)をクリックして MSDNMagazine2007_12ja-jp.chm をダウンロードします。

「MSDN Magazine December 2007」のコンパイルされたHTML ヘルプ ファイルを開いて、中身が見られない場合は、Explorer からのマウス右クリックによるファイルのプロパティ「全体」タブの下部の「セキュリティ：このファイルは他のコンピュータから取得したものです。～」の「ブロックの解除」ボタンを押下して解除すると中身は読むことができます。

その記事の「.NET の問題: Windows Vista での IFileOperation:」に記事があります。

その記事中の「コードのダウンロード」をクリックすると、サンプルのソースもダウンロードできます。

Visual Studio 2015に対応したWTLがリリースされてますね

待ちに待ったVisual Studio 2015に対応したWTLがリリースされているのに、今日気が付きました。

Windows Template Library (WTL)

これで、既存のVisual Studio 2010で作成されたあれやこれやのソースも、Visual Studio 2015でビルドできるかも！

C#で書かれたソースをVBに書き直す(またはその逆の)方法

二つの言語ともに精通しているなら、何も迷うこともなく移植できると思うんだけど、「あれっ？VBではどう書くんだっけ？」って手が止まる場合は、逆コンパイラを使うと良いかもね。

元のソースが、C#であろうとも、VBであろうとも、コンパイルされたものはアセンブリなので、大抵の逆コンパイラで、VBかC#なソースとして見ることができるはず。
では、逆コンパイルなツールの紹介。

古い記事なので、紹介文よりはマシになっているかも。

消費者にとっての本当の幸せ

ここの記事(既にリンク消失)より
市販されている缶チューハイは、ジュースより安い。なので、未成年の飲酒や飲酒運転を助長するから何とかしないとね。という記事なのですが、記事の一番最後で、

ＮＰＯ「アルコール薬物問題全国市民協会」の今成知美代表は「飲酒運転や依存症患者が社会問題になっている。消費者にとっての本当の幸せは、価格が安いことではない。増税やテレビＣＭ禁止などの規制強化が必要だ」と話している。

というフレーズがとても気になる。
消費者にとっての本当の幸せは、ジュースの値段が缶チューハイよりも安くなることなんじゃないのだろうか？
増税をされて幸せだと思う消費者はいないと思う。
飲酒運転を防止するための施策を実施するために増税が必要って意味なら分かるんだけどね。言葉足らずなだけなんだろうか？

(2006/10/05の旧ブロク掲載の記事を転載)