[Toc][Index]

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