>>>>>>Well, if the Windows Explorer is returning the incorrect results on one machine and not another, then I would say that it's almost a 100% sure thing that it's a ROM BIOS issue rather than a problem with the function. Simply consider the fact that the same exact function, in the same exact DLL is being called in both cases. Yet you get the wrong result from one machine and the right result from the other.
>>>>>>
>>>>>>I'd look at the setup routine that you can access when the computer boots. That will give you one clue. Further, a BIOS extender will have it's own setup program you may want to check.
>>>>>
>>>>>George, let me repeat my statement. I checked on two Windows 95 machines in the office and both returned incorrect result. I then checked on Windows NT machine (this machine is terribly slow, each operation takes ~5-10 min., the owner said, that he is working "slowly" :)) and it returned correct results both from WE and from VFP. So, my conclusion is that it depends on OS. For purity of the experiment I should try from home, where I'm running Windows 98.
>>>>
>>>>Nadya,
>>>>
>>>>*IF* all of the Win95 machines are the same brand purchased at the same time with identical features, then your conclusion *could* be an accurate one for that office. But it surely would NOT be correct for my setup, most likely, because I no doubt have a different BIOS on my machine.
>>>>
>>>>If you have Win95 machines with different configurations, especially BIOS and brand name, then try all the various kinds. You will have a good chance to see what George is trying to say.
>>>>
>>>>JimN
>>>
>>>Thanks, Jim. I now understood what George was trying to explain me. I can ask our Network Administrator about specific of company hardware (purchase, brand, etc.) and run this experiment on few other machines. Currently I ran it only on my and my manager computers, which both failing to show the correct result. Also our Network Administrator said, that it's an OS thing and Windows 95 doesn't recognize this amount correctly. He might be wrong, of course.
>>
>>Nadya,
>>
>>Read the FAQ again. It explains when GetDiskFreeSpaceEx() came into being (in terms of Windows version). If the function in the FAQ can't access it, it returns zero.
>>
>George, I re-read this FAQ again (BTW, got 'unhandled request' message the fisrt time I tried to search). I'm saying, that function returns 2GB instead of 68GB on my Windows 95. For another drive, which is 18GB, it returns the correct result. In our office all machines are the same, so I can not prove, if it's BIOS or not thing. Server itself and another Windows NT machine shows the correct amount. My conclusion is: "In our office Windows 95 machines don't return this info correctly for drives greater than 64GB". I can also test this from home through PCAnywhere. I don't have any other abilities to test.
>
>
>>To the best of my re-collection, when I originally wrote it (August, 1999), I was running Win95 and tested it against a Win95 box.
>
>Right, but I'm guessing, you don't try it on 68GB drives :)

Nope. In fact, I don't think I ever dealt with one that large. However, the data type that's being simulated is a PULARGE_INTEGER, or IOW, a pointer to an unsigned large integer, which is 64 bits and has the capacity or 1.8446744E+19, which is well in excess of 68 gb.

In looking over the help libraries, I note that this type is actually a union and is described as follows:
""

typedef union _ULARGE_INTEGER { 
  struct {
      DWORD LowPart; 
      DWORD HighPart; 
  };
  ULONGLONG QuadPart;
} ULARGE_INTEGER, *PULARGE_INTEGER;

Members
LowPart
Specifies the low-order 32 bits.
HighPart
Specifies the high-order 32 bits.
QuadPart
Specifies a 64-bit unsigned integer."

ULONGLONG is of type _int64.

This has been done this way for compilers that don't support the _int64 sized integer type. IOW, if the compiler doesn't support _int64, the two DWORDS are set. If it does, the QuadPart is set. In either case, however, because it's a union, the size is still 8 bytes. MS VC++ supports _int64.