KB_Soft Group - Software Vendor's Development Partner
Start page
Site map
Contacts
 

SMBIOS Inventory Tool

 
   

Objectives

The objective of the present project was to implement an application that would allow to get
  the DMI/SMBIOS information on the machines running under MS Windows 9x/Me/NT4/2k/XP.
   

Results

Desktop Management Interface (DMI) is a method of managing computers in an enterprise. The main component of DMI is the Management Information Format Database, or MIF. This database contains all the information about the computing system and its components. Using DMI, a system administrator can obtain the types, capabilities, operational status, installation date, and other information about the system components. The Desktop Management Interface Specification and its companion MASTER.MIF define "manageable
  attributes that are expected to be supported by DMI-enabled computer systems". Many of these attributes have no standard interface to the management software, but are known by the system BIOS. The System Management BIOS provides that interface via data structures through which the system attributes are reported. The developed application aims at being a part of the desktop management suite. The application assumes to be used for the hardware inventory purposes.
   

Developer's comments


Q: How does the application access the SMBIOS information?

KB_Soft: There are two access methods defined for the SMBIOS structures:
1. The first method provides the SMBIOS structures through a Plug-and-Play function interface. To prevent the proliferation of interfaces for accessing information embedded in the System BIOS, the SMBIOS Specification will follow the System Device Node model used by Plug and Play, and use Plug and Play BIOS functions to access DMI information. Plug and Play functions 50h-5Fh have been assigned to the SMBIOS BIOS Interface. Each of the SMBIOS BIOS Plug-and-Play functions is available both in real-mode and 16-bit protected-mode. A function called in 16-bit protected-mode supports both 16-bit and 32-bit stack segments.

2. A table-based method, defined in v2.1 of SMBIOS specification, provides the SMBIOS structures as a packed list of data referenced by a table entry point. The table convention allows the SMBIOS structures to be accessed under 32-bit protected-mode operating systems. This convention provides a searchable entry-point structure that
  contains a pointer to the packed SMBIOS structures residing somewhere in 32-bit physical address space. The SMBIOS Entry Point structure can be located by application software by searching for the anchor-string on paragraph (16-byte) boundaries within the physical memory address range 000F0000h to 000FFFFFh. This entry point encapsulates an intermediate anchor string that is used by our application. A BIOS compliant with v2.1 of SMBIOS specification can provide one or both methods. A BIOS compliant with v2.2 and later of SMBIOS specification must provide the table-based method and can optionally provide the Plug-and-Play function interface.
Our application can use both methods to access the SMBIOS structures. In each particular case, the use of a definite method depends on the version of the SMBIOS Specification supported by BIOS. If BIOS supports both methods, then the table-based method is preferable.

Q: Why did you decide to implement the application as Win16?

KB_Soft: This was necessary, as the SMBIOS data access method based on the use of the Plug-and-Play functions can be accessed only in real and 16-bit protected CPU modes.
    Q: How is the physical memory addressed?

KB_Soft: This can be implemented in a Win16 application rather easily. When an application needs to access physical memory that is not addressable with the selectors exported from the Windows kernel, it can allocate a new selector and initialize the associated descriptor with the appropriate base address and limit. The Windows kernel and the DOS Protected Mode Interface (DPMI) server (part of Windows) provide functions for applications to do this. This was the way we initially implemented in the application. But this approach does not allow to physically address memory above the 0-16 Mb range. When
  running the application, it appeared that some PC manufacturers locate the SMBIOS structures much above the 0-16 Mb range. In particular, this concerns the laptops by Toshiba and FUJITSU. That is why the special 32-bit kernel drivers were designed (Physical Memory Access Driver for MS Windows 9x/Me, Physical Memory Access Driver for MS Windows 2k/XP/2003) to access physical memory. Unfortunately, to let the Win16 application and 32-bit kernel drivers interact, we had to implement an additional module using the so called "THUNK" mechanism that allows to call the 32-bit code snippet from the 16-bit one.