-
Notifications
You must be signed in to change notification settings - Fork 0
MS_WOW64
- 戻る（Windows OSの基礎的トピック、64bit対応（
MS_Support64bit.md））- WOW64
WOW64についての情報を纏めている。
- WOW64（Windows-on-Windows 64-bit）は、64bit版のWindows OS上で
32bitアプリケーションを動作させるための互換レイヤー（サブシステム）。 - 64bit OSは本来64bitアプリのみをネイティブで動かしますが、
過去の資産（32bitアプリ）も実行できるようにするためにWOW64が存在。
32bitアプリ →（が、64bit OS上の）WOW64レイヤー（で動作し、）→ 64bitカーネル（との間を仲介する）
という流れで動作
- カーネルは64bitのみで、32bitカーネルをエミュレーションしている訳ではない。
- 32bitコードはユーザーモードで、WOW64上で32bitで動作し、64bitカーネルとの仲介がされる。
- カーネルモード・ドライバは32bit非対応（64bit専用が必要）。
- WOW64はCPUの互換モード（IA-32eの互換モード）と組み合わせて実現。
32bitアプリは最大4GBの仮想メモリ空間を利用可能
（通常、32bitの4GBは、カーネル2GB・ユーザ2GBと利用される）。
※ WOW64 上ではカーネルが 64bit なので、32bit アプリのユーザ空間を圧迫しない。
IMAGE_FILE_LARGE_ADDRESS_AWARE を立てた 32bit アプリは、
64bit OS 上で ユーザ空間 4GB 弱を使える（32bit OS の /3GB より有利）。
32bitアプリが呼び出すWin32 API（システムコール）を、64bitカーネル向けに変換（サンク）。
API呼び出しの互換性を維持するAPI変換とは別の技術でリソース参照の互換性を維持する。
- ファイルシステム・リダイレクト
-
C:\Windows\System32は64bit DLL用。 - 32bitアプリが利用する System32 を
C:\Windows\SysWOW64にリダイレクト。
-
- レジストリ・リダイレクト
-
HKLM\Softwareは64bit用。 - 32bitアプリが利用する
HKLM\Software\WOW6432Nodeにリダイレクト。
-
※ 紛らわしいが、System32 が 64bit、SysWOW64 が 32bit。
名前は「その環境から見た System32」という互換上の経緯による。
A: 64bit Windowsでは16bitアプリは動かない（NTVDMがない）。
A: カーネルモード・ドライバは32bit非対応（64bit専用が必要）。
A: WOW64の仕組みを拡張した WOW64（ARM64 版）で x86 アプリをエミュレーションできる。
ARM64EC は「エミュレーションと互換性のある ABI」で、
ネイティブ ARM64 コードと x64 コードを同一プロセス内で混在させるための仕組み。
移行メモ（正誤）: 原文は「WOW64EC で x86 アプリをエミュレーション」としていたが、 正しくは ARM64EC（Emulation Compatible）。 しかも ARM64EC はエミュレーションのための仕組みそのものではなく、 ネイティブ ARM64 と x64 の相互運用を可能にする ABI。 ARM64 版 Windows での x86/x64 エミュレーションは、 WOW64 の拡張（および Windows 11 の Prism エミュレータ）が担う。
A: 結論から言うと、WOW64上の32bitアプリから64bit DLLを直接呼び出すことはできない。
- WOW64はシステムコールやOS APIを変換するが、アプリコードとDLL間の呼び出しを変換する仕組みはない。
- プロセス間通信で、64bitブリッジを経由させ、64bit DLLを呼ぶことはできるが非常に手間がかかる。
※ COM の場合は、64bit のアウトプロセス サーバ（EXE）としてなら
プロセス境界をまたいでマーシャリング経由で呼べる（インプロセス DLL は不可）。
Environment.Is64BitProcess // プロセスが 64bit か
Environment.Is64BitOperatingSystem // OS が 64bit かIsWow64Process（または IsWow64Process2）API を使用する。
名前の後ろに *32 とか（32 ビット）とか表示される。
- レジストリ・リダイレクター
- ファイルシステム・リダイレクター
Program Files のフォルダの場合は少々勝手が違ってきます。
- .NET では
-
Environment.SpecialFolder.ProgramFilesのようにフォルダ情報を取得すると、
返ってくるのは%systemdrive%\Program Files (x86)フォルダになります。 - また、
%systemdrive%\Program Filesフォルダに対してファイルの作成などを
おこなってもリダイレクトはされず、そのままそのフォルダに I/O がおこなわれます。
-
- VC++ では
-
SHGetFolderPath()/SHGetKnownFolderPath()の挙動を確認する必要がある。
-
補足: つまり Program Files は「パス取得 API が別のパスを返す」のであって、 System32 のような「I/O が透過的に別フォルダへ差し替えられる」リダイレクトではない。 両者は別の仕組みである点に注意。
- 32bitアプリケーションから64bitコマンドを実行する場合、
逆に、リダイレクタが問題になる（通常、32bitコマンドを参照するため）。 - この様なケースでは、
-
%windir%\System32ディレクトリの代わりに -
%windir%\Sysnativeディレクトリを指定する。
-
- 事例を見ると、シェル・スクリプトで発生することが多い模様。
（自作アプリだと、自アプリのTarget CPUや、パス環境変数、
カレント・ディレクトリからの相対パスなどを気にするので）
※ Sysnative は32bitプロセスからのみ見える仮想ディレクトリで、
64bit プロセスから参照しても存在しない。
開発したCOMを登録する Regsvr32 にも32bit版・64bit版があります。
64 ビット版は %systemroot%\System32\regsvr32.exe
32 ビット版は %systemroot%\SysWoW64\regsvr32.exe
COMの設定を行う dcomcnfg.exe にも32bit版があるもよう。
dcomcnfg.exe /32
32ビット版のCScriptコマンドを使ってVBScriptのプログラムを実行するには、
CScriptコマンドを C:\Windows\SysWOW64\CScript.exe と記述します。
- Office は 64bit OS 上でも 32bit を使用した方が良い（実績的に）。
64bit の Office を採用する場合は色々調査・検証が必要になる。
補足（最新化）: Microsoft 365 Apps は 2019年以降、既定が 64bit に変更された。 したがって「32bit Office 推奨」は現在の既定と逆。 ただし、32bit 決め打ちの ActiveX / アドインを抱えている環境では 依然として 32bit 版を選ぶ判断はありうる （VBA 側は
#If Win64とPtrSafe/LongPtrでの対応が必要）。
64bit対応（MS_Support64bit.md）を参照。
ここでは、32bit用、64bit用データプロバイダに起因する問題をまとめています。
一般的なトピックは ADO.NETデータプロバイダ（MS_ADONETDataProvider.md）を参照下さい。
- ドライバはWOW64上で動作しないため64bitプラットフォームでは64bit対応
されたものを使用する必要があるのですが、ODBC、OLEDBドライバなどは所謂ドライバ
（デバイス・ドライバ、バス・ドライバ、フィルタ・ドライバ）とは異なるため、
WOW64上でも使用可能ですが、詳細は其々サポート状況の確認が必要です。 - 各プラットフォーム（32bit or 64bit ＋ 対象データソース）の
サポートのあるODBC、OLEDBドライバなどが用意されているか確認が必要です。
- ODP.NETのDLL（
Oracle.DataAccess.dll）は32/64bit決め打ちで、AnyCPUになっていないので、
クライアントプログラムのターゲット（32/64bit）に一致したものをインストールする必要がある。 - 警告（warning）は、上位プログラムがAnyCPU、下位プログラムが32/64bit決め打ちの場合に出力される。
- 64bit環境で、DBMSが同居しており、クライアントがWOW64で32bitの場合、
Oracleクライアント32bitをインストールする必要がある。 - マネージドの（Oracleクライアント不要の）ODP.NET を使用すれば簡単かもしれません。
Windows 7(64bit) / Office 2010(32bit) 環境での検証結果
- 64bit の ODBCアドミニストレータ（※1）の[ユーザDSNタブ]でExcel Filesを選択したところ
エラーとなり、追加ボタンで追加できるドライバーの一覧でも Excel はありませんでしたので、
この構成の場合32bit のExcel Files ODBC ドライバのみが追加されるもようです。 - 32bit の ODBCアドミニストレータ（※2）の[ユーザDSN]タブではExcel Files を選択できる。
※1：C:\Windows\System32\odbcad32.exe（64bit 版）
※2：C:\Windows\SysWOW64\odbcad32.exe（32bit 版）
※ 両者ともファイル名が odbcad32.exe で紛らわしいが、置かれているフォルダで判断する
（リダイレクトの節を参照）。
- 2008 R2 64bit上で32bit、64bitの両方の Jet OLE DB プロバイダが存在し、
それぞれ動作したことを確認しています。 - OLEDBが64bitに対応していない件については、以下の代替のドライバがあり、
これをインストールしてConnectStringを変更することにより、プログラム変更なく動作しました。- Microsoft Access データベース エンジン 再頒布可能コンポーネント
-
ConnectionStringプロパティのプロバイダ引数をMicrosoft.ACE.OLEDB.12.0に設定する必要がある。
- OO4O は discontinued で、64bit対応がされていないようです。
（MS_CodeAccessSecurity.md）
こちらにも同様に32bit設定と64bit設定があるようです。
ホストするアプリが32bitの場合、対象アプリが64bitでも、
32bitのコード・アクセス・セキュリティ ポリシー設定を参照するようです。
IE9(32bit) → Excel2010(64bit) → DLL(64bit) といった動作をする場合、
実行するプロセスは 64bit だが、CAS 設定は IE9 から、32bit のものを参照している。
補足（最新化）: コード アクセス セキュリティ（CAS）は .NET Framework 4 で非推奨となり、 .NET Core 以降には存在しない（セキュリティ境界としてはプロセス／コンテナを使う）。
Tags: Windows, 移行, .NET開発
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。