A97: Why negative memory values reported?

[MLH]

Am using code below to display memory
status. Problem with 4th and 5th ones
(dwTotalPageFile and dwAvailPageFile).
They show up as NEGATIVE. Why might
that be?

'xxxxxxxxxxxxxxxBEGIN SNIPPETxxxxxxxxxxxxx
Private Type MEMORYSTATUS
dwLength As Long
dwMemoryLoad As Long
dwTotalPhys As Long
dwAvailPhys As Long
dwTotalPageFile As Long
dwAvailPageFile As Long
dwTotalVirtual As Long
dwAvailVirtual As Long
End Type
Private Declare Sub GlobalMemoryStatus Lib "kernel32" _
(lpBuffer As MEMORYSTATUS)

Private Sub Form_Load()

Dim MS As MEMORYSTATUS

MS.dwLength = Len(MS)
GlobalMemoryStatus MS

Label1.Caption = Format$(MS.dwMemoryLoad, "###,###,###,###") & " %
used"
Label2.Caption = Format$(MS.dwTotalPhys / 1024, "###,###,###,###")
& " Kbyte"
Label3.Caption = Format$(MS.dwAvailPhys / 1024, "###,###,###,###")
& " Kbyte"
Label4.Caption = Format$(MS.dwTotalPageFile / 1024,
"###,###,###,###") & " Kbyte"
Label5.Caption = Format$(MS.dwAvailPageFile / 1024,
"###,###,###,###") & " Kbyte"
Label6.Caption = Format$(MS.dwTotalVirtual / 1024,
"###,###,###,###") & " Kbyte"
Label7.Caption = Format$(MS.dwAvailVirtual / 1024,
"###,###,###,###") & " Kbyte"

End Sub

[Trevor Best]

MLH wrote:

Am using code below to display memory
status. Problem with 4th and 5th ones
(dwTotalPageFile and dwAvailPageFile).
They show up as NEGATIVE. Why might
that be?

'xxxxxxxxxxxxxxxBEGIN SNIPPETxxxxxxxxxxxxx
Private Type MEMORYSTATUS
dwLength As Long
dwMemoryLoad As Long
dwTotalPhys As Long
dwAvailPhys As Long
dwTotalPageFile As Long
dwAvailPageFile As Long
dwTotalVirtual As Long
dwAvailVirtual As Long
End Type

It's what happens to long integers when you poke more than 2 gig into
them and nothing is error trapped, they wrap around. Internally the API
call is using unsigned integers. It fills the space with the right
number of 1s and 0s for an unsigned representation of the amount of RAM
you have, unfortunately VB only has signed integers so when the first
bit is a 1 then it's negative. If *you* try to poke more than 2 gigs
into a long int it will give you an overflow error as you're under the
control of VB.

A lot of API calls and even VB functions such as LOF() use long
integers, they were once sufficient but not in this day and age.

You can always check if <0 then add 2 gig and put result into another
data type but that only works if you know it's < 4GB as above that
figure it'll wrap around to the positive again, theoretically anyway as
I'd suspect a 4GB limitation might come into play here.

This is an age old problem that's happened before with disk space then
with RAM as 16 bit integers were used and used to wrap around at 32K.

I even remember a prime number finder I wrote years ago in DOS BASIC, it
would error at 32K then I'd switch to using a long int and error again
at 2 billion odd where I'd switch to using singles then doubles. This
was for speed reasons so the first few primes could be calculated
quickly (this really made a difference on a 12MHz 286). Once I compiled
the program to an EXE file it would just wrap. Putting in my own error
checking for overflows would have been expensive on CPU time so I ended
up just starting with doubles anyway. Never got far without getting
bored as you can imagine number crunching on a 286 :-\

--
[OO=00=OO]

[MLH]

Thanks, Trevor.

It's what happens to long integers when you poke more than 2 gig into
them and nothing is error trapped, they wrap around. Internally the API
call is using unsigned integers. It fills the space with the right
number of 1s and 0s for an unsigned representation of the amount of RAM
you have, unfortunately VB only has signed integers so when the first
bit is a 1 then it's negative. If *you* try to poke more than 2 gigs
into a long int it will give you an overflow error as you're under the
control of VB.

A lot of API calls and even VB functions such as LOF() use long
integers, they were once sufficient but not in this day and age.

You can always check if <0 then add 2 gig and put result into another
data type but that only works if you know it's < 4GB as above that
figure it'll wrap around to the positive again, theoretically anyway as
I'd suspect a 4GB limitation might come into play here.

This is an age old problem that's happened before with disk space then
with RAM as 16 bit integers were used and used to wrap around at 32K.

I even remember a prime number finder I wrote years ago in DOS BASIC, it
would error at 32K then I'd switch to using a long int and error again
at 2 billion odd where I'd switch to using singles then doubles. This
was for speed reasons so the first few primes could be calculated
quickly (this really made a difference on a 12MHz 286). Once I compiled
the program to an EXE file it would just wrap. Putting in my own error
checking for overflows would have been expensive on CPU time so I ended
up just starting with doubles anyway. Never got far without getting
bored as you can imagine number crunching on a 286 :-\