Top  上へ  目次



Ver.19系の話


 個人的にAtom機やセレロン機を使っているので、Ver.18はものすごい改善が実感できているのですが、ある程度の性能があるPCだと見た目や体感がほぼ変わらないという残念な結果でした。
 今度は向こう5年くらいを見据えて、社会情勢に合わせた更新を進めていこうと思っています。
 具体的には配布形態の変更ですね・・・これまた機能に関係ないものが・・・。

 まず既にリリース済みの内容ですが、Ver.18.0.3.0で実施したのは「AVX2命令使用版」と「外部アプリによる脆弱性があっても動く版」の廃止ですね。
 「AVX2命令使用版」は高速命令が使えるけれども、使用前の初期化(モード切替)が遅いという弱点があり、並列処理化の波に飲まれて優位性が大幅に減ってしまいました。
 むしろ速度低下する条件が増えたこともあって、廃止に至りました。
 今どきはコンパイラオプション未指定の場合にSSE2を使うようになっているので、余計に大差なくなってきたと言えます。

 「外部アプリによる脆弱性があっても動く版」は「検出されると困る筋からの横やり」です。
 色々と思うところはありますが、大人判断で自粛させていただきます。

 まぁ、ほぼ使われていないであろう機能や、今だともっと良い外部ソフトがある機能の削減も含めて、exeやdllファイルの数を減らしていく方向です。
 というわけで、Ver.19に向けた課題をツラツラ書き連ねてみようと思います。
 とりとめもない話ですし、例によってやるやらないは未確定ですが、今後の方針を決めるのにご意見、ご感想でもいただければ幸いです。


DLLの削減

 英語版とか作れるように、リソース部分をDLL化していましたが、きれいさっぱり諦めます。
 ぶっちゃけた話をすると、長編小説に換算して5〜6冊分くらいのテキスト量がありまして、こんなもん誰がタダで作業するねん・・・というオチです。
 DLL数が減少することで、配布サイズの削減が見込めます。


64ビット版なのに、32ビット版のランタイムが必要なのは理不尽

 前述の配布サイズが減った分だけ、肥大化させます。
 具体的には、32ビットのコマンドを静的ビルド(ランタイム要らないビルド)に変更します。
 exeが1個あたり4〜8倍くらいにサイズが肥大化しますが、32ビット版の外部DLLを必要とするexeの数が着々と減らしている、そろそろ頃合いか・・・という時期的な話です。
 具体的には統合アーカイバプロジェクトDLLを使用する、Arc.exe、ArcPack.exe、ArcUnPack.exe、MArc.exeの4つのみになっています。

 Windows10のサポートが2025年10月14日で終了予定ということで、32ビット版の寿命はあと1年ちょいです。
 統合アーカイバプロジェクトDLLの利用も、それまでには不要になるように、と考えています。
 もっとも扱えるのはWindowsで標準サポートしているzip/tar/7zのみなので、LHAなどのサポートが消えるのって時代の変遷ですねぇ。
 数年は併用できるように上記のコマンドも消さない方向で考えてますが・・・Arc.exeは削除でもいいかな。
 (※Windowsのビルド番号によって扱える書庫の種類は異なります)


そもそもランタイム不要にしたい

 64ビット版のコマンドも全部静的ビルドにしちゃって、ランタイムを一切不要に・・・という方向で考えてます。
 インストールする際にランタイムインストールで管理者権限とか要らなくなりますし、手間もかかりません。

 課題事項としては、サイズがものすごい肥大化します。
 執筆時点で、7zip形式で配布サイズは5MB前後→24MBで5倍です。
 インストール先のサイズは10〜12MB前後→32ビット版で97MB、64ビット版で117MBと10倍になります。

 1個のexeのサイズが2〜3MB程度増えており、単純にexeやdllの数が多いので、掛算でサイズが肥大化するわけです。
 exeやdllの数を減らす取り組みの本質は、ここにあります。

 なお1個当たりのexeの消費メモリが増えますが、DLLの読み込み数も減りますし今どき気になるレベルではありません。
 exeやdllのサイズが肥大化しても、今やSSDの時代ですから性能的な足かせにもならないでしょう。

 強いて言えば、MFCの性能が著しく悪いCMap(ハッシュとか連想配列とか呼ばれるモノ)の劣化回避の仕組みが効かなくなるので、大々的な改修が必要になるという難点があります。
 具体的には、スクリプトの変数とか環境変数とかの管理部分ですけど、この辺りをSTLのunordered_mapなどへの置き換えてやらねばなりません。
 まぁ、遅いだけで動かないわけじゃないから・・・追々で良いかなぁ(遠い目)
※変数や環境変数の合計が、1,000個を超えたあたりから劣化しはじめます。


インストール形式を普通にしたい(案1)

 現在、普通のインストーラー形式ではない理由は酷く単純です。
 「今更インストーラーを作るのがメンドクサイ」
 これにつきます。
 経緯を語ると、Windowsにおけるインストーラーの歴史は、控えめに言ってクソです。
 方針が二転三転して異様と言って良い数の方式がありますし、無償で提供されていたものが有料化されたり、廃止になったり、新方式になったり、さんざん振り回されて懲りたというのがメンドクサイに含まれています。

 で、手元の版ですが、いわゆるMSI形式のインストーラーは少し手を入れれば可能だったりします。
 この方式ですと、32ビット版/64ビット版の重複部分のサイズが無駄に大きくなります。
 やるやらないは置いておいて、ARM64版のリリースも不可(インストーラー作成ツールの選択肢にありません)です。
 しかも、ウィルススキャンソフトに嫌がらせされますし、Chromeには100%ブロックされますので、何の解決にもなりません。
 しいて言えば、アンインストールが「一般的になる」だけとも言えます。


インストール形式を普通にしたい(案2)

 MSIX形式にするという案もあり、Windows Storeにて配信というルートになります。
 既にMicrosoft社様の方針が二転三転してまして、Microsoft社様はこういうサービスをすぐやめちゃうので信用できないというのが前提にあります。

 これもサイズ肥大化の制限が付きますが、当サイトへの通信量の圧迫を気にしなくて良いのと、ウィルススキャンソフトに嫌がらせされることが激減します。
 ユーザー権限でインストールが可能であり、アンインストールも簡単です。
 Windows Store配信なら自動サイレントアップデートも多分できそうなのが魅力です。

 課題としては、Program filesの下の隠しディレクトリという、Administratorsでもアクセスできないところにアプリが配置されます。
 As/Rはもちろん、エクスプローラーですら開けないパスなので、凝った使い方の多くが死亡します。
 具体的には、コマンドラインオプションで記述したり、Power Shellで実行したり・・・といった使い方ができないってことですが、ライトユーザーの方にはこの方が良いかもしれません。
 他にも、ユーザー情報の管理ディレクトリへ情報を保管場所を移す仕組みを考えないとダメなので、それなりに改修規模もあります。

 あとこの方式、カンパ受付用としての使い道もあります。
 Windows Storeなら有償にすることも可能なので、Windows Store経由は有償、サイトでの配布は無料という感じにしても良いのかなとも思います。
 ※サイトでの配布でのMSIX形式は証明書のインポートがめんどくさいですが、手順は確立できます。

 正直な話、現時点でARM64のPCや、Windows12の購入予定がないので、この辺りの対応予定は未定です。
 個人的に仕事で使うとしても、そんなに最新OSである必要がないですしねぇ・・・。
 20年以上も前から「私が使う分に困らなければ良い」というスタンスに変わりはありませんが、応援していただける方が多ければ対応しましょうというのもやっぱり変わらないスタンスです。