ソフトウェアに関する不具合、要望、感想 - 1269072321

449：447：2017/04/18(火) 23:51:40 ID:cmU9yd1M0: >>448
document.txt
homepage.url
[folder]
+-xxxx.html
+-xxxx.jpg
+-xxxx.jpg
+-...
+-thumbs.db

みたいな構成の書庫に「*.db;*.lnk;*.url」でフィルタしてたのですが
再現環境を作ろうとサンプルファイルを構築して試行しているうちに
正常動作が確認出来ちゃいました。
何が悪かったのかさっぱり…
お手を煩わせてすみませんでした
450：通りすがりの人：2017/04/30(日) 21:58:13 ID:bF7yl/uY0: 公式にて7-zipが17.00 betaを公開しました
451：x@rgs★：2017/04/30(日) 22:40:19 ID:???0: >>450

ご報告ありがとうございます。
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.17.00.00.01を公開しましたのでご確認ください。
ビルド出来るように修正しただけですのでご注意くださいませ。
452：通りすがりの人：2017/05/01(月) 06:16:03 ID:bF7yl/uY0: 7-ZIP17.00βをインストールした状態で、gui4reces.exeを同じフォルダに配置した7z.dll対応版7-zip64.dll(888KB/16.4.0.1)を使用すると
動作しました。
17.00の7z.dll対応版7-zip64.dllはファイルが破損しますね。
453：通りすがりの人：2017/05/02(火) 03:46:46 ID:lw13yNV60: gui4reces 0.0.1.7
reces.exe 0.00.00.33

処理後削除（ゴミ箱）が指定されている再圧縮の一括処理中に
他の作業の影響でHDDの空き容量がなくなってしまい空き容量不足エラーが連発する状況に陥ったのですが
処理が完了する前にゴミ箱を消すなどしてHDDの空き容量を確保したところ、
エラーになった再圧縮されてない書庫までゴミ箱に送られてしまう挙動がありました。
気になったので一応報告しておきます。
454：x@rgs★：2017/05/07(日) 17:05:43 ID:???0: >>452
>>453

ご報告ありがとうございます。
お返事が遅れて申し訳ないです。
修正版公開までしばらくお待ちくださいませ。
455：x@rgs★：2017/05/14(日) 16:00:43 ID:???0: >>452-453

遅くなりましたが、recesの修正版を公開致しましたのでご確認ください。
456：通りすがりの人：2017/05/20(土) 20:10:38 ID:MhGBhFNc0: 人柱版は32bit版のようですが、x64版の予定はありますか？
457：x@rgs★：2017/05/20(土) 20:47:47 ID:???0: >>456

投稿ありがとうございます。
x64版を同梱した書庫に差し替えました。
ご確認くださいませ。
458：通りすがりの人：2017/05/20(土) 23:14:35 ID:.x9BOuE60: 人柱版x64版recesと7z.dll対応版7-zip64.dllVer.17.00.00.01をgui～のフォルダにぶちこんで
dllのverが17～であることを確認した上で使用してみましたが、正常動作しました
459：x@rgs★：2017/05/21(日) 16:55:50 ID:???0: >>458

動作報告ありがとうございます。
しばらく様子を見てから正式にバージョンアップします。
460：kiyohiro：2017/05/21(日) 17:12:16 ID:ucdEBbx.0: どうもお世話になってます
実装していただいた
/qe
なんですが
複数ドロップして一番最後がエラーの場合一時停止しないですが仕様ですか？
(リネームして順番を入れ替え一番最初、真ん中、単体は止まりました)
出来ればエラー確認のため一時停止して欲しいのですが
よろしくお願いします

reces000r33_Debug170514.zip
/c2 /ct /NF /qe /{"D:\Software\reces\cfg\resize.cfg"
Winxp環境
で試しました
461：x@rgs★：2017/05/21(日) 22:56:02 ID:???0: >>460

いつもお世話になります。
>複数ドロップして一番最後がエラーの場合一時停止しないですが仕様ですか？
人柱版では仕様です。
処理を続行するか否かのオプションであるので、最後の処理で一時停止するのは適当でないと考えこのような動作となりました。
しかし、最後だけ停止しないのは何とも使い辛い仕様なので、修正しますね。
462：kiyohiro：2017/05/28(日) 13:26:04 ID:ucdEBbx.0: >>461
修正ありがとうございます
reces 0.00r33aで最後の処理で一時停止するのを確認しました
463：kiyohiro：2017/06/18(日) 02:05:10 ID:ucdEBbx.0: どうもお世話になってます
先日メールしました
recesでエラーがでて圧縮出来なかったのでメールしましたの件

> 画像を確認する限り、プログレスバーのファイル名表示が原因のようです。
> 「/ni」でプログレスバーを非表示にすると処理されますか？

/niを付けると.zipと.7zどちらも正常に圧縮出来ました

> 他の環境(OS)でも発生しますか？
Win10環境でも同様に発生しました

よろしくお願いします
464：x@rgs★：2017/06/18(日) 11:30:59 ID:???0: >>463

報告ありがとうございます。
新規ダウンロードした状態で圧縮しても正常に動作するため、プロファイル内に原因がありそうです。
スクリーンショットを見る限り、Visual Historyあたりが怪しいのですが、ディレクトリごと送ってもらえませんか。
#手元で色々と試しましたが、再現出来ませんでした。
容量が大きいようであれば、dir /b visualHistory>logなりでファイル名だけでも構いません。
よろしくお願いします。
465：kiyohiro：2017/06/18(日) 12:29:05 ID:ucdEBbx.0: >>464
サイズが大きいので
以前教えていただいたファイル共有サイトに送ってみました
サイトからの連絡は行きましたか？
visualHistoryの部分だけで再現出来たのでそこだけ送ってます
466：x@rgs★：2017/06/18(日) 21:01:40 ID:???0: >>465

アップロードありがとうございました。
確認したところ、ファイル名に「%」を含む場合、フォーマット指定子と見なされ、それが「%n」である場合、強制終了してしまうようです。
この不具合を修正した人柱版を公開しましたのでご確認くださいませ。
467：kiyohiro：2017/06/18(日) 21:36:30 ID:ucdEBbx.0: >>466
修正ありがとうございます
reces000r33_Debug170618.zip
で問題無く圧縮(.zip&.7z)出来ました
win10&winxp環境

それと
Win10環境をお持ちならひとつ教えていただきたいのですが
recesのコマンドプロンプト画面を広げたくて
WinXpと同じ方法(タイトルバーをクリックしてプロパティをいじる)を
試したのですが1回広げてもすぐ元の大きさに戻ってしまいます
(先日やっと適用したのですが多分Windows 10 Creators Update適用後からだと)
これはこちらの環境だけなんでしょうか？
また他の設定方法をご存知なら教えてもらえないでしょうか？
468：x@rgs★：2017/06/18(日) 22:59:16 ID:???0: >>467

報告ありがとうございます。
また何かあればよろしくお願いします。

コマンドプロンプトについてはちょっと分かりません。すみません。
469：kiyohiro：2017/06/19(月) 12:42:45 ID:ucdEBbx.0: >>468
コマンドプロンプトの件はウィンドウズのバグみたいですね
同じようなの現象が起きてる方の記事を見つけました
ttp://blog.inasoft.org/article/179526406.html
470：通りすがりの人：2017/08/28(月) 23:14:54 ID:XOgW52bs0: 7-Zip 17.01 beta　が公開されましたのでお知らせします
471：通りすがりの人：2017/08/30(水) 21:55:07 ID:PAteqZM20: 7-Zip 17.01 beta対応版の更新確認しました。
問題なく動作しています。
472：x@rgs★：2017/08/30(水) 23:48:52 ID:???0: >>470-471

ご報告ありがとうございます。
なにか不具合・要望などございましたら、お気軽に投稿くださいませ。
473：kiyohiro：2017/09/15(金) 13:38:55 ID:sgNgRABQ0: どうもお世話になってます
使い方を教えてもらえないでしょうか
7zのパスワード付7z自己解凍書庫が作れなくて他も試してみたのですが
/mclzhsfx
/mc7zsfx
は作成出来ました
パスワード付7z自己解凍書庫とヘッダ暗号化書庫7z自己解凍書庫
なんですが
/mc7zpwsfx
/mc7zhesfx
では作成できませんでした他に何かオプションが必要なんでしょうか？
あとzipの自己解凍書庫は無いのでしょうか？

それとCabの圧縮なんですが
/mscab32:Cab -a D:\Test\foo.cab
にドロップ
だとファイル単体の圧縮がしたかったのですが
圧縮元のファイルのパスでフォルダが作成されてしまいます
フォルダ入りファイルをフォルダごとだと圧縮出来ませんでした
出来ればファイル名とか出力パスは通常圧縮のzipみたいに指定なしで
ファイル名で同フォルダに出力がありがたいのですが
あと確認用に/q0をつけたのですが止まりませんでした

よろしくお願いします
474：kiyohiro：2017/09/15(金) 19:36:53 ID:sgNgRABQ0: >> 473
追記
/mclzhsfx
で作ったものなんですが自己解凍出来ないみたいです
以下のダイアログ表示
LZH 自己解凍書庫 V2.13.w16.0008
'D:\TEST\TEST\てすと~3.EXE' ヘッダーの内容が不正
475：x@rgs★：2017/09/16(土) 11:21:26 ID:???0: >>473-474

いつもお世話になっております。

>パスワード付7z自己解凍書庫とヘッダ暗号化書庫7z自己解凍書庫
作成には「7z.sfx」を「7-zip32.dll」と同じ階層に用意する必要があります。
7-Zipをインストールしたディレクトリにありますので、コピーしてください。

>Cabの圧縮なんですが
cab32.dllで圧縮する場合、圧縮対象の基準ディレクトリを指定する必要があります。
例えば、C:\foo\bar\baz\qux.txtでqux.txtのみを圧縮したい場合、
/mscab32:Cab -a qux.cab C:\foo\bar\baz\ qux.txt
baz\qux.txtとディレクトリ付きで圧縮したい場合、
/mscab32:Cab -a qux.cab C:\foo\bar\ baz\qux.txt
とします。基準ディレクトリは必ず「\」で終わらせる必要があります。

>あと確認用に/q0をつけたのですが止まりませんでした
「/ms」オプションは以降を全て書庫ライブラリに渡すため、reces独自のオプションを使用する場合は、「/ms」より前に指定する必要があります。

>/mclzhsfx
申し訳ないです。オプション指定のミスです。
ArcUnlha32.cpp内の「-jw1」を「-gw3」に変更すると動作します。
しばらく開発環境が手元にないため、修正版の公開はお時間をいただきます。
ほかに不具合・要望があればご連絡くださいませ。
476：x@rgs★：2017/09/16(土) 11:27:57 ID:???0: >>475

追記です。
zip形式の自己解凍書庫には対応しておりません。
#オリジナルの7-Zipでも作成できません。
477：kiyohiro：2017/09/16(土) 13:24:24 ID:sgNgRABQ0: >>476
回答ありがとうございます
パスワード付7z自己解凍書庫とヘッダ暗号化書庫7z自己解凍書庫
も
Cab圧縮も
/q0 /mscab32:Cab -a I:\テスト\test.cab D:\Software\ reces\てすと.txt
/q0 /mscab32:Cab -a I:\テスト\test.cab D:\Software\reces\ てすと.txt
で
質問どおり圧縮できました
ただ、
Cab圧縮なんですが上記の様にrecesのフォルダ内のファイルしか圧縮出来ないです
/q0 /mscab32:Cab -a I:\テスト\test.cab D:\Test\ てすと.txt
の様に他のフォルダの場合アプリケーションエラーが出て落ちてしまいます
なにが悪いのでしょうか

>/mclzhsfx
>しばらく開発環境が手元にないため、修正版の公開はお時間をいただきます。
7z自己解凍書庫のついでにてすとしただけなので何時でもかまいません

> zip形式の自己解凍書庫には対応しておりません。
わかりました
友人リクエストでzip形式の自己解凍書庫送ってくれと言われたので
初めて自己解凍書庫を試したのですがrecesにzip形式がなかったもので。
Explzhで作れました
Cab圧縮も他の所のリクエストでしたメール送るなら圧縮率のいい7zに統一してほしいものです
ちなみに7zの圧縮率の変更は7-zipCMD.txtを見ると[0|1|3|5|7|9]になってますが
7zのrecesの/lオプションも奇数だけですか？
478：kiyohiro：2017/09/16(土) 21:22:42 ID:sgNgRABQ0: >>477
Cab圧縮のアプリケーションエラーの件原因がわかりました
recesのフォルダ内とか関係なかったです
適当に色んなファイルで試してたので
たまたまreces内のReadme.txtで試したのがokでフォルダ外で試したファイルがダメでした
てすと.txtで中身が
テスト
をテキストエディタで作ったものなんですが(Shift-JIS CR+LFです)
なぜがアプリケーションエラーが出るみたいです
中身を
テストです
に変えると圧縮出来、再度
テスト
にするとアプリケーションエラーが出ました
他のファイルも大丈夫でした
なんか変な動作ですがこちらの環境だけですかね
479：x@rgs★：2017/09/17(日) 00:41:00 ID:???0: >>477-478

>パスワード付7z自己解凍書庫とヘッダ暗号化書庫7z自己解凍書庫
>も
>Cab圧縮も
無事動作したようで何よりです。

>ちなみに7zの圧縮率の変更は7-zipCMD.txtを見ると[0|1|3|5|7|9]になってますが
>7zのrecesの/lオプションも奇数だけですか？
recesの「/l」は続けて指定された数字をライブラリに投げるだけですので、奇数偶数問いません。

>Cab圧縮のアプリケーションエラーの件
対象ファイルが7バイトもしくは8バイトの場合、アプリケーションエラーが発生するようです。
追加で「-mz」を指定するとエラーなく処理されました。
#/q0 /mscab32:Cab -a -mz I:\テスト\test.cab D:\Test\ てすと.txt
#でお試しくださいませ。
480：kiyohiro：2017/09/17(日) 06:37:40 ID:sgNgRABQ0: >>479
回答ありがとうございます
-mz追加で圧縮出来ました
これで全て解決しましたありがとうございました

それとすでに記入があったらスイマセンが
Cab圧縮や自己解凍書庫とかはめったに無く忘れる可能性もあるので
お手数ですが何時でもかまいませんので次回バージョンアップ時にも
今回の質問をReadme.txtに例として追加していただけると助かります
よろしくお願いします
481：x@rgs★：2017/09/18(月) 00:24:23 ID:???0: >>480

報告ありがとうございます。
私も忘れそうなのでReadme.txtに追記しておきます。

ほかに不具合・要望がありましたら是非々々お知らせくださいませ。
482：x@rgs★：2017/10/26(木) 22:43:06 ID:???0: ttp://jbbs.shitaraba.net/bbs/read.cgi/computer/42633/1272626885/15-16

のつづき。

とりあえず、要望のあった機能の実装だけはしてみましたのでご確認ください。
マルチモニター環境がないため、動作は確認できていませんのでご注意ください。

ttp://www16.atpages.jp/rayna/Tascher/debug.html

ほかにマルチモニター絡みでの要望や、その他ご意見ありましたら、是非是非投稿をお願いします。
483：razgriz13：2017/10/29(日) 19:42:06 ID:hlTGz1T.0: >> 482

早速のご対応、誠にありがとうございます。

早速、試してみました。

・・・・・が、まるで機能しません。
アプリは起動します。（初回起動時、OSのアプリ保護が出ましたが。）

キーボードショーカットからの呼び出しや、システムトレイのアイコンから設定
画面を開いたり、、、何かすると、強制終了します（アプリが）。

OSのイベントログでもWindows Error Reportingが挙がってきます。
～～～
障害バケット 120863262764、種類 4
イベント名: APPCRASH
応答: 使用不可
Cab ID: 0

問題の署名:
P1: Tascher.exe
P2: 1.6.3.0
P3: 59f589d3
P4: Tascher.exe
P5: 1.6.3.0
P6: 59f589d3
P7: c000041d
P8: 0000000000005157
P9:
P10:
～～～～

使っているOSは、
　Windows10 ６４ビット　Pro　
　バージョン　１７０３　
　ビルド　１５０６３．６７４

デバッグに向けて何か必要な情報があれば、コメント願います。
484：x@rgs★：2017/10/29(日) 21:31:59 ID:???0: >>483

返信ありがとうございます。
何度も申し訳ないです。再度修正版に差し替えましたのでご確認ください。
485：razgriz13：2017/11/08(水) 21:00:28 ID:hlTGz1T.0: >>484

返信遅くなり、申し訳ありません。
（勝手に、新規投稿は、メール通知されると思っていました。。）

動作確認の結果、プライマリー側のモニター上では、通常通り
期待した動きをします。

ただし、セカンダリー側のモニター上では、異常停止します。
メニューがポップアップしないと思ったら・・・フッとシステムトレイから
消えて無くなります。
OSイベントログでは、前回同様のメッセージが記録されます。

デバッグログなど、何か解析に役立つ情報が必要でしたら
ご連絡ください。

よろしくお願いします。
486：x@rgs★：2017/11/10(金) 01:34:25 ID:???0: >>485

返信ありがとうございます。
投稿のメール通知は下記URLより可能です。
ttp://jbbs.shitaraba.net/bbs/notice_mail.cgi/computer/42633/

動作確認何度も申し訳ありません。
仮想PC(Win7)では動作したので、てっきり修正されたものとばかり思っておりました。
Win10ではタスクバーが全てのモニタに表示可能だったりと、仕様が異なるので今のところ原因は分かりません。

下記はマルチモニタ対応のために追記した処理の一部を抜粋したものです。
カーソルをプライマリおよびセカンダリに置いて起動しても、正常に動作するか確認をお願いできませんか。
ttp://www16.atpages.jp/rayna/Tascher/monchk.zip
よろしくお願いします。
487：razgriz13：2017/11/19(日) 19:22:45 ID:hlTGz1T.0: >>486

ご連絡、並びにご対応いただきまして、ありがとうございます。
また、こちらからのご連絡ができておらず、申し訳ございません。

１８日版の修正モジュールにて、当方の環境でも動作致しました。
（前回までのような異常終了の症状は、再現しませんでした。）

しばらくこのまま、使ってみたいと思います。
進展ありましたら、また書き込み致します。
488：通りすがりの人：2018/01/11(木) 01:00:39 ID:SIodCj0A0: 7-Zip 18.00 betaが公開されました
489：x@rgs★：2018/01/11(木) 06:13:46 ID:???0: >>488

ご報告ありがとうございます。
近日中に公開予定です。
490：通りすがりの人：2018/01/13(土) 18:41:09 ID:odSgo6dA0: 7z18000001_ungarbled.zip
gui4reces + 7z.dll対応版7-zip64.dllで動作しました
491：x@rgs★：2018/01/14(日) 00:21:32 ID:???0: >>490

ご報告ありがとうございます。
とくに問題はないようで何よりです。
492：通りすがりの人：2018/01/30(火) 15:57:06 ID:zKDatD9s0: 7-Zip 18.01
正式版がReleaseされました
493：x@rgs★：2018/01/30(火) 20:57:17 ID:???0: >>492

ご報告ありがとうございます。
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.18.01.00.01を公開しましたのでご確認ください。
494：通りすがりの人：2018/01/30(火) 23:01:38 ID:nwipGVeA0: Ver.18.01.00.01
gui4reces + 7z.dll対応版7-zip64.dll
動作しました
495：x@rgs★：2018/01/31(水) 21:22:08 ID:???0: >>494

ご報告ありがとうございます。
問題はとくにないようで何よりです。
496：通りすがりの人：2018/05/01(火) 17:54:41 ID:5PQzfMrI0: 7-Zip 18.05
出ました
497：通りすがりの人：2018/05/01(火) 19:29:49 ID:5PQzfMrI0: 7-Zip 18.05、Bug関連なのか、引っ込められました。
しばらく様子見です
498：通りすがりの人：2018/05/01(火) 19:31:08 ID:5PQzfMrI0: と思ったらやっぱり公開されてました。すみません・・・
499：x@rgs★：2018/05/02(水) 00:30:53 ID:???0: >>496-498

ご報告ありがとうございます。
一部仕様変更に対応するため、公開まで少々お時間をいただきます。
しばらくお待ちくださいませ。
500：通りすがりの人：2018/05/08(火) 07:43:38 ID:kSvvbG6E0: 18.05更新、7z対応版で特に問題無く動作してます
501：x@rgs★：2018/05/08(火) 22:03:24 ID:???0: >>500

ご報告ありがとうございます。
問題はとくにないようで何よりです。
502：須藤幸一：2018/07/04(水) 21:11:50 ID:vdkKBWX.0: 【OS】Windows 8.1/ 10
【ソフト名】7-zip32.dll/7z.dll対応版
【バージョン】Ver.18.05.00.01
【症状】既存の同名ファイルがあるディレクトリにCHM等を解凍するとエラー
【再現手順】
コマンド例: x D:\Hoge.chm -oD:\Test\ -scsUTF-8
・空の指定ディレクトリにCHMファイルを解凍した場合は正常。
・ディレクトリ内に同名ファイルが一つでもあると解凍処理の途中でエラー。
例外 #C0000005 (access violation at ～: read of address 0x00000000)
・上書確認が出る前にエラーになっているようです。
・これによって呼び出し側アプリケーションも異常終了してしまいます。
・CHM 以外に、MSI を解凍した場合にもエラーになります。
・すべての形式は試していませんが、ZIP、7z、RAR、ISO などでは問題ありません。

アーカイバDLLは、NyanFi という2画面ファイラーで利用させていただいてますが、
解凍のみを行うテストプログラムを作って試しても、エラーが発生します。
503：x@rgs★：2018/07/05(木) 22:53:38 ID:???0: >>502

ご報告ありがとうございます。
不具合を確認しました。

しばらく開発環境が手元にないため、
修正版公開までしばらくお待ちください。
504：kiyohiro：2018/07/07(土) 12:40:03 ID:/CQ6kTUM0: どうもお世話になってます
解凍や書庫のテストでErrorメッセージが出るのですがこれは何のエラーなんでしょうか？
一応、解凍は問題無く出来てます
また、Explzhの書庫のテストではエラーは出なかったです

試したソフト
リサイズ超簡単！Pro v4.07 ttp://my.reset.jp/~triton/ (Vectorからのダウンロード)
そのままではwinxpで自己解凍出来ないけど中身はwinxpで使えるのでrecesで解凍しました

Errorメッセージは以下です
よろしくお願いします

7-Zip (a) 18.05 + ungarbled patch (x86) : Copyright (c) 1999-2018 Igor Pavlov : 2018-04-30

Testing archive:
D:\Test\RCKP407.exe

ERRORS:
Can't open volume: untitled.cab

--
Path = D:\Test\RCKP407.exe
Type = Cab
ERROR = Can't open volume: untitled.cab
Offset = 844795
Physical Size = 54734
Method = LZX:21
Blocks = 1
Volumes = 1
Volume Index = 0
ID = 12345

Archives with Errors: 1

Open Errors: 1
505：x@rgs★：2018/07/16(月) 22:29:01 ID:???0: >>502

修正版を公開しました。
動作のご確認をお願いいたします。

>>504
「untitled.cab」が含まれていると内部に情報があるものの、
データが壊れているためか、存在しないためか開くことができないようです。
Cab書庫ファイル側の問題と思われます。
506：須藤幸一：2018/07/17(火) 10:19:52 ID:GR8/BufM0: 修正版にて、上書き解凍時の正常動作を確認しました。
どうもありがとうございます。
7z.dll対応版はCHMの内容確認などもできるので重宝しています。
507：通りすがりの人：2018/12/31(月) 12:02:02 ID:MuvB.IPM0: 7-Zip 18.06
公開されました
508：x@rgs★：2018/12/31(月) 18:47:30 ID:???0: >>507

ご報告ありがとうございます。
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.18.06.00.01を公開しましたのでご確認ください。
509：通りすがりの人：2019/01/01(火) 20:35:03 ID:MuvB.IPM0: 7zip対応版、7-ZIP64.DLL ver.18.06.00.01
特に問題無く動作しました
510：通りすがりの人：2019/02/07(木) 16:26:18 ID:QQde9r0A0: 不具合なのかよく判らないですが、気になったので。
【OS】[Windows 10]
【ソフト名】[gui4reces]
【バージョン】[Ver.0.0.1.8]
【症状】[rarのpart書庫を解凍後、処理後削除がpart1ファイルのみ適応される]
【再現手順】
1.「処理後削除＞完全削除にチェック]
2.「rarのpartファイルのpart1を追加し解凍]
3.「マルチボリューム書庫解凍後part1のみ削除され、残りのpartが残る]
何かしら対策を見逃していた場合申し訳ないです
511：x@rgs★：2019/02/08(金) 02:31:40 ID:???0: >>510

ご報告ありがとうございました。
不具合確認いたしました。
7zのような「foo.7z.001」形式なら削除出来ていたのですが、
rarの「foo.part1.rar」形式への対応が出来ていませんでした。

しばらく開発環境が手元にないため、
修正版公開までしばらくお待ちください。
よろしくお願いいたします。
512：x@rgs★：2019/02/17(日) 11:10:07 ID:???0: >>510

お待たせいたしました。
修正版を公開しましたので、ご確認のほどよろしくお願いいたします。
ほかに不具合や要望等ありましたらお気軽にご投稿ください。
513：通りすがりの人：2019/02/18(月) 21:00:54 ID:QQde9r0A0: >>512
確認しました。
part~及び.r00 両形式とも処理後削除されました。
対応有難うございます。
514：通りすがりの人：2019/02/24(日) 14:58:59 ID:B/DF9u7g0: 7-Zip 19.00が公開されているようです。
515：x@rgs★：2019/02/24(日) 21:08:03 ID:???0: >>514

ご報告ありがとうございます。
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.19.00.00.01を公開していますのでご確認ください。
516：通りすがりの人：2019/02/24(日) 21:32:30 ID:B/DF9u7g0: 　ありがとうございます。
　正常に動作することを確認しました。
517：通りすがりの人：2019/03/03(日) 17:53:31 ID:3m.NQLuY0: 【OS】[Windows 10 Pro 1809 x64]
【ソフト名】[gui4reces]
【バージョン】[Ver.0.0.1.8]
【症状】[7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.19.00.00.01 を導入すると再圧縮ができない]
【再現手順】
1. 7-zip 19.0(x64)をインストーラでインストール
2. 文字化け対策版7z.dllを7-zipのインストールディレクトリにコピー（上書き）
3. 文字化け対策版7-zip64.dllをgui4recesのインストールディレクトリにコピー（上書き）
4. ファイルをD&Dして再圧縮すると「対応していない圧縮形式かファイルが壊れています。」のエラーが出る
---
ライブラリを読み込んでいます... 7-zip64.dll ver.19.00.00.01
'C:\Users\xxxx\Desktop\7z1900001_ungarbled.zip'を解凍しています...

=> return code 0[0]

7-Zip (a) 19.00 + ungarbled patch (x64) : Copyright (c) 1999-2018 Igor Pavlov : 2018-04-30

Extracting archive:
C:\Users\xxxx\Desktop\7z1900001_ungarbled.zip
--
Path = C:\Users\xxxx\Desktop\7z1900001_ungarbled.zip
Type = zip
Physical Size = 3721350

Everything is Ok

Folders: 2
Files: 9
Size: 8259554
Compressed: 3721350

ライブラリを読み込んでいます...
error: 対応していない圧縮形式かファイルが壊れています。
処理を続行しますか? (Y/N) [Y]:
---
518：517：2019/03/03(日) 17:56:28 ID:3m.NQLuY0: 7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.18.06.00.01 では問題なく再圧縮できます
519：x@rgs★：2019/03/03(日) 19:47:58 ID:???0: >>517-518

ご報告ありがとうございます。
この現象は、7-zip 19.00でSetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32|LOAD_LIBRARY_SEARCH_USER_DIRS)を呼び出すように処理が変更されたことによるものです。
そのため、7-zip32/64.dllがシステムディレクトリに存在しないかつ reces.exe/gui4reces.exeと同じディレクトリに7-zip32/64.dllが存在する場合、
1度目の処理は成功しますが、2度目以降は7-zip32/64.dllの読み込みに失敗してしまいます。
#再圧縮のほか、連続解凍等も同じです。

7-zip32/64.dllをシステムディレクトリに配置し、動作をご確認ください。
よろしくお願いします。
520：517：2019/03/03(日) 23:07:25 ID:3m.NQLuY0: >>519
ありがとうございます。
システムディレクトリに7-zip64.dllを入れることで問題なく動作しました！
521：通りすがりの人：2019/08/17(土) 00:11:13 ID:FzoB9DCw0: 【OS】[Windows 10 1903 64bit]
【ソフト名】[reces 32bit]
【バージョン】[Ver.0.00r34a]
【症状】[/oor 有効時に /d で元ファイルが削除されない]
【再現手順】
[1] test.rar と test.zip を同じフォルダに用意する。
[2] reces.exe /mrzip /oor /d test.rar を実行する。
[3] test_1.zip が作成されるが、元ファイルの test.rar が削除されない。
[4] test.zip が無い状態で[2]を実行すると test.zip が作成され test.rar は削除される。
522：x@rgs★：2019/08/18(日) 05:50:20 ID:???0: >>521

報告ありがとうございます。
不具合を確認いたしました。

修正版公開まで少々お時間をいただきます。
しばらくお待ちくださいませ。
523：x@rgs★：2019/08/18(日) 16:05:23 ID:???0: >>521

お待たせいたしました。
修正版を公開いたしましたので、ご確認のほどよろしくお願いいたします。
524：>>521：2019/08/19(月) 07:18:45 ID:afUr6hAg0: >>523
お疲れ様です。
修正ありがとうございます。
問題なく動作しました！
525：tenteko：2020/01/29(水) 21:27:59 ID:6h5qm12k0: はじめまして。
zipや7z書庫内ファイルを直接読み込める画像ビューワーを作るため、利用させて頂いております。

7-zip32.dll や 7-zip64.dll が通常メモリへの書き出し機能が無いことを知り、途方に暮れていたところ、
こちらの同機能が付いた 7-zip64.dll を偶然知り、とても有難く使わせて頂いております。

ただ、以下の症状が出まして、ちょっと困っております。
対応お願いできますでしょうか。

【OS】[Windows 10 Pro 64bit]
【ソフト名】[7-zip64.dll(7z.dll対応版ではない方)]
【バージョン】[Ver.19.00.00.01]
【症状】[SevenZipExtractMem()で、4,294,967,295バイトを超える書き出しができない]
【再現手順】以下のとおりです。

1.解凍後のサイズが unsigned int32 の上限4,294,967,295バイトを超える書庫ファイル（zipか7z）を用意する。

2.プログラム上で
　　SevenZipExtractMem(NULL, [UTF8のコマンドライン], [書き出し先のバッファへのポインタ], [解凍後の全データサイズ], NULL, NULL, NULL)
　のような感じでバッファへ書き出すようにする。

3.この状態で1.の書庫ファイルを解凍すると、恐らく1.の上限まで書き出したところでプロセスがストップする。

備考：
・SevenZipSetUnicodeMode(TRUE)にしています。
・zipでも7zでも、同じ症状が出ます。
・環境はVS2019、64bitです。
・解凍後のサイズが1.の上限以下（と思われます）だと、正常に解凍できています。
・PCのメモリは32GBです。
526：x@rgs★：2020/01/29(水) 23:22:10 ID:???0: >>525

ご報告ありがとうございます。
不具合確認の上修正いたします。
しばらくお待ちくださいませ。
527：tenteko：2020/01/31(金) 01:17:06 ID:6h5qm12k0: 早速のご返事、ありがとうございます！
対応頂いている最中で申し訳ないのですが、一つ疑問…というか要望があります。

もしかしたら仕様なのかもしれないのですが、SevenZipExtractMem()を実行した際、
コールバック関数（ARCHIVERPROC）に対してメッセージが
ARCEXTRACT_OPEN(3) と ARCEXTRACT_END(2) の２つだけしか送出されておらず、
ARCEXTRACT_BEGIN(0) と ARCEXTRACT_INPROCESS(1) は送出されていないようなのです。
（SevenZip()で解凍した場合は、この４つのメッセージは送出されていました）

ARCEXTRACT_BEGIN(0) と ARCEXTRACT_INPROCESS(1) も送出されるようにして頂けませんでしょうか。
というのは、解凍の途中でどのファイルまで解凍したか知りたいのと、
解凍の途中で解凍を中断したい場合があるためです。
（せめて ARCEXTRACT_BEGIN(0) だけでもあれば助かります）
528：x@rgs★：2020/01/31(金) 07:23:21 ID:???0: >>527

投稿ありがとうございます。
処理中のメッセージも見直してみます。

しばらく手元に開発環境がないため、そこそこお時間いただきます。
申し訳ないです。
529：通りすがり：2020/02/08(土) 04:55:03 ID:64OamMms0: 申し訳ございません、RSSの方の掲示板へ書き込みしてしまってるようでして削除お願いします。
影響するのかはわかりませんが、Ver19等の対応も更新していたということで
www.7-zip.org
7-Zip 20.00 alpha
更新されました。

7-Zipは、LZMA / LZMA2圧縮用の新しいオプションがサポート→bt5およびhc5、
bt4およびhc4マッチファインダーよりも冗長性の高いデータに対してより速く動作します。
最速レベル（-mx1）：256 KBの辞書を持つhc5マッチファインダー。
高速レベル（-mx3）：4 MBの辞書を持つhc5マッチファインダー。
Normal / Maximum / UltraのマルチスレッドLZMA / LZMA2圧縮のマイナーな速度の最適化
圧縮レベル。
bzip2デコードコードは、lbzip2プログラムによって作成されたbzip2アーカイブをサポートするように更新されました。
いくつかのバグが修正されました。

私は超圧縮で使い続けております。
まだアルファのINSTALLしてませんので
-t7z -mx=9 -ms=off -m0=lzma2 -ssw
多重ファイルをキューに入れて行う時[.BATにて]のテストも見直しもしてないですけど。
530：x@rgs★：2020/02/17(月) 19:00:16 ID:???0: >>527

大変お待たせいたしました。
修正版を公開いたしましたので、ご確認のほどよろしくお願いいたします。
(7-zip32.dllのページの「人柱版」からダウンロードください。)
追加したSevenZipExtractMemEx()はバッファサイズをLONGLONGで指定できます。

>>529

ご報告ありがとうございます。
本家のソースコードが公開されましたら対応いたします。
531：kiyohiro：2020/02/19(水) 12:32:08 ID:I/v61Ywo0: >>530
どうもお世話になってます
掲示板の書き込みを拝見しました
修正箇所は試せそうにないですが
取り敢えずWinXpで動くかどうかだけでも試そうかと思い
ダウンロードしたいのですが見つからないです

> (7-zip32.dllのページの「人柱版」からダウンロードください。)
Home > ソフトウェア > 7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版
のページでは無いのですか？
一応上から下まで見て人柱版をページ内検索とかしても何処なのかわかりませんでした
よろしくお願いします
532：通りすがりの人：2020/02/19(水) 19:36:55 ID:fqH/1Q3.0: 【OS】[Windows8.1 64bit]
【ソフト名】[Ashley]
【バージョン】[Ver.1.39]
【要望】１　リネームした際、同名ファイルがあれば自動的に末尾に (2) や (3) を付加してリネーム
　　　　２　リストからリネーム出来たファイルを削除し、エラーファイルだけを残したい
　　　　３　高度な設定のフォーマットの一覧に自分で作成した定型を追加したい

　リネームツールを探して、このツールにたどり着きました。
　非常に使いやすく、日頃から愛用させて頂いております。
　普段使っている中で、この機能があればより使いやすくなると感じた点をあげてみました。
　ご検討頂けたら幸いです。
533：x@rgs★：2020/02/19(水) 22:09:04 ID:???0: >>531

ご指摘ありがとうございます。
正しくアップロードできていなかったため修正しました。
ご確認ください。

>>532
投稿ありがとうございます。
要望について、1はオプションで実装できるかと思います。
2は「リネームに成功したファイルを全てリストから削除」を実装でよろしいですか。
リネーム成功ファイルを選択or失敗ファイルを選択でも、「選択範囲を反転」や「リストから削除」を組み合わせて実現可能ですが…
3はちょっと難しいかもしれません。例えば、%extで拡張子を表すようにして欲しい…とうことであれば追加します。
新しいファイル名のフォーマットをいくつか保存し、リストから選択したい…とうことであればそのような機能を検討します。
534：通りすがりの人：2020/02/19(水) 23:09:31 ID:fqH/1Q3.0: >>533
ありがとうございます。

２に関しては、リネームする際、成功したファイルより失敗したファイルを再リネームすることの方が多いため要望を出させて頂きました。
現行の機能で対応可能であれば、私の認識不足でした。申し訳ありません。
ただ、「リネームに成功したファイルを全てリストから削除」を実装して頂けるなら大変助かります。
３については、現在、元々のアーカイブ内に含まれない固定文字を付加してリネームするのに、
高度な設定のフォーマット入力フォームに固定文字を追加入力してリネームしているのですが、
毎回固定文字を付加する訳ではないので、そのたびに入力し直しており、それらを保存してリストから選択できたらと思った次第です

技術的に困難、手間がかかるのであれば無理にとは申しませんが、実装して頂けるなら大変助かります。
実際のところ、エラーになる原因のほとんどが同名ファイル存在のため、１だけでも非常にありがたいです。
535：tenteko：2020/02/20(木) 00:27:21 ID:6h5qm12k0: ＞＞530

対応ありがとうございました！

SevenZipExtractMemEx()についてだけですが、早速試させて頂きましたところ、
4,294,967,295バイトを超える書き出しも大丈夫なようです。
（符号『有り』のLONGLONGで宜しいのですよね？）

加えまして、解凍時におけるメッセージ（ARCEXTRACT_BEGIN(0)とARCEXTRACT_INPROCESS(1)）も
共に送出されておりました。

ただ、ひとつ問題を発見しました。
説明致しますと、

①SevenZipExtractMemEx()を実行。

②解凍中、コールバック関数に return true させている間は、正常に処理を継続する。

③解凍中、コールバック関数に return false させると、処理は中断（ARCEXTRACT_END(2)）へ向かうが、
その後プロセスがフリーズし、SevenZipExtractMemEx()が戻り値を返さなくなる
（SevenZipExtractMemEx()より後へ処理が進まなくなる）。

重ね重ねお手数をおかけしますが、対応頂ければ幸いです。
536：x@rgs★：2020/02/23(日) 00:12:55 ID:???0: >>534

2…「リネームに成功したファイルを全てリストから削除」を実装します。
3…「独自文字列を追加」機能(;で区切ると複数指定可能)を実装します。
公開までしばらくお待ちください。

>>535
ご報告ありがとうございます。
修正しましたのでご確認ください。
なお、SevenZipExtractMemEx()の引数は符号ありLONGLONGです。
537：x@rgs★：2020/02/24(月) 11:42:19 ID:???0: >>534

お待たせいたしました。
人柱版を公開しましたのでご確認ください。
要望1:オプション「高度な設定」→「重複時自動リネーム」
要望2:編集メニューなど→「リネーム済みのファイルをすべてリストから削除」
要望3:オプション「高度な設定」→「新しいファイル名のフォーマット」→「フォーマットの追加」
のとおりです。

重複時自動リネームはチェックを付けて有効化してください。
デフォルトの設定「%new(#)」だとfile(1).zipのように一桁で1からスタートします。
設定で「%new(##)」のようにすると、file(01).zipのように0埋めします。

想定していた機能と違う等あればご指摘ください。
538：tenteko：2020/02/24(月) 15:21:31 ID:4Hi1m3GA0: 度々の対応、ありがとうございます。

7-zip64.dll（7z.dll対応版ではない方）だけですが、
試させて頂いた結果を報告させて頂きたい思います。

まず、メッセージについてですが、次のような状態でした。

●ARCEXTRACT_OPEN(3)で return false した場合
その後はメッセージが送出されず、プロセスがフリーズ。
SevenZipExtractMemEx()が戻り値を返さなくなる。

●ARCEXTRACT_BEGIN(0)で return false した場合
その後、ARCEXTRACT_INPROCESS(1)とARCEXTRACT_END(2)は送出されるが、
ARCEXTRACT_END(2)後はフリーズ。
SevenZipExtractMemEx()が戻り値を返さなくなる。

●ARCEXTRACT_INPROCESS(1)で return false した場合
その後、（ファイルサイズによってARCEXTRACT_INPROCESS(1)が何度か送出された後）ARCEXTRACT_END(2)は送出され、正常終了。
SevenZipExtractMemEx()が戻り値としてエラー（0以外の数）を返す。

●ARCEXTRACT_END(2)で return false した場合
正常終了する。
SevenZipExtractMemEx()が戻り値としてエラー（0以外の数）を返す。

…ARCEXTRACT_OPEN(3)とARCEXTRACT_BEGIN(0)のときに問題があるようです。

次に、SevenZipExtractMemEx()のメモリへの書き出し自体についてですが、
データが壊れた状態で書き出されます。
ただ、戻り値は返されているようです。

また、アーカイブの解凍時、アプリケーションが落ちることがあります。
具体的には次のような状態でした。

●特定のアーカイブを解凍すると、必ず落ちる。
ただし、ARCEXTRACT_END(2)まではメッセージが送出されていると思われる。

なお、前バージョンではメモリ書き出しについて問題は有りませんでした。

度々スミマセン…。
539：通りすがりの人：2020/02/25(火) 21:21:15 ID:iQOFrb6o0: >>537
対応ありがとうございます。
自動リネームも編集可能と想定以上の追加機能で大変助かりました。
これからも応援しております。
頑張って下さい。
540：通りすがりの人：2020/02/25(火) 22:36:08 ID:iQOFrb6o0: >>539
ひとつ書き忘れていました

人柱版では起動時とリネーム時にたまにセキュリティソフト（ウイルスバスター）が反応してソフトが落ちることがあります
起動時はセキュリティソフトの除外設定に登録しておけば回避可能でした
リネーム時はおそらく私がリネーム規則をいじっている時に発生しているものと思われますがまだ条件がわかりません
わかりましたらご報告致します

他の方で発生するかどうかは不明ですし、おそらく私の環境と使い方のせいだと思われますので参考までに
541：x@rgs★：2020/02/27(木) 04:19:12 ID:???0: >>538

お待たせいたしました。
中断時のフリーズと正しくメモリに出力されない不具合を修正しましたので、
ご確認ください。

>●特定のアーカイブを解凍すると、必ず落ちる。
>ただし、ARCEXTRACT_END(2)まではメッセージが送出されていると思われる。
この不具合は当方の環境では確認できていません…。
もし今回のバージョンでも発生するようでしたら、
当該ファイルを送っていただくことは可能でしょうか？
よろしくお願いいたします。

>>539-540

ご報告ありがとうございます。
セキュリティソフト関連は少し気になります。
もし条件等が分かりましたらご連絡いただけると幸いです。
542：tenteko：2020/02/29(土) 21:54:49 ID:4Hi1m3GA0: 毎回対応いただきまして、本当にありがとうございます。

今回も7-zip64.dll（7z.dll対応版ではない方）だけですが、報告させていただきます。

●SevenZipExtractMem()実行時、コールバック関数で受信した各メッセージに対し return false した場合、
件の４つのメッセージの何れのケースでも正しく終了し、戻り値としてエラー（0以外の数）を返す。

●書き出したデータも壊れることなく正常に書き出されている（ように思います）。

●前回報告した「特定のアーカイブを解凍すると、必ず落ちる」という現象については、
該当するアーカイブを削除してしまったので試せる状態ではないのですが、
色々と解凍を繰り返しても同様の現象には遭遇しないため、
恐らくデータの書き出しが修正された時点でこの問題も修正されたのかもしれません。
（もし同様の問題に遭遇したときには、また報告させていただきます）

というわけで、報告させて頂いておりました不具合は無くなったようです！

…ただ、２つほど、別の問題を見つけてしまいました。

１つ目は大した問題ではないのかもしれませんが、次の様な現象が発生します。

●フォルダを含むアーカイブをSevenZipExtractMem()で解凍した場合、
実行ファイルがある場所にそのフォルダ（空）が生成されてしまう。

２つ目は、これはこちらで聞くべきことなのかどうか分からないのですが、
もし宜しければご教示頂ければと思います。

現在、OpenSiv3DというC++フレームワーク？で 7-zip64.dll を利用しているのですが、
VS C++ 2019 にて、ウィンドウ上部の再生ボタン？（ローカルWindowsデバッガーと書いてあるところです）を押して、
ここからDebugビルドとReleaseビルドが実行されている分には、SevenZipExtractMem()は十分に機能してくれているのですが、
VSを通さず、直接実行ファイルを実行すると、SevenZipExtractMem()が実行された時点で
アプリケーションがフリーズ（というか、SevenZipExtractMem()を実行したメインスレッドだけが止まっているっぽい？）します。
（このとき、上述の空フォルダが作られる現象は発生します）
前に「SevenZipExtractMem()を実行後に戻り値が返ってこず、プロセスが止まる」というのが有りましたが、
それとよく似ている…のかもしれません。

以上のように、VSを通したときと通さないときとでプログラムの挙動が違うわけなのですが、
何か対処方法等、思い当たるものがあるようでしたら、ご教示願えませんでしょうか。

因みに、SevenZip()など、その他のDLLの関数ではフリーズしないようです。

何分、DLLを用いたプログラムは今回が初めてでありまして、
もしかしたら勝手がわからずに何か根本的な間違いを犯しているのかもしれません…。

■追伸
OpenSiv3Dを利用するのではなく、VSのコンソールアプリのテンプレートからSevenZipExtractMem()を実行すると、
フリーズは発生しませんでした（が、空フォルダが作られるのは同じです）。
543：x@rgs★：2020/03/06(金) 18:23:25 ID:???0: >>542

お待たせいたしました。
報告いただいた不具合を修正しましたので、
ご確認ください。

実行方法によってフリーズしてしまう不具合について、
OpenSiv3Dは書き方が分からなかったため、OpenSiv3D環境下ではテストできていません…。
同様の不具合が発生するAutoHotkey下で動作を確認しましたので、おそらくは動作するものと思います。

OpenSiv3D環境下でのご報告をいただけるとありがたいです。
よろしくお願いします。
544：tenteko：2020/03/08(日) 02:08:31 ID:4Hi1m3GA0: ＞OpenSiv3D環境下でのご報告をいただけるとありがたいです

OpenSiv3Dの実行ファイル単独で実行しても、フリーズすること無く動くようになりました！
このままだとプログラムが完成しても単独で実行できないのでは意味がない…とヒヤヒヤしておりましたので、
これで安心してまたプログラムが組めます！
本当に有難うございました。

因みに原因は何だったのでしょうか？
後学までに教えて頂ければ嬉しいです。

あと、空フォルダの生成も無くなっていたのを確認いたしました。
こちらもありがとうございました。

…ところで、また２つほど問題を見つけてしまいました。

①

今現在、SevenZipFindFirst及びSevenZipFindNextを実行し、最初に見つけた画像ファイル（拡張子で判断）だけを解凍し、
ここからサムネイル画像を作る、ということをやっております。
それで、例えばSevenZipExtractMemExの第２引数に渡すコマンドラインを次のようなものにしているのですが…。

"x \"D:/test/test.zip\" -ir!\"test\\001.jpg\" -hide"

通常の場合はこれで解凍できているのですが、
アーカイブ内のファイル名（或いはフォルダ名）の中で半角スペースが２つ以上続く（以下、NGワード）とフリーズしてしまうようです。
（アーカイブファイル名の方では当該NGワードの有無は問題にならないようです）

なお、上記のように特定のファイルだけを解凍するのではなく、全てを解凍するような場合は、
NGワードの有無は関係なしに解凍できているように思います。

②

公式の7-zip（ver.19.00 x64）でLZMA2で圧縮したアーカイブをSevenZipExtractMemExで解凍したところ、
解凍自体は正常に行われているようなのですが、
LZMA圧縮アーカイブを解凍したときは、アーカイブ内の各ファイル毎にARCEXTRACT_BEGINが送出されるところ、
LZMA2圧縮アーカイブを解凍したときは、必ずしも各ファイル毎にARCEXTRACT_BEGINが送出されるわけではない、
という現象が発生しているように思います（アーカイブによって状況が異なる？）。

ARCEXTRACT_BEGINとARCEXTRACT_ENDを各ファイル書き出し完了のフラグを立てるのに利用していることもあり、
ちょっと困っております。
もしかしたら7zip自体の仕様なのかもしれませんが、修正は可能でしょうか。
545：x@rgs★：2020/03/08(日) 14:28:04 ID:???0: >>544

ご報告ありがとうございます。
無事動作したようで何よりです。

標準出力の割り当てに失敗していたことが原因です。
これを回避するために、裏でcmd.exeを立ち上げたりしています。

新規不具合について、
①これは「-i」スイッチ自体を二重引用符で囲うようにすると正常に動作すると思います。
-ir!\"test\\00 1.jpg\"
↓
\"-ir!test\\00 1.jpg\"
ファイル名部分だけを囲うと、7-zip32.dllの内部で
\"-ir!\"test\\00\" \"1.jpg\"\"
と解析されてしまうようです。

②いくつかLZMA2なアーカイブを作成しテストしましたが、当方の環境では再現できませんでした。
差し支えなければ当該ファイルを送付していただくか、構造等を教えていただけると幸いです。

その他、毎度々々のフリーズの原因であるパイプ読み込みスレッドの処理を改善したバージョンを公開しました。
546：x@rgs★：2020/03/08(日) 14:55:34 ID:???0: >>545

追記です。
不具合①は本家7-zip32.dllでも報告されており、
今後ファイル名を囲う方法も対応していく予定のようです。
547：tenteko：2020/03/13(金) 01:30:02 ID:4Hi1m3GA0: ＞標準出力の割り当てに失敗していたことが原因です。
＞これを回避するために、裏でcmd.exeを立ち上げたりしています。

ちょっと私にはまだ難しいようです…。
でも、今後のために覚えておきます！

＞二重引用符

これはそのようにさせて頂いたところ、バッチリ動作しました！
ありがとうございます。

さて、ARCEXTRACT_BEGINがLZMA2解凍時に送出されない件についてですが、
テスト用のファイルを用意しましたので、確認いただけますでしょうか。
参考までに、私の環境下で解凍した場合の、それぞれのメッセージの送出状況を
記しておきます。

ttps://30.gigafile.nu/0320-de726bea80631e3bd8ff85c1ad8cbcaa7
ファイル名：test_arc_files.zip
ダウンロードパスワード：arc

●test_LZMA.7zの場合（LZMA圧縮）

ARCEXTRACT_OPEN
ARCEXTRACT_BEGIN (フォルダ"test_LZMA"の解凍)
ARCEXTRACT_BEGIN (ファイル"test01.png"の解凍)
ARCEXTRACT_BEGIN (ファイル"test02.png"の解凍)
ARCEXTRACT_BEGIN (ファイル"test03.png"の解凍)
ARCEXTRACT_INPROCESS (ファイル"test03.png"の解凍)
ARCEXTRACT_END

●test_LZMA2.7zの場合（LZMA2圧縮）

ARCEXTRACT_OPEN
ARCEXTRACT_BEGIN (フォルダ"test_LZMA2"の解凍)
ARCEXTRACT_INPROCESS (フォルダ"test_LZMA2"の解凍？)
ARCEXTRACT_END
548：x@rgs★：2020/03/14(土) 12:49:25 ID:???0: >>547

LZMA2の件ですが、提供していただいたアーカイブで確認できました。
これはメッセージを投げる前にファイルの解凍が終わっていることが原因のようです。
Dialog.cppのCProgressDialog::SetCompleted()内、
if (m_nCompletedSize == nSize)
return;
をコメントアウトすればメッセージが送出されます。
ただ、解凍処理が終わっているのにメッセージを投げ続けるのはどうかなと思いますので、
この修正については見送らせてください。
申し訳ないです。
549：tenteko：2020/03/20(金) 21:08:02 ID:4Hi1m3GA0: ＞これはメッセージを投げる前にファイルの解凍が終わっていることが原因のようです。

なるほど。
となると、多くの画像ファイルが入ったアーカイブ（LZMA2圧縮）を解凍したときに、
最後付近のファイルについてARCEXTRACT_BEGINが送出されていなかった現象が
時々発生していたのですが、これについても同じ原因と考えられそうです。

＞ただ、解凍処理が終わっているのにメッセージを投げ続けるのはどうかなと思いますので、
＞この修正については見送らせてください。

了解いたしました。
となりますと、これまでARCEXTRACT_BEGINに依存した処理をしていたのですが、改めることにしました。

これを受けまして、今現在、『どのファイルまで解凍したか』というのを判断するために、
次のような処理をしております。

＝＝＝＝＝＝＝＝＝＝

①SevenZipFindFirst及びSevenZipFindNextにより取得したファイル情報を順に配列に保存。
また、各ファイルがこの後確保するバッファのどの位置に解凍されるかも一緒に保存しておく。

②SevenZipGetArcOriginalSizeExによって解凍される全ファイルのサイズを取得し、
そのサイズでバッファを作成。

③バッファに対し、①のデータをもとに、各ファイルの先頭位置にダミーのデータ（1byte：値0x11）を
書き込んでおく。

④バッファに対し、別スレッドでSevenZipExtractMemExによる解凍開始。

⑤1/60秒毎に、③でデータを書き込んだ各位置を調査し、ダミーのデータと異なる値が書き込まれていれば、
直前のファイルの書き出しが完了したものとみなし、当該「直前のファイル」の書き出し完了のフラグを立てる。

⑥各ファイルの書き出し完了フラグを調査し、フラグが立っていれば（複数の別スレッドで）逐次
読み込みを開始する。

⑦また、任意のタイミングで解凍を中断（コールバック関数でreturn false）し、
SevenZipExtractMemExの終了を待って、別のアーカイブの解凍を開始する（①に戻る）こともできる。

＝＝＝＝＝＝＝＝＝＝

…以上の処理をしている中で、時々次のような現象が発生します。
沢山の画像ファイルが入ったアーカイブを解凍するという場合についてですが、

(1)コールバック関数で受信したメッセージから書き出したサイズが取得できますが、
これが最大値（全ファイルのサイズ）になっているにもかかわらず、

『全てのファイルについて書き出し完了のフラグが立たない（全く書き出されていない？）』

『最後の方で書き出される、連続する幾つかのファイルについて、書き出し完了のフラグが立たない、または
フラグが立っても正しいファイルとして読み込めない（ある地点から書き出しがストップしている？）』

という現象が時々発生します（同じアーカイブを読み込み直すと正常に解凍できたりします）。
7zipではなく、通常のzipの場合に発生しやすいような印象で、
特に⑦によって連続で解凍や中断を繰り返していると発生しやすい、
というのが体感的な印象でしょうか。

(2)書き出し完了のフラグが立っているファイルを読み込みに行っても、
壊れた画像ファイルとして表示されることがあります（書き出し途中のファイルを読み込んだ感じです）。
ただし、もう一度読み込み直すと正常に表示されます。
これも通常のzipの場合に発生しやすいような印象です。

（続く）
550：tenteko：2020/03/20(金) 21:08:38 ID:4Hi1m3GA0: （続き）

そこで、幾つか質問があるのですが、

(a)SevenZipExtractMemExでは、SevenZipFindFirst及びSevenZipFindNextで得たファイル（とフォルダ）の順に
書き出しが行われているのでしょうか。

(b)SevenZipExtractMemExは、バッファに対し、バイト単位でシーケンシャルに
書き出しを行っているのでしょうか。
（上記(2)からの推測ですが、飛び飛びにデータが書き出されたりすることもあるのでしょうか）

(c)ARCEXTRACT_BEGINは直前のファイルの完全な書き出しを保証してはいないように
思えるのですが、これは正しいでしょうか。

(d)同様に、ARCEXTRACT_ENDは最後のファイルの完全な書き出しを保証してはいないように
思えるのですが、これは正しいでしょうか。

(e)また、コールバック関数で受信したメッセージ(EXTRACTINGINFOEX64)より得た書き出しサイズは、
そのサイズまでシーケンシャルに書き出したことを保証していないように思えますが、
これは正しいでしょうか。

(f)SevenZipExtractMemEx()の関数が終了し、その後に処理が移ったとしても、
裏ではまだバッファへの書き出しが行われている、という状況は有り得ますでしょうか。

(g)上記(1)の２つ目の現象からの推測なので、その推測が外れていれば意味のない質問なのですが、
例えば、解凍の処理は一定のブロック単位で解凍→書き出しを繰り返しているとして、
最後のブロックの書き出しだけ失敗する、ということは有り得ますでしょうか。

(h)上記(a)が正しいとして、その順で、あるファイルまで確実に書き出された、
ということを知る方法はありますでしょうか。

…以上、長々と失礼いたしました。

現在の処理方法（ダミーデータが上書きされれば直前のファイルは解凍済み）でも
大体は上手く処理できているのですが、たまに発生する上記の問題の対処に難儀しておりまして、
そのため幾つか質問させて頂きました。

何度もお手数をおかけしている中で申し訳ありませんが、
宜しくお願いいたします。
551：x@rgs★：2020/03/30(月) 01:58:06 ID:???0: >>549-550

返信が遅くなり申し訳ございません。
ご質問いただいた内容は内部処理に関することですので、確実な回答はちょっとできません…

とりあえず、SevenZip()のメインスレッド終了時に標準出力をフラッシュするようにし、
また標準出力に割り当てるパイプをCreateFile(FILE_FLAG_NO_BUFFERING)で作成してみました。

tenteko様の現象が再現できていないため、不具合が修正できているか分かりませんが…
よろしくお願いします。
552：tenteko：2020/04/05(日) 01:12:27 ID:4Hi1m3GA0: こんにちは。
毎回対応して下さり、ありがとうございます。

１週間弱ほど新しいバージョンを試させて頂いた結果を報告させていただきたいと思います。

前回報告させて頂いた不具合（(1)と(2)です）については、
これはどちらも再発しなくなりました（今のところは、ですが）。

ただその代わり、前バージョンではそんなことはなかったと思うのですが、
今バージョンではSevenZipExtractMemEx()がフリーズする現象が再発するようになりました。

恐らくですが、書き出しが開始した時点でフリーズしているように思えます。

発生する条件は未確定なのですが、次のような場合によく発生するように思えます。

(a) zipの解凍時によく発生するように思える（7zipの場合は無い…ように思える）

(b) やはり解凍中断→解凍開始とした場合に発生しやすいように思える
　　（「初回解凍」や「解凍完了→解凍開始」の場合も発生するかどうかはよくわかりません）

ただ、次のような処理をすると、高い確率でフリーズが再現できます。

(c) 画像の入ったzipを沢山用意し（何百個単位）、各zipに対し、
　　その中の最初の画像ファイルだけを解凍し、これをサムネイル化する
　　…ということを順に繰り返していく

なお、この(c)の処理において、SevenZipExtractMemEx()の直後にウェイトを入れてみたところ、
ウェイトの量が多いほどフリーズしにくいような印象ではありますが、
あまりこの手は使いたくないところです。

以上となります。
宜しくお願いいたします。
553：x@rgs★：2020/04/12(日) 02:53:12 ID:???0: >>552

ご報告ありがとうございます。
なかなか解決できず申し訳ないです。

フリーズについて、パイプ読み込みスレッドの終了・中断処理を改善しました。
今のところAutoHotkey環境で動かしている分にはフリーズしなくなったようです。

この修正で>>549で報告いただいたファイルの一部が出力されない不具合も改善されたかもしれない…
ということで、CreateFile(FILE_FLAG_NO_BUFFERING)に加え、従来のCreatePipe()版も同梱しています。
さらに、標準出力のフラッシュあり・なしで分けてあり、合計4種類あります。

お手数をおかけしますが、「01_CreatePipe版_FlushFileBuffersなし」から動作を確認していただき、
不具合が発生するようでしたら他のバージョンもお試しください。

よろしくお願いします。
554：tenteko：2020/04/17(金) 21:40:45 ID:4Hi1m3GA0: 今回はそれほど試せなかったのですが、一通り試してみた結果を報告します。

●01_CreatePipe版_FlushFileBuffersなし

前回の報告にあった「連続で各zipのサムネイルを一つずつ作る」という場合は問題なかったのですが、
通常通り全解凍する場合、検索順序で言うところの最後の方が解凍されない、という症状は出ました。

●02_CreatePipe版_FlushFileBuffersあり
●03_FILE_FLAG_NO_BUFFERING版_FlushFileBuffersなし
●04_FILE_FLAG_NO_BUFFERING版_FlushFileBuffersあり

これらは全て問題がないように思えます。

というわけで、もしかしたら安定したかも！　です！

まだ上記「連続で各zipのサムネイルを一つずつ作る」という機能を本格実装していないので、
なかなか物量的な実地調査はできていないのですが、引き続き調査してみたいと思います。

…ところで、画像ビューワーを現在作っているわけですが、悩んでいることがあります。
やりたいこととしては、次の２つを同時に行いたい、ということなのですが…

①アーカイブ内の画像（閲覧する対象）をオンメモリに解凍。

②別スレッドで並行して「連続で各アーカイブ（主に閲覧してないもの）のサムネイルを一つずつ作る」

…ここで問題となってくるのが
「①と②で実行した各SevenZipExtractMemEx()が、共通する１つのコールバック関数にメッセージを送る」
ということなんです。

そうなると、例えば「①は中断したいが②は中断したくない」という場合に
コールバック関数で return false してしまうと、両方ともが中断してしまう…という結果になってしまいます。

そこで、もしかしたらdllファイルをコピーしてリネームし、これをLoadLibrary()すればいけるかな？
と試してみたのですが、やはり１つのコールバック関数に双方のメッセージが送られてしまうように思います。

…なにか良い方法は有りませんでしょうか。
毎回お手数をおかけします…。

■追伸
４つのdllの調査の優先順位は、01が最優先で、順に04まで優先順位が下がっていく、
という感じに調査すればいいでしょうか。
555：x@rgs★：2020/04/20(月) 21:27:14 ID:???0: >>554

ご報告ありがとうございます。
問題がなければ「02_CreatePipe版_FlushFileBuffersあり」を採用していきたいと考えています。
優先度は数値の順番で、01がダメなようなので、02→03→04でお願いします。

1つのプロセスでの並行処理は難しいと思います。
・中断を判断するフラグがグローバル変数のため、1つを中断すると全ての処理が中断してしまう。
・他にもグローバル変数が存在。
・dllファイルをリネームして読み込んでも、プロセスごとに割り当てられる標準出力を利用するSevenZipExtractMem()は正しく動作しない。
等々。

サムネイル作成処理を別プロセス化して、共有メモリで本体とやり取りする…はいかがでしょう。
556：tenteko：2020/04/26(日) 22:12:42 ID:4Hi1m3GA0: こんにちは。

あれから「02_CreatePipe版_FlushFileBuffersあり」版を試していますが、問題は発生していません。
とても有難く使わせてもらっています。（本当にありがとうございます！）

前回教えて頂いた別プロセス＋共有メモリという方法について少し調べてみました。
メモリマップトファイル…というものを使うらしいのですが、合っていますでしょうか。

これを使うかどうかは思案中でありますが、ひとまずは同一プロセス内で
各アーカイブのサムネイルを作れるように実装してみましたところ、
割とテンポよくサムネイル作成ができるようになりました。
（SevenZipExtractMemEx()が並行実行されないようにアーカイブのサムネイル作成をしています）

ただ、ここで一つ、別の問題が発覚しました。
例えば、サムネイル作成しようとしているアーカイブ（7zの場合を想定）内にファイルが8個格納
されているとして、その解凍される順序が次のようになっている場合、

①画像ファイル以外のファイル
②（上に同じ）
③（上に同じ）
④（上に同じ）
⑤画像ファイル
⑥何らかのファイル
⑦（上に同じ）
⑧（上に同じ）

SevenZipExtractMemEx()には⑤だけを解答するように指示したとします。
ここで、例えば②の処理をしている時点で中断の指示を出した場合、
②の処理が終わった時点でSevenZipExtractMemEx()が終了してくれればよいのですが、
そうはならず、（恐らく）⑤の処理を終了するまでSevenZipExtractMemEx()は終了してくれない、
という現象が発生します。

これによって、例えば①～④にサイズの大きなファイルが入っている場合、
⑤の解凍を中断する場合にかなり待たされることになったりします。

一方、このアーカイブを全解凍する場合は、どの時点であってもその時点で取り掛かっている
ファイルの処理が終了したらSevenZipExtractMemEx()も終了してくれているように思います。

…そこで要望なのですが、特定のファイルだけを解凍する場合も、全解凍の場合と同じように
中断処理が行えるようにしていただけませんでしょうか。

ここまで対応して頂いた中で恐縮なのですが、宜しくお願いいたします。
557：x@rgs★：2020/04/29(水) 10:23:11 ID:???0: >>556

ご報告ありがとうございます。
CreatePipe()とFlushFileBuffers()の組み合わせでいきたいと思います。

メモリマップドファイルをCreateFileMapping(INVALID_HANDLE_VALUE,...)で作成して、
CreateProcess()でサムネイル作成用プログラムを起動し、書庫を開いてサムネイルを読み込んで…という手順になると思います。
開く書庫やサムネイルのファイル名は引数なり環境変数で渡して、メモリマップドファイルのオブジェクト名もそのように渡すか、
ハンドルを継承できるようにしてハンドルそのものを渡す…とか。

部分解凍の件について、
>SevenZipExtractMemEx()には⑤だけを解答するように指示したとします。
これは「x -hide <書庫名> -ir!<⑤ファイル名>」(もしくは-ir!なし)を指定しているということで間違いないでしょうか。
いくつか書庫を作って試していますが、コールバック関数では⑤の情報しか受け取れないため、なかなか再現できません。
処理手順や書庫について、もう少し情報をいただけるとありがたいです。(書庫を送付していただけるとよりありがたいです)

よろしくお願いします。
558：tenteko：2020/05/03(日) 19:29:46 ID:BrCfT3Wc0: こんにちは。
別プロセスの作り方も教えてくださり、ありがとうございます。とても参考になりました。
まだあまり理解していないのですが、openSiv3D自体に子プロセス作成とパイプライン？の機能があるようで、
これを使えばもしかしたらもうちょっと簡単になるのかも…という気がしております。

＞これは「x -hide <書庫名> -ir!<⑤ファイル名>」(もしくは-ir!なし)を指定しているということで間違いないでしょうか。

はい、そのとおりです。
アーカイブのサムネイル作成時に渡しているコマンドは次のようなものです。

x <書庫名> -ir!<⑤ファイル名> -hide

ちなみに、全解凍時に渡しているコマンドは次のようになっています。

x <書庫名> -hide

＞処理手順や書庫について、もう少し情報をいただけるとありがたいです。

中断処理手順の概要を以下に記してみようと思います。

(1) まず、あるアーカイブ（7z）のサムネイル作成にとりかかります。
ここでは、SevenZipFindFirst()とSevenZipFindNext()で最初にヒットした画像ファイルを対象とし、
このファイルのみ解凍するため、上記の最初のコマンドラインでSevenZipExtractMemEx()を起動します。

(2) SevenZipExtractMemEx()実行中、任意のタイミングで中断指示を行います。
具体的には、中断指示　＝　グローバル変数の中断フラグをオンにして、
コールバック関数内でこれがオンの場合には return false するようにしています。

(3) 全解凍の場合は、殆どのケースで中断指示 → 間もなく return false → SevenZipExtractMemEx()終了となります。
しかし一部解凍の場合は、対象ファイルが処理されるまでに大きなファイルが有る場合は、
中断指示を出してもSevenZipExtractMemEx()終了までに時間がかかってしまうことがあります。

…今回、コールバック関数のメッセージの受信状況を調べてみました。
以下のテストファイル（interruptionTest.7z）を使って調べました（大きなサイズで恐縮です）。

ttps://18.gigafile.nu/0510-l69ad0d3859cb18f7f9171bcc91cc3e48

このファイルでは、解凍される順で①～③までがサイズの大きいファイル、
④～⑥が画像ファイルとなっています。

解凍対象となるのは④（test01.png）です。

SevenZipExtractMemEx()が実行されましたら、メッセージは次の順序で送られていました。

(1) ARCEXTRACT_OPEN（interruptionTest.7z）
…（長いインターバル）…
(2) ARCEXTRACT_BEGIN（interruptionTest\\test01.png）
(3) ARCEXTRACT_INPROCESS（interruptionTest\\test01.png）
(4) ARCEXTRACT_END

となりますと、中断フラグを上記「長いインターバル」の間にオンにしたとしても、
メッセージが送られてこないことには return false しようがない、
よって、(2)まで待たなければ中断ができない、ということになっていたようでした。

…毎回お手数をおかけします…。
559：x@rgs★：2020/05/05(火) 00:12:13 ID:???0: >>558

ご報告&ファイルのアップロードありがとうございます。現象確認できました。
とりあえず、ソリッド書庫を解凍する場合等で実際に解凍しないファイルの処理中もメッセージを送るようにしてみました。
スキップするファイルの処理中はARCEXTRACT_SKIP(5)を送ります。勝手に追加していますので、今はどこかでdefineしてください。

何度もすみませんがよろしくお願いします。
560：通りすがりの人：2020/05/10(日) 01:46:52 ID:J948jCQA0: 7z公式にて7-Zip 20.00 alphaが上がっておりました。
sevenzip.osdn.jp/
2020-02-06と記載されながらも、updateは二日前となっておりました。
英文を読むと高速化を図った、decode方法を変更しましたとありますが、重要な点はいくつかのBugFixがされてるようです。
bzip2 decoding code was updated to support bzip2 archives, created by lbzip2 program.
Some bugs were fixed.
報告のみです。
561：通りすがりの人：2020/05/10(日) 01:58:07 ID:FnJlBZMA0: 【OS】[Windows 10]
【ソフト名】[gui4ehgm]
【バージョン】[Ver.1.12]
【症状】[貼り付けて実行を選択した後に表示されるURLを追加画面でのURLからSが削除されてしまう]
【再現手順】[毎回なります。Pの後ろにSを追加すればダウンロードできます、毎回手打ちでSを足しているので削除されないようにしていただけませんか]

とても便利に使わせていただいています。ありがとうございます。
562：x@rgs★：2020/05/10(日) 17:27:48 ID:???0: >>560

ご報告ありがとうございます。
本家のソースコードが公開されましたら対応いたします。

>>561

Ver.1.13を公開しましたのでご確認ください。
563：561：2020/05/10(日) 18:37:55 ID:FnJlBZMA0: gui4ehgmのバージョンアップありがとうございました
使わせていただきます
564：tenteko：2020/05/12(火) 00:02:34 ID:BrCfT3Wc0: 今回も対応して下さり、ありがとうございます！
スキップ中の中断も完全に動作しているように思います！

お陰様で作成中のビューワーの動作がかなり快適になってきました。
もしかしたら別プロセスの作成は無くても大丈夫かも…。

これであとは…各ファイルの書き出しが保証された時点でその都度新たな書出完了メッセージが送信されれば
便利だと思うのですが…。
565：通りすがりの人：2020/05/14(木) 05:31:13 ID:fhnnVVhI0: 【OS】[Windows 10 1903 64bit]
【ソフト名】[reces 32bit]
【バージョン】[Ver.0.00r34b]
質問です
/X オプションで、ファイル名に「 ; 」を含むファイルを指定する方法を教えてください
aa;bb.jpgというファイルがあったとして /Xaa;bb.jpg と記述してもうまく動作しません
566：x@rgs★：2020/05/14(木) 20:40:34 ID:???0: >>564
動作確認ありがとうございます。
現在、ARCEXTRACT_*メッセージを修正中です。
書き出し保証は難しいですが、>>544の②に対応するような、処理前に必ず送信されるメッセージを実装したり、
ARCEXTRACT_INPROCESSのタイミングを調整したりしています。
あまり期待せずお待ちください。

>>565
投稿ありがとうございます。
「;」は区切り文字として処理されるため、正規表現で文字コードとして指定するとうまくいくと思います。
/X:raa\x3bbb\.jpg

#今確認すると正規表現検索の場合は部分一致になってしまっているようですので、次回バージョンでは見直す予定です…
567：565：2020/05/14(木) 23:02:47 ID:fhnnVVhI0: >>566
返信ありがとうございます
動作確認しました
568：x@rgs★：2020/05/15(金) 00:21:44 ID:???0: >>564

>>566の内容を反映したものを公開しました。
ファイルの処理前にARCEXTRACT_PREPARE(6)を送出するようにしてみました。
ARCEXTRACT_BEGINは来たり来なかったりしますが、ARCEXTRACT_PREPAREは確実に送出されるはずです。
大抵はARCEXTRACT_PREPARE、ARCEXTRACT_BEGIN、ARCEXTRACT_INPROCESSの順番で送出されますが、
先頭に格納されているファイルの処理時等はARCEXTRACT_INPROCESSがなかったり、ARCEXTRACT_PREPAREとARCEXTRACT_BEGINの順番が逆になったりしてしまいます。
#そのため、ARCEXTRACT_PREPAREが来たからと言って、その前のファイルの処理が終了している保証はありません…

ほかに、ARCEXTRACT_INPROCESSをパイプからの読み込み処理にあわせて送出するようにしたため、コールバックで受けたllWriteSize等からどこまで処理されているかの参考になると思います。

良ければご確認ください。
569：tenteko：2020/05/18(月) 22:45:39 ID:BrCfT3Wc0: いつも要望を取り上げていただき、ありがとうございます。
今回は余り試せていないのですが、明らかな異常がありましたので取り急ぎ報告させていただきます。

すごく重くなりました。

特に、アーカイブのサムネイルを作るために連続で一部解凍を行う場合に顕著で、
解凍が開始される直前ごとに大きな空白時間（１秒位？）が発生しているような感じです。
恐らくですが、SevenZipGetArcOriginalSizeEx()開始後に待たされているように思います。

もしかして…デバッグビルドとかだったり…。
570：x@rgs★：2020/05/19(火) 07:42:43 ID:???0: >>569

ご報告ありがとうございます。
一部クリティカルセクションを削除しました。
ご確認ください。
571：tenteko：2020/05/22(金) 21:26:37 ID:BrCfT3Wc0: こんにちは。
今回も同様の報告となってしまうのですが、
体感的には前回と変わらず（１秒位待たされる）、という感じでした。

また、前回と同様だったかどうかはチェックしていないのですが、
別の問題として、コールバック関数で受信したメッセージでllWriteSizeを拾っているところ、
これが全解凍サイズ一歩手前で止まってしまっているように思います（成功する場合もあります）。
確認いただけますでしょうか。
572：x@rgs★：2020/05/31(日) 13:31:09 ID:???0: >>571

ご報告ありがとうございます。
大変遅くなりました。
恥ずかしいことに、一部デバッグ用コードが残っていたため削除しました。
また、パイプ読み込みで残りサイズに関わらずARCEXTRACT_INPROCESSを送るようにしました。

ご確認ください。
573：tenteko：2020/06/02(火) 23:12:49 ID:BrCfT3Wc0: こんにちは。
何度も対応いただき、本当にありがとうございます。
私ものんびりやっておりますので、どうぞ時間的なことはお気になさらないで下さい。

（以下、報告です）

今回のバージョンでは、前回までの報告に合った不具合（１秒位待たされる・llWriteSizeが途中で止まる）は
無くなったように思います。

ただ、別の問題が発生しました。

まず、解凍を行うとたまにアプリケーションが落ちるようになりました。
VSのリリースビルドでテストをしていると、「7-zip64.dllで例外がスローされました」とエラーが出ます。

もう一つ、llWriteSizeが頻繁にゼロの値を持ってくるようになりました（解凍の途中でも）。
また、再現は難しいのですが、ゼロ以外にもマイナスの値であったこともありました。
574：x@rgs★：2020/06/03(水) 21:42:44 ID:???0: >>573

毎度々々時間が掛ってしまい申し訳ないです。

llWriteSizeが0になる問題については修正しました。
強制終了の件は再現できませんでした…
どのタイミングで、(判明していれば)どの例外が発生しているか教えていただけませんか。
575：通りすがりの人：2020/06/07(日) 23:29:07 ID:PR8eTftk0: >560
です。
非公式DLL便利に使わせて戴いております。
上記ソフトは使用しておりません。
上の7-zip64.dllという書き込みを見てふと思ったのですが
公式ALPHA版にて修正された潜在的なバグが発生しているのでは？
と思った次第です。
以前の公式βも右上にあったと記憶してますが、公開されてるかどうか確認しようと探しましたがソースってどこにあるんでしょうか
公開されれば対応して下さるという記載が御座いましたが。
576：x@rgs★：2020/06/09(火) 08:06:25 ID:???0: >>575

投稿ありがとうございます。
もしかしたら本家側の不具合が関連するものもあるかもしれませんが、
今のところ独自で実装した部分が原因と思われます。

ソースは本家サイトの「Download」(左側)から19.00までなら入手できます。
20.00のソースはまだ公開されていないようです。
577：tenteko：2020/06/11(木) 23:01:51 ID:BrCfT3Wc0: こんにちは。
あれからしばらく動作テストをやってみたのですが、なにぶん不意に落ちるものでして、
なかなか「どのタイミングで落ちるのか」というのがよく分からないまま現在に至ります…。

以下、思いついたことを箇条書きにします。

●基本的には解凍が行われるとき（解凍開始の瞬間か、解凍の最中かはよくわかりません）に
再現性なく不定期に落ちる、という感じです。

●通常の全部解凍の場合も落ちた…ように思います（確か…）。

●サムネイル作成のための一部解凍の場合なんかは解凍回数が多くなるため、
落ちる確率が高くなるように感じます。

●逆に、サムネイル作成のための一部解凍が何百回と繰り返されても、落ちないときは落ちません。

あと、なにかの参考になるかと思い、エラーのスクリーンショットを用意しました。

ttps://20.gigafile.nu/0618-b242e13305ec44af3552f5e7601136cac

メモリアドレス？のような数値は、大体毎回同じものが表示されていました。
余りお役に立てず申し訳ないです…。
578：x@rgs★：2020/06/17(水) 01:13:51 ID:???0: >>577

ご報告ありがとうございます。
手元の環境では再現できなかったため、あやしいところを修正しました。
ご確認ください。
579：tenteko：2020/06/22(月) 21:45:22 ID:BrCfT3Wc0: こんにちは。

最新版をテストしておりましたら、前回報告させていただいた「7-zip64.dllで例外がスローされました」
というエラーは出なくなったようなのですが、次のような問題がありました。

●解凍中断→即別アーカイブ解凍などを繰り返していると、
時々、以下のhArcにnullptrが返ってくることがあります（そのファイルの解凍時に必ずそうなるわけでもない）。

HARC hArc = SevenZipOpenArchive(NULL, [filePath], M_CHECK_ALL_PATH or M_CHECK_FILENAME_ONLY);

●前にもありましたが、時々、llWriteSizeが全解凍サイズ一歩手前で止まってしまうことがあります。

●条件はよく分かりませんが、以前お渡しした「interruptionTest.7z」などで一部解凍を中断をした場合、
３秒位待たされるようになりました。
なお、全部解凍の中断の場合は待たされることはないようです。

お手数をおかけします…。
580：x@rgs★：2020/06/27(土) 00:59:44 ID:???0: >>579

確認ありがとうございます。
どの不具合も当方の環境では再現できなかったため、あまり対応できていません…

>●解凍中断→即別アーカイブ解凍などを繰り返していると、
>時々、以下のhArcにnullptrが返ってくることがあります（そのファイルの解凍時に必ずそうなるわけでもない）。
直後にSevenZipGetLastError()を呼ぶとどのような値を返しますか。

>●前にもありましたが、時々、llWriteSizeが全解凍サイズ一歩手前で止まってしまうことがあります。
変数の初期化タイミングを変更してみました。

>●条件はよく分かりませんが、以前お渡しした「interruptionTest.7z」などで一部解凍を中断をした場合、
>３秒位待たされるようになりました。
>なお、全部解凍の中断の場合は待たされることはないようです。
不具合発生時のコマンド引数や処理中ファイル、llWriteFileの値は分かりますか。
スキップファイルの情報送信ができていなかった不具合は修正しました…があまり関係なさそうです。
581：tenteko：2020/06/27(土) 23:01:30 ID:BrCfT3Wc0: こんにちは。
中断処理については直ったようなのですが（ありがとうございます）、
その他については改善ならず、という感じでした。

以下、報告です。

>>●解凍中断→即別アーカイブ解凍などを繰り返していると、
>>時々、以下のhArcにnullptrが返ってくることがあります（そのファイルの解凍時に必ずそうなるわけでもない）。
>直後にSevenZipGetLastError()を呼ぶとどのような値を返しますか。

次のようなコードで試してみたところ、error には 0 が、value には 33026 が入っていました。

auto hArc = SevenZipOpenArchive(NULL, [filePath], M_CHECK_ALL_PATH);
if (hArc == nullptr) {
DWORD error;
int32 value = SevenZipGetLastError(&error);
}

>>●前にもありましたが、時々、llWriteSizeが全解凍サイズ一歩手前で止まってしまうことがあります。
>変数の初期化タイミングを変更してみました。

こちらは変化なく、やはり一歩手前で止まることがあります。

>>●条件はよく分かりませんが、以前お渡しした「interruptionTest.7z」などで一部解凍を中断をした場合、
>>３秒位待たされるようになりました。
>>なお、全部解凍の中断の場合は待たされることはないようです。
>不具合発生時のコマンド引数や処理中ファイル、llWriteFileの値は分かりますか。
>スキップファイルの情報送信ができていなかった不具合は修正しました…があまり関係なさそうです。

こちらの方は修正成功のようで、無事即座に中断されるようになりました。
582：tenteko：2020/06/27(土) 23:09:15 ID:BrCfT3Wc0: すみません、続きがあるのですが、なぜかNGワードに引っかかるようで投稿できませんでした…。

要点としましては、前回のバージョンで各種値を調べてみた結果、
interruptionTest.7zの一部解凍（最初に見つけた画像の解凍）の最中に中断したときに（中断後１～２秒後くらい？）、
中断が完了するまでの間、コールバック関数で受信したメッセージは _nState == 6 (ARCEXTRACT_PREPARE) だけでした。
その時のファイル名は"interruptionTest\\dummy_file02.rar"です。
なお、コマンドラインは以前にお知らせしたものと変わりません。
583：x@rgs★：2020/06/28(日) 21:54:50 ID:???0: >>581-582

OpenArchive()は原因が分からないため、デバッグ用メッセージを追加しました。
内部のOpenCheck()で例外をcatchするとメッセージを表示します。全てに対応している訳ではないためちょとあやしいです。

>>llWriteSizeが全解凍サイズ一歩手前で止まってしまう
パイプ読み込みスレッドの処理を変更しました。
SevenZip()が正常終了した場合は読み込みが全て終了するまでループするようにしています。

よろしくお願いいたします。
584：tenteko：2020/07/06(月) 20:46:07 ID:BrCfT3Wc0: こんにちは。

前回、デバグ用メッセージを追加していただいたのですが、
幸か不幸か、SevenZipOpenArchive()がエラーを出さなくなってしまいまして…。
この部分については調査できずじまいとなりました。

他方、時々llWriteSizeが全解凍サイズ一歩手前で止まってしまう現象については
継続して発生しており、引き続き対処が必要なようです。

宜しくおねがいします。
585：x@rgs★：2020/07/07(火) 20:15:32 ID:???0: >>584

投稿ありがとうございます。
>>548の処理の処理を取り入れてみました。
ご確認ください。
586：tenteko：2020/07/18(土) 20:08:42 ID:nzIvPxNw0: こんにちは。
遅くなってしまいました。

しばらくテストをやってみた結果なのですが、以下の不具合が発生しておりました。

・SevenZipOpenArchive()が再びnullptrを返すようになってしまった。
・時々llWriteSizeが全解凍サイズ一歩手前で止まってしまうことがある。

中々難しいですね…。
587：x@rgs★：2020/07/20(月) 07:53:54 ID:???0: >>586

お世話になっております。
毎度毎度すみません。

>・時々llWriteSizeが全解凍サイズ一歩手前で止まってしまうことがある。
前回削除した処理を再度実装しました。
これで上手くいかないとなると、なかなか難しいです。

>・SevenZipOpenArchive()が再びnullptrを返すようになってしまった。
当方の環境では再現できないため、誠に申し訳ないのですがtenteko様の環境でデバッグをお願いできますでしょうか…
今回の書庫にソースファイルを同梱していますので、
1.7-zipのソースコードを展開。
2.7-zip32.dll(公式)のソースコードを展開。
3.7z1900002_ungarbled(今回)のソースコードを展開。
でビルドできます。
MyOpenArchive.cppのCOpenArchive::Open()内、
438行目か446行目のg_StdOut.SetLastError(res)でエラー値(ERROR_FATAL=0x8102=33026)がセットされているはずです。
お手数をおかけいたしますが、よろしくお願いいたします。
588：tenteko：2020/08/03(月) 21:36:08 ID:nzIvPxNw0: こんにちは。

折角ソースコードまで用意していただいて恐縮なのですが、
私の方でデバッグするのは、今の知識と技術力では難しそうです…すみません。

そこで一つ提案なのですが、今の所、「7z1900002_ungarbled_debug200504」版が
最も堅牢・安定しているように思います。
こちらのバージョンでひとまず安定版としてみられてはいかがでしょうか。
589：x@rgs★：2020/08/11(火) 07:01:06 ID:???0: >>588

投稿ありがとうございます。
無理を言って申し訳ございませんでした。

debug200504をベースに、以後の不具合修正を取り込んだものをリリースというかたちにしたいと思います。
引き続きよろしくお願いします。
590：x@rgs★：2020/08/17(月) 22:02:34 ID:???0: >>588-589

debug200504ベースの人柱版を公開しました。
問題がなければこのままリリースしたいと思います。
591：x@rgs★：2020/08/22(土) 22:40:24 ID:???0: >>588-590

Ver.19.00.00.02を公開しました。
592：kiyohiro：2020/08/23(日) 13:23:02 ID:OgaZs.BA0: どうもお世話になってます
Tascher 1.63
ですが
WinXp未対応ですか？
以下のウィンドウが出て起動出来ませんでした
---
Tascher.exe - コンポーネントが見つかりません
PROPSYS.dll が見つからなかったため、このアプリケーションを開始できませんでした。アプリケーションをインストールし直すとこの問題は解決される場合があります。
---
未対応の場合旧バージョンを使わせていただくので構わないのですが
Readme.txt
【動作環境】　Windows XP以降
とあるのでバグの可能性もと思いまして報告します

また、上書きしてしまったので
XP対応の旧バージョン(Tascher162.zip)をダウンロード出来るようにお願い出来ますか？
よろしくお願いします
593：x@rgs★：2020/08/25(火) 01:12:14 ID:???0: >>592

いつもお世話になっています。
一応はXP対応です。
起動できなかった原因はPropVariantToString()で、この関数はXP SP2以降であれば対応していますが、Windows Desktop Search(WDS) 3.0以上が必要です。
既にWDS 3.0は公開されていないようなので、動的リンクした人柱版を公開しました。
お試しください。
594：kiyohiro：2020/08/25(火) 15:24:28 ID:OgaZs.BA0: >>593
対応ありがとうございます
XP環境で動作確認しました
595：kiyohiro：2020/08/25(火) 16:26:49 ID:OgaZs.BA0: >>594
Microsoft®Update カタログ
でWDSを検索すると
Windows XP 用 Windows サーチ 4.0 (KB940157)
を見つけたのでインストールすると
Tascher 1.63
も動きました
596：x@rgs★：2020/08/26(水) 07:20:42 ID:???0: >>594-595

報告ありがとうございます。
無事動作したようで何よりです。
597：通りすがりの人：2021/11/20(土) 14:57:21 ID:/A6T.bsU0: archer

要望：予め除外するウィンドウ（exe）を指定したい。

マルチウィンドウでの利用で、いくつかのソフトやウィンドウは常に表示してあるためスイッチに表示あると煩わしい。

--
gui4recesの作者さんだとは知らず、毎日使っております！ありがたやm(_ _)m
598：x@rgs★：2021/11/21(日) 21:28:42 ID:???0: >>597

投稿ありがとうございます。
archerとのことですが、当該ソフトは公開を停止しています。
Tascherのことでしたら、[高度な設定]-[フィルタ]-[除外するファイル名]で指定することができます。
よろしくお願いします。
599：597：2021/11/22(月) 04:02:24 ID:3ZXq2teU0: 作者様、ご返信ありがとうございます。

Tascherでした。
設定の意味を誤解しておりましたが、無事希望が叶いました。ありがとうございますm(_ _)m
600：x@rgs★：2021/11/22(月) 07:14:49 ID:???0: >>599

分かりにくい設定ですみません。
解決したようで何よりです。
601：597：2021/11/22(月) 12:26:18 ID:zGZwmaUU0: 度々失礼いたします。

標準Alt+Tabと置き換えるべく、置き換え設定例はありますでしょうか？
Tascher表示にAlt+Tab指定すると「ホットキーの登録に失敗しました」と出ますが、とりあえず表示は別ソフトAutoHotKeyでなんとか解決。
「Alt押しながら」の挙動をシートカットに指定できず困っておりました。
602：x@rgs★：2021/11/22(月) 22:08:41 ID:???0: >>601

Tascher単独ではAlt+TabやWin+Tabを置き換えることは現在できません。
AutoHotKeyとの組み合わせ、例えば、
1.Tascherの[設定]-[表示(Alt+Tab風)]で、[次のアイテムを選択]を「Alt+[」、[前のアイテムを選択]を「Shift+Alt+[」に設定。
2.AutoHotKeyで「!Tab::![」
で表示できるかと思います。
#表示(Alt+Tab風)設定は現在公開中の人柱版から実装された機能です。

よろしくお願いします。
603：597：2021/11/23(火) 00:45:27 ID:QhptAkeA0: ご丁寧にありがとうございます。

なんと、すでにAlt+Tab風なるものがあったのですね！さっそく試してみますm(_ _)m
604：通りすがりの人：2021/11/30(火) 23:06:20 ID:3TvlCvBc0: いつもありがたくTimeStamp Keeperを使わせてもらってます。
ファイルの誤字を修正する際などにこれがあると大変便利です。

そんな便利なTimeStamp Keeperですが、1点だけ要望があります。
それは「クリア」実行前の確認機能の追加です。

まれにですが「復元」を押すつもりが誤って隣の「クリア」を押してしまい
「あ゛��！！」となる事があるので、
「復元」が押される前に「クリア」が押された場合は
確認ダイアログを出す、的なオプションがあると大変ありがたいです。

ご検討宜しくお願い致します。
605：x@rgs★：2021/12/01(水) 01:18:57 ID:???0: >>604

投稿いただきありがとうございます。
「復元前に確認ダイアログを表示」「クリア前に確認ダイアログを表示」設定を追加してみました。
それぞれ、引数「/cr」「/cc」を付加して起動すると、あらかじめ有効にすることができます。

手抜きのため、ご要望のあった「復元」が押下される前かどうかの判断はしていません…

ttp://frostmoon.sakura.ne.jp/TimeStampKeeper/debug.html

よろしくお願いします。
606：604：2021/12/01(水) 21:49:26 ID:c3ePbgGs0: >>605

迅速なご対応どうもありがとうございます！

早速使わせてもらいましたが、機能としてはこれで十分です。
コマンドライン引数での起動も問題無く動作しております。
これで間違ってクリアしてしまう事も無くなり、
ますますTimeStamp Keeperが使いやすくなりました。

こんなに早く対応して頂けるとは思っておりませんでした。
お忙しい中本当にどうもありがとうございました。
607：x@rgs★：2021/12/01(水) 22:53:19 ID:???0: >>606

無事動作したようで何よりです。
しばらく様子を見てから正式版として公開します。
608：604：2021/12/02(木) 06:09:50 ID:c3ePbgGs0: 承知しました。
もし何かあれば報告します。
609：さすらい猫：2021/12/14(火) 01:34:27 ID:Qu9EAeEo0: 深夜ですがこんばんは
ここんとこで、あぷろだ系のサイトから多量のデータを落として、久々にashleyを使おうとしたのですが…
ファイルはashleyに放り込めるんですがリネーム等の処理がまるでできないことに気が付きました。
旧PCから乗り換えた新PCで処理しようとしたんですが、Win10の最新版ではまだ対応できていない感じでしょうか？
旧PCもWin10でアップデートかけていないので１年前ぐらいのバージョンのままですが、そちらでは正常に処理できました。
ランタイムエラーも出ていないので、ちょっと原因がわからない状態です。

お忙しい中かもしれませんが、対応よろしくお願いいたします。
610：さすらい猫：2021/12/14(火) 23:14:55 ID:Qu9EAeEo0: どうやら、zipファイルの場合はリネームできるのですがrarファイルだけリネームできていないようです。
rarファイルのみなので、自分が使っているwinrar等の解凍する環境の違いかもしれませんが、原因特定には至らない状態です。
611：x@rgs★：2021/12/15(水) 00:43:03 ID:???0: >>609-610

投稿ありがとうございます。
最新版のUnRAR.dll(Ver.6.10.3.343)で確認してみましたが、
通常のRAR書庫であれば内部のフォルダ名やサムネイルの取得ができました。
件の書庫ファイルがさすらい猫さまの旧PCで処理できるようであれば、
一度新PCで最新版のUnRAR.dllを導入いただき、お試しください。
612：さすらい猫：2021/12/15(水) 02:52:16 ID:Qu9EAeEo0: >>x@rgs★さま

UnRAR.dllの最新版をAshleyのフォルダに入れて試してみたら、問題なくリネームできるようになりました！
早速の対応、ありがとうございます！
今までの旧PCの方でもWinRARを使ってたのですが、UnRAR.dllをAshleyフォルダに入れなくてもリネームできてたんで、気が付きませんでした(;^ω^)

このAshleyに成り代わるアプリは他にないので、とても重宝しています。
これからもどんどん使っていこうと思います！本当にありがとうございます！
613：x@rgs★：2021/12/15(水) 20:06:51 ID:???0: >>612

解決したようで何よりです。
また何かありましたら、お気軽にお知らせください。
614：kiyohiro：2021/12/31(金) 17:09:43 ID:gnMqvq6g0: どうもお世話になってます
7-Zip-zstd ｈｔｔｐｓ：／／github.com/mcmilk/7-Zip-zstd
を見つけこれの7z.dllを使い最近たまにもらうTest.tar.zstを
reces&ax7z.spi&7z.dll(/Ds"D:\Software (x86)\reces\spi" /me /c2 /ct /qe)
で解凍出来ないかと試しましたが
サイズ0のTest.tarが解凍されダメでした
2重の拡張子がダメなのかと思いましたが
Test.tar.gzはtar32.dllでですが問題無いですし行き詰まりました
単にオプションが間違ってるのでしょうか？
すいませんがアドバイスもらえないでしょうか？
ちなみに
画像ビューアなどではax7z.spi&7z.dllで中身を表示出来ました
ax7z.spi.iniもzst=1になってます
あと
7-Zip-zstd対応の
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版
は出来ないでしょうか
よろしくお願いします
615：x@rgs★：2021/12/31(金) 23:29:27 ID:???0: >>614

ご報告いただきありがとうございます。
人柱版を公開いたしましたので、ご確認ください。
616：kiyohiro：2022/01/01(土) 13:00:01 ID:gnMqvq6g0: >>615
修正ありがとうございます
解凍出来るようになりました
ただ、Test.tar.zstでTest.tarが解凍されもう一度解凍が必要になるので
出来ればTest.tar.gzのtar32.dllの解凍の様に2重の拡張子一気に解凍出来ないでしょうか?
zstは使いづらいので7zに再圧縮(Ds"D:\Software (x86)\reces\spi" /mr7z /lx /e /t)
などしたいのでよろしくおねがいします
あとWin10x64環境ですが
/Ds"D:\Software (x86)\reces\spi"
の様にパスを""でくくらないと認識しないのですね
WinXpは無しでもパスが通るので気付くのに時間がかかりました
こちらはReadme.txtの説明がなかったので報告だけしときます
617：x@rgs★：2022/01/01(土) 23:50:27 ID:???0: >>616

動作したようで何よりです。
7-Zipでtar.zstが一度に解凍できないのは仕様です。
tar.gzやtar.bz2も同様で、7-Zipで解凍させるには、パイプを使うかバッチを書くことになると思います。
もしかしたら、xzの時のように、zstdに対応したtar32.dllを誰かが開発するかもしれません。

/Dsオプションの件、パスにスペースがある場合は二重引用符で囲む必要があります。
これは/Dsオプションに限らず、他のオプションや入力ファイルも同様です。
618：kiyohiro：2022/01/03(月) 14:36:06 ID:gnMqvq6g0: >>617
> 7-Zipでtar.zstが一度に解凍できないのは仕様です。
分かりました
> もしかしたら、xzの時のように、zstdに対応したtar32.dllを誰かが開発するかもしれません。
7-Zip-zstdのCodecs-x32.7zのzstd-x32.dllや別に見つけたzstd.dllで
/ms[library][:prefix]
で解凍出来ないか試しましたがよくわからず
ファイラーやランチャーに登録してるのでそれほどてまでもないですし
結局1つずつ順番に解凍するのが早いですね
今回も色々ありがとうございました。
619：通りすがりの人：2022/01/30(日) 09:06:00 ID:OmOSGxQU0: Susieプラグインのdllとして使用。
ax7z_s.spi （ax7z-0.7-457s_y4b5.zip）から
7z1900001_ungarbledを使っていた。
久しぶりに更新したら、
7z1900001_ungarbledでは、rar書庫は開けたが、
7z2106001_ungarbledでは、rar書庫は開けなかった。
報告まで。
620：x@rgs★：2022/01/30(日) 10:41:31 ID:???0: >>619

報告いただきありがとうございます。
確認したところ、手元の環境では無事動作しました。
うまくファイルを配置できているか、念のためご確認いただけますでしょうか。
621：kiyohiro：2022/02/22(火) 18:58:54 ID:bGQIxGGM0: どうもお世話になってます
ライブラリ指定の
例　/me7-zip32
ですが
Spi(ax7z.spi)の指定はどうするのでしょうか?
または出来ないでしょうか?
622：x@rgs★：2022/02/23(水) 01:13:40 ID:???0: >>621

毎度ありがとうございます。
解凍であれば、「/meax7z.spi」で指定できます。
もし、「対応していない圧縮形式かファイルが壊れています。」とエラーが出た場合は、
「7z.dll」が存在するか確認してください。
「ax7z.spi」と同じ階層か、7-Zipがインストールされたディレクトリから読み込む仕様のようです。
「ax7z.spi」と同じ階層に「7z.dll」をコピーする方が楽かもしれません。
623：kiyohiro：2022/02/23(水) 05:25:34 ID:bGQIxGGM0: > 622
回答ありがとうございます
/meax7z.spi
で指定解凍出来ました

それで
画像ビューアのax7z.spi＋7z.dllで文字化け
の原因の特定が出来ました

recesではtar32.dllで解凍されるので気づきませんでしたが
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 v21.06.00.01の
7-zip32.dll
と
ax7z.spi＋7z.dll
.tarで圧縮したShift-JIFのテキストの
解凍ですが文字化けするみたいです
624：通りすがりの人：2022/02/23(水) 16:51:04 ID:E070r8vg0: 別の者です。文字化け再現しました。
昔のzipですが、MINT310.ZIPの中のmint-3.10/madoka/でぢかめ整理.misが文字化けします。
本家7-Zipの21.07 21.06でも文字化けし、19.00では文字化け無しなので19.00系の7-zip64.dllを利用して回避してます。
625：x@rgs★：2022/02/23(水) 18:38:47 ID:???0: >>623
>>624

ご報告ありがとうございます。
文字化け確認できました。
21.02の仕様変更が原因のようです。

21.07にも追い付けておらず、更新停滞気味ですが、
対応予定ですのでしばらくお待ちください。
626：kiyohiro：2022/02/23(水) 19:04:19 ID:bGQIxGGM0: >>625
回答ありがとうございます
もう一つ質問お願いします
同じオプションとspiパスでspiフォルダにUNBYPASSも入れましたが
x64版recesの方だけ解凍出来無いです
Win10x64環境

x86版は問題なく解凍出来ました
/Ds"D:\Software (x86)\reces\spi" /meax7z.spi /c2 /ct /qe /q0

x64版はエラー(ライブラリax7z.spiの読み込み失敗しました)
/Ds"D:\Software (x86)\reces\spi" /meax7z.spi /c2 /ct /qe /q0

UNBYPASSは入ってます
D:\Software (x86)\reces\reces.exe
D:\Software (x86)\reces\x64\reces.exe
D:\Software (x86)\reces\x64\UNBYPASS.DLL
D:\Software (x86)\reces\x64\UNBYPASS.EXE
D:\Software (x86)\reces\spi\UNBYPASS.EXE
D:\Software (x86)\reces\spi\ZBYPASSA.SPH
D:\Software (x86)\reces\spi\ZBYPASSI.SPH
D:\Software (x86)\reces\spi\7z.dll(x86とx64入れ替えて両方試しました)
D:\Software (x86)\reces\spi\ax7z.spi
627：x@rgs★：2022/02/24(木) 23:50:27 ID:???0: >>626

x64版の場合は、ax7z.spiではなく、ZBYPASSA.SPHを指定することになります。
628：x@rgs★：2022/02/25(金) 07:28:22 ID:???0: 7-Zip 19.00ベースの文字化け対策版の公開を再開しました。
今回の問題は本家でも報告されていますので、次バージョンで修正されるかもしれません。
629：kiyohiro：2022/02/25(金) 16:01:30 ID:bGQIxGGM0: >>627
回答ありがとうございます
/Ds"D:\Software (x86)\reces\spi" /meZBYPASSA.SPH /c2 /ct /qe /q0
でもダメでした
一応画像です
ｈｔｔｐｓ：／／imgur.com/PdZpaGk
630：x@rgs★：2022/02/28(月) 07:33:04 ID:???0: >>629

確認いただきありがとうございます。
ax7z.spiの場合、たしかに動作しませんね。
axzip.spiであればうまく動作しましたので、
少し原因を調べてみます。
631：x@rgs★：2022/04/08(金) 23:26:03 ID:???0: >>629-630

遅くなりましたが、不具合を修正した人柱版を公開しましたので、ご確認ください。
632：kiyohiro：2022/04/09(土) 05:54:45 ID:ovUvUBZ60: >>631
対応ありがとうございます
今夜勤でwin10x64環境ではまだ確認できてませんが
取り敢えずwinxp環境でエラーがでて使えないようです
---
reces.exe - エントリポイントが見つかりません
プロシージャエントリポイント InitializeCriticalSectionEx がダイナミックリンクライブラリ KERNEL32.dll から見つかりませんでした。
---
よろしくお願いします
633：x@rgs★：2022/04/09(土) 07:59:48 ID:???0: >>632

毎度ありがとうございます。
32bit版のプラットフォームツールセットを「Visual Studio 2017 - Windows XP (v141_xp)」から「Visual Studio 2015 - Windows XP (v140_xp)」に変更しました。
ご確認ください。
(64bit版は変更なしです。)
634：kiyohiro：2022/04/09(土) 13:38:37 ID:ovUvUBZ60: >>633
対応ありがとうございます
winxp環境での動作
win10x64でのZBYPASSA.SPH&az7z.spiで解凍
確認しました
ただ、
Ds"D:\Software (x86)\reces\spi" /meZBYPASSA.SPH /c2 /ct /qe /q0
で
空フォルダの解凍
と
/c2 /ctオプション
が出来ないようです
635：kiyohiro：2022/04/12(火) 16:48:48 ID:ovUvUBZ60: どうもお世話になってます
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版
某ソフトで旧バージョンを使いたいです
残ってましたらVer.17.01.00.01 - 2017/08/29 zip版
再公開お願いします

> ファイルやフォルダが表示されない場合は使用している「dll」のバージョンによります。
> 動作を確認している「7z」の「dll」は以下です。
> ○Ver.17.01.00.01 - 2017/08/29
> ・7-Zip 17.01 betaをベースにビルド。
636：x@rgs★：2022/04/12(火) 20:31:21 ID:???0: >>634-635

空フォルダの解凍は、今のところax7z.spiは対応していないようです。

/c2や/ctの動作は当方の環境では確認できました。
もし動作しないようであれば、お手数ですが書庫を送付いただけますでしょうか。

17.01 betaベースのバージョンは下記からダウンロードできます。
ttp://frostmoon.sakura.ne.jp/dlcnt/download.php?download=7z1701001_ungarbled
637：kiyohiro：2022/04/13(水) 13:14:21 ID:ovUvUBZ60: >>636
再公開ありがとうございます
通常の解凍では問題なかったのでバージョンアップしてましたが
19.00.00.03
21.06.00.01
では
書庫内操作で空フォルダの表示＆解凍が出来ない様になってたので
助かりました

> 空フォルダの解凍は、今のところax7z.spiは対応していないようです。
分かりました

> /c2や/ctの動作は当方の環境では確認できました。
空フォルダがあるとダメだったようです
これもax7z.spiの関係みたいですね
以下の様になりました

1.7z
書庫内
1\
2\てすと.txt
3\
解凍
2\てすと.txt

2.7z
書庫内
1\てすと.txt
2\てすと.txt
3\てすと.txt
解凍
2\1\てすと.txt
2\2\てすと.txt
2\3\てすと.txt

あと
tar32.dll/tar64.dll 2.42 rev.7(私家版)
と本家
TAR32.DLL 2.43
がバージョンアップしてました
軽く試しただけですがrecesで問題なく動作しました
638：x@rgs★：2022/04/14(木) 00:39:01 ID:???0: >>637

>書庫内操作で空フォルダの表示＆解凍が出来ない様になって
21.06.00.01で試してみましたが、手元の書庫では無事解凍できました。
どのような書庫でも、空ディレクトリの解凍はできませんか。

>tar32.dll/tar64.dll 2.42 rev.7(私家版)
ご報告ありがとうございました。
639：Kiyohiro：2022/04/14(木) 04:56:10 ID:ovUvUBZ60: >>638
すいません説明不足でした
recesのことではなく>>635の某ソフトのことです
640：x@rgs★：2022/04/14(木) 07:17:20 ID:???0: >>639

動作が少し気になりますので、差し支えなければソフト名を教えていただけませんか。
(メールでもかまいません。)

よろしくお願いします。
641：Kiyohiro：2022/04/14(木) 11:21:33 ID:ovUvUBZ60: >>640
どうもお世話になってます
最初メールしましたがGメールでexeが含まれてるので
エラーでしたがもしかしたら行ってるかもです

ソフトはannsFMarchiveです
以前相談したソフトで今度は空フォルダでした
> annsFMarchiveで一部ファイルが表示出来なくなった件
> これは、
> Ver10.13 2021-02-03のバイナリだと拡張子なしのファイルが表示されないこ
> と
> を確認しました。

以下の様な書庫
---
1.7z&1.zip
中身
1\てすと.txt
2\
a\てすと.txt
a.a\てすと.txt
---
で
2\
a\てすと.txt
が表示されませんでした

ただ、あの後対応して頂いて現在修正されてます
最新はannsFMarchive v10.43
ttps://www.bonsfm.com/annsfmwindows/annsfmarchivewin

メニュー→ファイルの
「7z の通常書庫をテキスト形式で取得」
「7z の自己解凍書庫をテキスト型式で取得」
「Zip の通常書庫をテキスト形式で取得」
「Zip の自己解凍書庫をテキスト型式で取得」
チェックを外す
メニュー→設定→アーカイブパラメータ設定
解凍用ZipDLL選択→7-zip32.dll

で以前の仕様に戻り再現出来ると思います
完全戻るかは分かりません
642：Kiyohiro：2022/04/14(木) 13:49:26 ID:ovUvUBZ60: >>641
追記
サブで使ってるファイラーでも
7-zip32.dllでの空フォルダの表示同様でした
Double Window(v2022年02月22日)
ttp://www.st.sakura.ne.jp/~higashi/
643：通りすがりの人：2022/05/01(日) 20:48:28 ID:SE3aXeWs0: こんばんは。

こちらに投稿してよいのかわからなかったのですが、久々に7-zip系の文字化け対策版DLLをダウンロードしようと「Frost Moon Project」のトップページ

ttp://frostmoon.sakura.ne.jp/

にアクセスしたのですが、レンタルサーバーのデフォルトページみたいなのが表示されて、ダウンロードできなくなっているようです。
配布を終了されてしまったのでしょうか。
それとも他のページへ移転したのでしょうか。

以上、よろしくお願いいたします。
644：通りすがりの人：2022/05/06(金) 19:17:27 ID:eG/vWEu60: こんばんは。

>>643 に投稿したものです。

すみません、この件ですが、結論からいうと解決しました。
こちらのブラウザの設定でhttpをhttpsに自動的にリダイレクトするようにしていたのですが、これが原因だったようです。
この設定で同じ「sakura.ne.jp」のアドレスでも問題ないサイトがあったので、原因を思いつくのにかなり時間を要してしまいました。
ご迷惑をおかけしました。

それでは。
645：x@rgs★：2022/05/06(金) 23:00:12 ID:???0: >>642
ご報告ありがとうございます。
確認してみます。

>>643-644
すみません。当サイトは未だに常時SSL化できていません。
646：Kiyohiro：2022/05/07(土) 05:53:21 ID:ovUvUBZ60: >>645
両ソフト共、不具合報告し
現在空フォルダ表示出来るように修正されました
647：Kiyohiro：2022/08/23(火) 12:38:05 ID:ovUvUBZ60: どうもお世話になってます
reces
にコメント(注釈)付けオプションが欲しいです
(/tと一緒に使いたい)
見るのは/mL /q0でいけました

最近コメントを付けて欲しいと言われ
Readme.txtを見たのですが見当たらず
zip系dllのコマンドを見ると
reces.exe /mszip32j:Zip -z
で付けることが出来ました
だだ、これだとタイムスタンプが更新されてしまいました
(ファイラーでタイムスタンプのソートで管理もよく使うので更新無しにしたい)
ZIP32J.DLL(CMD_ZIP.TXT)にrecesの/tの様なコマンドは見当たらないので
要望としてお願いします
ご検討よろしくお願いします
648：x@rgs★：2022/08/24(水) 22:54:41 ID:???0: >>647

毎度ありがとうございます。
現状、7-zip32.dllどころか7z.exeでも対応したコマンドがないようです。
これらでサポートされれば、recesでも取り入れる予定です。

/mszip32jで処理する場合、拙作TimeStamp Keeperのような外部ツールを活用するしかないと思います。
(/msの特徴上、/tの対応予定はありません。)
649：Kiyohiro：2022/08/25(木) 13:23:07 ID:ovUvUBZ60: >>648

回答ありがとうございます
分かりました
TimeStamp Keeperを使うことにします

一応コメント付けでタイムスタンプ保持出来るソフトも有りましたが
ポータブルで使えずファイラーにも組み込めないので
recesでなんとか出来ないかと
reces.exe /mszip32j:Zip -z /t /q0
reces.exe /t /q0 /mszip32j:Zip -z
など試してましたが
やはり/msで/tは使えなかったんですね
650：takets：2022/11/09(水) 09:49:35 ID:otV8LTio0: 【OS】Windows11 22H2
【ソフト名】Tascher
【バージョン】Tascher164.zip(210508)
【症状】『アクティブな仮想デスクトップのウインドウのみ表示』の設定が動作しない
【再現手順】
1. 設定を開く
2. 高度な設定→アクティブな仮想デスクトップのウインドウのみ表示のチェックボックスをオンにする
3. OKボタンをクリックする
4. ホットキーでTascherの候補画面を表示させる

初めまして、Tascherを利用させていただいております。
Winodws11に更新した際、気になる動作がありましたので、
報告させていただきます。

上記操作を行うものの、候補画面が表示されません。
Windows11 22H2にする前は動作しておりました。

上記のような場合、どのような設定を変更すれば動作するようになりますでしょうか。
ご確認いただければ幸いです。
651：x@rgs★：2022/11/11(金) 21:02:08 ID:???0: >>650

投稿ありがとうございます。
手元の環境がWindows10のため未確認ですが、
IVirtualDesktopManagerの関係で仕様変更があったのではないかと考えています。
Tascherの修正まで少し時間がかかるかと思いますが、しばらくお待ちください。
652：takets：2022/11/12(土) 02:54:26 ID:otV8LTio0: >>651
ご回答ありがとうございます。
お待ちしております。
653：x@rgs★：2022/12/13(火) 23:12:01 ID:???0: >>652

遅くなりましたが、人柱版を公開いたしましたので、
ご確認のほどよろしくお願いいたします。
654：takets：2022/12/14(水) 19:16:01 ID:otV8LTio0: >> 653
人柱版の動作確認をしたところ、
報告させていただいた現象が意図通りに動作することを確認しました。

ご対応ありがとうございます！
655：x@rgs★：2022/12/15(木) 07:38:11 ID:???0: >>654

無事動作したようで何よりです。
また何かありましたら、お気軽にお知らせください。
656：通りすがりの人：2023/02/11(土) 00:52:34 ID:uhfhouSI0: 【OS】Windows10 1909 Home
【ソフト名】7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版
【バージョン】Ver.21.06.00.01
【症状】書庫内のファイルの内容が表示できない
【再現手順】LHMeltで書庫内のファイルを選択した状態で[編集]→[表示]
の操作を行なうと「解凍できませんでした」のエラーが表示されます。オリジ
ナル版のVer.9.22.00.02では正常にできていました。
657：x@rgs★：2023/02/13(月) 21:57:05 ID:???0: >>656

投稿いただきありがとうございます。
これは、7-Zip側の仕様変更によるものです。

LHMeltは「表示」で下記コマンドを送信しているようです。
e -hide "-wC:\Users\***\AppData\Local\Temp\LMEL000_" -r- "C:\Users\***\foo.7z" "-oC:\Users\***\AppData\Local\Temp\LMEL000_\foo\" -scsUTF-8 -- "@C:\Users\***\AppData\Local\Temp\LMEL000_\LM***.tmp"

このうち、@によるリストファイルの指定について、
7-Zip 17.01 betaで仕様変更がされ、「--」以下の「@～」は読み込みません。
ttp://frostmoon.sakura.ne.jp/diary/archives/8818

公式によると、「--」の前に「-i@listfile」で指定するようありますので、
もし文字化け対策版を使用いただくようであれば、LHMelt側での対応が必要になるかと思います。
658：656：2023/02/14(火) 00:06:28 ID:uhfhouSI0: >>657
了解いたしました。
LHMeltの作者であるMiccoさんに問い合わせるべきでしょうね…
659：x@rgs★：2023/02/14(火) 22:18:33 ID:???0: >>658

ただ、非公式なライブラリに対してLHMelt側に対応してもらうのは如何かと思いますし、
開発環境があるようでしたら、
「--」以下の「@～」を「--」の前の「-i@」に置換するようなラッパーを作ってしまうのが手っ取り早いかと考えます。
660：kiyohiro：2023/05/23(火) 11:25:10 ID:Vh0Na5xc0: どうもお世話になってます
reces.exeの64版ですが
/me /c2 /ct /qe
7-zip64.dll
UNBYPASS.DLL+UNLHA32.DLL
Win10x64
で
1.zip
2.lzh
の2つドロップ
LZHの方エラーが出て解凍出来ません
順番を変え
3.lzh
4.zip
の2つドロップだと解凍出来ました
LZH単体も解凍出来ました

画像 ttps://imgur.com/xG7Qcyw
ご確認お願いします
661：x@rgs★：2023/05/23(火) 22:28:18 ID:???0: >>660

毎度ありがとうございます。
もしかしたら、>>517-520 と同じ現象が起きているかもしれません。
lzhを先に読み込む場合は、UNBYPASS.DLL+UNLHA32.DLLが1つ目のファイル、7-zip64.dllが2つ目のファイルを処理しているため、
不具合は発生しませんが、
zipを先に読み込む場合、7-zip64.dllで1つ目のファイルを処理→2つ目のファイルも7-zip64.dllで書庫の確認をしてしまいエラーが発生している、
という状況かもしれません。

ご確認ください。
よろしくお願いいたします。
662：kiyohiro：2023/05/24(水) 12:04:26 ID:Vh0Na5xc0: >>661
回答ありがとうございます
そういえば以前もありましたね完全に忘れてました
家のPCの7-zip64.dllはrecesフォルダから削除して
System32の方だけにしてましたが
今回ポータブル用にUSBに入れてるreces(7-zip64.dll入り)
を使ったのでエラーが出ましたが
7-zip64.dll削除済みの方で試すと解凍出来ました
しかし
> 7-zip 19.00でSetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32|LOAD_LIBRARY_SEARCH_USER_DIRS)を呼び出すように処理
これポータブ環境で使うにはは面倒な仕様ですね
7-zip64.dllがシステムに入ってるPCではrecesフォルダ内削除
システムに入ってないPCではrecesフォルダに7-zip64.dllがないと他の作業出来ないし
いっそポータブル用は旧バージョンにすべきですかね
663：x@rgs★：2023/05/24(水) 23:43:40 ID:???0: >>662

LOAD_LIBRARY_SEARCH_USER_DIRSが含まれているので、
reces側でライブラリの読み込み先のディレクトリを指定するオプションを追加し、
そのディレクトリをAddDllDirectory()すれば、この問題は解決できそうな気がします。
いつになるか分かりませんが、次バージョンの追加機能候補とします。
664：kiyohiro：2023/05/25(木) 05:08:50 ID:Vh0Na5xc0: >>663
>いつになるか分かりませんが、次バージョンの追加機能候補とします。
よろしくお願いします
665：kiyohiro：2023/06/21(水) 13:58:46 ID:Vh0Na5xc0: どうもお世話になってます
7-Zip 23.01
か出たようなのでよろしくお願いします
ちなみに最近
tar32.dll/tar64.dll ver 2.47 rev.2(私家版)
も出ました
Zstandardがサポートされたようです
recesでtar32.dll/tar64.dllでのnew.zstの解凍も確認しました
tar32.spi/tar64.sphにリネームしてSusie Plug-inでの解凍も出来ました
/q0 /mstar32.dll:Tar --inverse-procresult=1 --zstd -c D:\test\new.zst
で圧縮も出来ましたが一緒にフォルダも圧縮されるコマンドが間違ってるのかな?
まあ、自分では圧縮しない形式なのでいいんですが
666：x@rgs★：2023/07/03(月) 01:05:30 ID:???0: >>665

毎度ありがとうございます。
7-Zip 23.01ベースの文字化け対策版を公開しました。
>>624 のZipファイルの文字化けは解消したはずですが、
>>623 のTarファイルの文字化けは手元の環境で再現できず、対応できていません。

次バージョンのrecesでは、今回のtar32.dllの更新を取り込み、zstdに対応予定です。
667：kiyohiro：2023/07/03(月) 14:56:06 ID:Vh0Na5xc0: >>666
バージョンアップありがとうございます
>>623 のTarファイルの文字化けは手元の環境で再現できず、対応できていません。
すいませんxpのパソコンの方に試したファイルが入ってると思うのですが
現在無限起動ループ状態でセーフモード起動、リカバリーディスクも受け付けずお手上げ状態で
確認出来ません
色々解凍しましたが問題ないので取り敢えず流してください
668：x@rgs★：2023/07/03(月) 23:54:35 ID:???0: >>667

確認いただきありがとうございました。
また文字化け等問題がありましたら、ご報告いただけますと幸いです。
669：ターディス：2023/10/12(木) 21:57:10 ID:zVTDWmkM0: 「Tascher」とても便利で大変気に入り愛用させて頂いております。
特にサブモニターに表示可能・サムネイルプレビュー対応・仮想デスクトップにも対応、この3点が他のソフトと比べ特に嬉しい所です。

ただ１点、alt+tabのようにすべてのウィンドウサムネイル一覧表示が出来ないのが少しだけ惜しいと思ってしまいます。

alt+tabはサブモニターに表示することが出来ません。サードパーティ制のソフトを利用しても

・「窓換え」　サムネイル表示不可
・「Alt-Tab Terminator」サムネイル一覧表示不可
・「VistaSwitcher」　同上
・「ExplorerPatcher」別仮想デスクトップのウィンドウ表示不可
・「DisplayFusion」機能が多すぎてメモリCPUを大幅に消費
・「Actual Multiple Monitors」同上
・「TaskCollection」マルチモニター非対応

と、私の要望に沿うものがなかなかありません。
いろんなソフトを探し回ったり、自作しようともしましたが知識が足りずずっと心残りでした。

大変不躾で無礼なお願いなのですが、どうかタスクリストの横に全てのウィンドウサムネイルを表示させる機能を追加しては頂けないでしょうか。
alt+tabをサブモニターにも表示したいという要望は私以外にもかなり多くあるようで、検索すると日本・海外問わずかなり見つけられます。

お忙しい中本当に申し訳ありませんが、どうかご一考のほどよろしくお願いいたします。
670：x@rgs★：2023/10/13(金) 16:39:17 ID:???0: >>669

投稿ありがとうございます。
サムネイル表示を選択中のウインドウだけでなく、
リストにある全てのウインドウで表示するとのことですが、
どのような表示方法が良いでしょうか。

現状の仕様基準で、選択項目に揃えて全てのサムネイルを表示させると、
サムネイルが重なりほとんど見えませんし、
サムネイルを縮小して表示させようとしても、
小さくてわかりにくくなりそうです。

そこで例えば、リスト横にサムネイルを2列並べて表示することとして、
選択中以外のウインドウは暗めで表示するとか、
選択中のウインドウを枠線で囲むであるとか、
選択項目に揃えて表示するようにし、選択項目がかわるごとに並べ替えるとか…
等色々とすれば、少しは分かりやすいかもしれません。
(実装できるかどうかは不透明です。)

一方で、ウインドウリスト側の表示方法をそのものを、
Alt+Tabのようにサムネイルメインに変更することは、
根幹からの仕様変更となり対応はおそらくできません。

ターディスさまの理想のサムネイル表示方法をご教示ください。
よろしくお願いいたします。
671：ターディス：2023/10/13(金) 18:24:56 ID:zVTDWmkM0: >>670
ご多忙の中勝手な要望に対しての返信、大変ありがとうございます。

個人的にはリストの横に3列くらいでサムネイルが表示され、選択中のウィンドウは目立つ色の枠線で囲むような感じだとありがたいです。
（ttps://postimg.cc/jnYS58s2 勝手ながら例を作成させて頂きました。）

あとはリストの周りを取り囲むように表示される…とかでしょうか…。

そしてそのサムネイル画像をクリックしても、そのウィンドウに切り替える事が可能であれば大変嬉しいです。
（本当に勝手なお願いで申し訳ありません。これも根幹からの使用変更に該当するのであれば、全然大丈夫です！）

お時間があれば追加して頂けるとありがたい限りです。
672：x@rgs★：2023/10/17(火) 01:56:52 ID:???0: >>671

画像まで用意いただきありがとうございます。
ウインドウリストを画面中央に配置するのではなく、ウインドウリスト+サムネイルの合計幅から中央を割り出すイメージですね。
ほかにも、画像の例でウインドウが10以上になったときにサムネイルが小さくなっても全て表示させるべきか、
9個を上限として入れ替えていくか等、いろいろと考えるべき項目がありそうです。

いつになるか分かりませんが、追加に向け検討いたします。
673：ターディス：2023/10/17(火) 17:00:18 ID:zVTDWmkM0: 確かに９個以上の場合などを考えると難しそうですね…。
「中央にリストを配置＆囲うようにサムネイルを配置」にすると中央は変わらず出来そうですが、使い勝手を考えると…といった感じでしょうか。

この度は返信等お時間を割いて頂きありがとうございました。
勝手ながら追加される日を期待しつつ待っております。
674：通りすがりの人：2024/03/14(木) 17:36:27 ID:0m2LYGWs0: Tascherを長年使っています。
私の使い方はタスクスイッチだけではなく、コマンドとショートカットキーを組み合わせてランチャーとしても使っています。
例えば、
コマンド No.3 c:\windows\explorer.exeを登録しておいて、ショートカットでCtrl+Eでコマンド No.3を割り当てておくとTascherからアプリの起動も出来て便利です。
一つ要望ですが、この方式でアプリを起動すると常に新規に起動になります。
もし可能なら、
ショートカットのコマンド実行
→タスク一覧に既にアプリが起動している→そのアプリに切り替える
→タスク一覧に既にアプリはない→そのアプリを起動する
というふうに選択できるオプションがあると便利です。
コマンド指定時に「何もせずに実行・切り替えてから実行」などがありますがここに「タスクがあったら切替え無ければ実行」のようなオプションがあるとb理です。
もし他の方法で似た指定が出来るようであればご教示下さい。
以上、よろしくお願いします。
675：x@rgs★：2024/03/15(金) 21:51:17 ID:???0: >>674

投稿ありがとうございます。
ご要望いただいた機能を実装した場合に、例えばexplorer.exeのウインドウが複数あるとどのような動作とするか…という問題があるように思います。
現状のTascherで対応する場合、AHKなりを実行対象として、選択中のウインドウハンドルを渡し、
スクリプト側でウインドウハンドル→プロセス名orIDを取得し、存在すればそのウインドウをアクティブ化、
なければプロセスを新規起動という処理を行うことが考えられます。
何だかTascherの存在異議が問われる処理ですが、最適解だと考えます。
676：通りすがりの人：2024/04/02(火) 09:25:15 ID:eiTkXNn.0: >>675
お返事ありがとうございました。
おっしゃるようにAHKで以下のようにtascherから渡されたexeパスからウィンドウハンドルを取得し、ウィンドウをアクティブにするか新規起動することで望むことができました。
WinGet,handle,ID,ahk_exe %1%

ひとつ気づいたのは、tascherのコマンド設定で実行ファイルのパスや引数をダブルクォーテーションで囲って保存しても再起動するとダブルクォーテーションが消えています。
実行ファイルのパスに半角空白が入っていたためクォートしたのですが、消えてしまいます。

次のバージョンアップの際にでも修正して頂けたら幸いです。
677：x@rgs★：2024/04/10(水) 23:24:33 ID:???0: >>676

ご報告ありがとうございます。
ひとまず、解決できたようで何よりです。
Tascherだけで対応できず申し訳ございません。

ダブルクォーテーションの件、GetPrivateProfileString()の仕様で、
「"」で囲まれていると、読み込み時に削除されてしまいます。
実行ファイルだと問題ないと思いますが、
引数だと「"」の削除により、例えば「"%D" "%F"」と指定して再起動すると、「%D" "%F」になってしまうはずです。

次回、この不具合を修正いたします。
ご指摘いただきありがとうございました。
678：通りすがりの人：2024/05/11(土) 16:23:42 ID:bDyFizkY0: キーボード起動でTascherを使っています。
Tascherのウィンドウが開くまでワンテンポ遅れる感じがするのですが、何かオプションを変更することで高速化できますでしょうか。
Alt+Tabなら一瞬でタスク切り替えが表示されますが、Tascherはちょっと間があり高速化できればと思っています。
679：x@rgs★：2024/05/12(日) 22:39:52 ID:???0: >>678

投稿ありがとうございます。
Windows11環境で確認されている不具合です。
人柱版で一応の対応として、
[ListView]EnumWindowsを1としてウインドウの列挙方法を変更するか、
[IIDGuid]
IApplicationView={372E1D3B-38D3-42E4-A15B-8AB2B178F513}
IApplicationViewCollection={1841C6D7-4F9D-42C0-AF41-8747538F10E5}
IVirtualDesktopManager={A5CD92FF-29BE-454C-8D04-D82879FB3F1B}
といったかたちでIIDGuidを直接指定することにより解決できるはずです。

人柱版は下記から入手できます。
ttps://frostmoon.sakura.ne.jp/Tascher/debug.html
680：通りすがりの人：2024/05/15(水) 09:15:23 ID:0m2LYGWs0: >>679
人柱版ありがとうございます。
サクッと開くようになりました。
ひとまず人柱版で使ってみようと思います。
681：通りすがりの人：2024/05/15(水) 09:53:44 ID:0m2LYGWs0: Tascher 1.64で、ショートカットのCtrl+Lに他のコマンドを指定しても置き換わりません。
部分一致のままになります。
682：x@rgs★：2024/05/15(水) 22:20:08 ID:???0: >>681

投稿ありがとうございます。
ショートカット設定は、キー等を設定した後、「保存」をクリックする必要があります。
ご確認ください。
683：通りすがりの人：2024/05/16(木) 09:11:19 ID:bDyFizkY0: >>682
お返事ありがとうございます。
「保存」で設定を反映させております。
Ctrl+Lは設定が反映されません。Ctrl+A、P、Wなどは反映されております。
ご確認をお願いいたします。
684：x@rgs★：2024/05/17(金) 04:53:19 ID:???0: >>683

失礼いたしました。
「保存」ボタンを押下したとき、ショートカットのリスト上は設定が変更されていますか？
その時点では変更されているものの、再度設定を開くと元に戻っている状態でしょうか。

Tascherを終了させ、「Tascher.cfg」を直接編集すると設定は変更できますでしょうか。
(Ctrl+Lは[ShortcutKey]588です。)

ご確認のほどよろしくお願いいたします。)
685：通りすがりの人：2024/06/13(木) 20:03:25 ID:9m8RVjKY0: 【OS】[Windows 10 Pro 22H2]
【ソフト名】[Tascher]
【バージョン】[Ver.1.6.4.0]
【症状】[「切り替えてカーソルをウインドウ中央へ移動」ができない場合がある]
【再現手順】[NanaTerryに切り替える]

NaNaTerryは同一タイトル名のトップウィンドウがサイズ有りとサイズ無しがあるようでタスク切り替えはできるのですが、カーソルの移動はできません。

Ver.1.6.5.0を使用したところうまくカーソルの移動ができるので、既知の問題なのかもしれませんが、一応ご報告しておきます。
686：x@rgs★：2024/06/14(金) 01:03:03 ID:???0: >>685

ご報告ありがとうございます。
Ver.1.65_Test221023において、
Delphi製の一部ソフトウエアでウインドウの移動(モニタ間含む)等ができない不具合を修正しております。
おそらくカーソルの中央移動も関連する事象で、解決できているようです。
687：kiyohiro：2024/06/14(金) 11:32:19 ID:zjVXVLyI0: どうもお世話になってます
7-Zip 24.06が出てるので
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版のバージョンアップ
よろしくお願いします
特に新しく追加されたzst形式(.tar.zst/.zst)を扱いたいです

recesに要望
/mc[type]
にzst形式の圧縮を追加してほしいです
解凍の方(tar64.dll)は出来てます
tar32.dll/tar64.dllに入ってるtar32249\tar32_2\src\test\test_2099.tar.zst
試しました
Readme.txt内
綾川的趣味之接続集さんのtar32.dll/tar64.dllは
>私のコードは全てClaybirdさんのリポジトリにマージされています。以後はこちらから取得するようにしてください。
になってます
アドレスも変わってますｈttps://ayakawa.x0.com/
よろしくお願いします
688：sase：2024/06/18(火) 03:24:26 ID:slOB/nvo0: Tascherを非常に便利に利用させて頂いております。
１点、質問なのですがTascherをコマンドライン等から起動した際に絞り込み（インクリメンタルサーチ）を行った状態で起動することはできますでしょうか？
（たとえば、コマンドライン引数を受け取って絞り込み状態でウインドウを表示する等）

もし機能として存在しない場合には、改修のタイミング等でご検討いただけますと幸いです。よろしくお願いいたします。

# 試した方法１
AutoHotKeyで、Tascher起動後に Send / SendRaw / SendInput / SendPlay / SendEvent でキーイベントを送出する
→ どうも入力レイヤーもしくは入力要素が違うようで、絞り込みが行われない

# 試した方法２
のどか（キー配列変更ソフト）で Tascherを呼び出した後にキー入力を送出する（AutoHotkeyより低レイヤー）
&ShellExecute("open", "E:\\e\\Tascher164\\Tascher.exe",,, ShowNormal) &Wait(1000) c h r o m e
→ 絞り込みは行われるが、入力エリアがその後のユーザーキー入力を受け付けなくなってしまうため、上記の場合には "chrome"という絞り込み以降を入力できない

Tascher 1.64
689：kiyohiro：2024/06/20(木) 06:47:11 ID:zjVXVLyI0: >>687
どうもお世話になってます
7-Zip 24.07が出ました
690：x@rgs★：2024/06/22(土) 22:50:17 ID:???0: >>687,689

毎度ありがとうございます。
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.24.07.00.01を公開いたしましたので、
ご確認ください。

recesについては、しばらくお待ちください。

>>688

投稿ありがとうございます。
Tascherの機能としては実装していませんが、
Tascherリストビューに対して、SendMessage(WM_CHAR)することで、
絞り込みができるかと思います。

手元のHSP3で動作を確認したコードです。

exec "C:\\Users\\～\\Tascher.exe"
await 1000
tascher_hwnd = FindWindow("TascherWindowClass",0)
tascher_hwnd = FindWindowEx(tascher_hwnd,0,"SysListView32",0)
sendmsg tascher_hwnd,WM_CHAR,'c',0
sendmsg tascher_hwnd,WM_CHAR,'h',0
sendmsg tascher_hwnd,WM_CHAR,'r',0
sendmsg tascher_hwnd,WM_CHAR,'o',0
sendmsg tascher_hwnd,WM_CHAR,'m',0
sendmsg tascher_hwnd,WM_CHAR,'e',0
691：sase：2024/06/23(日) 06:37:12 ID:slOB/nvo0: >> 690
お忙しいところお返事頂きありがとうございます。
教えて頂いたコードを参考にウインドウメッセージを送信したところ、動作を実現できました。ありがとうございます！
Tashcerの完成度は唯一無二ですので、これからも愛用させて頂きます m(__)m

TascherChromeFiltered.pyw（Python3で実装しました）
import time
import ctypes
from pywinauto import Application
import pygetwindow as gw

WM_CHAR = 0x0102

app = Application().start(r"E:\e\Tascher164\Tascher.exe")
time.sleep(1)

FindWindow = ctypes.windll.user32.FindWindowW
FindWindowEx = ctypes.windll.user32.FindWindowExW
SendMessage = ctypes.windll.user32.SendMessageW

tascher_hwnd = FindWindow("TascherWindowClass", None)
if not tascher_hwnd:
raise Exception("TascherWindowClass not found.")

tascher_hwnd = FindWindowEx(tascher_hwnd, 0, "SysListView32", None)
if not tascher_hwnd:
raise Exception("SysListView32 not found.")

for char in "chrome":
SendMessage(tascher_hwnd, WM_CHAR, ord(char), 0)
692：kiyohiro：2024/06/23(日) 09:50:21 ID:zjVXVLyI0: >>690
対応ありがとうございます
7-zip32.dll/7-zip64.dllはファイラー等でzstの解凍出来ました
ただ、7z.dllがファイラー/画像ビューアでzstを扱えません
ax7z.spi+7z.dllで試しました
7-Zip 24.07の7z.dllではzstを扱えます
よろしくお願いします
693：x@rgs★：2024/06/23(日) 17:10:30 ID:???0: >>691

無事動作したようで何よりです。
コードまで投稿いただきありがとうございました。

>>692
報告ありがとうございます。
修正したVer.24.07.00.02を公開いたしましたので、
ご確認ください。
694：kiyohiro：2024/06/23(日) 18:20:31 ID:zjVXVLyI0: >>693
修正ありがとうございます
ax7z.spi+7z.dllでzstを扱えるのを確認しました
これで最近増えてるzstを
ファイラー/画像ビューアで扱えるので非常に助かります
695：kiyohiro：2024/06/26(水) 10:58:24 ID:zjVXVLyI0: どうもお世話になってます
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.24.07.00.02 + reces
D:\Software (x86)\reces\x64\reces.exe /c2 /ct /NF /qe /{"D:\Software (x86)\reces\cfg\resize.cfg"
で文字化けしてるのを見つけたのでご確認お願いします

Extracting archive:
の所の日本語のパス名ファイル名が文字化けします
他の部分に同じパス名ファイル名が表示されてますが他は全部正常です
参考画像
ttps://imgur.com/24A6sP5
v23.01.00.01 だとこの部分、空でした
よろしくお願いします
696：x@rgs★：2024/06/27(木) 01:28:53 ID:???0: >>695

ご報告ありがとうございます。
不具合を修正したバージョンを公開いたしましたので、
ご確認ください。
697：通りすがりの人：2024/06/27(木) 08:16:56 ID:zjVXVLyI0: >>696
修正ありがとうございます
文字化けしないのを確認しました
698： kiyohiro：2024/06/27(木) 08:18:20 ID:zjVXVLyI0: >>697
名前抜けてました
699：x@rgs★：2024/07/21(日) 21:18:15 ID:???0: >>687
recesについて、遅くなりましたが、ZSTD圧縮に対応にしたほか、
>>517-520
>>660-664
の問題について、統合アーカイバライブラリ(*.dll)のあるディレクトリを指定する「/Dd」を追加しました。
AddDllDirectory()だと対応できない環境もあるため、/Ddで指定されたディレクトリ内から探すよう処理しています。
「/Dd.」とすると、カレントディレクトリから取得します。

人柱版として公開しています。
700：kiyohiro：2024/07/22(月) 08:37:50 ID:zjVXVLyI0: >>699
対応ありがとうございます
/mctzs
/Dd.
だけですが動作確認しました
とりあえずランチャーやファイラーに登録してる分
/Dd.を追加して使ってみます
これでポータブル環境でも使えて助かります
ちなみに/Dd. /me /c2 /ct /qeみたいに先頭に付ければ問題ないですよね
701：x@rgs★：2024/07/22(月) 21:54:00 ID:???0: >>700

ご確認いただきありがとうございます。
/Dオプションはオプション中でしたらどの箇所でも大丈夫です。
702：kiyohiro：2024/07/24(水) 12:39:58 ID:zjVXVLyI0: どうもお世話になってます
> ・Tar32.dllのZSTD圧縮に対応。typeに「tarzst」「tzst」「tzs」「tzstd」を追加
typeに「zst」追加おねがいします
自分ではZSTD圧縮は使わないのですが
ダウンロードやもらった
手持ちのファイルはどれも.zstと.tar.zstのようなので
よろしくお願いします
>/Dオプションはオプション中でしたらどの箇所でも大丈夫です。
うろ覚えですが/q0が以前場所によって一時停止しなかったので
703：x@rgs★：2024/07/30(火) 22:48:51 ID:???0: >>702

typeに「zst」を追加した人柱版を公開しましたので、ご確認ください。
704：kiyohiro：2024/07/31(水) 12:47:42 ID:zjVXVLyI0: >>703
対応ありがとうございます
動作確認しました
自分ではZSTD圧縮は使わないのですが
もらったZSTD書庫(.zstと.tar.zst)を編集したときは一応
元の形式に再圧縮したかったので助かります
705：x@rgs★：2024/07/31(水) 20:59:29 ID:???0: >>704

ご確認いただきありがとうございました。
問題がなければ、そろそろバージョンを区切り、正式版として公開し直したいと思います。
706：通りすがりの人：2024/08/14(水) 07:35:21 ID:zjVXVLyI0: 7-Zip 24.08 (2024-08-11) が出てるので
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版
よろしくお願いします
707：x@rgs★：2024/08/21(水) 20:47:22 ID:???0: >>706

ご報告ありがとうございます。
Ver.24.08.00.01を公開いたしましたので、ご確認ください。
708：kiyohiro：2024/08/22(木) 19:10:26 ID:zjVXVLyI0: どうもお世話になってます
>>687
でrecesのReadme.txt内のアドレスが変わってる
のをちょと書いたので
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.24.08.00.01
も確認したらこちらも複数古いみたいです
まあ、特に困るものでもないので報告だけ
recesも
>問題がなければ、そろそろバージョンを区切り、正式版として公開し直したいと思います
とのことなのでもう一度コメントしとこうかと
よろしくお願いします
709：kiyohiro：2024/09/21(土) 15:55:28 ID:zjVXVLyI0: どうもお世話になってます
reces v0.00r34ですが
/Dd. /c2 /ct /NF /qe /{"D:\Software (x86)\reces\cfg\resize2.cfg"
でリサイズして.rarから.zipに変換でエラーが出ました
error: 対応していない圧縮形式かファイルが壊れています。
/Dd.
無しで
/c2 /ct /NF /qe /{"D:\Software (x86)\reces\cfg\resize2.cfg"
なら問題ありません
よろしくお願いします
710：nuko：2024/09/22(日) 03:47:18 ID:2ZlzQmjk0: 【OS】[Windows 11 Pro 23H2]
【ソフト名】[reces]
【バージョン】[Ver.0.00r34]
【症状】[複数のパスを渡して連続処理しようとするとエラーが発生する]

お忙しいところ恐れ入ります。
最新版のrecesで複数のパスを渡して連続処理させようとすると
ひとつ目は正常に処理されるものの、ふたつ目以降に渡されたパスは全て
　｜　ライブラリを読み込んでいます...
　｜　error: 対応していない圧縮形式かファイルが壊れています。
とエラーが出てしまい処理できません。
個別圧縮・解凍・書庫テストの連続処理は全て上記のエラーが発生し、
一方で複数のパスを渡してひとつの圧縮ファイルを作成する場合は問題ないようです。

7-zip32.dll/7-zip64.dllを以前のバージョンのものに差し替えたらエラーは起きなかったので
「7-zip32.dll/7-zip64.dll文字化け対策版 Ver.24.08.00.01」の問題なのかなと。

お手数をおかけして申し訳ございませんが、ご確認をよろしくお願いいたします。
711：x@rgs★：2024/09/23(月) 01:01:23 ID:???0: >>709
投稿ありがとうございます。
再圧縮時の圧縮処理で/Dd.を展開する際のカレントディレクトリが、
再圧縮用の一時ディレクトリになっているため、
ライブラリの読み込みに失敗しているようです。
現バージョンで対応するには、絶対パスを指定する必要があります。

>>710
投稿ありがとうございます。
>>519 にある、7-zip 19.00の仕様変更によるものかもしれません。
7-zip32.dllをシステムディレクトリに配置したり、
/Ddで7-zip32.dllのあるディレクトリを指定すると動作しますか。
712：nuko：2024/09/23(月) 08:47:52 ID:2ZlzQmjk0: >>711

お返事をありがとうございます。
64bit版recesを使用させて頂いているので
・/Ddで64bit版recesの絶対パスを指定
・7-zip64.dllのシステムディレクトリへの配置
のパターンではそれぞれ問題なく動作して
カレントディレクトリ指定の/Dd.だと同様のエラーが発生しました。

とりあえず、dllのシステムディレクトリ配置をしておけば
何も問題がなくなるようなので、このまま使わせて頂こうと思います。
713：x@rgs★：2024/09/23(月) 21:09:06 ID:???0: >>712

返信ありがとうございます。
再圧縮の場合だと、>>709、>>711のとおりカレントディレクトリが一時ディレクトリに変更されてしまいますが、
連続解凍やテストで、手元の環境だと確認できませんでした。

原因を調査したいので、差し支えなければ、ファイル構成や実行したコマンド等お示しいただければ幸いです。
714：nuko：2024/09/28(土) 02:29:20 ID:2ZlzQmjk0: >>713

お返事が遅くなり申し訳ございません。
私の環境ですが、recesの「x64」フォルダーの中身を
「C:\Tool\Archiver\reces-x64」に配置（パスは環境変数に登録）した上で
UNBYPASS／UNLHA32.DLL／UnRAR64.dll／unrar64j.dll
TotalObserver.wcx64関係のファイルも入れております。
（前回のコメント時から「System32」にも「7-zip64.dll」をコピーしています）
普段は用途別のコマンドを登録したファイラーから選択パスを渡す形で使用しており
ファイラー上でのパス指定はコマンドプロンプトでのものと少し異なるので
【例】reces /q1 /qe /me /c12t {allfilepath|noterm}
同様の処理となるように、テスト用ファイルを配置したフォルダー上で
コマンドプロンプトを開いてテストをしてみました。
また、「Windows Sandbox」上で「7-Zip 24.08」「7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版」を
インストーラーでインストール、recesを同様の配置&環境変数登録をしてテストしてみても
同じような結果になったので、以下にまとめて記載します。
【〇】は問題なし、【×】【△】は何かしら問題ありという感じです。

◆圧縮：「test」フォルダーと2つのファイルを対象に普通の圧縮or個別圧縮
【〇】reces /q1 /qe /mc7z /t "test" "1.png" "2.png"
【〇】reces /q1 /qe /mc7z /t /e "test" "1.png" "2.png"
【〇】reces /DdC:\Tool\Archiver\reces-x64 /q1 /qe /mc7z /t "test" "1.png" "2.png"
【〇】reces /DdC:\Tool\Archiver\reces-x64 /q1 /qe /mc7z /t /e "test" "1.png" "2.png"
【×】reces /Dd. /q1 /qe /mc7z /t "test" "1.png" "2.png"
【×】reces /Dd. /q1 /qe /mc7z /t /e "test" "1.png" "2.png"
※上記2つは、1つ目の処理から「error: 対応していない圧縮形式かファイルが壊れています。」

◆解凍：7z/zip/rar/lzhをまとめて渡して連続処理
【△】reces /q1 /qe /me /c12t "test1.7z" "test2.zip" "test3.rar" "test4.lzh"
【△】reces /Dd. /q1 /qe /me /c12t "test1.7z" "test2.zip" "test3.rar" "test4.lzh"
【△】reces /DdC:\Tool\Archiver\reces-x64 /q1 /qe /me /c12t "test1.7z" "test2.zip" "test3.rar" "test4.lzh"
※3つ目のファイルの「ライブラリを読み込んでいます...」で処理がストップ。
※7z/zipのみ、rar/lzhのみに処理対象を絞った場合は問題ありませんでした。

また、7z.dll対応版「7-zip32.dll」「7-zip64.dll」インストール時は解凍結果が少し変わりました。
【〇】reces /q1 /qe /me /c12t "test1.7z" "test2.zip" "test3.rar" "test4.lzh"
【〇】reces /Dd. /q1 /qe /me /c12t "test1.7z" "test2.zip" "test3.rar" "test4.lzh"
【△】reces /DdC:\Tool\Archiver\reces-x64 /q1 /qe /me /c12t "test1.7z" "test2.zip" "test3.rar" "test4.lzh"
※3つ目のファイルの「ライブラリを読み込んでいます...」で処理がストップ。

あと、書庫テストは解凍処理と同様の結果でした。
以上、ご確認をよろしくお願いいたします。
715：x@rgs★：2024/09/29(日) 20:49:03 ID:???0: >>714

詳細な動作テストをしていただきありがとうございます。

◆圧縮の【×】について、
「/Dd.」と指定しているので、コマンドプロンプト上のカレントディレクトリからライブラリを読み込もうとします。
今回の場合だと、「テスト用ファイルを配置したフォルダー」が「C:\Tool\Archiver\reces-x64」でないと動作しません。
ご確認ください。

◆解凍の【△】について、
手元の環境では、rar書庫は処理でき、lzh書庫は処理できませんでした。
これは「7-zip64.dll」側でSetDefaultDllDirectories()しているため、
「UNBYPASS.DLL」がうまく「UNLHA32.DLL」を読み込めないことによると考えられます。
この現象に対応した人柱版を下記で公開いたしましたので、ご確認ください。

ttps://frostmoon.sakura.ne.jp/reces/debug.html
716：nuko：2024/09/29(日) 23:44:48 ID:2ZlzQmjk0: >>715

お返事をありがとうございます。

>>「/Dd.」と指定しているので、コマンドプロンプト上のカレントディレクトリからライブラリを読み込もうとします。
>>今回の場合だと、「テスト用ファイルを配置したフォルダー」が「C:\Tool\Archiver\reces-x64」でないと動作しません。
言われてみればごもっともですね…。ファイラーと同じ条件にしようとして間違ったことをしていました。
Windows Sandbox上で「7-Zip 24.08」「7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版」を
インストールしない状態（recesとテスト用ファイルの配置のみ）で、「C:\Tool\Archiver\reces-x64」から
【〇】reces /Dd. /q1 /qe /mc7z /t "C:\圧縮\test" "C:\圧縮\1.png" "C:\圧縮\2.png"
【〇】reces /Dd. /q1 /qe /mc7z /t /e "C:\圧縮\test" "C:\圧縮\1.png" "C:\圧縮\2.png"
というコマンドでテストしたら圧縮関係は問題がなくなり、解凍関係も人柱版のexeに置き換えた上で
【〇】reces /Dd. /q1 /qe /me /c12t "C:\解凍\test1.7z" "C:\解凍\test2.zip" "C:\解凍\test3.rar" "C:\解凍\test4.lzh"
というコマンドでテストしたら問題なく処理できました。

私の使っているファイラーでは、処理対象を選択したフォルダでコマンドプロンプトが開かれるので
どうしようかと思ったのですが、こちらも人柱版のexeに置き換えた上で
【例】cd C:\Tool\Archiver\reces-x64
　　　reces /Dd. /q1 /qe /mc7z /t /e {allfilepath|noterm}
といった感じに登録コマンドを修正すれば、圧縮・解凍・書庫テストも問題ないようなので
登録していたコマンドをひと通り書き換える形で、今回ご相談差し上げていた問題は解決できそうです。
旧バージョンのreces同梱の7-zip64.dll文字化け対策版に戻せば以前のコマンドでも処理できましたが
流石に2017年のものを使い続けるのもどうかと思っていましたし、これで最新版への移行がちゃんとできます。

以上、取り急ぎご連絡差し上げますので、ご確認をよろしくお願いいたします。
717：kiyohiro：2024/09/30(月) 11:58:08 ID:zjVXVLyI0: >>709
対応ありがとうございます
>●(暫定)開発履歴
> ○Ver.0.00r35a_Debug240929 - 2024/09/29
> ・「/Dd」オプションで指定されたディレクトリに対してAddDllDirectory()するように。(Special Thanks!:kiyohiro様)
AddDllDirectory()がなにか理解できてませんが変わらずエラーでした
参考画像ｈｔｔｐｓ://imgur.com/suC1OI8
よろしくお願いします
718：x@rgs★：2024/10/01(火) 00:59:24 ID:???0: >>716

ご確認いただきありがとうございました。
うまく動作したように何よりです。
ほかにご要望等ございましたら、お気軽にご連絡ください。

>>717

失礼いたしました。
TODOをうまく管理できておりませんでした。
カレントディレクトリ変更のタイミングを調整した人柱版を公開いたしましたのでご確認ください。
719：kiyohiro：2024/10/01(火) 10:23:30 ID:zjVXVLyI0: >>718
対応ありがとうございます
rar書庫1つならzipに再圧縮出来ました
rar書庫2つだと1つ目が成功、2つ目がエラーになります

[1 / 2] 'D:\Software (x86)\変換\1.rar'
ライブラリを読み込んでいます... D:\Software (x86)\reces\x64\Unrar64j.dll ver.0.00.17.00
略
'"D:\Software (x86)\Ralpha Image Resizer\Ralpha.exe" /ini=resize2.ini .'を実行しています...
ライブラリを読み込んでいます... D:\Software (x86)\reces\x64\7-zip64.dll ver.24.08.00.01
略
7-Zip (a) 24.08 + ungarbled patch (x64) : Copyright (c) 1999-2024 Igor Pavlov : 2024-06-19

Creating archive: D:\Software (x86)\変換\1.zip

Add new data to archive: 1 folder, 16 files, 6526272 bytes (6374 KiB)

Archive size: 6514067 bytes (6362 KiB)
Everything is Ok

[2 / 2] 'D:\Software (x86)\変換\2.rar'
ライブラリを読み込んでいます... D:\Software (x86)\reces\x64\Unrar64j.dll ver.0.00.17.00
略
'"D:\Software (x86)\Ralpha Image Resizer\Ralpha.exe" /ini=resize2.ini .'を実行しています...
ライブラリを読み込んでいます...
error: 対応していない圧縮形式かファイルが壊れています。
続行するには何かキーを押してください . . .

よろしくお願いします
720：x@rgs★：2024/10/02(水) 07:04:32 ID:???0: >>719

何度もご不便おかけし申し訳ございません。
修正版を公開しましたので、ご確認ください。
721：kiyohiro：2024/10/02(水) 18:22:58 ID:zjVXVLyI0: >>720
対応ありがとうございます
動作確認しました
722：綾川：2025/03/06(木) 17:31:06 ID:gN68uH7A0: Windows 11 Insider Preview 26120.3360にて、ungarbled版7-zip64.dll/7-zip32.dllが
正常に動作しないようです(ver 24.09.00.01で確認)。
追跡してみるかとbuild環境を整えてみたんですが旨く構築できなくてビルド出来ず、
コードのどの辺で転けているかまでは分かりませんでした。GetVersionは動いて、
CheckArchiveが旨くファイルを扱えてないような感じでしたが……。
723：綾川：2025/03/06(木) 20:41:00 ID:gN68uH7A0: なんとか環境構築できたのでVS2022 Community Edition 17.13.2で
ver 24.09.00.01をbuildしたところ、こちらは問題無く動作しました。

VSかライブラリのバージョンのせいなんでしょうかね……あるいは
こちらの環境の何かのせいなのか。
724：x@rgs★：2025/03/06(木) 22:28:22 ID:???0: >>722-723

ご報告ありがとうございます。
現在手元にWin11環境がないため確認できませんが、次回更新に向け調査したいと思います。
725：綾川：2025/04/06(日) 18:16:15 ID:gN68uH7A0: 原因が分かりました。
こちらの完全なミスでございました。
7z.dllを使う版と使わない版を逆だと思って使っておりました。恥ずかしい……。
726：綾川：2025/04/06(日) 18:53:33 ID:gN68uH7A0: 7-zip32.dll/7-zip64.dll ver 24.09.00.01で、ファイル名中にが (U+304B U+3099) が存在
するとが (U+304C)に変換されてしまうようです。
7z.dllを使わない版、使う版の双方共に確認しています。なお、7z.dllをungarbled版に添付
されている物ではなく、公式の7zをインストールしたものを使用すると変換されずにそのま
まになります。
727：x@rgs★：2025/04/06(日) 19:40:17 ID:???0: >>726

投稿いただきありがとうございます。
文字化け対策版は、Yak!氏による対 zip UTF-8 強制試行版 7z.dll (UTF-8 MAC 対応)パッチの内容を取り込んでいるため、NFCに正規化する仕様となっております。
現バージョンには、この機能を無効にするオプションはありません…。
728：綾川：2025/04/07(月) 07:03:32 ID:gN68uH7A0: 仕様ということで了解しました。