Dynamic Link Library
DLLが珍しかった頃「ドルル」と呼んだ人がいた。
Dynamic Linkとは、Windowsがプログラムを起動する際にプログラムファイルのリンク情報からDLLのエントリーの先にコード・セグメントを調整するチャンクコードをくっ付け、すぐにDLLのコードを使える仕組みのことだ。当時はOBJやLIBファイルを組み合わせてEXEを作るのが普通だったので、これと区別するための用語。当初PCのメモリは、数Mバイトしかなく、これを融通するためによく使うコード（Library）をどのプログラムからも参照できる様にしたものだ。
DLLの名前さえ知っていれば、自由に参照できるAPIもあり再利用しやすいが、作ったDLLの名前が別のアプリのDLLと偶然一致してしまったりすると、大変なことになった。大抵はBAT起動でPATH変数を書き換えて対応していたが、混ぜて使うのはダメ。
このため、いくつかの試行が繰り返されたのちに、OLEでライブラリィの登録や参照をラッピングする方式に落ち着いた。ここまでくるとライブラリィに対する要求は肥大化しており、プログラムをパーツとして扱うことが主体になってきたから、EXEも登録して使えるようになっていた。
こうなると、色々なOLEパーツを画面に貼ったアプリやEXCELファイルのローディングは非常に重くなってしまうのは想像が付くから、あまりにも大きなコードを必要とするパーツのOLEは画面専用コードのみとし、複雑なデータ参照やただただ重いだけの設計モードなどは別途DLLやEXEを呼び出すような工夫がなされている。
しかし、パーツとして扱いやすいものは、その当時の事情に合わせ最適化がほどこされていたものが多く、それ故にMSが無頓着にUIやAPIを付け替え幾層にも重なったWindowsの分厚いバージョン層に対応できない製品が増えていった。
そのため、パーツが新しいWindowsに対応するまで『手元のWindowsをアップデートできない』というジレンマが生じるようになった。
Windows7のXPモードやクライアントHyper-Vなどの仮想化は、「とりあえず新しいWindowsに買い替えてもらう」ためのアイデアなのだろう。
しかし、XPからWindows7のXPモードに移行した後に、Windows8.1のHyper-Vに移行するのは程度の差はあるものの「一式再インストールしなければならないので結構面倒」なことに変わりない、このことは「バージョンアップを数年ごとに繰り返すWindowsに載せるアプリを保守していくことはかなり面倒なこと」の傍証でもある。
同様にAndroidの分厚いバージョン層も大きな課題。
4.xのスマホ(SO-04E)と5.xのタブレット(NEXUS7)を使い分けてると・・・デスクトップのページ編集の方法がたまに判らなくなる。そう5.xでは「設定」の中で不要なページを消さなければいけないのだ。
MS-OFFICEもどう操作すればいいのか？
久々にMS-WORDを使ったら・・・
ヘッダーセクションを現在の位置から変更するって選んで、ヘッダーをいじると、前のページのヘッダーも書き換わってしまっている様に見えるが、⇔ボタンで後ろのペ－ジへ移動すると正常な表示に変わる。
EXCELにビットマップを貼れば、かならずＡ１に正坐させられる。たまにビットマップが２０％サイズで表示してたり、でも実は表示がおかしいだけ・・・
と表示系のバグが多すぎて困るが、良く見るとdocやxlsのファイルだ。
Windows×MS-OFFICEのダブルのバージョン層は
どうしようもないのだろう。
その上にVisual Studio層まで重なって来るのだ。
時々、画面が真っ青な顔になっても仕方がないような気がした。：）
Windows 10 で少し解決できたら、一気に移行が始まるんだろうけどね :)