![[Toc]](../../toc.gif)
![[Index]](/idx.gif)
PMIREQUEST_SOFTWAREINT - Remarks
This API allows for real-mode BIOS calls that need up to 4 KB in one or
two input or output buffers. Although the service is generic, only VIDEO
BIOS has been tested.
There are two types of worker VDM processes, depending on the requested
VDM initialization as well as on the level of VDM support installed on the
target machine, as follows:
1. Full VDM.
This process is equivalent to a full-screen DOS session that is
created via an icon, stripped of its OS/2 components. The session
has unrestricted video access. The session's DOS settings are
manipulated by the VIDEOPMI and, therefore, are not affected by any
standard settings or modifications to any of the DOS icons. The
session can never be given foreground focus and is terminated only
after its parent process terminates. If that should occur, there are
no limitations on creating a new worker process. However, because
the shell is the parent process, the event is unlikely. The session
is completely hidden, as it is created without the knowledge of the
session manager.
Note: When the int 10 full VDM session is started, the system will
attempt to execute a videopmi.bat file. If the system does
not find a videopmi.bat file in the root directory, it will
default to autoexec.bat.
Because users often customize the autoexec.bat file, the
autoexec.bat is unreliable or unusable in the int 10 full
VDM session. To be sure the system has full control of the
run-time environment of that session, make sure a
videopmi.bat file exists in the system root directory.
Attention: LIMITATION
a. The full-VDM process can be created only under the shell
process. VIDEOPMI ensures that the creation is limited to this
window. A kernel patch is needed to cover any situations in
which this may not be acceptable, for example, running a custom
shell or testing the base video without a shell.
b. Full VDM requires that DOS support be installed on the target
machine. As a result, a vendor driver using the software
interface must ensure that this information is relayed to the
customer. If, for any reason, DOS support is not desirable,
full VDM is not the appropriate software interrupt solution and
the Mini-VDM process described below should be used.
To ensure that a full-VDM process is created, the caller that
initializes the VDM environment must specify the pIn parameter.
Specifying the pIn->ulFlags = VDM_INITIALIZE is sufficient.
Optional application name and parameters may be specified as
well. When initializing, if VDM creation fails, one of the
following errors is returned:
ERROR_INADEQUATE_VDM_SUPPORT
Make sure vprpmi.sys is installed.
ERROR_FULLVDM_CREATION_NOT_SHELLPROCESS
The limitation listed under 1.a. (above)
applies.
ERROR_MINIVDM_PROCESSUPPORT_ONLY
Make sure vprpmi.sys is installed. Mini-VDM is
available, so subsequent requests may be
successful.
2. Mini VDM
This type of VDM process is provided for customer situations in
which installing DOS support or running a full-VDM process is
unacceptable. A mini-VDM process is a minimal v86 process for which
ROM BIOS, BIOS data area, and video aperture are mapped in. All of
the same calling interfaces and buffer passing capabilities of the
full VDM apply. The worker VDM is created by the kernel as a child
of the root process and, as such, is indestructable. If the video
subsystem that created the process is unloaded and reloaded, the
same VDM process is used.
Attention: LIMITATION
a. Virtualization of hardware resources and the exception
management of mini-VDM are virtually nonexistent. All of the
I/O resources are mapped physical, so any I/O that is executed
goes to the hardware. None of the hardware interrupts are
reflected; for example, timer ticks are not reflected in the
BIOS data area. All of the ROM areas are mapped physical, so
any self-modifying BIOS (those that are not in true ROM, of
course) will affect subsequently started VDMs. The BIOS data
area is the only page that is mapped linear, which means that
it can be garbled without any danger to other VDMs running in
the system.
There is no exception management. As a result, any of the
unmapped memory (from 4 KB up to 0x9FFFF) or above 1 MB that is
touched will cause a kernel exception to occur (no recovery).
Neither virtual drivers nor the DOS kernel is loaded in this
process, so no TSRs or utilities can be executed.
b. This solution requires a kernel patch for OS/2 Warp, Version
3.x customers, and a kernel patch and DOSCALLS.DLL upgrade for
OS/2 2.x customers, in addition to the base video files.
Created using Inf-PHP v.2 (c) 2003 Yuri Prokushev
Created using Inf-HTML v.0.9b (c) 1995 Peter Childs