前回のブログエントリの予告通り、VB De FilMtnの最新版をリリースしました。
なんか、添付のEzExt.DLLの動きがおかしかったですね。ごめんなさい、このバージョンはきっと正しく動作するはずです。
さて、年末って忙しいですね。
先ほど年賀状を印刷し終わりました。これからポストへ投函です。
年賀状の準備はずっと前からできていたんですけどね。我が家の画伯(息子)に、今年の年賀状のデザイン画を発注しまして。
何故、今まで放置していたかというと、ただの思い付きが悪かっただけなんですよ。
やり始めると数時間で終わるのですけど...。
本日から、消防団の夜警が始まります。２４時まで詰所で待機です。待機中に事件が起こらないことを願いながら、詰所で待機しています。
2016/12/25
2016/12/24
偽UnZip32.DLLをリリース
前回の投稿の通り、偽UnZip32.DLLをリリースしました。
現状に困ってない人は、このリリースのDLLに入れ替える必要はないと思います。
これから、インストールしてみようと思った奇特な方は、最新のものをどうぞ。
ドキュメントの修正をしていて、履歴を見ると、前回のリリースからかなり時間が経っていることに気が付きました。その間、何をしていたのでしょうね。俺は。(^^ゞ
転職はしていないのですが、職場が５回変わったかな。いわゆる常駐先と言われる作業場。
どこも前任者がプロジェクトを抜ける事情があって、そこに代打や代走のように急きょあてがわれる要員として。
あてにされるというのは、やはり嬉しいのですが、あてにし過ぎです。ほかに要員は居ないのかと！
最初は、物凄く働く時間だけが長くて、会議が深夜だったりで生活リズムがバラバラで、とても趣味のプログラミングというような状態ではなかった。
その職場が激務のせいだと思うのだけど、そのあと十二指腸潰瘍で入院しましたもの。
その次は、自社で開発をしていたのですが、これは割と楽しかった。まぁ、さっきも話しましたが、入院はしたのですが。
そして、最もつらかった次の職場、通勤がマイカーで片道２２ｋｍ。
ニュービートルだと、１か月に２回の給油ですよ。通勤なので混雑するので運転はストレス以外の何物でもありませんでした。
仕事自体は、難しくなくて楽だったのですけど、通勤時間と通勤そのものがつらかった。
今も、それくらい通勤に時間とコストをかけている方、大変ですね、同情します。(^_^;)
で、そこが終わって、そろそろ自社の若い衆を鍛えてくれ！とか言われて、自社に戻ったものの、某所の要員が退職することになったので、帰社１か月で急遽代役として某所に。それが今の常駐先ですが、去年の１２月中からなので、ちょうど１年が過ぎたところです。
最初に書いた、時間がやたらと拘束される職場と同じ会社なのですが、部署が違うだけでこんなに楽とは！
特に、通勤が楽。自宅の最寄りのJR駅から職場最寄りのJR駅で、ほとんどドア・ツゥー・ドア。片道２０００歩以内。毎日ほぼ定時。
そりゃ、趣味のプログラミングでも復活させようか！って気持ちにもなるはずです。
やたらと、通勤距離が長かった職場のころに比べると、今は休みの日のお買い物に車を使うくらいなので、１か月に３０００円くらいガソリンを入れる(満タン入れない)で充分ですからね。ガソリン代が高いとか安い以前の問題です。(^_^;)
さて、次のリリースは、VB De FilMtnです。
実はもう準備していますが、そろそろ寝るので。(^^ゞ
現状に困ってない人は、このリリースのDLLに入れ替える必要はないと思います。
これから、インストールしてみようと思った奇特な方は、最新のものをどうぞ。
ドキュメントの修正をしていて、履歴を見ると、前回のリリースからかなり時間が経っていることに気が付きました。その間、何をしていたのでしょうね。俺は。(^^ゞ
転職はしていないのですが、職場が５回変わったかな。いわゆる常駐先と言われる作業場。
どこも前任者がプロジェクトを抜ける事情があって、そこに代打や代走のように急きょあてがわれる要員として。
あてにされるというのは、やはり嬉しいのですが、あてにし過ぎです。ほかに要員は居ないのかと！
最初は、物凄く働く時間だけが長くて、会議が深夜だったりで生活リズムがバラバラで、とても趣味のプログラミングというような状態ではなかった。
その職場が激務のせいだと思うのだけど、そのあと十二指腸潰瘍で入院しましたもの。
その次は、自社で開発をしていたのですが、これは割と楽しかった。まぁ、さっきも話しましたが、入院はしたのですが。
そして、最もつらかった次の職場、通勤がマイカーで片道２２ｋｍ。
ニュービートルだと、１か月に２回の給油ですよ。通勤なので混雑するので運転はストレス以外の何物でもありませんでした。
仕事自体は、難しくなくて楽だったのですけど、通勤時間と通勤そのものがつらかった。
今も、それくらい通勤に時間とコストをかけている方、大変ですね、同情します。(^_^;)
で、そこが終わって、そろそろ自社の若い衆を鍛えてくれ！とか言われて、自社に戻ったものの、某所の要員が退職することになったので、帰社１か月で急遽代役として某所に。それが今の常駐先ですが、去年の１２月中からなので、ちょうど１年が過ぎたところです。
最初に書いた、時間がやたらと拘束される職場と同じ会社なのですが、部署が違うだけでこんなに楽とは！
特に、通勤が楽。自宅の最寄りのJR駅から職場最寄りのJR駅で、ほとんどドア・ツゥー・ドア。片道２０００歩以内。毎日ほぼ定時。
そりゃ、趣味のプログラミングでも復活させようか！って気持ちにもなるはずです。
やたらと、通勤距離が長かった職場のころに比べると、今は休みの日のお買い物に車を使うくらいなので、１か月に３０００円くらいガソリンを入れる(満タン入れない)で充分ですからね。ガソリン代が高いとか安い以前の問題です。(^_^;)
さて、次のリリースは、VB De FilMtnです。
実はもう準備していますが、そろそろ寝るので。(^^ゞ
2016/12/14
Info-Zip製 UnZip32.DLLをbzip2対応でビルドする
Info-Zip製 UnZip32.DLLの最新のバージョンは、6.10bのようです。
ドキュメントを眺めてみると、deflate64メソッド以外にも、bzip2メソッドの展開のサポートも追加されているようです。
前回のブログのエントリで、偽UnZip32.DLLもバージョンアップするよ。って書いてしまったので、Info-Zip製 UnZip32.DLLが手元でビルドできるかを確認してみました。
というのは、
ワーニングがチョットばかし出ますが、致命的ではないので気にしない気にしない。(^_^;)
bzip2メソッドでzipしたファイルを同ディレクトリにコピーします。
コマンドプロンプトで、同ディレクトリにカレントディレクトリに移動して、
コマンドプロンプトで、そのディレクトリに移動して、
ドキュメントを眺めてみると、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をダウンロードします。ビルド環境の構築方法
- Microsoft Visual Studio Community 2015 Update 3をインストールする。
- unzip610b.zipを作業ディレクトリに展開する。
- bzip2-1.0.6.tar.gzを作業ディレクトリに展開する。
- 3.を展開して得られたソース一式を、2.で展開したunzipのソース配下のbzip2配下にコピーする。
- unzip610b\windll\vc8\unzip32.sln をVisual Studio Community 2015で読み込ませる。vc8用のプロジェクトなので、プロジェクトのアップデートを行う。
- ソリューション エクスプローラから、プロジェクト「c_dll_ex」と「unz32dll」以外を削除する。(今回は不要だから)
- スタートアップ プロジェクトは「c_dll_ex」に設定する。
- ソリューションにunzip610b\win32\vc8\bz2lib.vcproj プロジェクトをソリューションに追加する。変換されてソリューションに追加される。
- global.h内の「# include "bzlib.h"」を「# include "bzip2/bzlib.h」に修正する。
- ソリューションのプロパティ＞共通プロパティ＞プロジェクトの依存関係 のプロジェクト「unz32dll」の依存先をbz2libにする。
- unz32dll プロパティ＞構成プロパティ＞C/C++＞プリプロセッサ＞プリプロセッサの定義に「USE_BZIP2」を追加する。
- unz32dll プロパティ＞構成プロパティ＞リンカー＞入力 の追加の依存ファイルに、「bz2lib」でビルドされるbzip2.libをフルパスで追加する。(マクロを使うと簡単に表記できるかもね。)
- ソリューションのリビルドを行い、ビルドをする。
ワーニングがチョットばかし出ますが、致命的ではないので気にしない気にしない。(^_^;)
bzip2メソッドでzipしたファイルを同ディレクトリにコピーします。
コマンドプロンプトで、同ディレクトリにカレントディレクトリに移動して、
uzexampl.exe bzip_method.zipみたいにすると、展開できるようにビルドできたことが確認できます。
コマンドプロンプトで、そのディレクトリに移動して、
2016/12/12
偽Zip32J.DLL新バージョンリリース
偽Zip32J.DLL Version 0.37.0.10(10)をへろぱ的サイトにてリリースしました。
前のバージョンから新しい機能はありません。
この通り、サイトを移動したので添付のドキュメントを修正したのと、Visual Studio 2015 C/C++でリビルドしなおしただけです。
いやぁ、前のバージョンから６年以上経っていますよ。今回、６年ぶりくらいに自分の書いたソースを見直したのですが、...中々ですね！(^^ゞ
というか、今書くとしてもきっと同じコードになるはず。
進歩がないというか...。
自分の書いたコードなのに、ちょっと感心したのが、丁寧さと規模。今、これだけの規模のコードを一から書けるのか？今は、読書がメインの趣味になっているので、プライベートでこんなにコードに向かい合えるのか？
そんなことも思いました。
偽UnZip32.DLLも近日中にアップデートする予定です。
前のバージョンから新しい機能はありません。
この通り、サイトを移動したので添付のドキュメントを修正したのと、Visual Studio 2015 C/C++でリビルドしなおしただけです。
いやぁ、前のバージョンから６年以上経っていますよ。今回、６年ぶりくらいに自分の書いたソースを見直したのですが、...中々ですね！(^^ゞ
というか、今書くとしてもきっと同じコードになるはず。
進歩がないというか...。
自分の書いたコードなのに、ちょっと感心したのが、丁寧さと規模。今、これだけの規模のコードを一から書けるのか？今は、読書がメインの趣味になっているので、プライベートでこんなにコードに向かい合えるのか？
そんなことも思いました。
偽UnZip32.DLLも近日中にアップデートする予定です。
2016/10/18
標準出力を取り込む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ディレクトリのアリエスだそうです。
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みたいな感じです。
2016/10/08
MFC CFileDialogでカスタマイズ・ダイアログが使えない？
そんなことはない。
古いVisual Studioのプロジェクトを保守しようとして、ディレクトリの選択ダイアログの代わりに、カスタマイズ・ダイアログが使われているパターンに出くわしたとします。
古いプロジェクトを、今時のVisual Studioで更新して、実行してみるとカスタマイズが出来ないって事を経験したことがありませんか？
ディレクトリの選択ダイアログに書き直してしまいたいけど、そこまで既存のソースを弄りたくないとか、弄れる時間がないとか、弄れる権限がないとか...。
MSDNのCFileDialogの説明によると、
とあります。
この文章から読み取りにくい情報ではありますが、つまり、コンストラクタのbVistaStyleをFALSEでコンストラクタを呼び出すようにすれば、カスタマイズ・ダイアログは、ちゃんと表示されるはずです。
という情報が、なかなかネットになかったので。
MFCをやっている人の絶対数が減ってるだろうし、インターネットで自分から情報を公開しようとする人も少なくなっているようだし、結局はMSDNなどの一次情報から自分のやりたい事を紐解く作業が必要になってくるのかな、面倒くさい...。
古いVisual Studioのプロジェクトを保守しようとして、ディレクトリの選択ダイアログの代わりに、カスタマイズ・ダイアログが使われているパターンに出くわしたとします。
古いプロジェクトを、今時のVisual Studioで更新して、実行してみるとカスタマイズが出来ないって事を経験したことがありませんか？
ディレクトリの選択ダイアログに書き直してしまいたいけど、そこまで既存のソースを弄りたくないとか、弄れる時間がないとか、弄れる権限がないとか...。
MSDNのCFileDialogの説明によると、
Windows Vista の CFileDialog の外観と機能は、以前のバージョンの Windows から変更されています。 既定の CFileDialog は、コードを変更しなくても、プログラムが Windows Vista でコンパイルおよび実行されると、自動的に新しい Windows Vista スタイルを使用するようになっています。 この自動更新機能を手動でオーバーライドする場合は、コンストラクターで bVistaStyle パラメーターを使用します。 この自動更新機能が適用されないのは、カスタマイズしたダイアログ ボックスです。 カスタマイズしたダイアログ ボックスは、新しいスタイルに変換されません。
とあります。
この文章から読み取りにくい情報ではありますが、つまり、コンストラクタのbVistaStyleをFALSEでコンストラクタを呼び出すようにすれば、カスタマイズ・ダイアログは、ちゃんと表示されるはずです。
という情報が、なかなかネットになかったので。
MFCをやっている人の絶対数が減ってるだろうし、インターネットで自分から情報を公開しようとする人も少なくなっているようだし、結局はMSDNなどの一次情報から自分のやりたい事を紐解く作業が必要になってくるのかな、面倒くさい...。
2016/09/14
.NET Framework 4.6.2 でPathTooLongExceptionが回避できるのか？
というニュースをあちこちで見て、『ほぅ～、どれどれ』と、プログラムを書いてみるものの、全然思い通りにならない。
マジで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では、グループ・ポリシー・エディタって無いじゃん？と思ったら、先に紹介したサイトでも同じようなコメントが付いていて、レジストリエディタで値をいじると良いよ、的アドバイスがあります。
この件も、試行錯誤の上、そうしないと動かなかったって事なんですけど、「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の方が良く無くない？とか思いました。
2016/07/21
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ディレクトリに移動します。
これで、.NETで使用できるDLLが作成されます。
.NETでの参照設定には、上記DLLとIKVM.OpenJDK.Core.dllを加えます。
C#のソースは、こんな感じ。
Javaのクラスが所々混じって変な感じです。
getLastModifiedメソッドが返すjava.util.Dateは、年が1900年ほど足りないようです...。
java.util.Date.getMonthメソッドは、0始まりなので、DateTimeとは、1ズレるんですよね、javaってなんでこんな仕様なんだろう？って思うことがしばしば...。
出力は、こんな感じ。
わざわざこんな事をしなくても、WindowsにはUnLHA32.DLLがあるじゃないか！
ごもっともです。
ただ、IKVM経由でjLHAを使うってことは、64bit版アプリを簡単に作れるってことなんですよね？！
暑いから試してないけど。
でも、.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版アプリを簡単に作れるってことなんですよね？！
暑いから試してないけど。
(^_^;)
2016/07/02
車輪の再発明について思ったこと
プログラマにとって、車輪の再発明は駄目なことではないし、無駄でもない。
けど、その車輪が使えるものなら、使わないと損だよね。
車輪(ライブラリとかソリューション)の再発明をしてしまう理由とは、
1. と3. はどんどんやるべきだと思う。2. は、できるだけ避けたい。そのためには、事前の技術調査が必要なんだと思う。
4. なんだけど、再利用が制限されるライセンスって困る。個人的には、MITライセンス的なものが嬉しい。
車輪の再発明が悪でないと思うのは、多様性がある方が色々いいんじゃないかと思うんですよ。
例えば、なんたらFileUploadの脆弱性で、そのライブラリを使っているプロダクトが軒並み脆弱性の影響を受ける、とか...。
H・G・ウェルズの宇宙戦争の火星人のよう。
けど、その車輪が使えるものなら、使わないと損だよね。
車輪(ライブラリとかソリューション)の再発明をしてしまう理由とは、
- 車輪を自分で作りたかったから。
- その車輪の存在を知らなかった。
- その車輪に欠陥が多くて使えないから。
- ライセンスで使えないから。
1. と3. はどんどんやるべきだと思う。2. は、できるだけ避けたい。そのためには、事前の技術調査が必要なんだと思う。
4. なんだけど、再利用が制限されるライセンスって困る。個人的には、MITライセンス的なものが嬉しい。
車輪の再発明が悪でないと思うのは、多様性がある方が色々いいんじゃないかと思うんですよ。
例えば、なんたらFileUploadの脆弱性で、そのライブラリを使っているプロダクトが軒並み脆弱性の影響を受ける、とか...。
H・G・ウェルズの宇宙戦争の火星人のよう。
2016/06/23
Lha for Win32 Console作成開始
とりあえず、リストの出力は、Win32っぽくなったでしょ？
UnLha32.DLLが開発を休止して久しいですが、如何お過ごしでしょうか？＞関係者の方々
(^_^;)通勤にマイカーで片道20kmの常駐先から、JRで10分+徒歩5分の常駐先に移動となったので、ガソリン代貧乏から脱出することができて半年...。
就業時間も、ほぼ定時で帰れるのですが、夏の消防団小型ポンプ操法大会に向けての練習があり、なかなか趣味のプログラミングが捗りません...。
64bit版Windowsが16bitアプリのサポートをしなくなったので、MS-DOSコマンドとしてのLHA.EXEが動かなくなりました。
もう少し待っていれば、Ubuntuのコンソールアプリとして、Lha for UNIXなLhaが動くようになるのかもしれないですが、ちゃんとUnLha32.DLL互換なLzh書庫が作れるWin32コンソールアプリが欲しかったんだよぅ～！！
自分の為のアプリで、公開する予定はない。多分しない。そもそも、完成がいつになるか...。
2016/03/29
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!
新山(へろぱ)のホームページが、ホスティングしていたプロバイダーの都合で無くなってしまったので、やむなく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!
2016/03/19
車検、むっちゃ掛かった！
2001年式のニュービートル、今年で15年目。
ついさっき、車検の料金を払ってきたんだけど、むっちゃ高かった。
いや、車検自体の費用はいつもどおりなんだけど、整備費用がむっちゃ高かった。
こんな感じ。
これに、車検費用を含めて、30万円オーバー...。
まぁ、30万円でニュービートルは買えないから仕方が無いんだけど。
でも、クルマの調子は良くなった。
そうそう、新品の頃はこんなにエンジンレスポンス良かった！って思い出したくらい。
ハンドルを切るときに、途中でカクっとする変な感じも無くなっているし。
何よりも、ドアノブ内側の取っ手の取り付け部が折れてブラブラしていたのが、何気に直してくれているし。車内の清掃も完璧に綺麗だし。
これらの分の料金入ってないし。
顧客満足度100%です。素晴らしい！
ついさっき、車検の料金を払ってきたんだけど、むっちゃ高かった。
いや、車検自体の費用はいつもどおりなんだけど、整備費用がむっちゃ高かった。
| 作業内容・部品名名称 | 数量 | 単価 | 金額 | 技術料 |
|---|---|---|---|---|
| エンジンオイル | 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%です。素晴らしい！
登録:
投稿 (Atom)