>I am aware of the SYSINFO control. Althought this one does provide helpful tools it does not look at hardware.
>
Mike, I'm afraid you're not going to like the answer, but trying to get detailed information on the hardware via VFP is non-trivial. Some of the details can be obtained by scanning through the registry; the HKEY_LOCAL_MACHINE\Hardware key contains a wealth of detail. Some of the details, such as FSB speed, wait states, CPU clocking and the like need to be determined empirically, and the Windows environment, particularly NT and Win2K, make it difficult or impossible for a standard application to do the sort of detailed checking that might be necessary. VFP is not well-suited to low-level systems programming tasks.
A number of companies sell hardware inventory and benchmark applications; you might want to check for a commercial COM component that meets your requirements from a vendor like Component Source (
www.componentsource.com) that tests their products for VFP compatibility, or somewhere like Hallogram (they're accessible from the upper left frame on UT) that specializes in VFP-specific addons. Or try some shareware sites - I found this one on ZDNet -
SysInfo OCX - this is not the same one supplied by MS.
I'd be inclined to use a standalone benchmark and inventory product like WinBench or WinTune to test systems and produce a report, and then pull the information from the report into a VFP app if it were needed there. These products provide a reference benchmark that has some meaning and consistency when evaluating different systems, and are designed to operate outside of the normal application environment, so that they can access the hardware more directly. They're also good at spotting Windows configuration issues that might not have an effect on optimizing VFP's settings, but might be affecting overall system performance.
If you want to write your own components to try to extract detailed information on system hardware, I'd start at
www.x86.org - one of the best systems programming and detailed hardware architecture sites on the web, now operated by Doctor Dobbs Journal, an old and established hardware geek publication. There are articles available from the site describing mechanisms to detect CPU steppings, details on the support chipset and much more. You'll need to work in another language than VFP to implement most of the stuff they talk about.
One problem you face with trying to pin down requirements based on MHz or MB is that the numbers don't mean much in and of themselves. A 700MHz Pentium III is slower than a 700MHz Athlon, all other things being equal. Having PC100 compliant memory in the system doesn't make a bit of difference if the FSB runs at 66MHz, and may not be faster than a system with PC66 memory if the chipset is inserting extra wait states running with a 100MHz FSB. I can point to several clients who found that their systems got -much- slower when they went from 512MB of RAM to 1GB. Raw numbers are deceptive in many cases.
The most meaningful benchmarks for your applications would be to construct a variety of test scenarios that exercise the system in ways that directly correspond to the things your application will be doing. This would provide you with a mechanism for examining target systems based on the kind of work you expect them to perform in your application - something much more reasonable than CPU clock speed or memory. This allows you to establish a meaningful performance standard for the things that are important to your application. Equally important, it gives you a meaningful baseline for system optimization; you can record the base performance of the system, and then make configuration adjustments and rerun the benchamrk, comparing the result to the baseline measurement. Raw numbers in and of themselves may not be helpful - it's possible to have too much RAM or too much swapfile space (especially with NT!) and relying on the raw specs for the components of a system don't reliably predict system performance.
