開発者の異常な愛情、または私は如何にして心配するのをやめてWindowsを愛するようになったか

Windowsアプリ開発の「環境ごとに壊れるのが怖い」という感覚を、どう扱うかについての随筆です。API の使い方を解説する記事ではありません。

DLL、COM、32bit / 64bit、権限、DPI、配布。こうした心配ごとをなぜWindowsが抱え込んでいるのか、そしてその心配をどう設計とテストと観察に変えるのか、という話をします。手を動かす形で持ち帰れるものが欲しい方は、6章の「不安 / 設計上の対策 / 確認方法」の表だけ見ていただいても構いません。

1. 最初に結論

Windowsアプリを作っていると、心配することが多い。

このPCで起動するだろうか。 管理者権限がない環境でも動くだろうか。 32bit / 64bit の違いで壊れないだろうか。 日本語パス、長いパス、ネットワークドライブ、古いDLL、COMコンポーネント、ActiveX、プリンタ、シリアル通信、ウイルス対策ソフト、Windows Update。

考え始めると、心配は尽きません。

けれど、ある時から私は思うようになりました。

これは欠点というより、Windowsが現実の業務を背負ってきた証拠なのではないか、と。

Windowsは、綺麗な理想郷ではありません。 しかし、現場で何十年も動き続けてきたソフトウェア、装置、業務フロー、人間の慣れを抱え込んでいます。

その混沌こそが、Windowsの面白さであり、開発者として向き合う価値なのだと思います。

この記事の知識マップ

この随筆は、Windowsアプリ開発につきまとう「環境ごとに壊れるかもしれない」という不安の正体を、Windowsが積み重ねてきた後方互換性という性質から説明します。32bitアプリを64bit Windows上で動かすWOW64、レジストリ登録とビット一致が必要なCOMコンポーネント、今も現場に残る.NET Frameworkアプリ、高DPIや長いパスへの対応、配布方法の選定など、心配の種の多くは古い資産を切り捨てずに動かし続けてきた結果として生まれています。筆者は、その心配をなくすのではなく、Application VerifierやWinDbg、Get-WinEventによる観察とテストという設計に変えることを提案し、そこにWindowsを愛する理由を見出しています。

flowchart LR
    accTitle: Windowsの後方互換性への愛の知識マップ
    accDescr: Windowsアプリ開発者が抱く環境差異への不安が、COMやWOW64、.NET Frameworkといった後方互換性の中身と結びつき、Application VerifierやWinDbg、Get-WinEventによる観察でどう設計に変えられるかを示す図。
    windows_backward_compatibility["Windowsの後方互換性"]
    com["COM(コンポーネントオブジェクトモデル)"]
    bitness_match_requirement["bitness一致要件"]
    regsvr32["regsvr32"]
    wow64["WOW64"]
    dotnet_framework[".NET Framework"]
    dotnet[".NET(Core以降)"]
    high_dpi_support["高DPI対応"]
    windows_forms["Windows Forms"]
    long_path_support["長いパス・UNCパス・日本語パスへの対応"]
    app_distribution_method["アプリの配布方法"]
    application_verifier["Application Verifier"]
    windbg["WinDbg"]
    get_winevent["Get-WinEvent"]
    com -->|"前提とする"| windows_backward_compatibility
    com -.->|"前提とする"| bitness_match_requirement
    com -.->|"で構成できる"| regsvr32
    windows_backward_compatibility -->|"前提とする"| wow64
    windows_backward_compatibility -.->|"前提とする"| bitness_match_requirement
    windows_backward_compatibility -->|"前提とする"| dotnet_framework
    dotnet -->|"の後継"| dotnet_framework
    windows_backward_compatibility -->|"前提とする"| high_dpi_support
    windows_forms -.->|"前提とする"| high_dpi_support
    windows_backward_compatibility -->|"前提とする"| long_path_support
    windows_backward_compatibility -->|"前提とする"| app_distribution_method
    application_verifier -->|"推奨される対応"| windows_backward_compatibility
    windbg -->|"推奨される対応"| windows_backward_compatibility
    get_winevent -->|"推奨される対応"| windows_backward_compatibility

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全14件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. Windowsアプリ開発は、心配ごとが多い

Windowsアプリ開発では、「コードが正しい」だけでは足りません。

ローカル環境では動く。 開発者のPCでは動く。 検証用VMでも動く。

それでも、お客様のPCで動くとは限りません。

たとえば、次のようなことが起きます。

• DLLが見つからない
• Visual C++ ランタイムが入っていない
• .NET Framework のバージョンが合わない
• 32bit DLLを64bitプロセスから読み込もうとして失敗する
• COM登録が壊れている
• regsvr32.exe の32bit版と64bit版を間違える
• カレントディレクトリ前提のコードがタスクスケジューラで壊れる
• Program Files 配下に書き込もうとして権限エラーになる
• AppData\Roaming と AppData\Local の使い分けを間違える
• 日本語ユーザー名や日本語フォルダー名で落ちる
• 長いパスでファイルを開けない
• ネットワークドライブでは動くがUNCパスでは動かない
• 高DPI環境で画面が崩れる
• マルチモニターで座標計算がずれる
• プリンタードライバーによって印刷結果が変わる
• USB機器、カメラ、測定器、シリアル通信が環境によって認識されない
• ウイルス対策ソフトに一部の処理を止められる
• Windows Update後に挙動が変わる

こう並べると、少し気が遠くなります。

Webアプリならブラウザとサーバーの間に閉じ込められる問題が、WindowsアプリではPC全体に広がります。 ファイルシステム、レジストリ、ユーザープロファイル、プリンタ、デバイス、ネットワーク、セキュリティポリシー、インストーラー、ランタイム。

アプリケーションはOSの上で動いているというより、業務環境の中に置かれます。

だからWindowsアプリ開発は難しい。 ただし、それを「Windowsはダメ」と切り捨てるのは少し違うと思っています。

そこに乗っているのは、現実世界の複雑さです。

3. Windowsは“現場のOS”である

Windowsは、最新技術だけのためのOSではありません。

工場、病院、役所、学校、研究室、放送、検査装置、受付端末、帳票端末、倉庫、店舗、会計、給与、在庫管理。 そういう場所で、今も多くのWindows PCが動いています。

そこには、最新のWebサービスだけがあるわけではありません。

Excelマクロがあります。 Accessがあります。 古いVBアプリがあります。 .NET Frameworkの業務アプリがあります。 C++で作られた常駐アプリがあります。 COMコンポーネントがあります。 ActiveXがあります。 ODBC接続があります。 プリンタードライバーがあります。 バーコードリーダーがあります。 シリアル通信の測定器があります。 ベンダー提供のSDKがあります。

しかも、それらは単体で存在しているわけではありません。

人が操作し、帳票を印刷し、USB機器を差し替え、共有フォルダーにCSVを置き、夜間バッチが動き、翌朝の業務が始まる。 そういう一連の流れの中で動いています。

Windowsは、単にアプリを起動するための土台ではありません。 現場の作業、既存資産、周辺機器、人間の慣れまで含めて受け止めるプラットフォームです。

だから、ときどき古く見えます。 ときどき複雑です。 ときどき、なぜまだこれが残っているのかと思うものがあります。

けれど、それは古いものを雑に捨ててこなかったということでもあります。

4. 後方互換性という愛

OSを美しく見せるだけなら、古い仕組みを切り捨てる方が簡単です。

古いAPIを消す。 古いランタイムを消す。 古い設定画面を消す。 古いアプリは動かないものとして扱う。

そうすれば、設計はすっきりするかもしれません。 ドキュメントも短くなるかもしれません。 開発者の気分も少し軽くなるかもしれません。

でも、その裏で動かなくなる業務アプリがあります。 止まる装置があります。 困る現場があります。

Windowsの後方互換性は、技術的には厄介です。 32bitアプリを64bit Windowsで動かすためのWOW64（Windows 32-bit On Windows 64-bit）があります。 32bitと64bitでレジストリやDLLの見え方が変わることがあります。 C:\Windows\System32 が64bit側で、C:\Windows\SysWOW64 が32bit側という、初見では混乱しやすい構造もあります。

COM（Component Object Model。アプリ同士が部品をやり取りするためのWindowsの仕組み）も厄介です。 DLLを置いただけでは動かず、登録が必要なことがあります。 登録先がユーザー単位なのかマシン単位なのか。 32bit COMなのか64bit COMなのか。 管理者権限が必要なのか。

.NET Framework も同じです。 今なら .NET 8 / .NET 9 のような新しい .NET を使う選択肢があります。 しかし、現場には .NET Framework 4.x のアプリが今もあります。 それは単に古いのではなく、そのバージョンで長年業務を支えてきたということです。

後方互換性は、美しいだけの概念ではありません。 むしろ、重い責任です。

古いものを動かし続けるというのは、技術的負債を抱えることでもあります。 しかし同時に、利用者の業務を止めないという誠実さでもあります。

私はここに、Windowsの愛すべきところがあると思っています。

5. Windowsは地層のようなOSである

Windowsには、時代ごとの技術が地層のように積み重なっています。

Win32。 COM。 ActiveX。 Windows Forms。 WPF。 .NET Framework。 UWP。 WinUI。 Windows App SDK。 MSIX。 PowerShell。 Windows Terminal。 WSL。

それぞれに登場した時代があり、得意分野があり、使われてきた現場があります。

新しいものだけを見れば、古いものは邪魔に見えるかもしれません。 しかし、Windowsアプリ開発では、古い層を無視できない場面がよくあります。

たとえば、WPFアプリを作っていても、印刷ではGDI（Graphics Device Interface。Windowsが古くから持っている描画と印刷の仕組み）やプリンタードライバーの問題に触れることがあります。 C#で書いていても、ベンダーSDKがネイティブDLLならP/Invoke（Platform Invoke。C#からネイティブDLLの関数を呼び出す仕組み）やビット数の問題に触れます。 新しい画面を作っていても、既存のCOMコンポーネントやExcel連携を残す必要があることがあります。

Windowsは、整理されきった庭園ではありません。 むしろ、増改築を繰り返した巨大な都市に近い。

大通りもあります。 地下道もあります。 古い路地もあります。 新しい高層ビルもあります。

迷いやすい。 でも、その路地の奥で、今も大事な業務が動いています。

この「増改築の記録」を、随筆ではなく年表として具体的にたどったものが Windowsはなぜ今の形になったのか：開発者から見た歴代Windowsの進化 です。Windows 95 から Windows 11 までを、開発者から見た変化として整理しています。どの層がいつ積み上がったのかを知りたい場合は、そちらを読んでください。

開発者に必要なのは、「古いから不要」と判断することではありません。 どの層の技術が、どの業務を支えているのかを見極めることです。

6. 面倒くささを、設計に変える

タイトルでは「心配するのをやめて」と書きました。

ただし、心配をやめるとは、雑になることではありません。 問題を見なかったことにすることでもありません。

心配をやめるとは、心配を設計に変えることです。

たとえば、起動するか不安なら、起動確認をスモークテストにします。

Start-Process .\MyApp.exe

ただ起動するだけではなく、設定ファイルがない状態、ログフォルダーがない状態、標準ユーザー権限、ネットワーク未接続、プリンタ未設定、高DPI、長いパス、日本語パスでも試します。

DLLが不安なら、依存関係を確認します。 Visual C++ ランタイムが必要なら、インストーラーに含めるのか、前提条件として明記するのかを決めます。 ネイティブDLLを使うなら、x86 / x64 / AnyCPU の関係を曖昧にしません。

COMが不安なら、登録手順を手順書にし、検証用PCでゼロから再現します。

# 64bit COM DLL の登録例
C:\Windows\System32\regsvr32.exe .\SomeComponent64.dll

# 32bit COM DLL の登録例
C:\Windows\SysWOW64\regsvr32.exe .\SomeComponent32.dll

権限が不安なら、管理者権限でしか動かない設計を避けます。 ユーザー設定は AppData に置き、全体設定は ProgramData に置きます。 Program Files 配下にログを書き込むような設計は避けます。

パスが不安なら、日本語、空白、長いフォルダー名、UNCパスをテストに入れます。

New-Item -ItemType Directory -Path "C:\テスト 用\とても長いフォルダー名\さらに深いフォルダー" -Force

DPIが不安なら、100%、125%、150%、200%で確認します。 マルチモニターで、倍率が違うディスプレイをまたいでも破綻しないか見ます。 WinForms、WPF、WinUIでは、それぞれDPI対応の考え方が違うため、画面技術ごとに確認します。

メモリやハンドルが不安なら、Application Verifier、WinDbg、ProcDump、Process Explorerなどを使います。 クラッシュが不安なら、イベントログ、ダンプ、アプリケーションログを残します。

Get-EventLog -LogName Application -Newest 20

あるいは新しい環境なら、次のようにイベントログを確認します。

Get-WinEvent -LogName Application -MaxEvents 20

現場で再現しない不具合が不安なら、ログの粒度を上げます。 「エラーが発生しました」では足りません。 どのファイルを開こうとしたか。 どのデバイスを探したか。 どのユーザーで実行されたか。 どのパスに書き込もうとしたか。 どのDLLを読み込めなかったか。

心配を、観察できる形に変える。

これがWindowsアプリ開発ではとても重要です。

ここまでを1枚にまとめると、こうなります。

この表の左の列は、そのまま心配ごとの一覧です。右の2列があると、心配は作業に変わります。

7. 「お客様のPCで動く」が最終目標である

開発環境で動くことは大事です。 CIでテストが通ることも大事です。 クリーンなVMで動くことも大事です。

でも、Windowsアプリの場合、最後に立ちはだかるのは「お客様のPCで動くか」です。

そのPCには、すでに何かが入っています。 古いプリンタードライバーが入っているかもしれません。 独自のセキュリティソフトが入っているかもしれません。 ネットワークドライブが割り当てられているかもしれません。 ユーザーに管理者権限がないかもしれません。 Windows Updateをすぐに適用できない事情があるかもしれません。 インターネットに出られない環境かもしれません。

だから、配布方法も重要になります。

単にexeを渡せばよいのか。 MSIにするのか。 ClickOnceにするのか。 MSIXにするのか。 wingetで配れるのか。 社内配布システムに載せるのか。 オフラインインストーラーが必要なのか。 コード署名は必要か。 SmartScreenやウイルス対策ソフトで止まらないか。

アプリ本体だけでなく、インストール、更新、アンインストール、ログ取得、復旧手順まで含めて、ようやく「現場で使える」に近づきます。

Windowsアプリ開発では、ソフトウェアは納品して終わりではありません。 お客様の環境で、今日も明日も起動する必要があります。

8. それでもWindowsを愛する理由

Windowsには面倒なところがあります。 これは事実です。

DLL。 COM。 レジストリ。 UAC。 DPI。 プリンタ。 ランタイム。 32bit / 64bit。 ネットワークドライブ。 長いパス。 日本語環境。 セキュリティソフト。 Windows Update。

面倒なものを挙げれば、いくらでも出てきます。

念のため補足しておくと、UAC は User Account Control（ユーザーアカウント制御）、DPI は Dots Per Inch（画面の拡大率設定）です。どちらも「アプリが自分だけで完結できない」ことの別の言い方でもあります。

しかし、その面倒くささの多くは、Windowsが現実の業務を長く背負ってきたことから来ています。

古い資産を切り捨てず、新しい技術も取り込み、GUIもCLIも持ち、ローカルアプリもWebも、周辺機器も業務端末も、個人PCも企業PCも受け止める。

それは美しい単一思想ではありません。

でも、強いです。

そして、開発者としては挑む価値があります。

Windowsの上で確実に動くソフトウェアを作るということは、単にAPIを呼ぶことではありません。 現場の制約を読み、既存資産を理解し、壊れやすいところを見つけ、テストし、観察し、必要なところを直していくことです。

それは地味です。 でも、価値があります。

9. まとめ

Windowsアプリ開発では、心配ごとが尽きません。

しかし、その心配の多くは、WindowsというOSが長い時間をかけて現実の業務、現場、装置、人間の操作を受け止めてきた結果でもあります。

だから私は、Windowsを単なる古いOSだとは思っていません。

それは、現実と折り合いをつけながら動き続けてきた、巨大で複雑で、少し不器用なプラットフォームです。

そして、その上で確実に動くソフトウェアを作ることには、今でも大きな価値があります。

心配することをやめる。

ただし、油断するのではありません。

心配を、設計とテストと観察に変える。

そうして私は、少しずつWindowsを愛するようになりました。

参考リンク

• Application Verifier - Overview - Microsoft Learn
• High DPI Desktop Application Development on Windows - Microsoft Learn
• Setting the default DPI awareness for a process - Microsoft Learn
• Running 32-bit Applications - Microsoft Learn
• Maximum Path Length Limitation - Microsoft Learn
• MSIX documentation - Microsoft Learn
• Version compatibility in .NET Framework - Microsoft Learn

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。