xlib.doc

XLIB 2.0版 32位应用程序开发 ASM/C语言的DOS 扩展库

  virtualized.  Virtual 8086 mode interrupts will almost certainly be
  virtualized in either VCPI-based or DPMI-based environments.




                                        16






       When a key is pressed, the keyboard interrupt handler will examine the
  key to determine if it is the hot key.  If not, then the interrupt is cascaded
  to the inherited real-mode handler.  If so, then a hot key flag is recorded to
  a DWORD whose linear address is recorded at CCODEPTR (condition code pointer).
  The hot key is not cascaded.  CCODEPTR is a public DWORD in DSEG.  The hot key
  flag is listed among XLIB error codes in Appendix B.
       CCODEPTR initially contains the linear address to public DWORD location
  CCODE which is in DSEG.  Therefore, the hot key flag would be written to CCODE
  by default.  CCODEPTR may be changed by the user; however, it must point to an
  address in conventional memory.
       The hot key specification is stored in DSEG at a public WORD location
  called HOTKEY.  The lower byte of HOTKEY contains the scan code of the hot key
  while the upper byte specifies the state of the shift keys.  Bit 8 specifies
  the state of SHIFT; bit 9 specifies CTRL, and bit 10 specifies ALT.  All other
  bits are ignored.  Set bits require that the designated shift key be pressed.
  The default setting for HOTKEY is zero.  This setting disables hot key
  detection since no key has a zero scan code.
       The XLIB interrupt handler for FPU exceptions performs three major
  functions upon the occurrence of any FPU exception that is unmasked in the FPU
  control word.  First, an error code is loaded to EAX and is also recorded at
  the linear address in CCODEPTR.  Next, the FPU is initialized with FNINIT (the
  FPU control word is preserved).  Third, control is transferred to EXITPM to
  return to real mode.  The high word stored in EAX and the condition code will
  be the FPU status word.  This word may be examined to determine the nature of
  the exception.  The FPU interrupt handler is a real-mode routine.
       The response of the FPU to exception conditions is largely determined by
  the settings in the FPU control word.  If FPU save/restore is enabled, then
  the FPU control word will be set to FPUCW upon execution of CALLPM/ENTERPM.
  The default value for FPUCW is 0332H.  This sets rounding control to nearest,
  precision control to 64 bits, and unmasks exceptions for overflow, zero
  divide, and invalid operations.  Exceptions for underflow, precision, and
  denormalized operations are masked, and are therefore handled internally by
  the FPU.  FPUCW may be modified by the user.
       As explained above, the machine may be left in an unstable state after a
  program has been terminated from within a hardware interrupt handler.  This
  can also be the case for the FPU interrupt handler.  However, it will be safe
  to continue execution after FPU exceptions under clean configurations.  This
  follows because interrupts are not virtualized and because the exception will
  never be generated in the operating system (DOS does not use the FPU).  Nor
  should there be any problem with continuing execution after an exception in
  protected-mode under VCPI.  This follows since protected-mode interrupts
  cannot be virtualized under VCPI.  Exceptions occurring in Virtual 8086 mode
  or under DPMI protected mode may however leave the machine in an irregular
  state.  Reboot may be necessary in these cases.
       All tested DPMI hosts appear to be restored to normal state by execution
  of INT 21H function 4CH (DOS termination).  However, the DPMI specifications
  offer no guarantees to this approach.  FPU exceptions in virtual 8086 mode are
  generally no problem in single-task environments; however, they will
  frequently prove problematic under a multitasker such as DESQview.
       Bit 0 of OFLAGS is used by XLIB to simultaneously enable or disable all
  of its own hardware interrupt handlers.  Setting the bit enables the handlers.
  XLIB sets this bit upon calls to CALLPM/ENTERPM and clears the bit upon
  return.  All interrupts are immediately cascaded to the inherited real-mode
  handlers when the bit is clear.  Therefore, FPU exceptions are handled by XLIB



                                        17






  only after calls to CALLPM/ENTERPM.  Accordingly, hot key detection is enabled
  only after calls to CALLPM/ENTERPM.  The user may set the bit under other
  circumstances; however, XLIB will not be able to properly handle FPU
  exceptions in these cases.  The bit should be set by the user only when hot
  key detection is desired and when it is certain that the FPU exception handler
  will not be invoked.
       The FPU exception handler may be permanently disabled by setting bit 1 in
  OFLAGS.  If this bit is set, then the FPU interrupt handler simply cascades
  the interrupt to the inherited real-mode handler.  XLIB will set the bit
  during initialization if an FPU is not present; it is otherwise cleared.
       Real-mode software interrupts which receive or return values in segment
  registers cannot be used within protected mode because the deflection routine
  will restore selectors to segment registers upon completion of the interrupt.
  To use such software interrupts, one must switch to real mode through CALLRM;
  issue the interrupt, and then transfer the segment registers to other
  registers or to memory before returning to protected mode.
       Certain software interrupts use status flags for return flags, typically
  to signal error conditions.  This is particularly the case for DOS interrupts.
  The deflection routine will pass these alterations to the code which issued
  the interrupt.


  Installation of Interrupt Handlers


       The user may install real-mode interrupt handlers in usual fashion.  Such
  handlers will also receive interrupts occurring in protected mode because
  either XLIB or the DPMI host will deflect all protected-mode interrupts.  If
  XLIB deflects the interrupt, then the handler will receive SS = DSEG with ESP
  set to 100H free bytes.  Stack sizes under DPMI will depend upon the host, but
  must contain a minimum of 200H free bytes to meet DPMI specifications.
       The DOS routines to get and set interrupt vectors (INT 21H functions 35H
  and 25H) receive and return values through segment registers; consequently,
  they cannot be used in protected mode.  Instead, use the XLIB procedures
  PMGETRMIV and PMSETRMIV (protected mode - get/set real-mode interrupt vector).
       The user may install a protected-mode interrupt handler from real mode by
  calling SETPMIV (set protected-mode interrupt vector).  The current protected-
  mode interrupt vector may be obtained by calling GETPMIV.
       From protected mode, interrupt vectors can be managed with PMSETPMIV and
  PMGETPMIV.  These procedures have the same specifications as SETPMIV and
  GETPMIV.
       Interrupt handlers installed with SETPMIV/PMSETPMIV are never disabled by
  XLIB and will therefore always be active under protected-mode execution.
  These handlers will not be active under real-mode execution in the absence of
  DPMI.  That is, real-mode interrupts are never deflected to protected-mode
  handlers in such environments.  However if DPMI is active, then all hardware
  interrupts (IRQs 0-15) and the software interrupts:  1CH (BIOS timer tick),
  23H (DOS CTRL C), and 24H (DOS critical error) are deflected from real mode to
  the installed protected-mode handler.  Therefore the protected-mode handler
  always receives the interrupt first.  If the handler cascades the interrupt,
  then the real-mode handler will receive it next.  If the user has not
  installed protected-mode handlers for these interrupts, then they are serviced
  by default handlers in the DPMI host.  The default handlers typically deflect
  the interrupts to the real-mode handlers.



                                        18






       If the programmer wishes to install a protected-mode interrupt handler
  for a hardware interrupt or for INT 1CH, INT 23H, or INT 24H, then
  consideration must be given to the fact that treatment of these interrupts
  will differ under different protected-mode configurations.  As noted above,
  the DPMI host will always send these interrupts to the protected-mode handler
  regardless of the CPU mode in which the interrupt occurred.  If DPMI is not
  installed, then protected-mode handlers receive control only under protected-
  mode interrupts.  Therefore, if the protected-mode handler is to receive real-
  mode interrupts under such configurations, the programmer must install a real-
  mode handler to perform the deflection.
       XLIB includes a procedure called DEFLECTPM which can be used within a
  real-mode interrupt handler to deflect control to a protected-mode handler.
  DEFLECTPM functions only under VCPI and XLIB mode switching.  If DPMI is
  installed, then the procedure returns with no action.  The intent of this
  procedure is to enable simulation of DPMI treatment of hardware interrupts,
  INT 1CH, INT 23H, and INT 24H.
       Observe that if the real-mode handler deflects to the protected-mode
  handler, then the latter should not cascade the interrupt since an infinite
  loop would result.  This follows because the initial protected-mode handler
  deflects to the real-mode handler.
       Were one to use DEFLECTPM in a real-mode handler for the interrupts named
  above, then the protected-mode handler will receive all interrupts regardless
  of the protected-mode configuration.  This occurs naturally under DPMI.
  DEFLECTPM ensures that it will occur under other configurations.  Observe that
  under DPMI, the real-mode handler will never be executed.
       It is sometimes important that interrupt handlers execute in shortest
  possible CPU time.  This would typically be the case for handlers of the
  communication ports.  Since mode switching is time consuming, such handlers
  should be installed for the CPU mode which is expected to receive the most
  interrupts.
       If DPMI is installed, then it is possible for multiple clients to operate
  in a single virtual machine.  In such cases, DPMI will always send hardware
  interrupts to the primary client (the most recently installed client in the
  virtual machine).
       Under DPMI, all protected-mode handlers for hardware interrupts and
  software interrupts 0-7 will receive control with interrupts disabled.  Since
  DPMI virtualizes the interrupt flag, the IRET instruction may not reenable
  interrupts.  Consequently, all handlers for these interrupts should execute
  STI before executing IRET.  Other protected-mode interrupts do not affect the
  interrupt flag.
       All real-mode interrupt handlers will receive control with interrupts
  disabled regardless of the protected-mode configuration.  All protected-mode
  handlers will receive control with interrupts disabled under VCPI or XLIB mode
  switching.  However, if DPMI is installed, then protected-mode software
  interrupts apart from 0-7 will receive the virtual interrupt flag at its value
  as of the INT instruction.  That is, DPMI does not alter the interrupt flag in
  these cases.
       Hardware interrupts IRQ 0 through IRQ 7 are typically assigned to
  interrupt numbers 08H through 0FH, while IRQs 8 through 15 are typically
  assigned interrupt numbers 70H through 77H.  However, IRQs are remapped in
  some operating environments, typically to facilitate exception handling.  The
  current mappings may be loaded from IRQ0INTNO (IRQ 0 interrupt number) and
  IRQ8INTNO.  These are public BYTE locations in DSEG.  They should be read only
  after the call to INITXLIB.



                                        19






       DESQview does remap hardware interrupts; however, its interrupt handlers
  for the new locations generally transfer control to the addresses at the
  conventional vectors.  DESQview must be started with a command-line switch if
  it is to accommodate certain hardware interrupts.  In particular, the FPU
  interrupt will not function properly under DESQview unless DESQview is started
  with DV /HW:75:C.


  Detailed Specifications


  PMGETRMIV (Protected Mode - Get Real-Mode Interrupt Vector)
  Purpose:  Retrieve address of real-mode interrupt handler from protected mode.
  CPU Mode:  Protected
  Registers at Call:  AL = interrupt number.
  Return Registers:  Handler address returned in CX:DX.
  Details:  The DOS routine for this purpose (INT 21H function 35H) is not
  useful because it returns a value in ES.

  PMSETRMIV (Protected Mode - Set Real-Mode Interrupt Vector)
  Purpose:  Set address of real-mode interrupt handler from protected mode.
  CPU Mode:  Protected
  Registers at Call:  AL = interrupt number, CX:DX = address of handler.
  Return Registers:  None
  Details:
     The DOS routine for this purpose (INT 21H function 25H) is not useful
  because it requires an argument in DS.
     Real-mode interrupt handlers will also be called when interrupts occur in
  protected mode provided that the protected-mode interrupt handler cascades the
  interrupt.  The default protected-mode handlers do in fact cascade all
  interrupts.
     XLIB never disables handlers installed by this procedure.

  GETPMIV (Get Protected-Mode Interrupt Vector)
  Purpose:  Retrieve address of protected-mode interrupt handler from interrupt
  descriptor table.
  CPU Mode:  Real
  Registers at Call:  AL = interrupt number.
  Return Registers:  Handler address returned in CX:EDX (CX is a selector).
  Details:  This routine does not return addresses of CPU exception handlers
  under DPMI.  Use DPMI functions directly for this purpose.

  SETPMIV (Set Protected-Mode Interrupt Vector)
  Purpose:  Set address of protected-mode interrupt handler in interrupt
  descriptor table.
  CPU Mode:  Real
  Registers at Call:  AL = interrupt number.  Handler address in CX:EDX (CX is a
  selector).
  Return Registers:  EAX = 0 if successful.  EAX = error code if unsuccessful.
  AX = XLIB error code.  If DPMI is installed then the high word of EAX will
  contain a DPMI 1.0 error code (if provided by host).
  Details:
     XLIB never disables handlers installed by this procedure.




                                        20






     Protected-mode interrupt handlers never receive interrupts occurring in
  real mode unless DPMI is active.  Under DPMI all hardware interrupts (IRQs 0-
  15) and software interrupts 1CH, 23H, and 24H are deflected from real mode to
  the installed protected-mode handler.  The protected-mode handler therefore
  receives control of the interrupt first.  It may cascade the interrupt if so
  desired, in which event, the real-mode handler receives the interrupt next. If
  no protected-mode handler has been installed, then DPMI generally deflects the
  interrupt to the real-mode handler.
     All protected-mode handlers will receive control with interrupts disabled
  unless DPMI is installed.  Under DPMI, protected-mode software interrupts
  apart from 0-7 do not alter the state of the virtual interrupt flag.
     Protected-mode handlers under DPMI for hardware interrupts and software
  interrupts 0-7 should execute STI before IRET to ensure that the virtual
  interrupt flag is enabled.
     If multiple DPMI clients are running in the same virtual machine, then the
  primary client (most recently installed client) always receives hardware
  interrupts.
     If DPMI is installed, then protected-mode interrupt vectors should be reset
  to original values before termination.
     This routine should not be used to install CPU exception handlers under
  DPMI.  DPMI functions should be used for this purpose.

  PMGETPMIV (Protected Mode - Get Protected-Mode Interrupt Vector)
  Purpose:  Retrieve address of protected-mode interrupt handler from interrupt
  descriptor table.
  CPU Mode:  Protected
  Details:  This routine is the protected-mode version of GETPMIV