2026/05/12 2:17
3D モービーマーナーを Linux 向けに移植する
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
2026 年 5 月 9 日、Microsoft の「3D Movie Maker」（通称「Socrates」）は、3DMMEx を通じて Linux でネイティブにコンパイル及び実行できるようになり、Windows 外で動作する初のフォークとなった。これは、開発ツール、スクリプト言語用コンパイラ、ドキュメント、プリレンダリング済みアセットを含む完全なソースコードが、2022 年 5 月に Microsoft から寛容な MIT ライセンスの元にリリースされたことによる。1995 年の元ソースコードは、Alice Averlong（旧姓 Foone Turing）、Scott Hanselman、Jeff Wilcox および Microsoft チームによって確保され、リリースされた。
2024 年後半、著者は停滞していた3DMMForeverプロジェクトをフォークして3DMMExを作成し、Visual C++ を必要とする非標準化の C++ ダイヤレクト、Windows/Mac 68K 限定のカウアイ（Kauai）フレームワーク、直接的な Win32 API 呼び出し、インライン x86 アセンブリ、ポインタサイズ前提による 64 ビットエラー、未使用のアUTHORING ツール依存関係、静的ライブラリ、自動テストの不足を含む移植性課題に対応した。主要な技術的アップデートには以下が含まれる：BRender（Argonaut Technologies 製）の更新により手動で書かれた x86 アセンブリを移植可能な C コードに置き換え、Ghidra を用いて静的ライブラリAudioManのリバースエンジニアリングを行いクロスプラットフォームオーディオ用新しいminiaudioモジュールを追加し、カウアイ内の手動最適化済みインラインアセンブリを取り除いて現代的な C ランタイム関数を有効にし元C++のバグを特定し、単一テストを Google Test へ移植しカスタムデータ型（例：文字列クラス STN）用の NatVis ビジュアライザーを作成し、ファイル形式構造に対する静的アサートを追加し、UI ロジック内のスクリプト実行ログを記録する機能を追加した。Win32 GUI はSDLで置換され、システム列挙なしでフォント管理を再実装しキーボードアクセラレーターテーブル系を再構築し、内部文字列を CP1252/UCS-2 から UTF-8 へ変換することを必要とした。Linux への移植では Mark Cave-Ayland が POSIX サポートの実装、ファイル名ハンドリング問題の修正、FluidSynthによる MIDI 再生統合、シーンカット再生用のGStreamer追加などで支援した。
3DMMEx の現状の制限事項としては、特定の入力デバイスでアクターをドラッグする際のマウスハンドリングの問題と、不完全な UTF-8 ユニコードサポートが含まれる。今後の目標には macOS への移植および Emscripten ベースのウェブブラウザサポートが含まれる。x86、x64、ARM64 の Windows バイナリは GitHub Releases から入手可能であり、Linux ユーザーは現在ソースからビルドする必要があり、人気のある Linux ディストリビューション向けに事前にビルドされたバイナリリリースを計画している。
本文
2026 年 5 月 9 日
ブログ：ソフトウェア開発
ご存じでしょうか、現在 Microsoft 3D Movie Maker（以下「3D Movie Maker」）をそのまま（ネイティブに）Linux で動作させることができるようになりました。ここ過去 18 ヶ月の間、私は 3D Movie Maker のソースコードポートである「3DMMEx」の開発を行ってまいりました。私のフォーク版の目的の一つは、その汎用性にあります。そしてこのプロジェクトはついに大きなマイルストーンに到達しました。今や Linux 上でコンパイルおよび動作させることが可能となり、3DMMEx は Windows 以外の環境で動作するようになったとされる 3D Movie Maker のフォーク版として初となります！本記事では、古くからあるマルチメディアアプリケーションを新しいプラットフォームへ移植する際に出会ったいくつかの課題について探りを入れてみたいと思います。
これで Linux でも楽しくアニメーション映画を作れます！
背景
2020 年に私は、Microsoft 3D Movie Maker のリバースエンジニアリングに関する一連のブログ記事を書きました。それ以来、大きな進展がありました。2022 年 5 月、Microsoft が当該アプリケーションの完全なソースコードを公開したのです。これは非常に驚くべき出来事でした。私がかつては元のソースコードを見ることすら期待できるとは思っていなかったし、Microsoft のアーカイブにそのものが存在するかどうか疑わしくも思ったものです。しかし、今やそれは GitHub にアップロードされており、しかも寛容な MIT ライセンスが付与されています！
話を進める前に、3DMM ソースコードの入手に関わる断固たる努力を惜しまなかったエイリス・アヴェロング（旧姓：フォーン・ターンリング氏）に心より感謝したいと思います。また、この公開を実現させたスコット・ハンセルマン、ジェフ・ウィルコックスを含む Microsoft チーム全体の方々にも深く感謝申し上げます。ソースコードがどのようにして公開されたかのストーリーに興味がある場合は、リリースに関する「ハンゼルマインッツ」ポッドキャストをご参照ください。
リリースに含まれるリポジトリには、3DMM アプリケーションのソースコード（コードネームは「Socrates」）、3DMM とクリエイティブライター 2 で使用されている「Kauai」というアプリケーションフレームワーク、開発・作成ツール（私が以前リバースエンジニアリングしたスクリプト言語コンパイラも含まれます）、ドキュメント、そしてプリレンダリングされたアセットが含まれています。このリリースは十分完成しており、3DMOVIE.EXE の独自ビルドをコンパイルして動作させることも可能です。
リリース発表時、私はリポジトリを丹念に調査し、ソースコードに関するメモを作成しました。その際、すぐに気づいたことは、コードベースがいかに工夫が行き届いていたかということでした。コーディングスタイルは一貫しており、コメントも充実しており、断言チェック（assert 演算子など）が至るところに配置されていました。1995 年当時の開発者たちは、バグを修正するためアップデートを即座に配布するほどの余裕はありませんでしたので、リリース前のコード品質を徹底的に担保する必要がありました。他のいくつかの 90 年代中期のゲームソースコード公開版と比較しても、3DMM のコードベースははるかにクリーンです。
ポータビリティへの取り組みと課題
ソースコードが公開された際、私が真っ先に思い付いたのはそれを別のプラットフォームへ移植することでした。しかし、自分自身でフォーク版を作るのは大変な作業となるため、3DMMForever プロジェクトに参加する事にしました。このプロジェクトはリリース直後に立ち上がって以来、3DMM を現代化する取り組みを行っていました。私たちは古い makefile を CMake に置き換え、複数の問題を解決して 3DMM を Visual Studio 2022（最新のコンパイラ）で構築できるようにし、ポータブルな 3DMM に向けた第一歩を踏み出しました。
残念なことに、そのまもなくプロジェクトは停滞してしまいました...。そこで私は 2024 年末、3DMMForever をフォークして「3DMMEx」として再スタートさせることにしました。当初の計画は、3DMMForever のいくつかの小さな問題を修正し、3DMM を他のプラットフォームへ移植するために必要なことを初期段階で調査することでした。しかし、移植を困難にしていたいくつかの大きな課題が存在していました：
- コードは標準化されていない C++ の方言を使用しており、Microsoft Visual C++ でのみコンパイル可能でした。
- Kauai アプリケーションフレームワークは「クロスプラットフォーム」を謳っていますが、実際には正確に Windows と Macintosh 68K の 2 つのプラットフォームのみをサポートしています。なお、Macintosh 側への対応は非常に不完全です。
- 3DMM アプリケーションは Kauai のクロスプラットフォーム抽象化を基盤としていますが見えない場所から直接 Win32 API を呼び出すことがあり、これにより抽象化が破られる事がありました。
- フレームワークの性能に敏感な関数内にインライン x86 アセンブリ言語が使用されていました。
- プロジェクトはポインタサイズに関する前提を定めており、その結果 64 ビットシステムでのコンパイルエラーを引き起こしていました。
- フレームワークには 3DMM では使用されないものの、作成ツールでは必要な機能が多数含まれていました。
- 一部の外部依存ライブラリは、プリコンパイルされた静的ライブラリとしてビルドに連結されていました。
- コードの大部分についてはテストが用意されておらず、退步（regression）を捉えるのが困難でした。開発中の 3DMM では自動化されたテストを使用していたものの、テスト自体はオープンソースリリースには含まれていませんでした。
もしそのままのソースコードを取得して別のプラットフォームでコンパイルしようとすると、これら全ての問題に同時に直面する事となります。そこで私は、オリジナルの Windows x86 ビルドを維持しながら、いくつかの問題を個別に対処してみる事に決意しました。私の考えは、「これらの問題を解決できれば、他のプラットフォームへ移植を検討している誰かの役に立てるかもしれない」というものでした。
その通り、フォークを開始してまもなく、Mark Cave-Ayland 氏という素晴らしいソフトウェア開発者からメールを受け取りました。Mark 氏は 3DMM を Linux へ移植することに興味を持っており、息子や娘のために Raspberry Pi で動作させることを目的としていました。「それはとても面白いね」と私は考えました！そして過去 1 年間にわたり、私たちは協力して Linux 上で 3DMM を動かすことに成功しました。Mark は Linux 側への移植を担当し、私が Windows 側の SDL ポート開発を担当しました。
スタティックライブラリの扱い
3DMM プロジェクトには、BRender と AudioMan という 2 つの外部依存関係があり、これらは静的ライブラリとしてパッケージ化されています。BRender は Argonaut Technologies によって開発された 3D レンダリングエンジンです。Alice Averlong 氏が Argonaut Technologies の元 CEO であった Jez San 氏からの承認を得た後、BRender のソースコードも同様に公開されました。BRender はソースから構築可能ですが、手書きの x86 アセンブリ言語コードが相当含まれています。@prettytofugirl という 3DMMForever の貢献者は、この手書きの x86 アセンブリをポータブルな C コードに置き換える素晴らしい仕事を果たし、現在私が 3DMMEx で使用しているものです。
AudioMan は、90 年代中期の Microsoft マルチメディア製品で広く使用されているサウンドミキサーライブラリです。3DMM では AudioMan を音の再生だけでなく、インポートされた音や録画された音の変換にも使用しています。Visual Studio の Windows x86 アーキテクture 以外でのコンパイルでは、この静的ライブラリは機能しないためでした。そこで私は自分独自のミニデコンパイルプロジェクトを開始する事に決断しました！数日の週末を使って、私は Ghidra を使用して AUDIOD.LIB という静的ライブラリバースエンジニアリングを行い、それを C++ にデコンパイルしました。通常フルデコンパイルは非常に困難な作業ですが、今回の場合、ライブラリのデバッグビルドがあり、完全に記述されたシンボル情報を持っていたという幸運がありました。また、3DMM を正常に動作させるために必要なライブラリ全体ではなく、重要な部分のみをデコンパイルする必要があったためです。これは非常に楽しい副産物であり、おそらくこの件についてもブログ記事を書くべきかもしれません。
AudioMan のデコンパイルは、Windows x64 および ARM64 版の 3DMMEx を構築する上で重要な要素でしたが、結果として Windows サウンド API と COM インターフェースと強く結合しており、非 Windows プラットフォームでの動作实现は困難であることが判明しました。そこで私は、非 Windows プラットフォーム向けに新しいウェーブサウンド再生モジュールを追加し、miniaudio を使用する事にしました。miniaudio の統合により、アプリ内録音機能に必要なクロスプラットフォームオーディオ入力の問題も同時に解決されました。
アセンブリ言語の削除
Kauai の一部の関数には、手動で最適化されたアセンブリ言語が含まれています。これはメモリコピー、ビットマップ画像操作、データ圧縮など、パフォーマンスに敏感な関数で使用されています。コンパイル時マクロ（#define）を使用して C++ 実装とアセンブリ実装間で切り替えられます。いくつかの関数には、Windows 用 Intel x86 および Macintosh 用の Motorola 68020 向けの最適化バージョンが用意されています。
元のコードベースには、Kauai で使用される 2 つのカスタム圧縮アルゴリズムの x86 アセンブリ言語バージョンを生成するコードジェネレーターも含まれています。当初 3D Movie Maker のリバースエンジニアリングを開始した際、IDA で KCD2 デコンプレッション関数を見つけ、「人間が書こうはずがないほど複雑だ」と少しホラーを感じたことを覚えています。「これは絶対に人間の手によるものではない」と私は考えました。そして実はその通りでした！
C++ バージョンへの切り替えは比較的容易で、単に#define を削除するだけで済みましたが、対応する C++ 実装においていくつかのバグが発見されました。アセンブリバージョンを除去したことで、いくつかのパフォーマンス向上にもつながりました。アプリケーションは現在、現代のプロセッサ向けの最適化された C ランタイムの memcpy/memmove 実装を活用できるようになったためです。
地味なエンジニアリング作業
3DMM を新しいプラットフォームへ移植するには、既存コードを壊す可能性が高い変更を多数行う必要があります。大規模な変更を行う前に、デバッグとテスト体験を改善する時間を使っていました。これにより、私が変更を加える際のリグレッション検出が hopefully 促進されると期待しました。これらの変更には以下が含まれました：
- Kauai フレームワークはユニットテスト数が少なかったため、これらを Google Test に移植してビルドに統合しました。
- Visual Studio デバッガーでは読み込みにくいカスタムデータタイプを使用するため、Visual Studio 上で特定の型をどのようにレンダリングすべきかのヒントを与える NatVis ビジュアライザを作成しました。例えば、文字列クラス（STN）は現在、ポインタではなく実際の文字列値を表示します。
- 30 年前から保存された映画ファイルを読み込め続けることを保証するため、ファイル形式の互換性を損なう変更を避ける事に決意していました。そのため、プラットフォーム間でのコンパイル時にサイズが変化するのを防ぐため、ファイルフォーマット構造体の周りに静的断言を追加しました。これらの断言は、3DMM を 64 ビットシステムへ移植する際の問題を特定するのに役立ちました。
- 3DMM の UI デバッグは困難であり、論理の多くがスクリプト内部で行われます。UI ロジックの実行を追跡しやすくするため、現在実行中のスクリプトを表示するための追加ログを追加しました。
- コンポーネント間の境界を作成するための小規模なリファクタリングを多数行ったことで、SDL/クロスプラットフォームビルド向けの新しい実装を追加しつつ、元の動作する Win32 実装を取り除かずに済みました。
また、90 年代のオリジナル開発者たちが使用していたハンガリアンコーディングスタイルを Apps に残す事にしました。2026 年でそれが少し奇妙に映るかもしれませんが、新しいコードが元のコードと一貫性を持つようにしたいと考えたからです。慣れるには時間がかかりますが、コードベースに取り組んでいくうちに「mpgrfchpsz」といった変数名について二度考える事はなくなります！😄
Win32 を SDL に置き換える
Kauai の GUI ライブラリは Windows 上で Win32 API を、System 7 上では Macintosh Toolbox を使用するように記述されています。私は Win32 GUI 実装を、クロスプラットフォームマルチメディアアプリケーション用の人気のあるオープンソースライブラリである SDL に置き換えました。
SDL テストを容易にするために、最初にイベントディスパッチと基本的なレンダリングをテストする小さな「Hello World」タイプの Kauai アプリケーションを作成しました。これにより、フレームワークの変更をテストするために整个アプリケーションが正常に動作している必要はなくなりました。このテストアプリを使用してウィンドウ作成と基本の入力処理を動かした後、レンダリング作業を開始しました。
SDL バックエンドのほとんどは比較的単純なものでした。Kauai にはすでに GUI 機能に対する非常に良い抽象化が存在していたためです。例えば、全てのグラフィックスは GNV（Graphics Environment）および GPT（Graphics Port）クラスで処理されています。これらのクラスには矩形を描画する DrawRcs メソッドやテキストをレンダリングする DrawRgch メソッドなどのメソッドがあります。私が行う必要があったのは、Win32 GDI レンダリングコードを SDL equivalents に置き換えるだけでした。
しかし、これは時々少し難易度の高い作業となりました。Win32 で 1 行のコードで行う操作が、SDL では数百行の新しいコードに置き換えられる必要があるためです。フォント管理はその好例です。多くの 90 年代のマルチメディアアプリケーションは、アプリケーション資産と一并提供される固定セットのフォントのみを使用していました。一方、3DMM はシステム上に存在するあらゆる TrueType フォントを検出・利用できるようにしたいと考えています。Win32 API では、EnumFonts という簡単な呼び出しで新規フォントごとにコールバックを受け取り、そこから CreateFontIndirect を呼び出してレンダリング用のフォントハンドルを取得できます。一方、SDL にはフォントの列挙手段がないため、これはプラットフォームごとに実装する必要があります。
もう一つの例としてキーボードショートカット処理があります。Win32 ではアクセラレータテーブルというものが存在し、仮想キーコードと WM_COMMAND メッセージのマッピングを提供します。アクセラレータテーブルは通常、実行可能ファイルのリソースセクションに格納されます。アプリケーション起動時に LoadAccelerators を呼び出してテーブルを読み込み、イベントループ内で TranslateAccelerator を呼び出すことで、キー入力を WM_COMMAND へ変換します。テーブルの実際の管理作業はすべて Windows が処理してくれます。SDL ビルドでキーボードショートカットを動作させるためには、アクセラレータテーブルシステムを再実装する必要がありました。この再実装の良い点としては、カスタムキーバインディングをサポートするのが格段に容易になることです。将来のリリースでこれをサポートする予定があります。
少し遅く気がついたことのひとつは、SDL での文字列が UTF-8 エンコードである必要があるということです。3DMM は文字列に対してシステムのデフォルトコードページ（英語環境では CP1252）をデフォルトとして使用しています。これにより、レンダリングされたテキストはほぼ正しく表示されましたが、UI のある部分がエントーラシス（em-dash）をボックスとして表示する不具合が見つかるまでには至りました。そこで、UTF-8 への変換/逆変換を行うための追加メソッドを追加しました。3DMM は UCS-2 を使用したユーニコードもサポートしていますが、元のソースリリースでは非常に壊れており、1996 年の日本語版リリースまで完了していませんでした。将来的には、すべての文字列処理を内部で UTF-8 に変更したいと考えていますが、これは映画のシリアライゼーション方法に関する根本的な変更を必要とします。
猫頭鷹ペンギンの残りを描く
インラインアセンブリ言語が除去され、SDL バックエンドも動作するようになりました。3DMMEx は、もう一つのプラットフォーム上でネイティブに動作させる可能性がある段階に近づいていました。ここで Mark が多くの問題を解決するために多大な労力を発揮しました。ケース敏感なファイル名や誤ったバックスラッシュへの対処から始まり、POSIX プラットフォームサポートのための新しいモジュールの作成、および MIDI 再生のための FluidSynth とシーン再生のための GStreamer の統合まで含まれていました。数ヶ月後、Mark は Linux で 3DMMEx を起動することに成功しました！Mark が Linux への移植について書かれたブログシリーズをチェックすると、私たちが遭遇した他のいくつかの技術的課題に関する素晴らしい解説が見つかります。
Mark に感謝するのは、Linux ポートへの彼の素晴らしい仕事だけでなく、3DMMEx の開発を続けるためのモチベーションを維持してくれた点でもあります。ソフトウェアを別のプラットフォームへ移植することは少しつらく感じることもあるかもしれませんが、Mark 様のような経験豊富で意欲的な開発者との協働により、それははるかに容易で楽しい作業となりました！
もし 3DMMEx を試してみたい場合は、GitHub プロジェクトをご参照ください。x86、x64、ARM64 向けの Windows バイナリはリリースページで利用可能です。Linux で動作させるにはソースからビルドする必要がありますが、いくつかの人気の Linux ディストリビューション向けバイナリリリースを作成する予定です。
3DMMEx のすべての機能は SDL/Linux ポートで動作していますが、いくつかの改善点が残っています。現在最大の課題は、ステージ上でアクターをドラッグしている際のマウス処理であり、入力デバイスによっては全く使用できない場合があります。また、macOS などの他のプラットフォームへの移植や、ブラウザ内での動作（Emscripten）も歓迎します。これらのいずれかの支援に興味がある場合は、GitHub の issues ページまたはディスカッションページをご確認ください。
最後に、Linux でコンパイルおよび動作する 3DMMEx のビデオをご覧ください！