WindowModePatch 0.70 Alphaを公開

WindowModePatchの更新情報です。0.69Alphaは欠番ではなく更新してもしそのまま何も書かないとどうなるのか?を実験してみたのですが対して変わらなかったので0.70Alphaでは更新情報を記事にします。

 

0.69Alphaは入力系の更新

念のためにスタブとしてDirectInputに関する入力変換は実装していたのですがいろいろと調べてみるとなんとなくこれが理由のような事象があったのでDirectInputも対象にして処理するようになっています。おそらくそれほど問題にはならない更新だと思います。バリバリにDirectXを使うようなゲームなら影響がある可能性はあるかもしれませんがこちらはADVゲームがメインですのでDirectInputをまともに使っている物は余り見ませんので。

 

0.70Alphaは初期ウィンドウサイズに関する更新

通常は自動的に内部からウィンドウサイズ変更命令を行ってサイズ調整をするのですがなぜかサイズ調整の部分だけ無視するプログラムもあるようで。いろいろと調べたのですがなぜサイズ調整のルーチンが無視されているのかがさっぱりわからず、仕方がないので初期ウィンドウのサイズを直接設定できるように変更してみました。こちらは通常この機能を使う必要は全くありません。さらにいうなら自動認識でうまくいっている状態ならなおさら使う必要はないと思います。あるとするならウィンドウ検知に失敗するために描画サイズの固定を行っていてかつ外側のウィンドウサイズだけなぜか変更されない、こういう状態だけで有効です。また、設定は設定ファイルからのみ変更可能ですのでもしそんなゲームを対象にしたいのであればこの機能を使うとうまくいく「かもしれない」というものです。どうしてもこの手の記述って多くなってしまいますよね・・・

 

やっぱりまともに更新する暇がない

というのが現状ですか。0.70Alphaにかんしても調べて実装するまでは実効一日で終わってしまいましたし。単に思いついた後準備に手間取ったり都合がつかなくなってほったらかしになってしまったが故にTwitterに更新開始を書いてから今までかかってしまったわけですし。そうなると本当にコード公開やら何かを考えないと(これが宝かどうかは別として)宝の持ち腐れのようになるのかもしれませんね。

 

WindowModePatchのページに英語版を追加してみた

でも書いている記事は日本語な訳ですが…。

 

日本語ができない人の訪問が増えたようなので英訳してみた

頑張ってみました…といいたいところですがこちらも簡易です。やり方は簡単で適当な長さで区切った日本語の文を翻訳サイトで一度英語に訳した後再度自分が日本語に翻訳したときにある程度正しいか?をチェックして正しいならばそのまま、間違っているならば自分の知識内で修正を行って翻訳サイトにて再度日本語に翻訳して文法的な誤りがないかをチェックする、という手順で行っています。この頃のGoogle翻訳などの翻訳サイトは本当に質が向上しているので致命的な誤りが出ることがほとんどない状態となってきました。逆に言うなら翻訳結果が微妙となった場合であれば自分の日本語表現を多少変えてやることでそれなりの英文が出てくる、ということでもあります。

もちろん、この方法を使うためにはある程度自分に英語から日本語への翻訳ができる、という条件が必要です。一応英語の技術文書であればMSDNなどのプログラムのヘルプで読み込んでいるので単語の意味が調べられるのであれば問題ないレベルにはなっています。もちろんこの力がないと翻訳サイトを二回使う、という状態となりチェックが微妙になるのでは?と思います。さすがに二回の翻訳を行うと原文と離れた文となることも多くなるのでその辺はうまくやりましょう。

 

WindowModePatchで別方向の進展がありそうな感じ

忙しい合間を縫って動いています。まあ、これのために英語版のサイトを作ってみたというのが実情だったりします。一応ゲームの対象は日本語だけではないですし、WindowModePatchのフロントエンド側には日本語版のWindows以外で起動した場合には英語でメニューなどを表示するように仕掛けがしてあるのでいろいろな人と協力してやっていくのにはこういうことが必要になるのでしょうね。あとはトップページとか更新履歴なんかも英語になればもっといろいろな人に広がるなど情報が得られるのではないか?とも考えています。

また、Twitterやニコニコ動画などからのリンクがあったりといくつか確認している限りではWindowModePatchはある程度役には立っているようですのでうれしいです。こちらの方向も進展していくと面白いと考えています。忙しいので更新は難しいかもしれませんが動作情報などは受け付けていますので。

 

WindowModePatch 0.68 Alphaを公開

実はこの記事を書く時点で公開してからすでに一週間経過していたりするのですがそれはおいておきましょう。前回の更新から半年前後経過していて忘れ去られていたのかといえばさにあらず。いまだけ時間を作ることができる状態だったことと気になったプログラムが残ったままになっていたので自分でサンプルを作って仮想マシン上で動作をテストすることで修正点を見いだすというマッチポンプではないけれども似ているようなことを二週間前くらいから行って更新にこぎ着けました。

 

主な更新は二つ

基本的には以下になります。

  • DirectDrawをDirect3Dでエミュレーションを行う場合に8bitパレット処理における互換性の向上
  • パッチ対象の拡張子がexe,dll以外である場合に処理が行うことが非常に困難であったので修正

サンプルプログラムを作ってテストしていたのは前者で特に文字列描画で文字色が本来白色にならなければならない場合での互換性が向上しているはずです。検証プログラムを詳細に書いてみて初めてわかる仕様というのもあるのですね…。後者は特に外部モジュールを読み込んで動作するタイプの場合に本体に非推奨の完全パッチ処理を行いライブラリのロード時に強制的にWindowModePatchを読み込ませるか外部モジュールそのものにパッチ処理を行うか…という選択肢で外部モジュールの拡張子がdllではなかった場合にリネームしないとパッチ処理ができないのが面倒ということで処理を変えました。元々パッチ処理では対象が実行ファイル系かどうかの判別が入っているので問題はないのですが、実際にそういうことが必要になるゲームに出会うとさすがに変えたくなるということだったりします。

 

付け加えようとしていた機能はなんだろう?

機能の追加については数ヶ月前に思い立ったことなのでどうしようとしたか今の自分には理解できない…じゃなくて。おそらく途中で解像度を切り替える機能とかのはずなのですが機能が中途半端に実装されているので今回の更新では対象としていません。というか数ヶ月前の私は最終的にどの形にして実装をするつもりだったのか、について今の私にはわからない、という状態だったり。おそらくは対象のゲームと関係のないキーの組み合わせを入れると別のダイアログが表示されて画面の解像度をリストから選ぶか入力するか、という感じだと思うのですが…。まあ、余裕があれば適当に実装してみたいと考えてはいます。

 

自分一人での更新も難しくなってくるのかな

フリープログラマというのも自分で宣伝できなかったり仕事を受ける人脈がない場合はフリーターより悪い状況と見えるので真面目に職に就こうかと思い活動しています。そうするとこのWindowModePatchのメンテナンスも全くできなくなる、ということになる予感がしておりもったいないような気がしているのでいろいろと方策を考えています。信頼できるほかの人にソースコードを更新できる権限を持ってもらって対応できるゲームを増やしていったり情報を集めたり、などですね。

なお、WindowModePatchに関するWikiもこのサーバー内に設置してあり、容量制限もつけたのでデザインが整ったら…と思っていたのですが使っているWiki(MediaWiki)が昔に記事を書いたときから見るとかなり更新されてしまったためにどうしても情報を書くときに使おうと思っているWikipediaのテンプレートであるInfoboxが正常に取り込めないという問題にはまっていて抜け出せないのですね。はてさてどうするのがよいのでしょうか…。

 

Hash Calculator 0.02を公開

というわけでハッシュ計算につきまして新規にいくつかのアルゴリズムを実装すると同時にバグ修正を行いましてHashCalculatorを更新しました。なんと初期公開が2012年末ということで4年以上間隔が空いているのがびっくりというところです。

 

計算可能なハッシュアルゴリズムの追加および更新をしてみた

一つ前の記事で自分のライブラリに追加する、という話は書いていたと思いますがアルゴリズムを追加するということはHashCalculatorも更新できるネタができた、ということだったのでマイナーなアルゴリズムだけではなくもう少しメジャーなアルゴリズムも追加してみました。今回追加したのは

  • BLAKE(224bit,256bit,384bit,512bit)
  • BLAKE2b,BLAKE2s
  • SM3

の3種類になります。BLAKEはSHA-3の公募が行われたときに最終候補にまで残ったアルゴリズムとして有名でBLAKE2系はそれの改良系であり、MD5並みの計算速度を持つということを売りにしているアルゴリズムです。SM3は中国で標準のハッシュ処理として計算方法が公開されているもので中国圏で開発されている規格などでハッシュ処理を使うときによく使われている形式となっています。BLAKEについては公募の関係でドキュメントなどもかなり豊富にあるのですがSM3は範囲がかなり狭く国が公開している中国語の物かIETFが公開しているドキュメントくらいしかないようでIETFのものがあるとは知らず実装テストが終わるまでずっと中国語のドキュメントを訳してやっていました。まあ、数式の部分は共通ですし訳す必要がある部分も中国語の文法などを簡単に知っていれば漢字の意味をある程度共通にとれるので難しくはないところがありがたかったです。

 

KeccakとSHA-3の計算方法は「終端が微妙に」違う

「皆さんも気をつけましょう」という話題です。SHA-3のアルゴリズムは本家であるKeccakをそのまま使っていますが最後のメッセージパディングの部分が微妙に違います。これはSHA-3の仕様をちゃんと確認してみるとよいですがKeccak本体だとメッセージパディングは数式を使わず言葉で書くと

1を追加して0を(ブロック長ビット数-1)まで追加後最後に1を追加する

ですが、SHA-3だとSHA3-nとSHAKEnでは

SHA3-n:01を追加してkeccakの終端処理(1を追加して…)を行う

SHAKE-n:1111を追加してkeccakの終端処理(1を追加して…)を行う

となります。このあたりは仕様書をちゃんと読んでおく必要があると思いますので気をつけてください。多分以前に作ったサンプルだとKeccakの終端処理を使っているために間違っているような気がしないでもないです。

 

中国の暗号化規格であるSMnって複数あるのですね…

SM2とかSM3とかSM4とかあるようです。多分日本語のサイトで言葉を検索すると全く違う単語に引っかかるでしょうね。私も時々「三國無双」の略称じゃないの?と考えしまうこともあるくらいですから。ちなみにそれぞれ

  • SM2:楕円曲線を使った公開鍵暗号方式
  • SM3:SHA-256相当のハッシュ関数
  • SM4:ブロック構造を使った共通鍵暗号方式

となっています。最新の規格もあるようですが今回はそこまでは見ていません。「中国製のCPUで処理に対応した、という記事を見て実装してみたいと思った」というなんとも微妙な動機でやり始めた今回の拡張ですがこの数年間で暗号にまつわることも大分発展したのだな、と思いました。なお私個人だと暗号に用いられる数学の根本的な部分を学びましたので楕円曲線でなぜRSA暗号が成立するのか?といった部分もいまなら説明できるようになっています。

 

ついでにコンパイラのバージョンもアップ

VisualStudio2005からVisualStudio2010に変更しまして対応OSもWin8系およびWin10系を追加しました。これが今回の副産物ですね。数年前にVisualStudio2005で作成して公開したきり一度も更新していないプログラムが複数ありますがそれもやった方がよいのかな…と思っているところです。

SM4(formerly SMS4)を実装してみた

久しぶりのプログラムネタです。題名を見ても「は?」としか思われないかもしれませんね。

 

SM4(formerly SMS4)とは

おそらくこれの意味がわからないと思いますので説明を。SM4を単体で検索してもまともに出てこないですしSMS4で検索すると今回のものとは全く無関係のことが出てくるほどマイナーなアルゴリズムですので。

このアルゴリズムですが実はブロック暗号アルゴリズムの一つで中国ではよく使われている形式です。中国国内で使われる無線通信の暗号形式として登場することが多いようで、これを実装してみようと思った理由がVIAもといCentaurの流れを汲む8コアx86 CPUが中国で登場していた模様 – やじうまPC Watchの記事を読んでいるときにSMS4が追加サポートされたという部分があり、「どういうアルゴリズムなのだろうか?」というところからどうせなのでプログラムとして実装してみよう、という流れでやってみました。

なお、ドキュメントなどを探せばわかると思いますが本来のアルゴリズムを説明した文章は中国語(汉语)で書かれていてそれを英語に翻訳したものが別に存在しています。ほとんどの人は英語版を読めばよいと思いますが中国語(汉语)が読めるのであればそちらのバージョンを読んでみてもよいと思います。汉语を少しですが勉強していたので読んでみたのですが、読み方はわからない漢字が大量にあっても文法がある程度理解できるようになったので意味を大筋で理解できるのが面白かったですね。

 

アルゴリズムはXOR、SBox置換、巡回シフトを1ラウンドとした複数ラウンド構成

暗号キーの作成も暗号化の手順もほぼ同じ手順(線形処理である巡回シフトの式が異なるだけ)で、かつ処理の構成の方法から暗号キーから内部暗号キーを作り出してしまえば暗号と復号は内部暗号キーを使う順番が逆になるだけ、という至ってシンプルなアルゴリズムです。何回か暗号処理を実装した人であれば最適化を考えなければ数時間で完了できるほどのものです。

一部面倒なのはこの手のアルゴリズムの実装では当たり前の話なのですがエンディアン処理をうまくすることです。巡回シフト演算の関係で32bitワードの状態での演算が必要でその部分がビックエンディアンで行う、という定義なのでリトルエンディアンを前提としたコードだとどの部分に変換処理を入れる必要があるのか、を正しくすることが重要になってきます。この部分に気がつくのに時間がかかったために資料に記述されている例と状態が合わないために四苦八苦しました…。

 

実装しても使い道が…

まあ、中国語(汉语)のドキュメントを直接読む機会となりよい経験ができた、というところでしょうかね。もちろん普通のブロック暗号なのでCBCなどと組み合わせれば普通にファイルの暗号化もできるのですが、だからといってゲームのアーカイブなどに使ってみても意味がなさそうですし。それ以外だと一からプログラムを組む機会が少なくなっていたのでそちらでもよい刺激になった、というところで。

もしコードを見てみたい、という人がいればコメントにでも書いてもらえれば追加で記事にするかもしれません。