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

1. 最初に結論

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

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

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

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

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

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

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

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があります。 32bitと64bitでレジストリやDLLの見え方が変わることがあります。 C:\Windows\System32 が64bit側で、C:\Windows\SysWOW64 が32bit側という、初見では混乱しやすい構造もあります。

COMも厄介です。 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やプリンタードライバーの問題に触れることがあります。 C#で書いていても、ベンダーSDKがネイティブDLLならP/Invokeやビット数の問題に触れます。 新しい画面を作っていても、既存のCOMコンポーネントやExcel連携を残す必要があることがあります。

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

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

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

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

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アプリ開発ではとても重要です。

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。

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

しかし、その面倒くささの多くは、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