| |
|
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.
|