|
![]() ![]() ![]() ![]() ![]() | |
先日、久々に、Windows APIのGlobalMemoryStatusEx()を使用する機会がありました。 まぁ、一般には、そんな機会なんてなかなかないわけですけどね。 この関数の名前には、最後にExが付けられています。実は、Exが付かないGlobalMemoryStatus() というAPIも存在していたのですが、そのAPIでは各メモリ量の値をDWORD型(32bit整数値)で表しておりました。 32bit整数値の上限は約43億であり、メモリなら4GBまでしか表せないことになり、もし現代だったら人権無視のAPIだと言われていたかもしれません。 そんなこともあって、Windows 98の頃(正確にはWindows 95 OSR2)から、GlobalMemoryStatusEx() が新しいAPIとして追加されました。 そんな経緯もあって、「Windows 95でも動作させたいプログラムを作っている場合は、現在稼働しているOSでGlobalMemoryStatusEx()が利用可能かを調べ、その関数ポインタを取得して呼び出す」という、面倒くさいことをしなければならない状態になっていました。 今となっては、Windows 95で動作させたいかどうかを気にしなくてよいので、何も考えずにGlobalMemoryStatusEx()を呼び出しています。 で、そんなGlobalMemoryStatusEx()には仮想メモリの空き容量をバイト数で返す ullAvailVirtual と、仮想メモリの全容量をバイト数で返す ullTotalVirtual という変数が登場します。 昔、この関数をよく使っていた頃は気にしていなかったのですが、最近使ったところ、どうやら、
という感じで、どうやら固定値を返しているっぽいことがわかりました。もしかすると、3GBスイッチを有効にしたWindowsを使用していたら、また違う結果になるのかもしれませんが、試していません。 仮想メモリは、ページングとしてHDDにメモリ内容を書き込めば、原理的にはいくらでも増やすことはできるため、その時に搭載されているストレージの容量のことは置いておいて、CPU(もしくはOS?)が管理できるメモリ量の限界を、いちおうの上限として返しているということでしょうかね。 x64系のCPUで、48bitのアドレスを管理できるとするならば、256TBと返しそうなものなので、47bitに制限しているのはWindows 10の仕業ですかね。 目次の表示: ブログではないので、コメント機能とトラックバック機能は提供していません。ご質問・ご意見等はメール、フィードバックまたはTwitter等からお願いします。いただいたご質問・ご意見などは、この「管理人のひとこと」の記事に追加、あるいは新規の記事にする形で一部または全文をそのまま、あるいは加工させていただいた上で、ご紹介させていただく場合があります。 当サイトでは掲載内容による不具合等に関する責任を持ちません。また、内容の正確性についての保証もありませんので、情報をご利用の際は、利用者の自己責任で確認をお願いします。 |
- 最近の更新 - |
|
3278651 (+0160)[+0387] Copyright© 2010-2025 INASOFT |