回答:
アプリがAWEに対応している場合、4ビットを超えるアドレス空間を使用できますが、64ビットアプリよりも効率は劣ります。PAEが有効で、プロセスがそれを使用できる場合、32ビットWindowsバリアントの下の32ビットプロセスが、32ビットアドレス空間が許可する範囲を超えてアクセスすることさえ可能です。
個々の32ビットプロセス（AWE認識していない）通常の3Gb（その仮想アドレス空間の最初のGBのは、カーネル関連のアクションのために予約されている）に制限されますが、あなたが複数のプロセスを実行している場合、彼らはより多く使用することができますで 仮想アドレス空間が共有されていないため、合計（それぞれが最大3Gbまで使用でき、合計メモリが許可されます）。
プロセスごとの制限は、サービスがスレッドベースではなくプロセスベースである傾向があるUnixのような環境（1つのプロセスの複数のスレッドがプロセスリソースを共有するため、単一の3Gb仮想アドレススペースを共有する）でより一般的ですWindowsでは（ Windowsで新しいプロセスを開始するのは非常に高価なのでスレッドが優先されます。ほとんどのUnix環境では、新しいプロセスを開始する方が新しいスレッドを開始するよりもリソースを消費しません）。たとえば、SQL Serverのみを実行しているマシンでは、1つのプロセスにしかならず、3Gbの制限に達するため、あまり役に立ちません（一部のエディションは、すべてではなくAWEに対応するように構成できます。機能は次のメジャーリリースで削除される予定です。
合計で3Gb以上を使用できる32ビットプロセスと同様に、OSはディスクキャッシュに未使用のメモリを使用できるため、プロセスがこのような方法でファイルを開かないと仮定しても無駄にならない可能性がありますOSにこれを行わないように伝えます。
アプリケーションがAWEを使用する場合、yes（ただし、これは64ビットOSに制限されません）。これがない場合でも、プロセスは4GBのアドレス空間に制限されます。
あなたが何を言っているかに応じて、ソータ。
Windowsを想定しています...
OSが64ビットの場合、32ビットプロセスはデフォルトで2 GBのユーザーアドレス仮想アドレススペースを取得します。.exeファイルのPEヘッダーがIMAGE_FILE_LARGE_ADDRESS_AWAREフラグでマークされている場合、プロセスは4 GBのユーザーアドレス指定可能な仮想アドレススペースを取得します。いずれの場合も、カーネルの仮想アドレス空間はすべてのプロセスで共有されるため、64ビットプロセスと同じです。また、IMAGE_FILE_LARGE_ADDRESS_AWAREフラグを設定しない64ビットプロセスも、2 GBのユーザー仮想アドレススペースのみにアクセスできます。
特別なブートフラグ、3 GB、/ 3GBスイッチ、または/ uservaについて耳にすることは、すべて32ビットオペレーティングシステムに関するものであり、64ビットWindowsには適用されません。
これはすべて、MicrosoftのWindowsリリースのメモリ制限ページで詳細を説明することで終わりました。
@David Spillettの答えは別の点にも触れています。複数のプロセス（すべて2 GBのユーザースペースに制限されます）は、ファイルキャッシュと同様に、使用可能な場合はかなりの量のRAMを使用できます。
32ビットOS上の32ビットプロセスには4GBのアドレス空間があり、そのうち2GBはOSによって予約されており、2GBがプロセスに使用可能です。
OSに指定できるスイッチ（/ 3GB）があり、OSに予約されている量を1GBのみに変更し、プロセスがフラグで自分自身をラージアドレスとして宣言している場合のみプロセスに3GBを持たせることができます実行可能ファイルの。
64ビットOSの場合、32ビットプロセスは、大きなアドレスを認識している場合は4GB、それ以外の場合は2GBを取得します。
これはすべて、AWE非対応プロセス用です。プロセスがAWEを使用できる場合、他の人が言ったように、大きなアドレス空間を使用できますが、64ビットプロセスよりも効率が低くなります。
PAEでは、32ビットOSで4GB以上のRAMを使用できますが、互換性の問題があり、XPではサービスパックの1つによって無効にされたため、サーバーOSバージョンでのみ使用できます。