So effectively none of this applies to pre-Vista versions of Windows, all of which are officially unsupported now anyway. It is important to note that this API entrypoint did not become available until Windows Server 2003 SP1 and Windows XP Professional 64-bit SP3. Once retrieved it browses (some would say 'parses' but we really aren't) the compound structure for data items. It requires no 3rd party libraries and makes use of GetSystemFirmwareTable() in Kernel32.dll to retrieve the raw data. This is a VB6 collection class SmbiosInformation and a small item class SmbiosItem.
So here is an approach that bypasses WMI to get the same information. That's usually just fine, since it seldom makes sense for applications to use such information anyway, so WMI admin scripts usually more than suffice.īut some people still want to do this, as unreliable as the SMBIOS info is.
One of the things people often fall back on WMI for is system information, particularly information retrieved from the SMBIOS data block. It isn't meant for application use and if a user stops the service for security reasons relying on it can leave your program high and dry. WMI is a bulky service with a COM-based API that was meant to help computer technicians write administrative maintenance scripts.
