あるWindowsアプリケーションに対して、不特定多数のユーザーがそのアプリのディレクトリにDLLファイルを置くだけで機能を拡張するツールを公開している。

単独のDLLファイルを作成するだけで干渉できるならばアプリ全体の知識がなくても作成できるのでは？
と考えた。結果は迷走ののち異なったが。

結論

想像なので全部末尾に「だろう」や「と思われる」と付きますが、冗長なので省略します

ディレクトリ直下に置くだけでDLLファイルが何でも読み込まれるわけではない。
アプリケーションがもともとDLLの追加を想定していれば(MODのように？)別である。

第三者のカスタマイズを想定していないアプリへの干渉へはちょっとしたハックが必要。
具体的にはDLLの読み込み順を利用した既存DLLの改造？
DLLの探索順は(体感多くの場合)「exeファイルと同一ディレクトリ以下」 → 「WindowsがインストールしているDLL群」(それでもなければエラー)
なので、アプリが読み込むDLLを改造して他者が作成した追加のDLLを読み込む記述を追加する。
改造DLLがアプリ同梱なら上書き、Windowsに事前インストールを前提としているDLLならexeのディレクトリに同名で新規設置として、インストールされているDLLより先に読み込ませる。¹
たとえば、d3d9.dllを使うアプリに自作のmy.dllを呼ばせたい場合は、my.dllをloadする記述を追加したd3d9.dllを同時に用意してやればいい。
これで、そのアプリは直接はmy.dllを読み込まないが、依存するd3d9.dll経由でmy.dllを呼び出すことになる。

不特定多数がそれぞれ、アプリがもともと読み込むDLLを改造していくと、どこかで同一DLLを改造してしまう競合が発生する。
回避方法としていくつか考えられる
1. それぞれの拡張機能の作者が別々の標準DLLを改造する。
  基本的には後発が先発の操作DLLを調査して避けることになるか。
2. 後発機能作者が、先発機能作者の改造記述を引き継ぐ。
  後発が共存できるように配慮して、自分と他者のDLLの読み込み両方を記述してあげる。
  同一DLLファイルを編集する場合に後発が慮る方法。ただし先発の更新で齟齬の発生やメンテナンスコストの増大が考えられるか
3. 配下の任意のDLLをすべて読み込む「拡張機能管理」の拡張機能を作り、他をその配下にする。
  ゲームで言うMOD管理ツールのようなもの。ユーザー側で上下関係を作ってやれば、改造DLLは最小ひとつで済むはず。

前提筆者知識

C++
C#
.NET Framework
WIN32API
DLL

このあたりの知識がまったくありません。
9割を妄想で調査しています。

起動時のDLL不足程度なら自力でDLして解決できるかな？
程度です。

MMD (MikuMikuDance) の例

(拡張文化が目に入ったことからの調査なのでMMD自体は無知です)

MMDという3Dモデルを動かすツールがあり、その各種拡張ツールについて調べます。

MME (MikuMikuEffect)

おそらくもっとも導入されていそうな拡張です。

導入することでMMDの何もなかったメニュー右端に新たなメニューが追加されます。

ファイル構成は三つのDLLで、exeと同一の場所に置くことを想定されています。
仕組みは分かりませんが置くだけでインストール完了とはMMDは柔軟なツールなのだなあと当時は思っていました。

この機能は、(勝手に)拡張機能の大本だと見ましたので、競合回避のどれにも当てはまりません。
他の機能がMMEと競合しないように回避していきます。とします。

MMAccel

DLLインジェクション方式。MMEと併用可能なd3d9.dllが同梱されている。

MMEと併用可能なd3d9.dllが同梱されている。
この記述でd3d9.dllという共通のdllがキーなのかなと予想しました。
(ちなみにDLLインジェクション方式と解説されていますが、d3d9.dllの変更のことなのか機能の実現方法なのかが読み取れませんでした。おそらく後者だと思われますが)

【【MMDツール】MMDにショートカットキーを割り当てるツールを作ってみたより】

MMAccelは幸いにもソースコードが公開されているので適当に見てみると、DLLへの変換前のd3d9ファイルらしきものがありました。
逆アセンブルできないので助かります。

「MMEと併用可能」がキーワードなので、ヒストリーを眺めたりmmeで検索したりしてみます。

mmaccel/d3d9.cpp at master · LNSEAB/mmaccel

d3d9.cpp

void load_mme() 
{
	winapi::load_library( winapi::get_module_path() + "\\MMHack.dll" );
}

ありました。

MMEで配布されているMMHack.dllを読み込む記述が、MMAccelでなされています。

これが結論の回避方法その2ですね。
後発のMMAccelがMMEと同一DLLを編集しつつも、後から上書きしても大丈夫なように配慮しています。

ここから逆説的に、MMEの機能自体はMMHack.dllでありd3d9.dllの重要な役目は別のdllのloadである。という仮説を立てました。

MMDPlugin

MMDのプラグイン各種を簡単にインストールできるようにするツールです。基本的にこのツールを使用することを推奨します。

ということで、anyenvのように各種ツールを簡単にインストールしてくれるツールです。

MMDPluginを含めインストールを補助するMMDPluginInstallManagerは公開されていますが、MMDPlugin本体のコードは公開されていないのかな？

予想ではMMDPluginInstallManagerがインストールの自動化のみを行い、それで導入するMMDPluginが配下の各拡張(DLL)を読み込む機能を持っているのかなと思います。

MMDPluginのファイル構成は以下

またもd3d9.dllがMMEと競合しています。
が、readmeを読むと

・インストール方法
d3d9.dllとMMDPlugin.dllをMikuMikuDance.exeがあるフォルダに入れるだけです。
このツール単体では何も動作しません。

・MMEも使う場合
MMEをインストールするときに、plugin/mmeフォルダに入れるようにしてください

と回避方法が指示されています。
MMDPluginを入れるならば、全てMMDPluginで管理したほうがよさそうですね。

これが回避方法のその3、「拡張機能管理」の拡張機能かなと考えました。

MMDPluginInstallManagerが対応しているツール以外もMMDPluginが読み込んでくれるなら、自作のプラグインはこの機能経由で適用できるかもしれません。

MikuMikuPlus (MMPlus) (旧: AVI出力前に座標軸兄貴を消し忘れてたら教えてくれるプラグイン)

これがたまたま目に入ったのでMMD周りをいろいろ調べだした動画です。

機能を追加してMMDPluginを使わなくてもインストール可能なツールに生まれ変わりました！

前述のMMDPlugin依存からMMEのように単独でも動作するように昇格？された例です。(MMDPlugin配下でなくても共存できる(はず))

ではMikuMikuPlusのファイル構成を見ます。

今までのd3d9.dllと異なり、標準っぽいdllの同梱がMSIMG32.dllになっていますね。
回避方法その1、競合しないように改造DLLをずらす。がこれに当たるのかなと考えています。

利用者側としては単独で動くほうが嬉しいですが、裏側を知ろうとすると苦労が見えてきます。か？

機能開発がものすごく活発というわけではないので触るdllには困らなそうですが、逆に先の三つの機能がそろってd3d9.dllを触っている理由が気になりますね。
よく見かけるdllですし、各拡張機能によく絡むため挙ってこのファイルを操作しているのでしょうか？

おまけでMMDPluginが必要だったときのファイル(AVI出力前に座標軸兄貴～)も落としてみてみました。

MMDPluginを使う場合はやはりDLLは単体でよさそうですね。

ということで

4つのツールからDLLを使った機能の仕組みを結論の項のように予想しました。
手がかりはないかといろいろ探した結果、ひとつ仮定ができるとあれがそーなってとそれぞれの仕組みがドミノ式に分かった(気になって)調べものの楽しさを味わいました。

今回は末端の末端、インストール方法のみを手がかりに知識なしで調べたため信頼度は薄く役立つ情報でもないですが、無知な状態から取っ掛かりを探すことはなかなか難しいので考えかたの記録にでもなればいいかなと思います。
とりあえずGitHubで探してみるは大事。

調査時困ったこと

MMDのことを調べたくてもモデルデータの記事ばかりが引っかかり、
MMEのことを調べたくてもエフェクトファイル(fx)の記事ばかりが引っかかり。
プログラムの方向から調べることが難しかった。(そもそもDLLの題材として不適切か)
本体含めコード非公開だったが、いくつかの拡張がGitHubで管理されていたため、そこから予想を立ててみた。

性質上動画での説明が多くてそこもちょっと大変でした。が、見ていて華やかなので楽しかったです。

あとDLLやWIN32APIの解説記事を見ても全然作れそうになさそうなことですね…なにを見て入門すればいいのやら…

同一ディレクトリに入れればWindowsのそのDLLを参照する別アプリに対しては影響なしにできる ↩