>>It's reading the information from the BIOS (I think) on startup. These days the cluster size really isn't a big issue given the low cost of large hard drives. It's of realitively little importance. Further, cluster size is valid only on the local machine (if it's being reported correctly, which it isn't always). A network OS, such as Novell may report back that the cluster size is 32K, when in reality it's much smaller.
>
>I see the point on this specific issue. More generally, have you run into other properties/system information of this type that developers might want to know but are not able to access through the API and do you have thoughts as to why they (MS) would not provide a hook to it?
>
>For myself, I needed to get the processor clock rate thru an ActiveX control I developed and used some inline assembler code from another developer that effectively "calculates" the clock rate, since there was so "direct" route ( when I wrote the control ) to this information through the API w/o going through the WMI, which looked like a pain in the neck at the time. :-)
>
>In light of this thread, I was wondering as to the (MS) thought process as to why access to certain pieces of info would be restricted and was interested if you have any thoughts on this.

I think that this may fall into the "hardware abstraction" area. I don't see the information being "restricted" so much as unneeded. The only time that a problem could arise is if the application had to write multiple files to a disk at one time. If you've got enough free space on the drive for a single file, then the cluster size is irrelevant. However, when writing multiple files, then it could come into play.

I think a better illustration of this would be the status of a printer. We've seen the question as to how to determine this from within VFP a number of times. Even winspool.drv itself doesn't know this. Why? Simply because it hands the job over to the driver for the particular printer. It's that driver's responsibility to make this determination and, if a problem exists, notify the user. If a problem does exist, the print job will stay in the queue until either the problem is resolved or the job is deleted.

The big upside to this is that the programmer doesn't have to worry about this stuff and other related deltails. I mean does anyone really miss having to send escape sequences to the printer?

I think that this part of the price of having a pre-emptive multi-tasking operating system. It's the operating system that's in charge, not the application (as it was back in the DOS days). Further, having the operating system in charge is the only way to have a pre-emptive multi-tasking OS. The benefit is that you're largely shielded from some of the details and don't have to worry about it. The drawback is that if you really, really need the information it can be tough, if not impossible, to get to. If one were to find themselves in need of such, the question as to whether or not the information is absolutely essential must be answered.