遠い昔、多くのソフトウェアは速い動作が望まれ、遅いと罵られた。
今でも処理は速く終わったほうが良いが、昔ほどは罵られない。
昔は何もかも遅くて、ユーザーは待たされるのもので、常にイライラしてるものだった。
そういう背景もあり、中には無茶な高速化を施してしまった例もあったようだが、そういうのは避けたいという話だ。
自分がソースコードを見たわけではないので正確ではないかもしれないけど・・・。
Win32 APIにGetProcAddress()がある。
DLLが抱える関数のアドレスを取得する関数である。
引数に関数名の文字列を与えると関数を探すのに少々時間がかかる。
引数に序数を与えると少々高速化できる。
そこだけ見れば「序数の方がいいじゃん。速いんだし。」となるが、注意すべき点がある。序数と関数の対応の互換性だ。
仮にDLLがアップデートしたとき、序数と関数の対応が必ず維持される仕組みはない。
一度設定した対応が未来永劫に強制されることはなく、変更は可能だ。関数を削除することもできる。
つまり、自分がDLLを制御できない場合、指定した序数で目的の関数をアドレスを取得できなくなるかもしれないわけだ。
「序数の方がいいじゃん。速いんだし。」は「自分がDLLを例外なく100%自由に制御できるなら序数の方がいいじゃん。速いんだし。」となるわけだ。
で、問題が発生するわけだ。
「序数の方がいいじゃん。速いんだし。」しか考えず、副作用を考えず、あろうことか他社のDLLに対して序数でGetProcAddress()してしまった例があったようだ。
それが、いわゆるDLL HELLの正体の一部ではないかな?
序数と関数の対応は互換性が維持されるポイントではないので、自分が制御できないなら序数よりも関数名文字列で指定するべきだろうし、関数が存在しない場合の対応も実装すべきだろう。
Windows 95の登場で、長いファイル名を使えるようになった。
互換性のために、ファイル作成時に「長いファイル名」と「長いファイル名から作った短いファイル名」が作成され、どちらでもアクセスできるような仕掛けが追加された。
「Program Files」には「PROGRA~1」でもアクセスできるわけだ。
これにより、長いファイル名を知らないWindows 3.1用アプリケーションでも「長いファイル名」で作られたファイルにアクセスできる。
それだけなら「めでたしめでたし」だが、後に状況が変わる。
「長いファイル名から作った短いファイル名の作成」は抑制できるのだが、一部で流行ってしまった。無駄な処理を省けるから、その分だけ高速化できるという触れ込みで。
で、問題が発覚するわけだ。
Windows 3.1用でもないのに、短いファイル名でアクセス時するアプリケーションがあった。
短いファイル名でアクセスしたほうが若干速いという話だったと記憶してる。
「長いファイル名から作った短いファイル名の作成」があるから問題ないよね? と考えたのかもしれないが、その仕組みは抑制できる。そして残念ながら流行ってしまった。
トラブルを避けるため、長いファイル名を扱えるなら常に長いファイル名でアクセスするべきだろう。
どちらの場合も、遅いと罵られ、遅いと罵られ、遅いと罵られ続けることによって、「速度こそ正義で犠牲を出しても構わない」という意識が芽生え、判断が鈍ったのだろうと思う。
でも、動かないソフトウェアには価値がない。どれだけ高速化しても動作しないのであれば何の意味もない。
できるだけ幅広く状況に応じて適切に判断することを心がけたいと思う。