home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Professional / OS2PRO194.ISO / os2 / info / document / redbooks / os2redb2.inf (.txt) < prev    next >
OS/2 Help File  |  1992-08-27  |  832KB  |  16,097 lines
  1.  
  2. ΓòÉΓòÉΓòÉ 1. (C) Copyright IBM Corp. 1992 ΓòÉΓòÉΓòÉ
  3.  
  4. (C) Copyright International Business Machines Coporation 1992. All rights 
  5. reserved. 
  6.  
  7. Note to U.S. Government Users - Documentation related to restricted rights - 
  8. Use, duplication or disclosure is subject to restrictions set forth in GSA ADP 
  9. Schedule Contract with IBM Corp. 
  10.  
  11.  
  12. ΓòÉΓòÉΓòÉ 2. Cover ΓòÉΓòÉΓòÉ
  13.  
  14.  
  15. ΓòÉΓòÉΓòÉ <hidden> Title Page ΓòÉΓòÉΓòÉ
  16.  
  17.  
  18.                                                                 OS/2 Version 2.0
  19.                                                        Volume 2: Dos and Windows
  20.                                                                      Environment
  21.  
  22.                                                     Document Number GG24-3731-00
  23.  
  24.                                                                       April 1992
  25.  
  26.  
  27.                                                          International Technical
  28.                                                                   Support Center
  29.  
  30.                                                                       Boca Raton
  31.  
  32.  
  33. ΓòÉΓòÉΓòÉ 3. Version Notice ΓòÉΓòÉΓòÉ
  34.  
  35. Take Note:  Before using this information and the product it supports, be sure 
  36.             to read the general information under Special Notices. 
  37.  
  38. First Edition (April 1992) 
  39.  
  40. This edition applies to OS/2 Version 2.0. 
  41.  
  42. Order publications through your IBM representative or the IBM branch office 
  43. serving your locality. Publications are not stocked at the address given below. 
  44.  
  45. A form for reader's comments appears at the back of this publication. If the 
  46. form has been removed, address your comments to: 
  47.  
  48. IBM Corporation, International Technical Support Center
  49. Dept. 91J, Building 235-2 Internal Zip 4423
  50. 901 NW 51st Street
  51. Boca Raton, Florida 33432 USA
  52.  
  53. When you send information to IBM, you grant IBM a non-exclusive right to use or 
  54. distribute the information in any way it believes appropriate without incurring 
  55. any obligation to you. 
  56.  
  57. MAK - Revision 1.0
  58.  
  59.  
  60. ΓòÉΓòÉΓòÉ 4. Abstract ΓòÉΓòÉΓòÉ
  61.  
  62. This document describes both the Multiple Virtual DOS Machines (MVDM) component 
  63. of OS/2 Version 2.0 and the implementation of Microsoft Windows application 
  64. support under OS/2 Version 2.0.  It forms Volume 2 of a five volume set; the 
  65. other volumes are: 
  66.  
  67.  OS/2 Version 2.0 - Volume 1:  Control Program GG24-3730 
  68.  
  69.  OS/2 Version 2.0 - Volume 3:  Presentation Manager and Workplace Shell 
  70.   GG24-3732 
  71.  
  72.  OS/2 Version 2.0 - Volume 4:  Application Development GG24-3774 
  73.  
  74.  OS/2 Version 2.0 - Volume 5:  Print Subsystem GG24-3775 
  75.  
  76. The entire set may be ordered as OS/2 Version 2.0 Technical Compendium, 
  77. GBOF-2254. 
  78.  
  79. This publication is intended for IBM customers, IBM system engineers,  and IBM 
  80. authorized dealers, and other individuals who require a knowledge of the 
  81. features, functions, and implementation of DOS and Microsoft Windows 
  82. application support under OS/2 Version 2.0. 
  83.  
  84. This document assumes that the reader is generally familiar with the DOS 
  85. operating system and Microsoft Windows, and with the function provided in 
  86. previous releases of OS/2. 
  87.  
  88.  
  89. ΓòÉΓòÉΓòÉ 5. Acknowledgements ΓòÉΓòÉΓòÉ
  90.  
  91. The project leader and editor for this project was: 
  92.  
  93. Hans J. Goetz
  94. International Technical Support Center, Boca Raton
  95.  
  96. The authors of this document are: 
  97.  
  98. Robert Beck
  99. IBM United Kingdom
  100.  
  101. Herman Benders
  102. IBM Netherlands
  103.  
  104. Bo Falkenberg
  105. IBM Denmark
  106.  
  107. Dorle Hecker
  108. IBM Germany
  109.  
  110. Patrick Lee
  111. IBM Australia
  112.  
  113. Robert Penrose
  114. IBM Canada
  115.  
  116. Dwight Ronquest
  117. ISM South Africa
  118.  
  119. Laurie Rose
  120. IBM UK
  121.  
  122. Karl-Peter Schweder
  123. IBM Germany
  124.  
  125. Tim Sennitt
  126. IBM UK
  127.  
  128. Neil Stokes
  129. IBM Australia
  130.  
  131. Bernd Westphal
  132. IBM Germany
  133.  
  134. This publication is the result of a series of residencies conducted at the 
  135. International Technical Support Center, Boca Raton. 
  136.  
  137. This document was converted to the Information Presentation Facility by: 
  138.  
  139. Michael Kaply
  140. IBM Development Laboratories, Austin.
  141.  
  142. Thanks to the following people for the invaluable advice and guidance provided 
  143. in the production of this document: 
  144.  
  145. Terri Beck
  146. IBM Programming Center, Boca Raton.
  147.  
  148. Sam Casto and his staff
  149. IBM Programming Center, Boca Raton.
  150.  
  151. Monte Copeland
  152. IBM Programming Center, Boca Raton.
  153.  
  154. Mark Fiechtner
  155. IBM Programming Center, Boca Raton.
  156.  
  157. George Fulk
  158. IBM Programming Center, Boca Raton.
  159.  
  160. Alfredo Guti╨Ærrez
  161. IBM EMEA Education Center, Boca Raton.
  162.  
  163. Kip Harris
  164. IBM Programming Center, Boca Raton.
  165.  
  166. David Kerr
  167. IBM Programming Center, Boca Raton.
  168.  
  169. Bill Madden
  170. IBM Programming Center, Boca Raton.
  171.  
  172. Martin McElroy
  173. IBM European Personal Systems Center, Basingstoke.
  174.  
  175. Jeff Muir
  176. IBM Programming Center, Boca Raton.
  177.  
  178. Frank Schroeder
  179. IBM Programming Center, Boca Raton.
  180.  
  181. Jerry Stegenga
  182. International Technical Support Center, Boca Raton.
  183.  
  184. John Tyler
  185. IBM Programming Center, Boca Raton.
  186.  
  187. David Young
  188. IBM Western Area Systems Center, Los Angeles.
  189.  
  190. Thanks also to the many people, both within and outside IBM, who provided 
  191. suggestions and guidance, and who reviewed this document prior to publication. 
  192.  
  193. Thanks to the following people for providing excellent tools, used during 
  194. production of this document: 
  195.  
  196. Dave Hock (CUA Draw)
  197. IBM Cary.
  198.  
  199. J╨ærg von K╨önel (PM Camera)
  200. IBM Yorktown Heights.
  201.  
  202. Georg Haschek (BM2IPF)
  203. IBM Austria.
  204.  
  205.  
  206. ΓòÉΓòÉΓòÉ 6. Figures ΓòÉΓòÉΓòÉ
  207.  
  208.  Concurrent DOS Applications under the Workplace Shell 
  209.  MVDM Architecture 
  210.  MVDM System Structure Overview 
  211.  MVDM System Structure and Control Flow 
  212.  MVDM Protected Mode processes 
  213.  VDM Exception Handling 
  214.  Typical VDM Address Space Map 
  215.  VDM Initialization 
  216.  Virtual Display Management 
  217.  Virtual Keyboard Management 
  218.  Virtual Mouse Management 
  219.  VDM Exceptions and Interrupt Handling in a V86 Mode Task 
  220.  Descriptor Privilege Levels 
  221.  A20 Line Service (64KB Wraparound) 
  222.  V86 Memory Map Prior to DOS Emulation Initialization 
  223.  V86 Memory Map at Initial V86 Mode Entry 
  224.  V86 Memory Map after Initialization 
  225.  Default AUTOEXEC.BAT File 
  226.  Physical and Virtual Device Drivers under OS/2 Version 2.0 
  227.  Structure of Bi-Modal Device Drivers in OS/2 V1.x 
  228.  Physical Device Driver Statements in CONFIG.SYS 
  229.  Virtual Device Driver Statements in CONFIG.SYS 
  230.  Virtual COM and Physical COM Device Drivers 
  231.  Virtual Printer Device Driver Operation 
  232.  Virtual Programmable Interrupt Controller 
  233.  General Overview of Different Types of Memory for DOS Applications 
  234.  Expanded Memory Manager Control Flow 
  235.  Memory Map of Areas Supported by Extended Memory 
  236.  Extended Memory Manager Control Flow 
  237.  CONFIG.SYS - Loading Device Drivers into UMBs 
  238.  LOADHIGH Command - Loading TSRs into UMBs 
  239.  The Migrate Applications Windows 
  240.  DBTAGS.DAT 
  241.  User Definitions for other Applications 
  242.  Windows Applications Running under OS/2 Version 2.0 
  243.  Single Windows Application Running under OS/2 Version 2.0 
  244.  Single Windows Application(s) Running "Seamless" on the OS/2 Version 2.0 
  245.   Desktop 
  246.  Implementation of "Seamless" WIN-OS/2 VDM in OS/2 Version 2.0 
  247.  Installing Windows Support under OS/2 Version 2.0 
  248.  Defining a Windows Application to OS/2 Version 2.0 
  249.  Migrating the Windows Initialization Files 
  250.  p.Detailed View of the WIN-OS/2 Data Connections 
  251.  Low Level View of the WIN-OS/2 Printing Data Flow 
  252.  File Structure of Adobe Type Manager 
  253.  OS/2 Version 2.0 Clipboard Environment 
  254.  DDE Process between Windows Environments 
  255.  DDE Process between Presentation Manager and Windows 
  256.  Client/Server Structure for Operating System Extenders 
  257.  The Program Page of the Settings Notebook 
  258.  The Session Page of the Settings Notebook 
  259.  The DOS Settings Dialog of the Settings Notebook 
  260.  Setting Up a TSR Program 
  261.  The DOS Settings Dialog of the Settings Notebook 
  262.  The Program Page of the Settings Notebook for a VMB 
  263.  DOS Settings - DOS_STARTUP_DRIVE 
  264.  VMB from an OS/2 V2.0 Program 
  265.  Personal Communications/3270 for Windows running under OS/2 V2.0 
  266.  Memory Map of Extended Memory (HMA, UMA, and EMBs) 
  267.  QENV.BAT Batch File 
  268.  C Source Code for ENVIRON.EXE 
  269.  INT19.BAS Source Code 
  270.  GRAPHIC.BAS Source Code 
  271.  
  272.  
  273. ΓòÉΓòÉΓòÉ 6.1. Concurrent DOS Applications under the Workplace Shell ΓòÉΓòÉΓòÉ
  274.  
  275. We apologize for the picture quality.  The original was not available. 
  276.  
  277.  
  278. ΓòÉΓòÉΓòÉ 6.2. MVDM Architecture ΓòÉΓòÉΓòÉ
  279.  
  280.  
  281. ΓòÉΓòÉΓòÉ 6.3. MVDM System Structure Overview ΓòÉΓòÉΓòÉ
  282.  
  283.  
  284. ΓòÉΓòÉΓòÉ 6.4. MVDM System Structure and Control Flow ΓòÉΓòÉΓòÉ
  285.  
  286.  
  287. ΓòÉΓòÉΓòÉ 6.5. MVDM Protected Mode processes ΓòÉΓòÉΓòÉ
  288.  
  289.  
  290. ΓòÉΓòÉΓòÉ 6.6. VDM Exception Handling ΓòÉΓòÉΓòÉ
  291.  
  292.  
  293. ΓòÉΓòÉΓòÉ 6.7. Typical VDM Address Space Map ΓòÉΓòÉΓòÉ
  294.  
  295.  
  296. ΓòÉΓòÉΓòÉ 6.8. VDM Initialization ΓòÉΓòÉΓòÉ
  297.  
  298.  
  299. ΓòÉΓòÉΓòÉ 6.9. Virtual Display Management ΓòÉΓòÉΓòÉ
  300.  
  301.  
  302. ΓòÉΓòÉΓòÉ 6.10. Virtual Keyboard Management ΓòÉΓòÉΓòÉ
  303.  
  304.  
  305. ΓòÉΓòÉΓòÉ 6.11. Virtual Mouse Management ΓòÉΓòÉΓòÉ
  306.  
  307.  
  308. ΓòÉΓòÉΓòÉ 6.12. VDM Exceptions and Interrupt Handling in a V86 Mode Task ΓòÉΓòÉΓòÉ
  309.  
  310.  
  311. ΓòÉΓòÉΓòÉ 6.13. Descriptor Privilege Levels ΓòÉΓòÉΓòÉ
  312.  
  313.  
  314. ΓòÉΓòÉΓòÉ 6.14. A20 Line Service (64KB Wraparound) ΓòÉΓòÉΓòÉ
  315.  
  316.  
  317. ΓòÉΓòÉΓòÉ 6.15. V86 Memory Map Prior to DOS Emulation Initialization ΓòÉΓòÉΓòÉ
  318.  
  319.  
  320. ΓòÉΓòÉΓòÉ 6.16. V86 Memory Map at Initial V86 Mode Entry ΓòÉΓòÉΓòÉ
  321.  
  322. This diagram shows the VDM's memory map when the V86 mode DOS Emulation kernel 
  323. is first invoked. 
  324.  
  325.  
  326. ΓòÉΓòÉΓòÉ 6.17. V86 Memory Map after Initialization ΓòÉΓòÉΓòÉ
  327.  
  328. This diagram shows the VDM's memory map after initialization of the DOS 
  329. environment and prior to loading a DOS application. 
  330.  
  331.  
  332. ΓòÉΓòÉΓòÉ 6.18. Default AUTOEXEC.BAT File ΓòÉΓòÉΓòÉ
  333.  
  334. PATH C:\OS2;C:\OS2\MDOS;C:\;
  335. LOADHIGH APPEND C:\OS2;C:\OS2\SYSTEM
  336. PROMPT $I$P$G
  337.  
  338.  
  339. ΓòÉΓòÉΓòÉ 6.19. Physical and Virtual Device Drivers under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  340.  
  341. This example shows the asynchronous communications port. 
  342.  
  343.  
  344. ΓòÉΓòÉΓòÉ 6.20. Structure of Bi-Modal Device Drivers in OS/2 V1.x ΓòÉΓòÉΓòÉ
  345.  
  346.  
  347. ΓòÉΓòÉΓòÉ 6.21. Physical Device Driver Statements in CONFIG.SYS ΓòÉΓòÉΓòÉ
  348.  
  349. DEVICE=C:\OS2\MOUSE.SYS TYPE=PDIMOU$            (Mouse PDD)
  350. DEVICE=C:\OS2\COM.SYS                           (COM port PDD)
  351.  
  352.  
  353. ΓòÉΓòÉΓòÉ 6.22. Virtual Device Driver Statements in CONFIG.SYS ΓòÉΓòÉΓòÉ
  354.  
  355. DEVICE=C:\OS2\MDOS\VMOUSE.SYS                   (Mouse VDD)
  356. DEVICE=C:\OS2\MDOS\VCOM.SYS                     (COM port VDD)
  357. DEVICE=C:\OS2\MDOS\VEMM.SYS                     (EMS VDD)
  358.  
  359.  
  360. ΓòÉΓòÉΓòÉ 6.23. Virtual COM and Physical COM Device Drivers ΓòÉΓòÉΓòÉ
  361.  
  362.  
  363. ΓòÉΓòÉΓòÉ 6.24. Virtual Printer Device Driver Operation ΓòÉΓòÉΓòÉ
  364.  
  365.  
  366. ΓòÉΓòÉΓòÉ 6.25. Virtual Programmable Interrupt Controller ΓòÉΓòÉΓòÉ
  367.  
  368. Notes to the numbers in the above figure: 
  369.  
  370.  1.  8259 PIC port accesses 
  371.      VPIC initialization entry point (VDDInit) 
  372.      VPIC VDM creation entry point (vpicCreateVDM) 
  373.  
  374.  2.  Call when interrupts enabled service (VDHArmSTIHook) 
  375.      Return to VDM interrupt code service (VDHPushInt) 
  376.  
  377.  3.  Set the global and the VDM context hook service (VDHArmContextHook) 
  378.      Start the timer service (VDHArmTimerHook) 
  379.      Set the VDM priority service (VDHSetPriority) 
  380.  
  381.  4.  Set the IRET and EOI handlers service (VDHOpenVIRQ) 
  382.      Set the virtual IRR request service (VDHSetVIRR) 
  383.      Clear the virtual IRR request service (VDHClearVIRR) 
  384.      Get virtual IRQ status service (VDHQueryVIRQ) 
  385.      Send virtual EOI service (VDHSendEOI) 
  386.      Wait for simulated interrupt service (VDHWaitVIRRs) 
  387.      Wake up the VDM waiting for a simulated interrupt (VDHWakeVIRRs) 
  388.  
  389.  5.  Physical PIC hardware interrupt requests and EOI 
  390.      VPIC requests an IRQ level will be dispatched to VPIC if no physical 
  391.     device driver services the interrupt (INTSetVDMIRQ) 
  392.      VPIC notifies the interrupt manager of the end of the interrupt 
  393.     processing (INTEOIVDMIRQ) 
  394.  
  395.  6.  Hardware Interrupt dispatching 
  396.      The interrupt manager transfers control to the VPIC for hardware 
  397.     interrupts that the VPIC has set, and no physical device driver has 
  398.     serviced (VPICIntHdlr) 
  399.  
  400.  
  401. ΓòÉΓòÉΓòÉ 6.26. General Overview of Different Types of Memory for DOS Applications ΓòÉΓòÉΓòÉ
  402.  
  403.  
  404. ΓòÉΓòÉΓòÉ 6.27. Expanded Memory Manager Control Flow ΓòÉΓòÉΓòÉ
  405.  
  406.  
  407. ΓòÉΓòÉΓòÉ 6.28. Memory Map of Areas Supported by Extended Memory ΓòÉΓòÉΓòÉ
  408.  
  409.  
  410. ΓòÉΓòÉΓòÉ 6.29. Extended Memory Manager Control Flow ΓòÉΓòÉΓòÉ
  411.  
  412.  
  413. ΓòÉΓòÉΓòÉ 6.30. CONFIG.SYS - Loading Device Drivers into UMBs ΓòÉΓòÉΓòÉ
  414.  
  415. DEVICE = C:\OS2\VXMS.SYS
  416. DEVICEHIGH = SIZE = 1A00 C:\OS2\MDOS\ANSI.SYS
  417. DOS = UMB
  418.  
  419.  
  420. ΓòÉΓòÉΓòÉ 6.31. LOADHIGH Command - Loading TSRs into UMBs ΓòÉΓòÉΓòÉ
  421.  
  422. LOADHIGH progname <program parameters>
  423.  
  424.  
  425. ΓòÉΓòÉΓòÉ 6.32. The Migrate Applications Windows ΓòÉΓòÉΓòÉ
  426.  
  427.  
  428. ΓòÉΓòÉΓòÉ <hidden> DBTAGS.DAT ΓòÉΓòÉΓòÉ
  429.  
  430. //                           +--------------------+
  431. //                           | NOTE TO TRANSLATOR |
  432. //                           +--------------------+
  433. // Do not translate keywords or data types and delete these lines when done.
  434. // ============================================================================
  435. // dbtags.dat -- DOS setting "tags" used by PARSEDB and MIGRATE.  Each "tag"
  436. // consists of an index, a keyword, and a data type.
  437. //             +------------------------------------------------+
  438. //             | DO NOT EDIT THIS FILE UNDER ANY CIRCUMSTANCES! |
  439. //             +------------------------------------------------+
  440. // ============================================================================
  441. // Allows BASIC-style comments.
  442. // ----------------------------------------------------------------------------
  443. 1   REM                        NOP
  444.  
  445. // ----------------------------------------------------------------------------
  446. // Required "fake" DOS settings.
  447. // ----------------------------------------------------------------------------
  448. 2   NAME                       STR    // Filename used to execute application
  449. 3   TITLE                      STR    // Icon (desktop) title
  450. 4   TYPE                       BYTE   // Application type
  451.                                       // Valid settings: DOS
  452.                                       //                 Windows
  453.                                       //                 OS/2
  454.                                       //                 custom (for Microsoft
  455.                                       //                 Windows apps which
  456.                                       //                 must run full-screen)
  457. 5   ASSOC_FILE                 STR    // Associated file (NULL if one isn't
  458.                                       // known)
  459. 6   DEF_DIR                    STR    // Default installation directory (NULL
  460.                                       // if there isn't one)
  461.  
  462. // ----------------------------------------------------------------------------
  463. // Other "fake" DOS settings.
  464. // ----------------------------------------------------------------------------
  465. 7   FOLDER                     STR    // Name of folder to create and/or put
  466.                                       // the application icon in
  467. 8   PARAMETERS                 STR    // Application's command line parameters
  468. 9   WORK_DIR                   STR    // Application's working directory
  469.  
  470. // ----------------------------------------------------------------------------
  471. // "Fake" Windows settings
  472. // ----------------------------------------------------------------------------
  473. 10  WIN_FILES                  STR    // Files to be copied to the WinOS2
  474.                                       // directory when the application is
  475.                                       // migrated
  476. 11  COMMON_SESSION             BOOL   // Default: ON  -> the application is to
  477.                                       //                 be run in the common
  478.                                       //                 session
  479.                                       //          OFF -> the application is to
  480.                                       //                 be run "standalone"
  481.  
  482. // ----------------------------------------------------------------------------
  483. // Real DOS settings.  NOTE: WIN_RUNMODE is not supported; all Windows apps are
  484. // installed with SEAMLESS and WPS handles the mapping.
  485. // ----------------------------------------------------------------------------
  486. //  WIN_RUNMODE                INT    // Valid settings: 10 (REAL)
  487.                                       //                 11 (STANDARD)
  488.                                       //                 12 (AUTO)
  489.                                       //                 13 (SEAMLESS)
  490. 13  COM_HOLD                   BOOL   // Default: off
  491. 14  DOS_BREAK                  BOOL   // Default: off
  492. 15  DOS_DEVICE                 MLSTR  // Default: empty
  493. 16  DOS_FCBS                   INT    // Limits: 0 to 255, default 16
  494. 17  DOS_FCBS_KEEP              INT    // Limits: 0 to 255, default 8
  495. 18  DOS_FILES                  INT    // Limits: 20 to 255, default 20
  496. 19  DOS_HIGH                   BOOL   // Default: off
  497. 20  DOS_LASTDRIVE              STR    // Limits: last physical drive to 'Z',
  498.                                       //         default 'Z'
  499. 21  DOS_RMSIZE                 INT    // Limits: 128 to 640, default 640
  500.                                       // NOTE: increments of 16
  501. 22  DOS_SHELL                  STR    // Default: "#:\OS2\MDOS\COMMAND.COM "
  502.                                       //          "#:\OS2\MDOS\ /P" where #
  503.                                       //          is the boot drive
  504. 23  DOS_STARTUP_DRIVE          STR    // Default: empty
  505. 24  DOS_UMB                    BOOL   // Default: off
  506. 25  DOS_VERSION                MLSTR  // Default: DCJSS02.EXE,3,40,255
  507.                                       //          DFIA0MOD.SYS,3,40,255
  508.                                       //          DXMA0MOD.SYS,3,40,255
  509.                                       //          IBMCACHE.COM,3,40,255
  510.                                       //          IBMCACHE.SYS,3,40,255
  511.                                       //          ISAM.EXE,3,40,255
  512.                                       //          ISAM2.EXE,3,40,255
  513.                                       //          ISQL.EXE,3,40,255
  514.                                       //          NET3.COM,3,40,255
  515.                                       //          EXCEL.EXE,10,10,4
  516.                                       //          PSCPG.COM,3,40,255
  517.                                       //          SAF.EXE,3,40,255
  518.                                       //          WIN200.BIN,10,10,4
  519. 26  DPMI_DOS_API               STR    // Valid settings: AUTO (default)
  520.                                       //                 ENABLED
  521.                                       //                 DISABLED
  522. 27  DPMI_MEMORY_LIMIT          INT    // Limits: 0 to 512, default 3
  523. 28  EMS_FRAME_LOCATION         STR    // Valid settings: AUTO (default)
  524.                                       //                 NONE
  525.                                       //                 C000
  526.                                       //                 C400
  527.                                       //                 C800
  528.                                       //                 CC00
  529.                                       //                 D000
  530.                                       //                 D400
  531.                                       //                 D800
  532.                                       //                 DC00
  533.                                       //                 8000
  534.                                       //                 8400
  535.                                       //                 8800
  536.                                       //                 8C00
  537.                                       //                 9000
  538. 29  EMS_HIGH_OS_MAP_REGION     INT    // Limits: 0 to 96, default 32
  539.                                       // NOTE: increments of 16
  540. 30  EMS_LOW_OS_MAP_REGION      INT    // Limits: 0 to 576, default 384
  541.                                       // NOTE: increments of 16
  542. 31  EMS_MEMORY_LIMIT           INT    // Limits: 0 to 32768, default 2048
  543.                                       // NOTE: increments of 16
  544. 32  HW_NOSOUND                 BOOL   // Default: off
  545. 33  HW_ROM_TO_RAM              BOOL   // Default: off
  546. 34  HW_TIMER                   BOOL   // Default: off
  547. 35  IDLE_SECONDS               INT    // Limits: 0 to 60, default 0
  548. 36  IDLE_SENSITIVITY           INT    // Limits: 1 to 100, default 75
  549. 37  KBD_ALTHOME_BYPASS         BOOL   // Default: off
  550. 38  KBD_BUFFER_EXTEND          BOOL   // Default: on
  551. 39  KBD_CTRL_BYPASS            STR    // Valid settings: NONE (default)
  552.                                       //                 ALT_ESC
  553.                                       //                 CTRL_ESC
  554. 40  KBD_RATE_LOCK              BOOL   // Default: off
  555. 41  MEM_EXCLUDE_REGIONS        STR    // Default: empty
  556. 42  MEM_INCLUDE_REGIONS        STR    // Default: empty
  557. 43  MOUSE_EXCLUSIVE_ACCESS     BOOL   // Default: off
  558. 44  PRINT_TIMEOUT              INT    // Limits: 1 to 3600, default 15
  559. 45  VIDEO_8514A_XGA_IOTRAP     BOOL   // Default: on
  560. 46  VIDEO_FASTPASTE            BOOL   // Default: off
  561. 47  VIDEO_MODE_RESTRICTION     ENUM   // Valid settings: NONE (default)
  562.                                       //                 CGA
  563.                                       //                 MONO
  564. 48  VIDEO_ONDEMAND_MEMORY      BOOL   // Default: on
  565. 49  VIDEO_RETRACE_EMULATION    BOOL   // Default: on
  566. 50  VIDEO_ROM_EMULATION        BOOL   // Default: on
  567. 51  VIDEO_SWITCH_NOTIFICATION  BOOL   // Default: off
  568. 52  VIDEO_WINDOW_REFRESH       INT    // Limits: 1 to 600, default 1
  569. 53  XMS_HANDLES                INT    // Limits: 0 to 128, default 32
  570. 54  XMS_MEMORY_LIMIT           INT    // Limits: 0 to 16384, default 2048
  571.                                       // NOTE: increments of 4
  572. 55  XMS_MINIMUM_HMA            INT    // Limits: 0 to 63, default 0
  573. 56  DOS_BACKGROUND_EXECUTION   BOOL   // Default: on
  574. 57  DPMI_NETWORK_BUFF_SIZE     INT    // Limits: 1 to 64, default 8
  575.  
  576.  
  577. ΓòÉΓòÉΓòÉ 6.33. User Definitions for other Applications ΓòÉΓòÉΓòÉ
  578.  
  579. REM ---------------------------------------------------------------------------
  580. REM Windows file browser
  581. REM ---------------------------------------------------------------------------
  582.     NAME                      WNBROWSE.EXE
  583.     TITLE                     File Browser
  584.     TYPE                      Windows
  585.     ASSOC_FILE                WNBROWSE.HLP
  586.     DEF_DIR                   \WNBROWSE
  587.     MOUSE_EXCLUSIVE_ACCESS    OFF
  588.     KBD_CTRL_BYPASS           CTRL_ESC
  589.     COMMON_SESSION            ON
  590.     VIDEO_SWITCH_NOTIFICATION ON
  591.     KBD_ALTHOME_BYPASS        ON
  592.     DPMI_MEMORY_LIMIT         5
  593.  
  594. REM ---------------------------------------------------------------------------
  595. REM WordPerfect 5.1 by WordPerfect
  596. REM ---------------------------------------------------------------------------
  597.     NAME                      WP.EXE
  598.     TITLE                     WordPerfect
  599.     TYPE                      DOS
  600.     ASSOC_FILE                WP.FIL
  601.     DEF_DIR                   \WP51
  602.     MOUSE_EXCLUSIVE_ACCESS    OFF
  603.     IDLE_SENSITIVITY          88
  604.  
  605. REM ---------------------------------------------------------------------------
  606. REM PMCAMERA OS/2 screen capture utility
  607. REM ---------------------------------------------------------------------------
  608.     NAME                      PMCAMERA.EXE
  609.     TITLE                     PM Screen Capture
  610.     TYPE                      OS/2
  611.     ASSOC_FILE                PMCAMERA.HLP
  612.     DEF_DIR                   \PMCAMERA
  613.  
  614.  
  615. ΓòÉΓòÉΓòÉ 6.34. Windows Applications Running under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  616.  
  617. We apologize for the picture quality.  The original was not available. 
  618.  
  619.  
  620. ΓòÉΓòÉΓòÉ 6.35. Single Windows Application Running under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  621.  
  622. We apologize for the picture quality.  The original was not available. 
  623.  
  624.  
  625. ΓòÉΓòÉΓòÉ 6.36. Single Windows Application(s) Running "Seamless" on the OS/2 Version 2.0 Desktop ΓòÉΓòÉΓòÉ
  626.  
  627. We apologize for the picture quality.  The original was not available. 
  628.  
  629.  
  630. ΓòÉΓòÉΓòÉ 6.37. Implementation of "Seamless" WIN-OS/2 VDM in OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  631.  
  632.  
  633. ΓòÉΓòÉΓòÉ 6.38. Installing Windows Support under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  634.  
  635.  
  636. ΓòÉΓòÉΓòÉ 6.39. Defining a Windows Application to OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  637.  
  638.  
  639. ΓòÉΓòÉΓòÉ 6.40. Migrating the Windows Initialization Files ΓòÉΓòÉΓòÉ
  640.  
  641.  
  642. ΓòÉΓòÉΓòÉ 6.41. Detailed View of the WIN-OS/2 Data Connections ΓòÉΓòÉΓòÉ
  643.  
  644. We apologize for the picture quality.  The original was not available. 
  645.  
  646.  
  647. ΓòÉΓòÉΓòÉ 6.42. Low Level View of the WIN-OS/2 Printing Data Flow ΓòÉΓòÉΓòÉ
  648.  
  649. We apologize for the picture quality.  The original was not available. 
  650.  
  651.  
  652. ΓòÉΓòÉΓòÉ 6.43. File Structure of Adobe Type Manager ΓòÉΓòÉΓòÉ
  653.  
  654. We apologize for the picture quality.  The original was not available. 
  655.  
  656.  
  657. ΓòÉΓòÉΓòÉ 6.44. OS/2 Version 2.0 Clipboard Environment ΓòÉΓòÉΓòÉ
  658.  
  659. Note that not all data formats shown in this diagram will be supported by the 
  660. global clipboard server.  This is discussed in detail in Clipboard Support. 
  661.  
  662.  
  663. ΓòÉΓòÉΓòÉ 6.45. DDE Process between Windows Environments ΓòÉΓòÉΓòÉ
  664.  
  665.  
  666. ΓòÉΓòÉΓòÉ 6.46. DDE Process between Presentation Manager and Windows ΓòÉΓòÉΓòÉ
  667.  
  668.  
  669. ΓòÉΓòÉΓòÉ 6.47. Client/Server Structure for Operating System Extenders ΓòÉΓòÉΓòÉ
  670.  
  671.  
  672. ΓòÉΓòÉΓòÉ 6.48. The Program Page of the Settings Notebook ΓòÉΓòÉΓòÉ
  673.  
  674.  
  675. ΓòÉΓòÉΓòÉ 6.49. The Session Page of the Settings Notebook ΓòÉΓòÉΓòÉ
  676.  
  677.  
  678. ΓòÉΓòÉΓòÉ 6.50. The DOS Settings Dialog of the Settings Notebook ΓòÉΓòÉΓòÉ
  679.  
  680.  
  681. ΓòÉΓòÉΓòÉ 6.51. Setting Up a TSR Program ΓòÉΓòÉΓòÉ
  682.  
  683.  
  684. ΓòÉΓòÉΓòÉ 6.52. The DOS Settings Dialog of the Settings Notebook ΓòÉΓòÉΓòÉ
  685.  
  686.  
  687. ΓòÉΓòÉΓòÉ 6.53. The Program Page of the Settings Notebook for a VMB ΓòÉΓòÉΓòÉ
  688.  
  689. All that is needed in the Path and file name field is an asterisk. 
  690.  
  691.  
  692. ΓòÉΓòÉΓòÉ 6.54. DOS Settings - DOS_STARTUP_DRIVE ΓòÉΓòÉΓòÉ
  693.  
  694. This illustration shows the specification of a DOS diskette image named 
  695. DR-DOS50.VMB, located on hard disk. 
  696.  
  697.  
  698. ΓòÉΓòÉΓòÉ 6.55. VMB from an OS/2 V2.0 Program ΓòÉΓòÉΓòÉ
  699.  
  700. /*
  701.  *  BOOTA:  A simple program to start a DOS Boot session under OS/2 2.0.
  702.  *          This program can be run from an OS/2 command prompt and it
  703.  *          then starts to Boot DOS from the A: drive.
  704.  *
  705.  *  Last Modfied: 04/02/92
  706.  *
  707.  *  Author: Stacey Barnes
  708.  *  Modified: Jeff Muir
  709.  */
  710.  
  711. #define INCL_DOSSESMGR
  712. #define INCL_DOSMISC
  713. #include <os2.h>
  714.  
  715. /* messages used by BOOTA */
  716. PSZ pBootAMsg = "BOOTA: Booting DOS from A: Drive.\r\n";
  717. PSZ pBootSuccess = "Session started.\r\n";
  718. PSZ pBootFailure = "Session could not be started.\r\n";
  719.  
  720. STARTDATA startd;                  /* Session start information */
  721. USHORT    SessionID, ProcessID;    /* Session and Process ID for new session*/
  722.  
  723. void main(void)
  724. {
  725.   USHORT       rc;
  726.  
  727.   /* Print header message */
  728.   DosPutMessage(1,strlen(pBootAMsg),pBootAMsg);
  729.  
  730.   /* Init fields to Boot from A: drive */
  731.   startd.Length                   = sizeof(STARTDATA);
  732.   startd.Related                  = SSF_RELATED_INDEPENDENT;
  733.   startd.FgBg                     = SSF_FGBG_FORE;
  734.   startd.TraceOpt                 = SSF_TRACEOPT_NONE;
  735.   startd.PgmTitle                 = "Boot A: Drive";
  736.   startd.PgmName                  = NULL;
  737.   startd.PgmInputs                = NULL;
  738.   startd.TermQ                    = NULL;
  739.   startd.Environment              = "DOS_STARTUP_DRIVE=A:\0";
  740.   startd.InheritOpt               = SSF_INHERTOPT_PARENT;
  741.   startd.SessionType              = SSF_TYPE_VDM;
  742.  
  743.   /* Start the DOS Boot Session */
  744.   rc = DosStartSession( &startd, &SessionID, &ProcessID );
  745.  
  746.   /* Print out either Success or Failure message */
  747.   if(rc)
  748.     DosPutMessage(1,strlen(pBootFailure),pBootFailure);
  749.   else
  750.     DosPutMessage(1,strlen(pBootSuccess),pBootSuccess);
  751.  
  752. return;
  753. }
  754. This sample shows how to start a VMB from a DOS diskette by using an OS/2 V2.0 
  755. program. 
  756.  
  757.  
  758. ΓòÉΓòÉΓòÉ 6.56. Personal Communications/3270 for Windows running under OS/2 V2.0 ΓòÉΓòÉΓòÉ
  759.  
  760. We apologize for the picture quality.  The original was not available. In this 
  761. picture it is using the Token-Ring LAN gateway and running as a "seamless" 
  762. WIN-OS/2 application on the Workplace Shell desktop. 
  763.  
  764.  
  765. ΓòÉΓòÉΓòÉ 6.57. Memory Map of Extended Memory (HMA, UMA, and EMBs) ΓòÉΓòÉΓòÉ
  766.  
  767.  
  768. ΓòÉΓòÉΓòÉ 6.58. QENV.BAT Batch File ΓòÉΓòÉΓòÉ
  769.  
  770. @rem QENV.BAT
  771. @rem Purpose :     Query DOS environment size
  772. @rem Author  :     Bernd Westphal
  773. @rem W10390 VDM Lab - VDM Configuration
  774. @echo off
  775. cls
  776. echo Filling free environment space ....
  777. echo.
  778. echo Ignore any messages like "Out of environment space".
  779. echo.
  780. set Dummy1=Dummy.Text.to.fill.the.environment.space
  781. set Dummy2=%Dummy1%
  782. set Dummy3=%Dummy1%
  783. set Dummy4=%Dummy1%
  784. set Dummy5=%Dummy1%
  785. cls
  786. environ.exe
  787. set Dummy1=
  788. set Dummy2=
  789. set Dummy3=
  790. set Dummy4=
  791. set Dummy5=
  792. cls
  793. echo The dummy environment settings have been removed.
  794.  
  795.  
  796. ΓòÉΓòÉΓòÉ 6.59. C Source Code for ENVIRON.EXE ΓòÉΓòÉΓòÉ
  797.  
  798. /*******************************************************\
  799.  *  Program name: ENVIRON.C                            *
  800.  *  Created     : 5. May 1990                          *
  801.  *  Revised     :                                      *
  802.  *  Author      : Bernd Westphal                       *
  803.  *  Purpose     : Get DOS environment size for VDM lab *
  804.  *  Compile     : cl environ.c                         *
  805.  *  Input param : none                                 *
  806. \*******************************************************/
  807.  
  808. #include <stdio.h>
  809. #include <string.h>
  810. #include <ctype.h>
  811.  
  812. void main(argc, argv, envp)
  813.    int   argc;
  814.    char *argv[];
  815.    char *envp[];
  816. {
  817.    int   charcount = 0;                    /* # of char  */
  818.  
  819.    printf("Current environment settings:\n\n");
  820.    printf("-----------------------------\n");
  821.    while (*envp)
  822.    {
  823.       printf("%s\n", *envp);
  824.       charcount += strlen (*envp) + 1;     /* add 1 for the string terminator */
  825.       *envp++;
  826.    }
  827.    printf("-----------------------------\n");
  828.    printf("\nTotal environment size is %d bytes.\n\n", charcount);
  829.    printf("Press Enter to continue ...\n");
  830.    getchar();
  831. }
  832.  
  833.  
  834. ΓòÉΓòÉΓòÉ 6.60. INT19.BAS Source Code ΓòÉΓòÉΓòÉ
  835.  
  836. '*********************************************************
  837. '*  Program name: INT19.BAS                              *
  838. '*  Created     : 05/05/90                               *
  839. '*  Revised     :                                        *
  840. '*  Author      : Bernd Westphal                         *
  841. '*  Purpose     : Execute INT 19h in an OS/2             *
  842. '*                VDM environment. Only the current      *
  843. '*                should be terminated.                  *
  844. '*  Compiler    : IBM BASIC Compiler/2 V1.00             *
  845. '*  Compile     : BASCOM INT19 /O                        *
  846. '*  Link        : LINK INT19;                            *
  847. '*  Input param : none                                   *
  848. '*********************************************************
  849.  
  850. ' Variable definition for Interrupt call
  851. TYPE RegType
  852.    ax    AS INTEGER
  853.    bx    AS INTEGER
  854.    cx    AS INTEGER
  855.    dx    AS INTEGER
  856.    bp    AS INTEGER
  857.    si    AS INTEGER
  858.    di    AS INTEGER
  859.    flags AS INTEGER
  860. END TYPE
  861.  
  862. DECLARE SUB Interrupt (intnum AS INTEGER, inreg AS RegType, outreg AS RegType)
  863.  
  864. DIM InRegs AS RegType
  865. DIM OutRegs AS RegType
  866.  
  867.    ' *** Program code ***
  868.    CLS
  869.    COLOR 15
  870.    PRINT "OS/2 Virtual DOS Machine + INT 19h"
  871.    PRINT STRING$(80, 196);
  872.    PRINT
  873.    PRINT "Execution of INT 19h under DOS on a 8086 processor"
  874.    PRINT "will reboot the system."
  875.    PRINT
  876.    PRINT "To prevent a system reboot running under OS/2 Version 2.0,"
  877.    PRINT "the Virtual DOS Machine Manager terminates the current"
  878.    PRINT "VDM if an INT 19h occurs."
  879.    PRINT
  880.    PRINT "Press Enter to execute the INT 19h interrupt"
  881.    PRINT "or press Esc to terminate."
  882.    PRINT
  883.    PRINT "Your choice: ";
  884. GetChr: kb$ = INPUT$(1)
  885.    SELECT CASE kb$
  886.       CASE CHR$(27)
  887.            CLS
  888.            END
  889.  
  890.       CASE CHR$(13)
  891.            PRINT "OK, restarting ..."
  892.            CALL Int86(&H19, InRegs, OutRegs)
  893.  
  894.       CASE ELSE
  895.            GOTO GetChr
  896.    END SELECT
  897. This program runs in compiled BASIC only, because the Int86 function call is 
  898. not available in interpreted BASIC. 
  899.  
  900.  
  901. ΓòÉΓòÉΓòÉ 6.61. GRAPHIC.BAS Source Code ΓòÉΓòÉΓòÉ
  902.  
  903. '*********************************************************
  904. '*  Program name: GRAPHIC.BAS                            *
  905. '*  Created     : 05/14/90                               *
  906. '*  Revised     :                                        *
  907. '*  Author      : Bernd Westphal                         *
  908. '*  Purpose     : Draw some graphics                     *
  909. '*                for VDM clipboard lab session          *
  910. '*  Compiler    : IBM BASIC Compiler/2 V1.00             *
  911. '*  Compile     : BASCOM GRAPHIC /O                      *
  912. '*  Link        : LINK GRAPHIC;                          *
  913. '*  Input param : none                                   *
  914. '*********************************************************
  915.  
  916.    SCREEN 2                           ' select 640 x 200 graphics mode
  917.    CLS                                ' clear the screen
  918.    FOR X=1 TO 640 STEP 10
  919.       LINE (320,199)-(X,0)            ' draw some lines
  920.    NEXT
  921.    FOR X=1 TO 640 STEP 10
  922.       LINE (320,0)-(X,199)            ' draw some lines
  923.    NEXT
  924.    LOCATE 12,31                       ' position the cursor
  925.    PRINT SPACE$(21)                   ' print 21 blanks
  926.    LOCATE 13,31                       ' position the cursor
  927.    PRINT " IBM ITSC Boca Raton "      ' print some text
  928.    LOCATE 14,31                       ' position the cursor
  929.    PRINT SPACE$(21)                   ' print 21 blanks
  930.    KB$ = INPUT$(1)                    ' check for keystroke
  931.    SYSTEM                             ' return to DOS
  932.  
  933.  
  934. ΓòÉΓòÉΓòÉ 6.62. SOUND.BAS Source Code ΓòÉΓòÉΓòÉ
  935.  
  936. '*********************************************************
  937. '*  Program name: SOUND.BAS                              *
  938. '*  Created     : 05/14/90                               *
  939. '*  Revised     :                                        *
  940. '*  Author      : Bernd Westphal                         *
  941. '*  Purpose     : Access the speaker system in a         *
  942. '*                VDM environment                        *
  943. '*                Only 1 VDM has access to the speaker   *
  944. '*  Compiler    : IBM BASIC Compiler/2                   *
  945. '*  Compile     : BASCOM SOUND /O;                       *
  946. '*  Link        : Link SOUND;                            *
  947. '*  Input param : none                                   *
  948. '*********************************************************
  949.  
  950.     CLS                           ' clear the screen
  951.     PLAY ON                       ' trap background music events
  952.     ON PLAY(3) GOSUB PlayMusic    ' If there are less than 3 notes
  953.                                   ' in the buffer gosub line 1000
  954.     PRINT "Press ENTER to end."   ' display info, how to end program
  955.     '
  956.     PLAY "MB"                     ' background option for PLAY
  957.     GOSUB PlayMusic               ' start the music
  958.     '
  959.     kb$ = ""                      ' keyboard input buffer
  960.     WHILE kb$ = ""                ' start of loop
  961.        LOCATE 3, 1                ' position the cursor
  962.        COLOR c                    ' change color and print some text,
  963.                                   ' to show, that music executes
  964.                                   ' independent
  965.        PRINT "Playing your favorite music ..."
  966.        c = c + 1                  ' next color
  967.        IF c > 15 then c = 1       ' no blinking mode
  968.        kb$ = INKEY$               ' get a character if present
  969.     WEND                          ' end of loop
  970.     COLOR 7                       ' white on black
  971.     SYSTEM                        ' return to DOS
  972.  
  973. PlayMusic:
  974.    PLAY "t180 o2 p2 p8 L8 GGG L2 E- p24 p8 L8 FFF L2 D"
  975.    RETURN
  976.  
  977.  
  978. ΓòÉΓòÉΓòÉ 7. Tables ΓòÉΓòÉΓòÉ
  979.  
  980.  PIC Initialization Control Words 
  981.  PIC Operation Control Words 
  982.  List of Supported Video Configurations 
  983.  Graphical Applications Programs Support under OS/2 Version 2.0 
  984.  Driver Letter Assignment 
  985.  Free Base Memory 
  986.  Location of AUTOEXEC.BAT and CONFIG.SYS 
  987.  Type of Expanded Memory 
  988.  
  989.  
  990. ΓòÉΓòÉΓòÉ 7.1. PIC Initialization Control Words ΓòÉΓòÉΓòÉ
  991.  
  992.  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  993.  Γöé PIC Initialization Control Words                                      Γöé
  994.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  995.  Γöé ICW      Γöé FIELD    Γöé EXPLANATION                         Γöé SUPPORTED Γöé
  996.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  997.  Γöé ICW1     Γöé D0       Γöé 1 = ICW4 needed                     Γöé Supported Γöé
  998.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  999.  Γöé          Γöé          Γöé 0 = no ICW4 needed                  Γöé Supported Γöé
  1000.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1001.  Γöé          Γöé D1       Γöé 1 = single PIC                      Γöé Ignored   Γöé
  1002.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1003.  Γöé          Γöé          Γöé 0 = cascade mode (slaves)           Γöé Supported Γöé
  1004.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1005.  Γöé          Γöé D2       Γöé 1 = call address interval of 4      Γöé Ignored   Γöé
  1006.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1007.  Γöé          Γöé          Γöé 0 = call address interval of 8      Γöé Ignored   Γöé
  1008.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1009.  Γöé          Γöé D3       Γöé 1 = level triggered mode            Γöé Ignored   Γöé
  1010.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1011.  Γöé          Γöé          Γöé 0 = edge triggered mode             Γöé Supported Γöé
  1012.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1013.  Γöé          Γöé D4       Γöé 1                                   Γöé           Γöé
  1014.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1015.  Γöé          Γöé D5-D7    Γöé A7-A5 of int vector in 8080 mode    Γöé Ignored   Γöé
  1016.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1017.  Γöé ICW2     Γöé D0-D2    Γöé                                     Γöé Ignored   Γöé
  1018.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1019.  Γöé          Γöé D3-D7    Γöé base int vector number in 8086 mode Γöé Supported Γöé
  1020.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1021.  Γöé ICW3     Γöé          Γöé Ignore if slave is not IRQ2         Γöé           Γöé
  1022.  Γöé (Master) Γöé          Γöé                                     Γöé           Γöé
  1023.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1024.  Γöé          Γöé D0-D7    Γöé 1 = IRQ has a slave connected       Γöé           Γöé
  1025.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1026.  Γöé          Γöé          Γöé 0 = IRQ does not have a slave con-  Γöé           Γöé
  1027.  Γöé          Γöé          Γöé nected                              Γöé           Γöé
  1028.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1029.  Γöé ICW3     Γöé          Γöé Ignore if slave is not IRQ2         Γöé           Γöé
  1030.  Γöé (Slave)  Γöé          Γöé                                     Γöé           Γöé
  1031.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1032.  Γöé          Γöé D0-D2    Γöé slave ID                            Γöé           Γöé
  1033.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1034.  Γöé          Γöé D3-D7    Γöé 0                                   Γöé           Γöé
  1035.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1036.  Γöé ICW4     Γöé D0       Γöé 1 = 8086/8088 mode                  Γöé Supported Γöé
  1037.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1038.  Γöé          Γöé          Γöé 0 = 8080/8085 mode                  Γöé Ignored   Γöé
  1039.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1040.  Γöé D1       Γöé 1 = auto Γöé Ignored                             Γöé           Γöé
  1041.  Γöé          Γöé EOI      Γöé                                     Γöé           Γöé
  1042.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1043.  Γöé          Γöé          Γöé 0 = normal EOI                      Γöé Supported Γöé
  1044.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1045.  Γöé          Γöé D2-D3    Γöé 0x = non-buffered mode              Γöé Supported Γöé
  1046.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1047.  Γöé          Γöé          Γöé 10 = buffered mode/slave            Γöé Ignored   Γöé
  1048.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1049.  Γöé          Γöé          Γöé 11 = buffered mode/master           Γöé Ignored   Γöé
  1050.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1051.  Γöé          Γöé D4       Γöé 1 = special fully nested mode       Γöé Ignored   Γöé
  1052.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1053.  Γöé          Γöé          Γöé 0 = not special fully nested mode   Γöé Supported Γöé
  1054.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1055.  Γöé          Γöé D5-D7    Γöé 0                                   Γöé           Γöé
  1056.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1057.  
  1058.  
  1059. ΓòÉΓòÉΓòÉ 7.2. PIC Operation Control Words ΓòÉΓòÉΓòÉ
  1060.  
  1061.  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1062.  Γöé PIC Operation Control Words                                        Γöé
  1063.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1064.  Γöé OCW   Γöé FIELD  Γöé EXPLANATION                           Γöé SUPPORTED Γöé
  1065.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1066.  Γöé OCW1  Γöé D0-D7  Γöé IMR (interrupt mask register)         Γöé Supported Γöé
  1067.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1068.  Γöé       Γöé        Γöé    1 = IRQ masked (disabled)          Γöé           Γöé
  1069.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1070.  Γöé       Γöé        Γöé    0 = IRQ unmasked (enabled)         Γöé           Γöé
  1071.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1072.  Γöé OCW2  Γöé D0-D2  Γöé IRQ level to be acted upon            Γöé           Γöé
  1073.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1074.  Γöé       Γöé D3-D4  Γöé 0                                     Γöé           Γöé
  1075.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1076.  Γöé       Γöé D5-D7  Γöé EOI command                           Γöé           Γöé
  1077.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1078.  Γöé       Γöé        Γöé 000 = rotate in auto EOI mode (clear) Γöé Ignored   Γöé
  1079.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1080.  Γöé       Γöé        Γöé 001 = non-specific EOI                Γöé Supported Γöé
  1081.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1082.  Γöé       Γöé        Γöé 010 = no operand                      Γöé Supported Γöé
  1083.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1084.  Γöé       Γöé        Γöé 011 = specific EOI                    Γöé Supported Γöé
  1085.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1086.  Γöé       Γöé        Γöé 100 = rotate in auto EOI mode (set)   Γöé Ignored   Γöé
  1087.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1088.  Γöé       Γöé        Γöé 101 = rotate on non-specific EOI      Γöé Ignored   Γöé
  1089.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1090.  Γöé       Γöé        Γöé 110 = set priority command            Γöé Ignored   Γöé
  1091.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1092.  Γöé       Γöé        Γöé 111 = rotate on specific EOI          Γöé Ignored   Γöé
  1093.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1094.  Γöé OCW3  Γöé D0-D1  Γöé read register command                 Γöé           Γöé
  1095.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1096.  Γöé       Γöé        Γöé 00 = no action                        Γöé Supported Γöé
  1097.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1098.  Γöé       Γöé        Γöé 01 = no action                        Γöé Supported Γöé
  1099.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1100.  Γöé       Γöé        Γöé 10 = read IR register                 Γöé Supported Γöé
  1101.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1102.  Γöé       Γöé        Γöé 11 = read IS register                 Γöé Supported Γöé
  1103.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1104.  Γöé       Γöé D2     Γöé 1 = poll command                      Γöé Ignored   Γöé
  1105.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1106.  Γöé       Γöé        Γöé 0 = no poll command                   Γöé Supported Γöé
  1107.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1108.  Γöé       Γöé D3     Γöé 1                                     Γöé           Γöé
  1109.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1110.  Γöé       Γöé D4     Γöé 0                                     Γöé           Γöé
  1111.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1112.  Γöé       Γöé D5-D6  Γöé Special mask mode                     Γöé           Γöé
  1113.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1114.  Γöé       Γöé        Γöé 00 = no action                        Γöé Supported Γöé
  1115.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1116.  Γöé       Γöé        Γöé 01 = no action                        Γöé Supported Γöé
  1117.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1118.  Γöé       Γöé        Γöé 10 = reset special mask               Γöé Ignored   Γöé
  1119.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1120.  Γöé       Γöé        Γöé 11 = set special mask                 Γöé Ignored   Γöé
  1121.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1122.  Γöé       Γöé D7     Γöé 0                                     Γöé           Γöé
  1123.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1124.  
  1125.  
  1126. ΓòÉΓòÉΓòÉ 7.3. List of Supported Video Configurations ΓòÉΓòÉΓòÉ
  1127.  
  1128. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1129. Γöé List of Supported Video Configurations                                 Γöé
  1130. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1131. Γöé EXAMPLE Γöé SIZE Γöé COLOR Γöé ADAPTER Γöé RESOLUTION Γöé MEMORY Γöé COLORS/GRAYS  Γöé
  1132. Γöé DIS-    Γöé (IN.)Γöé       Γöé         Γöé            Γöé        Γöé               Γöé
  1133. Γöé PLAYS   Γöé      Γöé       Γöé         Γöé            Γöé        Γöé               Γöé
  1134. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1135. Γöé Mono    Γöé -    Γöé Mono  Γöé Mono    Γöé Supported  Γöé -      Γöé -             Γöé
  1136. Γöé         Γöé      Γöé       Γöé         Γöé as sec-    Γöé        Γöé               Γöé
  1137. Γöé         Γöé      Γöé       Γöé         Γöé ondary     Γöé        Γöé               Γöé
  1138. Γöé         Γöé      Γöé       Γöé         Γöé display    Γöé        Γöé               Γöé
  1139. Γöé         Γöé      Γöé       Γöé         Γöé only       Γöé        Γöé               Γöé
  1140. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1141. Γöé CGA     Γöé -    Γöé B&W   Γöé CGA     Γöé 640x200    Γöé -      Γöé -             Γöé
  1142. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1143. Γöé ECD     Γöé -    Γöé B&W   Γöé EGA     Γöé 640x350    Γöé 64K    Γöé no 4-color    Γöé
  1144. Γöé Monitor Γöé      Γöé       Γöé         Γöé            Γöé        Γöé support, uses Γöé
  1145. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé EGA/Mono      Γöé
  1146. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé driver        Γöé
  1147. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1148. Γöé ECD     Γöé -    Γöé Color Γöé EGA     Γöé 640x350    Γöé 128KB  Γöé 16 colors     Γöé
  1149. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1150. Γöé -       Γöé -    Γöé -     Γöé -       Γöé 640x350    Γöé 192KB  Γöé 16 colors     Γöé
  1151. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1152. Γöé -       Γöé -    Γöé -     Γöé -       Γöé 640x350    Γöé 256KB  Γöé 16 colors     Γöé
  1153. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1154. Γöé Mono    Γöé -    Γöé B&W   Γöé EGA     Γöé 640x350    Γöé any    Γöé no reverse    Γöé
  1155. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé memory Γöé video, blink  Γöé
  1156. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé size   Γöé or intense    Γöé
  1157. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé support       Γöé
  1158. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1159. Γöé RGB     Γöé -    Γöé EGA   Γöé Color   Γöé 640x200    Γöé any    Γöé 16 Colors     Γöé
  1160. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé memory Γöé               Γöé
  1161. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé size   Γöé               Γöé
  1162. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1163. Γöé EGA     Γöé -    Γöé -     Γöé EGA     Γöé -          Γöé -      Γöé Not supported Γöé
  1164. Γöé         Γöé      Γöé       Γöé w/2xx   Γöé            Γöé        Γöé               Γöé
  1165. Γöé         Γöé      Γöé       Γöé port    Γöé            Γöé        Γöé               Γöé
  1166. Γöé         Γöé      Γöé       Γöé config. Γöé            Γöé        Γöé               Γöé
  1167. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1168. Γöé 8503    Γöé 12   Γöé Mono  Γöé VGA     Γöé 640x480    Γöé -      Γöé 16 Grays      Γöé
  1169. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1170. Γöé 8512    Γöé 14   Γöé Color Γöé VGA     Γöé 640x480    Γöé -      Γöé 16 Colors     Γöé
  1171. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1172. Γöé 8513    Γöé 12   Γöé Color Γöé VGA     Γöé 640x480    Γöé -      Γöé 16 Colors     Γöé
  1173. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1174. Γöé 8514    Γöé 16   Γöé Color Γöé VGA     Γöé 640x480    Γöé -      Γöé 16 Colors     Γöé
  1175. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1176. Γöé 8503    Γöé 12   Γöé Mono  Γöé 8514/A  Γöé 640x480    Γöé -      Γöé 16 and 64     Γöé
  1177. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé Grays         Γöé
  1178. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1179. Γöé 8512    Γöé 14   Γöé Color Γöé 8514/A  Γöé 640x480    Γöé -      Γöé 16 and 256    Γöé
  1180. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé Colors        Γöé
  1181. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1182. Γöé 8513    Γöé 12   Γöé Color Γöé 8514/A  Γöé 640x480    Γöé -      Γöé 16 and 256    Γöé
  1183. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé Colors        Γöé
  1184. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1185. Γöé 8514    Γöé 16   Γöé Color Γöé 8514/A  Γöé 1024x768   Γöé -      Γöé 16 and 256    Γöé
  1186. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé Colors        Γöé
  1187. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1188. Γöé 8503    Γöé 12   Γöé Mono  Γöé XGA     Γöé 640x480    Γöé 512KB  Γöé 64 Grays      Γöé
  1189. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1190. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé 1MB    Γöé 64 Grays      Γöé
  1191. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1192. Γöé 8513    Γöé 12   Γöé Color Γöé XGA     Γöé 640x480    Γöé 512KB  Γöé 256 Colors    Γöé
  1193. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1194. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé 1MB    Γöé 256 Colors    Γöé
  1195. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1196. Γöé 8512    Γöé 14   Γöé Color Γöé XGA     Γöé 640x480    Γöé 1MB    Γöé 65536 Colors  Γöé
  1197. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1198. Γöé 8515    Γöé 14   Γöé Color Γöé XGA     Γöé 640x480    Γöé 512KB  Γöé 256 Colors    Γöé
  1199. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1200. Γöé         Γöé      Γöé       Γöé         Γöé 1024x768   Γöé 512KB  Γöé 16 Colors     Γöé
  1201. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1202. Γöé         Γöé      Γöé       Γöé         Γöé 640x480    Γöé 1MB    Γöé 256/65536     Γöé
  1203. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé Colors        Γöé
  1204. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1205. Γöé         Γöé      Γöé       Γöé         Γöé 1024x768   Γöé 1MB    Γöé 16/256 Colors Γöé
  1206. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1207. Γöé 8604    Γöé 15   Γöé Mono  Γöé XGA     Γöé 640x480    Γöé 512KB  Γöé 64 Grays      Γöé
  1208. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1209. Γöé         Γöé      Γöé       Γöé         Γöé 640x480    Γöé 1MB    Γöé 64 Grays      Γöé
  1210. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1211. Γöé 8507    Γöé 19   Γöé Mono  Γöé XGA     Γöé 1024x768   Γöé 512KB  Γöé 16 Grays      Γöé
  1212. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1213. Γöé         Γöé      Γöé       Γöé         Γöé 1024x768   Γöé 1MB    Γöé 16/64 Grays   Γöé
  1214. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1215. Γöé 8514    Γöé 16   Γöé Color Γöé XGA     Γöé 640x480    Γöé 512KB  Γöé 256 Colors    Γöé
  1216. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1217. Γöé         Γöé      Γöé       Γöé         Γöé 1024x768   Γöé 512KB  Γöé 16 Colors     Γöé
  1218. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1219. Γöé         Γöé      Γöé       Γöé         Γöé 640x480    Γöé 1MB    Γöé 256/65536     Γöé
  1220. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé Colors        Γöé
  1221. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1222. Γöé         Γöé      Γöé       Γöé         Γöé 1024x768   Γöé 1MB    Γöé 16/256 Colors Γöé
  1223. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1224. Γöé 8514    Γöé -    Γöé Color Γöé XGA     Γöé 1024x768   Γöé 512KB  Γöé 16 Colors     Γöé
  1225. Γöé Compat- Γöé      Γöé       Γöé         Γöé            Γöé        Γöé               Γöé
  1226. Γöé ible    Γöé      Γöé       Γöé         Γöé            Γöé        Γöé               Γöé
  1227. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1228. Γöé         Γöé      Γöé       Γöé         Γöé 640x480    Γöé 1MB    Γöé 65536 Colors  Γöé
  1229. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1230. Γöé         Γöé      Γöé       Γöé         Γöé 1024x768   Γöé 1MB    Γöé 16/256 Colors Γöé
  1231. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1232.  
  1233.  
  1234. ΓòÉΓòÉΓòÉ 7.4. Graphical Applications Programs Support under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  1235.  
  1236. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1237. Γöé Graphical Applications Programs Support under OS/2 Version 2.0          Γöé
  1238. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1239. Γöé       Γöé        Γöé    Γöé    Γöé         WINDOWS APPS       Γöé                 Γöé
  1240. Γöé       Γöé        Γöé    Γöé    Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ                 Γöé
  1241. Γöé       Γöé        Γöé    Γöé    Γöé  FULL SCREEN (FS)Γöé         Γöé     DOS APPS    Γöé
  1242. Γöé       Γöé        Γöé    Γöé    Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ         Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1243. Γöé       Γöé        Γöé    Γöé    Γöé MATCHES Γöé USING  Γöé         Γöé MATCHES Γöé USING Γöé
  1244. Γöé       Γöé        Γöé    Γöé    Γöé DESKTOP Γöé  VGA   Γöé         Γöé DESKTOP Γöé VGA   Γöé
  1245. Γöé       ΓöéSYSTEM  Γöé    ΓöéVIO Γöé  MODE   Γöé  MODE  ΓöéWIN-OS/2 Γöé  MODE   Γöé MODE  Γöé
  1246. ΓöéTYPE OFΓöéDESKTOP ΓöéPM  ΓöéOS/2Γö£ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöñ WINDOW  Γö£ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöñ
  1247. ΓöéVIDEO  ΓöéMODE    ΓöéAPPSΓöéAPPSΓöé A  Γöé B  Γöé A Γöé B  Γöé (Win)   Γöé FS ΓöéWIN ΓöéFS ΓöéWINΓöé
  1248. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1249. Γöé XGA   Γöé XGA    Γöé R  Γöé F  Γöé R  Γöé F  Γöé R Γöé F  Γöé N/A     Γöé F  Γöé X  Γöé F ΓöéX  Γöé
  1250. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1251. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1252. Γöé XGA   Γöé VGA    Γöé R  Γöé F  Γöé R  Γöé PF Γöé R Γöé PF Γöé R       Γöé PF Γöé PF'Γöé PFΓöéPF'Γöé
  1253. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1254. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1255. Γöé VGA   Γöé VGA    Γöé R  Γöé F  Γöé R  Γöé PF Γöé R Γöé PF Γöé R       Γöé PF Γöé PF'Γöé PFΓöéPF'Γöé
  1256. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1257. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1258. Γöé 8514  Γöé VGA    Γöé R  Γöé F  Γöé R  Γöé PF Γöé R Γöé PF Γöé R       Γöé PF Γöé PF'Γöé PFΓöéPF'Γöé
  1259. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1260. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1261. Γöé 8514  Γöé 8514   Γöé R  Γöé F  Γöé R  Γöé F  Γöé R Γöé R  Γöé N/A     Γöé F  Γöé X  Γöé R ΓöéR  Γöé
  1262. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1263. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1264. Γöé EGA   Γöé EGA    Γöé R  Γöé F  Γöé R  Γöé PF ΓöéN/AΓöé N/AΓöé N/A     Γöé PF Γöé PF'ΓöéN/AΓöéN/AΓöé
  1265. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1266. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1267. Γöé CGA   Γöé CGA    Γöé R  Γöé F  Γöé R  Γöé R  ΓöéN/AΓöé N/AΓöé N/A     Γöé R  Γöé R  ΓöéN/AΓöéN/AΓöé
  1268. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1269. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöñ
  1270. Γöé  LEGEND:                                                                Γöé
  1271. Γöé           R      Runs                                                   Γöé
  1272. Γöé           PF     Runs when PM has control of the screen, or when the    Γöé
  1273. Γöé                  application is in a foreground session                 Γöé
  1274. Γöé           PF'    Runs only when PM has control of the screen            Γöé
  1275. Γöé           F      Runs only when the application is in a foreground      Γöé
  1276. Γöé                  session                                                Γöé
  1277. Γöé           X      Not supported                                          Γöé
  1278. Γöé           N/A    Not applicable                                         Γöé
  1279. Γöé                                                                         Γöé
  1280. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1281.  
  1282. Note:   Column A indicates the use of a Windows display driver that suppresses 
  1283. background output.  Column B indicates the use of a Windows display driver that 
  1284. does not suppress background output. 
  1285.  
  1286.  
  1287. ΓòÉΓòÉΓòÉ 7.5. Driver Letter Assignment ΓòÉΓòÉΓòÉ
  1288.  
  1289.  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1290.  Γöé Drive Letter Assignment.  This table shows the way drive     Γöé
  1291.  Γöé letter assignments may differ on a mixed FAT and HPFS hard   Γöé
  1292.  Γöé disk when booted under DOS and OS/2 Version 2.0              Γöé                         Γöé
  1293.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1294.  Γöé PARTITION/TYPE           Γöé DRIVE LETTER    Γöé DRIVE LETTER    Γöé
  1295.  Γöé                          Γöé UNDER OS/2      Γöé UNDER DOS       Γöé
  1296.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1297.  Γöé Primary Partition 1,     Γöé none            Γöé none            Γöé
  1298.  Γöé Boot Manager             Γöé                 Γöé                 Γöé
  1299.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1300.  Γöé Primary Partition 2, FAT Γöé C:              Γöé C:              Γöé
  1301.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1302.  Γöé Extended Partition, HPFS Γöé D:              Γöé none            Γöé
  1303.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1304.  Γöé Extended Partition, FAT  Γöé E:              Γöé D:              Γöé
  1305.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1306.  
  1307.  
  1308. ΓòÉΓòÉΓòÉ 7.6. Free Base Memory ΓòÉΓòÉΓòÉ
  1309.  
  1310.  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1311.  Γöé Free Base Memory                                             Γöé
  1312.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1313.  Γöé SETTING     Γöé VDM DOS    Γöé DOS 5.0       Γöé DOS 4.0 Γöé DOS 3.3 Γöé
  1314.  Γöé             Γöé EMULATION  Γöé               Γöé         Γöé         Γöé
  1315.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1316.  Γöé DOS low     Γöé 610 KB     Γöé 566 KB        Γöé 588 KB  Γöé 545 KB  Γöé
  1317.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1318.  Γöé DOS high    Γöé 633 KB     Γöé 612 KB        Γöé -       Γöé -       Γöé
  1319.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1320.  Γöé With mode   Γöé 728 KB     Γöé 707 KB        Γöé 653 KB  Γöé 670 KB  Γöé
  1321.  Γöé restriction Γöé            Γöé               Γöé         Γöé         Γöé
  1322.  Γöé (CGA)       Γöé            Γöé               Γöé         Γöé         Γöé
  1323.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1324.  Γöé native DOS  Γöé -          Γöé 564 KB (low)  Γöé 545 KB  Γöé 562 KB  Γöé
  1325.  Γöé             Γöé            Γöé               Γöé         Γöé         Γöé
  1326.  Γöé             Γöé            Γöé 614 KB (high) Γöé         Γöé         Γöé
  1327.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1328.  
  1329. Note:    Each configuration has HIMEM, EMS and Mouse drivers loaded.  Values are
  1330. approximate.
  1331.  
  1332.  
  1333. ΓòÉΓòÉΓòÉ 7.7. Location of AUTOEXEC.BAT and CONFIG.SYS ΓòÉΓòÉΓòÉ
  1334.  
  1335. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1336. Γöé Location of AUTOEXEC.BAT and CONFIG.SYS                                 Γöé
  1337. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1338. Γöé VDM TYPE                           Γöé LOCATION                           Γöé
  1339. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1340. Γöé Virtual Machine Boot from diskette Γöé drive A:                           Γöé
  1341. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1342. Γöé Virtual Machine Boot from diskette Γöé imbedded in diskette image file on Γöé
  1343. Γöé image                              Γöé the hard disk                      Γöé
  1344. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1345. Γöé Virtual Machine Boot from DOS boot Γöé DOS boot partition                 Γöé
  1346. Γöé partition                          Γöé                                    Γöé
  1347. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1348. Γöé OS/2 V2.0 DOS emulator             Γöé root directory of OS/2 boot drive  Γöé
  1349. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1350.  
  1351.  
  1352. ΓòÉΓòÉΓòÉ 7.8. Type of Expanded Memory ΓòÉΓòÉΓòÉ
  1353.  
  1354.  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1355.  Γöé Types of Expanded Memory.  Memory types utilized by VDMs.    Γöé
  1356.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1357.  Γöé ATTRIBUTE                           Γöé HMA  Γöé EMB  Γöé UMB      Γöé
  1358.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1359.  Γöé Is extended memory                  Γöé X    Γöé X    Γöé          Γöé
  1360.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1361.  Γöé Accessible from real mode           Γöé X    Γöé      Γöé X        Γöé
  1362.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1363.  Γöé Data may be stored                  Γöé X    Γöé X    Γöé X        Γöé
  1364.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1365.  Γöé Code may be executed from real mode Γöé X    Γöé      Γöé X        Γöé
  1366.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1367.  Γöé Interrupt handler may be stored     Γöé      Γöé      Γöé X        Γöé
  1368.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1369.  Γöé Size may be changed after initial   Γöé      Γöé X    Γöé          Γöé
  1370.  Γöé allocation                          Γöé      Γöé      Γöé          Γöé
  1371.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1372.  Γöé Minimum size                        Γöé 64KB Γöé 1KB  Γöé 16 bytes Γöé
  1373.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1374.  Γöé Maximum size for one                Γöé 64KB Γöé 64MB Γöé 384KB    Γöé
  1375.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1376.  Γöé Maximum size total                  Γöé 64KB Γöé 64MB Γöé 384KB    Γöé
  1377.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1378.  Γöé Number available                    Γöé 1    Γöé 255  Γöé 24KB     Γöé
  1379.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1380.  
  1381.  
  1382. ΓòÉΓòÉΓòÉ 8. Special Notices ΓòÉΓòÉΓòÉ
  1383.  
  1384. This publication is intended to help customers and system engineers to 
  1385. understand and utilize the new features in Version 2.0 of OS/2. The information 
  1386. in this publication is not intended as the specification of any programming 
  1387. interfaces that are provided by OS/2 Version 2.0. See the PUBLICATIONS section 
  1388. of the IBM Programming Announcement for OS/2 Version 2.0 for more information 
  1389. about what publications are considered to be product documentation. 
  1390.  
  1391. References in this publication to IBM products, programs or services do not 
  1392. imply that IBM intends to make these available in all countries in which IBM 
  1393. operates.  Any reference to an IBM product, program, or service is not intended 
  1394. to state or imply that only IBM's product, program, or service may be used. Any 
  1395. functionally equivalent program that does not infringe any of IBM's 
  1396. intellectual property rights may be used instead of the IBM product, program or 
  1397. service. 
  1398.  
  1399. Information in this book was developed in conjunction with use of the equipment 
  1400. specified, and is limited in application to those specific hardware and 
  1401. software products and levels. 
  1402.  
  1403. IBM may have patents or pending patent applications covering subject matter in 
  1404. this document.  The furnishing of this document does not give you any license 
  1405. to these patents.  You can send license inquiries, in writing, to the IBM 
  1406. Director of Commercial Relations, IBM Corporation, Purchase, NY 10577. 
  1407.  
  1408. The information contained in this document has not been submitted to any formal 
  1409. IBM test and is distributed AS IS. The information about non-IBM ("vendor") 
  1410. products in this manual has been supplied by the vendor and IBM assumes no 
  1411. responsibility for its accuracy completeness. The use of this information or 
  1412. the implementation of any of these techniques is a customer responsibility and 
  1413. depends on the customer's ability to evaluate and integrate them into the 
  1414. customer's operational environment.  While each item may have been reviewed by 
  1415. IBM for accuracy in a specific situation, there is no guarantee that the same 
  1416. or similar results will be obtained elsewhere.  Customers attempting to adapt 
  1417. these techniques to their own environments do so at their own risk. 
  1418.  
  1419. References in this publication to IBM products, programs or services do not 
  1420. imply that IBM intends to make these available in all countries in which IBM 
  1421. operates.  Any reference to an IBM product, program, or service is not intended 
  1422. to state or imply that only IBM's product, program, or service may be used. Any 
  1423. functionally equivalent program that does not infringe any of IBM's 
  1424. intellectual property rights may be used instead of the IBM product, program or 
  1425. service. 
  1426.  
  1427. This document has not been subjected to any formal review and has not been 
  1428. checked for technical accuracy.  Results may be individually evaluated for 
  1429. applicability to a particular installation.  You may discuss pertinent 
  1430. information from this document with a customer, and you may abstract pertinent 
  1431. information for presentation to your customers.  However, any code included is 
  1432. for internal information purposes only and may not be given to customers. If 
  1433. included code is identified as incidental programming, its use must conform to 
  1434. the guidelines in the relevant section of the sales manual. 
  1435.  
  1436. Any performance data contained in this document was obtained in a controlled 
  1437. environment based on the use of specific data and is presented only to 
  1438. illustrate techniques and procedures to assist IBM personnel to better 
  1439. understand IBM products.  The results that may be obtained in other operating 
  1440. environments may vary significantly.  Users of this document should verify the 
  1441. applicable data in their specific environment.  No performance data may be 
  1442. abstracted or reproduced and given to non-IBM personnel without prior written 
  1443. approval by Business Practices. 
  1444.  
  1445. Any performance data contained in this document was determined in a controlled 
  1446. environment, and therefore, the results that may be obtained in other operating 
  1447. environments may vary significantly. Users of this document should verify the 
  1448. applicable data for their specific environment. 
  1449.  
  1450. The following document contains examples of data and reports used in daily 
  1451. business operations.  To illustrate them as completely as possible, the 
  1452. examples contain the names of individuals, companies, brands, and products. 
  1453. All of these names are fictitious and any similarity to the names and addresses 
  1454. used by an actual business enterprise is entirely coincidental. 
  1455.  
  1456. Reference to PTF numbers that have not been released through the normal 
  1457. distribution process does not imply general availability. The purpose of 
  1458. including these reference numbers is to alert IBM customers to specific 
  1459. information relative to the implementation of the PTF when it becomes available 
  1460. to each customer according to the normal IBM PTF distribution process. 
  1461.  
  1462. You can reproduce a page in this document as a transparency, if that page has 
  1463. the copyright notice on it.  The copyright notice must appear on each page 
  1464. being reproduced. 
  1465.  
  1466. The following terms, which are denoted by an asterisk (*) in this publication, 
  1467. are trademarks of the International Business Machines Corporation in the United 
  1468. States and/or other countries: 
  1469.  
  1470.  AIX
  1471.  C/2
  1472.  IBM
  1473.  Micro Channel
  1474.  Operating System/2
  1475.  OS/2
  1476.  Personal System/2
  1477.  Presentation Manager
  1478.  SAA
  1479.  Systems Application Architecture
  1480.  Workplace Shell
  1481.  
  1482. The following terms, which are denoted by a double asterisk (**) in this 
  1483. publication, are trademarks of other companies. 
  1484.  
  1485. Adobe is a trademark of Adobe Systems Inc.
  1486. AST is a trademark of AST.
  1487. CP/M is a trademark of Digital Research Inc.
  1488. CompuServe is a trademark CompuServe Inc.
  1489. DR-DOS is a trademark of Digital Research Inc.
  1490. Excel is a trademark of Microsoft Corporation.
  1491. Helvetica is a trademark of Linotype Company.
  1492. HP and Hewlett-Packard are trademarks of Hewlett-Packard Corporation.
  1493. Intel is a trademark of Intel Corporation.
  1494. LaserJet is a trademark of Hewlett-Packard Corporation.
  1495. Lotus and Lotus 1-2-3 are trademarks of Lotus Development Corporation.
  1496. Microsoft is a trademark of Microsoft Corporation.
  1497. MS-DOS is a registered trademark of Microsoft Corporation.
  1498. SPF/2 is a trademark of Command Technology Corporation.
  1499. Times New Roman is a trademark of Monotype Corporation Limited.
  1500. Windows is a trademark of Microsoft Corporation.
  1501. WordPerfect is a trademark of Wordperfect Corporation.
  1502. 386, 486, SX are trademarks of Intel Corporation.
  1503. 80286, 80386 and 80486 are trademarks of Intel Corporation.
  1504.  
  1505.  
  1506. ΓòÉΓòÉΓòÉ 9. Preface ΓòÉΓòÉΓòÉ
  1507.  
  1508. This document provides an understanding of the architecture and function of the 
  1509. Multiple Virtual DOS Machines (MVDM) component of OS/2 Version 2.0, which 
  1510. allows concurrent execution of multiple DOS applications, each in its own 
  1511. virtual DOS machine.  Further, this document describes the support for Windows 
  1512. applications under OS/2 Version 2.0. 
  1513.  
  1514. This document contains information on the MVDM architecture and components, 
  1515. including the use of device drivers by DOS applications, and support for 
  1516. expanded and extended memory.  Other MVDM-related topics discussed in this 
  1517. document include the DOS Settings feature, which allows the user to determine 
  1518. the way in which a DOS application runs and the resources available to it, and 
  1519. Virtual Machine Boot, which allows the user to load any version of DOS into a 
  1520. virtual DOS machine to support the execution of version-dependent DOS 
  1521. applications. 
  1522.  
  1523. Support for Windows applications on the OS/2 Version 2.0 platform is another 
  1524. important topic examined in this document.  The document includes a discussion 
  1525. of Windows device drivers, inter-process communication between Windows, DOS, 
  1526. and OS/2 applications (including DDE and clipboard capabilities), and 
  1527. compatibility issues as they relate to Windows applications in the OS/2 Version 
  1528. 2.0 environment. 
  1529.  
  1530. This document is intended for: 
  1531.  
  1532.  Customer planners and technical support personnel who require an 
  1533.   understanding of DOS and Windows implementation in OS/2 Version 2.0. 
  1534.  
  1535.  IBM and IBM authorized dealer technical support personnel. 
  1536.  
  1537.  Programmers of DOS and Windows applications who wish to ensure compatibility 
  1538.   of their applications with the OS/2 Version 2.0 platform. 
  1539.  
  1540. The information contained in this document assumes that readers have a general 
  1541. familiarity with the DOS and Windows environments and the applications which 
  1542. run in these environments. 
  1543.  
  1544. The code examples used in this document are available in electronic form via 
  1545. CompuServe** or through a local IBM Support Bulletin Board System (BBS), as 
  1546. package RB3731.ZIP. IBM employees may obtain the code examples from the 
  1547. GG243731 PACKAGE on OS2TOOLS. 
  1548.  
  1549. The document is organized as follows: 
  1550.  
  1551.  Overview provides a brief introduction to the topics covered in this 
  1552.   document. 
  1553.  
  1554.   This chapter is recommended for all readers of the document. 
  1555.  
  1556.  MVDM Architecture describes the architecture of the Multiple Virtual DOS 
  1557.   Machines component of OS/2 Version 2.0, including information regarding the 
  1558.   creation and management of virtual DOS machines. 
  1559.  
  1560.   This chapter is recommended for those readers who require an understanding of 
  1561.   the way in which OS/2 Version 2.0 manages virtual DOS machine resources and 
  1562.   an understanding of how MVDM implementation differs from the implementation 
  1563.   of the DOS Compatibility Box in previous versions of OS/2. 
  1564.  
  1565.  8086 Emulation discusses 8086 emulation under OS/2 Version 2.0. 
  1566.  
  1567.   This chapter is recommended for those readers who desire an overview of the 
  1568.   8086 emulation capabilities of the Intel 80386 processor, which are exploited 
  1569.   by OS/2 Version 2.0, and who wish to compare the functions this environment 
  1570.   provides to DOS applications with those available to DOS applications under 
  1571.   previous versions of OS/2. 
  1572.  
  1573.  MVDM DOS Emulation describes the way in which DOS emulation is achieved by 
  1574.   the MVDM component, and compares the functions available in a virtual DOS 
  1575.   machine to those available in native DOS 5.0.  Considerations for running a 
  1576.   DOS application under OS/2 Version 2.0 versus running it under native DOS are 
  1577.   also discussed. 
  1578.  
  1579.   This chapter is recommended for those readers who wish to compare the VDM 
  1580.   environment under OS/2 Version 2.0 with that of DOS 5.0. 
  1581.  
  1582.  Device Drivers discusses MVDM  device drivers.  It describes the device 
  1583.   drivers which are supported in a virtual DOS machine under OS/2 Version 2.0 
  1584.   and explains how device drivers are implemented, differentiating between 
  1585.   physical device drivers and virtual device drivers.  Virtual DOS machine 
  1586.   interrupt support is also discussed. 
  1587.  
  1588.   This chapter is intended primarily for programmers who plan to write device 
  1589.   drivers for DOS applications that will run under OS/2 Version 2.0 and for 
  1590.   technical support personnel who wish an in-depth understanding of virtual DOS 
  1591.   machine device driver support. 
  1592.  
  1593.  Memory Extender Support describes the support for DOS memory extenders 
  1594.   provided in the MVDM component.  This chapter explains expanded and extended 
  1595.   memory support. 
  1596.  
  1597.   This chapter is recommended for those readers who wish to understand the way 
  1598.   in which MVDM supports applications which make use of more than 640KB of 
  1599.   conventional memory. 
  1600.  
  1601.  Installing and Migrating Applications describes installing and migrating DOS 
  1602.   and Windows applications to OS/2 V2.0 It also discusses the use of the 
  1603.   utility for creating a customized migration database. 
  1604.  
  1605.   This chapter is recommended for system administrators responsible for setting 
  1606.   up applications for OS/2 V2.0 users. 
  1607.  
  1608.  Windows Applications describes the implementation of Windows application 
  1609.   support under OS/2 Version 2.0. 
  1610.  
  1611.   This chapter is intended for those readers who wish to run Windows 
  1612.   applications under OS/2 Version 2.0. 
  1613.  
  1614.  DOS Protected Mode Interface describes the implementation of the DOS Protect 
  1615.   Mode Interface, DPMI. 
  1616.  
  1617.   This chapter is intended for those readers who wish to run Windows 
  1618.   applications under OS/2 Version 2.0 and who also need a deeper understanding 
  1619.   of the technical implications of this programming interface. 
  1620.  
  1621.  Running DOS Applications describes the way to define, configure and start DOS 
  1622.   applications under OS/2 Version 2.0. 
  1623.  
  1624.   This chapter is recommended for those readers who wish to run DOS 
  1625.   applications under OS/2 Version 2.0, and who wish to define and configure 
  1626.   their application environment for optimum compatibility and performance. 
  1627.  
  1628.  DOS Settings describes the DOS Settings feature of MVDM.  This feature allows 
  1629.   the user to customize parameters which affect how an application runs in a 
  1630.   VDM and the resources available to it. 
  1631.  
  1632.   This chapter is recommended for every reader who plans to run DOS 
  1633.   applications under OS/2 Version 2.0. 
  1634.  
  1635.  Virtual Machine Boot describes the Virtual Machine Boot feature of MVDM, 
  1636.   which allows a specific version of DOS to be started within a virtual DOS 
  1637.   machine, thereby providing full compatibility for those applications which 
  1638.   require version-specific DOS features. 
  1639.  
  1640.   This chapter is recommended for readers who need to run such applications in 
  1641.   a VDM. 
  1642.  
  1643. The following appendixes are included in this document: 
  1644.  
  1645.  1. Running Personal Communications/3270 Version 2 for Windows explains how to 
  1646.     set up and run Personal Communications/3270 Version 2 for Windows in a 
  1647.     WIN-OS/2 window. 
  1648.  
  1649.  2. Running DOS PC Support/400 in OS/2 V2.0 explains how to set up and run DOS 
  1650.     PC Support/400 in a Virtual Machine Boot session. 
  1651.  
  1652.  3. Running Lotus 1-2-3 in a VDM explains how to set up and run Lotus 1-2-3 in 
  1653.     a virtual DOS machine session with EMS or DPMI support. 
  1654.  
  1655.  4. Memory Extender Architectures provides a brief overview of the 
  1656.     Lotus-Intel-Microsoft (LIM) Expanded Memory Specification (EMS) Version 4.0 
  1657.     and LIMA Extended Memory Specification (XMS) Version 2.0, for those readers 
  1658.     who desire an understanding of these specifications in the context of their 
  1659.     support by MVDM. 
  1660.  
  1661.  5. Multiple Virtual DOS Machines Lab Sessions provides a series of lab 
  1662.     exercises designed to illustrate the new functions and features of the 
  1663.     Multiple Virtual DOS Machines component of OS/2 Version 2.0.  The exercises 
  1664.     cover such topics as virtual DOS machine  configuration, use of the OS/2 
  1665.     clipboard, virtual DOS machine device drivers, and virtual DOS machine 
  1666.     video mode restrictions. 
  1667.  
  1668.  
  1669. ΓòÉΓòÉΓòÉ 10. Related Publications ΓòÉΓòÉΓòÉ
  1670.  
  1671. The following publications are considered particularly suitable for a more 
  1672. detailed discussion of the topics covered in this document. 
  1673.  
  1674. Prerequisite Publications 
  1675.  
  1676.  OS/2 Version 2.0 Installation Guide 
  1677.  
  1678.  OS/2 Version 2.0 Overview Guide 
  1679.  
  1680.  OS/2 Version 2.0 Online Documentation. 
  1681.  
  1682. Additional Publications 
  1683.  
  1684.  OS/2 V1.2 Standard Edition Internals and Evaluation, GG24-3466 
  1685.  
  1686.  OS/2 V1.3 Volume 1: New Features, GG24-3630 
  1687.  
  1688.  OS/2 V1.3 Volume 2: Print Subsystem, GG24-3631 
  1689.  
  1690.  OS/2 Version 2.0 - Volume 1:  Control Program, GG24-3730 
  1691.  
  1692.  OS/2 Version 2.0 - Volume 3:  Presentation Manager and Workplace Shell, 
  1693.   GG24-3732 
  1694.  
  1695.  OS/2 Version 2.0 - Volume 4:  Application Development, GG24-3774 
  1696.  
  1697.  OS/2 Version 2.0 - Volume 5:  Print Subsystem, GG24-3775 
  1698.  
  1699.  OS/2 Version 2.0 Remote Installation and Maintenance, GG24-3780 
  1700.  
  1701.  IBM DOS 5.0, Windows 3.0, Windows Connection 2.0, Personal 
  1702.   Communications/3270 2.0, GG24-3612 
  1703.  
  1704.  Intel 80386 System Software Writer's Guide, ISBN 1-55512-023-7 
  1705.  
  1706.  Virtual Control Program Interface (VCPI) Specification Version 1.0 
  1707.  
  1708.  DOS Protect Mode Interface (DPMI) Specification, Version 0.9 
  1709.  
  1710.  Expanded Memory Specification (EMS), Version 4.0 
  1711.  
  1712.  Extended Memory Specification (XMS), Version 2.0 
  1713.  
  1714.  IBM Personal System Technical Solutions Journal 
  1715.  
  1716.  IBM Personal System Developer Journal 
  1717.  
  1718.  Microsoft Systems Journal 
  1719.  
  1720.  Microsoft Windows Programming Reference 
  1721.  
  1722.  DOS 5.0 User's Guide and Reference 
  1723.  
  1724.  DOS 5.0 Technical Reference. 
  1725.  
  1726.  
  1727. ΓòÉΓòÉΓòÉ 11. Overview ΓòÉΓòÉΓòÉ
  1728.  
  1729. A significant new feature of IBM* OS/2* Version 2.0 is the ability to execute 
  1730. multiple DOS applications concurrently, with pre-emptive multitasking and full 
  1731. memory protection for each application.  Microsoft** Windows** applications are 
  1732. also supported in the same way.  These capabilities allow the use of OS/2 
  1733. Version 2.0 as an integration platform for DOS applications, Windows 
  1734. applications, and OS/2 applications in a seamless, fully functional 
  1735. environment. 
  1736.  
  1737. This chapter provides a brief overview of the OS/2 Version 2.0 product and the 
  1738. Multiple Virtual DOS Machines component which provides support for DOS and 
  1739. Windows applications.  DOS and Windows application support is then described in 
  1740. more detail in the remainder of the document. 
  1741.  
  1742.  
  1743. ΓòÉΓòÉΓòÉ 11.1. OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  1744.  
  1745. While this document focuses on Multiple Virtual DOS Machines and the support of 
  1746. Windows applications under OS/2 Version 2.0, it is useful to briefly review the 
  1747. highlights of OS/2 Version 2.0. 
  1748.  
  1749.  
  1750. ΓòÉΓòÉΓòÉ 11.1.1. OS/2 Version 2.0 Overview ΓòÉΓòÉΓòÉ
  1751.  
  1752. OS/2 Version 2.0 is an advanced multitasking, single-user operating system for 
  1753. IBM Personal System/2* computers and other computers equipped with the Intel** 
  1754. 80386**, 80486**, or compatible processors. It exploits a rich set of features 
  1755. from previous versions of OS/2, such as support for multitasking, 
  1756. multithreading, dynamic linking, interprocess communication, a graphical user 
  1757. interface, and the High Performance File System.  OS/2 Version 2.0, however, 
  1758. provides significant enhancements over previous versions of OS/2. 
  1759.  
  1760. The following new features have been implemented in OS/2 Version 2.0: 
  1761.  
  1762.  Support for the Intel 80386 32-bit microprocessor instruction set. 
  1763.  
  1764.  32-bit memory management. 
  1765.  
  1766.  Enhanced hardware exploitation. 
  1767.  
  1768.  Multiple Virtual DOS Machines. 
  1769.  
  1770.  Support for Microsoft Windows applications. 
  1771.  
  1772.  32-bit programming environment. 
  1773.  
  1774.  Object-code compatibility with previous versions of OS/2, allowing 16-bit 
  1775.   applications written for previous versions to execute under Version 2.0 
  1776.   without modification. 
  1777.  
  1778.  Enhanced Presentation Manager* user shell, which implements the 1991 SAA* CUA 
  1779.   Workplace Environment. 
  1780.  
  1781.  
  1782. ΓòÉΓòÉΓòÉ 11.1.2. Memory and Task Management ΓòÉΓòÉΓòÉ
  1783.  
  1784. The foundation for OS/2 Version 2.0 capabilities is its support for the Intel 
  1785. 80386 microprocessor. This support means that a powerful set of 32-bit features 
  1786. now becomes available to the operating system and applications, including 
  1787. enhanced memory management and more sophisticated multitasking. 
  1788.  
  1789. OS/2 Version 2.0 requires the features of the Intel 80386 or compatible 32-bit 
  1790. microprocessors, and therefore does not run on computers that use the Intel 
  1791. 80286** processor, or its predecessors.  In order to maintain compatibility, 
  1792. however, OS/2 Version 2.0 supports applications written for previous versions 
  1793. of OS/2 by providing both a 16-bit as well as a 32-bit application programming 
  1794. interface, allowing 16-bit applications to execute under OS/2 Version 2.0 
  1795. without modification.  The Intel 80386 can address 4 gigabytes of physical 
  1796. memory and up to 64 terabytes of virtual memory. 
  1797.  
  1798. OS/2 Version 2.0 supports execution of the following types of applications: 
  1799.  
  1800.  DOS applications, in full-screen mode or in window-mode on the Presentation 
  1801.   Manager desktop. 
  1802.  
  1803.  Microsoft Windows applications, in windows on the Presentation Manager 
  1804.   desktop. 
  1805.  
  1806.  16-bit OS/2 applications developed for previous versions of OS/2. 
  1807.  
  1808.  32-bit applications developed for OS/2 Version 2.0. 
  1809.  
  1810. All applications execute as protected mode processes under OS/2 Version 2.0, 
  1811. and are therefore provided with pre-emptive multitasking and full memory 
  1812. protection between processes. 
  1813.  
  1814. Memory management is the way in which the operating system allows applications 
  1815. to access the system's memory.  The operating system must check how much memory 
  1816. is available to an application, and handle the event when there is no longer 
  1817. any real memory left to satisfy an application's requests. 
  1818.  
  1819. In OS/2 Version 2.0, memory management has been enhanced to provide a flat 
  1820. memory model, which takes advantage of the 32-bit addressing scheme provided by 
  1821. the Intel 80386 architecture.  This means that through memory management, the 
  1822. system's memory is seen as one large linear address space of 4GB.  This 32-bit 
  1823. programming environment is free from the limitations and inherent complexity of 
  1824. the segmented memory model used by DOS and previous 16-bit versions of OS/2. 
  1825. Memory management within applications is greatly simplified, allowing 
  1826. applications to be developed faster, with better performance due to reduced 
  1827. memory manipulation overhead.  Through the use of the flat memory model, 
  1828. applications may be more easily ported to or from other operating system 
  1829. platforms. 
  1830.  
  1831. Task Management, the management of processes and threads executing in a system, 
  1832. is greatly simplified and streamlined under OS/2 Version 2.0. This is due 
  1833. primarily to the fact that support for processes executing in real mode (such 
  1834. as the DOS Compatibility Box in previous versions of OS/2) is no longer 
  1835. required, since the execution of DOS applications is supported using virtual 
  1836. DOS machines which run as protected mode processes under OS/2 Version 2.0. 
  1837.  
  1838. Interrupt handling under OS/2 Version 2.0 is simplified by removal of the need 
  1839. to handle real mode software interrupts.  Interrupts issued by DOS and Windows 
  1840. applications are trapped by a virtual programmable interrupt controller (VPIC) 
  1841. which translates the interrupts to the appropriate device access commands for 
  1842. the protected mode environment.  The virtual programmable interrupt controller 
  1843. is described in Device Drivers. 
  1844.  
  1845.  
  1846. ΓòÉΓòÉΓòÉ 11.1.3. User Interface ΓòÉΓòÉΓòÉ
  1847.  
  1848. OS/2 Version 2.0 also provides an enhanced user shell, known as the Workplace 
  1849. Shell*, through enhancements to Presentation Manager.  The Workplace Shell is 
  1850. object-based and implements the 1991 SAA CUA Workplace Environment.  This shell 
  1851. is more intuitive than the Presentation Manager shell implemented in previous 
  1852. versions of OS/2, and allows users to become familiar with the system more 
  1853. quickly. 
  1854.  
  1855. In the Workplace Shell, system resources, such as files and printers, are 
  1856. regarded as objects, and represented by graphical icons on the screen. Users 
  1857. may manipulate objects (open them for editing, copy them, and print them, for 
  1858. example) by direct manipulation of the icons.  For example, a file is copied 
  1859. from one location to another by pointing to it with the mouse, dragging the 
  1860. object's icon to the required destination, and dropping the icon by releasing 
  1861. the mouse button.  This is known as drag and drop manipulation. 
  1862.  
  1863. Presentation Manager and the Workplace Shell are described in more detail in 
  1864. OS/2 Version 2.0 - Volume 3:  Presentation Manager and Workplace Shell. 
  1865.  
  1866.  
  1867. ΓòÉΓòÉΓòÉ 11.2. Multiple Virtual DOS Machines ΓòÉΓòÉΓòÉ
  1868.  
  1869. OS/2 Version 2.0 provides the user with the ability to run multiple concurrent 
  1870. DOS applications, and to multitask these applications with OS/2 applications. 
  1871. In previous versions of OS/2, support for DOS applications was limited to a 
  1872. single DOS session, known as the DOS Compatibility Box, in which the amount of 
  1873. memory available to the DOS application was restricted.  Applications running 
  1874. in the DOS Compatibility Box could operate in full-screen mode only, and were 
  1875. suspended when switched to the background. 
  1876.  
  1877. Support for DOS applications has been completely redesigned in OS/2 Version 
  1878. 2.0, which now provides for the execution and management of multiple concurrent 
  1879. DOS applications, where each application is executed as a single-threaded, 
  1880. protected mode OS/2 program.  This capability is provided by a component of 
  1881. OS/2 Version 2.0 known as Multiple Virtual DOS Machines (MVDM). 
  1882.  
  1883. MVDM introduces powerful DOS application support to OS/2 by exploiting the 
  1884. virtual 8086 (V86) mode of the Intel 80386 processor.  This mode of operation 
  1885. allows the emulation of an Intel 8086 processor and associated hardware devices 
  1886. within a protected mode 80386 task.  OS/2 Version 2.0 uses the virtual 8086 
  1887. mode to allow the creation of multiple instances of independent virtual DOS 
  1888. machines. Through this technique, a virtual interface is provided to each 
  1889. virtual DOS machine, giving the impression that the application running in that 
  1890. machine owns all the required resources, both hardware and software. 
  1891.  
  1892. Each virtual DOS machine runs as a protected mode process, in a manner similar 
  1893. to an OS/2 application.  The use of protected mode allows pre-emptive 
  1894. multitasking of DOS applications and provides a protected system environment in 
  1895. which DOS applications can execute.  This means that system memory and all 
  1896. other applications (both DOS and OS/2), are protected from ill-behaved 
  1897. applications, and the user can terminate a DOS application which is "hung". An 
  1898. errant DOS application can affect only its own virtual DOS machine; other 
  1899. applications in the system will not be affected. 
  1900.  
  1901. Figure "Concurrent DOS Applications under the Workplace Shell" 
  1902.  
  1903. Each virtual DOS machine has a great deal more available memory than did the 
  1904. DOS Compatibility Box implemented in previous versions of OS/2.  Depending on 
  1905. the use of DOS device drivers and TSR programs, it is possible to have as much 
  1906. as 630KB of available memory for application execution.  In addition, OS/2 
  1907. Version 2.0 supports the use of the Lotus**-Intel-Microsoft (LIM) Expanded 
  1908. Memory Specification (EMS) and the Lotus-Intel-Microsoft-AST** (LIMA) Extended 
  1909. Memory Specification (XMS) to provide additional memory for those DOS 
  1910. applications which are capable of using such memory extenders.  OS/2 Version 
  1911. 2.0 maps this expanded or extended memory into the system's linear memory 
  1912. address space, and manages it in the same manner as any other memory. 
  1913.  
  1914. Each virtual DOS machine may run either in full-screen mode or within a 
  1915. Presentation Manager window. A window containing a DOS application may be sized 
  1916. and manipulated in the same manner as any other Presentation Manager window, 
  1917. and other Presentation Manager desktop features are readily available such as 
  1918. the ability to cut/copy/paste information between applications using the 
  1919. clipboard, or the ability to change fonts. 
  1920.  
  1921. From the user's perspective, DOS applications behave exactly like VIO 
  1922. applications.  DOS applications have the following characteristics: 
  1923.  
  1924.  They may run in either full-screen mode or in window-mode. 
  1925.  
  1926.  They can run in the background if doing text screen output. 
  1927.  
  1928.  Windowed DOS applications have all the same system menu controls as do OS/2 
  1929.   windowed applications, including font adjustment and clipboard functions such 
  1930.   as mark, copy and paste. 
  1931.  
  1932. Furthermore, DOS applications under OS/2 Version 2.0 have advantages over VIO 
  1933. applications: 
  1934.  
  1935.  They may be switched between windowed and full-screen while running. 
  1936.  
  1937.  A full-screen graphics-mode DOS application may be switched into a window and 
  1938.   the graphics bitmap will be rendered in the window. This allows the user to 
  1939.   copy graphics to the Presentation Manager clipboard and gives the viewer more 
  1940.   flexibility when running multiple applications. 
  1941.  
  1942.  For single-plane graphics modes (CGA, and VGA 320 x 200), DOS graphics 
  1943.   applications will execute in a window and continue to update while in the 
  1944.   background. 
  1945.  
  1946. The sole restriction for DOS applications running in a virtual DOS machine when 
  1947. compared with VIO applications is that DOS applications in virtual DOS machines 
  1948. cannot be used in process subtrees. That is, VDMs cannot be run as child 
  1949. processes of either an OS/2 session or another VDM session. 
  1950.  
  1951. There are some DOS applications and products that cannot be supported by DOS 
  1952. emulation, due to the nature of the emulation code and the multitasking and 
  1953. protection demands of OS/2 Version 2.0.  Unsupported products/functions 
  1954. include: 
  1955.  
  1956.  DOS applications which have internal DOS structure dependencies, such as 
  1957.   Windows 1.0x and MS/PC Net. 
  1958.  
  1959.  DOS applications which do not work in a multitasking environment, such as 
  1960.   Norton Disk Utilities**, DOS block device drivers, and Fastback**. 
  1961.  
  1962.  DOS network drivers, because DOS emulation uses an implementation different 
  1963.   from DOS to control its I/O.  However, DOS applications running in VDMs may 
  1964.   access network services through the normal OS/2 network driver. 
  1965.  
  1966. Some of these applications may be run under OS/2 Version 2.0 by booting a 
  1967. specific version of DOS in a virtual DOS machine, using the Virtual Machine 
  1968. Boot feature of MVDM.  This feature is described in detail in Virtual Machine 
  1969. Boot. 
  1970.  
  1971. Application compatibility in the virtual DOS machine is also enhanced over 
  1972. previous versions of OS/2.  A virtual DOS machine can be used to execute 
  1973. DOS-based communications applications and other applications which address 
  1974. hardware I/O devices, through the use of virtual device drivers, which map 
  1975. device driver calls from DOS applications to the appropriate physical device 
  1976. driver within the operating system.  Applications using hardware devices which 
  1977. do not have to be shared with DOS applications in the same system may access 
  1978. these devices using the standard DOS device drivers, without the need for a 
  1979. virtual device driver.  Certain restrictions still apply with respect to 
  1980. communications line speed and time-critical interrupt handling. 
  1981.  
  1982. A powerful new feature called DOS Settings allows an individual to easily 
  1983. tailor, via Presentation Manager windows, the resources, such as video and 
  1984. memory, available to an application running in a virtual DOS machine, and thus 
  1985. optimize the way in which a DOS application runs. 
  1986.  
  1987.  
  1988. ΓòÉΓòÉΓòÉ 11.2.1. MVDM Architecture ΓòÉΓòÉΓòÉ
  1989.  
  1990. MVDM is designed to exploit the virtual 8086 (V86) mode of the 80386 processor, 
  1991. which allows operating systems such as OS/2 Version 2.0 to execute multiple DOS 
  1992. applications within the 80386 protected mode environment.  Under OS/2 Version 
  1993. 2.0, each DOS application executes in a virtual DOS machine (VDM), which runs 
  1994. as a single-threaded protected mode process.  The operating system scheduler 
  1995. controls task switching of VDMs in the same way as it does OS/2 application 
  1996. processes. 
  1997.  
  1998. The MVDM kernel controls the state and operation of concurrent VDMs, and is 
  1999. composed of the following four major components as shown in Figure "MVDM 
  2000. Architecture". 
  2001.  
  2002.  1. The Virtual DOS Machine Manager (VDMM) contains the mechanism to start and 
  2003.     interact with DOS applications.  It creates, initializes, and terminates 
  2004.     VDMs.  The VDMM manages system resources such as memory, timers, 
  2005.     semaphores, and files for all VDMs active in the system.  The VDMM is 
  2006.     responsible for loading and initializing all virtual device drivers, in 
  2007.     conjunction with the Virtual Device Driver Manager.  The VDMM is described 
  2008.     in more detail in MVDM Architecture. 
  2009.  
  2010.  2. 8086 Emulation manages communication between 8086 instruction streams and 
  2011.     virtual device drivers.  This emulation performs 8086 instruction decoding, 
  2012.     controls the 80386 processor's I/O Privilege Map for each VDM, manages the 
  2013.     reflection of software interrupts for each VDM, routes IN/OUT instruction 
  2014.     traps to the appropriate virtual device driver, and manages various control 
  2015.     structures required by each virtual device driver.  8086 emulation is 
  2016.     described in more detail in 8086 Emulation. 
  2017.  
  2018.  3. DOS Emulation emulates the function and operation of the DOS operating 
  2019.     system on a per-VDM basis.  Each VDM emulates an entirely independent 
  2020.     instance of DOS.  DOS services are emulated within the MVDM kernel, or by 
  2021.     invoking protected-mode services provided by the OS/2 kernel.  For example, 
  2022.     most DOS file I/O functions are provided by the OS/2 file system.  DOS 5.0 
  2023.     compatibility is provided.  DOS emulation is described in more detail in 
  2024.     MVDM DOS Emulation. 
  2025.  
  2026.  4. The Virtual Device Driver Manager (VDDM) loads, initializes, and 
  2027.     communicates with virtual device drivers.  Virtual device drivers are 
  2028.     required to virtualize the hardware and ROM BIOS, thereby allowing DOS 
  2029.     applications to access hardware devices and BIOS without affecting other 
  2030.     VDMs or other non-V86 mode processes in the system.  The VDDM provides 
  2031.     various system services, known as Virtual Device Helper (VDH) services, to 
  2032.     virtual device drivers.  The Virtual Device Driver Manager is described in 
  2033.     more detail in Device Drivers. 
  2034.  
  2035. These four components interact with one another and with the OS/2 Version 2.0 
  2036. operating system kernel to provide requested services to DOS applications 
  2037. executing in VDMs. 
  2038.  
  2039.  
  2040. ΓòÉΓòÉΓòÉ 11.2.2. Virtual Device Drivers ΓòÉΓòÉΓòÉ
  2041.  
  2042. In order for multiple DOS applications, each running in its own VDM, to access 
  2043. physical hardware devices, each VDM must be provided with a set of "virtual 
  2044. interfaces" to these devices, so that the actions of one application do not 
  2045. affect the state of the device as perceived by applications in other VDMs. 
  2046.  
  2047. Figure "MVDM System Structure Overview" 
  2048.  
  2049. These virtual interfaces are provided by OS/2 Version 2.0 using virtual device 
  2050. drivers. Virtual device drivers are installable modules responsible for 
  2051. virtualizing the hardware and ROM BIOS aspects of the DOS environment for 
  2052. virtual DOS machines.  A virtual device driver manages shared access to 
  2053. hardware I/O devices for multiple VDMs, allowing an application running in a 
  2054. VDM to act as though it exercised sole control over I/O devices.  Virtual 
  2055. device drivers are implemented whenever possible, allowing the BIOS in the 
  2056. system to perform its functions without interference from DOS applications. 
  2057. Virtual device drivers are used to control hardware such as the keyboard, 
  2058. mouse, and serial and parallel ports. 
  2059.  
  2060. Virtual device drivers are responsible for the following functions: 
  2061.  
  2062.  Maintaining a virtual hardware state for each virtual DOS machine (VDM) 
  2063.  
  2064.  Preventing a VDM from corrupting the state of another VDM, or the system as a 
  2065.   whole 
  2066.  
  2067.  Supporting fast screen I/O 
  2068.  
  2069.  Supporting fast communications I/O. 
  2070.  
  2071. The virtual device driver architecture implemented in OS/2 Version 2.0 provides 
  2072. support for all standard hardware utilized by DOS applications and supports 
  2073. installable virtualization, so that new hardware may be added and supported by 
  2074. VDMs without requiring an upgrade to the operating system. 
  2075.  
  2076. Virtual device drivers obtain and release system resources via the Virtual 
  2077. Device Helper (VDH) services, provided by the MVDM kernel.  A virtual device 
  2078. driver typically performs I/O through a physical device driver using a direct 
  2079. call interface.  However, a virtual device driver may directly access an I/O 
  2080. control device.  The virtual video device driver performs such direct access 
  2081. under OS/2 Version 2.0 for performance purposes.  A virtual device driver may 
  2082. also simulate hardware interrupts into one or many VDM processes. 
  2083.  
  2084. Under OS/2 Version 2.0, a virtual device driver is inherently protected from a 
  2085. VDM because it is not visible in the VDM address space, although a virtual 
  2086. device driver must be careful to check all parameters coming in from a VDM to 
  2087. ensure that it does not damage itself or some other part of the system by 
  2088. executing an invalid instruction. 
  2089.  
  2090.  
  2091. ΓòÉΓòÉΓòÉ 11.2.3. Expanded and Extended Memory Support ΓòÉΓòÉΓòÉ
  2092.  
  2093. Many popular DOS applications use EMS (expanded) and/or XMS (extended) memory 
  2094. extenders to gain access to memory in protected mode on the 80286, 80386, or 
  2095. 80486 processors.  These extenders allow DOS applications to access memory 
  2096. above the 1MB real-mode addressing limit, in order to have total code and data 
  2097. space larger than the available base memory, and to have very large code or 
  2098. data objects loaded into memory for enhanced function and performance.  The 
  2099. standard configuration of OS/2 Version 2.0 provides both EMS and XMS functions 
  2100. as part of MVDM. 
  2101.  
  2102. Under MVDM, EMS and XMS memory allocations are managed as OS/2 pageable virtual 
  2103. memory in the same way as any other memory allocated under OS/2 Version 2.0, 
  2104. and not as fixed physical memory as is the case under DOS.  As such, the total 
  2105. expanded/extended memory allocated can exceed the amount of physical memory 
  2106. installed in the system. 
  2107.  
  2108. LIM EMS Version 4.0 Support 
  2109.  
  2110. The LIM (Lotus-Intel-Microsoft) Expanded Memory Specification (EMS) Version 4.0 
  2111. provides a standard interface for the use of expanded memory with Intel 80x86 
  2112. computers.  The specification allows for up to 32MB of expanded memory, with up 
  2113. to 255 expanded memory objects.  Regions within these objects can be mapped 
  2114. into the 8086 address space (below 1MB) as required, allowing DOS applications 
  2115. to access large address spaces. 
  2116.  
  2117. Under OS/2 Version 2.0, EMS emulation provides the following function: 
  2118.  
  2119.  Implements all the required functions in the LIM 4.0 EMS. 
  2120.  
  2121.  Provides each VDM with a logically separate EMS emulation.  Each VDM has its 
  2122.   own set of expanded objects so that features like interprocess communication 
  2123.   work as they would if each VDM were running on a different physical 8086.  A 
  2124.   VDM cannot affect the availability of objects in other VDMs or access 
  2125.   expanded memory "owned" by other VDMs. 
  2126.  
  2127.  Provides for remapping of conventional memory (below 640KB) for use by 
  2128.   programs such as Windows 2.0. 
  2129.  
  2130.  Provides configurable limits for how much expanded memory is available for 
  2131.   all VDMs, as well as a limit per VDM.  An installed program in the start list 
  2132.   allows the user to override the per-VDM limit, subject to the constraints 
  2133.   imposed by the overall limit. 
  2134.  
  2135.  Supports multiple physical to single logical mappings.  Different 8086 
  2136.   addresses can map to the same expanded memory object address. This is 
  2137.   required by programs like Lotus 1-2-3**. 
  2138.  
  2139. EMS emulation is provided in MVDM by the Virtual Expanded Memory Manager 
  2140. (VEMM).  VEMM is a virtual device driver offering a separate EMS emulation for 
  2141. each VDM.  This is accomplished by placing most EMS control structures for a 
  2142. VDM in a per-VDM instance data area outside the V86 application's address 
  2143. space. 
  2144.  
  2145. Unlike most virtual device drivers, VEMM does not have a corresponding physical 
  2146. device driver. Rather, VEMM traps software interrupts for EMS services using a 
  2147. system call and manages the appropriate memory.  VEMM depends upon the memory 
  2148. management capabilities of the OS/2 Version 2.0 operating system kernel. 
  2149. Allocation, reallocation, or deallocation of EMS memory objects is accomplished 
  2150. by requesting corresponding services from VDH services. 
  2151.  
  2152. LIMA XMS Version 2.0 Support 
  2153.  
  2154. The LIMA Extended Memory Specification (XMS) V2.0 provides a standard interface 
  2155. for the use of extended memory on Intel 80286, 80386, and 80486 computers.  XMS 
  2156. functions allow for the moving of code and data objects from base memory into 
  2157. extended memory, and from extended memory to base memory.  Two of the best 
  2158. known programs using XMS functions are print spoolers and virtual disks (RAM 
  2159. disks). 
  2160.  
  2161. The XMS specifications manage three distinct regions of memory: 
  2162.  
  2163.  The High Memory Area (HMA) is located immediately above 1MB and is exactly 
  2164.   65520 bytes (64KB - 16 bytes) in size. 
  2165.  
  2166.  The Upper Memory Area (UMA), consisting of Upper Memory Blocks (UMBs), is 
  2167.   located between 640KB and 1MB. 
  2168.  
  2169.  The Extended Memory Blocks (EMBs) are used only for data storage. 
  2170.  
  2171. Under OS/2 Version 2.0, LIMA XMS emulation provides the following function: 
  2172.  
  2173.  Implements all LIMA V2.0 XMS functions. 
  2174.  
  2175.  Provides each VDM with a separate XMS emulation.  Each VDM has its own high 
  2176.   memory area, upper memory area, and extended memory blocks, so that features 
  2177.   like interprocess communication work as they would if each VDM were running 
  2178.   on a different physical 8086 processor.  VDMs cannot affect the availability 
  2179.   of objects in other VDMs or access memory "owned" by other VDMs. 
  2180.  
  2181.  Provides configurable limits for how much extended memory is available across 
  2182.   all VDMs, as well as a limit per VDM.  An installed program in the start list 
  2183.   can override the per-VDM limit, subject to the constraint given by the 
  2184.   overall limit, and can disable XMS support altogether for a particular VDM if 
  2185.   its installation conflicts with the program being run in the VDM. 
  2186.  
  2187. The Virtual Extended Memory Manager (VXMS) is a virtual device driver that 
  2188. provides a separate XMS emulation for each VDM.  As with VEMM, this is 
  2189. accomplished by placing most VXMS control structures for a VDM in a per-VDM 
  2190. instance data area outside the V86 application's address space.  The amount of 
  2191. memory available to a VDM, the number of handles, and the existence of upper 
  2192. memory blocks are all configurable parameters which may be altered on a per-VDM 
  2193. basis. 
  2194.  
  2195. Like the VEMM virtual device driver, VXMS does not have a corresponding 
  2196. physical device driver, and utilizes the memory management capabilities of the 
  2197. operating system kernel.  XMS object allocation, reallocation and deallocation 
  2198. are accomplished by requesting corresponding services from the memory manager. 
  2199.  
  2200.  
  2201. ΓòÉΓòÉΓòÉ 11.2.4. DOS Settings ΓòÉΓòÉΓòÉ
  2202.  
  2203. MVDM provides the user with the ability to customize the operation of DOS 
  2204. applications via a feature called DOS Settings. This feature allows the user to 
  2205. control special properties which affect the behavior of DOS applications 
  2206. running in a VDM. 
  2207.  
  2208. The DOS Settings feature further enhances the DOS compatibility of a VDM 
  2209. because it allows a user to configure the VDM for DOS applications which might 
  2210. otherwise not work well (or not work at all) with the default settings for a 
  2211. VDM.  The DOS Settings feature also gives the user more control over the 
  2212. consumption of system resources by a DOS application. Help is provided for each 
  2213. setting to assist users in tuning their applications' operation. 
  2214.  
  2215. DOS sessions have many more customizable properties than OS/2 sessions. MVDM 
  2216. provides a common mechanism that supports both a standard complement of 
  2217. settings, and allows virtual device drivers to register custom settings. The 
  2218. standard settings are a subset of the configuration settings available in the 
  2219. CONFIG.SYS file, plus some additional settings required for MVDM. The primary 
  2220. reason for the existence of the option to alter these settings is that DOS 
  2221. applications are typically not careful about consuming system resources, such 
  2222. as memory and processor time.  Hence, MVDM itself must provide a flexible 
  2223. environment for these applications in order to preserve the integrity and 
  2224. performance of the system as a whole. 
  2225.  
  2226. DOS settings are managed on a per-VDM basis and are accessed through 
  2227. Presentation Manager windows.  The dialog boxes presented allow the user to 
  2228. change a setting while the VDM is running.  Only those settings that can be 
  2229. changed for that VDM are presented.  There are many settings which can be 
  2230. tuned.  One parameter, for example, the Idle Detection Threshold, detects idle 
  2231. DOS applications and allows the user to configure the system such that 
  2232. processor time is not wasted by idle DOS applications. 
  2233.  
  2234. Note that while the DOS Settings feature provides significantly enhanced 
  2235. control over the behavior and capabilities of a virtual DOS machine, this level 
  2236. of control is not necessarily obvious to the end user.  Most DOS applications 
  2237. will execute quite satisfactorily with the default VDM settings, and the user 
  2238. is therefore not required to use the DOS Settings feature.  This approach 
  2239. therefore provides the increased functionality without necessarily increasing 
  2240. the complexity of user interaction. 
  2241.  
  2242.  
  2243. ΓòÉΓòÉΓòÉ 11.3. Windows Application Support ΓòÉΓòÉΓòÉ
  2244.  
  2245. OS/2 Version 2.0 provides the capability for Microsoft Windows applications to 
  2246. run under OS/2 Version 2.0.  This support allows applications written for 
  2247. Windows 3.0 and previous versions of Windows (except V1.x) to coexist with OS/2 
  2248. and DOS applications under OS/2 Version 2.0. 
  2249.  
  2250. Each Windows application executes in a virtual DOS machine, and is thus a 
  2251. protected mode process.  As such, Windows applications are subject to the same 
  2252. application protection facilities provided to other protected mode processes 
  2253. under OS/2 Version 2.0.  Windows applications are protected from other Windows 
  2254. applications and from DOS and OS/2 applications executing in the system.  This 
  2255. is in contrast to the native Windows 3.0 environment, where limited protection 
  2256. is provided for Windows 3.0 applications, and none at all for DOS applications 
  2257. unless Windows is running in enhanced mode. 
  2258.  
  2259. The execution of Windows applications as protected mode tasks also allows these 
  2260. applications to take full advantage of the pre-emptive multitasking 
  2261. capabilities of OS/2 Version 2.0, with full pre-emptive multitasking between 
  2262. Windows applications, OS/2 applications, and DOS applications.  This is again 
  2263. in contrast to the native Windows 3.0 environment, where pre-emptive 
  2264. multitasking is available only when Windows 3.0 is running in enhanced mode, 
  2265. thereby impacting performance and preventing many applications written for 
  2266. previous versions of Windows from executing.  OS/2 Version 2.0 has no such 
  2267. restriction. 
  2268.  
  2269. Windows applications running under OS/2 Version 2.0 will run in a mode 
  2270. equivalent to the real or standard modes of Windows 3.0; the enhanced mode of 
  2271. Windows 3.0 is not required since the OS/2 Version 2.0 operating system itself 
  2272. provides equivalent function. 
  2273.  
  2274. Support for Microsoft Windows applications under OS/2 Version 2.0 is discussed 
  2275. in more depth in Windows Applications. 
  2276.  
  2277.  
  2278. ΓòÉΓòÉΓòÉ 11.4. Summary ΓòÉΓòÉΓòÉ
  2279.  
  2280. OS/2 Version 2.0 provides significantly enhanced DOS application support 
  2281. capability over previous versions of OS/2, using a component known as Multiple 
  2282. Virtual DOS Machines.  MVDM offers many significant functions and features, 
  2283. including: 
  2284.  
  2285.  Ability to run multiple DOS sessions concurrently, with full pre-emptive 
  2286.   multitasking and memory protection 
  2287.  
  2288.  Ability to run DOS applications in Presentation Manager windows 
  2289.  
  2290.  Ability to switch between DOS applications via Presentation Manager 
  2291.  
  2292.  High amount of available free memory for DOS applications (630KB and more) 
  2293.  
  2294.  Expanded (EMS) and extended (XMS) memory emulation support 
  2295.  
  2296.  Clipboard support. 
  2297.  
  2298. OS/2 Version 2.0 provides DOS 5.0 compatibility within the virtual 8086 mode of 
  2299. the 80386 processor, and allows execution of multiple concurrent DOS 
  2300. applications, each operating in its own 1MB virtual address space.  This brings 
  2301. true multiprogramming to the DOS environment under OS/2.  A user may run 
  2302. multiple DOS applications in much the same way as they run multiple OS/2 
  2303. applications.  DOS and OS/2 applications can be started in the same ways: 
  2304.  
  2305.  1. From a desktop group window. 
  2306.  2. From the Drives folder. 
  2307.  3. From a command prompt. 
  2308.  4. From the OS/2 START command. 
  2309.  
  2310. The DOS environment is more DOS-compatible than the DOS Compatibility Box 
  2311. implemented under previous versions of OS/2, since OS/2 Version 2.0 
  2312. encapsulates the entire DOS environment in a virtual machine.  This provides 
  2313. better protection for other processes in the system and for the operating 
  2314. system environment itself.  With MVDM, an errant DOS application can only 
  2315. "hang" its own virtual DOS machine, which may then be terminated by the user 
  2316. without affecting other applications in the system. 
  2317.  
  2318. DOS applications may be run full-screen, windowed, or iconized in the 
  2319. background.  Besides being better protected, providing better compatibility and 
  2320. more concurrent DOS applications, the OS/2 Version 2.0 MVDM environment leaves 
  2321. applications with more than 630KB of memory in which to execute. 
  2322.  
  2323. OS/2 Version 2.0 also provides support for the execution of Microsoft Windows 
  2324. applications (written for Windows 3.0 and/or previous versions of Windows, 
  2325. except version 1.0x) to execute under the control of OS/2 Version 2.0.  Each 
  2326. Windows application executes as a separate protected mode task, and is 
  2327. therefore provided with the same pre-emptive multitasking and memory protection 
  2328. as other protected mode tasks under OS/2 Version 2.0. 
  2329.  
  2330. Support for both the Expanded Memory Specification (EMS) and the Extended 
  2331. Memory Specification (XMS) is provided.  DOS asynchronous communications 
  2332. applications can support communication speeds of up to 9600 baud.  Since the 
  2333. DOS environments are swappable, starting many DOS sessions will not increase 
  2334. requirements for more physical (real) memory. 
  2335.  
  2336. The MVDM environment also provides an extendable architecture that allows the 
  2337. environment to be custom tailored to emulate any DOS environment.  The virtual 
  2338. device driver architecture supports this flexible environment.  All of the 
  2339. low-level DOS support, which in previous versions of OS/2 resided in physical 
  2340. device drivers, has been moved into virtual device drivers.  In virtual 8086 
  2341. mode, all interrupt processing is done in protected mode; bimodal device 
  2342. drivers are no longer needed.  The new driver architecture provides physical 
  2343. device drivers for basic device support and virtual device drivers for 
  2344. supporting virtual devices to the DOS environments.  DOS settings allow the 
  2345. user to tailor the functioning of DOS applications in the VDM environment. 
  2346.  
  2347.  
  2348. ΓòÉΓòÉΓòÉ 12. MVDM Architecture ΓòÉΓòÉΓòÉ
  2349.  
  2350. The Multiple Virtual DOS Machines component of OS/2 Version 2.0 is itself 
  2351. comprised of a number of subcomponents, which interact with one another and 
  2352. with the OS/2 Version 2.0 operating system kernel to provide services to DOS 
  2353. applications running in virtual DOS machines. This chapter describes each 
  2354. subcomponent of MVDM, and explains the interaction between subcomponents. 
  2355.  
  2356.  
  2357. ΓòÉΓòÉΓòÉ 12.1. Introduction ΓòÉΓòÉΓòÉ
  2358.  
  2359. OS/2 Version 2.0 is designed to fully exploit the advanced features of the 
  2360. Intel 80386 processor. A major innovation of the 80386 is its support for the 
  2361. execution of multiple 8086 tasks within the 80386 protected mode environment. 
  2362. An 8086 task in this environment is called a virtual 8086 (V86) task. Under 
  2363. OS/2 Version 2.0, V86 tasks are implemented as virtual DOS machines (VDMs), and 
  2364. each runs as a single-threaded, protected mode process. See also Figure "MVDM 
  2365. System Structure Overview". The OS/2 scheduler controls task switching for V86 
  2366. processes in a way similar to the manner in which it controls other OS/2 
  2367. application processes. When a task switch occurs, the VM bit in EFLAGS 
  2368. contained in the V86 process's task state segment indicates the type of the 
  2369. current process. If the VM bit is set, indicating that the process is a VDM, 
  2370. the processor switches to V86 mode. 
  2371.  
  2372. In this area, performance has been improved over previous versions of OS/2, 
  2373. since the processor is never switched to real mode. Switching from protected 
  2374. mode to real mode takes a long time since all CPU register contents must be 
  2375. saved and paging must be disabled before DOS registers are loaded.  Switching 
  2376. to real mode is often accomplished by resetting the CPU, which is very time 
  2377. consuming. The V86 mode of the processor allows the system to run both OS/2 and 
  2378. DOS applications in protected mode. 
  2379.  
  2380. Compared to previous versions of OS/2, DOS applications running in VDMs may: 
  2381.  
  2382.  Run full-screen or in a window 
  2383.  Run in a background session and not be suspended 
  2384.  Use the clipboard 
  2385.  
  2386.    - Copy text 
  2387.    - Copy graphics as bitmaps 
  2388.  
  2389.  Run graphics in full-screen mode 
  2390.  Switch between full-screen and windowed mode 
  2391.  Use LIM EMS Version 4.0 expanded memory services 
  2392.  Use LIMA XMS Version 2.0 extended memory services. 
  2393.  
  2394. Full-screen graphics applications may be switched to windowed mode where the 
  2395. graphics will be displayed as a bitmap. Switching between modes can be done via 
  2396. the system icon menu when in windowed mode. If in full-screen mode, the user 
  2397. must first switch to the Presentation Manager screen group. Selecting Windowed 
  2398. in the menu of the DOS program icon switches the application to windowed mode. 
  2399. To facilitate mode switching, the hot-key combination Alt+Home may be used. 
  2400.  
  2401. While in full-screen mode, the user may copy only the entire contents of the 
  2402. screen to the clipboard. Switching to windowed mode enables the user to copy 
  2403. parts of the screen to the clipboard by selecting areas with the mouse. 
  2404.  
  2405. DOS compatibility is achieved through a combination of hardware and software 
  2406. which ensure the successful execution of DOS applications. Since DOS 
  2407. compatibility is something of a "moving target", MVDM has been architected to 
  2408. provide the maximum possible flexibility. When attempting to ensure the proper 
  2409. execution of a DOS application, typical variable factors to be considered are 
  2410. the hardware and ROM BIOS of the machine, as well as DOS and the application 
  2411. itself. 
  2412.  
  2413.      DOS Operating System
  2414.    + Hardware
  2415.    + DOS Application
  2416.    ----------------------
  2417.    = Compatibility
  2418.  
  2419. The following DOS functions are supported by virtual DOS machines: 
  2420.  
  2421.  All documented DOS system interfaces 
  2422.  
  2423.  Most direct ROM BIOS interfaces 
  2424.  
  2425.  Memory extenders 
  2426.  
  2427.    - LIM EMS Version 4.0 
  2428.    - LIMA XMS Version 2.0 
  2429.  
  2430.  Direct manipulation of common hardware devices. 
  2431.  
  2432. VDMs have certain restrictions: 
  2433.  
  2434.  Single tasking only; no child processes 
  2435.  No active background graphics 
  2436.  No DOS block device drivers; such device drivers are not written for a 
  2437.   multitasking environment, and may compromise the integrity of other VDMs, or 
  2438.   of other processes in the system. 
  2439.  No direct manipulation of hard disk data (that is, bypassing, in this case, 
  2440.   the OS/2 file system); this may also compromise the integrity of other 
  2441.   processes in the system. 
  2442.  No DOS network device drivers, due to differences in the internal 
  2443.   implementation of DOS I/O.  However, DOS applications running in VDMs may 
  2444.   access LAN resources through the normal OS/2 network drivers, and therefore 
  2445.   no function is lost. 
  2446.  
  2447. Figure "MVDM System Structure and Control Flow" provides an overview of the 
  2448. OS/2 Version 2.0 system structure, showing the MVDM kernel and virtual device 
  2449. drivers in relation to key components of the operating system kernel and 
  2450. physical device drivers which provide services to MVDM. 
  2451.  
  2452. Note that virtual device drivers typically access hardware devices through a 
  2453. physical device driver. Direct communication between virtual device drivers and 
  2454. the hardware (as shown in Figure "MVDM System Structure and Control Flow") is 
  2455. used only in exceptional circumstances. One such case is the virtual video 
  2456. device driver, VVIDEO.SYS, which communicates directly with hardware in order 
  2457. to achieve the highest possible level of performance. 
  2458.  
  2459.  
  2460. ΓòÉΓòÉΓòÉ 12.2. Virtual DOS Machine Manager (VDMM) ΓòÉΓòÉΓòÉ
  2461.  
  2462. OS/2 Version 2.0 enables the user to start multiple DOS applications in 
  2463. multiple concurrent VDMs, all of which are controlled by the Virtual DOS 
  2464. Machine Manager (VDMM). 
  2465.  
  2466. Figure "MVDM Protected Mode processes" 
  2467.  
  2468. The VDMM creates a VDM by: 
  2469.  
  2470.  1. Allocating and mapping the required memory 
  2471.  
  2472.  2. Loading and initializing the virtual device drivers required to virtualize 
  2473.     the hardware and ROM BIOS 
  2474.  
  2475.  3. Access to the virtual device helper services and system resources, such as 
  2476.     memory, semaphores, timers, and files, is provided by the VDMM for all 
  2477.     VDMs. 
  2478.  
  2479. Figure "VDM Exception Handling" 
  2480.  
  2481. The VDMM is responsible for handling those 8086 instructions which cannot be 
  2482. executed in V86 mode, such as interrupts. Such instructions cause an exception 
  2483. to be generated by the 80386 processor; this exception is passed to an 
  2484. exception handler within the operating system, which checks the VM bit in the 
  2485. current process's EFLAGs control area. If the VM bit is set, control is passed 
  2486. to the VDMM. The VDMM therefore runs as a protected mode system level process 
  2487. at privilege level 0. 
  2488.  
  2489.  
  2490. ΓòÉΓòÉΓòÉ 12.2.1. VDM Address Space Management ΓòÉΓòÉΓòÉ
  2491.  
  2492. At initialization, each VDM has a linear address space of 4MB, because a single 
  2493. page table is assigned for each VDM. The page table itself is a single 4KB 
  2494. page, and can hold a maximum of 1024 page table entries. Each of these entries 
  2495. is a doubleword and points to a page with a size of 4KB, hence the 4MB size of 
  2496. the initial address space. The size of the address space can be expanded beyond 
  2497. 4MB if required; for instance, an application running in the VDM may request 
  2498. the allocation of a large amount of expanded memory, in which case the VDMM 
  2499. will allocate the memory as needed. 
  2500.  
  2501. Note that when memory is allocated OS/2 V2.0 merely reserves a linear address 
  2502. range. The range is not backed by physical memory until the memory is 
  2503. committed. Memory  may not actually be committed until a later time, and it may 
  2504. be committed in portions. Allocation without commitment does not use any 
  2505. physical memory and therefore does not waste resources. 
  2506.  
  2507. A typical VDM address space map is shown in Figure "Typical VDM Address Space 
  2508. Map". 
  2509.  
  2510. Each VDM task executes in the first megabyte of the linear address space, 
  2511. thereby allowing the physical addresses used within the DOS applications to be 
  2512. mapped directly to the process address space of the VDM. DOS system areas such 
  2513. as the ROM BIOS area and the Interrupt Vector table, are mapped from physical 
  2514. memory into the VDM's address space by the virtual device driver VBIOS.SYS. 
  2515.  
  2516. Page 0 contains, for example, the ROM BIOS area, the Interrupt Vector table, 
  2517. and the DOS communication area. ROM areas used by hardware devices are mapped 
  2518. by the virtual device drivers into the linear address space of the VDM. The 
  2519. same applies to other linear memory objects, such as EMS objects and display 
  2520. memory. 
  2521.  
  2522. A virtual device driver uses the VDHQueryFreePages() device helper service to 
  2523. find a region where no memory in the linear address space has been allocated or 
  2524. mapped. If a free region is found, the VDHReservePages() service is used to 
  2525. reserve the memory region. Mapping cannot take place where memory has already 
  2526. been allocated. On the other hand, memory may not be allocated where mappings 
  2527. already exist. The operating system's memory manager takes care of this. Page 
  2528. faults are generated if a process attempts to access memory which has 
  2529. previously been invalidated because it was unmapped, or if the page has been 
  2530. swapped out to disk. 
  2531.  
  2532. The 64KB memory area above 1MB (also known as the high memory area) must be 
  2533. treated in a special way. This is described in further detail in A20 Line 
  2534. Service (64KB Wraparound) and in High Memory Area (HMA). 
  2535.  
  2536.  
  2537. ΓòÉΓòÉΓòÉ 12.2.2. VDM Creation ΓòÉΓòÉΓòÉ
  2538.  
  2539. A number of tasks are performed when a VDM is initialized. The four main tasks 
  2540. managed by the Virtual DOS Machine Manager are: 
  2541.  
  2542.  1. Task state segment (TSS) initialization 
  2543.  
  2544.  2. Virtual DOS machine process initialization 
  2545.  
  2546.  3. 8086 Emulation initialization 
  2547.  
  2548.  4. DOS Emulation initialization. 
  2549.  
  2550. Task State Segment Initialization 
  2551.  
  2552. The task state segment describes the current machine state, including CPU 
  2553. register contents, and the current software state of a task, such as file 
  2554. descriptors and priority information. The following steps are necessary to 
  2555. initialize the TSS: 
  2556.  
  2557. Figure "VDM Initialization" 
  2558.  
  2559.  1. The VM bit in EFLAGS is set to 1, indicating that the process is a virtual 
  2560.     DOS machine. 
  2561.  
  2562.  2. The IOPL indicator in EFLAGS is set to 3 
  2563.  
  2564.  3. The instruction pointer is set to the task's entry point 
  2565.  
  2566.  4. The code segment (CS) register is set to the linear base address of the 
  2567.     task's initial code segment 
  2568.  
  2569.  5. An LDT is not used in V86 mode, but one must be initialized since interrupt 
  2570.     or exception routines might use an LDT 
  2571.  
  2572.  6. I/O access rights are defined in the I/O permission map. 
  2573.  
  2574. VDM Process Initialization 
  2575.  
  2576. The VDM process initialization is very similar to the creation of a protected 
  2577. mode session: 
  2578.  
  2579.  1. The Per-Task Data Area (PTDA) is created 
  2580.  
  2581.  2. A process slot and a process ID are allocated 
  2582.  
  2583.  3. The operating system's memory manager provides a 4MB linear address space 
  2584.  
  2585.  4. A 4MB global Page Directory Entry, which references the 4MB linear space, 
  2586.     is created 
  2587.  
  2588.  5. The VDM process is started. 
  2589.  
  2590. 8086 Emulation (V86) Initialization 
  2591.  
  2592. The 8086 Emulation initialization then proceeds as follows: 
  2593.  
  2594.  1. The 8086 Emulation code is loaded 
  2595.  
  2596.  2. VDM kernel data is allocated in per-VDM memory below 4MB 
  2597.  
  2598.  3. Virtual device driver instance data is allocated in per-VDM memory below 
  2599.     4MB 
  2600.  
  2601.  4. All known VDM creation hooks (registered by VDHInstallUserHook) are invoked 
  2602.     to initialize virtual device drivers on a per-VDM basis 
  2603.  
  2604.  5. The VEMM (expanded memory) virtual device driver (if used) allocates a 
  2605.     block of memory in a mappable window either between 640KB and 1MB or in the 
  2606.     area between 256KB and RMSIZE (as specified in CONFIG.SYS), and maps it 
  2607.     into the VDM address space. 
  2608.  
  2609. DOS Emulation Initialization 
  2610.  
  2611. The DOS Emulation initialization then proceeds as follows: 
  2612.  
  2613.  1. VDM-related kernel structures are initialized 
  2614.  
  2615.  2. DOS Emulation kernel (DOSKRNL) is loaded 
  2616.  
  2617.  3. Virtual processor mode is started 
  2618.  
  2619.  4. Standard file handles are opened 
  2620.  
  2621.  5. Virtual device driver and DOS device driver "stubs" are initialized 
  2622.  
  2623.  6. DOS device drivers are initialized 
  2624.  
  2625.  7. DOS shell is loaded and executed. 
  2626.  
  2627. DOS Emulation initialization and VDM creation are discussed in greater detail 
  2628. in MVDM DOS Emulation. 
  2629.  
  2630. Once DOS Emulation is complete, the Virtual DOS Machine Manager then issues the 
  2631. VDM_CREATE_DONE event handler to install default I/O hooks, page fault hooks, 
  2632. or INT hooks. Control is then passed to the DOS Emulation kernel to initialize 
  2633. and start the user application program. 
  2634.  
  2635. Once the VDM creation process is complete, the name of the DOS program and 
  2636. other customization parameters are passed to the new VDM. Customization 
  2637. parameters for a specific DOS application can be specified in the Workplace 
  2638. Shell folder in which the name of the DOS program is contained. To change these 
  2639. parameters select the DOS Settings pushbutton. 
  2640.  
  2641. DOS Settings allow the user to tune the VDM environment in which a DOS 
  2642. application runs in order to achieve optimal execution of the program. 
  2643.  
  2644.  
  2645. ΓòÉΓòÉΓòÉ 12.2.3. VDM Termination ΓòÉΓòÉΓòÉ
  2646.  
  2647. A VDM is terminated when the DOS application running within it terminates, or 
  2648. when a virtual device driver terminates the VDM due to some illegal operation. 
  2649. Termination is carried out in the following way: 
  2650.  
  2651.  1. All registered VDM termination hooks are called 
  2652.  
  2653.  2. The 8086 emulation releases all its per-VDM resources 
  2654.  
  2655.  3. The VDMM releases all its per-VDM resources 
  2656.  
  2657.  4. The VDM is destroyed in a way similar to an OS/2 process. 
  2658.  
  2659. The criteria for abnormal termination of a VDM by a virtual device driver are 
  2660. discussed in VDM Termination. 
  2661.  
  2662.  
  2663. ΓòÉΓòÉΓòÉ 12.3. 8086 Emulation ΓòÉΓòÉΓòÉ
  2664.  
  2665. OS/2 Version 2.0 MVDM 8086 Emulation provides "pure" 8086 emulation support for 
  2666. the V86 mode of the Intel 80386 SX and DX processors. [The Intel 80486 SX and 
  2667. DX processors also provide a compatible V86 mode, and are therefore supported 
  2668. by MVDM.] In a native 8086 processor environment, an application can access all 
  2669. available memory up to 1MB and can execute all 8086 processor instructions when 
  2670. running as a single task in an unprotected environment. However, virtual DOS 
  2671. machines run only in protected mode, and an application running in the V86 mode 
  2672. environment therefore has limited access to system memory and cannot execute 
  2673. all CPU instructions; only the OS/2 Version 2.0 operating system itself has 
  2674. full access to memory and the processor. 
  2675.  
  2676. Each VDM runs as a single V86 mode process, emulating all DOS operating system 
  2677. functions and providing a compatible DOS environment unaffected by other VDMs 
  2678. in the system. In the VDM environment, therefore, an application behaves as if 
  2679. it has complete control over system processor and memory resources. In this 
  2680. way, full application function is provided while preserving the integrity of 
  2681. other applications and of the system as a whole. 
  2682.  
  2683. The 8086 Emulation component provides the following: 
  2684.  
  2685.  Software interrupt reflection support 
  2686.  IOPL sensitive instruction emulation support 
  2687.  I/O port trapping 
  2688.  I/O simulation support 
  2689.  Context hook services 
  2690.  Hook software interrupt virtual device driver service 
  2691.  Change VDM execution flow services. 
  2692.  
  2693. 8086 Emulation is described in more detail in 8086 Emulation. 
  2694.  
  2695. Note that the 8086 Emulation component does not provide DOS or 
  2696. hardware-specific emulation. These emulations are provided by the DOS Emulation 
  2697. component (described in more detail below and in MVDM DOS Emulation) and 
  2698. virtual device drivers (described in more detail below and in Device Drivers) 
  2699. respectively. 
  2700.  
  2701.  
  2702. ΓòÉΓòÉΓòÉ 12.4. DOS Emulation ΓòÉΓòÉΓòÉ
  2703.  
  2704. Provision of DOS compatibility requires a combination of hardware, operating 
  2705. system, and application software support. The MVDM DOS Emulation component of 
  2706. OS/2 Version 2.0 addresses only the software aspects of providing DOS 
  2707. compatibility; the VDM Manager, 8086 Emulation and virtual device drivers work 
  2708. together to provide hardware and ROM BIOS compatibility. 
  2709.  
  2710. DOS Emulation provides DOS services to DOS applications running in a virtual 
  2711. DOS machine in such a way as to provide maximum compatibility with the same 
  2712. services provided to DOS applications running under native DOS 5.0. 
  2713.  
  2714. DOS Emulation is implemented by running a very small portion of the DOS 
  2715. Emulation kernel in V86 mode and a much larger portion of code in protected 
  2716. mode outside the VDM. In OS/2 Version 2.0, physical device drivers are loaded 
  2717. above 1MB and only the DOS Emulation kernel resides below 1MB; hence, any 
  2718. user-installed OS/2 device drivers will not affect the amount of application 
  2719. space available to a DOS application running in a VDM. Similarly, adding LAN 
  2720. drivers to the OS/2 configuration to support the network server or redirector 
  2721. functions does not take up DOS application space, even though DOS applications 
  2722. may make use of these network devices. Virtual device drivers are also loaded 
  2723. outside the VDM  address space, and therefore do not reduce the amount of 
  2724. memory available to a DOS application. 
  2725.  
  2726. In this way, the MVDM architecture makes available to DOS applications the 
  2727. maximum amount of memory. In fact, up to 630KB is free for multiple DOS 
  2728. sessions; this represents an increase of about 100KB over memory available to 
  2729. the single DOS session that was available under OS/2 Version 1.3. Note that 
  2730. this amount may be reduced if DOS device drivers and/or TSR programs are loaded 
  2731. in a VDM. 
  2732.  
  2733. DOS Emulation supports all documented DOS interrupts and features. In addition, 
  2734. some undocumented aspects of these functions (especially INT 21h) are supported 
  2735. because a large number of significant DOS applications rely upon these 
  2736. interfaces. 
  2737.  
  2738. DOS Emulation is described in more detail in MVDM DOS Emulation. 
  2739.  
  2740.  
  2741. ΓòÉΓòÉΓòÉ 12.5. Virtual Device Drivers ΓòÉΓòÉΓòÉ
  2742.  
  2743. Virtual device drivers are installable modules responsible for virtualizing the 
  2744. hardware and ROM BIOS aspects of the DOS environment for virtual DOS machines. 
  2745. A virtual device driver manages shared access to hardware I/O devices for 
  2746. multiple VDMs, allowing an application running in a VDM to act as though it 
  2747. exercised sole control over I/O devices. See also Figure "MVDM System Structure 
  2748. Overview". 
  2749.  
  2750. Virtual device drivers are implemented whenever possible, allowing the BIOS in 
  2751. the system to perform its functions without interference from DOS applications. 
  2752. Virtual device drivers are used to control hardware, such as the keyboard, 
  2753. mouse, and serial and parallel ports. 
  2754.  
  2755. The virtual device driver architecture implemented in OS/2 Version 2.0 provides 
  2756. compatible support for all standard hardware utilized by DOS applications and 
  2757. supports installable virtualization, allowing new hardware to be added in the 
  2758. field and supported by VDMs without requiring an upgrade to the operating 
  2759. system. 
  2760.  
  2761. Virtual device drivers are responsible for the following functions: 
  2762.  
  2763.  Maintaining a virtual hardware state for each virtual DOS machine (VDM) 
  2764.  
  2765.  Preventing a VDM from corrupting the state of another VDM, or the system as a 
  2766.   whole 
  2767.  
  2768.  Supporting fast screen I/O 
  2769.  
  2770.  Supporting fast communications I/O. 
  2771.  
  2772. Since DOS may be emulated more than once in OS/2 Version 2.0, virtual device 
  2773. drivers must virtualize the following features to maintain a separate hardware 
  2774. state for each VDM: 
  2775.  
  2776.  ROM BIOS services 
  2777.  Direct manipulation of ROM BIOS data area 
  2778.  Direct manipulation of video RAM 
  2779.  Direct programming of I/O ports 
  2780.  Direct manipulation of device memory 
  2781.  Hardware interrupts 
  2782.  Software interrupts. 
  2783.  
  2784. A virtual device driver typically performs I/O through a physical device 
  2785. driver, using a direct call interface.  However, a virtual device driver may 
  2786. directly access an I/O control device; this technique is used by the virtual 
  2787. video device driver, VVIDEO.SYS, for performance reasons. A virtual device 
  2788. driver may simulate hardware interrupts into one or many VDM processes. 
  2789.  
  2790. Virtual device drivers use a minimal amount of memory. Virtual device drivers 
  2791. do not have to reserve arrays of data structures for each VDM (as did device 
  2792. drivers under previous versions of OS/2). They may be made swappable, so that 
  2793. each device driver does not increase the amount of conventional (or real) 
  2794. memory space consumed. Conventional memory is used only for code and data that 
  2795. must be accessible at hardware interrupt time (for example, when calling a 
  2796. physical device driver). 
  2797.  
  2798. Under OS/2 Version 2.0, a virtual device driver is inherently protected from a 
  2799. VDM because it is not visible in the VDM address space, although the device 
  2800. driver must be careful to check all parameters coming in from a VDM to ensure 
  2801. that it does not damage itself or some other part of the system by executing an 
  2802. invalid instruction. 
  2803.  
  2804. Virtual device drivers obtain and release system resources via the Virtual 
  2805. Device Helper (VDH) services provided by the MVDM kernel. These helper services 
  2806. are accessed via a published programming interface so that manufacturers of 
  2807. hardware devices may develop virtual device drivers for their own devices. 
  2808. Virtual device drivers are installed using the DEVICE= statement in CONFIG.SYS. 
  2809.  
  2810. Note that a virtual device is required only if a device will be shared with 
  2811. other virtual DOS machines. If a particular device is to be used exclusively by 
  2812. one DOS application, a normal DOS device driver (that is, one that is written 
  2813. for DOS) may be used, and a virtual device driver is not required. 
  2814.  
  2815.  
  2816. ΓòÉΓòÉΓòÉ 12.6. VDM Page Faults ΓòÉΓòÉΓòÉ
  2817.  
  2818. A page fault exception may occur in a VDM where a particular page in real 
  2819. memory has been swapped to disk. When a page fault occurs for a linear region 
  2820. which has been initialized as an alias by a virtual device driver, the 
  2821. exception is routed to an exception handler, which has been registered 
  2822. previously by the virtual device driver for the linear address region in which 
  2823. the page fault occurred. The exception handler may cause the page to be loaded 
  2824. or may allow the memory reference to default into a temporary data page, 
  2825. several of which are provided by the MVDM kernel at initialization time. 
  2826.  
  2827. Exception handlers are registered by virtual device drivers at initialization 
  2828. time using the VDHInstallFaultHook() helper function. If no exception handler 
  2829. is registered for the linear region in which the page fault occurred, the page 
  2830. is mapped to temporary data pages in memory. 
  2831.  
  2832. The start address and size of each aliased region, and the exception handler 
  2833. address for each aliased region, is kept in a table, which is set up via the 
  2834. VDHInstallFaultHook() helper service. When a page fault occurs in the VDM 
  2835. address space, this table is searched for a matching region, and the exception 
  2836. handler for that address is called. The page address and the type of fault 
  2837. which occurred are passed to the exception handler. 
  2838.  
  2839.  
  2840. ΓòÉΓòÉΓòÉ 12.7. VDM Window Management ΓòÉΓòÉΓòÉ
  2841.  
  2842. OS/2 Version 2.0 provides for the ability to run a V86 task in a window. The 
  2843. PMShield manages windowed VIO sessions input/output and windowed VDM 
  2844. input/output. 
  2845.  
  2846. The video VDD (Virtual Device Driver) intercepts all I/O instructions to the 
  2847. video adapter, and all screen updates will be redirected/mapped to a logical 
  2848. video buffer (LVB) maintained by the Video VDD. When the Video VDD detects 
  2849. changes in a VDM's video state, it notifies a new PMShield thread, providing it 
  2850. with update information for a specified VDM window. This thread is a 
  2851. high-priority thread that serves the needs of all windowed VDMs. 
  2852.  
  2853. For keyboard and mouse input, the PMShield must simply transform keystroke and 
  2854. mouse event messages into calls to the keyboard and mouse VDDs. 
  2855.  
  2856.  
  2857. ΓòÉΓòÉΓòÉ 12.7.1. Virtual Display Management ΓòÉΓòÉΓòÉ
  2858.  
  2859. Figure "Virtual Display Management" 
  2860.  
  2861. The PMShield is notified by the Video VDD of different changes, which are 
  2862. prioritized, for example "change in video mode", "change in palette", "change 
  2863. in LVB", "scroll of LVB", "string output", "change in cursor", "input 
  2864. notification" when the window scroll has to be adjusted based on the cursor 
  2865. position, "paste notification". 
  2866.  
  2867. Having received notification of one of these changes, it is the PMShield's 
  2868. responsibility to make appropriate changes to the VDM window, usually through 
  2869. the use of one or more PM Graphics Engine call(s). 
  2870.  
  2871. When a windowed VDM is found with a dirty page, the PMShield thread is notified 
  2872. of a LVB change, along with rectangles describing which areas of the VDM's LVB 
  2873. may be dirty. The PMShield finds the smallest rectangle(s) of change, and 
  2874. updates the window using appropriate Graphics Engine services. 
  2875.  
  2876. The PMShield obtains access to the VDM's LVB indirectly, by requesting the 
  2877. Video VDD to copy some rectangular portion of it into a "shield buffer". The 
  2878. PMShield compares the "shield buffer" against a "shadow buffer", which contains 
  2879. the previously displayed contents of the VDM window, to find the smallest areas 
  2880. of change. The roles of the two buffers are then interchanged in preparation 
  2881. for the next update, as it is now the "shield buffer", which contains the last 
  2882. data displayed. 
  2883.  
  2884. If the VDM changes video modes before the PMShield is able to copy the VDM's 
  2885. LVB, an error will be returned to the PMShield on the copy request. The 
  2886. PMShield's action will be to query the new mode and recopy the LVB. 
  2887.  
  2888.  
  2889. ΓòÉΓòÉΓòÉ 12.7.2. Virtual Keyboard Management ΓòÉΓòÉΓòÉ
  2890.  
  2891. Figure "Virtual Keyboard Management" 
  2892.  
  2893. The PMShield transforms keystroke messages into calls to the Keyboard VDD. No 
  2894. buffering by the PMShield is necessary, since the Keyboard VDD already 
  2895. maintains its own virtual keyboard buffer. 
  2896.  
  2897. The only keystrokes that require special handling by the PMShield are those 
  2898. that affect shift states. 
  2899.  
  2900. There are two operations that a VDM can perform on its virtual keyboard: 
  2901.  
  2902.  Change repeat rate 
  2903.  
  2904.  Change shift states. 
  2905.  
  2906. When a VDM changes the repeat rate, whether it is in the foreground, background 
  2907. or windowed at that time, the repeat rate is changed for the whole system. 
  2908. Since the repeat rate is not a per-session attribute under OS/2, the PMShield 
  2909. need not be involved. The shift state information is per-VDM and is managed by 
  2910. the Keyboard VDD, in conjunction with the physical keyboard driver. 
  2911.  
  2912.  
  2913. ΓòÉΓòÉΓòÉ 12.7.3. Virtual Mouse Management ΓòÉΓòÉΓòÉ
  2914.  
  2915. Figure "Virtual Mouse Management" 
  2916.  
  2917. For mouse input, the PMShield will transform mouse event messages into calls to 
  2918. the Mouse VDD. The conversation will require a mapping of the physical mouse 
  2919. position reported by Presentation Manager to a corresponding position within 
  2920. the VDM's screen dimensions. 
  2921.  
  2922. A VDM can change the state of its virtual pointer in various ways: 
  2923.  
  2924.  Change pointer position 
  2925.  
  2926.  Change pointer shape 
  2927.  
  2928.  Change pointer scaling factors. 
  2929.  
  2930. These special changes are of no interest to PMShield. 
  2931.  
  2932.  
  2933. ΓòÉΓòÉΓòÉ 12.8. VDM Interprocess Communication ΓòÉΓòÉΓòÉ
  2934.  
  2935. Communication between processes is valuable in a multitasking operating system 
  2936. to enable concurrent processes to work together.  Pipes are one of three forms 
  2937. within OS/2 of interprocess communication (IPC) and the only form available for 
  2938. IPC from a DOS application running in a VDM to an OS/2 application. 
  2939.  
  2940. This chapter describes how to create, manage, and use named pipes for IPC of a 
  2941. DOS application in a VDM to an OS/2 program. Pipes enable two or more processes 
  2942. to communicate as if they were reading from and writing to a file. 
  2943.  
  2944.  
  2945. ΓòÉΓòÉΓòÉ 12.8.1. About Pipes ΓòÉΓòÉΓòÉ
  2946.  
  2947. A pipe is a named or unnamed buffer used to pass data between processes. A 
  2948. process writes to or reads from a pipe as if the pipe were standard input or 
  2949. standard output.  A parent process can use pipes to control the input that a 
  2950. child process receives and to receive the output that the child process 
  2951. produces. There are two types of pipes - named and unnamed. The only supported 
  2952. pipe to be used between a DOS application in a VDM and an OS/2 program is the 
  2953. named pipe. 
  2954.  
  2955.  
  2956. ΓòÉΓòÉΓòÉ 12.8.2. Named Pipes ΓòÉΓòÉΓòÉ
  2957.  
  2958. Named pipes enable related or unrelated processes on the same computer system 
  2959. or different systems to communicate with each other. Any process that knows the 
  2960. name of a pipe can open and use a named pipe. In addition, named pipe data can 
  2961. be transparently redirected across a network, such as a local area network 
  2962. (LAN). 
  2963.  
  2964. Note:   The current file system implementation for VDMs does not support named 
  2965.         pipes across the LAN. (This limitation will go away with future 
  2966.         versions of OS/2 V2.0). To use named pipes within a VDM and across the 
  2967.         LAN, you would have to boot a real DOS session (see also Virtual 
  2968.         Machine Boot). You would also have to load the LAN Support Program and 
  2969.         the DOS LAN Requestor within such a VMBOOT session. If you do that, 
  2970.         your network adapter will be used by that DOS session exclusively and 
  2971.         cannot be shared with any other session on this machine. 
  2972.  
  2973. One process (server process) creates the pipe and connects to one end of it. 
  2974. Other processes that access the named pipe are called client processes; they 
  2975. connect to the other end of the pipe.  The server and client processes can then 
  2976. pass data back and forth by reading from and writing to the pipe.  The server 
  2977. process controls access to the named pipe. 
  2978.  
  2979. The client process can be either local or remote.  A local client process is 
  2980. one that runs on the same computer system as the server process.  A remote 
  2981. client process runs on a different system and communicates with the server 
  2982. process across a local area network (LAN). 
  2983.  
  2984. The DOS applications running in different VDMs can only work as client 
  2985. processes. The OS/2 application for this kind of IPC has to be the server 
  2986. process. That is because there are no equivalent pipe APIs in DOS to create a 
  2987. named pipe, etc. there are only the standard I/O commands. This means that the 
  2988. DOS client process can read and write from and to the pipe, but it cannot 
  2989. create one.  To do this the DOS client has to know the name of the named pipe 
  2990. to be able to use it like it would use a flat file to open it and process the 
  2991. I/O calls. 
  2992.  
  2993. There is an exercise included in the appendixes that demonstrates a VDM IPC and 
  2994. shows you the sample code (see Lab Session 5: VDM Interprocess Communications 
  2995. for more information). 
  2996.  
  2997.  
  2998. ΓòÉΓòÉΓòÉ 12.9. Summary ΓòÉΓòÉΓòÉ
  2999.  
  3000. MVDM is composed of four major components: 
  3001.  
  3002.  1. The Virtual DOS Machine Manager is responsible for creating and 
  3003.     initializing VDMs. 
  3004.  
  3005.  2. 8086 Emulation provides an emulation of the 8086 hardware environment, 
  3006.     supporting actions such as direct hardware manipulation and hardware 
  3007.     interrupts. 
  3008.  
  3009.  3. DOS Emulation provides an emulation of the DOS operating system 
  3010.     environment, supporting actions such as software interrupts and INT 21h 
  3011.     services. 
  3012.  
  3013.  4. Virtual device drivers provide virtualization of hardware devices, allowing 
  3014.     these devices to appear to a DOS application as though the application has 
  3015.     direct control over the device.  Devices may thus be shared by multiple DOS 
  3016.     applications and/or protected mode (OS/2) applications. 
  3017.  
  3018. These components operate in conjunction with the hardware and the OS/2 Version 
  3019. 2.0 operating system kernel to provide support for DOS applications under OS/2 
  3020. Version 2.0. 
  3021.  
  3022. MVDM allows OS/2 Version 2.0 to exploit the capabilities of the virtual 8086 
  3023. mode of the 80386 processor. MVDM provides the capability to run multiple 
  3024. concurrent DOS applications in virtual DOS machines. Since each VDM is a 
  3025. protected mode task, MVDM provides pre-emptive multitasking and full memory 
  3026. protection for DOS applications, protecting other applications in the system 
  3027. and the operating system itself from interference by an ill-behaved 
  3028. application. Executing VDMs in protected mode (as opposed to real mode) also 
  3029. improves the performance of DOS applications, since the processor is never 
  3030. required to switch to real mode. 
  3031.  
  3032. Each VDM executes in its own 4MB protected mode address space, with the DOS 
  3033. application having access to the lower 1MB of the linear address space. The 
  3034. remainder of the space is occupied by the MVDM code, device drivers, and 
  3035. extended or expanded memory objects. VDMs may run in window or full-screen 
  3036. mode, and a user can dynamically switch between the two. 
  3037.  
  3038. All documented DOS system interfaces, most direct ROM BIOS interfaces, and 
  3039. memory extenders, such as LIM EMS Version 4.0 and LIMA XMS Version 2.0, are 
  3040. supported by the MVDM  architecture. Direct manipulation of common hardware 
  3041. devices is also supported by MVDM. In addition, certain undocumented but 
  3042. commonly used INT 21h services are supported. DOS Emulation provides DOS 5.0 
  3043. compatible support. 
  3044.  
  3045.  
  3046. ΓòÉΓòÉΓòÉ 13. 8086 Emulation ΓòÉΓòÉΓòÉ
  3047.  
  3048. A significant capability of the Intel 80386 and 80486 processor families is 
  3049. their ability to emulate the Intel 8086 processor.  This emulated state is 
  3050. known as virtual 8086 (V86) mode.  The Multiple Virtual DOS Machines component 
  3051. of OS/2 Version 2.0 makes use of this mode to provide emulation of a native DOS 
  3052. environment for applications executing in virtual DOS machines.  The 8086 
  3053. processor hardware emulation is provided by the 8086 Emulation component of 
  3054. MVDM. Other aspects of the DOS environment, such as program loading and 
  3055. execution and device driver support, are provided by the DOS Emulation 
  3056. component, which is described in MVDM DOS Emulation, and by virtual device 
  3057. drivers, described in Device Drivers. 
  3058.  
  3059. This chapter provides an overview of V86 mode, and describes the operation of 
  3060. the 8086 Emulation component. 
  3061.  
  3062.  
  3063. ΓòÉΓòÉΓòÉ 13.1. Virtual 8086 Mode ΓòÉΓòÉΓòÉ
  3064.  
  3065. In a native 8086 environment, the processor does not constrain an application 
  3066. in any way.  The application may access all available memory and execute all 
  3067. processor instructions, since it is running as a single task in an unprotected, 
  3068. real mode environment.  Operating systems and applications written for the 8086 
  3069. (such as DOS) typically take advantage of this freedom to exercise direct 
  3070. control over hardware and system resources. 
  3071.  
  3072. The 80386 processor exhibits its best performance when running in protected 
  3073. mode.  However, in the protected mode environment, applications are restricted 
  3074. to a subset of the system memory and processor instruction set, and real mode 
  3075. applications written for the 8086 processor can violate the protection rules 
  3076. imposed by the processor. 
  3077.  
  3078. The virtual 8086 mode of the 80386 processor allows an operating system to 
  3079. integrate existing applications, written for the 8086 processor, into the 
  3080. protected mode multitasking environment of the 80386, and to execute such 
  3081. applications concurrently with other 8086 applications and protected mode 
  3082. applications. 
  3083.  
  3084. V86 mode tasks execute in the 80386 processor at privilege level 3, and are 
  3085. compatible with the virtual memory and paging facilities of the 80386.  A V86 
  3086. mode task may execute most 8086 instructions, including those which reference 
  3087. memory mapped or I/O mapped devices, or which access the 80386 interrupt enable 
  3088. flag.  These instructions may be executed by the 80386 processor directly, or 
  3089. the 80386 operating system may trap and emulate such instructions. 
  3090.  
  3091. Certain 8086 instructions may not be executed in V86 mode; these include 
  3092. instructions which generate interrupts or exceptions, some of which are not 
  3093. valid in a normal protected mode task.  However, such instructions may be valid 
  3094. for a V86 mode task.  For example, an application running in V86 mode may issue 
  3095. an interrupt 21h operating system call.  An 80386 operating system may register 
  3096. an exception handler to trap and emulate such instructions at a higher 
  3097. privilege level. 
  3098.  
  3099. Figure "VDM Exceptions and Interrupt Handling in a V86 Mode Task" 
  3100.  
  3101. An interrupt or exception in the V86 mode task causes the processor to switch 
  3102. from V86 mode to protected mode.  An exception handler running as a protected 
  3103. mode task at privilege level 0 is then invoked by the 80386 operating system. 
  3104. This handler first determines that the task which issued the interrupt or 
  3105. exception instruction is a valid V86 mode task.  It does this by checking the 
  3106. VM bit in the EFLAGS register.  Two possible states are possible: 
  3107.  
  3108.  If this bit is set, the current task is a V86 mode task.  The exception 
  3109.   handler then invokes a virtual machine monitor. 
  3110.  
  3111.   The virtual machine monitor locates the instruction which caused the 
  3112.   interrupt or exception, decodes the instruction and, if it is a valid 8086 
  3113.   instruction, simulates its execution by invoking appropriate 80386 operating 
  3114.   system services.  If the instruction is not valid (for example, a privileged 
  3115.   80386 instruction), the virtual machine monitor terminates the V86 mode task. 
  3116.  
  3117.  If the bit is not set, the task has issued an illegal instruction, and is 
  3118.   terminated by the virtual machine monitor. 
  3119.  
  3120. Once the instruction which caused the interrupt or exception has been 
  3121. processed, the virtual machine monitor transforms the result into the expected 
  3122. format for the V86 mode task.  It then advances the V86 mode task's EIP 
  3123. (Extended Instruction Pointer) to the next instruction, and issues an IRET 
  3124. instruction which causes the processor to switch back to V86 mode and continue 
  3125. execution of the V86 mode task. 
  3126.  
  3127. The 8086 Emulation component of MVDM is a virtual machine monitor. 
  3128.  
  3129.  
  3130. ΓòÉΓòÉΓòÉ 13.2. DOS Software Interrupt Handling ΓòÉΓòÉΓòÉ
  3131.  
  3132. Upon creation of a VDM, the IOPL field in the EFLAGS register within the VDM 
  3133. process's task state segment is set to 3.  This has two major effects: 
  3134.  
  3135.  It allows the VDM to access the interrupt enable flag (IF), thus permitting 
  3136.   compatibility with DOS applications which temporarily disable interrupts 
  3137.   while performing critical operations. 
  3138.  
  3139.  It means that an interrupt issued from a VDM does not necessarily cause a 
  3140.   general protection exception; certain interrupt handlers may execute at 
  3141.   privilege level 3 within the VDM. 
  3142.  
  3143. If the VDM process is running with IOPL < 3, every interrupt causes a general 
  3144. protection exception; in such cases the operating system would need to 
  3145. virtualize the interrupt at all times, and to emulate all IOPL-sensitive 
  3146. instructions (CLI, STI, LOCK, PUSHF, POPF, INT n, and IRET).  This would result 
  3147. in increased mode switching (between V86 and protected mode) and higher 
  3148. interrupt latency, and would therefore reduce performance. 
  3149.  
  3150. Thus, under OS/2 Version 2.0, a VDM runs with IOPL=3 for maximum performance. 
  3151. Interrupts are virtualized and, where possible, handled within the V86 mode 
  3152. task. 
  3153.  
  3154.  
  3155. ΓòÉΓòÉΓòÉ 13.2.1. Virtualizing Interrupts ΓòÉΓòÉΓòÉ
  3156.  
  3157. The behavior of 8086 Emulation in response to an interrupt is dependent upon 
  3158. the descriptor privilege level (DPL) field for the interrupt handler.  This is 
  3159. shown in Figure "Descriptor Privilege Levels". 
  3160.  
  3161. When a software interrupt occurs in a DOS application running in a VDM, the 
  3162. interrupt is vectored to an interrupt handler determined by an entry in the 
  3163. VDM's Interrupt Vector table.  This interrupt handler has its own descriptor 
  3164. privilege level (DPL).  If the DPL is 3, the interrupt handler code is simply 
  3165. executed, and control returns to the DOS application. 
  3166.  
  3167. If the DPL of the interrupt handler is less than 3, a general protection 
  3168. exception is generated by the processor and passed to the OS/2 Version 2.0 
  3169. kernel.  The general protection exception handler then determines that the 
  3170. exception occurred from a V86 mode task, and invokes 8086 Emulation to simulate 
  3171. execution of the interrupt handler.  Depending upon the type of interrupt, 8086 
  3172. Emulation may perform the emulation within itself, or call another component of 
  3173. MVDM to handle the emulation. 
  3174.  
  3175.  
  3176. ΓòÉΓòÉΓòÉ 13.2.2. Disabling Interrupts ΓòÉΓòÉΓòÉ
  3177.  
  3178. Disabling interrupts from within a DOS application running in a VDM may cause 
  3179. severe problems. If an error or program loop occurs while interrupts are 
  3180. disabled, the condition cannot be handled correctly and the system may crash. 
  3181.  
  3182. To prevent a DOS application running in V86 mode from disabling interrupts for 
  3183. an extended period of time, a hardware timer is provided by the 80386 processor 
  3184. known as the watchdog timer. Such lengthy disabling may cause unrecoverable 
  3185. system errors. The watchdog timer is programmable and generates non-maskable 
  3186. interrupts (NM) after a specified period of time which allow an operating 
  3187. system to detect an errant 8086 application and terminate it. OS/2 Version 2.0 
  3188. provides a hardware interrupt manager. This maintains a time counter for every 
  3189. VDM. All interrupts, except NMI, are checked by this hardware interrupt 
  3190. manager, which resets the time counter with every occurrence of an interrupt 
  3191. for the corresponding VDM. 
  3192.  
  3193. If a counter exceeds a predefined limit (a typical value is 60 milliseconds), 
  3194. interrupts are automatically re-enabled.  The Virtual DOS Machine Manager is 
  3195. notified of the ill-behaved application program, and will then terminate the 
  3196. VDM. 
  3197.  
  3198.  
  3199. ΓòÉΓòÉΓòÉ 13.3. I/O Port Trapping ΓòÉΓòÉΓòÉ
  3200.  
  3201. A DOS application running in a VDM may access I/O ports directly using the 
  3202. normal 8086 I/O instructions (such as, IN and OUT).  These instructions are not 
  3203. considered IOPL-sensitive and do not normally generate a general protection 
  3204. exception;  the operating system checks the I/O privilege map in the VDM's task 
  3205. state segment to determine whether to allow the instruction to execute or to 
  3206. generate a general protection exception.  This allows DOS applications to 
  3207. access hardware devices using the normal DOS device drivers from within a VDM. 
  3208.  
  3209. When access to a device must be shared with other applications, however, a 
  3210. virtual device driver is required, and the VDM may not directly access the I/O 
  3211. port. At initialization time, the virtual device driver issues a call to the 
  3212. VDHSetIOHookState() device helper function, which sets the appropriate bit in 
  3213. the I/O privilege map. 
  3214.  
  3215. When a DOS application subsequently issues an instruction for the I/O port: 
  3216.  
  3217.  1. A general protection exception is generated. 
  3218.  
  3219.  2. The operating system's exception handler routes the exception to 8086 
  3220.     Emulation. 
  3221.  
  3222.  3. 8086 emulation then invokes the virtual device driver. 
  3223.  
  3224.  
  3225. ΓòÉΓòÉΓòÉ 13.4. A20 Line Services (64KB Wraparound) ΓòÉΓòÉΓòÉ
  3226.  
  3227. The region from 1MB to 1MB+64KB is known as the A20 wrap area. Due to the 
  3228. segmented scheme for generating 20-bit physical addresses on an 8088, it is 
  3229. possible for a DOS program to generate physical addresses in the range from 1MB 
  3230. to 1MB + 64KB. On an 8088 system, these addresses wrap to the low 64KB of 
  3231. physical memory. 
  3232.  
  3233. In the 16-bit version of OS/2, OS/2 V1.x, 80286 physical addresses are 24 bits. 
  3234. The twenty-first address line of the 80286 is called the A20 line, and its 
  3235. setting determines whether real-mode programs wrap low physical memory, or 
  3236. directly access the range from 1MB to 1MB + 64KB. When an 80286 is started, the 
  3237. A20 line is disabled, causing the 80286 to emulate the 8088 environment. When 
  3238. the 80286 is switched to protected mode, the A20 line is enabled, since the 
  3239. protected mode of the 80286 generates 24-bit physical addresses. However, the 
  3240. A20 wrap area can be addressed in real mode in OS/2 V1.x if the A20 line is 
  3241. enabled manually. OS/2 V1.x can thus use the memory in the A20 wrap area for 
  3242. bimodal code (for example, OS/2 V1.x device drivers) by managing the state of 
  3243. the A20 line. When running a DOS application in real mode, OS/2 V1.x disables 
  3244. the A20 line to force the 8088 segment wrapping semantics on DOS applications. 
  3245. When accessing bimodal code in the range from 1MB to 1MB + 64KB in real mode, 
  3246. the OS/2 V1.x kernel enables the A20 line. 
  3247.  
  3248. In OS/2 V2.0 however, the area between 1MB and 1MB + 65519 bytes, cannot be 
  3249. accessed by a DOS program in V86 mode using 20 address lines (that is lines 0 
  3250. to 19). For example, addressing 1MB + 1 byte from within a DOS application in 
  3251. V86 mode would access physical memory at address 0;  in other words, the memory 
  3252. addressing would wrap around to access the extra byte of memory.  This is known 
  3253. as wraparound.  Under OS/2 Version 2.0, the addressing of memory beyond 1MB 
  3254. would result in an addressing exception because although address line 20 is 
  3255. activated, it is not valid for a V86 mode process. This is shown in Figure "A20 
  3256. Line Service (64KB Wraparound)". 
  3257.  
  3258. In order to avoid addressing exceptions in OS/2 Version 2.0, the wraparound 
  3259. feature must be simulated with aliased pages. The 1MB V86 address space 
  3260. requires a page table with 256 entries (256 x 4KB = 1MB).  Sixteen additional 
  3261. page table entries are used for the 65519 bytes above 1MB.  These 16 entries 
  3262. are identical to the first 16 entries for the 1MB area, thereby mapping the 
  3263. wraparound area to the address range 0 to 65519. 
  3264.  
  3265. The wraparound feature requires some additional housekeeping by the OS/2 
  3266. Version 2.0 kernel.  When an aliased page is swapped to disk, both page table 
  3267. entries must be flagged as not present. 
  3268.  
  3269.  
  3270. ΓòÉΓòÉΓòÉ 13.5. Summary ΓòÉΓòÉΓòÉ
  3271.  
  3272. The 8086 Emulation component makes use of the virtual 8086 mode of the 80386 
  3273. processor to provide an emulation of the 8086 hardware environment for DOS 
  3274. applications executing in virtual DOS machines.  Application instructions which 
  3275. cause interrupts or which cannot be executed in V86 mode are trapped by the 
  3276. OS/2 Version 2.0 operating system kernel and routed to 8086 Emulation, which 
  3277. may process the instruction within itself or re-route it to the appropriate 
  3278. component of MVDM. 
  3279.  
  3280. For maximum performance, not all interrupts are trapped and routed in this 
  3281. manner.  MVDM makes use of the IOPL field in the VDM process's task state 
  3282. segment, and the Descriptor Privilege Level (DPL) field in the interrupt 
  3283. handler's code segment, to allow certain interrupts to be processed in V86 
  3284. mode.  Only when the interrupt handler must execute at a higher privilege level 
  3285. are the interrupts trapped and routed by the operating system to 8086 
  3286. Emulation.  This improves performance by reducing the number of processor 
  3287. mode-switches required. 
  3288.  
  3289. 8086 Emulation also supports the use of the Intel 8086 64KB wraparound feature, 
  3290. allowing access to the 64KB of memory immediately above the 1MB address line. 
  3291. This capability is used by some DOS software such as the LIMA XMS memory 
  3292. extender, which implements its high memory area (HMA) in this region.  More 
  3293. detailed information regarding HMA can be found in Memory Extender Support. 
  3294.  
  3295.  
  3296. ΓòÉΓòÉΓòÉ 14. MVDM DOS Emulation ΓòÉΓòÉΓòÉ
  3297.  
  3298. MVDM DOS Emulation provides DOS services to applications running in Multiple 
  3299. Virtual DOS Machines. The environment provided is highly compatible with those 
  3300. same services that are provided to DOS applications running under native DOS 
  3301. 5.0. It addresses only DOS compatibility aspects; processor and other hardware 
  3302. aspects of the DOS environment are addressed by the 8086 Emulation component 
  3303. and virtual device drivers. 
  3304.  
  3305. This chapter describes the implementation of the DOS Emulation component, and 
  3306. the DOS software services provided to support DOS applications running in 
  3307. virtual DOS machines. 
  3308.  
  3309.  
  3310. ΓòÉΓòÉΓòÉ 14.1. DOS Emulation Overview ΓòÉΓòÉΓòÉ
  3311.  
  3312. DOS Emulation is implemented by running a very small portion of the DOS 
  3313. Emulation kernel in V86 mode and a much larger portion of this code in 
  3314. protected mode outside the VDM. In OS/2 Version 2.0, physical device drivers 
  3315. are loaded above 1MB and only the DOS Emulation kernel resides below 1MB. Any 
  3316. user-installed OS/2 device drivers will not affect the amount of application 
  3317. space available to a DOS application running in a virtual DOS machine. 
  3318. Similarly, adding LAN drivers to the OS/2 configuration to support a network 
  3319. server or redirector does not impact DOS application space, even though DOS 
  3320. applications may make use of these OS/2 network devices. Virtual device drivers 
  3321. are also loaded outside the VDM  address space, and therefore do not reduce the 
  3322. amount of memory available to a DOS application. 
  3323.  
  3324. In this way, the MVDM architecture makes the maximum amount of memory available 
  3325. to DOS applications. In fact, up to 630KB are free for use by DOS applications; 
  3326. this represents an increase of approximately 100KB over memory available to the 
  3327. single DOS session that was available under OS/2 Version 1.3. Note that this 
  3328. amount may be reduced if DOS device drivers and/or TSR programs are loaded in a 
  3329. VDM. The following DOS features are implemented by the DOS Emulation: 
  3330.  
  3331.  DOS console device driver 
  3332.  DOS device driver loading/support 
  3333.  DOS program loading and execution 
  3334.  DOS FCB I/O support 
  3335.  DOS memory manager 
  3336.  DOS NLS support 
  3337.  DOS PDB process support 
  3338.  VDM entering and exiting kernel mode support 
  3339.  Special DOS compatibility mechanisms. 
  3340.  
  3341. DOS Emulation supports all documented DOS interrupts and features. In addition, 
  3342. some undocumented aspects of these functions (especially INT 21h) are 
  3343. supported. This support is incorporated in the DOS Emulation  component because 
  3344. a large number of popular DOS applications rely upon these interfaces. 
  3345.  
  3346. The following list shows the documented DOS system interrupt services which are 
  3347. implemented by DOS Emulation and which are available to DOS applications 
  3348. running in VDMs: 
  3349.  
  3350. INT 20h               Program terminate interface 
  3351.  
  3352. INT 21h               System call interface 
  3353.  
  3354. INT 22h/INT 23h       Terminate and Ctrl-Break address interfaces 
  3355.  
  3356. INT 24h               Critical error handler interface 
  3357.  
  3358. INT 25h/INT 26h       Absolute disk read/write interfaces 
  3359.  
  3360. INT 27h               Terminate and stay resident (TSR) interface 
  3361.  
  3362. INT 28h               Idle loop interface 
  3363.  
  3364. INT 2Fh               Print spool interface. 
  3365.  
  3366. Other DOS compatibility functions are implemented by the 8086 Emulation 
  3367. component of MVDM, and by virtual device drivers. The functions provided by 
  3368. these components are explained in 8086 Emulation and in Device Drivers, 
  3369. respectively. 
  3370.  
  3371.  
  3372. ΓòÉΓòÉΓòÉ 14.2. DOS Emulation Implementation ΓòÉΓòÉΓòÉ
  3373.  
  3374. A primary design goal for MVDM and the DOS Emulation component was to provide a 
  3375. DOS compatible environment in which a VDM could not negatively affect other 
  3376. VDMs or OS/2 protected mode processes, while at the same time providing the 
  3377. greatest amount of free memory for DOS applications. This goal was achieved by 
  3378. allowing as much of the DOS Emulation  code as possible to execute in protected 
  3379. mode, outside the VDM  address space. This provides improved protection, leaves 
  3380. more memory available for DOS application use, and enhances overall 
  3381. performance. 
  3382.  
  3383.  
  3384. ΓòÉΓòÉΓòÉ 14.2.1. Initialization and VDM Creation ΓòÉΓòÉΓòÉ
  3385.  
  3386. Initialization of the DOS Emulation component is divided into two stages.  The 
  3387. first occurs during OS/2 system initialization. The second stage occurs during 
  3388. creation of each virtual DOS machine. 
  3389.  
  3390. OS/2 Initialization 
  3391.  
  3392. DOS Emulation is involved in OS/2 system initialization because it requires 
  3393. access to information contained in CONFIG.SYS. As the OS/2 initialization 
  3394. procedure processes the CONFIG.SYS file, it records parameters relevant to DOS 
  3395. Emulation. These parameters include those specified in the FCBS and RMSIZE 
  3396. statements, and any DEVICE statements which specify DOS device drivers. These 
  3397. parameters become the default DOS settings for all VDMs. 
  3398.  
  3399. Note:   Virtual device drivers are not loaded or initialized at this stage. 
  3400. Initialization of DOS settings occurs prior to loading virtual device drivers, 
  3401. since these default settings may be required by the device drivers during VDM 
  3402. initialization (creation). 
  3403.  
  3404. VDM Creation Stage 
  3405.  
  3406. Upon creation of a VDM, the Virtual DOS Machine Manager calls the creation-time 
  3407. initialization routines for virtual device drivers and then passes control to 
  3408. the DOS Emulation kernel. At this point, the V86 memory organization appears as 
  3409. shown in Figure "V86 Memory Map Prior to DOS Emulation Initialization". 
  3410.  
  3411. During VDM creation, DOS Emulation performs the following steps: 
  3412.  
  3413.  1. Initialize VDM-Related Kernel Structures 
  3414.  
  3415.     Certain structures in the OS/2 Version 2.0 kernel are initialized in 
  3416.     preparation for processing VDM requests. The System File Table (SFT) 
  3417.     structures, for example, which are used for FCB I/O, are allocated and 
  3418.     initialized. 
  3419.  
  3420.  2. Load DOS Emulation Kernel (DOSKRNL.COM) 
  3421.  
  3422.     The portion of the DOS Emulation kernel which runs in V86 virtual memory is 
  3423.     loaded at the high end of the VDM memory address space. 
  3424.  
  3425.  3. Start Virtual Processor Mode 
  3426.  
  3427.     The protected mode initialization routine returns control to the Virtual 
  3428.     DOS Machine Manager, which then invokes the initialization code within the 
  3429.     V86 mode DOS Emulation kernel. This represents the first transition to V86 
  3430.     mode; at this point, memory is organized as in Figure "V86 Memory Map at 
  3431.     Initial V86 Mode Entry". 
  3432.  
  3433.  4. Open Standard Devices 
  3434.  
  3435.     The initial five file handles (stdin, stdout, stderr, stdaux, and stdprn) 
  3436.     are opened. 
  3437.  
  3438.  5. Initialize Virtual Device Driver DOS Device Driver "stubs" 
  3439.  
  3440.     Some virtual device drivers provide a DOS device driver "stub";  these 
  3441.     stubs are inserted into the V86 address space prior to initialization of 
  3442.     DOS Emulation. As such, this step involves calling the inserted 
  3443.     initialization code and linking the devices into the device chain. Unlike 
  3444.     real DOS device drivers, however, the return from the initialization does 
  3445.     not allow reducing the size of the driver code. See Device Drivers for 
  3446.     further information. 
  3447.  
  3448.  6. Initialize DOS Device Drivers 
  3449.  
  3450.     Each DOS device driver specified in the CONFIG.SYS file is loaded into the 
  3451.     VDM and initialized. Any VDM-specific DOS device drivers passed in the 
  3452.     DosCreateProcess() function call, or configured via the DOS Settings option 
  3453.     DOS Device Drivers, are then loaded and initialized. This is performed one 
  3454.     device driver at a time to allow the device drivers to consume only the 
  3455.     memory that they require or to de-install themselves entirely. As each 
  3456.     device is initialized, it is added to the chain of devices in the VDM. 
  3457.  
  3458.     During initialization, device drivers may issue a limited set of INT 21h 
  3459.     system calls (functions 01h through 0Ch, 25h, 30h, and 35h). This restores 
  3460.     functionality that had been removed from previous versions of OS/2. 
  3461.  
  3462.     Note:   The result is undefined when a DOS device driver issues an INT 21h 
  3463.     system call other than those mentioned above. This is consistent and 
  3464.     compatible with DOS. Issuing an unsupported INT 21h system call will crash 
  3465.     the VDM. 
  3466.  
  3467.     After all device drivers have been initialized, the initialization code is 
  3468.     discarded. 
  3469.  
  3470.  7. Load and Execute DOS Shell 
  3471.  
  3472.     The shell specified in the SHELL command in CONFIG.SYS is loaded, the 
  3473.     initialization code in the V86 address space is discarded, and control is 
  3474.     passed to the shell program. The SHELL specified in CONFIG.SYS can be 
  3475.     overridden in the DosCreateProcess() function call. This is a useful 
  3476.     feature if, for example, a software developer wishes to allow different 
  3477.     versions of COMMAND.COM, for such reasons as alternative national language 
  3478.     support. 
  3479.  
  3480. Upon invocation of the shell program, the VDM's memory map is organized as 
  3481. shown in Figure "V86 Memory Map after Initialization". 
  3482.  
  3483. Before passing control, the Program Descriptor Block (PDB) of the shell is 
  3484. initialized with the command line parameters as specified in CONFIG.SYS. As an 
  3485. extension to the native DOS environment, an additional string is appended after 
  3486. these parameters, separated from the command line string by a NULL byte. This 
  3487. string specifies the drive and directory of the virtual DOS environment after 
  3488. the shell completes its initialization.  This extension provides a default 
  3489. working drive and directory for real mode applications, as is provided for 
  3490. protect mode applications using the Presentation Manager. 
  3491.  
  3492.  
  3493. ΓòÉΓòÉΓòÉ 14.2.2. Requesting System Services ΓòÉΓòÉΓòÉ
  3494.  
  3495. As previously mentioned, MVDM isolates some VDM-specific code and places it 
  3496. into the DOS Emulation kernel in the VDM's address space. This code provides 
  3497. those DOS services which can be supported in V86 mode, such as memory 
  3498. management services. Other services which require protected mode execution are 
  3499. provided by additional code which runs in protected mode. 
  3500.  
  3501. When the DOS Emulation kernel requires protected mode services, it specifies 
  3502. the kernel procedure via an index, and executes a processor instruction which 
  3503. causes a general protection exception. The OS/2 Version 2.0 general protection 
  3504. exception handler traps the exception and invokes the 8086 Emulation component, 
  3505. which in turn transfers control to the specified kernel procedure. This is 
  3506. explained in detail in 8086 Emulation. 
  3507.  
  3508.  
  3509. ΓòÉΓòÉΓòÉ 14.2.3. System Service Call Behavior ΓòÉΓòÉΓòÉ
  3510.  
  3511. DOS system services provided within VDMs are generally compatible with their 
  3512. implementation under DOS 5.0. Some differences do exist, however, and are 
  3513. described below. 
  3514.  
  3515. INT 20h   This service forwards the request to the INT 21h function 00h service 
  3516.           in order to abort the application. 
  3517.  
  3518. INT 21h   All INT 21h services provided in DOS 5.0 are also provided in VDMs. 
  3519.           However, the internal behavior and error processing of some functions 
  3520.           may be different. Where such changes are significant, they are listed 
  3521.           here: 
  3522.  
  3523.     Function 00h (ABORT) 
  3524.  
  3525.      If the CS register does not reference the current PDB, the VDM is 
  3526.      terminated. In certain previous DOS versions, the effect of such a call 
  3527.      was undefined. 
  3528.  
  3529.     FCB Functions 
  3530.  
  3531.      Although OS/2 only provides file I/O access externally through file 
  3532.      handles, it supports these handles internally through the System File 
  3533.      Table (SFT). MVDM allows file handles to be bypassed and SFT entries to be 
  3534.      manipulated directly using a special set of reserved SFT entries, in a 
  3535.      manner similar to previous versions of OS/2. However, since multiple VDMs 
  3536.      are supported, these SFT entries are allocated dynamically upon creation 
  3537.      of a VDM 
  3538.  
  3539.      FCB functions may now be called from device drivers during initialization; 
  3540.      this functionality was not available in previous versions of OS/2. 
  3541.  
  3542.     Function 38h (International) 
  3543.  
  3544.     Function 44h (IOCTL) 
  3545.  
  3546.      IOCTL requests which are destined for device drivers within the VDM are 
  3547.      processed internally. IOCTL requests which are destined for OS/2 device 
  3548.      drivers, however, are treated specially by their respective device 
  3549.      drivers. Such requests may contain pointers to data within the VDM. In 
  3550.      these cases, it is the responsibility of the OS/2 device driver to perform 
  3551.      the necessary translation from V86 virtual addresses into addresses that 
  3552.      are meaningful to the device driver. 
  3553.  
  3554.     Function 5Dh (Internal) 
  3555.  
  3556.       - Subfunction 0Ah (Set Extended Error Information) 
  3557.  
  3558.         This subfunction allows the calling program to set the register values 
  3559.         that are returned from a call to function 59h. This provides 
  3560.         functionality that was not present in previous versions of OS/2. 
  3561.  
  3562.         This subfunction allows terminate and stay resident programs (TSRs) to 
  3563.         save and restore extended error information when they are invoked. 
  3564.  
  3565.     Function 66h - Get/Set Code Page 
  3566.  
  3567.     Function 67h - Set Handle Count 
  3568.  
  3569.      This function restricts the maximum number of open device handles to 254, 
  3570.      including the four standard devices. 
  3571.  
  3572. INT 25h/INT 26h Absolute Disk Read/Write 
  3573.  
  3574.           The read function operates in the same way as in a DOS 5.0 system. 
  3575.           The write function however, is restricted to removable media only, 
  3576.           and reports a hard error on non-removable media. 
  3577.  
  3578.  
  3579. ΓòÉΓòÉΓòÉ 14.2.4. System Callback Procedures ΓòÉΓòÉΓòÉ
  3580.  
  3581. The system callback procedures are "hooks" into DOS (in the case of VDMs, into 
  3582. the DOS Emulation kernel)  which allow application programs to change the 
  3583. default processing action taken for certain system events. These hooks are 
  3584. specified in the V86 mode interrupt vector table as trap service routines. By 
  3585. default, the vectors reference a single IRET instruction if an application does 
  3586. not register its own hook procedure. 
  3587.  
  3588. The vectors used to specify the callback routines are: 
  3589.  
  3590. INT 22h - Terminate Address The DOS Emulation kernel stores the termination 
  3591.           return address at this vector location. 
  3592.  
  3593. INT 23h - Control-C Exit Address The method used to invoke this callback 
  3594.           procedure works the same way as in a DOS 5.0 system. 
  3595.  
  3596. INT 24h - Critical Error Handler Hard errors are normally generated from within 
  3597.           the OS/2 kernel.  When such an error is detected, the file system 
  3598.           checks to see if the requesting task is a VDM. If so, the error 
  3599.           indication is returned to the protected mode portion of DOS 
  3600.           Emulation, which determines if the INT 24h vector has been changed. 
  3601.  
  3602.           If it has not been changed, the normal OS/2 hard error monitor is 
  3603.           called to display the hard error information and to prompt for a 
  3604.           reply.  If it has been changed, the specified critical error handler 
  3605.           is invoked. 
  3606.  
  3607. INT 28h - Idle Loop The method used to call the INT 28h callback routine is 
  3608.           similar to that used in DOS 5.0, but takes into account the fact that 
  3609.           the DOS session is running in a multitasking environment. 
  3610.  
  3611.           The OS/2 scheduler maintains a flag in the VDM address space which 
  3612.           indicates if another process in the system is ready to run. While in 
  3613.           the idle loop, the DOS Emulation kernel repeatedly examines this 
  3614.           flag. If no other OS/2 tasks are ready, the loop proceeds as normal. 
  3615.           If the flag indicates that other tasks are waiting, DOS Emulation 
  3616.           yields control to the operating system, which dispatches the waiting 
  3617.           task. 
  3618.  
  3619. In all other respects, callback procedures operate under MVDM in an identical 
  3620. manner to that experienced under DOS 5.0. 
  3621.  
  3622.  
  3623. ΓòÉΓòÉΓòÉ 14.2.5. VDM Termination ΓòÉΓòÉΓòÉ
  3624.  
  3625. When a VDM is terminated, DOS Emulation closes all handles that have been 
  3626. assigned to all PDB processes within the VDM. All resources associated with 
  3627. open FCBs are also closed. 
  3628.  
  3629. Since the VDM may have been terminated due to an error in a DOS application 
  3630. within the VDM, no data within the VDM is relied upon when closing resources 
  3631. and cleaning up. DOS Emulation explicitly closes both the files and the OS/2 
  3632. devices opened by the VDM. 
  3633.  
  3634.  
  3635. ΓòÉΓòÉΓòÉ 14.2.6. Standard Devices ΓòÉΓòÉΓòÉ
  3636.  
  3637. As in DOS, DOS Emulation includes device drivers for the three "standard" 
  3638. devices, CON, AUX, and PRN. While DOS packages these device drivers in 
  3639. IBMBIO.COM (IO.SYS), DOS Emulation links these into the DOS Emulation kernel 
  3640. (DOSKRNL) to avoid the need for another file. 
  3641.  
  3642. Unlike DOS, the AUX and PRN drivers do not include support for COM1, COM2, 
  3643. LPT1, LPT2, and LPT3. These latter devices are supported directly by the OS/2 
  3644. asynchronous (COM.SYS) and printer (PRINT0n.SYS) device drivers. 
  3645.  
  3646. This approach allows the CON, AUX, and PRN drivers to behave in a highly 
  3647. compatible manner. These drivers issue ROM BIOS calls (INT 10, 14, and 17, 
  3648. respectively) in order to perform their required tasks. At the same time, using 
  3649. the OS/2 device drivers directly for the numbered I/O devices provides higher 
  3650. performance than through the ROM BIOS interfaces, and allows a numbered I/O 
  3651. device to be easily redirected to a remote device on a network, using the 
  3652. underlying OS/2 mechanisms. Hence there is no INT 17 issued when printing on 
  3653. the numbered I/O devices (for example, LPT1, LPT2, etc.) as long as there is 
  3654. only the virtual printer device driver VLPT.SYS installed as the device driver 
  3655. for LPTn devices. If INT 17 is required, for example by a DOS TSR (Terminate 
  3656. and Stay Resident) that intercepts INT 17, the LPTDD.SYS device driver must be 
  3657. installed as well. You can find LPTDD.SYS in the subdirectory \os2\mdos. 
  3658.  
  3659. Note:   Installing LPTDD.SYS will cause printing from a VDM to slow down. 
  3660.  
  3661. Remember that only PRN redirection is supported. This is achieved by the 
  3662. virtual printer device driver VLPT.SYS, which routes INT 17 and direct hardware 
  3663. printing to LPT1, LPT2, or LPT3 using the OS/2 file system.  This is explained 
  3664. in more detail in Device Drivers. 
  3665.  
  3666.  
  3667. ΓòÉΓòÉΓòÉ 14.3. Maximizing VDM Memory ΓòÉΓòÉΓòÉ
  3668.  
  3669. The OS/2 Version 2.0 CONFIG.SYS file specifies the operating system 
  3670. configuration, and installs device drivers and other memory-resident programs. 
  3671. The OS/2 AUTOEXEC.BAT file is specific to the functioning of the VDM 
  3672. environment. More base memory can be made available to programs running in a 
  3673. VDM by removing unnecessary commands from these files. 
  3674.  
  3675.  
  3676. ΓòÉΓòÉΓòÉ 14.3.1. CONFIG.SYS ΓòÉΓòÉΓòÉ
  3677.  
  3678. Virtual device drivers utilized by VDMs consume very little or no memory below 
  3679. the 640KB limit. These device drivers reside outside the V86 mode address 
  3680. space. However, a user may install device drivers that are required by and are 
  3681. specific to certain applications which will run in a VDM. If the commands to 
  3682. load these device drivers (or other memory-resident programs) are added to 
  3683. CONFIG.SYS, these device drivers (or programs) will be loaded into every VDM 
  3684. when it is created, and will reduce the amount of conventional memory available 
  3685. to DOS applications in every VDM. To ensure the maximum amount of memory is 
  3686. available in each VDM, it is recommended that: 
  3687.  
  3688.  DOS device drivers specific to a particular DOS application should be loaded 
  3689.   via the DOS_DEVICE option of DOS Settings. DEVICE= statements for DOS device 
  3690.   drivers should be eliminated from CONFIG.SYS unless the device driver is 
  3691.   required for every VDM. 
  3692.  
  3693.  The number of buffers specified in the Buffers command in CONFIG.SYS should 
  3694.   be minimized. Each buffer consumes about 500 bytes. Be careful to not reduce 
  3695.   this number too much because some programs might not run properly if there 
  3696.   are too few buffers. The default number of buffers is 30; the number should 
  3697.   not be reduced to fewer than 10 or 15 buffers. 
  3698.  
  3699.  If CONFIG.SYS includes the LASTDRIVE command, this should be set to a letter 
  3700.   such as J or K, rather than Z. Each additional drive uses about 100 bytes. 
  3701.  
  3702.  If the CONFIG.SYS file contains an FCBS command, set FCBS to 1. 
  3703.  
  3704. The order of the DEVICE and DEVICEHIGH commands in CONFIG.SYS is important 
  3705. since it can affect both the efficient use of memory and the proper operation 
  3706. of the various programs started from CONFIG.SYS. 
  3707.  
  3708. The CONFIG.SYS statements and options related to VDM operation, and which can 
  3709. be selected during installation, are shown below: 
  3710.  
  3711.  Load the DOS Command Interpreter and load it resident into memory 
  3712.  
  3713.    - SHELL=C:\OS2\MDOS\COMMAND.COM C:\OS2\MDOS /P 
  3714.  
  3715.  Where to load DOS in memory 
  3716.  
  3717.    - DOS=HIGH, UMB 
  3718.  
  3719.  Optional: extended keyboard and display features 
  3720.  
  3721.    - DEVICE=C:\OS2\MDOS\ANSI.SYS 
  3722.  
  3723.  Expanded Memory Manager 
  3724.  
  3725.    - DEVICE=C:\OS2\MDOS\VEMM.SYS 
  3726.  
  3727.  Extended Memory Manager 
  3728.  
  3729.    - DEVICE=C:\OS2\MDOS\VXMS.SYS /UMB 
  3730.  
  3731.  Mouse support 
  3732.  
  3733.    - DEVICE=C:\OS2\MDOS\VMOUSE.SYS 
  3734.  
  3735.  DOS graphics support 
  3736.  
  3737.    - DEVICE=C:\OS2\MDOS\Vxxx.SYS 
  3738.  
  3739.   Where xxx depends on video adapter: 
  3740.  
  3741.    - VCGA.SYS       (if CGA or EGA w/ 64KB) 
  3742.    - VEGA.SYS       (if EGA w/ 128KB) 
  3743.    - VVGA.SYS       (if VGA or 8514) 
  3744.    - V8514.SYS      (if 8514) 
  3745.  
  3746.  Direct I/O serial communication support 
  3747.  
  3748.    - DEVICE=C:\OS2\MDOS\VCOM.SYS 
  3749.  
  3750. The following list shows the order in which device drivers should be specified 
  3751. in CONFIG.SYS: 
  3752.  
  3753.  1. VEMM.SYS 
  3754.  
  3755.  2. Any device drivers that use expanded memory 
  3756.  
  3757.  3. VXMS.SYS 
  3758.  
  3759.  4. Any device drivers that use extended memory 
  3760.  
  3761.  5. Any device drivers that use upper memory blocks. 
  3762.  
  3763. This is the optimal order in which the CONFIG.SYS file should start device 
  3764. drivers. Whether these statements are included at all depends on the amount of 
  3765. memory installed, the hardware configuration, and on the DOS applications to be 
  3766. run. 
  3767.  
  3768.  
  3769. ΓòÉΓòÉΓòÉ 14.3.2. AUTOEXEC.BAT ΓòÉΓòÉΓòÉ
  3770.  
  3771. AUTOEXEC.BAT is specific to the virtual DOS machine environment and has no 
  3772. effect on the OS/2 Version 2.0 operating system. The AUTOEXEC.BAT file starts 
  3773. memory-resident programs, such as network programs, and sets up environment 
  3774. variables.  In addition, the AUTOEXEC.BAT file may also define the command 
  3775. prompt. 
  3776.  
  3777. The default AUTOEXEC.BAT file for all VDMs in OS/2 Version 2.0 is shown in 
  3778. Figure "Default AUTOEXEC.BAT File". 
  3779.  
  3780. In the above AUTOEXEC.BAT file, the LOADHIGH command loads the APPEND TSR into 
  3781. the High Memory Area, thus making available more memory to all DOS applications 
  3782. running in every VDM.  This example assumes that the function performed by the 
  3783. SET COMSPEC command, which is often found in AUTOEXEC.BAT, has been moved to 
  3784. CONFIG.SYS. 
  3785.  
  3786. Note:   In order to maximize the amount of base memory available to 
  3787. applications, any unnecessary commands should be removed from AUTOEXEC.BAT. 
  3788. Commands should only be included in AUTOEXEC.BAT if they are required for every 
  3789. VDM. Commands which are required only for a specific DOS application to be run 
  3790. in a VDM should be placed into a batch file. This batch file should be 
  3791. explicitly entered into the path and file name field of the "parameters field" 
  3792. in the DOS Settings notebook on the "program page" for that specific 
  3793. application. 
  3794.  
  3795.  
  3796. ΓòÉΓòÉΓòÉ 14.4. Command Compatibility ΓòÉΓòÉΓòÉ
  3797.  
  3798. For maximum compatibility, OS/2 Version 2.0 now supports commands previously 
  3799. unique to DOS, including new commands and enhancements recently introduced with 
  3800. IBM DOS 5.0. Commands new to OS/2 Version 2.0 are: 
  3801.  
  3802. MEM               Display memory availability and contents 
  3803. FC                Intelligent file compare utility 
  3804. DOSKEY            Command-line enhancer 
  3805. DEBUG             Program debugger 
  3806. UNDELETE          Recover erased files 
  3807. QBASIC            Enhanced BASIC Interpreter 
  3808.  
  3809. UNDELETE runs in both an OS/2 session and in a VDM. The others run in DOS MVDM 
  3810. mode only. 
  3811.  
  3812. In addition, several enhancements introduced in DOS 5.0 are also supported: 
  3813.  
  3814. DIR               Several new output formatting options 
  3815. ATTRIB            Now supports hidden and system file attributes 
  3816. RESTORE           Option to list backup diskette's contents 
  3817. FIND              Case-insensitive search option 
  3818.  
  3819. These command enhancements are available in both MVDM and OS/2 protect mode. 
  3820.  
  3821. Note:   The following DOS 5.0 enhancements are not provided in OS/2 Version 
  3822. 2.0: 
  3823.  
  3824.  UNFORMAT command 
  3825.  
  3826.  Quick FORMAT 
  3827.  
  3828. A brief summary follows for those unfamiliar with DOS 5.0 enhancements. 
  3829.  
  3830.  
  3831. ΓòÉΓòÉΓòÉ 14.4.1. MEM ΓòÉΓòÉΓòÉ
  3832.  
  3833. MEM displays the amount of used and free memory in the DOS environment.  It 
  3834. lists information about allocated memory areas, free memory areas, and programs 
  3835. that are currently loaded into memory. 
  3836.  
  3837. The format of the MEM command is: 
  3838.  
  3839.     mem [/program | /debug | /classify]
  3840.  
  3841. where: 
  3842.  
  3843. /p(rogram)     displays the status of programs that are currently loaded into 
  3844.                memory. 
  3845. /d(ebug)       displays the status of currently loaded programs, internal 
  3846.                drivers and other programming information. 
  3847. /c(lassify)    displays the status of programs loaded into conventional memory 
  3848.                and the upper memory area. 
  3849.  
  3850. MEM only runs in a DOS session. 
  3851.  
  3852.  
  3853. ΓòÉΓòÉΓòÉ 14.4.2. FC (File Compare) ΓòÉΓòÉΓòÉ
  3854.  
  3855. FC compares two files and displays their differences.  The format of the FC 
  3856. command to compare ASCII (text) files is: 
  3857.  
  3858. FC [/A][/C][/L][/LBn][/N][/T][/W][/n] <file1> <file2>
  3859.  
  3860. FC /B [drive1:][path1] <file1> <file2>
  3861.  
  3862. where: 
  3863.  
  3864. /A        Displays only first and last lines for each set of differences 
  3865. /B        Performs a binary comparison 
  3866. /C        Disregards the case of letters 
  3867. /L        Compares files as ASCII text 
  3868. /LBn      Sets the maximum consecutive mismatches to "n" lines 
  3869. /N        Displays the line numbers on an ASCII comparison 
  3870. /T        Does not expand tabs to spaces 
  3871. /W        Compresses white space (tabs and spaces) for comparison 
  3872. /n        Specifies the number of consecutive lines that must match after a 
  3873.           mismatch 
  3874.  
  3875. Unlike the COMP command, FC attempts to resynchronize after a mismatch.  It 
  3876. recognizes inserted or deleted character sequences, then resumes the 
  3877. comparison. 
  3878.  
  3879.  
  3880. ΓòÉΓòÉΓòÉ 14.4.3. DOSKEY ΓòÉΓòÉΓòÉ
  3881.  
  3882. DOSKEY enhances command line editing, recalls DOS commands, and creates macros. 
  3883. The format of the DOSKEY command is: 
  3884.  
  3885.     doskey [/reinstall] [/bufsize=size] [/macros] [/history]
  3886.         [/insert | /overstrike] [macroname=[text]]
  3887.  
  3888. where: 
  3889.  
  3890. /r(einstall)        installs a new copy of the DOSKEY program 
  3891. /b(ufsize)=size     size of buffer (in bytes) to store commands and macros 
  3892. /m(acros)           displays list of all macros 
  3893. /h(istory)          displays list of all commands stored in memory 
  3894. /i(nsert)|/o(verstrike) selects insert or overtype mode 
  3895.  
  3896. DOSKEY stacks and recalls commands from a LIFO buffer using the up and down 
  3897. cursor keys. The command line can be intuitively edited via left and right 
  3898. cursor keys, with insert and non-destructive backspace.  DOSKEY provides 
  3899. similar command line editing to that of an OS/2 prompt with KEYS=ON specified. 
  3900.  
  3901.  
  3902. ΓòÉΓòÉΓòÉ 14.4.4. DEBUG ΓòÉΓòÉΓòÉ
  3903.  
  3904. DEBUG is used to assist in testing and debugging of executable files.  The 
  3905. format of the DEBUG command is: 
  3906.  
  3907.     debug <filename> [parameters]
  3908.  
  3909. where <filename> is the file to test. 
  3910.  
  3911. parameters are any command line parameters to be passed to the program being 
  3912. debugged, not to DEBUG itself. 
  3913.  
  3914. DEBUG allows the user to examine memory and registers, assemble and disassemble 
  3915. programs, set breakpoints, and step through programs one instruction at a time. 
  3916.  
  3917. Note:   DEBUG supports 8086 and 8087 instructions only. It will not assemble or 
  3918. disassemble 80286/7 or later opcodes, and can only access the low 16 bits of 32 
  3919. bit registers. 
  3920.  
  3921.  
  3922. ΓòÉΓòÉΓòÉ 14.4.5. UNDELETE ΓòÉΓòÉΓòÉ
  3923.  
  3924. The UNDELETE utility recovers files that have been deleted or erased.  When the 
  3925. DEL or ERASE command is issued from any session type, the file is moved to a 
  3926. specified hidden directory, along with details of where the file originated. 
  3927. If no space is available, the oldest files are automatically purged to provide 
  3928. more space. 
  3929.  
  3930. The DELDIR environment variable is used to specify the name and maximum size of 
  3931. the directories where files targeted for deletion are to be stored.  Normally 
  3932. this will be set in CONFIG.SYS, and takes the form: 
  3933.  
  3934.   SET DELDIR = drive:\path, maxsize [;drive:\path, maxsize]
  3935.  
  3936. The string is composed of a directory path specifier and maximum size value for 
  3937. each supported logical drive. These parameters are separated by commas. The 
  3938. definitions for each drive are separated by semicolons. 
  3939.  
  3940. The path portion of the string consists of a drive letter and the fully 
  3941. qualified path of the directory that will be used for storing deleted files. 
  3942.  
  3943. The maxsize portion of the string defines the maximum size of the storage 
  3944. directory, in kilobytes. 
  3945.  
  3946. In order to keep track of deleted files, the system also maintains a control 
  3947. file in each storage directory. 
  3948.  
  3949. When UNDELETE is specified and the file is still recoverable, it is restored to 
  3950. its specified path. If the file already exists, the user is prompted to rename 
  3951. the file, or to skip the current entry. 
  3952.  
  3953. Space occupied by recoverable files is included in DIR and CHKDSK output 
  3954. reports. 
  3955.  
  3956. The format of the UNDELETE command is : 
  3957.  
  3958.   undelete <filename> [/list | /all] [/s] [/force]
  3959.  
  3960. re: 
  3961.  
  3962. <filename>     is the path and name of the file to recover or purge. It may be 
  3963.                wildcarded. 
  3964. /l(ist)        lists deleted files that are available to be recovered without 
  3965.                recovering the files. 
  3966. /a(ll)         recovers all deleted files if they are still present without 
  3967.                prompting for confirmation on each file. 
  3968. /s             include all files in the specified directory and all 
  3969.                subdirectories 
  3970. /f(orce)       removes files so they cannot be recovered. 
  3971.  
  3972. UNDELETE runs in both protect mode and in a DOS VDM. 
  3973.  
  3974.  
  3975. ΓòÉΓòÉΓòÉ 14.4.6. DIR ΓòÉΓòÉΓòÉ
  3976.  
  3977. DIR lists files and subdirectories: New options on the DIR command are: 
  3978.  
  3979. /a attribute Lists only those files with the chosen attribute: 
  3980.  
  3981.    a.  files not yet backed up 
  3982.    h   hidden files 
  3983.    r   read-only files 
  3984.    s   system files 
  3985.    d   directories 
  3986.  
  3987.           attribute may be preceded by a minus sign to select items which do 
  3988.           not have that attribute. 
  3989. /o sortorder Lists items in the chosen order: 
  3990.  
  3991.    n   sorted by name 
  3992.    e   sorted by extension 
  3993.    d   sorted by date 
  3994.    s   sorted by size 
  3995.    g   directories grouped before files 
  3996.  
  3997.           sortorder may be preceded by a minus sign to reverse the output 
  3998.           order. 
  3999. /b        Displays "bare" file information (no date or size) 
  4000. /f        Displays fully qualified file and directory names. 
  4001. /l        Displays output in lowercase letters. 
  4002. /n        Displays the listing in "HPFS" style format. 
  4003. /s        Includes all subdirectories in the search 
  4004.  
  4005. Other enhancements to the DIR command include: 
  4006.  
  4007.  The total byte count of matched files is given 
  4008.  /p (pause) repeats the directory name after each screen is full 
  4009.  /w (wide) distinguishes directory entries from file entries via square 
  4010.   brackets. 
  4011.  
  4012.  
  4013. ΓòÉΓòÉΓòÉ 14.4.7. ATTRIB ΓòÉΓòÉΓòÉ
  4014.  
  4015. ATTRIB now supports manipulation of "hidden" and "system" file attributes. 
  4016.  
  4017. attrib +s <file>    sets the system attribute. 
  4018. attrib -s <file>    clears the system attribute. 
  4019. attrib +h <file>    sets the hidden attribute. 
  4020. attrib -h <file>    clears the hidden attribute. 
  4021.  
  4022. ATTRIB may also be used to set or clear the "Archive" and "Read-only" 
  4023. attributes as before. 
  4024.  
  4025.  
  4026. ΓòÉΓòÉΓòÉ 14.4.8. RESTORE ΓòÉΓòÉΓòÉ
  4027.  
  4028. A new parameter "/d" displays a list of files on the backup diskette which 
  4029. match the file's specified filename, without restoring any files. 
  4030.  
  4031.  
  4032. ΓòÉΓòÉΓòÉ 14.4.9. FIND ΓòÉΓòÉΓòÉ
  4033.  
  4034. A new parameter "/I" will ignore the case of characters when searching for the 
  4035. string. 
  4036.  
  4037.  
  4038. ΓòÉΓòÉΓòÉ 14.5. Summary ΓòÉΓòÉΓòÉ
  4039.  
  4040. The DOS Emulation component provides an emulation of the DOS operating system 
  4041. environment, including DOS features and system services, for applications 
  4042. running in virtual DOS machines. DOS Emulation uses the parameters specified in 
  4043. CONFIG.SYS and virtual device drivers to create an application-compatible DOS 
  4044. environment within the VDM address space. 
  4045.  
  4046. During execution, DOS Emulation receives requests from DOS applications. 
  4047. Depending upon the type of request, it either processes the request itself or 
  4048. causes a general protection exception which results in the request being routed 
  4049. by the operating system kernel to the 8086 Emulation component, which processes 
  4050. the request at a higher privilege level. 
  4051.  
  4052. DOS Emulation also allows DOS applications to hook interrupts, in order to 
  4053. modify the default behavior in response to particular events. This is achieved 
  4054. by providing a virtual interrupt vector table within the V86 mode address 
  4055. space, and routing interrupts through this table. 
  4056.  
  4057. At VDM termination time, DOS Emulation is responsible for closing all files 
  4058. opened by the VDM, and cleaning up the environment to ensure that no devices 
  4059. are still held or memory objects allocated after termination. 
  4060.  
  4061. DOS Emulation also provides support for applications which access the standard 
  4062. devices CON, AUX, and PRN. These devices are emulated within DOS Emulation 
  4063. itself, which processes the interrupts for these devices and returns the 
  4064. results to the DOS application. 
  4065.  
  4066.  
  4067. ΓòÉΓòÉΓòÉ 15. Device Drivers ΓòÉΓòÉΓòÉ
  4068.  
  4069. In order to provide the maximum level of hardware independence for the OS/2 
  4070. Version 2.0 operating system, device driver are used to communicate with 
  4071. hardware devices.  This concept is not new, and has been implemented in 
  4072. previous versions of OS/2 and in the DOS operating system.  However, the 
  4073. implementation of device drivers under OS/2 Version 2.0 differ in several 
  4074. significant ways from that seen in previous versions.  This chapter describes 
  4075. the implementation of device drivers under OS/2 Version 2.0. 
  4076.  
  4077.  
  4078. ΓòÉΓòÉΓòÉ 15.1. Device Driver Architecture ΓòÉΓòÉΓòÉ
  4079.  
  4080. The architecture and structure of a device driver differs considerably, 
  4081. depending on whether the device driver is physical or virtual. 
  4082.  
  4083. OS/2 Version 2.0 makes use of two distinct types of device driver to 
  4084. communicate between the operating system and hardware devices: 
  4085.  
  4086.  Physical device drivers are considered as true device drivers in the sense 
  4087.   that they have a unique and rigid file structure, and interface directly with 
  4088.   the hardware. They operate in protected mode, and are accessed by protected 
  4089.   mode processes and by virtual device drivers. 
  4090.  
  4091.  Virtual device drivers are essentially a dynamic link library conforming to 
  4092.   the EXE32 Load Module format, and generally do not interface directly with 
  4093.   hardware devices. Instead, virtual device drivers are responsible for 
  4094.   presenting a virtual copy of a hardware resource to DOS applications running 
  4095.   in virtual DOS machines, and for coordinating physical access to that 
  4096.   resource. DOS applications typically address hardware devices directly using 
  4097.   interrupts; the virtual device driver allows the VDM environment to appear to 
  4098.   the DOS application as though the application had direct control over the 
  4099.   hardware. Virtual device drivers include a stub which executes in V86 mode 
  4100.   within each VDM, while the main portion of the virtual device driver executes 
  4101.   in protected mode. 
  4102.  
  4103. The relationship between applications, physical and virtual device drivers, and 
  4104. hardware devices is shown in Figure "Physical and Virtual Device Drivers under 
  4105. OS/2 Version 2.0". 
  4106.  
  4107.  
  4108. ΓòÉΓòÉΓòÉ 15.2. Physical Device Drivers ΓòÉΓòÉΓòÉ
  4109.  
  4110. The concept of a device driver is not new to OS/2 Version 2.0; previous 
  4111. versions of OS/2 and DOS have employed device drivers to communicate with 
  4112. hardware devices.  Under previous versions of OS/2, however, many device 
  4113. drivers were required to run in both real mode and protected mode in order to 
  4114. accommodate the requirements of applications running in the DOS Compatibility 
  4115. Box.  This complicated the design of device drivers under previous versions of 
  4116. OS/2, since they were required to be written in a bi-modal manner.  Figure 
  4117. "Structure of Bi-Modal Device Drivers in OS/2 V1.x" shows the structure of 
  4118. bi-modal OS/2 device drivers. MVDM removes the need for real mode device 
  4119. drivers, since DOS applications run in virtual DOS machines, where each VDM is 
  4120. a protected mode task. Real mode device interrupts issued by DOS applications 
  4121. are trapped by the MVDM kernel and routed to device drivers which execute in 
  4122. protected mode. Hence device drivers for OS/2 Version 2.0 need not include real 
  4123. mode sections, and existing device drivers may be updated to remove the real 
  4124. mode components. 
  4125.  
  4126. Physical device drivers communicate directly with hardware devices, and are 
  4127. installed at system initialization time using DEVICE= statements in CONFIG.SYS, 
  4128. as shown in Figure "Physical Device Driver Statements in CONFIG.SYS". 
  4129.  
  4130. The advantage of physical device drivers, as with device drivers in previous 
  4131. versions of OS/2, is that the operating system itself need not be changed if a 
  4132. new hardware device or adapter is installed.  The corresponding device driver 
  4133. may be installed with the device, and used by applications which require access 
  4134. to the device.  The major enhancement in Version 2.0 over previous versions of 
  4135. OS/2 lies in the removal of the real mode component, which simplifies device 
  4136. driver development and improves performance by avoiding the need for processor 
  4137. mode switching. 
  4138.  
  4139.  
  4140. ΓòÉΓòÉΓòÉ 15.3. Virtual Device Drivers ΓòÉΓòÉΓòÉ
  4141.  
  4142. As mentioned previously, DOS applications typically address hardware devices 
  4143. directly using interrupts. This is permissible in a single tasking DOS 
  4144. environment, since it can be safely assumed that the application has complete 
  4145. and exclusive control over the hardware.  However, in the OS/2 Version 2.0 
  4146. environment where multiple applications may be executing concurrently in 
  4147. virtual DOS machines, it is clearly not allowable, since applications could 
  4148. interfere with one another to the detriment of application and system 
  4149. integrity. 
  4150.  
  4151. Multiple DOS applications accessing the same hardware devices from within VDMs 
  4152. require those hardware devices to be virtualized; virtualization implies 
  4153. separate simulation of the physical hardware (I/O ports, device memory, and ROM 
  4154. BIOS) for each virtual DOS machine. This virtualization is accomplished by 
  4155. installable virtual device drivers, which in turn communicate with physical 
  4156. device drivers to address hardware devices. 
  4157.  
  4158. The following virtual device drivers are provided with the OS/2 Version 2.0 
  4159. operating system: 
  4160.  
  4161. VDD            Description 
  4162.  
  4163. VBIOS          ROM BIOS support (1) 
  4164.  
  4165. VCMOS          CMOS data area + Real Time Clock support (1) 
  4166.  
  4167. VDMA           Direct Memory Access (1) 
  4168.  
  4169. VDSK           Disk, only for INT 13 copy-protection (1) 
  4170.  
  4171. VFLPY          Floppy Disk interface (1) 
  4172.  
  4173. VKBD           Keyboard (1) 
  4174.  
  4175. VLPT           Parallel Port Printer (1) 
  4176.  
  4177. VNPX           Numeric Coprocessor Extension (80387) (1) 
  4178.  
  4179. VPIC           Programmable Interrupt Controller (1) 
  4180.  
  4181. VTIMER         Timer (1) 
  4182.  
  4183. VCOM           Asynchronous communication ports 
  4184.  
  4185. VDPMI          DOS Protected Mode Interface 
  4186.  
  4187. VDPX           DOS Protected Mode Extender 
  4188.  
  4189. VXMS           Extended Memory Support 
  4190.  
  4191. VEMM           Expanded Memory Support 
  4192.  
  4193. VWIN           WIN-OS/2 windows 
  4194.  
  4195. VMOUSE         Mouse 
  4196.  
  4197. VCDROM         CD-ROM support 
  4198.  
  4199. VVIDEO         Video (VCGA, VEGA, VMONO, VVGA, VXGA, V8514, VSVGA). 
  4200.  
  4201. These virtual device drivers are described in Standard Virtual Device Drivers. 
  4202. Those indicated with an (1) form the base set of OS/2 V2.0 and are 
  4203. automatically loaded at system initialization time. The others are installed at 
  4204. operating system initialization time, using DEVICE= statements in CONFIG.SYS, 
  4205. as shown in Figure "Virtual Device Driver Statements in CONFIG.SYS". The first 
  4206. two virtual device drivers in Figure "Virtual Device Driver Statements in 
  4207. CONFIG.SYS" communicate with the corresponding physical device drivers from 
  4208. Figure "Physical Device Driver Statements in CONFIG.SYS". 
  4209.  
  4210. Virtual device drivers perform four main functions: 
  4211.  
  4212.  Maintain the hardware state for each VDM 
  4213.  
  4214.  Prevent an application in one VDM from corrupting another VDM 
  4215.  
  4216.  Support fast screen I/O 
  4217.  
  4218.  Support fast communications I/O. 
  4219.  
  4220.  
  4221. ΓòÉΓòÉΓòÉ 15.3.1. Loading Virtual Device Drivers ΓòÉΓòÉΓòÉ
  4222.  
  4223. Virtual device drivers are loaded into memory when the initialization phase of 
  4224. the physical device drivers has completed.  Upon loading, the virtual device 
  4225. driver verifies the communication path to the corresponding physical device 
  4226. driver, and registers hooks with the Virtual DOS Machine Manager for VDM events 
  4227. such as creation, destruction, and foreground/background switching. 
  4228.  
  4229. Upon creation of a VDM, the virtual device driver is notified by the Virtual 
  4230. DOS Machine Manager, and the creation routine of the virtual device driver is 
  4231. invoked.  This causes a stub device driver to be loaded into the VDM's V86 mode 
  4232. address space.  This stub driver accepts device requests from DOS applications 
  4233. within the VDM, and routes them to the virtual device driver outside the V86 
  4234. mode address space. 
  4235.  
  4236. This is typically achieved by having the stub device driver issue an 
  4237. instruction which causes a general protection exception.  This exception is 
  4238. passed to the operating system's general protection exception handler, which in 
  4239. turn passes it to the Virtual DOS Machine Manager, and finally to the 
  4240. appropriate virtual device driver.  The virtual device driver then communicates 
  4241. with the corresponding physical device driver in order to access the hardware 
  4242. device. 
  4243.  
  4244. When a hardware interrupt occurs, the physical device driver is notified and 
  4245. communicates the event to the virtual device driver, which then takes the 
  4246. appropriate action to inform the DOS application.  This occurs even if the VDM 
  4247. is not currently executing in the foreground, since the virtual device driver 
  4248. can access its instance data directly. 
  4249.  
  4250. Note that certain virtual device drivers do not have a corresponding physical 
  4251. device driver.  For example, the VEMM.SYS virtual device driver is used to 
  4252. provide support for the LIM Expanded Memory Specification Version 4.0; this 
  4253. virtual device driver communicates directly with the operating system's memory 
  4254. manager to allocate and manipulate expanded memory objects. 
  4255.  
  4256. Virtual device drivers communicate with the OS/2 Version 2.0 kernel using 
  4257. virtual device helper (VDH) services. The use of these services is required 
  4258. because virtual device drivers execute at privilege level 0, and are thus 
  4259. prevented from issuing normal privilege level 3 function calls to the operating 
  4260. system kernel.  VDH services are also used to communicate with physical device 
  4261. drivers, and for communication between virtual device drivers. 
  4262.  
  4263. Note that there is no fixed communication protocol between a virtual device 
  4264. driver and a physical device driver.  The programmer may use any protocol that 
  4265. suits the needs of the driver.  A shutdown protocol is recommended in case the 
  4266. virtual device driver has to be shut down. 
  4267.  
  4268.  
  4269. ΓòÉΓòÉΓòÉ 15.3.2. Virtual Device Driver Structure ΓòÉΓòÉΓòÉ
  4270.  
  4271. A virtual device driver is a 32-bit EXE file which runs in protected mode and 
  4272. supports the flat memory model.  Figure "Virtual COM and Physical COM Device 
  4273. Drivers" shows the structure of a virtual device driver and the interfaces to a 
  4274. physical device driver. 
  4275.  
  4276. Nearly all virtual device drivers provided in OS/2 V2.0 are written in a 
  4277. high-level language ("C"), although several have portions that were developed 
  4278. using assembler language.  Since software interrupts and hooked I/O port 
  4279. operations cause a trap to privilege level 0, time critical code for these 
  4280. operations should be written in assembler language to achieve the maximum 
  4281. possible performance. 
  4282.  
  4283. A virtual device driver is a 32-bit EXE file that can contain some, all, or 
  4284. none of the following types of objects: 
  4285.  
  4286.  Initialization code 
  4287.  
  4288.  Initialization data 
  4289.  
  4290.  Swappable global code. 
  4291.  
  4292. A virtual device driver must have at least one object of the following types: 
  4293.  
  4294.  Swappable global data 
  4295.  
  4296.  Swappable instance data 
  4297.  
  4298.  Resident global code 
  4299.  
  4300.  Resident global data 
  4301.  
  4302.  Resident instance data. 
  4303.  
  4304. A virtual device driver should contain resident objects for code and data which 
  4305. must be accessed at physical hardware interrupt time, that is, when a physical 
  4306. device driver calls the virtual device driver.  A virtual device driver which 
  4307. does not interact with a physical device driver needs no resident objects. 
  4308. Examples of such device drivers are VEMM and VXMS. 
  4309.  
  4310. A virtual device driver locates its instance data above the 1MB + 64KB line, 
  4311. but below 4MB.  The instance data is therefore outside the VDM's V86 mode 
  4312. address space.  This linear address range is the same for all VDMs; that is, 
  4313. all VDMs have the instance data for a particular virtual device driver at the 
  4314. same linear address.  The offset from the VDM's linear base address to the 
  4315. virtual device driver's instance data is returned by the OS/2 kernel when the 
  4316. device driver is initialized. 
  4317.  
  4318. A virtual device driver may need to access its instance data area at physical 
  4319. hardware interrupt time.  This may be required even when the VDM is not 
  4320. currently executing in the foreground.  Since the instance data is system data 
  4321. located above the V86 addressing range, the virtual device driver may address 
  4322. the per-VDM buffer regardless of which process is currently running.  VDM 
  4323. instance data is accessed by adding the VDM's handle + instance data area 
  4324. offset + data offset within the instance data area. 
  4325.  
  4326. Note that memory objects created by a virtual device driver for passing to a 
  4327. physical device driver must not exceed 64KB in size.  This limitation results 
  4328. from the fact that many physical device drivers are still written using the 
  4329. 16:16 segmented memory model, and cannot therefore support memory objects 
  4330. greater than 64KB in size. 
  4331.  
  4332.  
  4333. ΓòÉΓòÉΓòÉ 15.3.3. ROM BIOS Compatibility ΓòÉΓòÉΓòÉ
  4334.  
  4335. ROM BIOS provides many function calls which are typically used by a DOS 
  4336. application program.  To maintain the virtualization concept and ensure 
  4337. compatibility with applications which access BIOS or its functions, these 
  4338. functions are emulated by a virtual device driver. 
  4339.  
  4340. The VBIOS virtual device driver contains a mechanism to map and initialize the 
  4341. system ROMs (including the ROM and EBIOS data areas) and the interrupt vector 
  4342. table into memory within each virtual DOS machine.  This is done at VDM 
  4343. creation time, before any other virtual device drivers are loaded.  This allows 
  4344. other virtual device drivers to hook interrupt vectors and use VBIOS services. 
  4345. Certain BIOS interfaces are not emulated directly, but are passed to other 
  4346. routines which provide improved performance or functionality.  For example, the 
  4347. video interface routines provided by ROM BIOS are powerful but extremely slow. 
  4348. In order to increase the performance of the video output, the video virtual 
  4349. device driver intercepts the ROM BIOS video interrupt (INT 10h) and performs 
  4350. the requested operations directly, providing improved performance. 
  4351.  
  4352.  
  4353. ΓòÉΓòÉΓòÉ 15.3.4. Hardware Interrupt Simulation ΓòÉΓòÉΓòÉ
  4354.  
  4355. A virtual device driver typically establishes communications with a physical 
  4356. device driver and receives events at hardware interrupt time. Based on the 
  4357. event received from the physical device driver and the VDM's current state, the 
  4358. virtual device driver may need to send a hardware interrupt to the VDM. 
  4359. However, the virtual device driver cannot simply call the VDM's interrupt 
  4360. handler, since the interrupt handler may currently be paged out, and page 
  4361. faults cannot be taken on the VDM's interrupt handler code at hardware 
  4362. interrupt time. 
  4363.  
  4364. The solution is to "simulate" the hardware interrupt to the VDM by delaying it 
  4365. until the VDM process becomes active.  This is done in three steps: 
  4366.  
  4367.  1. The VDM's interrupt request flag for the particular interrupt level (IRQ) 
  4368.     is set, and a global context hook is set to pass control to the virtual 
  4369.     device driver as soon as any VDM becomes active. 
  4370.  
  4371.  2. A VDM context hook is set, which increases the priority of the target VDM, 
  4372.     based on the priority of the interrupt, thereby enabling fast interrupt 
  4373.     processing by the VDM. 
  4374.  
  4375.  3. When the VDM is scheduled and the interrupt request flag is noted, the 
  4376.     VDM's interrupt handler code is invoked. 
  4377.  
  4378. The VDM's interrupt handler typically issues a request for the interrupt data 
  4379. or an EOI instruction.  When the virtual device driver receives either of 
  4380. these, it calls the VDHClearVIRR() helper service to clear the interrupt 
  4381. request flag. If the interrupt request flag is not cleared before the VDM 
  4382. issues an EOI instruction, the virtual device driver immediately simulates 
  4383. another interrupt to the VDM.  For example, the virtual timer device driver may 
  4384. leave the interrupt request flag set when it receives the EOI from a previously 
  4385. simulated interrupt, if it has another hardware timer interrupt pending for 
  4386. that VDM. 
  4387.  
  4388. Clearing Interrupts 
  4389.  
  4390. Note that a virtual device driver must call the VDHClearVIRR() helper service 
  4391. when the VDM issues an EOI instruction.  Otherwise, the application may receive 
  4392. spurious interrupts because the interrupt request flag is not cleared.  For 
  4393. this reason, unknown device interrupts are not supported for VDMs, since there 
  4394. is typically no virtual device driver to clear the interrupt request flag. 
  4395.  
  4396. Interrupts must be simulated to VDMs as quickly as possible.  It is not 
  4397. advisable for a virtual device driver to have too many interrupts pending since 
  4398. the physical device driver's buffers may overflow. 
  4399.  
  4400. A virtual device must also be very careful when it simulates an interrupt to a 
  4401. VDM because too many nested interrupts may cause the application's stack to 
  4402. overflow.  A virtual device driver should wait until the IRET instruction has 
  4403. been executed in the VDM's interrupt handler before it simulates the next 
  4404. interrupt; the virtual device driver may gain control immediately upon IRET 
  4405. being issued, via an IRET handler registered using the VDHOpenVIRQ() helper 
  4406. service. 
  4407.  
  4408. Shared Interrupts 
  4409.  
  4410. Personal System/2 machines equipped with the IBM Micro Channel* bus 
  4411. architecture support multiple hardware devices on the same IRQ level. Hence, 
  4412. support may also be required for virtual device drivers to share interrupts. 
  4413. This support is provided through the VDHOpenVIRQ() helper function, which 
  4414. accepts a flag indicating that a virtual device driver is willing to share its 
  4415. IRQ.  Note that all virtual device drivers using the same IRQ must pass the 
  4416. sharing flag; otherwise, an error is returned. 
  4417.  
  4418. Each virtual device driver receives an IRQ handle, which points to an IRQ data 
  4419. block specific to that device driver.  Data not specific to the virtual device 
  4420. driver is contained in a shared IRQ data structure. 
  4421.  
  4422. When an interrupt is received for a VDM, the virtual interrupt request flag is 
  4423. set and a device request mask is updated.  This device request mask is specific 
  4424. to each VDM, and contains a bit for every virtual device driver which has 
  4425. requested a virtual interrupt for the IRQ.  When the interrupt is cleared, the 
  4426. device mask bit for the virtual device driver is cleared.  However, the virtual 
  4427. interrupt request flag is not cleared until all virtual device drivers have 
  4428. cleared the interrupt. 
  4429.  
  4430. Note that EOI and IRET handler routines are called when the device mask bit is 
  4431. cleared, allowing virtual device drivers to perform correct interrupt 
  4432. termination handling. 
  4433.  
  4434.  
  4435. ΓòÉΓòÉΓòÉ 15.3.5. Protection ΓòÉΓòÉΓòÉ
  4436.  
  4437. An application within a VDM cannot corrupt or destroy a virtual device driver, 
  4438. since the virtual device driver operates in protected mode outside the V86 mode 
  4439. address space, and is thus not accessible by the application. However, the 
  4440. parameters passed to a virtual device driver from the VDM must be carefully 
  4441. checked before being acted upon, in order to ensure that the service request is 
  4442. valid.  Failure to do so may result in failure of a virtual device driver due 
  4443. to an invalid instruction or invalid data. 
  4444.  
  4445. System registers must not be modified by a virtual device driver.  Only certain 
  4446. flags may be modified. These are as follows: 
  4447.  
  4448.  Arithmetic bits 
  4449.  Interrupt bit; note that this must be handled with extreme care 
  4450.  Direction bit. 
  4451.  
  4452. Failure to observe these rules by a virtual device driver may result in failure 
  4453. of the VDM's parent process, and possible corruption of the virtual device 
  4454. driver itself. 
  4455.  
  4456.  
  4457. ΓòÉΓòÉΓòÉ 15.4. Standard Virtual Device Drivers ΓòÉΓòÉΓòÉ
  4458.  
  4459. The following pages provide brief descriptions of each of the standard virtual 
  4460. device drivers provided with the OS/2 Version 2.0 operating system. 
  4461.  
  4462.  
  4463. ΓòÉΓòÉΓòÉ 15.4.1. VBIOS Device Driver ΓòÉΓòÉΓòÉ
  4464.  
  4465. The VBIOS virtual device driver is like any other base virtual device driver 
  4466. except that it is loaded before any other virtual device drivers.  This driver 
  4467. is loaded and initialized first, so that other virtual device drivers can use 
  4468. services provided by VBIOS. 
  4469.  
  4470. The system BIOS reserves physical memory for the interrupt vector table, ROM 
  4471. and EBIOS data areas.  This reservation is done by an indication in the arena 
  4472. info data structure passed to the kernel. These physical pages are treated as 
  4473. "unavailable" by the virtual memory manager. 
  4474.  
  4475. During virtual device driver initialization, the physical interrupt vector 
  4476. table and ROM data area (previously allocated/reserved by the BIOS) are mapped 
  4477. with the VDHMapMem() function.  VBIOS also installs hooks which cause its own 
  4478. VDM creation handler to be invoked, and an I/O hooking routine to be invoked 
  4479. when all virtual device drivers have been initialized for a particular VDM. 
  4480.  
  4481. Space is also reserved for the EBIOS data area (if the machine is a PS/2) and 
  4482. the system ROM linear address ranges.  This allows virtual device drivers to 
  4483. use and modify this information globally (affecting all VDMs created 
  4484. thereafter). 
  4485.  
  4486. The following steps are taken when initializing the BIOS for a newly created 
  4487. VDM: 
  4488.  
  4489.  1. Map the CBIOS system area to the VDM address space, using the VDHMapMem() 
  4490.     service. 
  4491.  2. Allocate memory for the interrupt vector table and ROM BIOS data area. 
  4492.  3. Map and copy the physical interrupt vector table and ROM BIOS data area 
  4493.     into the VDMs linear address space. 
  4494.  4. Allocate memory for the extended BIOS data area in the VDM's linear address 
  4495.     space (only on PS/2s). 
  4496.  5. Map and copy the physical extended BIOS data area into the linear address 
  4497.     space. 
  4498.  
  4499. When VBIOS's VDM_CREATE_DONE handler is called (after all virtual device 
  4500. drivers' VDM_CREATE handlers have been invoked), VBIOS attempts to install I/O 
  4501. hook routines for the serial and parallel ports COMx and LPTx.  These hook 
  4502. routines will take effect only if the virtual COM device driver or the virtual 
  4503. printer device driver have not successfully hooked the I/O ports. VBIOS I/O 
  4504. hook routines are used only to display pop-up messages when the device is not 
  4505. virtualized, and to terminate the VDM on user request. 
  4506.  
  4507.  
  4508. ΓòÉΓòÉΓòÉ 15.4.2. Virtual CMOS Device Driver ΓòÉΓòÉΓòÉ
  4509.  
  4510. The virtual CMOS device driver VCMOS.SYS provides support for virtualization of 
  4511. the CMOS battery backed-up RAM, the real time clock (RTC) and the non-maskable 
  4512. interrupt (NMI) disable logic. It provides virtual access to CMOS addresses and 
  4513. data latches through virtual I/O ports. 
  4514.  
  4515. CMOS Memory Access 
  4516.  
  4517. The CMOS portion of the CMOS/RTC may be read or written.  Virtual CMOS memory 
  4518. is initialized to the contents of the physical CMOS memory upon VDM 
  4519. initialization.  Values written to CMOS memory by DOS applications are written 
  4520. in a buffer local to the VDM.  Unlike the physical CMOS memory, however, the 
  4521. contents of the virtual CMOS buffer are lost when the VDM is terminated. 
  4522.  
  4523. I/O Port Support 
  4524.  
  4525. The virtual CMOS device driver component monitors all accesses to its two VDM 
  4526. I/O ports.  The two ports are a write-only address latch and a read/write data 
  4527. latch.  The address latch port has two functions: 
  4528.  
  4529.  NMI disable 
  4530.  
  4531.  CMOS/RTC device address selection. 
  4532.  
  4533. The data latch is a register for holding a byte being transferred to or from 
  4534. the CMOS/RTC device. 
  4535.  
  4536. NMI Disable 
  4537.  
  4538. The NMI-disable portion of the address latch may be set or reset by a DOS 
  4539. application, but changes to enable or disable NMI are otherwise ignored by 
  4540. VCMOS. 
  4541.  
  4542. Real Time Clock and Interrupt Access 
  4543.  
  4544. The real time clock consists of a time-of-day clock, an alarm interrupt, and a 
  4545. periodic interrupt.  Accesses to the real time clock to change the time of day, 
  4546. the timing mode or to set an alarm or periodic interrupt are disallowed.  Thus, 
  4547. the CMOS/RTC registers related to the real time clock are supported for 
  4548. read-only access. 
  4549.  
  4550. Since interrupts can only be supported through write access to the ports, real 
  4551. time clock interrupts are not supported by VCMOS. 
  4552.  
  4553.  
  4554. ΓòÉΓòÉΓòÉ 15.4.3. Virtual DMA Device Driver ΓòÉΓòÉΓòÉ
  4555.  
  4556. The PC AT has eight DMA channels, each of which can be hard-wired to a slave 
  4557. device on the bus.  Assignments, therefore, cannot change unless the device 
  4558. adapter is reconfigured by changing jumpers.  Because of this one-to-one 
  4559. relationship, there is no separate device driver for the DMA controller.  Each 
  4560. device requiring DMA services programs the corresponding DMA channel directly 
  4561. in its device driver, as though the DMA channel were part of its own hardware. 
  4562.  
  4563. In the PS/2, virtual DMA channels may also be assigned; two of the eight 
  4564. channels, channels 0 and 4, are virtual channels which can be dynamically 
  4565. assigned to any device.  These channels can, therefore, be multiplexed to 
  4566. service more than one device.  ABIOS serializes channel accesses to avoid 
  4567. contention. 
  4568.  
  4569. Device drivers for hardware devices access the DMA channels directly, with no 
  4570. device driver required for the DMA controller itself. OS/2 Version 2.0, 
  4571. therefore, does not use a physical device driver for DMA access.  The virtual 
  4572. DMA device driver VDMA.SYS supports access to DMA ports from DOS applications 
  4573. in virtual machines. 
  4574.  
  4575. VDMA consists of port trap handlers which ignore IN/OUT commands.  The 
  4576. supported DMA services are: 
  4577.  
  4578.  Memory address and page address registers for all DMA channels 
  4579.  
  4580.  Transfer count registers for all DMA channels 
  4581.  
  4582.  Status registers 
  4583.  
  4584.  Mask registers 
  4585.  
  4586.  Mode registers 
  4587.  
  4588.  Byte pointer flip flop port 
  4589.  
  4590.  Extended function/execute ports (for PS/2 only) 
  4591.  
  4592.  Master clear ports 
  4593.  
  4594.  Command register (for PC/AT only) 
  4595.  
  4596.  Write request register (for PC/AT only). 
  4597.  
  4598. Note that VDMA does not support direct access to the DMA controller by DOS 
  4599. applications. 
  4600.  
  4601.  
  4602. ΓòÉΓòÉΓòÉ 15.4.4. Virtual Disk Device Driver ΓòÉΓòÉΓòÉ
  4603.  
  4604. The virtual disk device driver VDSK.SYS supports access to disk via the INT 13h 
  4605. CBIOS service.  Since the CBIOS accesses the hardware ports directly and may 
  4606. therefore cause problems for other processes in the system, VDSK traps the INT 
  4607. 13h interrupt and emulates the processing of this interrupt. Note that VDSK 
  4608. does not provide I/O port level access to disk controllers. 
  4609.  
  4610. The processing of an INT 13h request typically proceeds as follows: 
  4611.  
  4612.  1. The DOS application accesses the disk using INT 13h interface; the INT 13h 
  4613.     request is trapped by VDSK. 
  4614.  
  4615.  2. VDSK builds a device driver request packet and sends it to the physical 
  4616.     disk device driver.  The VDM is then blocked, waiting for the request to 
  4617.     complete. 
  4618.  
  4619.  3. The physical disk device driver processes the request packet.  If the disk 
  4620.     is currently busy, the request is queued. 
  4621.  
  4622.  4. When the request is completed, the physical disk device driver notifies 
  4623.     VDSK, which unblocks the VDM. 
  4624.  
  4625. Protected mode applications access disks via a programming interface which goes 
  4626. through the kernel's device routing mechanism and finally to the physical disk 
  4627. device driver.  The physical device driver receives an access request packet 
  4628. similar to that sent by VDSK. 
  4629.  
  4630.  
  4631. ΓòÉΓòÉΓòÉ 15.4.5. VFLPY Device Driver ΓòÉΓòÉΓòÉ
  4632.  
  4633. The virtual diskette device driver (VFLPY) intercepts virtual DOS machine 
  4634. access to the diskette drive directly or through INT 13H calls in order to 
  4635. serialize and coordinate diskette I/O between multiple virtual DOS machines. 
  4636.  
  4637.  
  4638. ΓòÉΓòÉΓòÉ 15.4.6. Virtual Keyboard Device Driver ΓòÉΓòÉΓòÉ
  4639.  
  4640. The Virtual Keyboard Device Driver VKBD.SYS provides virtualization support for 
  4641. the keyboard.  It allows keystrokes to be passed from the keyboard to virtual 
  4642. DOS machines.  It also allows for text to be pasted into the VDM as key 
  4643. strokes. 
  4644.  
  4645. Upon creation of the VDM, VKBD establishes communication with the physical 
  4646. keyboard device driver and initializes the portions of the CBIOS data area 
  4647. associated with the keyboard.  Subsequently, the physical device driver 
  4648. notifies VKBD of each scan code that is bound for the VDM. 
  4649.  
  4650. To allow monitoring of I/O activity, VKBD registers itself with the 8086 
  4651. Emulation component.  8086 Emulation then notifies VKBD when a DOS application 
  4652. in a VDM accesses a virtual keyboard port. 
  4653.  
  4654. VKBD supports two virtual I/O ports: 
  4655.  
  4656.  Port 64h - Controller Status/Command 
  4657.  
  4658.  Port 60h - Controller Input/Output Buffer. 
  4659.  
  4660. These two ports may respond to requests in a variety of ways, depending on the 
  4661. state of the controller at the time of the request. 
  4662.  
  4663. Read Output Buffer 
  4664.  
  4665. An I/O read request to port 0x60 reads the contents of the controller output 
  4666. buffer. If the "output-buffer-full" status was set before the read request, a 
  4667. timer (T1) is started.  The output-buffer-full status is then cleared.  When 
  4668. the T1 timer expires, VKBD determines if another byte is ready to be placed 
  4669. into the output buffer.  If so, the byte is placed into the output buffer and 
  4670. the "output-buffer-full" status is set. 
  4671.  
  4672. Write Output Buffer 
  4673.  
  4674. An I/O write request to port 0x60 writes the specified byte to the controller 
  4675. input buffer.  The previous contents of the input buffer are lost.  The port 
  4676. number (0x60) is saved and the byte written is processed, depending on the 
  4677. current state of the keyboard controller.  The "input-buffer-empty" status is 
  4678. never set. 
  4679.  
  4680. Status Read 
  4681.  
  4682. An I/O read request to port 0x64 simply returns the contents of the controller 
  4683. internal status register.  Reading this port has no effect on the state of the 
  4684. virtual keyboard hardware. 
  4685.  
  4686. Write Controller Command 
  4687.  
  4688. An I/O write request to port 0x64, like a write request to port 0x60, writes 
  4689. the specified byte to the controller input buffer.  Since the port number 
  4690. (0x64) is saved here, the system distinguishes between a command byte and a 
  4691. data byte.  As above, the byte written is processed, depending on the state of 
  4692. the controller, and the "input-buffer-empty" status is never set. 
  4693.  
  4694. Physical Device Driver Notification 
  4695.  
  4696. Since keystrokes are external events, it is the responsibility of the physical 
  4697. device driver to notify VKBD when keystrokes are available for processing.  In 
  4698. particular, the physical device driver calls VKBD when hardware scan codes 
  4699. arrive, and passes each scan code received to VKBD. This occurs whenever the 
  4700. keyboard's current focus is a virtual DOS machine. 
  4701.  
  4702. When called, VKBD places the scan code in a queue.  If the queue was previously 
  4703. empty, the controller "output-buffer-full" status condition is set and if 
  4704. interrupts are enabled, the Virtual Programmable Interrupt Controller is called 
  4705. to simulate the interrupt to the VDM.  If the queue was not previously empty, 
  4706. the scan code is added without any other processing.  If the queue is full, the 
  4707. speaker is sounded. 
  4708.  
  4709. INT 09h Processing 
  4710.  
  4711. In a "real" DOS environment, the IRQ1 interrupt request is translated by the 
  4712. interrupt controller, causing the INT 09h interrupt service routine to be 
  4713. invoked.  This interrupt vector normally points to a routine in the CBIOS. This 
  4714. manner of processing is not desirable in a VDM since the CBIOS only performs 
  4715. U.S. key translation; such processing would complicate the task of national 
  4716. language support.  Instead, VKBD simulates this CBIOS function, and may thus 
  4717. use whatever key translation is appropriate for the current country and code 
  4718. page. 
  4719.  
  4720. The INT 09h emulation code within VKBD performs all functions that the CBIOS 
  4721. would normally perform.  This includes: 
  4722.  
  4723.  Key and scan code enqueueing 
  4724.  
  4725.  INT 05h (Print Screen) processing 
  4726.  
  4727.  INT 15h processing for monitoring scan codes and handling the SysReq key 
  4728.  
  4729.  INT 1Bh for Ctrl+Break and Pause key processing 
  4730.  
  4731.  Key translation 
  4732.  
  4733.  Update of keyboard LEDs 
  4734.  
  4735.  Update of the CBIOS data area status. 
  4736.  
  4737. Upon termination, VKBD relinquishes access to the keyboard. 
  4738.  
  4739.  
  4740. ΓòÉΓòÉΓòÉ 15.4.7. Virtual Printer Device Driver ΓòÉΓòÉΓòÉ
  4741.  
  4742. The virtual line printer device driver VLPT.SYS supports access to three 
  4743. virtual parallel port controller devices from DOS applications running in 
  4744. virtual DOS machines. 
  4745.  
  4746. VLPT hooks INT 17h and processes requests for INT 17h services itself, rather 
  4747. than allowing these requests to be handled by CBIOS. INT 17h support includes 
  4748. support for function 02h (Read Status). 
  4749.  
  4750. VLPT does not support virtual hardware interrupts.  If a DOS application 
  4751. attempts to enable interrupts (that is, it attempts to set control port bit 4, 
  4752. "IRQ EN"), that I/O operation is ignored, and the application will not receive 
  4753. interrupts from the parallel port hardware. 
  4754.  
  4755. VLPT buffers the print data which is subsequently directed to the OS/2 spooler 
  4756. using file system services provided by the Virtual DOS Machine Manager.  The 
  4757. spooler may be configured for output on each printer device (LPTx) that will be 
  4758. accessed by DOS applications from a VDM. Figure "Virtual Printer Device Driver 
  4759. Operation" shows the various operations performed by the virtual printer device 
  4760. driver. 
  4761.  
  4762. If VLPTDD.SYS is the only virtual printer device driver installed, no INT 17 
  4763. will be issued when printing is done on numbered I/O devices (for example, 
  4764. LPT1, LPT2, etc.). However, if an application such as a TSR program must catch 
  4765. all INT 17 interrupts, the LPTDD.SYS device driver must be installed as well. 
  4766. You can find LPTDD.SYS in the subdirectory \os2\mdos. 
  4767.  
  4768. When LPTDD.SYS is available, a request from the DOS file system issuing INT 21 
  4769. is converted by LPTDD.SYS into INT 17. INT 17 is then forwarded to VLPT.SYS and 
  4770. from this point on the print request proceeds as described above in Figure 
  4771. "Virtual Printer Device Driver Operation". Note, however, that installing 
  4772. LPTDD.SYS in addition to VLPT.SYS will cause the printing from a VDM to slow 
  4773. down. 
  4774.  
  4775. Spooling 
  4776.  
  4777. In order to support spooled print output, the OS/2 spooler must be installed. 
  4778. A new IOCTL interface is defined in order to allow the spooler to identify 
  4779. itself to the physical printer device driver.  The new IOCTL functions Set 
  4780. Spooler Status and Get Spooler Status are called by the spooler and the Virtual 
  4781. DOS Machine Manager. 
  4782.  
  4783. The spooler invokes the Set Spooler Status function (Category 5, Function 4Ch) 
  4784. at spooler monitor registration time to inform the physical device driver that 
  4785. a particular port is actively configured as the output device for a particular 
  4786. spool queue.  It also invokes this interface whenever the user manipulates the 
  4787. spooler queue setup by invoking the Print Manager's Setup Printers/Change 
  4788. Printers dialog. 
  4789.  
  4790. The Virtual DOS Machine Manager invokes the Get Spooler Status function 
  4791. (Category 5, Function 6Ch) during an implicit open of a print device whenever 
  4792. VLPT processes the first print output (INT 17h) from a VDM.  This allows the 
  4793. Virtual DOS Machine Manager to determine if the spooler is active so that it 
  4794. can return the spool queue file handle to VLPT to continue printing. 
  4795.  
  4796. Print Screen 
  4797.  
  4798. VLPT also supports the Print Screen function by hooking INT 05h so that it is 
  4799. notified before the CBIOS INT 05h handler.  The CBIOS INT O5h handler invokes 
  4800. INT 17h functions, and the VLPT INT 17h emulation in turn sends this data to a 
  4801. spool file, if the spooler is active.  When the CBIOS INT 05h handler returns, 
  4802. VLPT also receives control so that it may close the spool file. 
  4803.  
  4804. File Transfer 
  4805.  
  4806. To support DOS file transfer programs which use the parallel ports (such as the 
  4807. IBM Data Migration Facility), and which typically program the parallel port 
  4808. controller directly, VLPT provides a mode known as direct I/O access. In this 
  4809. mode, the physical printer device driver grants temporary exclusive ownership 
  4810. of the parallel port hardware to the VDM in which the application is running. 
  4811. This mode allows the application to have direct access to the parallel port's 
  4812. data, status and control registers. 
  4813.  
  4814. If the port is not currently active (printing) under control of the physical 
  4815. printer device driver, the physical device driver will grant VLPT exclusive 
  4816. access to the port, and continue to service incoming file system I/O requests. 
  4817. Any incoming monitor requests from the spooler are blocked until exclusive 
  4818. access is released (no error or status monitor packets are sent to the monitor 
  4819. chain). 
  4820.  
  4821. If the physical printer device driver is actively processing a hardware I/O 
  4822. operation, when VLPT makes a request for exclusive access, the physical device 
  4823. driver will return an error code to VLPT.  VLPT will then display a pop-up 
  4824. message (via the VDHPopUp() helper service), allowing the user to select the 
  4825. most appropriate system action ("End program" or "Retry"). 
  4826.  
  4827. Note:   Due to the multitasking nature of OS/2 V2.0, data communications using 
  4828.         this type of application have an increased probability of error when 
  4829.         multiple processes are concurrently active and/or when the virtual DOS 
  4830.         machine is switched to the background. 
  4831.  
  4832. PS/2 Register Virtualization 
  4833.  
  4834. On PS/2 systems, the physical printer device driver ensures that all LPT ports 
  4835. which support extended mode (read/write 8-bit parallel I/O) will be enabled for 
  4836. extended mode at system initialization time.  On any PS/2 models which do not 
  4837. enable this mode by default, the physical printer device driver enables 
  4838. extended mode via the system's Programmable Option Select (POS) function.  This 
  4839. ensures that all PS/2 LPT ports will support manipulation of the control port 
  4840. Direction Control bit. 
  4841.  
  4842. On all PS/2 models (but not on IBM PC/AT systems), VLPT will virtualize the 
  4843. adapter enable/setup register.  All bits of this register are virtualized for 
  4844. read operations, but only bit 7 of the enable/setup register is virtualized for 
  4845. write operations.  DOS applications may modify bit 7 of this register in order 
  4846. to gain access to the system board's POS Register 2, thereby enabling or 
  4847. disabling extended mode operation of the parallel ports.  When bit 7 is set to 
  4848. 0 (the default state), the parallel port is configured as an 8-bit, parallel, 
  4849. bidirectional interface.  When bit 7 is set to 1, the parallel port 
  4850. bidirectional mode is disabled.  As described above, the physical printer 
  4851. device driver ensures that all PS/2 models have this bit set to 0 (extended 
  4852. mode enabled) during system initialization. 
  4853.  
  4854. Note that only bit 7 is virtualized and may be manipulated; attempting to 
  4855. manipulate any other bits of this register will result in termination of the 
  4856. VDM.  As the behavior is virtualized, the true state of the hardware register 
  4857. is not affected by any operations of a DOS application running in a virtual DOS 
  4858. machine. 
  4859.  
  4860. Printer Close 
  4861.  
  4862. VLPT exports the VDHPrintClose() service. This interface may be called by 
  4863. another virtual device driver such as VKBD to force any open printers in a VDM 
  4864. to close.  This technique is used to handle a forced End-of-Job 
  4865. (Ctrl+Alt+PrintScreen) character, and is required because some DOS applications 
  4866. do not explicitly close or disable the printer when their print activity is 
  4867. completed. 
  4868.  
  4869. VLPT may also close open print files whenever a VDM is terminated.  VLPT 
  4870. registers an event hook with the Virtual DOS Machine Manager, and is therefore 
  4871. notified upon termination of a VDM.  All open print files in the terminating 
  4872. VDM are closed, after any buffered data has been sent to the spooler. 
  4873.  
  4874. When operating in direct I/O access mode, VLPT can detect application 
  4875. termination in one of three ways: 
  4876.  
  4877.  PDB is changed or destroyed (default) 
  4878.  VDM is terminated 
  4879.  User hot-key (Ctrl+Alt+PrintScreen). 
  4880.  
  4881. When this termination event is detected, direct I/O access mode is cancelled 
  4882. and VLPT relinquishes the VDM's exclusive control of the parallel port 
  4883. hardware.  The physical printer device driver then reclaims ownership of the 
  4884. port and resumes normal I/O operations. 
  4885.  
  4886. Note that VLPT will not always close an open print file when the DOS 
  4887. application terminates.  Depending on the DOS application's behavior, the VDM 
  4888. may remain active when the program ends, and the spooler print file may 
  4889. therefore remain open.  If so, the user can cause the open print file(s) to 
  4890. close by using the Ctrl-Alt-PrintScreen control key sequence. Alternatively, 
  4891. the user can leave it to the system by setting the PRINT_TIMEOUT value in the 
  4892. DOS settings to the time in seconds that the operating system should wait 
  4893. before forcing the print job to the printer. Consequently there is no need to 
  4894. exit these DOS programs to have the print job released from the print spooler. 
  4895. For more information on PRINT_TIMEOUT see DOS Settings. 
  4896.  
  4897.  
  4898. ΓòÉΓòÉΓòÉ 15.4.8. Virtual Numeric Coprocessor Device Driver ΓòÉΓòÉΓòÉ
  4899.  
  4900. The virtual numeric coprocessor device driver VNPX.SYS provides virtualization 
  4901. of the 80287/80387 numeric coprocessor hardware, allowing access to numeric 
  4902. coprocessor facilities by multiple DOS applications running in virtual DOS 
  4903. machines. 
  4904.  
  4905. OS/2 Version 2.0 provides a physical device driver for the numeric coprocessor, 
  4906. within the operating system kernel.  At system initialization time, VNPX 
  4907. registers a number of hooks with the physical device driver, so that VNPX is 
  4908. informed whenever a numeric coprocessor exception or emulation trap occurs. 
  4909. Handling routines are also registered with the Virtual DOS Machine Manager, and 
  4910. are invoked upon VDM creation and termination.  Coprocessor I/O ports visible 
  4911. to V86 mode applications are hooked by VNPX. 
  4912.  
  4913. VNPX is informed by the physical device driver at initialization time, whether 
  4914. VDMs are permitted to use the coprocessor.  Upon VDM creation, VNPX sets the 
  4915. equipment summary flag for the numeric coprocessor according to the information 
  4916. received at initialization time.  In the event of the coprocessor being 
  4917. unavailable to DOS applications, the equipment summary flag is turned off.  An 
  4918. application interrogating the flag will therefore assume that no coprocessor is 
  4919. present, and take appropriate action. 
  4920.  
  4921. The first time an application in a VDM executes a coprocessor instruction 
  4922. within a particular timeslice, an exception condition (Trap 0007) occurs. The 
  4923. exception handler sets a flag within the physical device driver before allowing 
  4924. processing of the instruction to continue.  This flag is checked at task switch 
  4925. time and if it is set, the coprocessor state is saved by the physical device 
  4926. driver.  Note that the save operation takes place only if the coprocessor is 
  4927. used by an application during its timeslice; for those applications which do 
  4928. not use the coprocessor, no action is taken.  This allows optimum performance 
  4929. during task switching. 
  4930.  
  4931.  
  4932. ΓòÉΓòÉΓòÉ 15.4.9. Virtual Programmable Interrupt Controller ΓòÉΓòÉΓòÉ
  4933.  
  4934. The virtual programmable interrupt controller VPIC.SYS is a virtual device 
  4935. driver responsible for virtualization of hardware interrupts to virtual DOS 
  4936. machines.  This device driver simulates interrupts to virtual DOS machines by 
  4937. providing a virtual interface to the 8259 Programmable Interrupt Controller 
  4938. (PIC). 
  4939.  
  4940. The virtual PIC device driver supports the hardware interrupt-related services 
  4941. needed by virtual device drivers and DOS Sessions.  The services include 
  4942. setting handlers to trap EOI and IRET events, simulating interrupts to DOS 
  4943. Sessions, and handling PIC I/O accesses by DOS Sessions.  The virtual PIC 
  4944. device driver maintains a per-DOS Session virtual PIC state so that each DOS 
  4945. Session appears to have its own independent 8259 Programmable Interrupt 
  4946. Controller. 
  4947.  
  4948. This per-DOS Session virtual PIC state contains items such as the current mask, 
  4949. the current IR (interrupt request) and IS (interrupt service) registers, base 
  4950. interrupt vector and initialization mode for a particular VDM.  A per-VDM state 
  4951. machine is used to track the initialization control word (ICW) or operation 
  4952. control word (OCW) for which VPIC is waiting.  This module also invokes the 
  4953. virtual device driver's EOI handler when it receives EOI commands from a VDM. 
  4954.  
  4955. The interrupt simulation mechanism is similar to the way signals are handled 
  4956. for OS/2 applications. The virtual PIC device driver can be broken up into two 
  4957. major parts: 
  4958.  
  4959.  1. The virtualization of the PIC ports, and 
  4960.  
  4961.  2. The simulation of hardware interrupts to VDMs. 
  4962.  
  4963. Figure "Virtual Programmable Interrupt Controller" below shows this breakdown 
  4964. and the interfaces to other components, it shows the VPIC architecture and the 
  4965. role it plays in virtualizing hardware interrupts to virtual DOS machines. 
  4966.  
  4967. Not all combinations of ICWs or OCWs are supported.  Some seldom used 
  4968. initialization modes and operation commands are ignored.  These unsupported 
  4969. features are: 
  4970.  
  4971.  Slave PIC on any IRQ other than IRQ2 
  4972.  Level-triggered initialization 
  4973.  Special fully nested mode 
  4974.  Auto EOI mode 
  4975.  8080/8085 mode 
  4976.  Buffered mode 
  4977.  Special mask mode 
  4978.  Set IRQ priority command 
  4979.  Poll command 
  4980.  Rotate on specific and non-specific EOI commands. 
  4981.  
  4982. The following tables show in detail which 8259 PIC initialization and operation 
  4983. commands from a VDM are supported by the VPIC. Table "PIC Initialization 
  4984. Control Words" shows the supported and unsupported initialization control 
  4985. words. 
  4986.  
  4987. Table "PIC Operation Control Words 
  4988.  
  4989.  
  4990. ΓòÉΓòÉΓòÉ 15.4.10. Virtual Timer Device Driver ΓòÉΓòÉΓòÉ
  4991.  
  4992. The virtual timer device driver VTIMER.SYS provides virtualization of timers 
  4993. used by DOS applications running in VDMs.  Three timer ports are supported in 
  4994. order to allow reprogramming of interrupt frequency and speaker tone frequency. 
  4995. VTIMER also distributes timer ticks to VDMs and maintains a count of timer 
  4996. ticks. 
  4997.  
  4998. All accesses to the timer are simulated by VTIMER.  Therefore, unlike most 
  4999. other virtual device drivers, VTIMER has no communication with the physical 
  5000. timer.  VTIMER derives its timer tick directly from the system clock. 
  5001.  
  5002. VTIMER keeps a per-VDM cumulative timer count in the VDM's data area. When a 
  5003. periodic timer interrupt occurs, VTIMER receives control.  It adds the periodic 
  5004. interval count value to the cumulative timer count of the VDM and compares it 
  5005. with the  VDM's programmed count.  If the cumulative timer count exceeds the 
  5006. VDM's programmed count, an interrupt is simulated to the VDM and the programmed 
  5007. count is subtracted from the cumulative timer count. 
  5008.  
  5009. Timer 0 
  5010.  
  5011. This timer is normally used to provide periodic interrupts to DOS applications. 
  5012. A periodic system timer with an interval close to 18.2 milliseconds is set up 
  5013. so that VTIMER can accumulate virtual ticks and simulate tick interrupts if 
  5014. necessary. 
  5015.  
  5016. If a VDM attempts to program an interrupt period less than 18.2 milliseconds, 
  5017. the periodic timer interval will be changed to four times the normal frequency 
  5018. of 18.2 Hz, regardless of the VDM's programmed value.  A HighRate reference 
  5019. count is also kept to record the number of VDMs using a higher interrupt rate. 
  5020. As long as there is at least one VDM using a higher interrupt rate, the 
  5021. periodic rate is maintained at approximately four times 18.2 Hz.  Otherwise, 
  5022. the timer frequency is reset to 18.2 Hz. 
  5023.  
  5024. Accesses to timer count registers from within a VDM are trapped by VTIMER. 
  5025. Read accesses to the count registers should be preceded by a counter latch 
  5026. command written to the control word register, in which case a random value 
  5027. derived from the system time is latched and stored in the virtual latch 
  5028. registers.  Its purpose is to provide the applications with a sense of elapsed 
  5029. time, although the count value itself is meaningless. Read access to the count 
  5030. register is simulated by reading the virtual latch value.  Write accesses to 
  5031. the count registers are stored in the virtual count registers. 
  5032.  
  5033. Timer 1 
  5034.  
  5035. Timer 1 is used in the PC AT [Although the IBM PC AT is based on the Intel 
  5036. 80286 processor and therefore is not supported by OS/2 Version 2.0, many PC AT 
  5037. machines exist which have been fitted with processor upgrades from various 
  5038. manufacturers, which may enable them to run OS/2 Version 2.0.  Information on 
  5039. the PC AT architecture is therefore included herein for completeness. ] as the 
  5040. memory refresh request timer.  Since the correct operation of this timer is 
  5041. vital to the system, no known software reprograms it for uses other than 
  5042. reading it as the random number generator speed.  Therefore, VTIMER does not 
  5043. support any access except counter read to this timer by DOS applications.  Any 
  5044. accesses other than counter reads are trapped and ignored. 
  5045.  
  5046. Timer 2 
  5047.  
  5048. Timer 2 is the speaker tone generator.  It is accessed by DOS applications 
  5049. directly, via programming interfaces or DevHlp services, or by the VDHBeep() 
  5050. function. Serialization of the speaker usage can be achieved by using a 
  5051. semaphore in the kernel. 
  5052.  
  5053. When a DOS application accesses the speaker, it typically programs timer 2 for 
  5054. the appropriate frequency and then enables the speaker by programming the 
  5055. speaker enable bits in system control port B.  These programming operations are 
  5056. trapped by VTIMER and the frequency value is stored for the VDM.  When Control 
  5057. Port B is programmed to enable the speaker, the kernel beep service is called 
  5058. to generate the beep. This call may be blocked due to the fact that another 
  5059. process is beeping and thus owns the speaker semaphore.  After the semaphore is 
  5060. obtained, the stored frequency value is programmed into timer 2 and the speaker 
  5061. is enabled. The semaphore is released when the DOS application disables the 
  5062. speaker by programming the System Control Port B. 
  5063.  
  5064. There is one exception to the speaker serialization, and this occurs during 
  5065. interrupt time.  For example, when a process is generating a speaker tone, the 
  5066. keyboard buffer may be full and the keyboard interrupt handler needs to 
  5067. generate a warning beep immediately.  Therefore, the kernel also provides an 
  5068. interrupt time beep service which can pre-empt any ongoing beeps and use the 
  5069. speaker to generate its own beep regardless of which process currently owns the 
  5070. speaker semaphore. 
  5071.  
  5072.  
  5073. ΓòÉΓòÉΓòÉ 15.4.11. Virtual COM Device Driver ΓòÉΓòÉΓòÉ
  5074.  
  5075. The virtual COM device driver VCOM.SYS provides virtual support for the serial 
  5076. communication I/O ports and for the serial channel-related CBIOS entry points. 
  5077. It provides support in each VDM for up to two communication channels on the IBM 
  5078. PC AT and compatible systems, and up to four on the IBM PS/2 Model 80 and 
  5079. compatible PS/2 systems. 
  5080.  
  5081. VCOM only supports access to communication channels which are physically 
  5082. present on a given system.  It does not include support for accessing 
  5083. communication devices which may be redirected by network software.  For each 
  5084. supported port, VCOM searches for the port's base address in the CBIOS data 
  5085. area.  If the address is zero, indicating that the device is not present or is 
  5086. owned by a physical device driver other than the COM.SYS device driver, VCOM 
  5087. does not attempt to support that serial device. 
  5088.  
  5089. If the port's base address is found, VCOM verifies that the physical device 
  5090. driver has installed itself for that serial device.  If the physical device 
  5091. driver indicates it is not installed for that port, VCOM does not attempt to 
  5092. support that serial device. 
  5093.  
  5094. Many DOS applications that support asynchronous communications include hardware 
  5095. interrupt handler routines.  These routines typically perform I/O directly to 
  5096. the COM port hardware. To support these DOS applications and to allow them to 
  5097. run in both background and foreground, VCOM simulates hardware interrupts in 
  5098. the task-time context of the V86 mode process. VDMs are scheduled and 
  5099. dispatched using the same preemptive task dispatching method that drives OS/2 
  5100. processes.  Hardware interrupts on the other hand, occur asynchronously to this 
  5101. scheduling process.  By simulating hardware interrupts and presenting a virtual 
  5102. hardware state, the interrupt handling logic of the DOS application does not 
  5103. execute on the physical interrupt thread.  This means that switching to V86 
  5104. mode is not done at interrupt time, but is deferred until the scheduler 
  5105. dispatches the VDM task. 
  5106.  
  5107. The advantage of simulated interrupts is that mode switching and hardware 
  5108. virtualization need not be done at interrupt time.  In addition, the DOS 
  5109. application does not gain control at interrupt time, which helps to maintain 
  5110. system integrity.  A potential disadvantage of this approach is that DOS 
  5111. applications with time-critical routines may not operate correctly under some 
  5112. system load configurations. 
  5113.  
  5114. Port/Channel Contention 
  5115.  
  5116. After VDM creation, the CBIOS data area provides a logical link between the 
  5117. virtual communication channels in the VDM and the physical serial channel 
  5118. hardware.  Since VCOM does not support a COM port if its address is not in the 
  5119. CBIOS area, it can handle its own errors and/or terminate in its usual fashion 
  5120. if the DOS application does not find the device address. 
  5121.  
  5122. If the CBIOS area indicates that the device is present, however, VCOM 
  5123. determines if the device is already in use in another VDM when the DOS 
  5124. application makes its first access to that device.  If so, VCOM does not 
  5125. attempt to send the OPEN command to the physical device driver.  Instead, VCOM 
  5126. will issue a pop-up message that informs the user of the resource contention 
  5127. and allows for a user-selected action.  As a result of the user action, the 
  5128. conflict is resolved or the VDM may be terminated. 
  5129.  
  5130. If the port is not already in use, VCOM calls the physical device driver with 
  5131. the OPEN command.  This command will succeed provided the port is not currently 
  5132. in use by a protected mode process. 
  5133.  
  5134. Once the device is opened, VCOM communicates directly with the physical device 
  5135. driver to perform all virtual hardware operations.  These include sending and 
  5136. receiving data, detection and simulation of hardware interrupts, and setting or 
  5137. querying the status and control registers. 
  5138.  
  5139. CBIOS Access 
  5140.  
  5141. VCOM also supports access to CBIOS COM port services through software interrupt 
  5142. 14h.  Rather than allowing the CBIOS to perform the functions by accessing the 
  5143. virtual I/O ports directly, VCOM emulates CBIOS functions. The CBIOS access 
  5144. emulation supports six functions: 
  5145.  
  5146.  Initialize 
  5147.  
  5148.   The initialize function establishes the communication speed and framing 
  5149.   options for the channel, and returns the modem and line status.  To specify 
  5150.   bit rates of greater than 9600 bits per second, the extended initialize 
  5151.   function must be used. 
  5152.  
  5153.  Extended Initialize 
  5154.  
  5155.   The extended initialize function, like the initialize function, establishes 
  5156.   the communication speed and framing options for the channel and returns the 
  5157.   modem and line status.  This function is used if a bit rate of 19,200 bits 
  5158.   per second (or greater) is desired,  or if space or mark parity selection is 
  5159.   desired. 
  5160.  
  5161.  Send Character 
  5162.  
  5163.   The send character function sends a character to the communication channel. 
  5164.  
  5165.  Receive Character 
  5166.  
  5167.   The receive character function waits for a character from the communication 
  5168.   channel and returns the character. 
  5169.  
  5170.  Read Status 
  5171.  
  5172.   The read status function returns the modem and line status. 
  5173.  
  5174.  Extended Port Control 
  5175.  
  5176.   The extended port control function sets or reads the modem control register. 
  5177.  
  5178. DOS applications running in VDMs may access these functions using the standard 
  5179. INT 14h service, in a manner identical to that used in a native DOS 
  5180. environment. 
  5181.  
  5182. Virtual Interrupt Indication 
  5183.  
  5184. The DOS application must properly enable interrupts and the specific interrupt 
  5185. type before the interrupt will be simulated to the VDM.  The following INS8250 
  5186. interrupt types are virtualized by VCOM: 
  5187.  
  5188.  Line Status Interrupt 
  5189.  
  5190.  Receive Data Available Interrupt 
  5191.  
  5192.  Transmitter Holding Register Empty Interrupt 
  5193.  
  5194.  Modem Status Interrupt. 
  5195.  
  5196. When the physical device driver notifies VCOM of an interrupt, VCOM passes a 
  5197. virtual interrupt to the Virtual Programmable Interrupt Controller, which in 
  5198. turn simulates the interrupt to the VDM. 
  5199.  
  5200. To maintain high performance on the physical serial channel, the COM physical 
  5201. device driver typically does not notify the VCOM on every interrupt.  Rather, 
  5202. VCOM receives notification of certain events, and determines whether to begin 
  5203. or continue simulating interrupts to the VDM. 
  5204.  
  5205. Coexistence with Other Serial Device Drivers 
  5206.  
  5207. Since there is always the potential for other device drivers to own a serial 
  5208. port, VCOM does not assume ownership of any devices for which the physical COM 
  5209. device driver has not been installed.  For example, a serial mouse device 
  5210. driver may be installed and may own the COM1 serial port.  The COM physical 
  5211. device driver will not install for this port, and VCOM will therefore support 
  5212. only the higher numbered serial ports (if installed). 
  5213.  
  5214. If a physical device driver installs itself and zeros the COM port base 
  5215. addresses in the CBIOS data area, VCOM does not attempt to initialize for that 
  5216. COM port and will not assume any responsibility to virtualize the serial device 
  5217. hardware for that port.  This may result in problems for certain DOS 
  5218. applications which rely on the CBIOS data area in order to access multiple 
  5219. serial ports. 
  5220.  
  5221.  
  5222. ΓòÉΓòÉΓòÉ 15.4.12. VDPMI Device Driver ΓòÉΓòÉΓòÉ
  5223.  
  5224. The virtual DOS Protected Mode Interface(VDPMI) device driver provides Version 
  5225. 0.9 DPMI support for virtual DOS machines. DPMI applications run in protected 
  5226. mode, not V86 mode. VDPMI allows the user to specify how much protected mode 
  5227. memory should be made available to a DOS session using the DPMI_MEMORY_LIMIT 
  5228. setting in the settings notebook. 
  5229.  
  5230.  
  5231. ΓòÉΓòÉΓòÉ 15.4.13. VDPX Device Driver ΓòÉΓòÉΓòÉ
  5232.  
  5233. The virtual DOS Protected Mode Extender(VDPX) device driver provides address 
  5234. translation from protected mode to V86 mode for DPMI applications running in 
  5235. virtual DOS machines. This translation is necessary because DPMI applications 
  5236. run in protected mode but issue interrupt requests in V86 mode to perform 
  5237. systems services. 
  5238.  
  5239. The VDPX device driver registers the DOS Setting called DPMI_DOS_API. The 
  5240. available settings are: 
  5241.  
  5242. Enabled      VDPX always translates the interrupts it supports from protected 
  5243.              mode to V86 mode 
  5244.  
  5245. Auto         The application must issue an INT 2FH in protected mode to begin 
  5246.              the translation 
  5247.  
  5248. Disabled     VDPX does not perform any address translation. 
  5249.  
  5250.  
  5251. ΓòÉΓòÉΓòÉ 15.4.14. VXMS Device Driver ΓòÉΓòÉΓòÉ
  5252.  
  5253. The Extended Memory Specification (XMS) Version 2.0 provides a standard 
  5254. interface for the use of three regions of extended memory on 80286 and 80386 
  5255. machines: 
  5256.  
  5257.  High Memory Area (HMA), accessible in real mode if the A20 address line is 
  5258.   enabled 
  5259.  Extended Memory Blocks(EMBs), up to 64MB that is used for data storage 
  5260.  Upper Memory Blocks(UMBs), located between 640KB and 1MB in conventional 
  5261.   memory. 
  5262.  
  5263. The Virtual Extended Memory Specification(VXMS) device driver 
  5264.  
  5265.  Implements all the functions of XMS Version 2.0 
  5266.  Provides each virtual DOS machine with its own separate XMS emulation 
  5267.  Provides configurable limits on the amount of extended memory for each 
  5268.   virtual DOS machine separately. 
  5269.  
  5270. The VXMS device driver is installed via CONFIG.SYS, with the following syntax 
  5271. and options: 
  5272.  
  5273. Syntax 
  5274.  
  5275. DEVICE=\OS2\MDOS\VXMS.SYS [options]
  5276.  
  5277. Options 
  5278.  
  5279. /XMMLIMIT=g,i Set the global maximum memory usage of VXMS to gKB, and the per 
  5280.           virtual DOS machine limit to iKB. The default is 16384,2048. 
  5281.  
  5282. /HMAMIN=d Minimum request size in KB for an HMA request to succeed. The default 
  5283.           is 0, the maximum is 63. 
  5284.  
  5285. NUMHANDLES=n Number of handles available to each virtual DOS machine. Handles 
  5286.           are used to access EMBs. The maximum is 128 and the default is 32. 
  5287.  
  5288. /UMB      Create UMBs. The default is not to create any. 
  5289.  
  5290. /NOUMB    Do not create UMBs. This is the default setting. 
  5291.  
  5292.  
  5293. ΓòÉΓòÉΓòÉ 15.4.15. VEMM Device Driver ΓòÉΓòÉΓòÉ
  5294.  
  5295. The Lotus-Intel-Microsoft (LIM) Expanded Memory Specification (EMS) Version 4.0 
  5296. provides a standard interface for the use of expanded memory on 8086 and 8088 
  5297. machines. The specification offers up to 32MB of expanded memory divided into 
  5298. up to 255 objects that can be mapped into conventional memory. 
  5299.  
  5300. The Virtual Expanded Memory Specification (VEMM) virtual device driver: 
  5301.  
  5302.  Implements all the INT 67H functions in LIM 4.0 EMS, except those for DMA 
  5303.   registers 
  5304.  Provides each virtual DOS machine with its own separate EMS emulation 
  5305.  Supports remapping of conventional memory for use by DOS programs 
  5306.  Provides a configurable limit to EMS memory for each virtual DOS machine 
  5307.  Supports multiple physical to single logical memory mappings so that 
  5308.   different 8086 addresses can be mapped to the same expanded memory object 
  5309.   address. 
  5310.  
  5311. The VEMM device driver is installed via CONFIG.SYS, with the following syntax 
  5312. and options: 
  5313.  
  5314. Syntax 
  5315.  
  5316. DEVICE=\OS2\MDOS\VEMM.SYS [options]
  5317.  
  5318. Options 
  5319.  
  5320. /S=n      EMS memory limit per virtual DOS machine, with the default being 
  5321.           2048. This can also be set with the EMS_MEMORY_LIMIT setting in the 
  5322.           settings notebook for the virtual DOS machine. 
  5323.  
  5324. /L=n      Size of the remappable conventional memory. This can also be set with 
  5325.           the EMS_LOW_OS_MAP_REGION setting in the settings notebook for the 
  5326.           virtual DOS machine. 
  5327.  
  5328. /H=n      Size of the extra mappable memory, with the default being 32. This 
  5329.           can also be set with the EMS_HIGH_OS_MAP_REGION setting in the 
  5330.           settings notebook for the virtual DOS machine. 
  5331.  
  5332. /F=xxxx   Frame location for remapping expanded memory into conventional 
  5333.           memory. The default is AUTO. This can also be set with the 
  5334.           EMS_FRAME_LOCATION setting in the settings notebook for the virtual 
  5335.           DOS machine. The frame location may need to be moved if there is a 
  5336.           conflict with the mapping address of a physical device driver that 
  5337.           does not have a corresponding virtual device driver. Refer to DOS 
  5338.           Settings on how to use the MEMORY_INCLUDE_REGIONS and 
  5339.           MEMORY_EXCLUDE_REGIONS settings when memory conflicts occur. 
  5340.  
  5341.  
  5342. ΓòÉΓòÉΓòÉ 15.4.16. VWIN Device Driver ΓòÉΓòÉΓòÉ
  5343.  
  5344. "Seamless" WIN-OS/2 support is the ability to run Windows applications in a 
  5345. window right on top of the Workplace Shell desktop. This requires the Windows 
  5346. video device driver and the PM video device driver communicate and coordinate 
  5347. their access of the video hardware.  Each device driver effectively owns its 
  5348. piece of the screen.  Allowing the Windows display device driver to access the 
  5349. video hardware directly avoids the more cumbersome process of a thorough task 
  5350. switch. However this hardware access poses integrity problems in the areas of 
  5351. simultaneous access of hardware, rectangle invalidation handling, window 
  5352. management, and the exchange of window state information between PM and 
  5353. seamless VDMs supported by separate video device drivers. 
  5354.  
  5355. To address these problems, a high performance, interprocess communication, 
  5356. virtual device driver (VWIN.SYS) was created.  It serializes the simultaneous 
  5357. accesses to the hardware, oversees the exchange of window state information 
  5358. between PM and seamless VDMs, and establishes the addressability of PM 
  5359. resources (either directly or indirectly) by the Windows display device driver. 
  5360.  
  5361.  
  5362. ΓòÉΓòÉΓòÉ 15.4.17. Virtual Mouse Driver ΓòÉΓòÉΓòÉ
  5363.  
  5364. Given the diversity of mouse hardware, and the complexity of dealing with all 
  5365. possible combinations of mouse hardware and video equipment, few if any 
  5366. applications talk directly to mouse hardware.  Most applications which support 
  5367. a mouse do so through the INT 33h interface.  Virtualization of the INT 33h 
  5368. interface is provided by the virtual mouse device driver VMOUSE.SYS. 
  5369.  
  5370. The INT 33h interface performs the following: 
  5371.  
  5372.  Position and button tracking 
  5373.  
  5374.  Position and button event notification 
  5375.  
  5376.  Selectable pixel and mickey mappings 
  5377.  
  5378.  Video mode tracking 
  5379.  
  5380.  Video pointer management (location and appearance) 
  5381.  
  5382.  Light pen emulation. 
  5383.  
  5384. The interface between the physical mouse driver and VMOUSE is straightforward. 
  5385. The physical mouse driver is aware at all times of which session owns the 
  5386. mouse; thus, when a foreground VDM owns the mouse, it notifies VMOUSE of mouse 
  5387. events.  The events themselves remain buffered by the physical device driver 
  5388. until VMOUSE requests them.  Normally, VMOUSE asks for each event immediately, 
  5389. and updates the INT 33h data structures for the foreground VDM, unless the 
  5390. application running in the VDM has registered a mouse event subroutine. 
  5391.  
  5392. If a mouse event subroutine has been registered by the application, VMOUSE may 
  5393. have to notify the routine of a mouse event.  This depends on the events for 
  5394. which the subroutine has requested notification.  When a registered subroutine 
  5395. must be called, VMOUSE requests a fake interrupt to be simulated into the VDM. 
  5396. A fake interrupt service routine (loaded into each VDM upon creation) 
  5397. immediately emulates the interrupt and then proceeds to notify the VDM's 
  5398. registered subroutine.  In order to pick an IRQ that is guaranteed to not 
  5399. conflict with any other virtual device driver, VMOUSE queries the physical 
  5400. mouse driver at initialization time for the physical IRQ used by the mouse. 
  5401. This ensures that no conflict occurs. 
  5402.  
  5403. Position and Button Data Tracking 
  5404.  
  5405. Position and button events are interrupt time events that are communicated to 
  5406. VMOUSE by the physical device driver via a "data ready" entry point.  If the 
  5407. VDM is not already processing a previous event, VMOUSE calls the physical 
  5408. device driver to get the new event; otherwise, VMOUSE waits until previous 
  5409. event processing is complete.  This avoids the need for buffering within 
  5410. VMOUSE. 
  5411.  
  5412. Normally, the VDM will not be processing any events, so position and button 
  5413. information can be immediately retrieved and stored for later query by a VDM 
  5414. application, via INT 33h. 
  5415.  
  5416. Position and Button Event Notification 
  5417.  
  5418. As events are requested and supplied by the physical mouse driver, VMOUSE peeks 
  5419. ahead to the next event (if any) and, if it is a movement-only event, extracts 
  5420. it and overlays the current event.  This is continued until there are no more 
  5421. events, or the next event is not a movement-only event.  This reduces the 
  5422. amount of interrupt-simulation overhead during periods of rapid mouse movement. 
  5423.  
  5424. Selectable Pixel-to-Coordinate and Mickey-to-Pixel Mappings 
  5425.  
  5426. Since pixel-to-virtual-coordinate mappings are often used by DOS applications 
  5427. but are not supported for protected mode applications;  VMOUSE manages such 
  5428. mappings.  Since mickey-to-pixel mappings are supported for protected mode, 
  5429. VMOUSE relies on the physical mouse driver to perform these mappings.  Thus 
  5430. physical mouse driver interfaces are provided to set the mickey-to-pixel 
  5431. mapping and the dimensions of the screen in pixels. 
  5432.  
  5433.  
  5434. ΓòÉΓòÉΓòÉ 15.4.18. VCDROM Device Driver ΓòÉΓòÉΓòÉ
  5435.  
  5436. The VCDROM virtual device driver enables audio support for CD-ROM applications 
  5437. running in virtual DOS machines. In native DOS, audio and other IOCTL support 
  5438. is provided by the pass-through function of the CD-ROM file system driver, 
  5439. MSCDEX. VCDROM provides two features necessary to support DOS CD-ROM 
  5440. applications: 
  5441.  
  5442.  It emulates the presence of the MSCDEX 
  5443.  It translates the DOS style IOCTLs into requests that the physical CD-ROM 
  5444.   device driver can understand. 
  5445.  
  5446. VCDROM provides only audio IOCTL support and not a full emulation of MSCDEX, as 
  5447. most DOS CD-ROM applications use the standard DOS interface for file system 
  5448. services and the MSCDEX interface for audio services only. Any application that 
  5449. calls MSCDEX for file system services will not run in a virtual DOS machine. 
  5450.  
  5451.  
  5452. ΓòÉΓòÉΓòÉ 15.4.19. Virtual Video Device Driver ΓòÉΓòÉΓòÉ
  5453.  
  5454. VDM video activity consists of both port I/O and memory operations. Virtual 
  5455. video device drivers are provided to support concurrent operations by multiple 
  5456. VDMs.  A number of virtual video device drivers are provided by OS/2 Version 
  5457. 2.0, and are installed depending upon the physical display adapter types 
  5458. present in the system: 
  5459.  
  5460.  VCGA.SYS provides support for CGA devices 
  5461.  
  5462.  VEGA.SYS provides support for EGA devices 
  5463.  
  5464.  VVGA.SYS provides support for VGA devices 
  5465.  
  5466.  VSVGA.SYS provides support for SVGA devices 
  5467.  
  5468.  VEGB.SYS provides support for VGA devices when configured to operate in EGA 
  5469.   modes only 
  5470.  
  5471.  V8514.SYS provides support for the display adapter 8514/A 
  5472.  
  5473.  VXGA.SYS provides support for the XGA display adapter. 
  5474.  
  5475. In the following discussion, the term VVIDEO will be used generically to refer 
  5476. to all virtual video device drivers. 
  5477.  
  5478. By trapping all I/O operations and mapping a virtual video memory buffer to the 
  5479. region where a VDM expects physical video memory, VVIDEO insulates the physical 
  5480. hardware from background VDM  activity.  Only a foreground VDM's video 
  5481. operations are allowed to write directly to the physical hardware. 
  5482.  
  5483. The major IBM adapter types (MONO, CGA, EGA, VGA, XGA and 8514) are fully 
  5484. supported by VVIDEO, in that it supports all standard modes of operation for 
  5485. multiple VDMs (concurrently, if all VDMs are running in text modes). 
  5486.  
  5487. The following is a list of the video configurations supported and their default 
  5488. mode of operation: 
  5489.  
  5490. Table "List of Supported Video Configurations" 
  5491.  
  5492. As in a native DOS environment, the default setting of the equipment flags 
  5493. determines which display adapter is the primary display.  VVIDEO examines this 
  5494. to determine which will be the primary display. The video signal for secondary 
  5495. displays is initially disabled, until such time as a MODE command or user 
  5496. application explicitly enables it. 
  5497.  
  5498. VDM Screen-Switching 
  5499.  
  5500. The OS/2 Version 2.0 session manager informs VVIDEO whenever a VDM's display 
  5501. state changes, ensuring that no more than one foreground VDM exists at any 
  5502. point in time, and that no VDMs are regarded as foreground processes while any 
  5503. other protected mode process, including the operating system shell, is in 
  5504. foreground.  This mutually exclusive activity relationship between VVIDEO and 
  5505. OS/2 display drivers ensures screen integrity. 
  5506.  
  5507. VDMs in background are switchable at any time since their state is maintained 
  5508. in memory by VVIDEO, rather than in the device itself.  32KB of virtual video 
  5509. buffer memory is allocated by VVIDEO for each VDM upon creation.  This is the 
  5510. maximum buffer size addressable in any text mode. When the VDM is switched to 
  5511. foreground, the video buffer is reallocated to the maximum size supported by 
  5512. the adapter, with a limit of 256KB. 
  5513.  
  5514. The act of switching a VDM from foreground to background or vice versa requires 
  5515. that the calling routine yield control, and hence there may be a time delay 
  5516. during the switch.  In order to preserve the integrity of the video buffer, the 
  5517. VDM is suspended for the duration of the screen switch, to avoid any portion of 
  5518. the video state that was already copied to or from the hardware being changed 
  5519. before the switch is complete. 
  5520.  
  5521. Foreground VDM Support 
  5522.  
  5523. There are literally no limits to what a VDM can do with video hardware when 
  5524. running in foreground, since it has complete access to all ports and device 
  5525. memory through VVIDEO.  I/O trapping is still operative, but only to "shadow" 
  5526. changes and ensure the ability to switch screens. 
  5527.  
  5528. Background VDM Support 
  5529.  
  5530. VDMs running in the background must always use virtual video memory, which is 
  5531. actually normal system memory that has been mapped into the VDM's video address 
  5532. space.  In cases where the selected video mode (typically a graphics mode) 
  5533. requires multiple planes of video memory, normal system memory is inadequate to 
  5534. effectively virtualize video memory. 
  5535.  
  5536. Whenever a VDM running the in background places the video hardware in a 
  5537. multi-plane graphics mode, virtual video memory is invalidated and if touched, 
  5538. results in the VDM being "frozen". If the VDM returns to a single-plane video 
  5539. mode (implying that it never accessed video memory), then its virtual video 
  5540. memory is validated once more.  This approach allows VDMs to switch between 
  5541. different text modes entirely in background, without the risk of being frozen. 
  5542.  
  5543. To support graphics operation in the background, VVIDEO must trap all video 
  5544. memory references and remap them to a set of simulated planes, or use some form 
  5545. of hardware-assisted virtualization that Presentation Manager and the other 
  5546. OS/2 processes know nothing about. 
  5547.  
  5548. Suspended Background VDM:  There are three cases in which DOS graphics 
  5549. applications may be suspended (receive no processor time) when running in the 
  5550. background: 
  5551.  
  5552.  1. A DOS multiplane graphics application that uses advanced graphics, such as 
  5553.     640x480x16 or 640x350x16, will be suspended, regardless of the graphics 
  5554.     adapter installed, if any other DOS application is running in the 
  5555.     foreground in a full-screen session. 
  5556.  
  5557.  2. A DOS multiplane graphics application that uses advanced graphics, such as 
  5558.     640x480x16 or 640x350x16, will be suspended when a Presentation Manager 
  5559.     session is running in the foreground in XGA mode. Currently, this situation 
  5560.     occurs even if you have an Extended Graphics Array (XGA) and a Video 
  5561.     Graphics Array (VGA) adapter connected to your system. 
  5562.  
  5563.  3. A DOS multiplane graphics application that uses 1024x768x16 graphics mode 
  5564.     will be suspended when a Presentation Manager session is running in the 
  5565.     foreground in 8514/A mode. 
  5566.  
  5567. Note that suspending DOS applications running in the background generally poses 
  5568. no problems unless the applications are timing-dependent, such as 
  5569. communications or process-control applications. In these cases, suspending them 
  5570. may cause them to fail. Avoid this situation by running these applications in 
  5571. the foreground in full-screen sessions only. If they are graphics applications, 
  5572. run them only in a single-plane mode, such as 640x200x2, 320x200x256, or 
  5573. 640x480x2, in full-screen sessions. 
  5574.  
  5575. Note also that for WIN-OS/2 sessions, set the VIDEO_SWITCH_NOTIFICATION DOS 
  5576. setting to ON to avoid having Windows programs suspended when running in the 
  5577. background. 
  5578.  
  5579. Graphical Applications Programs Support:  OS/2 Version 2.0 supports a broad 
  5580. variety of display-adapter hardware as you can see from Table "Graphical 
  5581. Applications Programs Support under OS/2 Version 2.0". This allows OS/2 
  5582. programs, DOS programs, and Windows programs to run in both windowed and 
  5583. full-screen sessions. OS/2, DOS, and Windows programs can run successfully in 
  5584. both the foreground and the background.  Normally, the OS/2 user need not be 
  5585. concerned with the graphics modes that are used within a program, or whether a 
  5586. program will run successfully in a background session. 
  5587.  
  5588. Some types of display adapters do, however, place limits on the ability of the 
  5589. OS/2 operating system to run certain classes of DOS and Windows graphics 
  5590. programs in the background. The limits exist because of the difficulty of 
  5591. providing virtual access to the display-adapter hardware without disturbing 
  5592. either the foreground session or other background sessions. 
  5593.  
  5594. Under certain conditions, DOS applications that use graphical display modes 
  5595. will become suspended in background sessions when they attempt to write to the 
  5596. display. 
  5597.  
  5598. Table "Graphical Applications Programs Support under OS/2 Version 2.0" gives 
  5599. you an overview of what happens with graphical applications programs in 
  5600. combination with different display adapters. 
  5601.  
  5602. To determine under what conditions your applications will run in a background 
  5603. session in Table "Graphical Applications Programs Support under OS/2 Version 
  5604. 2.0" as described now: 
  5605.  
  5606.  1. Find your graphical display hardware in the "Type of Video" column. 
  5607.  
  5608.  2. Find your System Desktop Mode. 
  5609.  
  5610.  3. Read across the table to your application column. 
  5611.  
  5612. For example, assume you have a DOS application using VGA mode on a system with 
  5613. VGA video. The application is in full-screen. To determine if the application 
  5614. will be suspended: 
  5615.  
  5616.  1. Find your type of video (VGA) in the "Type of Video" column. 
  5617.  
  5618.  2. Find your System Desktop Mode (VGA). 
  5619.  
  5620.  3. Read across the table to your application column (DOS Application, Matches 
  5621.     Desktop Mode, Full-Screen). 
  5622.  
  5623. The PF indicates that the DOS application runs when PM has control of the 
  5624. screen or when the application is in a foreground session. 
  5625.  
  5626. Device-Independent Pointer Services 
  5627.  
  5628. VVIDEO provides services which allow the virtual mouse driver to define a 
  5629. pointer image and specify its position.  Since the position must always be 
  5630. given relative to the physical dimensions of the VDM's screen, and since 
  5631. coordinates may change whenever the video mode is reset, the virtual mouse 
  5632. driver provides an entry point which is notified of such changes by VVIDEO. 
  5633. These interfaces are device-independent because dimensions are always given in 
  5634. terms of pixels or character cells, and not in predefined video mode 
  5635. identifiers.  By separating the pointer-drawing code from the virtual mouse 
  5636. driver, mouse support becomes automatically available on any video adapter. 
  5637.  
  5638. Font Support 
  5639.  
  5640. At VDM creation time only a single font exists; this is either a default font 
  5641. contained in video ROM, or one specified by OS/2 if code page support is 
  5642. active.  In the latter case, VVIDEO automatically loads the OS/2 code page font 
  5643. whenever the VDM restores the default ROM font by resetting the video mode. 
  5644.  
  5645. Note that since the process of loading a font is essentially the same as 
  5646. entering a graphics mode, background VDMs will "freeze" if they attempt this. 
  5647.  
  5648. Clipboard Support 
  5649.  
  5650. To transfer VDM screen contents to the clipboard, VVIDEO provides two services: 
  5651. one to return the VDM's video configuration, and a second to copy the video 
  5652. contents to a shell-supplied buffer address.  The shell then handles the 
  5653. transfer from this buffer to the clipboard. 
  5654.  
  5655.  
  5656. ΓòÉΓòÉΓòÉ 15.5. Virtual Device Helper Services ΓòÉΓòÉΓòÉ
  5657.  
  5658. In order to allocate, free and reallocate memory, virtual device drivers use 
  5659. the virtual device helper (VDH) memory management services. These services help 
  5660. the virtual device driver maintain a linear heap for each VDM.  This heap is 
  5661. maintained as a linked list; each entry in this linked list refers to a linear 
  5662. region with attributes such as: 
  5663.  
  5664.  Reserved 
  5665.  Allocated 
  5666.  Mapped 
  5667.  Page granular 
  5668.  Byte granular. 
  5669.  
  5670. Memory allocation is always done in chunks of 4KB (page granular), but byte 
  5671. granular services are provided for handling instance data reservations and for 
  5672. memory allocation in the DOS environment. 
  5673.  
  5674.  
  5675. ΓòÉΓòÉΓòÉ 15.5.1. Memory Management ΓòÉΓòÉΓòÉ
  5676.  
  5677. VDH services provide the following support for memory management within virtual 
  5678. device drivers: 
  5679.  
  5680.  Allocation/reallocation/freeing services for: 
  5681.  
  5682.    - Global and per-VDM objects 
  5683.    - Page and byte granular objects 
  5684.    - Options for fixed, swappable allocations. 
  5685.  
  5686.  Allocation of memory in DOS environment 
  5687.  
  5688.  Reserve specified linear space 
  5689.  
  5690.  V86-mode stack manipulation 
  5691.  
  5692.  Mapping services: 
  5693.  
  5694.    - Map to physical address 
  5695.    - Map to linear address 
  5696.    - Map to invalid address 
  5697.    - Map to black holes (don't care) pages 
  5698.  
  5699.  Copy/exchange services 
  5700.  
  5701.  Block management services (pools of equal-size memory blocks) 
  5702.  
  5703.  Query services: 
  5704.  
  5705.    - Query the biggest linear space in a specified range 
  5706.    - Query dirty bits for set of pages 
  5707.    - Query amount of free virtual memory. 
  5708.  
  5709.  
  5710. ΓòÉΓòÉΓòÉ 15.5.2. Semaphore Services ΓòÉΓòÉΓòÉ
  5711.  
  5712. These services are used to synchronize a virtual device driver with another 
  5713. OS/2 process.  If a virtual device driver blocks a VDM process, that VDM will 
  5714. not receive any simulated hardware interrupts until it becomes unblocked.  VDH 
  5715. semaphore services are used to handle the following: 
  5716.  
  5717.  Mutual exclusion and event semaphores 
  5718.  OS/2 process to physical device driver communication 
  5719.  Virtual device driver/physical device driver communication 
  5720.  VDM event list management. 
  5721.  
  5722.  
  5723. ΓòÉΓòÉΓòÉ 15.5.3. Freeze/Thaw Services ΓòÉΓòÉΓòÉ
  5724.  
  5725. The virtual video device driver uses these services to freeze and unfreeze the 
  5726. operation of a VDM.  This is typically required in response to a video mode 
  5727. switch in a background VDM, which would place the VDM in a video mode not 
  5728. supported when running in the background. 
  5729.  
  5730.  
  5731. ΓòÉΓòÉΓòÉ 15.5.4. Timer/Priority Services ΓòÉΓòÉΓòÉ
  5732.  
  5733. Timer services are provided to support the virtual programmable interrupt 
  5734. controller in the event of a time out occurring in an interrupt handler. 
  5735. Priority services are also used by VPIC to handle VDM scheduling priority. 
  5736.  
  5737.  
  5738. ΓòÉΓòÉΓòÉ 15.5.5. Page Fault Services ΓòÉΓòÉΓòÉ
  5739.  
  5740. A virtual device driver may register its own handler for page fault exceptions, 
  5741. in order to handle such events in an orderly manner.  VDH services are provided 
  5742. in order to support this registration. 
  5743.  
  5744.  
  5745. ΓòÉΓòÉΓòÉ 15.5.6. Other Services ΓòÉΓòÉΓòÉ
  5746.  
  5747.  Error message and display 
  5748.  Terminate VDM service 
  5749.  
  5750.  
  5751. ΓòÉΓòÉΓòÉ 15.5.7. VDH Functions ΓòÉΓòÉΓòÉ
  5752.  
  5753. The following list summarizes most of the VDH functions: 
  5754.  
  5755. VDH API                    Description 
  5756. VDHAllocDosMem             Reserve memory for stub DOS device driver 
  5757. VDHAllocMem                Allocate small buffers 
  5758. VDHAllocPages              Allocate linear space and commit backing storage 
  5759. VDHArmReturnHook           Used to catch return from a VDHPushFarCall 
  5760. VDHArmSTIHook              Receive control when current DOS session enables 
  5761.                            simulated interrupts 
  5762. VDHClearVIRR               Clear interrupt request flag 
  5763. VDHClearSem                Used to protect global structures 
  5764. VDHCloseVDD                Terminate communication between virtual device 
  5765.                            driver and physical device driver 
  5766. VDHCopyMem                 Used by the EMM copy service and to copy device 
  5767.                            driver stub to VDM 
  5768. VDHExchangeMem             Used by the EMM exchange service 
  5769. VDHFindFreePages           Find a region of free linear space below 1MB + 64KB 
  5770. VDHFreeMem                 Deallocate small buffers 
  5771. VDHFreePages               Deallocate memory objects 
  5772. VDHGetDirtyPageInfo        Read and clear dirty-page bits (Dirty bits indicate 
  5773.                            whether a page has been written to) 
  5774. VDHInstallFaultHook        Install hook for page faults 
  5775. VDHInstallIntHook          Used to hook INT 67h (EMS interrupt) 
  5776. VDHInstallUserHook         Register to get notification about VDM creation and 
  5777.                            termination 
  5778. VDHLockMem                 Verifies that a specified memory region is available 
  5779.                            and locks it 
  5780. VDHMapPages                Used to map EMS windows to EMS objects or to unmap 
  5781.                            pages 
  5782. VDHNotIdle                 Resets VDHPostIdle 
  5783. VDHOpenVDD                 Establish communication between virtual device 
  5784.                            driver and physical device driver 
  5785. VDHOpenVIRQ                Returns an IRQ handle for use with the other VPIC 
  5786.                            services 
  5787. VDHPopInt                  Remove ROM return address from user's CS:IP 
  5788. VDHPostIdle                Put VDM into sleeping state. 
  5789. VDHPushFarCall             Used by the EMM map and call service 
  5790. VDHPushInt                 Change control to the V86-interrupt handler 
  5791. VDHQueryConfigString       Used to retrieve configuration data strings 
  5792. VDHQueryFreePages          Determine amount of free virtual memory 
  5793. VDHQuerySysValues          Determine VDM conventional memory size 
  5794. VDHReallocPage             Change previous page allocation 
  5795. VDHRequestSem              Used to protect global data 
  5796. VDHRequestVDD              Requests the operation of a VDD 
  5797. VDHReservePage             Reserve region of linear space below 1MB + 64KB 
  5798. VDHSetDOSDevic             Register DOS device driver 
  5799. VDHSetVIRR                 Set interrupt request flag 
  5800. VDHUnreservePages          Unreserve region of linear space below 1MB + 64KB 
  5801. VDHWakeIdle                Awake VDM from sleeping state 
  5802. VDHYield                   Yield the processor to any other thread of equal or 
  5803.                            higher priority 
  5804.  
  5805. These functions are only valid when issued from within a module executing at 
  5806. privilege level 0; they cannot be issued by normal protected mode application 
  5807. processes. 
  5808.  
  5809.  
  5810. ΓòÉΓòÉΓòÉ 15.6. VDM Termination ΓòÉΓòÉΓòÉ
  5811.  
  5812. Virtual device drivers are responsible for a number of actions upon termination 
  5813. of a VDM. The nature of these actions is largely dependent on whether the VDM 
  5814. terminates normally or abnormally. 
  5815.  
  5816.  
  5817. ΓòÉΓòÉΓòÉ 15.6.1. Normal Termination ΓòÉΓòÉΓòÉ
  5818.  
  5819. A virtual device driver typically registers a VDM_TERMINATE hook with the 
  5820. Virtual DOS Machine Manager, which causes the virtual device driver to be 
  5821. informed when a VDM is terminated.  When the VDM_TERMINATE hook is called, the 
  5822. virtual device driver is responsible for freeing all resources allocated on 
  5823. behalf of the terminating VDM. 
  5824.  
  5825.  
  5826. ΓòÉΓòÉΓòÉ 15.6.2. Abnormal Termination ΓòÉΓòÉΓòÉ
  5827.  
  5828. Virtual device drivers may experience a number of different error conditions, 
  5829. and must be able to act in order to recover from such errors where possible. 
  5830.  
  5831. Errors Returned from VDH Services 
  5832.  
  5833. Requests for VDH services may be refused by the operating system or may fail 
  5834. due to lack of resources.  For example, a call to VDHAllocMem() may return 0, 
  5835. indicating that the memory allocation request cannot be satisfied. 
  5836.  
  5837. During initialization of the virtual device driver or creation of a VDM such an 
  5838. error would cause the initialization or creation to be terminated. During 
  5839. execution of a DOS application, the virtual device driver should return control 
  5840. to the application, indicating the failure of the requested application 
  5841. service.  If this cannot be done, the VDM must be terminated. 
  5842.  
  5843. Bad Parameter Passed to VDH Service 
  5844.  
  5845. A virtual device driver may make a service request with bad data, typically due 
  5846. to a bug in the device driver code; such events are likely during development 
  5847. and testing.  For example, the virtual device driver may attempt to issue a 
  5848. VDHFreeMem() function call specifying an address which was not previously 
  5849. allocated using VDHAllocMem(). 
  5850.  
  5851. Such errors are costly; since virtual device drivers operate at privilege level 
  5852. 0 and hence have access to all code and data in the system, it is impossible to 
  5853. localize the effect to a single VDM, or to be certain that the event has not 
  5854. corrupted data or control structures in the operating system kernel.  In such 
  5855. cases, the Virtual DOS Machine Manager will halt the system. 
  5856.  
  5857. Virtual Device Driver Consistency Failures 
  5858.  
  5859. A virtual device driver may detect inconsistencies within its own state 
  5860. information.  Such inconsistencies may be experienced in either global or 
  5861. instance state data.  The virtual device driver must inform the user of the 
  5862. error.  If the error can be isolated to the instance data of a single VDM, that 
  5863. VDM must be terminated.  If the error is in global state data, it will be 
  5864. necessary to halt the system. 
  5865.  
  5866. Note that halting the entire system is highly unfriendly behavior on the part 
  5867. of a virtual device driver.  Very rarely, if ever, should such action become 
  5868. necessary.  A virtual device driver should take all possible steps to isolate 
  5869. any state inconsistencies to a single VDM only. 
  5870.  
  5871. Illegal Operation by a DOS Application 
  5872.  
  5873. DOS applications running in VDMs may issue illegal instructions.  For example, 
  5874. a DOS application may issue an OUT instruction to a port controlled by the 
  5875. virtual disk device driver, which does not support direct hardware control of 
  5876. the disk controller. 
  5877.  
  5878. In such cases, the virtual device driver must inform the user of the error 
  5879. condition and either ignore the error or terminate the VDM and the application 
  5880. within it. 
  5881.  
  5882.  
  5883. ΓòÉΓòÉΓòÉ 15.7. Summary ΓòÉΓòÉΓòÉ
  5884.  
  5885. OS/2 Version 2.0 provides device drivers to handle the interface between the 
  5886. operating system and the hardware.  Physical device drivers are used by normal 
  5887. protected mode processes running OS/2 applications, while virtual device 
  5888. drivers are used by DOS applications running in virtual DOS machines. 
  5889.  
  5890. Virtual device drivers provide a means of representing hardware devices to a 
  5891. DOS application in a virtual DOS machine, such that the devices appear to the 
  5892. application as though the application had sole control over the device.  In 
  5893. this way, MVDM allows DOS applications to issue instructions which directly 
  5894. manipulate hardware devices or the DOS system environment, while maintaining 
  5895. full protection of other applications in the system.  Virtual device drivers 
  5896. typically access hardware by requesting services from physical device drivers. 
  5897.  
  5898. Virtual device drivers are used not only for shared hardware devices, but also 
  5899. for other aspects of the machine environment, such as BIOS, CMOS, and the 
  5900. (physical) programmable interrupt controller.  Through the use of virtual 
  5901. device drivers for these components, DOS applications may freely access and 
  5902. manipulate them without affecting other DOS applications or OS/2 applications 
  5903. in the system. 
  5904.  
  5905. OS/2 Version 2.0 provides a number of standard virtual device drivers for the 
  5906. DOS system environment and common hardware devices.  Hardware vendors may 
  5907. develop virtual device drivers for their own hardware adapters.  Note that if a 
  5908. hardware device will be dedicated to one application (that is, sharing of the 
  5909. hardware is not required) then a virtual device driver is not needed; the 
  5910. normal DOS device driver will allow the application to access the hardware 
  5911. device as in a native DOS environment. 
  5912.  
  5913. A virtual device driver operates at privilege level 0, and therefore cannot 
  5914. access operating system services via the normal application programming 
  5915. interfaces provided by OS/2 Version 2.0.  Instead, a set of virtual device 
  5916. helper services is provided to enable virtual device drivers to access system 
  5917. services.  Virtual device drivers may be written in a high-level language such 
  5918. as "C". 
  5919.  
  5920.  
  5921. ΓòÉΓòÉΓòÉ 16. Memory Extender Support ΓòÉΓòÉΓòÉ
  5922.  
  5923. Many popular DOS applications use memory extenders such as EMS and/or XMS to 
  5924. gain access to memory above the 1MB real mode addressing limit on the 80286, 
  5925. 80386, or 80486 processors.  Such extenders allow DOS applications to have 
  5926. total code and data spaces larger than the available base memory, and to have 
  5927. very large code or data objects loaded into memory for enhanced execution 
  5928. speed.  The standard configuration of OS/2 Version 2.0 provides both LIM EMS 
  5929. Version 4.0 (which includes backward compatibility with LIM Version 3.X) and 
  5930. LIMA XMS Version 2.0 functions for DOS applications running in virtual DOS 
  5931. machines. 
  5932.  
  5933. Figure "General Overview of Different Types of Memory for DOS Applications" 
  5934.  
  5935. This chapter describes the implementation of EMS and XMS support for virtual 
  5936. DOS machines.  For those readers not already familiar with the architecture of 
  5937. these memory extenders, an overview is provided in Memory Extender 
  5938. Architectures. 
  5939.  
  5940.  
  5941. ΓòÉΓòÉΓòÉ 16.1. Expanded Memory Support ΓòÉΓòÉΓòÉ
  5942.  
  5943. OS/2 Version 2.0 supports expanded memory according to the LIM EMS Version 4.0. 
  5944. Under DOS, special hardware is normally required to support EMS, although a 
  5945. number of software-based EMS emulation packages exist.  MVDM supports EMS by 
  5946. mapping memory allocation requests into the linear process address space, using 
  5947. normal system memory.  Hence no special hardware or software is required. 
  5948.  
  5949. The OS/2 Version 2.0 LIM EMS emulation provides the following function: 
  5950.  
  5951.  Implements all the required functions in the LIM EMS Version 4.0. 
  5952.  
  5953.  Provides each VDM with a separate EMS emulation.  Each VDM has its own set of 
  5954.   expanded objects so that features like interprocess communication work as 
  5955.   they would if each VDM were running on a different real 80386. Each VDM 
  5956.   cannot affect the availability of objects in other VDMs or access memory in 
  5957.   other VDMs. 
  5958.  
  5959.  Provides for remapping of conventional memory (below 640KB) for use by 
  5960.   programs like Windows 2.0. 
  5961.  
  5962.  Provides configurable limits for how much EMS memory is available across 
  5963.   VDMs, as well as a limit per VDM.  The DOS Settings feature allows the user 
  5964.   to override the per-VDM  limit, subject to the constraint given by the 
  5965.   overall limit. 
  5966.  
  5967.  Supports multiple physical to single logical mappings.  Different 8086 
  5968.   addresses can map to the same expanded memory object address. This is 
  5969.   required by programs like Lotus 1-2-3. 
  5970.  
  5971.  EMS can be removed and the operating system can run without loading EMS in 
  5972.   any VDM session. 
  5973.  
  5974. Memory objects are mapped into the V86 mode address space (below 1MB), so DOS 
  5975. applications can access very large address spaces.  Applications access EMS 
  5976. services using the DOS interrupt INT 67h. 
  5977.  
  5978.  
  5979. ΓòÉΓòÉΓòÉ 16.1.1. Virtual Expanded Memory Manager ΓòÉΓòÉΓòÉ
  5980.  
  5981. EMS services are implemented under MVDM using a virtual device driver known as 
  5982. the Virtual Expanded Memory Manager (VEMM), which offers a separate EMS 
  5983. emulation to each VDM. This implementation is accomplished by placing most VEMM 
  5984. control structures in a per-VDM data area outside the V86 mode address space. 
  5985. Each VDM has up to 255 handles, 15 alternate register sets, remappable 
  5986. conventional memory for operating system use, and a 16KB "raw" block size. 
  5987.  
  5988. VEMM prehooks interrupt vector 67h through a VDH service to catch software 
  5989. interrupts for EMS services.  Prehooking means that VEMM gains control before 
  5990. the V86 mode interrupt vector is called. VEMM also provides a V86 mode stub 
  5991. driver used to indicate to DOS applications that EMS is available. This stub 
  5992. must hook INT 67h so that applications can find a particular string in the 
  5993. header to determine if EMS is available. When, as in the typical case, 
  5994. applications have not also hooked INT 67h, VEMM handles service requests at 
  5995. prehook time. When INT 67 has been hooked, VEMM handles requests when the 
  5996. stub's hook calls it by doing an INT 67h from inside the stub. 
  5997.  
  5998. To prevent VDM's from grabbing large amounts of EMS memory, there is a 
  5999. configurable default per VDM limit.  VEMM depends heavily upon the memory 
  6000. manager. EMS object allocation, reallocation, or deallocation is accomplished 
  6001. by requesting corresponding services from VDH services. Most VEMM creation time 
  6002. setup is postponed until the first INT 67h service request is made. Figure 
  6003. "Expanded Memory Manager Control Flow" shows the flow of control when a DOS 
  6004. application makes an EMS service request from within a VDM: 
  6005.  
  6006.  1. INT 67h service requests are trapped by the Virtual DOS Machine Manager and 
  6007.     routed to VEMM. 
  6008.  
  6009.  2. The VEMM makes the appropriate requests to VDH services to allocate or 
  6010.     manipulate the EMS object. 
  6011.  
  6012. Expanded Memory Manager Control Flow 
  6013.  
  6014. During the initialization of the VDM the VDM Manager loads and initializes the 
  6015. EMS DOS stub device driver into the VDM address space. 
  6016.  
  6017. The VDM Application can use either of two methods to test for the existence of 
  6018. the VEMM: 
  6019.  
  6020.  1. Issue an open request (INT 21h Function 3DH) using the guaranteed device 
  6021.     name of the VEMM driver. If the open function succeeds, either the driver 
  6022.     is present or a file with the same name coincidentally exists on the 
  6023.     default disk drive. To rule out the latter, the application can use 
  6024.     IOCTL(INT 21h Function 44H) subfunctions 00h and 07h to ensure that VEMM is 
  6025.     present. Don't forget to use INT 21H Function 3Eh to close the handle that 
  6026.     was obtained from the open function, so that the handle can be reused for 
  6027.     another file or device. 
  6028.  
  6029.  2. Look for a special signature in the EMS DOS stub device driver which 
  6030.     signals the VDM Application that EMS is available. This search is done by 
  6031.     using the address that is found in the INT 67h vector to inspect the device 
  6032.     header of the presumed VEMM which is, in this case, the fooling EMS DOS 
  6033.     stub device driver. Interrupt handlers and device drivers must use this 
  6034.     method. If the VEMM seems to be present, the name field at a special offset 
  6035.     of the device header contains a special string. This method is not only 
  6036.     avoiding the relatively high overhead of an VDM DOS open function but is 
  6037.     nearly foolproof. However, it is somewhat less well behaved because it 
  6038.     involves inspection of memory that does not belong to the application. 
  6039.  
  6040.     The only task of the EMS DOS stub device driver is to tell the VDM DOS 
  6041.     application that EMS is available. As soon as this is done the regular EMS 
  6042.     business can start as explained in the following points: 
  6043.  
  6044.  1. The VDM Application issues a INT 67h service request. 
  6045.  
  6046.  2. The VDM Manager loads the VEMM. 
  6047.  
  6048.  3. The VDM Manager initialization, creation, termination calls for 
  6049.     EMM-objects. 
  6050.  
  6051.  4. The VDM Manager traps the VDM application's INT 67h service request and 
  6052.     routes it to VEMM. 
  6053.  
  6054.  5. The VDM callback for V86 call with far return. 
  6055.  
  6056.  6. The VEMM requests corresponding services from the VDH services: 
  6057.  
  6058.     Creation/termination handler registration 
  6059.  
  6060.     INT 67h pre-hooking 
  6061.  
  6062.     Linear address reservation 
  6063.  
  6064.     Memory management. 
  6065.  
  6066.  7. The result is returned. 
  6067.  
  6068. This constellation also allows a VDM application to hook INT 67h. 
  6069.  
  6070. Note that unlike most virtual device drivers, VEMM does not have a 
  6071. corresponding physical device driver.  Instead, VEMM manages its memory using 
  6072. the OS/2 Version 2.0 operating system kernel's memory management services. EMS 
  6073. object allocation, reallocation, or deallocation is accomplished by requesting 
  6074. corresponding services from the operating system's memory manager.  For 
  6075. example, when an application requests the allocation of an expanded memory 
  6076. object, VEMM asks the memory manager to allocate a memory object in linear 
  6077. memory outside any VDM. 
  6078.  
  6079. Structure 
  6080.  
  6081. The VEMM module consists of: 
  6082.  
  6083.  An Initialization Component that determines the default size at boot time 
  6084.  
  6085.  A Creation Component that initializes per-VDM structures when a VDM is 
  6086.   created 
  6087.  
  6088.  A Router that decodes application INT 67h (and routes the call to a service 
  6089.   routine) and 30 service routines with associated sub-services. 
  6090.  
  6091. Each VDM has a 255-entry EMS handle table used to keep track of the size and 
  6092. allocation of expanded memory objects, 16 register sets that indicate which 
  6093. parts of the expanded objects are mapped into the VDM address space, and save 
  6094. tables to save register set contents.  Only one register set is active at a 
  6095. time.  That active register set indicates the actual page table contents. 
  6096. Switching register sets or restoring a saved register set resets all aliases in 
  6097. the windows to those indicated by the new register set.  Unmapped pages are set 
  6098. to "black hole" memory.  The memory manager's page size for all these 
  6099. operations is 4KB.  VEMM makes the adjustment for its 16KB page size. 
  6100.  
  6101. Initialization 
  6102.  
  6103. VEMM is typically installed at system initialization time, via a DEVICE= 
  6104. statement in CONFIG.SYS, as shown below: 
  6105.  
  6106. DEVICE=C:\OS2\MDOS\VEMM.SYS 4096, 2048
  6107.  
  6108. To prevent VDMs from using all available memory, there is an overall limit on 
  6109. the amount of EMS memory, and a default limit for each VDM to prevent a VDM 
  6110. from requesting all available EMS memory.  The defaults for these limits are 
  6111. specified in the DEVICE= statement for VEMM.  The default limit for each VDM 
  6112. may be overridden using the DOS Settings feature. 
  6113.  
  6114. Setting the overall limit to zero disables EMS in all VDMs, regardless of the 
  6115. per-VDM value.  Setting the per-VDM value to zero disables EMS in all VDMs 
  6116. unless their entries on the Presentation Manager desktop specify a non-zero EMS 
  6117. size.  Setting the EMS size to zero for an entry on the desktop disables EMS 
  6118. for that application only.  Most users need never change the default value. 
  6119. DOS settings for frame position, and the size of extra mapping regions above 
  6120. and below 640KB may be configured by the user; see DOS Settings. 
  6121.  
  6122. Upon installation, an initialization routine within VEMM supplies the entry 
  6123. point addresses of VEMM creation and close routines to the Virtual DOS Machine 
  6124. Manager. 
  6125.  
  6126. Most VEMM setup is postponed until the first INT 67H service request is made. 
  6127. Only remappable conventional memory is set up before that time. This assures 
  6128. that other virtual device drivers have a chance to reserve ROM and device 
  6129. memory areas. 
  6130.  
  6131. VDM Creation 
  6132.  
  6133. Upon creation of a VDM, a VDH service is used to get the EMS size for that VDM. 
  6134. This will return a string if the DOS program's entry on the desktop has an 
  6135. associated EMS size.  If not defined, the default size retrieved from 
  6136. CONFIG.SYS at system initialization is used.  If EMS size is not zero, the 
  6137. following steps are then performed: 
  6138.  
  6139.  1. Two mappable windows are located and reserved. 
  6140.  
  6141.  2. Memory is mapped into the low window. 
  6142.  
  6143.  3. Interrupt 67h is hooked using a VDH service. 
  6144.  
  6145.  4. The V86 mode device driver stub is loaded. 
  6146.  
  6147.  5. An initial block of the handle table is allocated. 
  6148.  
  6149. Upon VDM creation, VEMM allocates a block of memory in the area between 256KB 
  6150. and RMSIZE [The RMSIZE statement in CONFIG.SYS specifies the maximum size of a 
  6151. VDM's address space; values up to 640KB are allowed. ] and maps it into the VDM 
  6152. address space.  VEMM requests VDH services to locate the largest free address 
  6153. range in the V86 mode address space above 640KB that is available for the 
  6154. mappable window.  VEMM then reserves the largest range available that is at 
  6155. least 64KB and no more than 128KB in size, and is a multiple of 16KB.  If an 
  6156. extended BIOS data area is present, the returned free range will be below this 
  6157. area so that BIOS cannot be inadvertently mapped away. 
  6158.  
  6159. Waiting until creation time to reserve this memory allows virtual device 
  6160. drivers with actual hardware to claim their addresses first, since VEMM can 
  6161. place its memory at any available address.  A consequence of this technique is 
  6162. that the space is reserved only for the VDM being created. It could be in a 
  6163. different location or be a different size for other VDMs. 
  6164.  
  6165. VEMM performs mapping by requesting the operating system's memory manager to 
  6166. alias linear space inside a mappable window in the V86 mode address space to a 
  6167. memory region outside the V86 address space.  The application can then access 
  6168. this part of the expanded memory object. 
  6169.  
  6170. The VEMM virtual device driver prehooks interrupt vector 67h through a VDH 
  6171. service to catch software interrupts for EMS services.  Prehooking means that 
  6172. VEMM gains control before the V86 mode interrupt vector is called. VEMM also 
  6173. provides a stub driver, the sole function of which is to indicate to DOS 
  6174. applications that EMS is available. 
  6175.  
  6176. VEMM then arranges for the loading of a stub device driver in the VDM. This 
  6177. driver provides a header within the V86 mode address space which can be read by 
  6178. an application searching for the name of the real mode EMS driver.  It also 
  6179. responds to a few simple requests made to its strategy routine, basically 
  6180. replying that it is present and ready.  The stub driver does not actually 
  6181. process EMS service requests; these are handled by VEMM. 
  6182.  
  6183. Routing 
  6184.  
  6185. The router receives notification from the Virtual DOS Machine Manager when an 
  6186. application issues an INT 67h request.  The router checks the request to ensure 
  6187. that it is valid, and then causes an exception which is routed to the Virtual 
  6188. DOS Machine Manager.  The Virtual DOS Machine Manager then reflects the 
  6189. interrupt back into the VDM's interrupt vector table.  This technique is 
  6190. necessary since interrupt vector hooks are only allowed after application code 
  6191. has been executed.  The V86 mode interrupt vector for INT 67h causes another 
  6192. exception which is routed to the Virtual DOS Machine Manager which then calls 
  6193. VEMM. 
  6194.  
  6195. The EMS Alter Map and Call service allows an application to have VEMM remap 
  6196. memory to place a routine within the V86 mode address space, call that routine 
  6197. and then remap memory to its previous state again after the routine issues a 
  6198. far return.  This call can occur recursively; the application code that is 
  6199. called can in turn use the Alter Map and Call service. 
  6200.  
  6201. VEMM does the initial remapping and stores the after-call remapping information 
  6202. on the client's stack.  VDH services are used to call the application's routine 
  6203. and intercept the return.  VEMM supplies the Virtual DOS Machine Manager with a 
  6204. V86 mode address to call and a VEMM handler which is invoked when the 
  6205. application routine does a far return.  After the routine returns, VEMM 
  6206. restores the original mapping saved on the client's stack. 
  6207.  
  6208. The Remap and Jump service is similar but does not require interception of an 
  6209. application routine's return or the saving of a mapping.  Remapping is done and 
  6210. the CS:IP is changed to jump to the address provided by the application. 
  6211.  
  6212. Information calls involve at most a quick search of structures.  Structures are 
  6213. maintained to provide information about handles, allocations, and VEMM 
  6214. capabilities.  Handle directory services are also provided.  The number of 
  6215. pages VEMM reports as available is the minimum of the number of pages the VDM 
  6216. has left in VEMM pages and the amount the memory manager estimates is 
  6217. available. 
  6218.  
  6219. Protection 
  6220.  
  6221. A pseudo-random key is produced with the first protection call made by a VDM 
  6222. and also for the first protection call made after a key was returned. This key 
  6223. is given to the application which made the call that caused its generation. 
  6224. OSEnabled can be reset only by the owner of the key.  The key owner can also 
  6225. return the key.  OSEnabled indicates whether or not protected functions can be 
  6226. executed.  The key will be generated by operations on the current time to 
  6227. ensure that the key changes, even for multiple calls between successive timer 
  6228. ticks. 
  6229.  
  6230.  
  6231. ΓòÉΓòÉΓòÉ 16.1.2. EMS Object Mapping ΓòÉΓòÉΓòÉ
  6232.  
  6233. Mappable windows are located by asking the Virtual DOS Machine Manager to 
  6234. provide free linear regions after other virtual device drivers have claimed the 
  6235. address ranges required for their hardware.  The base window (region from 256KB 
  6236. to RMSIZE) is mapped to an expanded object at VDM  creation time.  This window 
  6237. is used as normal memory by DOS or DOS applications, but can also be remapped 
  6238. by applications that wish to do so. 
  6239.  
  6240. Some applications assume mappable regions begin on 17KB boundaries, although 
  6241. this is not part of the EMS specification.  OS/2 Version 2.0 follows this 
  6242. undocumented convention. 
  6243.  
  6244. There are multiple techniques for saving and restoring mappings in LIM. Save 
  6245. tables and copies of parts of register sets copied to application memory can be 
  6246. used to save and restore mappings.  All contain a pairing of physical segment 
  6247. and <handle, logical page> pairs.  Saving of mappings is done by segment, 
  6248. handle, and logical page entries to the buffer in which the save is performed. 
  6249. For saves that save the entire mapping, the register index need not be stored. 
  6250. Mappings are restored by making a set of aliasing calls to the memory manager, 
  6251. and copying the new mapping into the active register set. 
  6252.  
  6253. Illegal mappings are mapped to black hole pages. A black hole page is a page 
  6254. that does not cause faults, but which need not store values written to it. 
  6255. Black hole pages can be implemented as invalid addresses that float on the bus, 
  6256. ROM pages if there is no ROM caching, a wasted physical memory page, or a 
  6257. discardable page. 
  6258.  
  6259. Structures returned to the client will use physical pages rather than segments 
  6260. since these are smaller for the client to store and are simpler to check for 
  6261. validity when restored.  All save structures held by the V86 client use a 
  6262. checksum to detect tampering by the V86 client. 
  6263.  
  6264. LIM allows an application to reallocate the special handle that contains 
  6265. conventional memory, thus allowing the expanded memory to be reused.  This is 
  6266. supposed to be done only by an operating system program that knows the special 
  6267. handle is handle 0, but may conceivably be done by any application. Note that 
  6268. applications can deallocate the DOS memory area.  If they do this and fail to 
  6269. restore it, COMMAND.COM is unable to reload and the VDM will terminate.  This 
  6270. behavior is identical to a native DOS environment. 
  6271.  
  6272. Register Sets 
  6273.  
  6274. Application requests to map pages into a register set are handled by storing 
  6275. the new mappings in the register set data structure.  A call is made to the 
  6276. memory manager to alias pages or set them to a black hole for unmapped pages. 
  6277.  
  6278. The current register set is changed to a new register set by aliasing linear 
  6279. memory through memory manager calls according to the new registers and changing 
  6280. the current register set variable.  Other calls allow saving and restoring 
  6281. register sets from an application-supplied array similar to Save/Restore above. 
  6282.  
  6283. Allocating/Deallocating Objects 
  6284.  
  6285. Upon receiving an application request to allocate, reallocate, or deallocate an 
  6286. EMS object, VEMM transforms the request into corresponding calls to the OS/2 
  6287. Version 2.0 memory manager.  Each EMS object is allocated as a separate memory 
  6288. object in a linear address range in the VDM's process address space, but 
  6289. outside the V86 mode address space.  The memory manager returns the start 
  6290. address and size of each EMS object to VEMM, which then updates its EMS handle 
  6291. table accordingly. 
  6292.  
  6293. Allocations are made by selecting a free EMS object handle; a free handle has a 
  6294. start address of zero.  VEMM then requests the memory manager to allocate the 
  6295. required memory, and records the start address and size of the object as 
  6296. returned by the memory manager.  The total allocation size for each VDM and the 
  6297. total allocations across all VDMs are maintained so that the maximum allocation 
  6298. size is not exceeded.  If an allocation is of size zero, no actual allocation 
  6299. is made and a non-zero address and zero size are recorded in the handle entry. 
  6300.  
  6301. When a deallocation request is made, the address in the handle is changed to 0 
  6302. and the memory manager is called to free the allocation.  Reallocation requests 
  6303. are serviced by passing on the request to a VDH service and recording the new 
  6304. size and start address.  Since reallocations may lead to object movement, pages 
  6305. mapped from the object are unmapped before reallocation and remapped afterward. 
  6306.  
  6307. When an application reallocates to zero, VEMM has the memory manager deallocate 
  6308. the memory object, and changes the handle table entry so it has zero pages with 
  6309. a meaningless non-zero address to indicate the handle is still in use.  Objects 
  6310. of size zero are allowed in VEMM, but not in OS/2, so VEMM will free the memory 
  6311. but retain its own data for the object handle. When a non-zero reallocation is 
  6312. performed on the object, a new object is transparently allocated. 
  6313.  
  6314. LIM allows an application to deallocate memory that is mapped into the current 
  6315. register set, alternate register sets, or save maps (all internal structures 
  6316. that save mappings).  EMS is silent about what should happen if an application 
  6317. touches this mapped memory after deallocation.  Since 8086 applications are 
  6318. generally allowed to search through the address space without harm, these 
  6319. deallocated pages should be remapped to a black hole. 
  6320.  
  6321. Searching through all 255 SaveMaps and 15 non-current register sets is 
  6322. expensive even with optimizations.  Exhaustive search slows deallocations and 
  6323. shrinking reallocations, and keeping track of the locations of mappings slows 
  6324. mapping operations.  Therefore, upon deallocation or shrinking reallocation, 
  6325. only the current register set is checked for deallocated pages.  Stored 
  6326. registers (255 SaveMaps and 15 RegSets for the VDM) will not be checked until 
  6327. they are reactivated.  When an invalid page is found during remapping, it is 
  6328. simply remapped to the black hole. 
  6329.  
  6330.  
  6331. ΓòÉΓòÉΓòÉ 16.1.3. Per-VDM Data Allocation ΓòÉΓòÉΓòÉ
  6332.  
  6333. Handle table entries, register sets, save tables, and handle names all require 
  6334. a good deal of space if used fully.  Most of these data structures typically do 
  6335. not require their maximum possible size.  For this reason, they are allocated 
  6336. dynamically by VEMM in order to reduce memory utilization. 
  6337.  
  6338. Memory for a register set is allocated when clients allocate the register set. 
  6339. An array of 16 pointers will address buffers for allocated register sets; these 
  6340. pointers are null for free register sets that applications may yet allocate. 
  6341.  
  6342. The handle table, handle name table, and save tables are all allocated with a 
  6343. directory structure.  A directory is an array of pointers to allocation blocks; 
  6344. each allocation block contains enough space for multiple entries. This allows a 
  6345. specific entry to be found by specifying the block and entry offset within the 
  6346. block.  Since each can have at most 255 entries, both the block and offset can 
  6347. fit in a single byte. 
  6348.  
  6349. An allocated handle entry contains an index for its associated save table or 
  6350. name (if used).  For unallocated objects, the index is zero.  The smallest free 
  6351. handle will be allocated when a handle is needed, thus requiring less memory to 
  6352. be allocated for the handle table. 
  6353.  
  6354. The name table is kept in packed form.  When an entry is freed, the last entry 
  6355. is moved into the free hd, thus reducing space requirements. 
  6356.  
  6357. Save table entries are larger and generally have short lifetimes.  These will 
  6358. be allocated in the same way handles are allocated (that is, where the smallest 
  6359. available is allocated first).  For all three of these tables, when new entries 
  6360. are needed and all blocks are full, a new block is allocated. 
  6361.  
  6362.  
  6363. ΓòÉΓòÉΓòÉ 16.1.4. Problems with Expanded Memory ΓòÉΓòÉΓòÉ
  6364.  
  6365. EMS requires a 64KB block of contiguous free memory in the address range 640KB 
  6366. to 1MB for its page frame. As we can see from Figure "General Overview of 
  6367. Different Types of Memory for DOS Applications" this memory range is shared 
  6368. with BIOS, hardware buffers and device drivers. If your application reports 
  6369. that no EMS memory is available, even if you have used the DOS Settings option 
  6370. EMS_MEMORY_LIMIT to set a non-zero value, it could be that a 64KB page frame 
  6371. location could not be found. See Expanded Memory (EMS) and Upper Memory (UMB) 
  6372. on how to resolve this contention. 
  6373.  
  6374. If a program returns an error due to insufficient expanded memory, the 
  6375. following points should be addressed: 
  6376.  
  6377.  Ensure that CONFIG.SYS and/or AUTOEXEC.BAT do not start unnecessary programs 
  6378.   that use expanded memory. 
  6379.  
  6380.  Change the DEVICE= statement for VEMM.SYS in CONFIG.SYS to provide more 
  6381.   expanded memory to every VDM.  Alternatively, use the EMS Memory Size DOS 
  6382.   Settings to allocate more memory to a specific VDM.  See DOS Settings. 
  6383.  
  6384. VEMM for OS/2 was designed to install for EMS only when the DOS application 
  6385. makes its first EMS request. This was done for two reasons. First, it saves 
  6386. time and memory. Second, it gives the DOS drivers or applications a chance to 
  6387. access adapters in the EMS page frame address space. OS/2 V2.0 will recognize 
  6388. adapters with the ROM signature header, but will not see adapter RAM/MMPIO 
  6389. areas. 
  6390.  
  6391. VEMM determines that it has space available during DOS Session creation but a 
  6392. DOS program/driver could cause EMS to not install by accessing memory in the 
  6393. page frame before calling the EMS driver. Lotus 1-2-3 Version 2.3 was found to 
  6394. access the adapter space BEFORE calling EMS. On some machines, this caused no 
  6395. EMS to be present for Lotus 1-2-3. 
  6396.  
  6397. To satisfy this situation, VEMM has than been changed (after GA) to not wait 
  6398. for the first EMS call. This should clear up the EMS problems related to 
  6399. programs accessing the adapter address space (X'C0000'-X'E0000'). However, it 
  6400. should be known that it is now possible for VEMM to claim areas that could 
  6401. actually be adapter address space. In general, the user should be aware of this 
  6402. situation. To resolve this we suggest to use the MEM_EXCLUDE property to force 
  6403. EMS not to use the desired address space. 
  6404.  
  6405.  
  6406. ΓòÉΓòÉΓòÉ 16.2. Expanded Memory (EMS) and Upper Memory (UMB) ΓòÉΓòÉΓòÉ
  6407.  
  6408. The following section applies to both VDM DOS Emulation and DOS VMB. 
  6409.  
  6410. Expanded Memory Specification (EMS) is discussed in detail in Memory Extender 
  6411. Support. One requirement of EMS is a page frame in real memory between 640KB 
  6412. and 1MB (hex addresses X'A0000' to X'FFFFF'). Since IBM systems reserve 
  6413. addresses X'A0000' to X'BFFFF' for video, and X'E0000' to X'FFFFF' for BIOS, 
  6414. the EMS page frame is normally restricted to addresses between X'C0000' and 
  6415. X'E0000'. This area can also be used for Upper Memory Blocks, where DOS device 
  6416. drivers and resident programs can be loaded. This frees up valuable space below 
  6417. 640KB for conventional DOS programs. 
  6418.  
  6419. Unfortunately, memory between X'C0000' and X'E0000' is also needed for Option 
  6420. Adapter ROM and RAM. Indeed it can be difficult or even impossible to configure 
  6421. EMS on a system which has several intelligent adapters installed. 
  6422.  
  6423. There is really no solution to this problem (sometimes known as "RAM Cram") 
  6424. under DOS. However OS/2 Version 2.0 provides an elegant alternative. 
  6425.  
  6426. Normally a VDM inherits a memory map which mirrors the actual system hardware 
  6427. configuration; adapter ROM and RAM addresses set by the PS/2 Reference Diskette 
  6428. (or adapter switches on non-Micro Channel systems) are mapped into the VDM 
  6429. address space and are not available for EMS or UMBs. 
  6430.  
  6431. But since the VDM occupies virtual memory this can easily be changed. The DOS 
  6432. Settings value MEM_INCLUDE_REGIONS parameter releases adapter addresses for use 
  6433. as EMS or UMBs. In most cases this can be set to the complete X'C0000'-X'DFFFF' 
  6434. range. 
  6435.  
  6436. If a VDM uses an adapter directly (usually via a DOS device driver), the 
  6437. adapter ROM or RAM address must not be specified in MEM_INCLUDE_REGIONS. 
  6438. Addresses of adapters used indirectly by the VDM (through OS/2 Version 2.0) may 
  6439. be included. For example, the full X'C0000'to X'DFFFF' range may be included on 
  6440. a SCSI-based PS/2, even though the SCSI adapter ROM may occupy X'D8000' to 
  6441. X'DFFFF'. The DOS VDM does not directly access the SCSI adapter so it does not 
  6442. need SCSI ROM mapped into its address space. It can still access files on SCSI 
  6443. disks via the OS/2 Version 2.0 file system. 
  6444.  
  6445. Another example could be a 3270 connection adapter.  Depending on the setup, it 
  6446. could occupy 8KB of memory (for example, X'DE000' to X'E0000'). If you are 
  6447. using Extended Services and Communications Manager to establish a DFT 
  6448. connection to your /370 system, you could release this memory for use by DOS 
  6449. applications and specify this address frame in the Include Region.  Of course, 
  6450. if you want to use a DOS-based emulator, such as Personal Communications/3270 
  6451. Version 2.0, you can't include this area, as the DOS application and its device 
  6452. driver want to access this adapter directly. 
  6453.  
  6454. Note:   The MEM_INCLUDE_REGIONS parameter should be entered as shown above, 
  6455.         using 5-digit hex addresses (not 4-digit segment addresses, as is often 
  6456.         the case). Also, note that the range is inclusive - you must specify 
  6457.         the second address as (for example) X'DFFFF', not X'E0000'. The 
  6458.         parameter is not validity-checked when entered. If an invalid parameter 
  6459.         is saved, the default (no include region) is used when the VDM is 
  6460.         initialized; no error message is generated. 
  6461.  
  6462. In summary, a typical DOS VDM may have a 64KB EMS page frame and 64KB of UMBs 
  6463. (or 128KB of UMBs) regardless of the hardware adapters installed. Such a 
  6464. configuration is not possible under PC DOS. 
  6465.  
  6466.  
  6467. ΓòÉΓòÉΓòÉ 16.3. Extended Memory Support ΓòÉΓòÉΓòÉ
  6468.  
  6469. The OS/2 Version 2.0 Multiple Virtual DOS Machines architecture provides 
  6470. support for the LIMA Extended Memory Specification Version 2.0 specification, 
  6471. in a similar manner to that provided for LIM EMS Version 4.0, using normal 
  6472. system memory and emulating XMS functions.  The following discusses how MVDM 
  6473. support for the extended memory specification has been implemented. 
  6474.  
  6475. The extended memory specification manages three different kinds of memory: 
  6476.  
  6477.  High Memory Area (HMA) 
  6478.  
  6479.  Upper Memory Blocks (UMBs) in the Upper Memory Area (UMA) 
  6480.  
  6481.  Extended Memory Blocks (EMBs). 
  6482.  
  6483. Each of these areas is discussed as they relate to the implementation of 
  6484. expanded memory support for VDMs in OS/2 Version 2.0. Figure "Memory Map of 
  6485. Areas Supported by Extended Memory"below shows where these memory areas or 
  6486. blocks reside in memory. 
  6487.  
  6488. For more information regarding the Expanded Memory Specification, refer to DOS 
  6489. Protected Mode Interface. 
  6490.  
  6491. The OS/2 Version 2.0 LIMA XMS emulation provides the following functions: 
  6492.  
  6493.  Implements all LIMA XMS Version 2.0 functions. 
  6494.  
  6495.  Provides each VDM with a separate XMS emulation.  Each VDM has its own High 
  6496.   Memory Area, Upper Memory Blocks and Extended Memory Blocks; hence features 
  6497.   such as interprocess communication work as if each VDM was running on a 
  6498.   different real 80386.  A VDM therefore cannot affect the availability of 
  6499.   extended memory objects in other VDMs or access memory owned by other VDMs. 
  6500.  
  6501.  Provides configurable limits for how much XMS memory is available across all 
  6502.   VDMs as well as a limit per-VDM.  The DOS Settings feature can override the 
  6503.   per-VDM limit, subject to the constraint given by the overall limit, and can 
  6504.   disable XMS altogether for a particular VDM if its installation conflicts 
  6505.   with the program being run in the VDM. 
  6506.  
  6507.  XMS can be removed and the operating system can run without loading XMS in 
  6508.   any VDM session. 
  6509.  
  6510. Applications which use extended memory may use the XMS support in the same 
  6511. manner as in a native DOS environment.  In addition, portions of the DOS 
  6512. operating system, device drivers and TSR programs may be loaded into extended 
  6513. memory, thereby conserving memory within the DOS application address space for 
  6514. application use. 
  6515.  
  6516. Note that older applications which access extended memory directly, rather than 
  6517. through an extended memory manager, may not be compatible with the XMS support 
  6518. under MVDM.  For example, Microsoft Windows Version 2.x cannot make use of 
  6519. extended memory in a VDM. 
  6520.  
  6521.  
  6522. ΓòÉΓòÉΓòÉ 16.3.1. Extended Memory Manager ΓòÉΓòÉΓòÉ
  6523.  
  6524. XMS services are implemented under MVDM using a virtual device driver known as 
  6525. the Virtual Extended Memory Manager (VXMM) which is represented by the file 
  6526. VXMS.SYS (VXMS). VXMM provides a separate XMS emulation for each VDM by placing 
  6527. most VXMS control structures in a per-VDM data area outside the V86 mode 
  6528. address space. The amount of memory available to a VDM, the number of handles, 
  6529. and the existence of Upper Memory Blocks (UMBs) are all configurable parameters 
  6530. which may be altered on a per-VDM basis. 
  6531.  
  6532. The VXMM hooks interrupt vector 2Fh in order to announce its presence to 
  6533. applications. It also provides a V86 stub device driver (XMM 3X device driver), 
  6534. which indicates to DOS applications that XMS is available, but more importantly 
  6535. acts as a V86 mode interface between the application and the VXMM proper. 
  6536.  
  6537. VXMM depends heavily upon the memory manager.  XMS object allocation 
  6538. reallocation, and deallocation are accomplished by requesting corresponding 
  6539. services from the memory manager.  When an application requests the allocation 
  6540. of a block of extended memory, for example, VXMS asks the memory manager to 
  6541. allocate a memory object in linear memory outside any VDM.  Reallocation and 
  6542. deallocation are handled similarly. 
  6543.  
  6544. All EMS functions are executed by calling the XMS Control Function, the address 
  6545. of which can be obtained by a call to INT 2Fh. Arguments are passed in 
  6546. registers. 
  6547.  
  6548. Figure "Extended Memory Manager Control Flow" 
  6549.  
  6550. During the initialization of the VDM the VDM Manager loads and initializes the 
  6551. XMM DOS stub device driver into the VDM address space. As soon as there is a 
  6552. XMS request the VDM Manager loads the the XMS virtual device driver VXMS. 
  6553.  
  6554.     a) The VDM Application issues a INT 15h service request. VXMS directly 
  6555.        hooks INT 15h for function 87h and 88h. It does not provide any services 
  6556.        through these calls but makes sure that no program tries to use extended 
  6557.        memory directly. INT 15h function 88h will respond that no normal 
  6558.        extended memory is available. Programs that want to use extended memory 
  6559.        directly by using INT 15 and RAMdisks (electronic disks) using INT 15 
  6560.        won't work. The MS DOS RAMDRIVE for DOS 5.0 does work because it uses 
  6561.        XMS instead of INT 15. 
  6562.  
  6563.     b) The VDM application issues INT 2Fh to determine if an XMS driver is 
  6564.        installed. 
  6565.  
  6566.     c) The VDM application issues INT 2Fh to determine if an XMS driver is 
  6567.        installed. 
  6568.  
  6569.     d) Next the VDM application issues a INT 2Fh to obtain the address of the 
  6570.        XMS driver's control function.  As soon as the VDM Application got the 
  6571.        address of the XMS driver's control function it can use any of the 
  6572.        functions and call the XMM DOS stub device driver directly. 
  6573.  
  6574.     e) The VDM application calls the XMS driver's control function to access 
  6575.        all of the XMS functions. 
  6576.  
  6577.     f) The XMM DOS stub device driver calls breakpoint traps by the VXMM 
  6578.        Control Function. 
  6579.  
  6580.     g) The VDM Manager initialization, creation, termination calls for 
  6581.        XMS-Objects. The VDM Manager traps the VDM application's INT 15h service 
  6582.        request and routes it to VXMS as well as XMS control function requests 
  6583.        for XMS memory. 
  6584.  
  6585.     h) The VXMS requests corresponding services from the VDH services: 
  6586.  
  6587.        Creation/termination handler registration 
  6588.  
  6589.        INT 67h prehooking 
  6590.  
  6591.        Linear address reservation 
  6592.  
  6593.        Memory management 
  6594.  
  6595.        Obtaining configuration information. 
  6596.  
  6597.     i) The result is returned. 
  6598.  
  6599. Like VEMM and unlike most other virtual device drivers, VXMS.SYS does not have 
  6600. a corresponding physical device driver.  Instead, it depends heavily upon the 
  6601. OS/2 Version 2.0 memory manager.  XMS object allocation, reallocation and 
  6602. deallocation are accomplished by requesting corresponding services from the 
  6603. operating system's memory manager.  For example, when an application requests 
  6604. the allocation of a block of extended memory, VXMM requests the memory manager 
  6605. to allocate a memory object in linear memory outside the V86 mode address 
  6606. space.  Reallocation and deallocation are handled similarly. 
  6607.  
  6608. Structure 
  6609.  
  6610. The VXMS.SYS module consists of: 
  6611.  
  6612.  1. An initialization component that initializes global structures and reads 
  6613.     the global configuration at boot time. 
  6614.  
  6615.  2. A creation component that initializes per-VDM structures, reads per-VDM 
  6616.     configuration values, and installs the DOS device driver stub when a VDM is 
  6617.     created. 
  6618.  
  6619.  3. A router component that receives control from the control function 
  6620.     contained in the stub device driver, and dispatches the call to an 
  6621.     appropriate service routine.  In addition, the router function hooks 
  6622.     interrupt vector 15h upon the first non-version-query call to VXMM, as 
  6623.     required by the specifications, in order to: 
  6624.  
  6625.     a) Preserve the state of the A20 line across block copies (service AH=87h). 
  6626.  
  6627.     b) Respond to service AH=88h (Query Extended Memory) by reporting that 
  6628.        there is no extended memory available. 
  6629.  
  6630.  4. A number of service routines, which perform the required XMS functions. 
  6631.  
  6632. Applications request XMS services by calling a subroutine contained within the 
  6633. VXMM, known as the Control Function.  The VXMS virtual device driver hooks 
  6634. interrupt vector 2Fh in  order to announce its presence to applications. 
  6635.  
  6636. Initialization 
  6637.  
  6638. VXMS.SYS may be loaded at system initialization time by using a DEVICE= 
  6639. statement in CONFIG.SYS, as shown below: 
  6640.  
  6641. DEVICE=C:\OS2\MDOS\VXMS.SYS 8192, 2048
  6642.  
  6643. This statement should be placed in CONFIG.SYS after the DEVICE= statement for 
  6644. VEMM.SYS, since VXMM queries VEMM to ensure that no conflicts occur in memory 
  6645. allocation. 
  6646.  
  6647. The DEVICE= statement uses parameters to specify the total amount of available 
  6648. XMS memory, and the default limit for each VDM.  In the above example, the 
  6649. overall limit is set to 8MB and the limit for each VDM is set to 2MB. 
  6650.  
  6651. The virtual device driver VXMS.SYS can be configured as follows. 
  6652.  
  6653.        device = {path} vxms.sys {options}
  6654.  
  6655. The options are of the form "/keyword=value": 
  6656.  
  6657. /XMMLIMIT=g,i       Sets the global (system-wide) maximum memory usage of the 
  6658.                     VXMS.SYS driver to g kilobytes, and a per-VDM maximum of i 
  6659.                     kilobytes.  These values should be large enough to 
  6660.                     accommodate an automatic 64KB allocation in each VDM for 
  6661.                     the HMA.  Values are restricted to the range 0..65535 (= 
  6662.                     64Meg). 
  6663.  
  6664.                     The values of g and i are rounded up to the nearest 
  6665.                     multiple of 4. 
  6666.  
  6667.                     Specifying i = 0 suppresses XMS installation in all VDMs 
  6668.                     unless specifically overridden by a VDM-specific 
  6669.                     configuration string.  (See below.) 
  6670.  
  6671.                     Default:  /XMMLIMIT=4096,1024 
  6672.  
  6673. /HMAMIN=d           Sets the minimum request size (in kilobytes) for an HMA 
  6674.                     request to succeed.  Values are restricted to the range 
  6675.                     0..63. 
  6676.  
  6677.                     Default: /HMAMIN=0 
  6678.  
  6679. /NUMHANDLES=n       Sets the number of handles available in each VDM. Each 
  6680.                     handle occupies eight bytes.  Values are restricted to the 
  6681.                     range 0..128. 
  6682.  
  6683.                     Default: / NUMHANDLES=32 
  6684.  
  6685. /UMB                Instructs XMM to create Upper Memory Blocks 
  6686.  
  6687.                     Default:  off 
  6688.  
  6689. /NOUMB              Instructs XMM not to create Upper Memory Blocks 
  6690.  
  6691.                     Default: /NOUMB 
  6692.  
  6693.                     All other keywords are ignored.  Case is ignored. 
  6694.  
  6695. These options affect all VDMs, but can be overridden by a VDM's configuration 
  6696. strings.  The same option names are available to VDMs (without the prefixing 
  6697. slash), except that XMMLIMIT only takes one numeric argument, corresponding to 
  6698. the value i above.  The value g above cannot be changed once XMM is installed. 
  6699.  
  6700. If a value of i=0 was specified on the DEVICE= line, to create a VDM with XMS 
  6701. installed, specify a configuration string "XMMLIMIT" with a non-zero value. 
  6702. Conversely, to have no XMS installed, specify a configuration string "XMMLIMIT" 
  6703. with a value of zero. 
  6704.  
  6705. If UMBs are being used, it is crucial that VXMS.SYS be the last device driver 
  6706. loaded, for VXMS.SYS reserves all available addresses between 640KB and 1Meg 
  6707. for use as UMBs.  Hence, any device drivers which reserve pages in that region 
  6708. (for example, VEMM) will not be able to install. 
  6709.  
  6710. VXMS.SYS will fail to install if some other device driver has already reserved 
  6711. the region from 1MB to 1MB+64KB. 
  6712.  
  6713. The overall limit comprises the only relationship between XMS memory objects in 
  6714. different VDMs, and is imposed to prevent XMS from acquiring all available 
  6715. memory.  The default overall limit is 4MB, and the default limit for each VDM 
  6716. is 1MB.  The default limit for each VDM can be overridden by installing an 
  6717. application on the desktop and choosing to specify the XMS size with the DOS 
  6718. Settings feature (see DOS Settings). 
  6719.  
  6720. Setting the overall limit to zero disables XMS in all VDMs regardless of the 
  6721. per-VDM value.  Setting the default limit for a particular VDM to zero disables 
  6722. XMS in all VDMs unless their start list entries specify a non-zero XMS size. 
  6723. Setting the XMS size to zero for an entry in the start list disables XMS for 
  6724. that application's VDM only.  Novice users need never change the default 
  6725. values. 
  6726.  
  6727. In addition to memory sizes, the number of handles and the presence or absence 
  6728. of Upper Memory Blocks are all configurable parameters which may be altered on 
  6729. a per-VDM basis using the DOS Settings feature. 
  6730.  
  6731. Upon installation, an initialization routine within VXMS.SYS supplies the 
  6732. addresses of the VXMS.SYS VDM-creation and close routines to the Virtual DOS 
  6733. Machine Manager. 
  6734.  
  6735. VDM Creation 
  6736.  
  6737. Upon creation of a VDM, a VDH service is used to get the maximum XMS size for 
  6738. that VDM.  This will return a string if the program's entry on the desktop has 
  6739. an associated VXMS size.  If the per-VDM size is not defined, the default 
  6740. retrieved from CONFIG.SYS at initialization time will be used. If VXMS size is 
  6741. not 0, the following steps are then performed: 
  6742.  
  6743.  1. Upper Memory Blocks (UMBs) are found and reserved. 
  6744.  
  6745.  2. The High Memory Area (HMA) is reserved. 
  6746.  
  6747.  3. The real mode device driver stub is loaded. 
  6748.  
  6749.  4. The handle table and UMB list are initialized. 
  6750.  
  6751. To find an available linear region to use for UMBs, VXMS requests VDH services 
  6752. to locate the largest free address range in the V86 mode address space above 
  6753. 640KB. VXMS reserves all the pages returned until the call fails. 
  6754.  
  6755. VXMS requests the OS/2 Version 2.0 memory manager to allocate the 64KB region 
  6756. immediately above 1MB for use as the High Memory Area.  The way in which this 
  6757. is accomplished depends upon a number of variables; see High Memory Area (HMA) 
  6758. for further details. 
  6759.  
  6760. Waiting until creation time to reserve this memory allows virtual device 
  6761. drivers with actual hardware to claim their addresses first, since VXMS's UMBs 
  6762. can be placed at any available address.  A consequence is that the space is 
  6763. reserved only for the VDM being created; it could be in a different location or 
  6764. be a different size for other VDMs. 
  6765.  
  6766. VXMS then arranges for the loading of a stub device driver in the VDM. This 
  6767. driver serves three purposes: 
  6768.  
  6769.  The device driver header can be read by an application searching for the name 
  6770.   of the real mode VXMS driver.  It responds to all device requests with "done" 
  6771.   without actually doing anything. 
  6772.  
  6773.  The device driver's initialization code attaches VXMS to interrupt vector 
  6774.   2Fh.  Attaching to vector 2Fh must be delayed until after the virtual DOS 
  6775.   environment has completed hooking all of its interrupts. 
  6776.  
  6777.  The device driver contains the VXMS control function; calls to XMS services 
  6778.   are not performed by calling a software interrupt, but rather by calling a 
  6779.   V86 mode far subroutine called the control function. Moreover, XMS 
  6780.   specifications require the control function to have a particular physical 
  6781.   layout.  Hence, the control function is placed in a DOS device driver so that 
  6782.   it may have the layout required by the specifications and can transfer 
  6783.   control to the virtual device driver code (the router function). 
  6784.  
  6785. The stub device driver is used to transfer control to the router function. A 
  6786. DOS application invokes XMS functions by calling the control function as a far 
  6787. procedure, the address of which can be obtained by a different INT 2Fh call. 
  6788. In response to such a request, the INT 2Fh interrupt handler returns the 
  6789. address of the control function in the device driver stub.  The Control 
  6790. Function then calls the protected mode VXMS entry point, and the router obtains 
  6791. control. 
  6792.  
  6793. The interrupt hook cannot be performed by the VXMS creation function, since the 
  6794. virtual DOS environment does not establish its interrupt hooks until after all 
  6795. virtual device driver creation code has completed.  DOS device driver 
  6796. initialization code is called after the interrupt vectors are set; therefore 
  6797. delaying the hooking of vector 2Fh until DOS device driver initialization time 
  6798. succeeds in hooking the vector. 
  6799.  
  6800. Routing 
  6801.  
  6802. The router receives control from the control function within the stub device 
  6803. driver, as described above.  After checking that the XMS service request is 
  6804. valid, the router calls the appropriate protected mode service routine, which 
  6805. in turn requests the OS/2 Version 2.0 memory manager to allocate and manipulate 
  6806. XMS objects. 
  6807.  
  6808. Information calls involve at most a quick search of structures.  The number of 
  6809. kilobytes VXMS reports as available is the minimum of the number of kilobytes 
  6810. the VDM has left before it hits its per-VDM XMS memory usage limit, the number 
  6811. of kilobytes all VDMs have left before hitting the system-wide memory usage 
  6812. limit, and the amount the memory manager estimates is available. 
  6813.  
  6814.  
  6815. ΓòÉΓòÉΓòÉ 16.3.2. High Memory Area (HMA) ΓòÉΓòÉΓòÉ
  6816.  
  6817. VXMS requests that the operating system's memory manager reserve the region of 
  6818. memory between 1MB and 1MB + 64KB, so that it may use that region for 
  6819. simulating the A20 address line wraparound.  This region of memory is called 
  6820. the High Memory Area (HMA). 
  6821.  
  6822. When the processor's A20 address line is disabled, the HMA is mapped to the 
  6823. first 64KB of conventional memory.  When the A20 address line is enabled, the 
  6824. mapping depends on whether the HMA is in use.  If the A20 address is not 
  6825. enabled, the HMA is mapped to black hole memory.  Black hole memory can safely 
  6826. be accessed by a VDM, but values written to it cannot be retrieved (ROM or 
  6827. invalid physical addresses, for example).  If the HMA is in use, VXMS requests 
  6828. the memory manager to alias a linear region inside the HMA to a memory object 
  6829. outside the V86 mode address space, which has been specially allocated for this 
  6830. purpose. 
  6831.  
  6832. DOS Emulation code may reside in the HMA; this is specified by including the 
  6833. following statement in CONFIG.SYS: 
  6834.  
  6835. DOS=HIGH
  6836.  
  6837. OS/2 Version 2.0 installation places this statement into CONFIG.SYS as a 
  6838. default, and the operating system is thus installed such that DOS Emulation 
  6839. runs in the HMA. The only drawback to using the HMA for DOS Emulation code is 
  6840. that applications are prevented from using the HMA.  This is not usually a 
  6841. serious problem, since few programs require use of the HMA.  It is recommended 
  6842. that DOS Emulation code is loaded in the HMA as this will free base memory for 
  6843. application use. 
  6844.  
  6845. Note that if XMS size is less than 64KB for a VDM, the HMA is not emulated. 
  6846. All requests for the HMA will fail. 
  6847.  
  6848.  
  6849. ΓòÉΓòÉΓòÉ 16.3.3. Upper Memory Blocks (UMBs) ΓòÉΓòÉΓòÉ
  6850.  
  6851. VXMS attempts to reserve all unreserved pages in the region of memory between 
  6852. 640KB and 1MB; this region is often termed the Upper Memory Area (UMA).  The 
  6853. address ranges reserved in this manner will be used to simulate Upper Memory 
  6854. Blocks (UMBs).  Note that this allocation scheme requires that VXMS be the last 
  6855. device driver loaded; any device drivers loaded after VXMS will not be able to 
  6856. reserve any addresses in the UMA. 
  6857.  
  6858. When a UMB is not in use, its corresponding range of addresses is mapped to a 
  6859. black hole.  When it is in use, the range of addresses corresponding to the UMB 
  6860. being allocated is mapped to a memory object outside the V86 mode address space 
  6861. which is allocated for this purpose.  This is similar to the technique used to 
  6862. map objects in the HMA. 
  6863.  
  6864. VXMS uses a delayed UMB allocation scheme.  Unlike conventional XMS 
  6865. implementations, no UMBs are allocated until the first UMB request.  Upon 
  6866. receiving the first UMB request, VXMS queries the UMB region to determine which 
  6867. address ranges are available, and reserves those ranges.  This technique 
  6868. supports memory mapped devices which lie in the same region from which UMBs are 
  6869. taken.  Advanced users can use Include/Exclude Regions in the DOS Settings 
  6870. feature to tell VXMS which ranges are not to be used. 
  6871.  
  6872. Note that by default, all UMBs are owned by the DOS Emulation kernel and are 
  6873. not available for application use.  If an application wishes to use UMBs, the 
  6874. DOS = NOUMB statement must be included in CONFIG.SYS or the application can't 
  6875. get any UMB because they are already used by DOS. Alternatively, the ownership 
  6876. of UMBs for a single VDM may be enabled or disabled using the DOS owns UMBs 
  6877. setting; see DOS Settings. 
  6878.  
  6879. VXMS allows coexistence with EMS services, in that it queries VEMM before 
  6880. reserving address ranges, so that VEMM may reserve the space it requires for 
  6881. its frame.  As such, it is possible that an application using both EMS and XMS 
  6882. services will execute and function correctly. 
  6883.  
  6884. DOS Device Drivers 
  6885.  
  6886. DOS device drivers may be loaded into UMBs, thereby conserving memory within 
  6887. the 640KB DOS application space; this support is functionally compatible with 
  6888. that provided by DOS 5.0.  Loading a DOS device driver into a UMB requires a 
  6889. number of additional statements in CONFIG.SYS; an example is given in Figure 
  6890. "CONFIG.SYS - Loading Device Drivers into UMBs". 
  6891.  
  6892. The first statement causes the VXMS virtual device driver VXMS.SYS to be loaded 
  6893. at initialization time.  The second statement causes the ANSI.SYS device driver 
  6894. to be loaded into a UMB.  The SIZE parameter ensures that the device driver is 
  6895. loaded into a UMB of the required size for its operation;  if a UMB of this 
  6896. size cannot be allocated, the device driver is automatically loaded into low 
  6897. memory. 
  6898.  
  6899. For DOS device drivers loaded into a specific VDM using DOS Device Drivers in 
  6900. the DOS Settings feature, the SIZE parameter is also supported. Specifying a 
  6901. SIZE parameter in DOS Settings will cause the device driver to be loaded into a 
  6902. UMB if possible; if UMBs are not present or if a sufficiently large UMB cannot 
  6903. be allocated, the device driver will be loaded into low memory. 
  6904.  
  6905. Note that device drivers are always loaded into the largest available UMB; 
  6906. hence, in order to achieve efficiency in the utilization of UMBs, device 
  6907. drivers should be loaded in order of size, from largest to smallest.  This is 
  6908. achieved by placing the DEVICE= statements in CONFIG.SYS, or names of the 
  6909. device drivers in the DOS Device Drivers setting, in that order. 
  6910.  
  6911. The third statement allocates ownership of UMBs to the DOS kernel, and prevents 
  6912. applications from accessing UMBs.  This statement sets the default for all 
  6913. VDMs; if an application running in a VDM requires UMBs, the default may be 
  6914. overridden for that VDM using the appropriate DOS Settings function. 
  6915.  
  6916. Note that some device drivers may not function correctly in a UMB if they rely 
  6917. on having all memory above them available for their use.  If incorrect 
  6918. operation of a device driver is experienced in a UMB, the value of the SIZE 
  6919. parameter should be increased by modifying the DEVICEHIGH statement in 
  6920. CONFIG.SYS or by altering the appropriate DOS settings for the VDM. 
  6921.  
  6922. TSR Programs 
  6923.  
  6924. TSR programs may also be loaded into UMBs in order to conserve DOS application 
  6925. space.  TSR programs such as APPEND, which are loaded by default when a VDM is 
  6926. started, are loaded into a UMB where possible, thereby saving approximately 6KB 
  6927. of memory.  Loading a TSR program into a UMB is performed from the DOS command 
  6928. line or from a batch file using the LOADHIGH command, as shown in Figure 
  6929. "LOADHIGH Command - Loading TSRs into UMBs". 
  6930.  
  6931. Note that parameters for TSR programs are supported by the LOADHIGH command. 
  6932.  
  6933. TSR programs which rely on having all memory above their location available for 
  6934. their use may not execute correctly when loaded in a UMB.  In such cases, the 
  6935. TSR must be loaded into low memory. 
  6936.  
  6937.  
  6938. ΓòÉΓòÉΓòÉ 16.3.4. Extended Memory Blocks (EMBs) ΓòÉΓòÉΓòÉ
  6939.  
  6940. Extended Memory Blocks (EMBs) reside in the region above 1MB, and are therefore 
  6941. not directly accessible from DOS applications running in V86 mode.  The only 
  6942. way a DOS application can access EMBs is by using the VXMS service Move 
  6943. Extended Memory Block. VXMS then requests the memory manager to remap the EMB 
  6944. into low memory, from which it may then be accessed by the application.  Each 
  6945. Extended Memory Block is allocated as a separate memory object with linear 
  6946. addresses outside the V86 mode address space. 
  6947.  
  6948. Note that memory requests for UMBs and EMBs are made by applications in units 
  6949. of paragraphs and kilobytes, whereas the memory manager allocates in 4KB pages. 
  6950. VXMS rounds all allocation requests up to the nearest integral page multiple 
  6951. before passing the request on to the operating system's memory manager. 
  6952.  
  6953.  
  6954. ΓòÉΓòÉΓòÉ 16.3.5. Allocating/Deallocating Memory ΓòÉΓòÉΓòÉ
  6955.  
  6956. Application requests to allocate, reallocate, or deallocate Extended Memory 
  6957. Blocks are translated into corresponding call to the memory manager.  A free 
  6958. handle table entry, indicated by a start address of zero, is selected and 
  6959. updated to contain the start address and size of the memory object. The total 
  6960. XMS memory size for the system and for each VDM is checked at this point to 
  6961. ensure that these limits are not exceeded. 
  6962.  
  6963. Reallocation requests are serviced by passing the request to a VDH service and 
  6964. recording the new size and start address.  When an application reallocates to 
  6965. zero, VXMS requests the memory manager to deallocate the memory object, and 
  6966. changes the handle table entry so it has zero pages with a sentinel non-zero 
  6967. address to indicate the handle is still in use. Objects of size zero are 
  6968. allowed in VXMS, but not in OS/2, so VXMS will deallocate but retain its own 
  6969. data for the handle.  When a non-zero reallocation is performed on an object of 
  6970. size zero, a new object is transparently allocated by the memory manager. 
  6971.  
  6972. All allocations (and reallocations) are rounded up to the nearest integral page 
  6973. multiple.  Since there is no facility for telling the applications how much 
  6974. memory was actually reserved, the extra memory is wasted. 
  6975.  
  6976. High Memory Area 
  6977.  
  6978. There is only one HMA per VDM, so a single pointer suffices to manage the state 
  6979. of the HMA. If the pointer is zero, then the HMA is not in use.  Otherwise, the 
  6980. pointer contains the linear address of the block of memory being used to 
  6981. simulate the HMA. Whether the HMA region is mapped to this block of memory is 
  6982. determined by the state of the simulated A20 line; see section High Memory Area 
  6983. (HMA). 
  6984.  
  6985. When a request for the HMA is made, the pointer is tested against zero.  If the 
  6986. pointer is non-zero, then the HMA is in use, and the request fails. Otherwise, 
  6987. the pointer is set to a newly allocated 64KB block of memory, and the HMA 
  6988. region is mapped to this block if the A20 address line is active. 
  6989.  
  6990. When the HMA is released, the block of memory is freed, and the pointer is 
  6991. reset to 0.  The HMA is then mapped to a black hole if the A20 address line is 
  6992. active.  Once an HMA is freed, all information previously stored therein 
  6993. becomes invalid. 
  6994.  
  6995. Upper Memory Blocks 
  6996.  
  6997. For UMB allocation, a linked list of reserved address ranges is maintained. 
  6998. This list contains information about the start address of each reserved range, 
  6999. the base address of the physical memory block allocated and mapped into address 
  7000. range, and the length of the block. If the base address is zero, then the 
  7001. address range is not in use and is instead mapped to a black hole. 
  7002.  
  7003. Allocations are made by searching through the list to find an address range for 
  7004. which the base address is zero and which is large enough to satisfy the 
  7005. request.  If the address range exceeds the required size, it is split into two 
  7006. parts and a new object is allocated to hold the unused portion. 
  7007.  
  7008. Deallocations are made by searching the list to find a structure whose starting 
  7009. address matches the one being deallocated.  The physical memory into which the 
  7010. address range was mapped is freed, and the address range is instead remapped to 
  7011. a black hole.  Finally, the newly freed object has its base address set to zero 
  7012. to signify that it is not in use.  It is then coalesced with any adjacent free 
  7013. blocks. 
  7014.  
  7015. Extended Memory Blocks 
  7016.  
  7017. Each VDM has a fixed table of up to 255 EMB handles, the exact number of which 
  7018. is under user control.  Each entry of the table describes a single Extended 
  7019. Memory Block. 
  7020.  
  7021. Each entry contains a field which records the number of active locks on the 
  7022. Extended Memory Block.  Locking a handle prevents the corresponding Extended 
  7023. Memory Block form being reallocated or freed, and also prevents the base 
  7024. address from changing.  As part of its function, the lock subfunction returns 
  7025. the 32-bit base address. 
  7026.  
  7027. If an allocation is of size zero, no physical memory allocation is requested, 
  7028. but a sentinel non-zero address and zero size are recorded in the handle entry. 
  7029. The lock count for the newly created Extended Memory Block is reset to zero. 
  7030.  
  7031. When a deallocation request is made for an Extended Memory Block with zero lock 
  7032. count, the address in the handle is changed to zero, and the memory manager is 
  7033. called to free the memory. 
  7034.  
  7035.  
  7036. ΓòÉΓòÉΓòÉ 16.4. Problems with Extended Memory ΓòÉΓòÉΓòÉ
  7037.  
  7038. If an application in a VDM encounters an error due to insufficient extended 
  7039. memory, the following points should be checked: 
  7040.  
  7041.  Ensure the overall limit and the limit for the VDM are large enough to 
  7042.   accommodate the amount of extended memory required by the application. 
  7043.  
  7044.  Ensure that the DEVICE= statement for VMXS.SYS is in CONFIG.SYS. 
  7045.  
  7046.  Ensure that the expanded memory driver VEMM.SYS, is not using all of the 
  7047.   available memory.  The amount of memory allocated to VEMM may be reduced by 
  7048.   changing the parameters of the DEVICE= statement for VEMM to something less 
  7049.   than that specified (or less than the default which is 4MB).  If necessary, 
  7050.   VEMM command may be disabled by removing or remarking out the DEVICE= 
  7051.   statement in CONFIG.SYS. 
  7052.  
  7053.  Ensure that CONFIG.SYS and/or AUTOEXEC.BAT do not start unnecessary programs 
  7054.   that use extended memory. 
  7055.  
  7056. If a program does not start and displays a message such as High Memory Area 
  7057. (HMA) already in use, the HMA may be freed by disabling the DOS=HIGH statement 
  7058. in CONFIG.SYS.  If the statement is DOS=HIGH, UMB then the statement should be 
  7059. changed to DOS=UMB. 
  7060.  
  7061.  
  7062. ΓòÉΓòÉΓòÉ 16.5. Summary ΓòÉΓòÉΓòÉ
  7063.  
  7064. MVDM provides support for applications which use the LIM EMS Version 4.0 and 
  7065. LIMA XMS Version 2.0 memory extenders to access more than 640KB of memory.  The 
  7066. memory requested is allocated from OS/2 Version 2.0 system memory, and is 
  7067. managed by the operating system kernel; special hardware is not required. Each 
  7068. VDM has its own copy of EMS or XMS memory objects, and the objects of one VDM 
  7069. are protected from access by another VDM. 
  7070.  
  7071. Support for these memory extenders is provided by two virtual device drivers, 
  7072. VEMM.SYS and VXMS.SYS.  Unlike most virtual device drivers, these drivers do 
  7073. not have corresponding physical device drivers, but access the operating 
  7074. system's memory manager to handle memory allocation requests from applications. 
  7075.  
  7076. MVDM supports the loading of DOS device drivers and TSR programs into XMS Upper 
  7077. Memory Blocks, in order to reduce memory consumption below the 640KB line, 
  7078. thereby leaving more base memory for applications.  Loading of these programs 
  7079. into UMBs is supported by the DEVICEHIGH statement in CONFIG.SYS and the 
  7080. LOADHIGH command included in AUTOEXEC.BAT or executed from the command line. 
  7081.  
  7082.  
  7083. ΓòÉΓòÉΓòÉ 17. Installing and Migrating Applications ΓòÉΓòÉΓòÉ
  7084.  
  7085. Installing DOS and Windows applications under OS/2 V2.0 is in most cases very 
  7086. similar to installing them in their native environments. However, since OS/2 
  7087. V2.0 is a true multitasking operating system, we should ensure that the 
  7088. installation programs do not introduce incompatibilities with existing 
  7089. programs. The flexibility in tailoring the virtual DOS machine environment for 
  7090. these programs, also gives us an opportunity to easily tune DOS settings to 
  7091. suit our needs. 
  7092.  
  7093. OS/2 V2.0 has a utility to help users place their application icons onto the 
  7094. desktop after they have been installed. The utility uses information stored in 
  7095. a migration database that is shipped with OS/2 V2.0. 
  7096.  
  7097. Systems administrators can use another utility to create their own migration 
  7098. database to install their corporation's unique applications. 
  7099.  
  7100. This chapter discusses the installation of DOS and Windows applications under 
  7101. OS/2 V2.0. It also shows how to use the application migration utilities shipped 
  7102. with OS/2 V2.0. 
  7103.  
  7104. We describe the use of the migration program in this chapter, and show an 
  7105. example of how to use the PARSEDB utility to create a customized migration 
  7106. database. 
  7107.  
  7108.  
  7109. ΓòÉΓòÉΓòÉ 17.1. Installing DOS Programs ΓòÉΓòÉΓòÉ
  7110.  
  7111. Application installation methods vary widely in the DOS world. Some 
  7112. installations involve nothing more than copying the software from diskette to 
  7113. the hard disk. In more complex applications, the install procedure may check 
  7114. the workstation configuration (both hardware and software), implement copy 
  7115. protection and modify system files. 
  7116.  
  7117. For most DOS applications, installation under OS/2 Version 2.0 is simply a 
  7118. matter of starting a DOS full-screen or windowed session and following the 
  7119. instructions supplied with the package as if the installation was taking place 
  7120. on a DOS system. However, some may not work correctly because of the special 
  7121. requirements of the installation program. 
  7122.  
  7123.  
  7124. ΓòÉΓòÉΓòÉ 17.1.1. General Installation Procedure for DOS Programs ΓòÉΓòÉΓòÉ
  7125.  
  7126. To install a new DOS program: 
  7127.  
  7128.  1. Read the installation instructions for the DOS program. 
  7129.  
  7130.  2. Select the OS/2 System icon. 
  7131.  
  7132.  3. Select the Command Prompts icon. 
  7133.  
  7134.  4. Select the DOS Full Screen icon. 
  7135.  
  7136.  5. Type the installation command as specified in the installation instructions 
  7137.     on the command prompt. 
  7138.  
  7139.     For example: 
  7140.  
  7141.         a:install
  7142.  
  7143.  6. Follow the instructions on the screen. 
  7144.  
  7145.  7. When installation is complete, close the Command Prompts folder. 
  7146.  
  7147. To add an icon to the desktop, you can use either: 
  7148.  
  7149.  The Program template in the Templates folder (refer to Running DOS 
  7150.   Applications.) 
  7151.  The Migrate Applications program (refer to Migrating Programs.). 
  7152.  
  7153.  
  7154. ΓòÉΓòÉΓòÉ 17.1.2. Installation Programs with Special Requirements ΓòÉΓòÉΓòÉ
  7155.  
  7156. Some DOS application installation programs will not run properly in the OS/2 
  7157. V2.0 virtual DOS machine, or will not install the program correctly. Some of 
  7158. the possible problems are as follows: 
  7159.  
  7160.  1. The installation program attempts to verify the version of DOS that is 
  7161.     running, and receives a response that it cannot understand. One example is 
  7162.     Lotus 1-2-3 Release 3.1+. 
  7163.  
  7164.     The OS/2 V2.0 virtual DOS machine environment can be customized to return a 
  7165.     DOS version in response to the installation program query and thus bypass 
  7166.     the problem. This is accomplished by changing the DOS_Version  parameters 
  7167.     in the DOS Settings facility, which is accessed by pressing the DOS 
  7168.     Settings push button on the Session page of the Settings notebook. 
  7169.  
  7170.     The DOS Settings facility and the available settings are described in 
  7171.     detail in DOS Settings. 
  7172.  
  7173.  2. The copy protection or user registration scheme implemented by the 
  7174.     application bypasses DOS and directly accesses the disk. The OS/2 V2.0 
  7175.     system will not allow the installation program to do this, since it may 
  7176.     interfere with other applications, and will terminate the virtual DOS 
  7177.     machine in which it is running. 
  7178.  
  7179. It may therefore be necessary to perform the installation in a native DOS 
  7180. environment by rebooting the workstation with a DOS boot diskette. When the 
  7181. installation is complete, the workstation can be rebooted under OS/2 V2.0 and 
  7182. the application added to the Workplace Shell. 
  7183.  
  7184.  
  7185. ΓòÉΓòÉΓòÉ 17.2. Planning Hard Disk Partitions ΓòÉΓòÉΓòÉ
  7186.  
  7187. If the workstation is booted from a DOS diskette in order to perform the DOS 
  7188. application install, the installation is restricted to those logical drives 
  7189. that have been formatted as FAT. This is because logical HPFS drives cannot be 
  7190. accessed in a native DOS environment. 
  7191.  
  7192. When the system is booted with DOS 5, HPFS drives are not assigned drive 
  7193. letters and are invisible to the user. If DOS 4.01 with CSD UR35284 is used to 
  7194. perform the boot, drive letters will be assigned to all drives, whether HPFS or 
  7195. FAT. However, you cannot access the files on the HPFS drives. With earlier 
  7196. versions of DOS, even FAT drives that lie beyond the first HPFS drive will not 
  7197. be assigned drive letters. 
  7198.  
  7199. Some installation programs store directory information into control files that 
  7200. are used at run time. For example, WordPerfect** 5.1 records the path to its 
  7201. subdirectories. On a hard disk with both FAT and HPFS logical drives, this can 
  7202. cause the installation program run in native DOS to record drive assignments 
  7203. that are wrong when the application is started from a virtual DOS machine. 
  7204.  
  7205. Consider the following example of a hard disk setup for dual boot or with Boot 
  7206. Manager: 
  7207.  
  7208. Table "Drive Letter Assignment" 
  7209.  
  7210. Note that FAT drive in the extended partition appears as drive E: to the OS/2 
  7211. Version 2.0 virtual DOS machine, but appears as drive D: when booted under DOS. 
  7212. Consequently, if the DOS application is installed on that partition when the 
  7213. system was booted under DOS, the drive letter it records in its control files 
  7214. will be D:. When the system is rebooted under OS/2 V2.0 and the application is 
  7215. run from a virtual DOS machine, the application will be looking to drive D:, 
  7216. which under OS/2 V2.0 is assigned to the HPFS drive of the extended partition. 
  7217. This will cause the application to miss the information it is seeking. 
  7218.  
  7219. The user may be able to change the control file information and correct the 
  7220. error through the application. However, if the system is booted from DOS and 
  7221. the application is started, it will again be looking for the wrong drive. 
  7222.  
  7223. In order to avoid this confusion we recommend that HPFS logical drives be 
  7224. placed last. In the above example, the FAT and HPFS logical drives in the 
  7225. extended partition should be transposed. This will allow the drive letters for 
  7226. the FAT partitions to be the same regardless of whether the workstation is 
  7227. booted from DOS or OS/2 Version 2.0. 
  7228.  
  7229. More details on hard disk management can be found in Chapter 4 of the OS/2 2.0 
  7230. Installation Guide. 
  7231.  
  7232.  
  7233. ΓòÉΓòÉΓòÉ 17.3. Installing Windows Programs ΓòÉΓòÉΓòÉ
  7234.  
  7235. Windows programs installation are usually performed from the DOS command 
  7236. prompt, or the Windows Program Manager. 
  7237.  
  7238. To install a new Windows program: 
  7239.  
  7240.  1. Read the the program installation instructions. 
  7241.  
  7242.  2. To install the program from a DOS command prompt: 
  7243.  
  7244.     a) Select the OS/2 System icon. 
  7245.  
  7246.     b) Select the Command Prompts folder. 
  7247.  
  7248.     c) Select DOS Full Screen. 
  7249.  
  7250.     d) Enter the installation command as specified in the installation 
  7251.        instructions. 
  7252.  
  7253.        For example: 
  7254.  
  7255.               a:setup
  7256.  
  7257.     e) Follow the instructions on the screen to complete the installation. 
  7258.  
  7259.  3. To install the program from the Program Manager: 
  7260.  
  7261.     a) Select the OS/2 System icon. 
  7262.  
  7263.     b) Select the Command Prompts folder. 
  7264.  
  7265.     c) Select WIN-OS/2 Full Screen. 
  7266.  
  7267.     d) Select Run from the File pull-down on the action bar. 
  7268.  
  7269.     e) Enter the installation command as specified in the installation 
  7270.        instructions. 
  7271.  
  7272.        For example: 
  7273.  
  7274.               a:setup
  7275.  
  7276.     f) Follow the instructions on the screen to complete the installation. 
  7277.  
  7278. To add an icon to the desktop, you can use either: 
  7279.  
  7280.  The Program template in the Templates folder (refer to Running DOS 
  7281.   Applications.) 
  7282.  The Migrate Applications program (refer to Migrating Programs.). 
  7283.  
  7284. If you use the Migrate Applications option, the program icon will be placed in 
  7285. the Windows Programs folder or the Additional Windows Programs folder on the 
  7286. desktop. 
  7287.  
  7288. The Migrate Applications program always sets up Windows programs to run in a 
  7289. WIN-OS/2 window session if possible. WIN-OS/2 window sessions cannot be used 
  7290. for programs that have to be run in real mode, such as Windows 2.0 programs. 
  7291. Therefore if you use the Migrate Applications utility on Windows 2.0 programs, 
  7292. open the Settings Notebook to the Sessions page and select the WIN-OS/2 full 
  7293. screen radio button. 
  7294.  
  7295.  
  7296. ΓòÉΓòÉΓòÉ 17.4. AUTOEXEC.BAT and CONFIG.SYS ΓòÉΓòÉΓòÉ
  7297.  
  7298. The installation program for a DOS or Windows application may alter the 
  7299. AUTOEXEC.BAT (usually to modify the PATH statement) and CONFIG.SYS (to modify 
  7300. the FILES and BUFFERS statements or add a DEVICE statement). Usually the copies 
  7301. edited are the ones found in the root directory of the OS/2 V2.0 boot drive. If 
  7302. the option is given the user should not allow the installation program to make 
  7303. the modifications before reviewing the changes. We recommend that you back up 
  7304. both of these files prior to running an installation. After installation, 
  7305. inspect the date and time stamps of the files to see if they have been 
  7306. modified. 
  7307.  
  7308. The most common change made to the AUTOEXEC.BAT file is to the PATH statement, 
  7309. so that the program being installed can be started from any subdirectory. The 
  7310. function of the PATH statement can be provided in a virtual DOS machine by 
  7311. using the Path and file name and Working directory fields of the Program page 
  7312. of the Settings notebook. 
  7313.  
  7314. Since the CONFIG.SYS is used for every virtual DOS machine, the device driver 
  7315. that an installation program adds will be loaded for all VDMs and consume 
  7316. system resources unnecessarily. We recommend that when the DOS application is 
  7317. added to the Workplace Shell the device driver statement be added via the 
  7318. DOS_DEVICE  setting  in the DOS Settings facility. This setting is accessed by 
  7319. pressing the DOS Settings push button on the Session  page of the Settings 
  7320. notebook. 
  7321.  
  7322.  
  7323. ΓòÉΓòÉΓòÉ 17.5. Migrating Programs ΓòÉΓòÉΓòÉ
  7324.  
  7325. OS/2 V2.0 provides a migration database (DATABASE.DAT) that contains parameters 
  7326. and settings for commonly used DOS, Windows and OS/2 programs. This binary 
  7327. database file is used by the Migrate Applications program to place the program 
  7328. icons onto the desktop and customize their Settings notebooks to the 
  7329. recommended values. 
  7330.  
  7331. Figure "The Migrate Applications Windows" 
  7332.  
  7333. To use the Migrate Applications program, follow these steps: 
  7334.  
  7335.  1. Locate and select the OS/2 System icon on the desktop. 
  7336.  
  7337.  2. Select System Setup. 
  7338.  
  7339.  3. Select Migrate Applications. 
  7340.  
  7341.     The Find Programs window appears. The Database Used for Find Option field 
  7342.     displays the default database (\OS2\INSTALL\DATABASE.DAT). The Migrate 
  7343.     Applications program compares programs on the hard disk with the list of 
  7344.     programs in the database and places any that match in a DOS, OS/2, or 
  7345.     Windows programs folder on the desktop. 
  7346.  
  7347.  4. From the Drives list, deselect the drives which should not be searched. The 
  7348.     default is to search all drives. 
  7349.  
  7350.  5. Deselect the types of programs that should not be migrated in the Migrate 
  7351.     type check boxes. The default is to migrate all the listed programs. 
  7352.  
  7353.  6. Select Find.... The Migrate Programs window appears. Programs are listed in 
  7354.     the Applications list box. 
  7355.  
  7356.  7. If your program is not on the list: 
  7357.  
  7358.     a) Select the Add Programs... push button. The Add Programs window appears. 
  7359.        Programs are listed in the Available Programs list. 
  7360.  
  7361.     b) Highlight a program. The Working directory and Program title fields are 
  7362.        filled in. Type a new title if required. 
  7363.  
  7364.     c) Type the appropriate parameters for the selected program in the 
  7365.        Parameters field. 
  7366.  
  7367.     d) Select the types of programs to migrate in the Program type field. The 
  7368.        Migrate Applications program creates the Additional Programs folders 
  7369.        based on the types of programs specified. 
  7370.  
  7371.     e) Select Add. The program moves to the Selected Programs list. 
  7372.  
  7373.     f) Select OK. The Migrate Programs window appears. 
  7374.  
  7375.  8. Select Migrate to migrate all the selected programs. When migration is 
  7376.     complete, the Find Programs window reappears. 
  7377.  
  7378.  9. Select Exit. 
  7379.  
  7380. The Migrate Applications program creates a DOS Programs folder and a Windows 
  7381. Programs folder. The programs in these folders have the recommended 
  7382. pre-selected settings that work best for your programs' performance. 
  7383.  
  7384. If the Add Programs option was used, an Additional DOS Programs folder and an 
  7385. Additional Windows Programs folder will also be created. The programs in these 
  7386. folders have default  settings. If these programs do not run correctly, specify 
  7387. other settings. See DOS Settings on the use of the settings. 
  7388.  
  7389.  
  7390. ΓòÉΓòÉΓòÉ 17.6. Creating a Customized Migration Database ΓòÉΓòÉΓòÉ
  7391.  
  7392. Some corporate users have an installed base of unique or custom-written DOS and 
  7393. Windows applications. These programs will not be listed in the migration 
  7394. database (DATABASE.DAT) that is supplied with OS/2 V2.0. The PARSEDB.EXE 
  7395. program is provided by OS/2 V2.0 to allow a system administrator to build a 
  7396. customized migration database that can be used to set up these unique 
  7397. applications on the Workplace Shell desktop. 
  7398.  
  7399.  
  7400. ΓòÉΓòÉΓòÉ 17.6.1. PARSEDB ΓòÉΓòÉΓòÉ
  7401.  
  7402. A customized migration database is created as follows: 
  7403.  
  7404.  1. Create the input text_database file 
  7405.  
  7406.  2. Run PARSEDB to create the binary database file. 
  7407.  
  7408. To start PARSEDB, type the following statement from a command prompt: 
  7409.  
  7410.  PARSEDB [path] DBTAGS.DAT [path] text_database [path] binary_database
  7411.  
  7412. where: 
  7413.  
  7414.  DBTAGS.DAT is the file name that contains the definitions for the tags used 
  7415.   to define the DOS settings 
  7416.  text_database is the name of the file that contains the program settings for 
  7417.   a specific DOS, OS/2 or Windows program 
  7418.  binary_database is the name of the new migration database file. 
  7419.  
  7420. The text_database file is the main input file for PARSEDB that has to be 
  7421. created. 
  7422.  
  7423. For example, type the following statement to create a  new database named 
  7424. MYDATA.DAT: 
  7425.  
  7426. PARSEDB E:\OS2\INSTALL\DBTAGS.DAT MYDATA.TXT MYDATA.DAT
  7427.  
  7428. Note that you must specify a file name for the binary database file to prevent 
  7429. the PARSEDB utility program from overwriting the default database file 
  7430. DATABASE.DAT. 
  7431.  
  7432. When creating the text_database file, each program must have the following 
  7433. migration information: 
  7434.  
  7435. NAME      Name of the file that runs the program. 
  7436.  
  7437. TITLE     Program object name that appears below the icon. 
  7438.  
  7439. TYPE      DOS, Windows or OS/2 
  7440.  
  7441. ASSOC_FILE File name associated with the file name specified in the Name field. 
  7442.           Use this file name to uniquely identify the program. 
  7443.  
  7444. DEF_DIR   Directory that the program is installed into. 
  7445.  
  7446. ASSOC_FILE and DEF_DIR can have NULL values; NULL values must be included when 
  7447. defining the program if specific values for these fields cannot be provided. 
  7448.  
  7449. When creating MYDATA.TXT, group the settings for a given program on consecutive 
  7450. lines. Use blank lines to mark the end of a program's settings. Begin non-blank 
  7451. lines with a token. The tag file DBTAGS.DAT defines valid token settings, 
  7452. limits, and default values for various DOS properties. 
  7453.  
  7454. Here is the listing of DBTAGS.DAT: DBTAGS.DAT 
  7455.  
  7456. The layout of each line in DBTAGS.DAT is as follows: 
  7457.  
  7458. INDEX VALUE TYPE (optional comments)
  7459.  
  7460. where: 
  7461.  
  7462. INDEX     Is a sequence number 
  7463.  
  7464. VALUE     Is the name of the setting 
  7465.  
  7466. TYPE      Is the type of the value. 
  7467.  
  7468. TYPE is one of the following: 
  7469.  
  7470. NOP       Comments; any line with this type is ignored 
  7471.  
  7472. STR       A string value 
  7473.  
  7474. INT       An integer value 
  7475.  
  7476. BOOL      Boolean, with value of ON or OFF 
  7477.  
  7478. BYTE      Program type, either DOS, OS/2, or Windows. 
  7479.  
  7480. MLSTR     A multi-line string with component lines on individual lines in the 
  7481.           text_database file. 
  7482.  
  7483. Using these types, various settings for programs can be defined. Do not edit 
  7484. DBTAGS.DAT or create a new one; the tag file is available only as a reference 
  7485. when creating the MYDATA.TXT file. 
  7486.  
  7487. PARSEDB checks the validity of all entries in MYDATA.TXT and compares them to 
  7488. the  settings definitions in DBTAGS.DAT. If all entries are valid, PARSEDB 
  7489. creates a binary database named MYDATA.DAT. 
  7490.  
  7491. Errors in the text file will cause PARSEDB to exit and display a message: 
  7492.  
  7493.  A message that a file is corrupted indicates embedded ASCII NUL characters in 
  7494.   the input text file. 
  7495.  A message about an invalid setting indicates the use of a setting not found 
  7496.   in DBTAGS.DAT. The message should include a line number and the name of the 
  7497.   input file. 
  7498.  A message that an entry has missing parameters indicates the absence of the 
  7499.   minimum settings for the entry. 
  7500.  
  7501. PARSEDB does not check for duplicate entries in the input text file, nor does 
  7502. it require settings to be in any particular order. It is also not case 
  7503. sensitive, that is, "Off" is treated the same as "OFF". 
  7504.  
  7505. We recommend that a copy of the input text file (DATABASE.TXT) for the default 
  7506. migration database file (DATABASE.DAT) be made and used as the template for 
  7507. your own input file. A sample input text file is listed below. 
  7508.  
  7509. User Definitions for other Applications 
  7510.  
  7511.  
  7512. ΓòÉΓòÉΓòÉ 17.7. Summary ΓòÉΓòÉΓòÉ
  7513.  
  7514. DOS and Windows application installation under OS/2 V2.0 is generally performed 
  7515. from a DOS command prompt or from the WIN-OS/2 Program Manager. In some cases, 
  7516. it may be necessary to boot from a DOS diskette to perform the install. 
  7517. Modifications made to CONFIG.SYS and AUTOEXEC.BAT by installation programs 
  7518. should be carefully reviewed. 
  7519.  
  7520. If the OS/2 V2.0 system is to be set up for Boot Manager or dual boot to DOS, 
  7521. the arrangement of the hard disk partitions needs to be planned. 
  7522.  
  7523. The Migrate Applications program is used to migrate already installed DOS, 
  7524. Windows, and OS/2 programs, and creates and places the program objects in a 
  7525. folder on the desktop. If the DOS or Windows program is in the migrate database 
  7526. \OS2\INSTALL\DATABASE.DAT, the Migrate Applications program automatically 
  7527. selects the recommended DOS settings for the program. 
  7528.  
  7529. The Migrate Applications program always sets up Windows programs to run in a 
  7530. WIN-OS/2 window session, if possible. Some exceptions exist, for example, 
  7531. CorelDraw!** and Arts & Letters**. Those programs use some very special Windows 
  7532. programming techniques, which can cause some problems in a "seamless" WIN-OS/2 
  7533. VDM. This may not happen in every user scenario but it was felt to be safer to 
  7534. install those applications as fullscreen SAVDMs. 
  7535.  
  7536. The Migrate Applications program is used: 
  7537.  
  7538.  During installation of the OS/2 Version 2.0 operating system if you have DOS, 
  7539.   OS/2, or Windows programs already installed on your hard disk. 
  7540.  If a DOS, OS/2, or Windows program is added to a working OS/2 Version 2.0 
  7541.   system. 
  7542.  
  7543. A utility, PARSEDB, is supplied to help system administrators to add an 
  7544. organization's unique applications to the migration database, or to create 
  7545. their own. 
  7546.  
  7547.  
  7548. ΓòÉΓòÉΓòÉ 18. Windows Applications ΓòÉΓòÉΓòÉ
  7549.  
  7550. OS/2 Version 2.0 provides the capability for Windows applications to run under 
  7551. OS/2 Version 2.0, using its WIN-OS/2 component.  With this support, 
  7552. applications written for Windows 3.0 and Windows 2.x can coexist and execute 
  7553. with OS/2 and DOS applications in the same machine under OS/2 Version 2.0. 
  7554.  
  7555. Figure "Windows Applications Running under OS/2 Version 2.0" 
  7556.  
  7557. Each Windows application executes as a protected mode process within a VDM. As 
  7558. such, Windows applications are subject to the same application protection 
  7559. facilities provided to other protected mode applications (both OS/2 and MVDM 
  7560. tasks) under OS/2 Version 2.0.  Windows applications are protected from other 
  7561. Windows applications and from DOS and OS/2 applications executing in the 
  7562. system.  This is in contrast to the native Windows 3.0 environment, where 
  7563. protection is limited to DOS applications (Windows applications share a common 
  7564. address space), and is only available when Windows is running in standard or 
  7565. 386 enhanced modes. 
  7566.  
  7567. The execution of Windows applications in a protected environment allows these 
  7568. applications to take full advantage of the pre-emptive multitasking 
  7569. capabilities of OS/2 Version 2.0, with full pre-emptive multitasking between 
  7570. Windows applications, OS/2 applications and DOS applications.  This is again in 
  7571. contrast to the native Windows 3.0 environment, where pre-emptive multitasking 
  7572. is available only for DOS applications and only when Windows 3.0 is running in 
  7573. enhanced mode, thereby impacting performance and preventing many applications 
  7574. written for previous versions of Windows from executing.  OS/2 Version 2.0 has 
  7575. no such restriction. 
  7576.  
  7577.  
  7578. ΓòÉΓòÉΓòÉ 18.1. Windows 3.0 Execution Modes ΓòÉΓòÉΓòÉ
  7579.  
  7580. The native Windows 3.0 environment has three execution modes, though the 
  7581. options available to any user depend upon the machine's processor and the 
  7582. amount of installed memory. These modes are important, as they are relevant, to 
  7583. the discussion later of the way in which OS/2 runs Windows applications. The 
  7584. initial description of each mode comes from the Microsoft Windows User's Guide. 
  7585.  
  7586.  
  7587. ΓòÉΓòÉΓòÉ 18.1.1. Real Mode ΓòÉΓòÉΓòÉ
  7588.  
  7589. Real Mode:  An operating mode that Windows runs in to provide maximum 
  7590.             compatibility with versions of Windows applications prior to 3.0. 
  7591.             Real mode is the only mode available for computers with less than 
  7592.             1MB of extended memory. 
  7593.  
  7594. Real mode is equivalent to previous versions of Windows (2.x), and can address 
  7595. 640KB of conventional memory, plus LIM EMS Version 4.0 expanded memory. 
  7596. Extended memory can be used for a virtual disk or disk caching only. 
  7597.  
  7598. Real mode requires an 8088 processor or above, and 640KB of installed memory. 
  7599. Real mode requires 384KB of free conventional memory after DOS and other memory 
  7600. resident software, including network drivers, is loaded. 
  7601.  
  7602. Real mode is supported for Windows and its applications under OS/2 Version 2.0, 
  7603. in either of two ways: 
  7604.  
  7605.  The WIN-OS/2 kernel provided by OS/2 Version 2.0 may be used to run Windows 
  7606.   applications in real mode. 
  7607.  
  7608.  The commercially available Windows 3.0 product may be run in real mode in a 
  7609.   VDM, and real mode applications started from within this VDM by the Windows 
  7610.   Program Manager. 
  7611.  
  7612. Note that the commercially available Windows product cannot be run in standard 
  7613. or enhanced modes in a VDM due to Windows' memory management architecture; 
  7614. Windows assumes that it is a DPMI host and cannot act as a DPMI client.  Many 
  7615. Windows applications run quite adequately in real mode; in fact, some 
  7616. applications written for Windows 2.x cannot run in any other mode. 
  7617.  
  7618.  
  7619. ΓòÉΓòÉΓòÉ 18.1.2. Standard Mode ΓòÉΓòÉΓòÉ
  7620.  
  7621. Standard Mode:  The normal operating mode for running Windows. This mode 
  7622.                 provides access to extended memory and also lets you switch 
  7623.                 among non-Windows applications. 
  7624.  
  7625. Standard mode uses the 80286 processor's protected mode to provide direct 
  7626. access for Windows and Windows applications to up to 16MB of extended memory. 
  7627. Expanded memory for DOS applications is only supported with physical expanded 
  7628. memory cards (emulation of expanded memory using extended memory is not 
  7629. supported). 
  7630.  
  7631. Standard mode requires an 80286 processor or above, and at least 1MB of 
  7632. installed memory, with a minimum 192KB of free extended memory.  The XMS driver 
  7633. HIMEM.SYS must also be loaded.  Windows applications must be written to comply 
  7634. with the memory management rules for Windows 3.0 in order to run in standard 
  7635. mode. 
  7636.  
  7637. Standard mode is recommended by Microsoft when running only Windows 
  7638. applications (that is, no DOS applications) in certain configurations, even on 
  7639. an 80386 machine. In the Windows 3.0 manual, on page 429, it is suggested that 
  7640. users running only Windows 3.0 applications should run in standard mode, even 
  7641. on 80386 systems with 2-3MB of memory, as there is a performance improvement in 
  7642. doing so. 
  7643.  
  7644. Standard mode is necessary for some Windows applications (for example, 
  7645. Microsoft Excel** Version 3.0). To accommodate such applications, OS/2 Version 
  7646. 2.0 must provide additional support.  Basically, these applications need to 
  7647. access DPMI services for extended memory support, which is available under 
  7648. Windows 3.0 when running in standard or enhanced modes.  See DOS Protected Mode 
  7649. Interface for further information on DPMI support under OS/2 Version 2.0. 
  7650.  
  7651. The other requirement is to supply Windows services to Windows applications. 
  7652. This service is provided in OS/2 Version 2.0 by modifying the Windows kernel 
  7653. and running it in standard mode in a VDM. As part of the joint development and 
  7654. cross-licensing agreement between IBM and Microsoft, IBM has access to the 
  7655. Windows source code. IBM has modified the source to provide a Windows kernel 
  7656. (WIN-OS/2)  capable of running as a DPMI client within a VDM (the retail 
  7657. version of Windows 3.0 can only function as a DPMI host), and includes this 
  7658. kernel as part of the OS/2 Version 2.0 product. 
  7659.  
  7660. OS/2 therefore supports Windows applications running in standard mode in a VDM. 
  7661. Use of the VDM design, which provides a self-contained DOS environment, means 
  7662. that the environment is identical, from the application's point of view, to 
  7663. running under Windows loaded in standard mode, on DOS. This design therefore 
  7664. provides the maximum compatibility with the DOS/Windows environment. In fact, 
  7665. it offers a wider range of compatibility, since Windows 2.x applications, which 
  7666. require real mode operation under Windows 3.0 in DOS, can be run concurrently 
  7667. with Windows 3.0 applications running in standard mode.  This combination is 
  7668. not possible at the same time under DOS/Windows 3.0. 
  7669.  
  7670.  
  7671. ΓòÉΓòÉΓòÉ 18.1.3. 386 Enhanced Mode ΓòÉΓòÉΓòÉ
  7672.  
  7673. 386 Enhanced Mode:  A mode that Windows runs in to access the virtual memory 
  7674.                     capabilities of the Intel 80386 processor. This mode allows 
  7675.                     Windows to use more memory than is physically available and 
  7676.                     to provide multi-tasking for non-Windows applications. 
  7677.  
  7678. 386 enhanced mode uses the 80386 processor's protected mode to provide direct 
  7679. access for Windows and Windows applications to up to 16MB of extended memory. 
  7680. In addition, the virtual 8086 mode of the 80386 is used to provide multiple DOS 
  7681. environments for non-Windows applications. Most DOS applications can be run in 
  7682. a window.  Virtual memory support is provided, for Windows applications only, 
  7683. using the demand paging feature of the 80386 processor. 
  7684.  
  7685. 386 enhanced mode requires an 80386 processor or above, at least 2MB of 
  7686. installed memory, with a minimum 1MB of free extended memory.  The XMS driver 
  7687. HIMEM.SYS must also be loaded. Windows applications must be written to comply 
  7688. with the memory management rules for Windows 3.0 to run in 386 enhanced mode. 
  7689.  
  7690. The 386 enhanced mode of Windows 3.0 provides a number of additional 
  7691. capabilities over standard mode: 
  7692.  
  7693.  The capability for pre-emptive multitasking  of DOS sessions 
  7694.  
  7695.  Demand paging for efficient virtual memory. 
  7696.  
  7697. Both of these capabilities are provided by OS/2 Version 2.0 itself for both DOS 
  7698. and Windows applications, independent of the Windows kernel.  There is hence no 
  7699. need to provide such functions within the Windows kernel. 
  7700.  
  7701. There are, however, a small number of Windows applications which require 
  7702. enhanced mode to run.  Such applications require enhanced mode either because 
  7703. they rely on features only available in enhanced mode, such as Windows 3.0's 
  7704. permanent swap file capability (such as Caere Omnipage**), or have been coded 
  7705. using the WINMEM32.DLL, a set of routines that provide some 32-bit functions 
  7706. for Windows applications, such as Wolfram Research's Mathematica**. 
  7707.  
  7708. It is believed that there are only, at maximum, three or four such applications 
  7709. on the market, which represents less than 0.3% of Windows 3.0 applications 
  7710. (assuming Microsoft's quoted figure of 1500 Windows applications).  It is 
  7711. unlikely there will ever be many in the latter category of applications, since 
  7712. the WINMEM32.DLL is very difficult to use, and Microsoft itself warns in 
  7713. Appendix E of the Windows Programmer's Reference: "only experienced Windows 
  7714. application programmers with extensive experience writing assembly-level code 
  7715. should attempt to use these functions in an application." 
  7716.  
  7717. This warning is necessary because even something as basic as memory management 
  7718. using these routines can be very complex, and requires the programmer to create 
  7719. assembly language interfaces between the 16- and 32-bit parts of a program 
  7720. (note that such "thunks" are provided by OS/2 Version 2.0 between 16-bit and 
  7721. 32-bit modules; see OS/2 Version 2.0 - Volume 1:  Control Program).  Charles 
  7722. Petzold, possibly the most widely respected authority on Windows programming, 
  7723. whose book on the subject is a standard reference work, concluded on this 
  7724. subject that "something is seriously wrong when memory access becomes 
  7725. difficult", and contrasted the current Windows approach with the ease of 32-bit 
  7726. memory management under OS/2 Version 2.0. 
  7727.  
  7728. Applications which require enhanced mode will not be supported by OS/2 Version 
  7729. 2.0. Support of this mode requires Windows to run at the Ring 0 privilege level 
  7730. in the 80386 processor, which allows Windows or a Windows application to access 
  7731. all system memory and resources, including those belonging to the operating 
  7732. system itself.  This could result in a serious breach of system integrity, and 
  7733. is therefore not permitted under OS/2 Version 2.0. 
  7734.  
  7735. So, although there will almost certainly be a very small minority of Windows 
  7736. applications that will not run under OS/2 Version 2.0, the vast majority will 
  7737. run, and in a mode which allows access to their full function.  Indeed, to the 
  7738. Windows application, the environment will appear exactly the same as if the 
  7739. application were running under DOS/Windows in standard mode. 
  7740.  
  7741.  
  7742. ΓòÉΓòÉΓòÉ 18.2. Windows Applications under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  7743.  
  7744. Under OS/2 Version 2.0, Windows applications are treated as special cases of 
  7745. DOS applications, which need a special environment in which to run.  Therefore, 
  7746. the key to Windows application compatibility is to provide these applications 
  7747. with as similar an environment as possible to that experienced under DOS, while 
  7748. taking advantage of the inherent design superiority of OS/2. 
  7749.  
  7750.  
  7751. ΓòÉΓòÉΓòÉ 18.2.1. Supported Components ΓòÉΓòÉΓòÉ
  7752.  
  7753. The following components of Windows 3.0 are supported and available within the 
  7754. OS/2 V2.0 Windows kernel: 
  7755.  
  7756.  Windows real mode kernel (WINOS2.COM and KERNEL.EXE) 
  7757.  
  7758.  Modified Windows standard mode kernel (OS2K286.EXE) 
  7759.  
  7760.  Modified DOS Extender (VDPX.SYS) 
  7761.  
  7762.  Print Manager (Spool Function) 
  7763.  
  7764.  Program Manager: 
  7765.  
  7766.    - Permits the starting of multiple Windows applications in a VDM 
  7767.    - Permits switching between Windows applications in the VDM 
  7768.  
  7769.  Help Manager 
  7770.  
  7771.  Video device drivers 
  7772.  
  7773.  Keyboard, mouse and communications device drivers 
  7774.  
  7775.  Task Manager 
  7776.  
  7777.  Windows user and GDI DLLs 
  7778.  
  7779.  Printer device drivers 
  7780.  
  7781.  Clipboard support 
  7782.  
  7783.  Setup, with only one function left in order to install Windows network device 
  7784.   drivers (DLLs). 
  7785.  
  7786.   Note:   This is really not necessary to do if you are already running any 
  7787.           network requester code under OS/2 itself. This would be transparent 
  7788.           to the entire system and therefore every VDM and WIN-OS/2 session 
  7789.           will have full access to the network, printers, files, etc. 
  7790.  
  7791.  Control Panel, with functions limited to: 
  7792.  
  7793.    - Printer Install 
  7794.    - Color 
  7795.    - Fonts 
  7796.    - Sound 
  7797.    - Mouse 
  7798.    - International 
  7799.    - KBD (Keyboard rate). 
  7800.  
  7801. The Clock program is available in a Multiple Application VDM (MAVDM) (see 
  7802. Methods of Execution). 
  7803.  
  7804. The following Microsoft Windows 3.0 components are not included within OS/2 
  7805. V2.0 (even though they would run just as any other Windows application): 
  7806.  
  7807.  File Manager 
  7808.  Systems Editor (SYSEDIT) 
  7809.  Games 
  7810.  Write 
  7811.  Terminal 
  7812.  Notepad 
  7813.  Cardfile 
  7814.  Calendar 
  7815.  Calculator 
  7816.  PIF Editor 
  7817.  Paintbrush 
  7818.  Recorder 
  7819.  Wallpaper bitmaps 
  7820.  
  7821. For each of these functions, equivalent capabilities are provided by OS/2 
  7822. Version 2.0, or these functions are not required within the OS/2 Version 2.0 
  7823. environment. 
  7824.  
  7825. Multimedia Extensions (MME) for Windows 
  7826.  
  7827. Multimedia Extensions for Windows can be installed under WIN-OS/2 and are fully 
  7828. supported. 
  7829.  
  7830. Some multimedia applications may require more than the default DPMI memory. If 
  7831. that happens, the WIN-OS/2-Setting DPMI_MEMORY_LIMIT should be adjusted to the 
  7832. appropriate value. 
  7833.  
  7834.  
  7835. ΓòÉΓòÉΓòÉ 18.2.2. Methods of Execution ΓòÉΓòÉΓòÉ
  7836.  
  7837. Windows applications may be run under OS/2 Version 2.0 in six ways: 
  7838.  
  7839.  The original licensed Windows V3.0 or Windows V2.x may be started in a VDM, 
  7840.   and will allow Windows V3.0 and Windows V2.x, and its applications, to be run 
  7841.   in real mode. 
  7842.  
  7843.  A Single Application VDM (SAVDM) may be started, for a single Windows 
  7844.   application. The icon supplied with the Windows application will be defined 
  7845.   within the Workplace Shell desktop. 
  7846.  
  7847.  A Multiple Application VDM (MAVDM) may be started, which activates the 
  7848.   Windows Program Manager, allowing the user to access a number of Windows 
  7849.   applications. 
  7850.  
  7851.  A Separate "seamless" WIN-OS/2 VDM may be used, which is basically a SAVDM 
  7852.   running in its own window under the Workplace Shell.  See "Seamless" WIN-OS/2 
  7853.   VDM below for further information. 
  7854.  
  7855.  A common "seamless" WIN-OS/2 VDM may be used, which is a special kind of 
  7856.   MAVDM. WIN-OS/2 will start all "seamless" WIN-OS/2 VDMs in a single session, 
  7857.   but in separate windows running under the Workplace Shell.  See Common 
  7858.   "Seamless" WIN-OS/2 VDM below for further information. 
  7859.  
  7860.  A separate "seamless" WIN-OS/2 VDM may be used, and the WIN-OS/2 Program 
  7861.   Manager may be launched from there. This will allow to launch other Windows 
  7862.   applications from there and therefore, this would actually be a MAVDM running 
  7863.   in its own window under the Workplace Shell. Every Windows application 
  7864.   launched from there would run in its own window under the Workplace Shell but 
  7865.   share the same WIN-OS/2 kernel. 
  7866.  
  7867. No license of Windows V3.0 or Windows V2.x is necessary to run Windows 
  7868. applications, as the Windows environment is an implementation of Windows V3.0 
  7869. and Windows V2.x within OS/2 V2.0 (WIN-OS/2) itself.  Multiple instances of any 
  7870. of the above methods may be started in the same system. 
  7871.  
  7872. However, note that in the current release, "seamless" WIN-OS/2 VDMs and common 
  7873. "seamless" WIN-OS/2 VDMs may only be started on machines with VGA graphics. 
  7874. Seamless execution of Windows applications is not supported using other 
  7875. graphics modes. 
  7876.  
  7877. The following applications are started (iconized) when the first VDM (either 
  7878. SAVDM or MAVDM) is started: 
  7879.  
  7880.  Modified Windows Clipboard Viewer Program 
  7881.  
  7882.  DDE Server/Agent Application 
  7883.  
  7884.  Presentation Manager icon 
  7885.  
  7886.  Task Manager (no icon) 
  7887.  
  7888.  Windows Program Manager (not visible in a SAVDM) 
  7889.  
  7890.  Clock (MAVDM only) 
  7891.  
  7892.  Windows Control Panel (MAVDM only). 
  7893.  
  7894. Each of these methods is described in the following sections. 
  7895.  
  7896. Single Application VDM (SAVDM) 
  7897.  
  7898. A SAVDM is the recommended way of running Windows applications under  OS/2 
  7899. Version 2.0 in a non-VGA system, such as a PS/2 with an XGA or 8514/A display 
  7900. adapter, because seamless execution is only supported with VGA graphics. Using 
  7901. a SAVDM is also recommended if the user wishes to run Windows applications in 
  7902. real mode (seamless execution is supported only in Windows standard mode). 
  7903.  
  7904. Since the Windows application runs in a self-contained Windows environment in 
  7905. its own VDM, it is fully protected from other applications, and the system is 
  7906. protected from it.  This means that if the application crashes for any reason, 
  7907. it only affects its own VDM, and thus only that one application.  Other Windows 
  7908. or DOS applications running in other VDMs are not affected, nor are OS/2 
  7909. applications.  This represents a significant improvement in reliability over 
  7910. DOS/Windows, in which a failure in one Windows application may bring down the 
  7911. entire Windows system or corrupt the data areas of other Windows programs, 
  7912. since all Windows applications and Windows itself share the same address space. 
  7913.  
  7914. Figure "Single Windows Application Running under OS/2 Version 2.0" 
  7915.  
  7916. Also, by running in SAVDMs, Windows applications are timesliced more 
  7917. effectively than in a MAVDM or native DOS/Windows environment, since each 
  7918. application is under the control of OS/2's scheduler and its pre-emptive 
  7919. multitasking.  In a MAVDM environment, all Windows applications are still 
  7920. subject to the cooperative multitasking under Windows itself. 
  7921.  
  7922. Ctrl-Esc is the key combination used to display the Windows "Window List". 
  7923.  
  7924. Alt-Esc is the key combination used to switch to the next session as defined in 
  7925. the Workplace Shell. 
  7926.  
  7927. The SAVDM provides a simple approach to Presentation Manager integration.  The 
  7928. application is loaded from the Workplace Shell in a very similar way to a DOS 
  7929. application, and the user may easily switch back to Presentation Manager, as 
  7930. well as share data via clipboard or DDE with other Windows or Presentation 
  7931. Manager  applications. The icon displayed on the Workplace Shell desktop is the 
  7932. application's own Windows icon. 
  7933.  
  7934. Each SAVDM will indicate the Windows execution mode based on the file type 
  7935. specified in the EXE header of the Windows application. Real mode will be 
  7936. indicated for Windows applications written for versions of Windows prior to 
  7937. 3.0.  Auto-Select (real or standard mode) is selected by default for Windows 
  7938. 3.0 applications, based on processor type. 
  7939.  
  7940. Multiple Application VDM (MAVDM) 
  7941.  
  7942. The MAVDM is almost identical to running Windows 3.0 on a DOS-based machine. 
  7943. The MAVDM uses the Windows 3.0 Program Manager to start multiple Windows 
  7944. applications within the same VDM, running on a separate Windows desktop. It 
  7945. therefore provides maximum "look and feel" compatibility for the DOS/Windows 
  7946. user migrating to OS/2 Version 2.0. 
  7947.  
  7948. Note that the use of a MAVDM or the common "seamless" WIN-OS/2 VDM  is a 
  7949. requirement where Windows applications must communicate with one another via 
  7950. shared memory. 
  7951.  
  7952. Ctrl-Esc is used within the VDM to display the Windows "Window List". 
  7953.  
  7954. Alt-Esc is used to switch to the next session defined in the Workplace Shell. 
  7955.  
  7956. For a MAVDM, the Workplace Shell icon will represent the MAVDM itself, rather 
  7957. than the applications executing within the VDM.  Terminating an application 
  7958. within the VDM will not terminate the VDM itself.  The user must select Exit 
  7959. Windows in the Windows Program Manager to terminate the VDM, or close the VDM 
  7960. from the Workplace Shell. 
  7961.  
  7962. In the MAVDM and the common "seamless" WIN-OS/2 VDM environment, all Windows 
  7963. applications are still subject to the cooperative multitasking of Windows 
  7964. itself.  Since several Windows applications are typically loaded in the same 
  7965. VDM, the MAVDM environment shares some of the pitfalls of DOS/Windows in terms 
  7966. of robustness.  If one Windows application crashes within a MAVDM,  it may 
  7967. cause all the applications within that VDM to fail.  However, the effect is 
  7968. only within that VDM; other VDMs running DOS or Windows applications, and other 
  7969. processes executing under OS/2 Version 2.0, are not affected and continue 
  7970. execution.  So even here there are benefits from running Windows applications 
  7971. under OS/2, for greater resilience from system crashes.  Furthermore, the MAVDM 
  7972. environment provides additional error checking and handling over that provided 
  7973. by Windows 3.0 itself. 
  7974.  
  7975. "Seamless" WIN-OS/2 VDM 
  7976.  
  7977. One of the goals of OS/2 2.0 is to be the integrating platform of choice; that 
  7978. is, to provide a desktop environment from which all types of applications: 
  7979.  
  7980.  16-bit OS/2 
  7981.  32-bit OS/2 
  7982.  DOS 
  7983.  Windows 
  7984.  
  7985. may be executed in a uniform manner.  Although OS/2 V2.0 is able to support 
  7986. Windows applications effectively in SAVDMs, the additional ability to launch a 
  7987. Windows application from a Workplace Shell object, and execute it on the OS/2 
  7988. desktop along with Presentation Manager and DOS applications, achieves the goal 
  7989. of creating an environment that is explicitly simple and uniform enough that 
  7990. the end user need not be concerned with the implicit differences between the 
  7991. types of applications that need to be executed in it.  OS/2 V2.0 will concern 
  7992. itself with the differences and "seamlessly" accommodate the applications. 
  7993. This level of support extends not only to execution but to installation and 
  7994. configuration of the application as well. 
  7995.  
  7996. Figure "Single Windows Application(s) Running "Seamless" on the OS/2 Version 
  7997. 2.0 Desktop" 
  7998.  
  7999. The appearance of Windows applications on the Workplace Shell desktop requires 
  8000. that the Windows video device driver and the Presentation Manager video device 
  8001. driver communicate and coordinate their access of the video hardware.  Each 
  8002. device driver effectively "owns" its area of the screen.  Allowing the Windows 
  8003. display device driver to directly access the video hardware avoids the more 
  8004. cumbersome process of a complete task switch.  However, this hardware access 
  8005. poses integrity problems in the areas of simultaneous access of hardware, 
  8006. rectangle invalidation handling, window management, and the exchange of window 
  8007. state information between Presentation Manager and seamless VDMs supported by 
  8008. separate video device drivers. 
  8009.  
  8010. To address these problems, a high performance virtual device driver named 
  8011. (VWIN.SYS), capable of interprocess communication, was created.  This VDD 
  8012. serializes the simultaneous accesses to the hardware, oversees the exchange of 
  8013. window state information between Presentation Manager and seamless VDMs, and 
  8014. establishes the addressability of Presentation Manager resources (either 
  8015. directly or indirectly) by the Windows display device driver. 
  8016.  
  8017. When the system is initialized, the Presentation Manager display driver calls 
  8018. the VWIN.SYS driver, and passes a pointer to an array of structures that 
  8019. specify the protocol required to enable the Windows device driver to access 
  8020. Presentation Manager resources.  To prevent a seamless Windows application from 
  8021. hanging the entire Workplace Shell desktop, the Windows video device driver and 
  8022. the Presentation Manager video device driver together implement and monitor a 
  8023. VDM "heartbeat" or counter.  This counter is stored in the Presentation Manager 
  8024. display driver's data area and is made available to the Windows display driver. 
  8025.  
  8026. The "heartbeat" counter information is made available to the Windows DD to 
  8027. indicate that hardware access is in progress by the Windows DD. The "heartbeat" 
  8028. counter is incremented by the Windows DD prior to the video hardware access. If 
  8029. a Windows application is locking up the Workplace Shell desktop, it is the 
  8030. responsibility of VWIN.SYS to identify the current owner of the semaphore, 
  8031. terminate the VDM and tell the Presentation Manager DD to clean up. 
  8032.  
  8033. In the event that the Presentation Manager display device driver requests 
  8034. hardware resources and the time interval allotted for this access to occur is 
  8035. exceeded, then: 
  8036.  
  8037.  1. If it is the first request, the Presentation Manager display driver records 
  8038.     the heartbeat value, process ID and thread ID of the process in control of 
  8039.     the hardware, and raises an internal flag. 
  8040.  
  8041.  2. If it is the second request, and the heartbeat value, PID and TID have not 
  8042.     changed, the Presentation Manager display driver calls the Windows display 
  8043.     driver before clearing the flag, and passes it the PID and TID. 
  8044.  
  8045.     It is the responsibility of the Windows driver to use the PID and TID to 
  8046.      identify the process that is monopolizing the hardware resources and 
  8047.      inform the Presentation Manager driver. 
  8048.  
  8049.     If it is an active, seamless VDM, WIN-OS/2 will terminate the VDM and 
  8050.      inform the Presentation Manager driver to clean up. 
  8051.  
  8052.     If the PID and TID are invalid, the Windows driver will inform the 
  8053.      Presentation Manager driver to clean up. 
  8054.  
  8055.     If the PID and TID belong to a Presentation Manager application, the 
  8056.      Windows driver will tell the Presentation Manager driver to attempt access 
  8057.      again. 
  8058.  
  8059. This algorithm is relatively simple but not totally fail-safe.  It is quite 
  8060. possible to create a serialization mechanism that would safeguard the Workplace 
  8061. Shell desktop to a greater degree.  However, when one considers the remoteness 
  8062. of the possibility of its failure (which requires a bogus PID or TID), the 
  8063. costs, in terms of a performance impact, would far outweigh the benefits 
  8064. incurred. 
  8065.  
  8066. Some important points about "seamless" WIN-OS/2 VDMs: 
  8067.  
  8068.  Note that the use of a MAVDM or a common "seamless" WIN-OS/2 VDM  is a 
  8069.   requirement where Windows applications must communicate with one another via 
  8070.   shared memory. 
  8071.  
  8072.  Only standard mode is supported in this mode of operation. 
  8073.  
  8074.  Presentation Manager must provide extensive support for this implementation 
  8075.   of WIN-OS/2.  Basically, Presentation Manager supports a "black hole" and 
  8076.   allows the WIN-OS/2 kernel to control it.  A modified WIN-OS/2 and 
  8077.   Presentation Manager display device driver is built into OS/2 Version 2.0 to 
  8078.   support this mechanism. 
  8079.  
  8080.  The "seamless" WIN-OS/2 VDM is only supported if OS/2 is configured for VGA 
  8081.   mode, because only the Windows VGA display device driver is supported.  This 
  8082.   means that, on an 8514 or XGA equipped system, the Presentation Manager 
  8083.   display device driver must be configured in VGA mode to be able to run 
  8084.   Windows applications in a "seamless" WIN-OS/2 VDM.  If the user selects a 
  8085.   higher resolution display device driver such as XGA, Windows applications may 
  8086.   only run in a SAVDM or MAVDM environment. 
  8087.  
  8088.   Notes: 
  8089.  
  8090.     1. Over time, more display device drivers will be enhanced to support this 
  8091.        seamless mode of WIN-OS/2.  Once available, installed and configured 
  8092.        appropriately, WIN-OS/2 will provide seamless execution on other 
  8093.        supported graphics modes. 
  8094.  
  8095.     2. Readers should check the ReadMe file in the Information folder for the 
  8096.        latest information on this subject.  Information in this folder explains 
  8097.        how to reconfigure the system to have seamless WIN-OS/2 support as well 
  8098.        as high resolution MAVDM and/or SAVDM sessions. 
  8099.  
  8100.  A VDD (VWIN.SYS) provides the necessary services to the Windows kernel and 
  8101.   Presentation Manager. 
  8102.  
  8103. As shown in Figure "Implementation of "Seamless" WIN-OS/2 VDM in OS/2 Version 
  8104. 2.0" PMVIOP.DLL contains a PMShield routine which is responsible for 
  8105. maintaining the entire Workplace Shell desktop, including the "black holes" 
  8106. which correspond to and are maintained by each "seamless" WIN-OS/2 VDM. 
  8107.  
  8108. WinShield is the Windows VDM's counterpart of PMShield.  The Workplace Shell 
  8109. desktop windowing state must be maintained in its entirety by this component. 
  8110. WinShield registers a service routine with VWIN.SYS, giving it the ability to 
  8111. post a message to PMShield whenever the Workplace Shell desktop state changes. 
  8112.  
  8113. Upon creation of the first "seamless" WIN-OS/2 VDM, PMShield spawns three 
  8114. dedicated threads under the Workplace Shell to specifically service its 
  8115. "seamless" WIN-OS/2 VDM clients: 
  8116.  
  8117.  Thread 1 is the IPC Read Thread, which normally suspends itself within 
  8118.   VWIN.SYS, waiting for window-related events to occur in the "seamless" 
  8119.   WIN-OS/2 VDM. The typical events sent by the WinShield are Create, Move, 
  8120.   Size, Show Activate, etc. These events are duplicated by PMShield on the 
  8121.   Workplace Shell desktop for the purpose of tracking the "black hole" windows. 
  8122.  
  8123.  Thread 2 is the Control Windows Procedure Thread that the PMShield registers 
  8124.   with PMWIN.DLL.  This thread handles all relevant events that alter the state 
  8125.   of the Workplace Shell desktop.  Once in control, this thread will broadcast 
  8126.   all Workplace Shell desktop initiated events asynchronously to all VDMs by 
  8127.   calling VWIN.SYS.  This causes a previously registered WinShield routine to 
  8128.   be dispatched, giving it an opportunity to post an asynchronous message to 
  8129.   itself. 
  8130.  
  8131.  Thread 3 is the Error Handling Thread. All non-fatal errors on all "seamless" 
  8132.   WIN-OS/2 VDM related operations will be reported through this mechanism where 
  8133.   a Presentation Manager dialog box will pop up explaining to the user what 
  8134.   went wrong. 
  8135.  
  8136. On successful creation of a "seamless" WIN-OS/2 VDM, the Presentation Manager 
  8137. Session Start thread will notify VVGA.SYS to allow the started VDM to access 
  8138. the video hardware directly. 
  8139.  
  8140. Common "Seamless" WIN-OS/2 VDM 
  8141.  
  8142. There is no visible difference between Windows applications running in a 
  8143. "seamless" WIN-OS/2 VDM and those running in a common "seamless" WIN-OS/2 VDM. 
  8144. The technical differences between them are described in the following 
  8145. paragraphs. Everything else discussed in the above section ."Seamless" WIN-OS/2 
  8146. VDM is common to both. 
  8147.  
  8148. To reduce the system resource usage in a low memory environment, users are 
  8149. given the option to start all "Seamless" WIN-OS/2 applications in the same VDM. 
  8150. This also helps to reduce startup time for Windows applications, and reduces 
  8151. the swap file space required.  By default, Windows applications migrated from a 
  8152. DOS/Windows system at OS/2 installation time are migrated to a common 
  8153. "seamless" WIN-OS/2 VDM.  The user has the option of prestarting one or more 
  8154. Windows applications in the common "seamless" WIN-OS/2 VDM by using the Startup 
  8155. folder in the Workplace Shell. 
  8156.  
  8157. There is only one common "seamless" WIN-OS/2 VDM in the system.  If the system 
  8158. is not currently configured to run "seamless" WIN-OS/2 VDMs, any Windows 
  8159. application which is defined for common "seamless" WIN-OS/2 VDM will be loaded 
  8160. and run in a fullscreen SAVDM. 
  8161.  
  8162. By default, only the first Windows program launched from the Workplace Shell as 
  8163. a "seamless" WIN-OS/2 VDM will create a new VDM.  Any subsequent Windows 
  8164. programs will share this environment, in exactly the same way as in a MAVDM 
  8165. full-screen session.  This is known as the common "seamless" WIN-OS/2 
  8166. environment. 
  8167.  
  8168. However, the user may wish to protect these Windows programs from each other, 
  8169. and to maximize the timeslicing efficiency of Windows applications. This can be 
  8170. done by checking the Separate session option on the Session page of the 
  8171. Settings notebook for any Windows program object under the Workplace Shell. 
  8172. That procedure would activate a "normal" "seamless" WIN-OS/2 VDM session. 
  8173.  
  8174. The Workplace Shell Window List will contain an entry for the common "seamless" 
  8175. WIN-OS/2 VDM itself, in addition to an entry for each Windows program running 
  8176. in this VDM  This provides also a mechanism for terminating this VDM from the 
  8177. Workplace Shell desktop, along with all the active Windows applications in it. 
  8178. As the user has a visual representation of the "contents" of the common 
  8179. "seamless" WIN-OS/2 VDM, the user knows which applications will be terminated 
  8180. if the Close option is chosen.  If the common "seamless" WIN-OS/2 VDM hangs 
  8181. because one of the Windows programs is not behaving properly, the Close option 
  8182. on the entry for the common "seamless" WIN-OS/2 VDM will close down the entire 
  8183. VDM, including all Windows programs running in it.  This behavior is similar to 
  8184. that of a MAVDM. 
  8185.  
  8186. In the MAVDM and the common "seamless" WIN-OS/2 VDM environment, all those 
  8187. Windows applications are still subject to the cooperative multitasking under 
  8188. Windows itself.  Since several Windows applications are loaded in the same VDM, 
  8189. the common "seamless" WIN-OS/2 VDM shares the same pitfalls as does the MAVDM. 
  8190. If one Windows application crashes within a common "seamless" WIN-OS/2 VDM, it 
  8191. may cause all the applications within that VDM to fail.  However, as in a 
  8192. MAVDM, the effect is only within that VDM; other VDMs running DOS or Windows 
  8193. applications, and other processes executing under OS/2 Version 2.0, are not 
  8194. affected and continue execution.  So even here there are additional benefits 
  8195. running Windows applications seamlessly under OS/2.  Furthermore, as for the 
  8196. MAVDM environment, enhancements are made to provide additional error checking 
  8197. and handling for the common "seamless" WIN-OS/2 VDM. 
  8198.  
  8199. A number of restrictions apply to the use of a common "seamless" WIN-OS/2 VDM. 
  8200. These are as follows: 
  8201.  
  8202.  The DOS settings which will be in effect for the common "seamless" WIN-OS/2 
  8203.   VDM will be those which are defined by the first Windows program to start in 
  8204.   this VDM. Changes to the settings for any subsequent Windows program in that 
  8205.   VDM will not affect the actual settings of the common "seamless" WIN-OS/2 
  8206.   VDM. To make this obvious to the user, the WIN-OS/2 Settings button on the 
  8207.   Session page of the Settings notebook is grayed for all Windows applications 
  8208.   running in the common "seamless" WIN-OS/2 VDM once it is active.  This 
  8209.   implies that WIN-OS/2 settings cannot be viewed or changed once this VDM is 
  8210.   started. 
  8211.  
  8212.  The DPMI limit for the common "seamless" WIN-OS/2 VDM is higher than when 
  8213.   defined for "seamless" WIN-OS/2 VDM, since multiple applications are likely 
  8214.   to require more DPMI memory. 
  8215.  
  8216.  Each Windows program running in the common "seamless" WIN-OS/2 VDM will have 
  8217.   the same HAPP application handle), PID (process ID), and SGID (screen group 
  8218.   ID). Any action taken on one of these values will cause that action against 
  8219.   the entire VDM and not against only a specific instance inside the common 
  8220.   "seamless" WIN-OS/2 VDM. For example, if a WinTerminateApp() call is issued, 
  8221.   which uses the HAPP as input, then all applications running within the common 
  8222.   "seamless" WIN-OS/2 VDM will be terminated.  The user will be warned by a 
  8223.   dialog that multiple Windows applications will be ended. 
  8224.  
  8225.  
  8226. ΓòÉΓòÉΓòÉ 18.3. Installing WIN-OS/2 Support Under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  8227.  
  8228. Windows application support is provided by default during the installation of 
  8229. OS/2 Version 2.0.  If the user wishes not to install Windows support, the 
  8230. appropriate option must be chosen during OS/2 installation. 
  8231.  
  8232. The OS/2 installation program detects the video resolution of the machine on 
  8233. which it is being installed.  If Windows support is selected during "first 
  8234. time" installation, then the following configurations will be applied according 
  8235. to the detected video resolution: 
  8236.  
  8237. CGA, EGA         Configured for full-screen (only) Windows support. 
  8238.  
  8239. VGA              Configured for "seamless" WIN-OS/2 VDM support. 
  8240.  
  8241. 8514/A, XGA      During installation, a panel with the option to select 
  8242.                  seamless support (and downgrade to VGA graphics mode) is 
  8243.                  provided (see Figure "Installing Windows Support under OS/2 
  8244.                  Version 2.0").  If full-screen (only) Windows support is 
  8245.                  selected, then the higher resolution is maintained. 
  8246.  
  8247. Note:   Readers should check the ReadMe file in the Information folder for the 
  8248.         latest information on this subject.  This folder contains information 
  8249.         on how to reconfigure the system to have seamless WIN-OS/2 support as 
  8250.         well as high resolution MAVDM and/or SAVDM sessions.  Additional 
  8251.         support information for SVGA display device drivers will be provided as 
  8252.         well.  OS/2 Version 2.0 - Volume 1:  Control Program also discusses 
  8253.         several installation and configuration aspects of OS/2 V2.0. 
  8254.  
  8255. When Windows support is selected at installation time, all the files necessary 
  8256. to provide this support are installed in the following subdirectories: 
  8257.  
  8258.  \OS2\MDOS\WINOS2 
  8259.  
  8260.  \OS2\MDOS\WINOS2\SYSTEM 
  8261.  
  8262. If the user decides to install Windows application support, DOS application 
  8263. support is automatically installed.  OS/2 Version 2.0's CONFIG.SYS file is 
  8264. updated to include the above directories in the PATH statement. 
  8265.  
  8266. Since Windows real mode requires 640KB of conventional memory and several MB of 
  8267. expanded memory (EMS), the EMS virtual device driver is also required.  If the 
  8268. user did not select standard mode at installation time and wishes to add it at 
  8269. later time, the OS/2 Version 2.0 CONFIG.SYS must be modified by adding the 
  8270. following statements: 
  8271.  
  8272.  DEVICE=C:\OS2\MDOS\VDPMI.SYS (DOS Protect Mode Interface) 
  8273.  
  8274.  DEVICE=C:\OS2\MDOS\VDPX.SYS (DOS Extender Virtual Device Driver). 
  8275.  
  8276. If these device drivers are not loaded, the Windows kernel will execute in real 
  8277. mode. 
  8278.  
  8279. Windows can use expanded memory which conforms to the LIM EMS 4.0 specification 
  8280. when running in real mode. This memory is primarily used for storing background 
  8281. applications.  In a DOS/Windows environment, an appropriate Expanded Memory 
  8282. Manager must be installed.  Under OS/2 V2.0 this is not necessary, as the 
  8283. virtual device driver already provides that service. In standard mode, Windows 
  8284. may also use extended memory (XMS). 
  8285.  
  8286.  
  8287. ΓòÉΓòÉΓòÉ 18.4. Migrating to OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  8288.  
  8289. Upon completion of the installation process, the user is given the opportunity 
  8290. to migrate installed Windows applications (defined to the Windows Program 
  8291. Manager) to the OS/2 Version 2.0 Workplace Shell.  All Windows applications 
  8292. which are to be migrated must have the appropriate DOS and Windows settings 
  8293. defined in the Certified Application Database (CAD), which is shipped as a 
  8294. standard component of OS/2 Version 2.0.  See also Installing and Migrating 
  8295. Applications. 
  8296.  
  8297. Note:   Only the settings for those applications which have been certified via 
  8298.         approved IBM testing channels will be held in the Certified 
  8299.         Applications Database (CAD), and only those settings which differ from 
  8300.         the default settings will be recorded. 
  8301.  
  8302. If a referenced Windows application is found on any of the available disk 
  8303. volumes during OS/2 installation, the existing *.INI and *.GRP files will be 
  8304. read, the necessary changes applied to them, and the updated versions stored in 
  8305. the \OS2\MDOS\WINOS2 directory.  This will effectively migrate the user's 
  8306. Windows desktop, including all Windows applications, into a MAVDM, SAVDM or 
  8307. seamless environment. 
  8308.  
  8309. The CAD provides information enabling the installation procedure to 
  8310. automatically set the DOS settings for certified DOS and Windows applications. 
  8311. The user is presented with a list of the certified applications found, which 
  8312. can then be migrated. The user may select any or all of these applications. 
  8313. The CAD is searched for each of the selected applications, and DOS and/or 
  8314. Windows settings information found in the database will be used to 
  8315. automatically assign settings to applications.  Windows applications will be 
  8316. placed in a single "Windows Applications" folder.  DOS applications are placed 
  8317. in a single "DOS Applications" folder. 
  8318.  
  8319. The CAD is a binary database, generated from an ASCII database and a predefined 
  8320. tag file. Each field in the ASCII database starts with a descriptive tag that 
  8321. is associated with a value between 0-225 in the predefined tag file; the 
  8322. maximum number of tags is therefore 256.  When the binary CAD generation tool 
  8323. encounters one of the descriptive tags, it generates an entry in the binary CAD 
  8324. with a 0-255 value specified in the predefined tag file.  To add new or 
  8325. additional DOS properties, a short descriptive tag is created for the ASCII 
  8326. file and associated with an unused value between 0-255 in the predefined tag 
  8327. file. A length specification is also provided for the value in the tag file. 
  8328.  
  8329. Each field in the binary CAD starts with a predefined tag value of 0-255 that 
  8330. identifies the field. This tag is followed by a size field, which in turn is 
  8331. followed by the actual value of the field. 
  8332.  
  8333. Each application in the CAD has the following minimum information: 
  8334.  
  8335.  The filename used to start the application 
  8336.  
  8337.  The title of the application 
  8338.  
  8339.  A pointer to the next application. 
  8340.  
  8341. The filename that starts the application is used to identify the application on 
  8342. the hard drive. The next application pointer points directly to the next 
  8343. application entry in the CAD. This provides the ability to jump from one entry 
  8344. to the next without parsing all of the tags between entries in the CAD. The 
  8345. application title is displayed to the user if the application is found on the 
  8346. hard drive. The user will use this information to specify if the application is 
  8347. to be migrated. 
  8348.  
  8349. The filename extensions held in the CAD will determine what files are searched 
  8350. for; that is all EXE, COM and BAT files. 
  8351.  
  8352. When the applications have been migrated into the OS/2 Version 2.0 Workplace 
  8353. Shell, information for DOS applications is stored in the OS2.INI file.  Windows 
  8354. settings for Windows applications are stored in the WIN.INI file, while their 
  8355. DOS-related settings are stored in the OS2.INI file. 
  8356.  
  8357.  
  8358. ΓòÉΓòÉΓòÉ 18.5. Defining Windows Applications ΓòÉΓòÉΓòÉ
  8359.  
  8360. As mentioned in the previous section, Windows applications may be automatically 
  8361. migrated to the Workplace Shell desktop at OS/2 installation time. However, for 
  8362. applications which are not defined in the Certified Application Database, or 
  8363. which are installed after OS/2 installation, a Workplace Shell object may be 
  8364. created from a template in the Templates folder.  For such applications, the 
  8365. WIN-OS/2 application execution environment is defined to the Workplace Shell 
  8366. using the Program page of the program object's Settings notebook. 
  8367.  
  8368. Figure "Defining a Windows Application to OS/2 Version 2.0" 
  8369.  
  8370. The Session page allows the user to change Windows settings via the Windows 
  8371. Settings dialog. This page defines whether the Windows kernel will execute in 
  8372. real, standard, or Auto-Select mode. Auto-Select mode is highlighted as the 
  8373. default.  All DOS settings are selectable for Windows applications via the 
  8374. Windows Setting dialog;  Windows settings are included in the same list. 
  8375.  
  8376.  
  8377. ΓòÉΓòÉΓòÉ 18.5.1. Defining a Single Application VDM (SAVDM) ΓòÉΓòÉΓòÉ
  8378.  
  8379. For a SAVDM, the Windows application name is entered into the Path and Filename 
  8380. field on the Program page of the Settings notebook. The Workplace Shell then 
  8381. determines the application type. Upon detecting that the application is a 
  8382. Windows application, the Program Type in the Session page of the notebook will 
  8383. be set to Windows Full Screen. When a user interactively creates a program 
  8384. object for a Windows  application  and the Workplace Shell determines it is a 
  8385. real mode application, Windows Full Screen will be marked as the default and 
  8386. the application will be started as a SAVDM. 
  8387.  
  8388. Each SAVDM has its own icon on the Workplace Shell desktop, for the application 
  8389. within the SAVDM.  This icon is the normal Windows icon for this application. 
  8390. The icon title text will be the text specified in the Title field in the 
  8391. General page of the Settings notebook. 
  8392.  
  8393.  
  8394. ΓòÉΓòÉΓòÉ 18.5.2. Defining a Multiple Application VDM (MAVDM) ΓòÉΓòÉΓòÉ
  8395.  
  8396. When defining a MAVDM, the user specifies WINOS2.COM for the Path and Filename 
  8397. field in the Program page of the Settings notebook.  As explained above, the 
  8398. Workplace Shell detects that the application is a Windows application and sets 
  8399. the Program Type field in the Session page to Windows Full Screen. 
  8400.  
  8401. The user may also define one or more Windows applications which will be 
  8402. activated when the VDM is started. This is achieved as follows: 
  8403.  
  8404.  1. The applications to be started are specified in the Parameters field of the 
  8405.     Program dialog.  Full path name and parameters should be specified. 
  8406.  
  8407.     The syntax for the parameters field is: 
  8408.  
  8409.             /R|/S [{][!|^]App1 App-parms [,] [!|^]App2 App-parms
  8410.  
  8411.     /R Windows real mode 
  8412.  
  8413.     /S Windows standard mode These parameter are active for the whole VDM and 
  8414.     not on an application base. 
  8415.  
  8416.     [ ] Optional Parameters 
  8417.  
  8418.     ! Start the Windows Application Minimized 
  8419.  
  8420.     ^ Start the Windows Application Maximized. No blank must be specified 
  8421.     between '!' or '^' and the application name. 
  8422.  
  8423.     A MAVDM will be created if one of the following are present: 
  8424.  
  8425.     {} Braces 
  8426.  
  8427.     Comma separating the application names 
  8428.  
  8429.     An application name is not passed as a parameter. 
  8430.  
  8431.     If neither the exclamation mark nor the caret is specified, the Windows 
  8432.     application will start "normalized", approximately one third of the screen 
  8433.     size. 
  8434.  
  8435.     Changes are effective immediately and are saved when the Settings notebook 
  8436.     is closed or when the system is shut down.  The Default button resets all 
  8437.     settings to their previous values. 
  8438.  
  8439.  2. In the Session dialog WIN-OS/2 full screen must be selected. 
  8440.  
  8441. The icon will be the Windows full-screen icon defined by WINOS2.COM. 
  8442. Individual icons for applications running in the MAVDM are not displayed on the 
  8443. Workplace Shell desktop. 
  8444.  
  8445.  
  8446. ΓòÉΓòÉΓòÉ 18.5.3. Defining a "Seamless" WIN-OS/2 VDM ΓòÉΓòÉΓòÉ
  8447.  
  8448. In order to obtain the highest integration of the Windows V3.0 and Windows V2.x 
  8449. application into the OS/2 V2.0 Workplace Shell, the following definitions must 
  8450. be provided in order to have the application execute in seamless mode: 
  8451.  
  8452.  1. Select the Program page of the program object's Settings notebook. 
  8453.  
  8454.  2. Enter the Windows application name in the Path and Filename field. A fully 
  8455.     qualified path and filename is necessary. 
  8456.  
  8457.  3. Select the Session page of the program reference object's Settings 
  8458.     notebook. 
  8459.  
  8460.  4. Click on the WIN-OS/2 window radio button. 
  8461.  
  8462.  5. All DOS settings are selectable for Windows applications via the Windows 
  8463.     Settings page dialog; Windows settings are included in the same list. 
  8464.  
  8465. The "WIN-OS/2 Window" radio button indicates that the associated Windows 
  8466. application program is to be initiated in a "seamless" Windows VDM.  This is a 
  8467. single application VDM.  However, the WIN-OS/2 Program Manager may be 
  8468. registered with the Workplace Shell as a "seamless" WIN-OS/2 program object. 
  8469. Once the Program Manager is up and running, the user may launch any other 
  8470. Windows program from it.  Of course, this assumes that other Windows programs 
  8471. were installed through the Program Manager, and that they all run in the same 
  8472. WIN-OS/2 session. 
  8473.  
  8474. A new parameter is added to the SYSTEM.INI file: 
  8475.  
  8476.               WOS2VDMApps=!clipwos2,!ddeagent
  8477.  
  8478. The WIN-OS/2 Program Manager reads this line for "seamless" WIN-OS/2 VDM, to 
  8479. determine which applications to pre-start. 
  8480.  
  8481. Since "WIN-OS/2 Window" is the default Windows application setting, all Windows 
  8482. program objects that are created through the Windows Migration utility (for 
  8483. standard mode Windows applications) will default to that setting. If a user 
  8484. chooses to execute a Windows application by double clicking its program file's 
  8485. icon in the Drives folder, rather than its program object icon (if any), then 
  8486. the Workplace Shell will attempt to initiate it in a "seamless" Windows 
  8487. environment. 
  8488.  
  8489.  
  8490. ΓòÉΓòÉΓòÉ 18.6. Starting Windows Applications ΓòÉΓòÉΓòÉ
  8491.  
  8492. The following methods may be used to start Windows applications: 
  8493.  
  8494.  1. Select the application's program file from within the Drives folder. This 
  8495.     method is not recommended, as it will not pick up any optimized DOS and/or 
  8496.     Windows settings. 
  8497.  
  8498.  2. Enter the application name at an OS/2 command line prompt.  This method is 
  8499.     not recommended, for the same reason as stated above. 
  8500.  
  8501.  3. Install the application in a folder, in the Workplace Shell desktop as 
  8502.     described in Defining Windows Applications, and start it by double-clicking 
  8503.     the mouse on its icon.  This is the preferred method for starting a Windows 
  8504.     application. 
  8505.  
  8506. If the application is started from either the Drives Folder or an OS/2 command 
  8507. prompt, a SAVDM will be created. If the application is started from an icon, 
  8508. either a SAVDM, a MAVDM or a "seamless" WIN-OS/2 VDM will be created, depending 
  8509. on how the application was defined at installation. 
  8510.  
  8511.  
  8512. ΓòÉΓòÉΓòÉ 18.6.1. SAVDM ΓòÉΓòÉΓòÉ
  8513.  
  8514. A SAVDM is created for the execution of a single Windows application.  The 
  8515. Workplace Shell actually starts WINOS2.COM as the application in the VDM, and 
  8516. the application to be started in the VDM is passed as a parameter to WINOS2. 
  8517. This process is transparent to the user; the definition of the SAVDM in the 
  8518. Settings notebook uses the Windows application name only. 
  8519.  
  8520. If WINOS2 is to execute in real mode, the /r option will be automatically 
  8521. inserted into the parameter list for the VDM creation, based on the WIN-OS/2 
  8522. settings.  If standard mode was highlighted, /s is passed as a parameter to 
  8523. WINOS2.  The default is to pass no Windows options, only the application name. 
  8524.  
  8525. When the Windows application is terminated, WINOS2.COM terminates, which in 
  8526. turn causes the VDM to be terminated. 
  8527.  
  8528.  
  8529. ΓòÉΓòÉΓòÉ 18.6.2. MAVDM ΓòÉΓòÉΓòÉ
  8530.  
  8531. In the case of a MAVDM, the Windows Program Manager is loaded in the VDM, 
  8532. transparently to the user.  The Program Manager's window is displayed 
  8533. maximized, and applications are then launched from the Windows Program Manager. 
  8534. In this case, the Workplace Shell's Window List will display the name of the 
  8535. Windows kernel (WINOS2.COM) executing in the VDM.  It will not show each 
  8536. individual Windows application running within that MAVDM.  This is different 
  8537. from a SAVDM, where the Workplace Shell's Window List will display the name of 
  8538. the Windows application. 
  8539.  
  8540.  
  8541. ΓòÉΓòÉΓòÉ 18.6.3. "Seamless" WIN-OS/2 VDM ΓòÉΓòÉΓòÉ
  8542.  
  8543. OS/2 Version 2.0 does not allow a "seamless" WIN-OS/2 VDM to be started from a 
  8544. DOS or OS/2 command prompt, nor is there any programmed interface for starting 
  8545. a "seamless" WIN-OS/2 VDM application from a Presentation Manager application. 
  8546. In addition, a SAVDM or MAVDM cannot be switched to a "seamless" WIN-OS/2 VDM 
  8547. once the virtual DOS machine is running. 
  8548.  
  8549. The "seamless" WIN-OS/2 VDM execution mode allows Windows applications to run 
  8550. from the Workplace Shell desktop in a manner that is virtually 
  8551. indistinguishable from other OS/2 and DOS applications.  Double clicking a 
  8552. "seamless" WIN-OS/2 VDM application icon will cause that application to be run 
  8553. in a window on the Workplace Shell desktop. This single application "seamless" 
  8554. WIN-OS/2 VDM environment will be a separate Windows VDM, where the Program 
  8555. Manager is not visible. 
  8556.  
  8557. In order to be perceived as a compatible part of the Workplace Shell 
  8558. environment, the "seamless" WIN-OS/2 VDM application's execution must be 
  8559. controllable in the same manner as the execution of other OS/2 and DOS 
  8560. applications. This has several implications: 
  8561.  
  8562.  The name of each active "seamless" WIN-OS/2 VDM application will be included 
  8563.   in the Workplace Shell Task List. 
  8564.  
  8565.  Each "seamless" WIN-OS/2 VDM supports an appropriate context menu. 
  8566.  
  8567.  The user is able to cycle through all open Workplace Shell windows in the 
  8568.   standard Alt-Esc manner. 
  8569.  
  8570.  The minimize/hide icons on Windows applications function consistently with 
  8571.   other such icons on the Workplace Shell desktop. 
  8572.  
  8573.  The window controls on a "seamless" WIN-OS/2 VDM window operate in the same 
  8574.   fashion as analogous Workplace Shell controls. The display style of the 
  8575.   window controls on a "seamless" WIN-OS/2 VDM window will be "Windows-style" 
  8576.   however. 
  8577.  
  8578.  When a "seamless" WIN-OS/2 VDM Windows application terminates, its Workplace 
  8579.   Shell window is also terminated. 
  8580.  
  8581. This approach allows the appearance of a Windows application executing in a 
  8582. "seamless" WIN-OS/2 VDM to conform as closely as possible to that seen when 
  8583. running in a native DOS/Windows environment, while its behavior is as close as 
  8584. possible to that of a normal Presentation Manager/Workplace Shell application. 
  8585.  
  8586. If You can't get a "Seamless" WIN-OS/2 VDM to Work 
  8587.  
  8588. Starting a Windows application requires a number of configuration options to be 
  8589. correctly completed prior to starting the application.  Failure to do so may 
  8590. result in the application failing to start.  This is typically due to one of 
  8591. three problems: 
  8592.  
  8593.  1. Failures that are due to the configuration of the overall OS/2 V2.0 system. 
  8594.  
  8595.  2. Failures that are due to the configuration of the overall Windows 
  8596.     environment. 
  8597.  
  8598.  3. Failures that are due to the nature of a particular Windows  application. 
  8599.  
  8600. The first two classes result from not being "seamless capable"; that is, some 
  8601. part of the system's configuration is not set up properly for "seamless" 
  8602. WIN-OS/2 VDM operation.  For example: 
  8603.  
  8604.  An OS/2 V2.0 video device driver other than the "seamless" VGA driver is 
  8605.   installed. 
  8606.  
  8607.  VWIN.SYS is not installed, due to the following line being missing in 
  8608.   CONFIG.SYS: 
  8609.  
  8610.                   DEVICE=C:\OS2\MDOS\VWIN.SYS
  8611.  
  8612.  The Windows video device driver referenced by the SDISPLAY.DRV= statement in 
  8613.   SYSTEM.INI file does not point to the "seamless" Windows VGA device driver. 
  8614.   The correct entry in the SYSTEM.INI is: 
  8615.  
  8616.                   SDISPLAY=SWINVGA.DRV
  8617.  
  8618. The third class arises because the "seamless" execution environment will be a 
  8619. SAVDM that runs in standard mode only.  This means that real mode Windows 
  8620. applications will not be able to run in "seamless" WIN-OS/2 VDM ("seamless" 
  8621. VDMs).  The Workplace Shell is able to gracefully handle the initiation of real 
  8622. mode Windows applications, because it can determine the mode of a Windows 
  8623. application from its program header.  Such Windows applications will be 
  8624. automatically initiated in full-screen SAVDMs. 
  8625.  
  8626. In addition, groups of applications which depend on the sharing of global 
  8627. Windows memory will not be able to run in a "seamless" WIN-OS/2 VDM, unless it 
  8628. is possible to manually initiate one application in the set and then have that 
  8629. application programmatically spawn the rest of the applications in the set. In 
  8630. theory, this situation should never occur because the casual sharing of Windows 
  8631. global memory is expressly against the Microsoft guidelines for Windows system 
  8632. programming.  However, if there are applications that depend on such sharing, 
  8633. the user will have to explicitly know to run them in a full-screen MAVDM. 
  8634.  
  8635.  
  8636. ΓòÉΓòÉΓòÉ 18.7. Windows Environment Settings ΓòÉΓòÉΓòÉ
  8637.  
  8638. When Windows application support is selected during installation of OS/2 
  8639. Version 2.0, a WIN.INI file is built.  The options for devices selected for the 
  8640. OS/2 environment are included in this file. 
  8641.  
  8642. Should the user migrate from a DOS/Windows 3.0 environment, the original 
  8643. WIN.INI created by Windows will be left unchanged.  At installation time, the 
  8644. Windows installation process will examine the original AUTOEXEC.BAT file and 
  8645. search in all directories specified in the PATH statement in there for the 
  8646. original Windows WIN.COM file.  If one exists, it will copy all Windows *.INI 
  8647. files and all the Windows application *.INI files from that same subdirectory 
  8648. into the \OS\MDOS\WINOS2 subdirectory.  It will then modify these copies to 
  8649. adjust for the appropriate video, mouse, country and keyboard settings.  This 
  8650. happens in accordance with the answers provided during the initial OS/2 setup. 
  8651.  
  8652. Figure "Migrating the Windows Initialization Files" 
  8653.  
  8654. The Windows group files (*.GRP) and other Windows application-specific *.INI 
  8655. files are also copied.  The modified WIN.INI and PROGMAN.INI files will have 
  8656. their path statements modified to point to the new locations of these files. 
  8657.  
  8658. Printer definitions for the Windows environment will also depend on the OS/2 
  8659. setup, rather than on any previously defined printer device driver.  Of course, 
  8660. all path statements in these files will be modified to point to the appropriate 
  8661. directories. 
  8662.  
  8663. If a user installs OS/2 V2.0 over a previous version of OS/2 V2.0, the Windows 
  8664. install process will look for the existence of \OS2\MDOS\WINOS2\WINOS2.COM. If 
  8665. found, it will perform the same migration process from that base environment. 
  8666. If none of these files can be found, the Windows installation process will 
  8667. start from scratch, in the same way that a first-time Windows 3.0 installation 
  8668. would do it. 
  8669.  
  8670. The following initialization files are created/modified: 
  8671.  
  8672.  WIN.INI 
  8673.  
  8674.  PROGMAN.INI 
  8675.  
  8676.  CONTROL.INI 
  8677.  
  8678.  SYSTEM.INI. 
  8679.  
  8680. The initialization and group files are required to restore a corrupted Windows 
  8681. environment. Backups of these files should be taken prior to making any changes 
  8682. to this environment. 
  8683.  
  8684. These files and their contents are described in the following sections. 
  8685.  
  8686.  
  8687. ΓòÉΓòÉΓòÉ 18.7.1. WIN.INI ΓòÉΓòÉΓòÉ
  8688.  
  8689. WIN.INI contains a number of sections which may be customized by the user, 
  8690. including which applications should be started or run when a Windows MAVDM is 
  8691. started. Each Windows application is recorded in a separate section indicating 
  8692. the drive and path to execute the application. The supported file extensions, 
  8693. for each application installed, are recorded in the Extensions section. 
  8694.  
  8695. Users need to be careful when applying any changes to this file, especially 
  8696. when it comes to configuring of any device drivers.  The user might install a 
  8697. device driver which either does not exist or is not supported under OS/2 V2.0, 
  8698. such as specialized video device drivers. 
  8699.  
  8700. Most, but not all, Windows applications also have their private entries in the 
  8701. WIN.INI file.  Usually, such entries consist merely of a pointer to the 
  8702. application's own working directory.  However, some applications register all 
  8703. their installation-dependent configuration information, and may therefore be 
  8704. very dependent upon finding their data in this file.  The migration process 
  8705. will take care of these entries and migrate them appropriately. 
  8706.  
  8707.  
  8708. ΓòÉΓòÉΓòÉ 18.7.2. PROGMAN.INI ΓòÉΓòÉΓòÉ
  8709.  
  8710. PROGMAN.INI contains the Windows Program Manager settings.  This file contains 
  8711. the following sections: 
  8712.  
  8713.  Setting: Describes the settings of the Program Manager, along with the user's 
  8714.   preferences. 
  8715.  
  8716.  Groups: Specifies the Program Groups that exist in Program Manager and the 
  8717.   path name to their group files (*.GRP). 
  8718.  
  8719.  
  8720. ΓòÉΓòÉΓòÉ 18.7.3. CONTROL.INI ΓòÉΓòÉΓòÉ
  8721.  
  8722. CONTROL.INI contains the color and desktop settings for the Windows Control 
  8723. Panel.  The following options are available: 
  8724.  
  8725.  Current: Specifies the window color setting 
  8726.  
  8727.  Color Schemes: Specifies the available color options 
  8728.  
  8729.  Custom Colors: Specifies up to 16 customization colors 
  8730.  
  8731.  Patterns: Specifies options for the desktop pattern. 
  8732.  
  8733.  
  8734. ΓòÉΓòÉΓòÉ 18.7.4. SYSTEM.INI ΓòÉΓòÉΓòÉ
  8735.  
  8736. SYSTEM.INI contains the global system information used by Windows when it 
  8737. starts. Changes are not effective until Windows is restarted. 
  8738.  
  8739. The following sections are included: 
  8740.  
  8741.  Boot: Lists the drivers and Windows modules. The OS/2 file contains new Boot 
  8742.   section keywords which cover MAVDM and SAVDM default applications: 
  8743.  
  8744.    GOPM      This program returns the user to the Workplace Shell 
  8745.  
  8746.    Clipboard The modified WIN-OS/2 Clipboard View program 
  8747.  
  8748.    DDEAGENT  The WIN-OS/2 DDE (Dynamic Data Exchange) program 
  8749.  
  8750.    Printman  The modified WIN-OS/2 Print Manager program, in MAVDM only. 
  8751.  
  8752.  Boot.description: Lists the names of devices the user can change using 
  8753.   Windows Setup 
  8754.  
  8755.  Keyboard: Contains information about the keyboard 
  8756.  
  8757.  NonWindowsApp: This section should not contain any information, since 
  8758.   non-Windows applications are started from the OS/2 desktop. In the case of a 
  8759.   migrated Windows environment, this section might contain information, but 
  8760.   under OS/2 V2.0 it will be ignored. 
  8761.  
  8762.  Standard: Contains information required by Windows to run in standard mode 
  8763.  
  8764.  386Enh: Contains information used by Windows to operate in 386 enhanced mode. 
  8765.   This section is not used as OS/2 provides equivalent function. 
  8766.  
  8767.  
  8768. ΓòÉΓòÉΓòÉ 18.7.5. DOS and WIN-OS/2 Settings ΓòÉΓòÉΓòÉ
  8769.  
  8770. The following DOS settings are automatically defined for any Windows 
  8771. application under the Workplace Shell. If a user explicitly modifies these 
  8772. entries, following these settings is recommended: 
  8773.  
  8774. WIN_RUNMODE                        AUTO 
  8775.  
  8776.                                    OS/2 V2.0 will decide whether the Windows 
  8777.                                    application will run in real or standard 
  8778.                                    mode, unless the user specifically selects a 
  8779.                                    mode. 
  8780.  
  8781. KBD_CTRL_BYPAS                     CTRL_ESC 
  8782.  
  8783.                                    This keyboard sequence is required in a 
  8784.                                    WIN-OS/2 MAVDM in order to bring up the 
  8785.                                    Windows List.  If not bypassed, the Ctrl+Esc 
  8786.                                    sequence is trapped by the Workplace Shell. 
  8787.  
  8788. MOUSE_EXCLUSIVE_ACCESS             ON 
  8789.  
  8790.                                    Only necessary if the user wishes to run 
  8791.                                    this SAVDM or MAVDM in a window under the 
  8792.                                    Workplace Shell.  Note this pertains to 
  8793.                                    running the entire VDM in a Presentation 
  8794.                                    Manager window, not to running in seamless 
  8795.                                    mode. 
  8796.  
  8797. DPMI_MEMORY_LIMIT                  2 (MB) 
  8798.  
  8799.                                    This is the default for the Windows 
  8800.                                    environment and can always be increased when 
  8801.                                    needed.  However, decreasing this value is 
  8802.                                    not recommended. 
  8803.  
  8804. IDLE_SENSITIVITY                   75 
  8805.  
  8806.                                    This is the default value.  The performance 
  8807.                                    of some Windows applications can be improved 
  8808.                                    by re-adjusting this value to their specific 
  8809.                                    needs.  In particular, applications which 
  8810.                                    make extensive use of the mouse may exhibit 
  8811.                                    "jumpy" mouse movement when IDLE_SENSITIVITY 
  8812.                                    is allowed to default; for such 
  8813.                                    applications, IDLE_SENSITIVITY should be set 
  8814.                                    to 100, which disables idle detection. 
  8815.  
  8816.  
  8817. ΓòÉΓòÉΓòÉ 18.8. Windows Device Drivers ΓòÉΓòÉΓòÉ
  8818.  
  8819. Upon installation, the WIN.INI file is updated with the appropriate information 
  8820. for the following options.  Installation will install the following Windows 
  8821. device drivers in the appropriate directories: 
  8822.  
  8823.  Keyboard 
  8824.  
  8825.  Mouse 
  8826.  
  8827.  Video 
  8828.  
  8829.  Printer 
  8830.  
  8831.  Codepage/country. 
  8832.  
  8833. If a device driver is supported in Windows but not supported by OS/2, the 
  8834. Windows version will not be supported. 
  8835.  
  8836. Note:   Any "illegal" combination of OS/2 and Windows display device drivers 
  8837.         may cause the Windows environment to crash or not to come up at all. 
  8838.  
  8839. On the other hand, the user can configure a useful dual screen configuration, 
  8840. which will actually run the Workplace Shell on one screen and Windows on the 
  8841. other simultaneously.  OS/2 V2.0 may be run with the standard system display, 
  8842. such as VGA, XGA and so on, and in addition, another display adapter may be 
  8843. installed to run Windows applications, such as the IBM PS/2 Image Adapter/A, 
  8844. which is a Micro Channel card and supported on PS/2s. This requires the 
  8845. appropriate Windows display device driver to run exclusively on that adapter 
  8846. and the screen connected to it.  Of course, the user must change several things 
  8847. (examples shown relate to the Image Adapter/A): 
  8848.  
  8849. CONFIG.SYS     Add "DEVICE=C:\MYSUB\IADOSRFS.SYS" 
  8850.  
  8851.                This may be done via the DOS Settings for that particular 
  8852.                Windows session object under the Workplace Shell. 
  8853.  
  8854. SYSTEM.INI     Change "display.drv=IAA.DRV" 
  8855.  
  8856. IASETUP.EXE    This is a DOS program which needs to be run once after 
  8857.                installation.  This utility will actually add some special 
  8858.                entries to the WIN.INI file, which will tell the IAA.DRV display 
  8859.                device driver what resolution and color setup to use on the 
  8860.                Image Adapter. 
  8861.  
  8862. These device drivers and programs can be found on the Image Adapter support 
  8863. diskette. 
  8864.  
  8865. Note:   Do not confuse the scenario above with OS/2's standard dual screen 
  8866.         support, which is installed and configured automatically if a VGA and 
  8867.         8514 (or XGA) are found during initial installation.  In that case, 
  8868.         only one screen will be active at any given moment, while the display 
  8869.         of the other will be frozen. 
  8870.  
  8871.  
  8872. ΓòÉΓòÉΓòÉ 18.9. Print Support for Windows Applications ΓòÉΓòÉΓòÉ
  8873.  
  8874. The installation procedure will update the new WIN.INI file to include the 
  8875. printer device driver details required by Windows for printers selected under 
  8876. OS/2.  Installation selects a Windows printer device driver comparable with the 
  8877. OS/2 printer device driver for that printer. The Windows printer device driver 
  8878. will initially operate in its default mode. If the printer device driver must 
  8879. be configured in a mode other than the default mode, the printer should be 
  8880. configured from within the Windows Control Panel. 
  8881.  
  8882. If there is no equivalent OS/2 printer device driver, the Windows device driver 
  8883. should be installed and configured via the Windows Control panel. The user 
  8884. should also use a printer port which is associated with the IBMNULL.DRV PM 
  8885. printer device driver on the OS/2 side.  This will ensure the print data is 
  8886. passed straight through the port without OS/2's print subsystem modifying 
  8887. anything within the data stream.  Even the usual "printer reset" should not 
  8888. occur. 
  8889.  
  8890.  
  8891. ΓòÉΓòÉΓòÉ 18.9.1. Print Subsystem Architecture ΓòÉΓòÉΓòÉ
  8892.  
  8893. There are some interesting and significant changes to the OS/2 print subsystem 
  8894. architecture which are used to support Windows applications, and which are 
  8895. worth noting: 
  8896.  
  8897.  The print subsystem has been expanded to provide printing support for Windows 
  8898.   applications running on WIN-OS/2. 
  8899.  
  8900.  The OS/2 file system now intercepts ALL print jobs routed to an LPTx port, 
  8901.   even those directed to WIN-OS/2 LPT1 to LPT3 and WIN-OS/2 LPT1.OS2 to 
  8902.   LPT2.OS2 ports, and routes them to the OS/2 spooler. Jobs routed to a COM 
  8903.   port are not intercepted by the file system and can proceed directly to the 
  8904.   physical port via the serial port device driver. 
  8905.  
  8906. Figure "Detailed View of the WIN-OS/2 Data Connections" shows the WIN-OS/2 
  8907. details of the print subsystem architecture in more detail.  The interesting 
  8908. feature to note here is that a second spooler is present; that is, the WIN-OS/2 
  8909. spooler. The WIN-OS/2 spooler is the OS/2 V2.0 implementation of the Windows 
  8910. spooler. Similarly, the WIN-OS/2 Print Manager and WIN-OS/2 Control Panel 
  8911. represent the OS/2 V2.0 implementation of the Windows Print Manager and Windows 
  8912. Control Panel. There are minor user changes apparent in the WIN-OS/2 Control 
  8913. Panel, but these provide extra function rather than take it away. 
  8914.  
  8915. For WIN-OS/2 printing, raw print data is generated via the WIN-OS/2 printer 
  8916. driver and GDI (Graphical Device Interface).  The WIN-OS/2 printer driver 
  8917. directs the data to the appropriate port but the data route then taken varies 
  8918. depending on whether or not the OS/2 spooler is enabled, as shown in Figure 
  8919. "Low Level View of the WIN-OS/2 Printing Data Flow". 
  8920.  
  8921. If the OS/2 spooler is enabled, an INT21 is issued which provides a direct path 
  8922. for the print data to come into the OS/2 V2.0 file system.  Jobs directed to 
  8923. LPTx or LPTx.OS2 ports are intercepted by the file system and are sent on to 
  8924. the SplQmxxx interface. The print data is then processed by the print subsystem 
  8925. as though it was raw data arriving from a PM queued application. Note that for 
  8926. this scenario, the print data is processed by the WIN-OS/2 printer driver and 
  8927. also part 2 of the equivalent OS/2 printer driver. 
  8928.  
  8929. Note:   It is important to ensure that the WIN-OS/2 and OS/2 printer drivers 
  8930.         match to avoid conflict between them. If you use a WIN-OS/2 driver 
  8931.         which has no OS/2 equivalent then use the IBMNULL driver. 
  8932.  
  8933. Print jobs directed to COMx ports are not intercepted by the file system as for 
  8934. LPTx/LPTx.OS2 ports. Instead, they are passed directly to the serial  kernel 
  8935. device driver. 
  8936.  
  8937. If the OS/2 spooler is disabled, the print data bypasses many of the print 
  8938. subsystem components.  In this scenario, the WIN-OS/2 spooler will be called 
  8939. upon to spool the print job, which is actually written to the root directory of 
  8940. the fixed disk.  The queued spool files are distinguished by having the file 
  8941. extension .TMP. If the WIN-OS/2 spooler is also disabled then the print job 
  8942. passes straight through. 
  8943.  
  8944. With the OS/2 spooler disabled, there are three routes that print jobs can 
  8945. take, according to their port destination: 
  8946.  
  8947.  1. When it is the turn of a COMx job to be printed, the WIN-OS/2 spooler 
  8948.     passes the print job to the COM VDD (Virtual Device Driver). The reason for 
  8949.     this is that the job will ultimately be printed through the OS/2 serial KDD 
  8950.     (Kernel Device Driver) which is COM.SYS. A VDD cannot call upon physical 
  8951.     device drivers, such as COM.SYS, directly.  Instead it must call on the 
  8952.     services of the VDH (Virtual Device Helper) which is a programming 
  8953.     interface that is able to do this on behalf of the VDD.  Consequently, the 
  8954.     VDD passes the print data to the serial KDD via the VDH. 
  8955.  
  8956.     Note:   If you are printing to a COMx port, the WIN-OS/2 printer device 
  8957.             driver needs to initialize that port and know about the handshaking 
  8958.             protocol. To specify the correct settings, you will have to use the 
  8959.             WIN-OS/2 Control Panel and click on the Ports icon. 
  8960.  
  8961.     You should also make sure that you have installed the matching PM printer 
  8962.     device driver under the Workplace Shell. If you don't have a matching 
  8963.     version, use the IBMNULL printer device driver. This printer object needs 
  8964.     to be assigned to the same COMx port and the settings must match the 
  8965.     settings on the WIN-OS/2 side as well as the current printer setup. 
  8966.  
  8967.     If you don't do that, the printing result will be unpredictable, especially 
  8968.     for large and complex print jobs. 
  8969.  
  8970.  2. Jobs directed to LPTx are routed to the parallel physical device driver, 
  8971.     PRINT0x.SYS.SYS, via INT21. 
  8972.  
  8973.  3. Jobs sent to LPTx.OS2 are routed directly to the parallel physical device 
  8974.     driver from the WIN-OS/2 spooler. 
  8975.  
  8976. Recommendation:  It is strongly recommended that users operate the print 
  8977.                  subsystem with both spoolers enabled. Otherwise, print data 
  8978.                  from different jobs may become mixed up, and individual 
  8979.                  applications may have to wait until printing is completed 
  8980.                  before resuming execution. 
  8981.  
  8982. For more details about the entire print subsystem, including DOS and WIN-OS/2 
  8983. sessions, readers should refer to OS/2 Version 2.0 - Volume 5:  Print 
  8984. Subsystem. 
  8985.  
  8986.  
  8987. ΓòÉΓòÉΓòÉ 18.10. Font Support ΓòÉΓòÉΓòÉ
  8988.  
  8989. The following discussion can also be found in OS/2 Version 2.0 - Volume 5: 
  8990. Print Subsystem, including more details about Presentation Manager, the 
  8991. Workplace Shell, and the print subsystem. 
  8992.  
  8993. Fonts are used for output by the system to two devices: 
  8994.  
  8995.  1. Displays 
  8996.  
  8997.  2. Printers. 
  8998.  
  8999. With the many types of displays and even more numerous types of printers one 
  9000. can imagine the complexity of tracking who can use which fonts and what do they 
  9001. look like on a 75 dot display as well as a 300 dot printer. 
  9002.  
  9003. OS/2 Version 2.0 utilizes Adobe** Type Manager (ATM) for this specific purpose. 
  9004. There are two ATMs present in OS/2 Version 2.0, one for OS/2 PM applications 
  9005. and the other for WIN-OS/2 applications. These ATMs allow the system to provide 
  9006. a seamless look and consistent output while using most applications. Because 
  9007. there are two ATMs with some duplicate files, however, user installation and 
  9008. management is critical. 
  9009.  
  9010.  
  9011. ΓòÉΓòÉΓòÉ 18.10.1. Adobe Type Manager Overview ΓòÉΓòÉΓòÉ
  9012.  
  9013. ATM provides WYSIWYG text to all OS/2 V2.0 PM and WIN-OS/2 supported printers 
  9014. and displays. WYSIWYG (What You See Is What You Get) implies that what you see 
  9015. on the display is what you will see on the printed page. In reality, a 75 dot 
  9016. per inch display can not show you what a 300 dot per inch printer will produce. 
  9017. It is physically impossible. What it will give you is fully formed characters 
  9018. in virtually any size and a sense of the "balance" of the page with respect to 
  9019. line, word and letter spacing. With ATM you have the ability to install and use 
  9020. any of the hundreds of Type 1 Fonts compatible with the PostScript** Page 
  9021. Description Language. Thirteen Type 1 fonts are included in OS/2 V2.0 in four 
  9022. font groups (Times New**, Helvetica**, Courier and Symbol). This group provides 
  9023. a satisfactory basic working set, to which extra fonts can be added. 
  9024.  
  9025. With ATM, users now have a wider choice of fonts, and can display and print 
  9026. them even on lower-cost devices. For example, PostScript-quality fonts can now 
  9027. be printed on non-PostScript devices such as the IBM 4019 and 4029, and the 
  9028. HP** LaserJet** series without the need to add the additional PostScript 
  9029. interpreter option. You still get excellent results, though slower performance, 
  9030. as the fonts will be rasterized in the PS/2 rather than the printer. Even an 
  9031. IBM 4201 or an IBM 5152 or other low-cost matrix printers can print Type 1 
  9032. fonts but, of course, not with the same quality as laser printers. These same 
  9033. fonts can also be "installed" as downloadable fonts to be sent to PostScript 
  9034. printers for faster print performance. 
  9035.  
  9036. The list of available fonts for most applications is a combination of the list 
  9037. in the printer device driver you have selected for output and the fonts you 
  9038. have installed in the ATMs. Tests with Lotus 1-2-3 for Windows, Aldus** 
  9039. PageMaker, and DeScribe** indicated that as soon as additional fonts were 
  9040. installed in the Font Palette of OS/2 PM and the ATM Control Panel of WIN-OS/2, 
  9041. all of these applications were able to include them in their font choice list, 
  9042. display them and print them. Some applications like CorelDraw!** 2.0 and 
  9043. Micrographx** Designer use their own internal outline format for fonts. They 
  9044. will use the same Type 1 fonts as ATM but the fonts must be installed 
  9045. seperately in each application. Consult your application documentation to 
  9046. determine how each one handles fonts. 
  9047.  
  9048.  
  9049. ΓòÉΓòÉΓòÉ 18.10.2. ATM File Formats ΓòÉΓòÉΓòÉ
  9050.  
  9051. Files: .FON 
  9052.  
  9053. These files hold the standard OS/2 V2.0 bitmap fonts and are copied there by 
  9054. the OS/2 V2.0 install procedure. 
  9055.  
  9056. Files: .PSF 
  9057.  
  9058. PostScript font files are the new Type 1 Font files in internal-to-PM format 
  9059. which is designed (for efficiency) for the core fonts only (Times New, Courier 
  9060. and Helvetica). 
  9061.  
  9062. Files: .AFM 
  9063.  
  9064. These files hold the Adobe Font Metrics and are used by OS/2 PM ATM. 
  9065. Information such as character widths and kerning pairs are in this file. 
  9066.  
  9067. Files: .PFB 
  9068.  
  9069. These files hold the Printer Font Binary and are used by both OS/2 PM ATM and 
  9070. WIN-OS/2 ATM. These are the files that can be downloaded into printer storage. 
  9071.  
  9072. Files: .PFM 
  9073.  
  9074. These files hold the Printer Font Metrics and are used by the PostScript device 
  9075. driver to download fonts and by WIN-OS/2 ATM. 
  9076.  
  9077. Files: .PFA 
  9078.  
  9079. These files hold the Printer Font ASCII and are embedded by the PostScript 
  9080. device driver into the PostScript print job if you installed them as 
  9081. downloadable fonts. 
  9082.  
  9083. For non-ATM file formats, such as the native formats for PCL, PPDS and 420X 
  9084. printers. 
  9085.  
  9086. Figure "File Structure of Adobe Type Manager" 
  9087.  
  9088.  
  9089. ΓòÉΓòÉΓòÉ 18.11. ATM for WIN-OS/2 ΓòÉΓòÉΓòÉ
  9090.  
  9091. While ATM for OS/2 PM is integrated into the operating system, ATM for WIN-OS/2 
  9092. is a separate program that is automatically installed into the WIN-OS/2 desktop 
  9093. for you. ATM for WIN-OS/2 is accessed by using the ATM Control Panel in the 
  9094. WIN-OS/2 Main group. If you plan to manage fonts frequently after your initial 
  9095. installation it is recommended that you create a program icon on your OS/2 PM 
  9096. desktop for the WIN-OS/2 ATM control panel. The next section will describe how 
  9097. to do this. 
  9098.  
  9099.  
  9100. ΓòÉΓòÉΓòÉ 18.11.1. Installing ATM for WIN-OS/2 ΓòÉΓòÉΓòÉ
  9101.  
  9102. ATM for WIN-OS/2 is automatically installed when you install the OS/2 base 
  9103. code. However, the 13 "IBM Core Fonts" that are automatically installed for you 
  9104. in OS/2 PM are not installed under WIN-OS/2. In fact ATM for WIN-OS/2 is itself 
  9105. not active until you install at least one font. This is why you will see an "X" 
  9106. over the ATM icon when you start the WIN-OS/2 Full-Screen command prompt if you 
  9107. have not installed any fonts. Included on the device drivers diskettes are the 
  9108. necessary font files to install these "IBM Core Fonts" for WIN-OS/2. They are 
  9109. currently located on device driver diskette #5. 
  9110.  
  9111. As mentioned previously, it is a good idea to have the WIN-OS/2 ATM icon on 
  9112. your OS2 PM desktop if you manage fonts frequently. There are two ways to do 
  9113. this: 
  9114.  
  9115.  1. You can use the Migrate Applications program in the System Setup folder. 
  9116.     However, this action will place the icon in a folder called "Additional 
  9117.     Windows Programs". You will then have to open that folder and drag-and-drop 
  9118.     the ATM Control Panel icon onto your desktop. 
  9119.  
  9120.  2. You can also open the Templates folder and drag-and-drop the Program icon 
  9121.     on your desktop and type in the prompts. ATM for WIN-OS/2 is located in 
  9122.     \OS2\MDOS\WINOS2\ATMCNTRL.EXE. Use \OS2\MDOS\WINOS2 as your working 
  9123.     directory. Under Session select WIN-OS/2 window if available, otherwise 
  9124.     select WIN-OS/2 full screen. 
  9125.  
  9126. Under certain conditions ATM may become disabled or you may want to remove it 
  9127. for performance reasons if you only use standard fonts. In either case ATM for 
  9128. WIN-OS/2 is activated based on entries in the SYSTEM.INI file located in the 
  9129. path \OS2\MDOS\WINOS2. If installed correctly you will see the following 
  9130. statements: 
  9131.  
  9132.  1. system.drv=atmsys.drv 
  9133.  
  9134.  2. atm.system.drv=system.drv 
  9135.  
  9136. To disable ATM: 
  9137.  
  9138.  1. Delete the atm.system.drv=system.drv statement 
  9139.  
  9140.  2. Change system.drv=atmsysdrv to system.drv=system.drv. 
  9141.  
  9142.  
  9143. ΓòÉΓòÉΓòÉ 18.11.2. Installing Additional Fonts for WIN-OS/2 ATM ΓòÉΓòÉΓòÉ
  9144.  
  9145. Before installing any additional fonts for WIN-OS/2 make sure that all of your 
  9146. printers are installed and that they are configured for the correct output 
  9147. port. WIN-OS/2 maintains its font information in the ATM.INI for non-PostScript 
  9148. printers and in the WIN.INI for PostScript printers. For PostScript printers 
  9149. this means that PostScript printers installed after the font installation will 
  9150. not have those fonts in their list. Also if you change the output port of an 
  9151. installed PostScript printer then your fonts will disappear unless the new port 
  9152. also had a PostScript printer assigned to it while the fonts were being 
  9153. installed. 
  9154.  
  9155. To install an additional font: 
  9156.  
  9157.  1. Open the ATM Control Panel 
  9158.  
  9159.  2. Click on Add... 
  9160.  
  9161.  3. Double Click on the source of the new font(s) 
  9162.  
  9163.  4. Click on the Font files you wish to add 
  9164.  
  9165.  5. Click on Add 
  9166.  
  9167.  6. Click on Exit 
  9168.  
  9169. You must restart Windows to access the new fonts. The system will prompt you to 
  9170. do this. 
  9171.  
  9172. Important:  When you install the fonts the system will prompt you with 
  9173.             suggested paths for the files. Although you may change the path, 
  9174.             remember one thing: OS2 PM ATM will be installing the .PFB file as 
  9175.             well and will place it in a different directory. You will be 
  9176.             tempted to use the same directory for both OS/2 PM and WIN-OS/2. We 
  9177.             recommend that you use the default settings because when you delete 
  9178.             a font with the OS/2 PM Font Palette it will also delete the .PFB 
  9179.             font file! This will make the font unusable, although still 
  9180.             installed, in WIN-OS/2. Allowing the system to keep your OS/2 PM 
  9181.             and WIN-OS/2 fonts separate will save a lot of confusion in 
  9182.             managing fonts. 
  9183.  
  9184. These files would have been added to the \PSFONTS directory after installing 
  9185. the Berthold Bodoni Antiqua fonts. 
  9186.  
  9187. \PSFONTS. 
  9188.  
  9189.                       5-01-90   8:00a     39648           0  bpbi____.pfb
  9190.                       5-01-90   8:00a     38664           0  bpb_____.pfb
  9191.                       5-01-90   8:00a     36930           0  bpi_____.pfb
  9192.                       5-01-90   8:00a     37381           0  bpli____.pfb
  9193.                       5-01-90   8:00a     35979           0  bpl_____.pfb
  9194.                       5-01-90   8:00a     38740           0  bpmi____.pfb
  9195.                       5-01-90   8:00a     38098           0  bpm_____.pfb
  9196.                       5-01-90   8:00a     35837           0  bprg____.pfb
  9197.  
  9198. And these files would have been added to the \PSFONTS\PFM directory after 
  9199. installing the Berthold Bodoni Antiqua fonts. 
  9200.  
  9201. \PSFONTS\PFM. 
  9202.  
  9203.                               4-10-92  10:42a      7016           0  BPBI____.PFM
  9204.                               4-10-92  10:42a      5830           0  BPB_____.PFM
  9205.                               4-10-92  10:43a      6019           0  BPI_____.PFM
  9206.                               4-10-92  10:43a      5934           0  BPLI____.PFM
  9207.                               4-10-92  10:42a      5700           0  BPL_____.PFM
  9208.                               4-10-92  10:43a      7869           0  BPMI____.PFM
  9209.                               4-10-92  10:43a      5571           0  BPM_____.PFM
  9210.                               4-10-92  10:43a      6004           0  BPRG____.PFM
  9211.  
  9212. Note:   The internal file format is different from the standard core fonts 
  9213. delivered with OS/2 V2.0. Those have been modified for performance reasons, 
  9214. where these fonts are installed as standard Type 1 fonts. :enote. 
  9215.  
  9216. Important:  As information is added to the ATM.INI file, don't try to install 
  9217.             or remove fonts just by copying or erasing files. Adding or 
  9218.             deleting fonts must be done with the ATM Control Panel and/or the 
  9219.             Print Manager. 
  9220.  
  9221. For faster performance and better typeset quality don't forget to either 
  9222. install these fonts as downloadable, or download them directly, if you are 
  9223. using them with a PostScript printer, which does not have them already 
  9224. built-in. 
  9225.  
  9226.  
  9227. ΓòÉΓòÉΓòÉ 18.11.3. Deleting Fonts for WIN-OS/2 ATM ΓòÉΓòÉΓòÉ
  9228.  
  9229. The standard core fonts and the additional Type 1 fonts have to be deleted with 
  9230. the ATM Control Panel. To delete them: 
  9231.  
  9232.  1. Open the ATM Control Panel 
  9233.  
  9234.  2. Click on the font(s) to be removed 
  9235.  
  9236.  3. Click on Remove 
  9237.  
  9238.  4. Click on Yes in the confirmation box 
  9239.  
  9240.  5. Click on Exit 
  9241.  
  9242. You must restart Windows to use the updated font list in the ATM.INI file. The 
  9243. system will prompt you to do this. The soft font entries in the WIN.INI file, 
  9244. however, will not be deleted. This means that you will still "see" the deleted 
  9245. fonts in the font list for your applications if you choose a printer(usually 
  9246. PostScript) that has these entries. Although the font name will appear, when 
  9247. you select it you will not get the expected screen font as it has been deleted 
  9248. from ATM. Instead you will get an installed font, usually Times or Helv, 
  9249. depending on the font you selected. 
  9250.  
  9251. In order to remove the deleted fonts from the lists you must edit the 
  9252. \OS2\MDOS\WINOS2\WIN.INI file. The following example shows you a before and 
  9253. after version of the WIN.INI file if you wanted to remove all Berthold Bodoni 
  9254. Antiqua fonts from your application font lists. 
  9255.  
  9256. WIN.INI after ATM delete but before manual edit. 
  9257.  
  9258. [PostScript,LPT2.OS2]
  9259. device=36
  9260. feed1=1
  9261. feed3=1
  9262. feed5=1
  9263. feed15=1
  9264. softfonts=12
  9265. softfont1=c:\psfonts\pfm\archi___.pfm,c:\psfonts\archi___.pfb
  9266. softfont2=c:\psfonts\pfm\balleeng.pfm,c:\psfonts\balleeng.pfb
  9267. softfont3=c:\psfonts\pfm\bpb_____.pfm,c:\psfonts\bpb_____.pfb
  9268. softfont4=c:\psfonts\pfm\bpbi____.pfm,c:\psfonts\bpbi____.pfb
  9269. softfont5=c:\psfonts\pfm\bpl_____.pfm,c:\psfonts\bpl_____.pfb
  9270. softfont6=c:\psfonts\pfm\bpli____.pfm,c:\psfonts\bpli____.pfb
  9271. softfont7=c:\psfonts\pfm\bprg____.pfm,c:\psfonts\bprg____.pfb
  9272. softfont8=c:\psfonts\pfm\bpm_____.pfm,c:\psfonts\bpm_____.pfb
  9273. softfont9=c:\psfonts\pfm\bpmi____.pfm,c:\psfonts\bpmi____.pfb
  9274. softfont10=c:\psfonts\pfm\bpi_____.pfm,c:\psfonts\bpi_____.pfb
  9275. softfont11=c:\psfonts\pfm\blackcha.pfm,c:\psfonts\blackcha.pfb
  9276. softfont12=c:\psfonts\pfm\saintfra.pfm,c:\psfonts\saintfra.pfb
  9277.  
  9278. WIN.INI after manual edit. 
  9279.  
  9280. [PostScript,LPT2.OS2]
  9281. device=36
  9282. feed1=1
  9283. feed3=1
  9284. feed5=1
  9285. feed15=1
  9286. softfonts=4
  9287. softfont1=c:\psfonts\pfm\archi___.pfm,c:\psfonts\archi___.pfb
  9288. softfont2=c:\psfonts\pfm\balleeng.pfm,c:\psfonts\balleeng.pfb
  9289. softfont3=c:\psfonts\pfm\blackcha.pfm,c:\psfonts\blackcha.pfb
  9290. softfont4=c:\psfonts\pfm\saintfra.pfm,c:\psfonts\saintfra.pfb
  9291.  
  9292. Note:   In addition to deleting the line entries you must also renumber the 
  9293. remaining lines and edit the total number in the softfonts= statement. If you 
  9294. have more than one printer installed you may have to edit other groups in the 
  9295. WIN.INI under other port entries. 
  9296.  
  9297.  
  9298. ΓòÉΓòÉΓòÉ 18.12. Clipboard Support ΓòÉΓòÉΓòÉ
  9299.  
  9300. OS/2 Version 2.0 provides clipboard support between Windows applications, in 
  9301. the same or separate VDMs, as well as support between Windows applications and 
  9302. OS/2 Presentation Manager applications.  The clipboard serves as a 
  9303. data-exchange feature acting as a common area to store data handles through 
  9304. which applications exchange formatted data. The same data may be represented in 
  9305. a number of different formats as specified by the application. Note that 
  9306. objects in the clipboard may be of any size and format. 
  9307.  
  9308. The combined OS/2 and Windows clipboard environment under OS/2 Version 2.0 is 
  9309. shown in Figure "OS/2 Version 2.0 Clipboard Environment". 
  9310.  
  9311. Data is formatted in either a predefined or private format, before being copied 
  9312. to the clipboard. In most cases the data is copied to pre-allocated global 
  9313. memory and a function call is used to copy the memory handle to the clipboard. 
  9314. Windows provides a number of predefined data formats: 
  9315.  
  9316. TEXT        Null-terminated text 
  9317.  
  9318. OEMTEXT     Null-terminated text using an OEM character set 
  9319.  
  9320. PICTURE     Metafile picture structure 
  9321.  
  9322. BITMAP      Device-dependent bitmap 
  9323.  
  9324. DIB BITMAP  Device-independent bitmap 
  9325.  
  9326. SYLK        SYLK Standard data interchange format 
  9327.  
  9328. DIF         DIF standard data interchange format. 
  9329.  
  9330. TIFF        Tag Image File Format 
  9331.  
  9332. Any Private Format Will be kept in the same format.  This will be usable only 
  9333.             by applications which know about this private format. 
  9334.  
  9335. These formats will be recognized and exported/imported by the global clipboard 
  9336. server. 
  9337.  
  9338. Data formats which are not supported by the clipboard server, cannot be 
  9339. transferred.  Such formats can only be handled by the local clipboards. This 
  9340. means that such formats may only be used to exchange data between Presentation 
  9341. Manager applications, or between Windows applications running in the same VDM. 
  9342. In addition, some of the data formats will also be converted, because of 
  9343. several differences between Windows and Presentation Manager data structures. 
  9344. This is further discussed in WIN-OS/2 Clipboard Support (Scenario 3 - Cut/Paste 
  9345. Between OS/2 And WIN-OS/2). 
  9346.  
  9347. The OwnerDraw feature in the Windows clipboard is only supported within a 
  9348. MAVDM, as shared memory is required. OwnerDraw is a process whereby a Windows 
  9349. application takes control over the appearance of menu items and has 
  9350. responsibility for managing these menu items. 
  9351.  
  9352. The native Microsoft Windows 3.0 clipboard provides support for both Windows 
  9353. applications and non-Windows applications. Non-Windows applications (that is, 
  9354. "native" DOS applications) run in either full-screen or "windowed" mode.  This 
  9355. kind of environment is not supported in a MAVDM, because it is supported by the 
  9356. Workplace Shell  directly.  Therefore, clipboard support for native DOS 
  9357. applications is provided through Presentation Manager. 
  9358.  
  9359. Should the user wish to capture the contents of a VDM running in full-screen 
  9360. mode, the following approach is adopted: 
  9361.  
  9362.  1. Switch to the Presentation Manager screen containing the VDM 
  9363.  
  9364.  2. Select the System menu on the VDM icon 
  9365.  
  9366.  3. Select Copy All. 
  9367.  
  9368. This procedure will copy the VDM's video buffer to the Presentation Manager 
  9369. clipboard (either in ASCII format or as a Presentation Manager bitmap). 
  9370.  
  9371. Selective copy is available in windowed mode.  When a VDM is running in a 
  9372. window, the user may mark a specific rectangular area which will then be copied 
  9373. into the clipboard. 
  9374.  
  9375. This level of clipboard data exchange is fully supported by the VDM itself. The 
  9376. Windows kernel is not involved at all. 
  9377.  
  9378.  
  9379. ΓòÉΓòÉΓòÉ 18.12.1. WIN-OS/2 Clipboard Support ΓòÉΓòÉΓòÉ
  9380.  
  9381. The WIN-OS/2 clipboard view utility will display the captured data in a number 
  9382. of formats, either predefined or private. Auto displays the data in the format 
  9383. it had when placed onto the clipboard. 
  9384.  
  9385. The clipboard view program CLIPWOS2.EXE, installed in C:\OS2\MDOS\WINOS2, is 
  9386. available within each SAVDM and MAVDM by default.  This is a modified version 
  9387. of the original Windows 3.0 clipboard program. 
  9388.  
  9389. A Clipboard Server (Global Clipboard) runs as a protected mode background 
  9390. process under OS/2 Version 2.0, to service clipboard functions between VDMs. 
  9391. If the Clipboard Server is not executing, clipboard functions are limited to 
  9392. within a single VDM. The Clipboard Server (\OS2\MDOS\WINOS2\VDMSRVR.EXE) is 
  9393. automatically started with the first WIN-OS/2 VDM. 
  9394.  
  9395. Should a user elect to exit from the Windows clipboard, a warning message will 
  9396. be displayed, advising that exiting will terminate public clipboard functions. 
  9397. The clipboard functions within each VDM are public by default, unless 
  9398. explicitly set to LOCAL, which restricts clipboard activity to that WIN-OS/2 
  9399. session only. 
  9400.  
  9401. The WIN-OS/2 clipboard viewer pull-down menus have been enhanced to include 
  9402. support for an Options menu, which contains the Public Clipboard option. 
  9403. Selecting this option causes changes to the local clipboard to be reflected in 
  9404. the public clipboard and vice versa. When deselected, the contents of the 
  9405. public and local clipboards will not affect each other. 
  9406.  
  9407. The File pull-down menu now supports Import/Export functions; Public must be 
  9408. deselected from the Options pull-down menu before Import/Export can be 
  9409. selected. 
  9410.  
  9411. Export will copy the current contents of the local clipboard to the Public 
  9412. clipboard. 
  9413.  
  9414. Import will copy the contents of the public clipboard to the Local clipboard. 
  9415.  
  9416. Implementation Notes:  The Import/Export functions communicate via named pipes 
  9417.                        to the \pipe\CLPAgent to the clipboard program 
  9418.                        (CLIPWOS2.EXE) within each VDM. This could cause 
  9419.                        performance problems on systems which already utilize 
  9420.                        named pipes heavily for other purposes or when the 
  9421.                        content of the clipboard data is too big, for example 
  9422.                        huge bitmaps.  If you don't need to exchange clipboard 
  9423.                        data outside a MAVDM, you could keep it local and 
  9424.                        therefore get around any possible performance problems. 
  9425.  
  9426.  
  9427. ΓòÉΓòÉΓòÉ 18.12.2. Using Cut and Paste ΓòÉΓòÉΓòÉ
  9428.  
  9429. The following three scenarios describe the clipboard functions: 
  9430.  
  9431.  1. Cut and Paste from a Windows Application in a VDM to another application in 
  9432.     a separate VDM; Public is deselected. 
  9433.  
  9434.  2. Cut and Paste between two Windows applications within the same VDM (MAVDM). 
  9435.  
  9436.  3. Cut and Paste between the OS/2 and Windows environments. Cut and Paste 
  9437.     within the OS/2 environment remains essentially unchanged. 
  9438.  
  9439. Scenario 1 - Cut/Paste Between Independent WIN-OS/2 Sessions 
  9440.  
  9441.  1. Cut the data into the local Windows VDM clipboard. 
  9442.  
  9443.  2. Select Export from the clipboard pull-down menu. The data is copied into 
  9444.     the external clipboard. 
  9445.  
  9446.  3. Select the VDM containing the destination Windows application. 
  9447.  
  9448.  4. Select Import from the clipboard pull-down menu. The data is copied from 
  9449.     the external clipboard into the local clipboard of the receiving VDM. 
  9450.  
  9451.  5. Paste the data into the destination Windows application. 
  9452.  
  9453. Note:   Steps 2 and 4 above are not necessary if the clipboard is public in the 
  9454. source and destination VDM. 
  9455.  
  9456. Scenario 2 - Cut/Paste Within A MAVDM 
  9457.  
  9458.  1. Cut the data into the Windows VDM clipboard 
  9459.  
  9460.  2. Paste the data from the clipboard into the destination application. 
  9461.  
  9462. Scenario 3 - Cut/Paste Between OS/2 And WIN-OS/2 
  9463.  
  9464. The OS/2 V2.0 clipboard is activated upon loading the operating system.  A new 
  9465. OS/2 utility named CLIPVIEW.EXE is located in the OS2\APPS\ directory, and has 
  9466. been provided to support the extended clipboard functions. CLIPVIEW.EXE must be 
  9467. started in order to view and transfer the contents of the OS/2 V2.0 clipboard. 
  9468.  
  9469. With the exception of the File option of the Windows clipboard, the same 
  9470. pull-down menus are provided. The Render option is the same as the Display 
  9471. option in the Windows clipboard.  Render will display the contents of the 
  9472. clipboard in a number of different formats.  Because the contents of the 
  9473. clipboard are stored in separate areas in memory, it is possible to view both 
  9474. the ASCII (text) and graphics contents of the clipboard. 
  9475.  
  9476. Note:   An application may or may not clear the entire contents of the 
  9477.         clipboard, prior to copying data to it.  For example, the system editor 
  9478.         will always erase the entire Presentation Manager clipboard, and 
  9479.         therefore any public Windows clipboard as well, before it copies its 
  9480.         text data into it.  On the other hand, some of the Presentation Manager 
  9481.         applications do not behave that way. They will only override the 
  9482.         specific data areas which are copied into the clipboard and leave the 
  9483.         other ones in the clipboard unchanged. 
  9484.  
  9485. The global Windows VDM clipboard is visible to the Presentation Manager 
  9486. clipboard. CLIPVIEW.EXE has been enhanced to perform the following two 
  9487. activities: 
  9488.  
  9489.  1. Update the Presentation Manager clipboard when changes are made to the 
  9490.     global VDM Clipboard 
  9491.  
  9492.  2. Update the global Windows VDM clipboard when changes are made to the 
  9493.     Presentation Manager clipboard. 
  9494.  
  9495. The Presentation Manager clipboard server application is registered as 
  9496. "clipboard viewer" to receive notification of clipboard updates.  This ensures 
  9497. that the following messages are forwarded to the clipboard server, so that when 
  9498. updates are made to the Presentation Manager clipboard, messages are sent to 
  9499. the Presentation Manager CLIPVIEW.EXE. 
  9500.  
  9501.  WM_DESTROYCLIPBOARD: Signals that the contents of the clipboard are being 
  9502.   destroyed 
  9503.  
  9504.  WM_DRAWCLIPBOARD: Signals an application to notify the next application in 
  9505.   the chain of a change to the clipboard 
  9506.  
  9507.  WM_HSCROLLCLIPBOARD: Requests horizontal scrolling of the clipboard contents 
  9508.  
  9509.  WM_PAINTCLIPBOARD: Requests painting of the contents of the clipboard 
  9510.  
  9511.  WM_RENDERALLFMTS: Notifies the owner of the clipboard that it must render 
  9512.   clipboard data in all possible formats 
  9513.  
  9514.  WM-RENDERFMT: Notifies the clipboard owner that it must format the last data 
  9515.   copied to the clipboard 
  9516.  
  9517.  WM_SIZECLIPBOARD: Notifies the clipboard  owner that the clipboard 
  9518.   application's window size has changed 
  9519.  
  9520.  WM_VSCROLLCLIPBOARD: Requests vertical scrolling of the clipboard contents. 
  9521.  
  9522. Note:   No changes have been made to the Presentation Manager API functions to 
  9523.         accommodate this design.  Presentation Manager applications will not 
  9524.         notice any difference; there appears to be just one (Presentation 
  9525.         Manager) clipboard as it always used to be.  The same is true for 
  9526.         Windows applications as well. 
  9527.  
  9528. Data formats are translated from Presentation Manager to Windows formats and 
  9529. vice versa, as required. This translation is performed when data is placed in 
  9530. the global clipboard. The following data formats will be translated between 
  9531. Presentation Manager and Windows: 
  9532.  
  9533. Windows DIB bitmaps: The Windows device-independent bitmaps are translated 
  9534.                      to/from OS/2 Presentation Manager bitmaps. 
  9535.  
  9536. Windows bitmaps:     This translated pre-Windows 3.0 formatted bitmaps to OS/2 
  9537.                      Presentation Manager bitmaps. 
  9538.  
  9539.                      Note:   This is a one way only translation. 
  9540.  
  9541. Windows Metafiles:   Windows metafiles are first internally converted to the 
  9542.                      Windows DIB format by the Windows clipboard viewer, before 
  9543.                      being forwarded to the global clipboard. 
  9544.  
  9545. PM Metafiles:        PM metafiles are first internally converted to the PM 
  9546.                      bitmap format by the PM clipboard viewer, before being 
  9547.                      forwarded to the global clipboard. 
  9548.  
  9549. Text:                ASCII text will be translated in both directions.  If the 
  9550.                      sending and receiving environment are using a different 
  9551.                      codepage, the appropriate codepage translation will take 
  9552.                      place. 
  9553.  
  9554.  
  9555. ΓòÉΓòÉΓòÉ 18.13. Dynamic Data Exchange ΓòÉΓòÉΓòÉ
  9556.  
  9557. This section describes Dynamic Data Exchange (DDE) support between Windows 
  9558. applications in a full-screen VDM. 
  9559.  
  9560.  
  9561. ΓòÉΓòÉΓòÉ 18.13.1. DDE Concepts ΓòÉΓòÉΓòÉ
  9562.  
  9563. DDE is a message protocol for dynamic data exchange between Windows programs. 
  9564. Data may be shared among applications, the intention being to create an 
  9565. integrated Windows environment. 
  9566.  
  9567. Client, Server and Conversation: 
  9568.  
  9569. Two applications participating in dynamic data exchange are said to be engaged 
  9570. in a DDE conversation. The application which initiates the conversation is the 
  9571. client application. The application which responds to the client is the server 
  9572. application.  An application may be engaged in several conversations at the 
  9573. same time, acting as a client in some conversations and as a server in others. 
  9574.  
  9575. A DDE conversation takes place between two windows, one for each of the 
  9576. participating applications.  The window may be the main window of the 
  9577. application, a secondary window associated with the application, or a hidden 
  9578. window. A hidden window is typically used to process DDE messages. 
  9579.  
  9580. DDE identifies the units of data passed between the client and server with a 
  9581. three-level hierarchy of: 
  9582.  
  9583.  Application name 
  9584.  
  9585.  Topic 
  9586.  
  9587.  Item. 
  9588.  
  9589. Each DDE conversation is uniquely identified by the application name and topic. 
  9590. The application name is normally the name of the server application. The topic 
  9591. is a general classification of data, within which multiple data items may be 
  9592. exchanged during the conversation. The item is the actual information related 
  9593. to the conversation topic that is exchanged between the applications.  Values 
  9594. for the data item can be passed from the server to the client, or from client 
  9595. to server. The format of the data item may be any one of the clipboard formats 
  9596. (see Clipboard Support). 
  9597.  
  9598. Once a DDE conversation has been initiated, the client may establish one or 
  9599. more permanent data links with a server. A data link is a communication 
  9600. mechanism by which the server notifies the client whenever the value of a given 
  9601. data item changes.  The link is permanent in the sense that the notification 
  9602. process continues until the data link or DDE conversation is terminated. 
  9603.  
  9604. The DDE link may be warm or hot. In a warm data link, the server notifies the 
  9605. client that a value of a given data item has changed, but the server does not 
  9606. actually send the data value to the client until the client requests it. In a 
  9607. hot data link, the server immediately sends the changed data value to the 
  9608. client. 
  9609.  
  9610. Applications which support DDE typically provide a Copy/Paste command in the 
  9611. Edit menu to allow the user to establish a DDE link. 
  9612.  
  9613.  
  9614. ΓòÉΓòÉΓòÉ 18.13.2. Windows Application to Windows Application ΓòÉΓòÉΓòÉ
  9615.  
  9616. In a native Windows 3.0 environment, a Windows application (client) will 
  9617. broadcast a DDE Initiate message. Windows serially posts a message to every 
  9618. Windows application currently running and then awaits a reply. As described 
  9619. above, the Initiate Conversation message contains the DDE topic to which any 
  9620. Windows application can respond. The client application continues execution 
  9621. when all other applications have serviced the message. At this time, the client 
  9622. application communicates directly with the server applications, as opposed to 
  9623. the initial broadcast message. 
  9624.  
  9625. OS/2 Version 2.0 provides two applications to support communications between 
  9626. VDMs, without altering the Windows code: 
  9627.  
  9628.  A resident Windows application referred to as the DDE ServerAgent (SA) 
  9629.  
  9630.  A DOS protected mode application referred to as the DDEServer (VDMSRVR.EXE). 
  9631. ServerAgent 
  9632.  
  9633. The Windows VDM's resident ServerAgent consists of two parts: 
  9634.  
  9635.  A "ServerAgent" which sends and receives messages outside of the VDM 
  9636.  
  9637.  One or more "agents" (each agent is a child window of the ServerAgent), which 
  9638.   act as "clones" of applications running in other VDMs. 
  9639.  
  9640. If either the DDEServer or the VDM's ServerAgent is not executing, DDE is not 
  9641. available outside of the VDM.  The ServerAgent is automatically started when 
  9642. the Windows VDM is started.  When started, DDE is in public mode.  To keep it 
  9643. local, simply kill (close) the DDE Interchange Agent.  To make it public again, 
  9644. simply start the Interchange Agent once more. 
  9645.  
  9646. Should the user choose to kill the DDE Interchange Agent, an information 
  9647. message will be displayed indicating that DDE activity will be visible only to 
  9648. the Windows applications executing in the current VDM, discontinuing DDE 
  9649. communication with Presentation Manager applications and other Windows 
  9650. applications. 
  9651.  
  9652. The ServerAgent is responsible for all routing of DDE messages, including 
  9653. broadcast messages beyond the confines of the VDM to the DDEServer. The 
  9654. ServerAgent communicates with the DDEServer (VDMSRVR.EXE) via named pipes. 
  9655.  
  9656. Agent applications communicate with Windows applications in their VDM and the 
  9657. ServerAgent executing in their VDM. Only the ServerAgent uses named pipes. 
  9658. Agents send requests to the ServerAgent to be forwarded outside of the VDM. 
  9659.  
  9660. DDEServer (VDMSRVR.EXE) 
  9661.  
  9662. The DDEServer is responsible for routing requests from ServerAgents to the 
  9663. appropriate VDMs. The DDE process is schematically represented in Figure "DDE 
  9664. Process between Windows Environments". 
  9665.  
  9666. The sequence of events for DDE communication between applications running in 
  9667. different WIN-OS/2 VDMs is as follows: 
  9668.  
  9669.  1. A DDE Initiate message is broadcast from Windows application A. 
  9670.  
  9671.  2. The message is forwarded by the ServerAgent to the DDEServer. 
  9672.  
  9673.  3. The DDEServer forwards this message to all other DDEAgents. 
  9674.  
  9675.  4. Each DDEAgent broadcasts this initiate message to all Windows applications 
  9676.     in their VDM. 
  9677.  
  9678.  5. Windows application D responds  affirmatively to this DDE initiate message. 
  9679.  
  9680.  6. The DDEAgent creates a child task ServerAgent A to act as an agent to 
  9681.     Windows application A. 
  9682.  
  9683.  7. The DDEAgent forwards an acknowledgement to the DDEServer. 
  9684.  
  9685.  8. The DDEServer forwards this acknowledgement to the DDEAgent for the Windows 
  9686.     application A. 
  9687.  
  9688.  9. This DDEAgent creates a child task ServerAgent D to act as an agent to 
  9689.     Windows application D. 
  9690.  
  9691. 10. The DDEAgent forwards the response from Windows application D to the 
  9692.     Windows application A. 
  9693.  
  9694. From here on, the two Windows applications communicate through this established 
  9695. path. 
  9696.  
  9697. Appl. A <-> DDEChildAgent D <-> DDEAgent A <-> DDEServer <-> DDEAgent D <-> 
  9698. DDEChildAgent A <-> Appl. D. 
  9699.  
  9700. This mechanism isolates all named pipe transactions (Steps 2, 3, 7 and 8) to 
  9701. the DDEAgents and the DDEServer.  It also gives the Windows application A the 
  9702. illusion of a point-to-point connection to Windows application D (because it 
  9703. will actually communicate with Windows application D's child agent in the same 
  9704. VDM). 
  9705.  
  9706. The interprocess communication protocol used between the Windows applications 
  9707. and the DDEAgents is the original and unmodified DDE protocol. 
  9708.  
  9709. If two Windows applications require significant amounts of DDE, these 
  9710. applications should be executed from within the same MAVDM.  In such instances, 
  9711. the ServerAgent and DDEServer applications would not be required, thereby 
  9712. improving performance and usability.  Once this is done, the user need only 
  9713. kill (close) the participating DDE Interchange Agent to ensure that all DDE 
  9714. messaging is kept local. 
  9715.  
  9716.  
  9717. ΓòÉΓòÉΓòÉ 18.13.3. Windows Application to Presentation Manager Application ΓòÉΓòÉΓòÉ
  9718.  
  9719. DDE support between Windows applications and Presentation Manager applications 
  9720. requires that the DDEServer be linked with the Presentation Manager DDE APIs. 
  9721. Both DDE messages and data formats are translated during the data exchange 
  9722. between Presentation Manager and any given VDM running a Windows application. 
  9723. This process consists of a protected mode DDEServer, a Windows DDE ServerAgent, 
  9724. as described above, and a Presentation Manager DDE ServerAgent. The 
  9725. Presentation Manager DDE ServerAgent is a mirror to the Windows DDE 
  9726. ServerAgent. The ServerAgent is responsible for routing all DDE messages beyond 
  9727. the confines of Presentation Manager to the DDEServer. The ServerAgent 
  9728. communicates with the DDEServer via named pipes. 
  9729.  
  9730. The DDE process between Presentation Manager applications and Windows 
  9731. applications may be represented as in Figure "DDE Process between Presentation 
  9732. Manager and Windows". 
  9733.  
  9734. The following data formats are translated between the Presentation Manager 
  9735. environment and the Windows environment: 
  9736.  
  9737. Bitmaps:             Windows DIB format to/from OS/2 BITMAPINFO2 and 
  9738.                      Presentation Manager BITMAPINFO to/from Windows DIB 
  9739.                      format. 
  9740.  
  9741. Windows Device Dependent Bitmaps: Pre-Windows 3.0 format to Windows DIB format 
  9742.                      to/from Presentation Manager  BITMAPINFO. 
  9743.  
  9744. Windows Metafiles:   Metafiles are converted to Window DIB format prior to 
  9745.                      being translated as above. 
  9746.  
  9747. PM Metafiles:        PM metafiles are first converted to Window DIB format 
  9748.                      prior to being translated as above, and are then forwarded 
  9749.                      to the global clipboard. 
  9750.  
  9751. Text:                Codepage translation is provided in both directions, if 
  9752.                      required. 
  9753.  
  9754. Any data format which is not supported by the global DDEServer translation 
  9755. routines, can still be used on a local base, that means within the same VDM. 
  9756.  
  9757. The Presentation Manager DDE ServerAgent will reside as a utility in a 
  9758. Productivity folder on the Workplace Shell.  Where there is a demand to provide 
  9759. DDE support between Presentation Manager applications and Windows applications, 
  9760. the Presentation Manager DDE ServerAgent should be placed in the Workplace 
  9761. Startup folder.  The DDE ServerAgent runs only as a minimized icon. To shut 
  9762. down global DDE, the Presentation Manager  DDE ServerAgent must be terminated 
  9763. through the Window List. 
  9764.  
  9765. If a seamless Windows session is started, the DDE ServerAgent will 
  9766. automatically be started, so that this particular Windows application can 
  9767. automatically use DDE.  Otherwise, it would appear to be isolated and this 
  9768. would confuse the novice user. 
  9769.  
  9770. Existing DDE support between Presentation Manager applications remains 
  9771. essentially unchanged. Where DDE is only used between Presentation Manager 
  9772. applications, the DDEServer should be deactivated to improve performance. 
  9773.  
  9774.  
  9775. ΓòÉΓòÉΓòÉ 18.14. Object Linking and Embedding ΓòÉΓòÉΓòÉ
  9776.  
  9777. Object Linking and Embedding (OLE) focuses on document formats rather than on 
  9778. an application's ability to exchange data, as implemented using the DDE 
  9779. approach. OLE is concerned with sharing functionality as opposed to sharing 
  9780. data. The better the application of OLE, the less the concern with programs as 
  9781. opposed to their data. 
  9782.  
  9783. All OLE transactions involve a client application and a server application. The 
  9784. server creates the embedded or linked document and is activated when any 
  9785. activity beyond display is required; the client packages and renders the object 
  9786. within its own document. 
  9787.  
  9788. OLE objects are packaged within client documents either statically (embedded) 
  9789. or dynamically (linked).  The entire contents of an embedded object, including 
  9790. references to the server application, are included in the client document. 
  9791.  
  9792. OLE defines a format for compound documents which contain multiple forms of 
  9793. data. The data formats are understood and managed by multiple applications. The 
  9794. application uses various combinations of data to construct a compound document. 
  9795.  
  9796.  
  9797. ΓòÉΓòÉΓòÉ 18.14.1. OLE Concepts ΓòÉΓòÉΓòÉ
  9798.  
  9799. The concepts used in OLE are best described by contrasting them with the 
  9800. approach adopted by clipboard and DDE: 
  9801.  
  9802.  When using the clipboard, an application obtains data from another 
  9803.   application in a standard format, usually ASCII, a bitmap or a metafile. 
  9804.   This data exists only as data; there is no link with the application that 
  9805.   originally placed the data in the clipboard. 
  9806.  
  9807.  When using DDE, an application also obtains data from another application in 
  9808.   a standard format, such as ASCII, bitmap or metafile. However, the client can 
  9809.   establish and maintain a link with the application which delivered the data. 
  9810.   Should the data change in the server application, the client application's 
  9811.   data is also updated. 
  9812.  
  9813. OLE also enables an application to obtain data from another application; in 
  9814. this instance the data can be in two formats: 
  9815.  
  9816.  One format is understood only by the application sending the data 
  9817.  
  9818.  The display format (ASCII, bitmap or metafile) is understood by the receiving 
  9819.   application, and is used to display the data on the screen. 
  9820.  
  9821. When an object is linked, only the references to the actual data, including the 
  9822. name of the server application, are embedded within the client document. In 
  9823. both cases, the references allow the OLE libraries to execute the server and 
  9824. properly instruct it. 
  9825.  
  9826. When initially embedding or linking objects, client and server applications 
  9827. typically exchange data using the Windows clipboard. When the server puts data 
  9828. on the clipboard, it uses various combinations of four types of data: 
  9829.  
  9830.  1. Native data is specific to the server and likely to be alien to the client. 
  9831.  
  9832.  2. Presentation data uses one of several display formats commonly used by 
  9833.     Windows programs to render data. 
  9834.  
  9835.  3. OwnerLink data is the name and address identifying the object or 
  9836.     application that owns the data. 
  9837.  
  9838.  4. ObjectLink data uses the same format as OwnerLink data but describes the 
  9839.     application and object from which the data originated. 
  9840.  
  9841. The order in which this data is put on the clipboard, or otherwise presented to 
  9842. the client, determines what type of object is intended. 
  9843.  
  9844. For example, if OwnerLink data is presented first, then a linked object is 
  9845. intended. If Native data is first and OwnerLink is second, then the object can 
  9846. be embedded (though not necessarily rendered properly). 
  9847.  
  9848. In fact, a presentation format is optional for an embedded object, partly 
  9849. because some objects are meant to be invisible. If no presentation data is 
  9850. available and understood by the client and no object handler is provided by the 
  9851. server, the object will not be properly rendered by the client. 
  9852.  
  9853. The significance of this approach may be appreciated by way of an example. 
  9854. Voice annotation may be attached to a word processing application; the word 
  9855. processing application need not have any facility to support or manage voice. 
  9856. The word processor will store the data in two formats; the digitized sound and 
  9857. a display format (an icon). When the icon is selected in the document, a voice 
  9858. application is invoked and the word processing application passes the digitized 
  9859. sound to the voice application, which then plays the sound. 
  9860.  
  9861.  
  9862. ΓòÉΓòÉΓòÉ 18.14.2. Linking versus Embedding ΓòÉΓòÉΓòÉ
  9863.  
  9864. When an object is embedded, information from one document is inserted into a 
  9865. document in a different application. Embedding is similar to copying, but with 
  9866. one significant difference; to make changes to an embedded object, the user 
  9867. simply selects the object from within the destination document. The application 
  9868. in which the object was created is invoked, and the user may make the required 
  9869. changes.  There is no need to switch among applications to view or change 
  9870. different kinds of information; it is all in one document. 
  9871.  
  9872. When an embedded object is modified, the source document is not affected. For 
  9873. example, if a drawing is embedded into a report, changes made to the drawing 
  9874. within the report do not affect the original drawing which resides in its own 
  9875. file. 
  9876.  
  9877. When an object is linked, many documents can share a single item of 
  9878. information.  The object itself is not placed into the destination document; 
  9879. rather, a representation, or placeholder, for the object being linked is placed 
  9880. into the document.  The object still exists in the source document, and the 
  9881. destination document merely contains a link to the object's location in the 
  9882. source document. 
  9883.  
  9884. When changes are made to a linked object, the source document and any other 
  9885. documents linked to the object will reflect the changes. For example, if a 
  9886. drawing is linked to a report, any changes you make to the drawing appear in 
  9887. the source document and in any other reports linked with the drawing. 
  9888.  
  9889. Access may be gained to the object from any document that contains a link to 
  9890. it, and changes may be made to the object from within any such document. The 
  9891. updated version automatically appears in all the documents that have a link to 
  9892. this object. Linking makes it easy to track information that appears in more 
  9893. than one place and which must be identical. 
  9894.  
  9895. Only objects from saved documents may be linked.  For example, if a drawing is 
  9896. created using Paintbrush, the drawing must be saved as a document before it may 
  9897. be linked from another document. 
  9898.  
  9899. Not all applications can provide and accept objects. Some may only be the 
  9900. source of objects (server applications). Others (client applications) may only 
  9901. accept objects. 
  9902.  
  9903.  
  9904. ΓòÉΓòÉΓòÉ 18.15. Summary ΓòÉΓòÉΓòÉ
  9905.  
  9906. OS/2 Version 2.0 provides support for the execution of Windows applications 
  9907. within the MVDM architecture.  This support allows the concurrent execution of 
  9908. multiple Windows applications, using both real mode and standard mode, with 
  9909. DPMI and Windows services provided as required by a Windows kernel. 
  9910.  
  9911. Windows applications running under OS/2 Version 2.0 are provided with 
  9912. pre-emptive multitasking by the operating system.  Full memory protection is 
  9913. also provided for the Windows applications; an errant application may not 
  9914. affect other applications executing in the system.  A bug in an application 
  9915. will cause the termination of that application only. 
  9916.  
  9917. Windows applications may be run under OS/2 Version 2.0 in three ways: 
  9918.  
  9919.  Each application may run in its own VDM.  This method of execution provides 
  9920.   full protection for the application from other processes running in the 
  9921.   system, and protects these other processes from errors in the Windows 
  9922.   application. 
  9923.  
  9924.  Applications may share a VDM, and may be started and controlled within this 
  9925.   VDM using the Windows Program Manager.  This method of execution provides 
  9926.   protection for the Windows applications within the VDM from other processes, 
  9927.   and protection for other processes from errors in the Windows VDM's 
  9928.   applications.  However, the applications within the VDM may affect one 
  9929.   another since they share a common address space, just as if they were running 
  9930.   natively under DOS/Windows. 
  9931.  
  9932.  Windows applications may run "seamlessly" on the Workplace Shell  desktop, 
  9933.   along with windowed VDMs and Presentation Manager applications.  This method 
  9934.   of execution is similar to the case of a single application in a VDM, except 
  9935.   that the Windows application shares the Workplace Shell desktop rather than 
  9936.   running in its own full-screen session. 
  9937.  
  9938. Any combination of these three methods may be used concurrently. 
  9939.  
  9940. Windows applications may be defined on and started from the Workplace Shell 
  9941. desktop.  Where a single application is defined for a VDM, or where the 
  9942. application will run seamlessly, the icon used to represent the application on 
  9943. the desktop is the icon embedded within the Windows program which runs the 
  9944. application. 
  9945.  
  9946. During installation of OS/2 Version 2.0 over an existing DOS/Windows 3.0 
  9947. system, existing applications defined to the Windows Program Manager will be 
  9948. detected and migrated where possible to the OS/2 Version 2.0 Workplace Shell. 
  9949. The installation procedure uses application definition information contained in 
  9950. the Certified Application Database, which is shipped as part of the OS/2 
  9951. Version 2.0 product. 
  9952.  
  9953. OS/2 Version 2.0 allows communication between Windows applications running in 
  9954. the same or different VDMs, and between Windows applications and Presentation 
  9955. Manager applications.  This communication is provided through clipboard, DDE 
  9956. and OLE support.  Communication between Windows applications using shared 
  9957. memory is also supported, but only where Windows applications are executing in 
  9958. the same VDM. 
  9959.  
  9960. In summary, OS/2 Version 2.0 provides an integration platform which allows 
  9961. Windows applications to coexist with one another and with DOS and OS/2 
  9962. applications in a multitasking, fully protected environment, and which allows 
  9963. these applications to communicate with one another. 
  9964.  
  9965.  
  9966. ΓòÉΓòÉΓòÉ 19. DOS Protected Mode Interface ΓòÉΓòÉΓòÉ
  9967.  
  9968. Perhaps the most significant limitation of real mode operation, as used by DOS 
  9969. and similar operating systems, is the 1MB addressing limitation.  This 
  9970. limitation can be overcome by executing applications in protected mode, but 
  9971. since the DOS operating system and most TSR applications must run in real mode, 
  9972. problems arise when applications attempt to access interrupts, TSRs or 
  9973. operating system facilities. 
  9974.  
  9975. The DOS Protected Mode Interface (DPMI) is a protected mode programming 
  9976. interface for DOS applications, allowing such applications to run on an 80286 
  9977. or 80386 processor in protected mode, while utilizing the real mode services of 
  9978. the operating system and device drivers.  When an application wishes to access 
  9979. a DOS service, it makes a request to DPMI, which handles the appropriate 
  9980. address translations, switches the processor to real mode and makes the service 
  9981. request to DOS.  The result of the request is then translated to the correct 
  9982. format for the protected mode application, the processor is switched back to 
  9983. protected mode, and control is returned to the application. 
  9984.  
  9985. DPMI has been implemented in the Multiple Virtual DOS Machines component of 
  9986. OS/2 Version 2.0, and provides functions such as memory allocation and 
  9987. interrupt management for applications which use DPMI services. This support is 
  9988. provided through a component, implemented as a virtual device driver, known as 
  9989. the DPMI API Layer, in conjunction with the MVDM kernel. 
  9990.  
  9991. This chapter provides a brief overview of DPMI, and describes its 
  9992. implementation under OS/2 Version 2.0. 
  9993.  
  9994.  
  9995. ΓòÉΓòÉΓòÉ 19.1. DPMI Introduction ΓòÉΓòÉΓòÉ
  9996.  
  9997. Most processor instructions that are available in real mode may also be 
  9998. executed from a protected mode task.  Hence an application may overcome the 
  9999. limitations of real mode simply by executing in protected mode. However, direct 
  10000. access to physical hardware and interrupts is typically not permitted from a 
  10001. protected mode task running at Ring 3 privilege, and therefore DOS itself and 
  10002. many TSR programs must run in real mode. Protected mode specifications are such 
  10003. that communication between protected mode and real mode programs is difficult, 
  10004. making it difficult for an application to request services from DOS or a device 
  10005. driver. 
  10006.  
  10007. For example, a TSR, with which an application communicates through a software 
  10008. interrupt or a shared buffer, cannot run in protected mode.  The real mode 
  10009. address of the TSR, if used by the protected mode application, will not point 
  10010. to the same location in memory as would the same address if used in real mode, 
  10011. since the segment portion of the address is interpreted differently in the two 
  10012. modes.  Address conversion is therefore required when passing between the two 
  10013. modes. 
  10014.  
  10015. DPMI provides an interface between protected mode and real mode programs. DPMI 
  10016. consists of a set of protected mode functions which allow a DOS application to 
  10017. enter protected mode, allocate real mode memory, simulate real mode interrupts 
  10018. and function calls, intercept real mode interrupt vectors, etc.  By using these 
  10019. calls, an application running in protected mode can communicate with DOS or a 
  10020. TSR running in real mode. 
  10021.  
  10022. DPMI facilitates the following: 
  10023.  
  10024.  Allows DOS applications to run in protected mode 
  10025.  
  10026.  Provides DOS applications with access to a large memory address space 
  10027.  
  10028.  Provides DOS applications with mode switching and calls between real mode and 
  10029.   protected mode 
  10030.  
  10031.  Provides DOS applications running in protected mode with access to hardware 
  10032.   facilities such as debug registers, in a way that maintains system integrity. 
  10033.  
  10034. The term real mode is used to refer to code that runs in the low 1MB address 
  10035. space and uses segment:offset addressing.  Under many implementations of DPMI, 
  10036. so-called real mode software is actually executed in virtual 8086 mode.  Since 
  10037. virtual 8086 mode closely approximates real mode, V86 mode and real mode are 
  10038. interchangeable in the DPMI context. 
  10039.  
  10040. One of the major benefits offered by DPMI is that of allowing DOS extenders to 
  10041. work effectively in a multitasking, protected mode environment.  DOS extenders 
  10042. allow DOS applications to access extended memory while running in protected 
  10043. mode.  These extenders switch between modes as required to: 
  10044.  
  10045.  Execute application code in protected mode, in order to realize the enhanced 
  10046.   addressing capabilities and protection facilities of protected mode 
  10047.  
  10048.  Access DOS services and TSRs in real mode, to perform functions which cannot 
  10049.   be performed in protected mode. 
  10050.  
  10051. The Microsoft Windows/286 DOS extender (running under DOS on an 80286 
  10052. processor) was able to switch modes of its own accord. However, when running in 
  10053. virtual 8086 mode on an 80386 processor, a task cannot switch to protected 
  10054. mode; the required instruction is not legal for a V86 mode task. The 
  10055. architecture of DPMI, however, allows DOS extenders to request services using 
  10056. INT 31h DPMI calls; DPMI itself handles the mode switching and address 
  10057. conversion necessary to invoke the real mode services. 
  10058.  
  10059.  
  10060. ΓòÉΓòÉΓòÉ 19.2. Virtual Control Program Interface ΓòÉΓòÉΓòÉ
  10061.  
  10062. The forerunner to DPMI was the Virtual Control Program Interface (VCPI), 
  10063. developed by Phar Lap Software** and Quarterdeck Office Systems**.  VCPI 
  10064. allowed 80386-based protected mode DOS extenders to coexist with 80386-specific 
  10065. memory managers and expanded memory (EMS) emulators, such as QEMM-386 by 
  10066. Quarterdeck.  Most current 80386-specific software products support, or are 
  10067. capable of using, the VCPI interface. 
  10068.  
  10069. In VCPI, the DOS extender acts as a client and the EMS emulator acts as a 
  10070. server.  The client invokes the VCPI server to: 
  10071.  
  10072.  Switch between real mode and protected mode 
  10073.  
  10074.  Allocate memory 
  10075.  
  10076.  Program the interrupt controller(s) 
  10077.  
  10078.  Inspect or set the 80386 debug registers. 
  10079.  
  10080. If a DOS extender is loaded and a VCPI server is not present, the DOS extender 
  10081. may assume total control of the system and perform hardware-dependent 
  10082. manipulations directly. This can lead to system and data integrity problems. 
  10083.  
  10084. Note:   Do not confuse VCPI (Virtual Control Program Interface) with VPIC 
  10085.         (Virtual Programmable Interrupt Controller). 
  10086.  
  10087. While VCPI performs well for that which it was intended, it does not provide a 
  10088. platform for multitasking DOS extender applications.  The deficiency lies in 
  10089. VCPI allowing client programs to run in Ring 0, the highest privilege level 
  10090. possible under the 80386 processor. 
  10091.  
  10092. What was required was an interface capable of managing and controlling device 
  10093. initialization and providing centralized virtual memory management. Most 
  10094. important the interface had to shield one client from another. 
  10095.  
  10096.  
  10097. ΓòÉΓòÉΓòÉ 19.3. The DPMI Specification ΓòÉΓòÉΓòÉ
  10098.  
  10099. DPMI was devised by a committee of major software vendors.  The first (and 
  10100. current) DPMI version is Version 1.0. 
  10101.  
  10102. DPMI was defined to allow DOS programs to access extended memory while 
  10103. maintaining system protection.  DPMI defines a specific subset of DOS and BIOS 
  10104. calls that can be made by DOS programs running in protected mode. These 
  10105. services are accessed via software interrupt 31h, using a defined series of 
  10106. functions which protected mode programs may use to allocate memory, modify 
  10107. descriptors and call real mode software. 
  10108.  
  10109. Like VCPI, a DPMI host (or server) program provides mode switching and extended 
  10110. memory management services to client programs.  Unlike a VCPI server, however, 
  10111. a DPMI host runs at a higher privilege level than its clients.  A DPMI host 
  10112. supports demand-paged virtual memory and maintains complete control over the 
  10113. address space and hardware access of its clients. 
  10114.  
  10115. Some DPMI implementations execute multiple protected mode programs in 
  10116. independent virtual machines.  In such implementations, DPMI applications 
  10117. behave exactly like any other standard DOS programs.  For example, they can run 
  10118. in the background or in a window, provided the environment supports these 
  10119. features.  Programs that run in protected mode gain all the benefits of virtual 
  10120. memory and can utilize a 32-bit flat memory model if desired. OS/2 Version 2.0 
  10121. provides a DPMI implementation of this nature. 
  10122.  
  10123. DPMI services accessed via INT 31h are only available to protected mode 
  10124. programs.  Programs running in real mode cannot use these services.  The only 
  10125. exception to this rule is the service which allows an application to enter 
  10126. protected mode, which must be called by real mode programs before calling any 
  10127. other DPMI service. 
  10128.  
  10129. Note that the majority of software vendors who released applications using the 
  10130. VCPI specification have since released versions which use DPMI instead, or have 
  10131. produced upgrades to their software to take advantage of DPMI. 
  10132.  
  10133.  
  10134. ΓòÉΓòÉΓòÉ 19.3.1. DPMI Hosts and Clients ΓòÉΓòÉΓòÉ
  10135.  
  10136. DPMI services are provided by a DPMI host program.  Programs which use DPMI 
  10137. services are known as DPMI clients.  Generally, DPMI clients fall into two 
  10138. categories: 
  10139.  
  10140.  1. Extended applications 
  10141.  
  10142.  2. Applications that use DPMI directly. 
  10143.  
  10144. Most DPMI applications are likely to be extended applications.  These 
  10145. applications are bound with a DOS extender, which is the actual DPMI client 
  10146. since it requests DPMI services on the application's behalf.  The application 
  10147. calls DOS extender services, which are then translated by the DOS extender into 
  10148. DPMI service calls.  The advantage of an extended application over one that 
  10149. calls DPMI services directly is that generally, an extender will support 
  10150. functions other than DPMI services.  In fact, it is recommended that extenders 
  10151. look for extension services in the following order: 
  10152.  
  10153.  1. DPMI 
  10154.  
  10155.  2. VCPI/EMS 
  10156.  
  10157.  3. XMS 
  10158.  
  10159.  4. Top-down (INT 15h). 
  10160.  
  10161. Extended memory may be allocated "top-down" by hooking the BIOS extended memory 
  10162. size system call (INT 15h, function 88h) and reporting less memory available 
  10163. than is actually present on the machine.  This method may be used by DOS 
  10164. extenders to allocate a contiguous block of memory starting at the top of 
  10165. extended memory and growing downward.  Since other applications querying the 
  10166. amount of memory available in the system will not be able to "see" this upper 
  10167. portion of memory, the memory is available solely to the DOS extender. 
  10168.  
  10169. A DPMI client can provide a single set of functions to an application, and then 
  10170. translate these functions to one or more underlying services (for example, 
  10171. DPMI, EMS, and/or XMS) provided by the client.  Where the corresponding host's 
  10172. services are lacking in a particular function, the extender must itself provide 
  10173. that function for the application.  This is illustrated in Figure 
  10174. "Client/Server Structure for Operating System Extenders". 
  10175.  
  10176. As shown in Figure "Client/Server Structure for Operating System Extenders", 
  10177. application code directly accesses a set of base extender functions.  The 
  10178. extender then has separate modules for each type of extension service, and 
  10179. itself contains code to provide functions in which the underlying service 
  10180. layers are lacking. 
  10181.  
  10182. Readers should refer to the DPMI 1.0 Specification published by the DPMI 
  10183. committee for information concerning the external interfaces available to DPMI 
  10184. applications.  Copies of the specification may be obtained by contacting Intel 
  10185. Literature Sales, P.O. Box 58130, Santa Clara, CA 95052. 
  10186.  
  10187.  
  10188. ΓòÉΓòÉΓòÉ 19.3.2. DPMI Services ΓòÉΓòÉΓòÉ
  10189.  
  10190. The following is a brief outline of the DPMI services.  For details regarding 
  10191. invocation of DPMI services from an application via INT 31h, please refer to 
  10192. the DPMI 0.9 Specification. 
  10193.  
  10194. DPMI provides six main classes of services: 
  10195.  
  10196.  Local Descriptor Table management 
  10197.  
  10198.  Memory management 
  10199.  
  10200.  Page management 
  10201.  
  10202.  Interrupt management 
  10203.  
  10204.  Translation 
  10205.  
  10206.  Debug watchpoint. 
  10207.  
  10208. Each of these services is briefly described in the following sections. 
  10209.  
  10210. Note that DPMI services are normally never called by an application program 
  10211. itself, but are intended to be used by DOS extenders which request DPMI 
  10212. services on an application's behalf. 
  10213.  
  10214. LDT Descriptor Management Services 
  10215.  
  10216. The LDT descriptor management service provides interfaces for allocating, 
  10217. freeing, and creating protected mode descriptors in the current task's Local 
  10218. Descriptor Table (LDT).  Access to the Global Descriptor Table is not provided, 
  10219. so that the DPMI server can protect itself from protected mode applications and 
  10220. isolate these applications from one another. 
  10221.  
  10222. DOS Memory Management Services 
  10223.  
  10224. The DOS memory management services provided an interface from protected mode 
  10225. applications to real mode INT 21h functions which are used to allocate, free 
  10226. and resize memory blocks.  These services allow a protected mode applications 
  10227. to use memory below 640KB, to exchange data with DOS, ROM BIOS device drivers, 
  10228. TSRs and other real mode programs which are incapable of accessing data in 
  10229. extended memory. 
  10230.  
  10231. Extended Memory Management Services 
  10232.  
  10233. The extended memory management services are used to allocate, free and resize 
  10234. memory blocks above the 1MB boundary.  If the DPMI server is an 80386 or 80486 
  10235. control program and paging is enabled, the extended memory blocks are always 
  10236. allocated in units of 4KB. 
  10237.  
  10238. Page Management Services 
  10239.  
  10240. Under DPMI implementations which support virtual memory, applications may 
  10241. discard memory blocks or may not access them for long periods of time, in which 
  10242. case the memory block's contents may be swapped out to disk.  In certain 
  10243. circumstances, such as interrupt handling code, this swapping must be disabled 
  10244. and the appropriate pages locked in physical memory.  The page management 
  10245. services allow pages to be individually locked or unlocked. 
  10246.  
  10247. Interrupt Management Services 
  10248.  
  10249. These services allow protected mode applications to intercept real and 
  10250. protected mode interrupts and hook processor exceptions.  Certain services 
  10251. allow a protected mode program to intercept hardware or software interrupts 
  10252. which occur in real mode or protected mode, or to install handlers for 
  10253. processor exceptions.  Other interrupt services permit a process to enable or 
  10254. disable its own servicing or hardware interrupts without affecting the 
  10255. interrupt status of the entire system.  DPMI accomplishes this by maintaining a 
  10256. virtual interrupt flag on a per-process basis. 
  10257.  
  10258. Translation Services 
  10259.  
  10260. The translation services permit control to be passed between operating modes. 
  10261. A protected mode program may transfer control to a real mode routine using a 
  10262. simulated far call or a simulated interrupt.  Translation services also allow a 
  10263. protected mode program to declare a real mode callback, or entry point which 
  10264. can be invoked by the a real mode program. 
  10265.  
  10266. Debug Watchpoint Services 
  10267.  
  10268. The 80386 processor supports special registers that are used for debugging. 
  10269. Since the instructions to modify these registers can only be executed by code 
  10270. running at privilege level zero, protected mode debugging tools running in DPMI 
  10271. environments cannot modify the registers directly.  These services provide 
  10272. mechanisms for setting and clearing debug watchpoints and detecting when a 
  10273. watchpoint has caused a fault. 
  10274.  
  10275.  
  10276. ΓòÉΓòÉΓòÉ 19.4. DOS Extenders ΓòÉΓòÉΓòÉ
  10277.  
  10278. Programs which use DPMI services are normally bound to DOS extenders, in order 
  10279. to run under any DOS environment.  Most DOS extenders provide an interface to 
  10280. applications using an INT 21h multiplex.  For functions which utilize DPMI 
  10281. services, the DOS extender then makes the appropriate INT 31h request. 
  10282.  
  10283. Extenders that support DPMI will need to initialize differently when they are 
  10284. run under DPMI environments.  They will need to enter protected mode using the 
  10285. DPMI real to protected mode entry point, install their own API handlers, and 
  10286. then load the DOS extended application program. 
  10287.  
  10288. DOS extenders should check for the presence of DPMI before attempting to 
  10289. allocate memory or enter protected mode using any other API.  When DPMI 
  10290. services are detected, extenders that provide interfaces that extend or are 
  10291. different from the basic DPMI interface will switch into protected mode and 
  10292. initialize any internal data structures.  DPMI-compatible extenders that 
  10293. provide no API extensions should simply execute the protected mode application 
  10294. in real mode. 
  10295.  
  10296.  
  10297. ΓòÉΓòÉΓòÉ 19.4.1. Loading DPMI Clients and Extended Applications ΓòÉΓòÉΓòÉ
  10298.  
  10299. All DPMI applications begin execution in real mode.  An application must run 
  10300. first as a real mode DOS program, but can then switch to protected mode by 
  10301. making a call to DPMI (or to a DOS extender).  Once in protected mode, all INT 
  10302. 31h calls supported by DPMI may be issued by the application or its associated 
  10303. DOS extender functions. 
  10304.  
  10305. A DOS extender and its application under DPMI are loaded and initialized as 
  10306. described below.  The DOS extender: 
  10307.  
  10308.  1. Loads in real mode (or V86 mode on an 80386/80486 machine). 
  10309.  
  10310.  2. Checks for presence of a DPMI server. 
  10311.  
  10312.  3. Switches the CPU from real mode to protected mode, and loads registers with 
  10313.     the appropriate selectors. 
  10314.  
  10315.     If no DPMI server is present, the DOS extender checks for the existence of 
  10316.     a VCPI server or XMS device driver before assuming total control of the 
  10317.     CPU's execution mode, privileged control registers, and memory management 
  10318.     hardware. 
  10319.  
  10320.  4. Uses DPMI services to build the protected mode environment to be used by 
  10321.     the application. 
  10322.  
  10323.  5. Allocates extended memory segments to hold the application's code, data, 
  10324.     and stacks. 
  10325.  
  10326.  6. Allocates selectors to be used by the application to execute in and/or 
  10327.     address the memory segments. 
  10328.  
  10329.  7. Reads the application's code and data from disk into the segments. 
  10330.  
  10331.     The DOS extender can mark pageable memory it uses below 640KB so as to 
  10332.     reduce the demand for physical memory. 
  10333.  
  10334.  8. Installs its own handlers for any software interrupts (such as DOS INT 21h) 
  10335.     that the application will execute. 
  10336.  
  10337. Control is then passed to the application. 
  10338.  
  10339.  
  10340. ΓòÉΓòÉΓòÉ 19.4.2. Processing in DOS Extenders ΓòÉΓòÉΓòÉ
  10341.  
  10342. The way in which a DOS extender processes interrupts varies.  Some INT 21h 
  10343. requests are passed directly to DOS.  The DOS extender simply switches to real 
  10344. mode, calls DOS, and then switches back to protected mode when DOS returns 
  10345. after completing the function.  File input and output, however, may demand that 
  10346. the DOS extender translate addresses, while other INT 21h functions such as DOS 
  10347. memory management must be replaced entirely by the DOS extender. 
  10348.  
  10349. Unless the A20 address line has been explicitly enabled through the XMS 
  10350. interface, it cannot be assumed that memory from 1MB to 1MB+64KB-16 (the High 
  10351. Memory Area) is addressable once a program is running protected mode. If HMA is 
  10352. to be accessed, the A20 address line must be enabled through XMS before 
  10353. entering protected mode.  XMS calls are not supported in protected mode. 
  10354.  
  10355. This restriction is only important for software that wishes to access the HMA. 
  10356. Under all implementations of DPMI, the physical A20 address line will always be 
  10357. enabled while executing protected mode code.  However, some 80386 specific DPMI 
  10358. implementations simulate 1MB address wrap for compatibility reasons.  Under 
  10359. these DPMI implementations, the HMA will not be accessible unless the A20 
  10360. address line is enabled through the XMS interface.  This is the case under OS/2 
  10361. Version 2.0. 
  10362.  
  10363.  
  10364. ΓòÉΓòÉΓòÉ 19.4.3. Session Termination ΓòÉΓòÉΓòÉ
  10365.  
  10366. When the DOS extender or its application issue the DOS terminate interrupt, 
  10367. DPMI traps the interrupt and releases all of the application's protected mode 
  10368. resources.  The DPMI server passes the interrupt to real mode so as to permit 
  10369. DOS to clean up the program's real mode resources, including file and device 
  10370. handles and any memory blocks below 640KB. 
  10371.  
  10372.  
  10373. ΓòÉΓòÉΓòÉ 19.5. DPMI Implementation in OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  10374.  
  10375. OS/2 Version 2.0 provides DPMI services to applications running in VDMs.  The 
  10376. DPMI Version 0.9 specification is fully supported, and the architecture of the 
  10377. DPMI implementation is such that both the API functions and the underlying 
  10378. services are independently expandable to cope with future versions of DPMI. 
  10379.  
  10380. DPMI support under OS/2 Version 2.0 is divided into three components: 
  10381.  
  10382.  The DPMI API is implemented using the DPMI API Layer, a virtual device driver 
  10383.   which services INT 31h requests from applications. 
  10384.  
  10385.  The operating system kernel provides support for the DPMI VDD and the Virtual 
  10386.   Programmable Interrupt Controller (VPIC). 
  10387.  
  10388.  Protected mode hardware interrupts are routed via the VPIC. 
  10389.  
  10390. DPMI is service request driven.  An application first makes an INT 31H service 
  10391. request, which is handled by the DPMI VDD, calling the kernel for basic 
  10392. services such as allocating memory. 
  10393.  
  10394.  
  10395. ΓòÉΓòÉΓòÉ 19.5.1. DPMI Services ΓòÉΓòÉΓòÉ
  10396.  
  10397. DPMI services are requested using INT 31h requests, which are trapped by the 
  10398. DPMI virtual device driver, and either serviced by the VDD itself or routed to 
  10399. the operating system kernel. 
  10400.  
  10401. The DPMI API Layer performs input parameter checking on all service requests, 
  10402. to validate requests and to enforce restrictions mandated by the DPMI 
  10403. specification. 
  10404.  
  10405. LDT Descriptor Management 
  10406.  
  10407. The 8086 Emulation component of MVDM arranges for allocation of a task's LDT 
  10408. upon initialization of the VDM.  Under DPMI 0.9, all tasks in a VDM share the 
  10409. same LDT.  Applications may modify descriptors only through DPMI service calls. 
  10410.  
  10411. Three types of descriptors must be kept track of: 
  10412.  
  10413.  1. Per-task DPMI descriptors that the client may modify 
  10414.  2. V86 segment to selector mappings with descriptors that cannot be modified 
  10415.  3. Per-task DOS descriptors that the client cannot modify. 
  10416.  
  10417. Memory used by a DPMI application is allocated by the OS/2 Version 2.0 
  10418. operating system to the parent process of the VDM within which that application 
  10419. executes.  Full memory protection is therefore provided for applications using 
  10420. DPMI services. 
  10421.  
  10422. DOS Memory Management 
  10423.  
  10424. DOS memory management services are implemented under OS/2 Version 2.0 in 
  10425. various ways, according to the nature of the service. 
  10426.  
  10427.  Allocate DOS memory and selector set 
  10428.  
  10429.   This service allocates DOS memory along with a set of descriptors to cover 
  10430.   the allocation.  For 32-bit clients, a single descriptor is set to cover the 
  10431.   entire allocated region.  For 16-bit clients, this descriptor is followed by 
  10432.   descriptors to cover the rest of the region in 64KB segments.  This allows 
  10433.   16-bit applications to refer either through a single large segment or through 
  10434.   tiled selectors. 
  10435.  
  10436.   A V86 mode DOS call is used to allocate memory from the DOS arena. Therefore, 
  10437.   after initial setup, the DPMI API Layer switches back into V86 mode to issue 
  10438.   the DOS call, and then traps the return from DOS in order to finish the 
  10439.   service. 
  10440.  
  10441.  Free DOS memory and selector set 
  10442.  
  10443.   The allocated list is searched to make sure the region being freed is 
  10444.   allocated.  The allocation record is moved to the pending list with the 
  10445.   request marked as free.  A switch is then made to V86 mode and the INT 21h is 
  10446.   simulated as above with the return trapped.  When the return is trapped, 
  10447.   return values are set up.  If the call succeeded, the selectors that were 
  10448.   allocated are freed.  If a selector other than the allocated selector was 
  10449.   passed in the free call, that selector set is freed as well. 
  10450.  
  10451.  Resize DOS memory and selector set 
  10452.  
  10453.   Resizing is done in the same way as the original allocation.  The allocation 
  10454.   record is moved to the pending list.  The desired size is listed in the 
  10455.   allocation record and new selectors are allocated if the size increases and 
  10456.   new selectors are needed.  Descriptors are allocated before reflection so the 
  10457.   call can fail before allocating DOS memory in V86 mode if they are not 
  10458.   available.  The DOS call is then done as above. 
  10459.  
  10460.   If the call failed, the new selectors are freed when the hook regains 
  10461.   control.  If it succeeded, new descriptors are set up if they were needed or 
  10462.   descriptors are freed if the resize made some unnecessary. The return values 
  10463.   for the client are set up and the allocation record is returned to the 
  10464.   allocated list with its new size noted. 
  10465.  
  10466. Extended Memory Management 
  10467.  
  10468. Extended memory management services are also implemented in a number of ways, 
  10469. depending on the service. 
  10470.  
  10471.  Get memory information 
  10472.  
  10473.   This service uses memory management calls to load an application buffer with 
  10474.   a variety of information about the memory.  A VDH service is used to copy the 
  10475.   data to user space, with appropriate exception handling. 
  10476.  
  10477.  Allocate 
  10478.  
  10479.   Memory is allocated using a memory management service.  Record of the 
  10480.   allocation noting the start address, allocated size, and sparse linear 
  10481.   address size are kept in a hash table.  The allocation records are kept in 
  10482.   the DPMI API Layer per DPMI task area so that they can be cleaned up when the 
  10483.   task terminates. 
  10484.  
  10485.  Free 
  10486.  
  10487.   This function is implemented quite simply; the DPMI API Layer per-task data 
  10488.   area is checked for the allocation records, and the corresponding memory is 
  10489.   freed via a call to the operating system kernel. 
  10490.  
  10491.  Resize 
  10492.  
  10493.   DPMI changes a memory object's size in one of two ways: 
  10494.  
  10495.    - If the size of the object is to be decreased, pages at the end of the 
  10496.      object are decommitted. 
  10497.    - If the size of the object is to be increased, a new and larger object is 
  10498.      allocated and a kernel worker is used to move the pages from the original 
  10499.      object to the new one. 
  10500.  
  10501. Page Locking 
  10502.  
  10503. Page locking services are necessary on systems which deliver interrupts at 
  10504. interrupt time or which use DOS for paging.  On a system that simulates 
  10505. interrupts and has its own file system (such as OS/2 Version 2.0)  the calls 
  10506. are no-ops.  They will simply return a success indication to the client. 
  10507.  
  10508. Interrupt Hooking 
  10509.  
  10510. 8086 Emulation maintains a table of the current handler for each protect mode 
  10511. hook and exception.  These services are implemented by calling 8086 Emulation 
  10512. to get the current value from this table or to set a new value in the table. 
  10513.  
  10514. 8086 Emulation offers a service to change the client's virtual interrupt state 
  10515. (the IF flag). 
  10516.  
  10517. Translation (Protect/V86 Control Transfer) 
  10518.  
  10519. These services provide cross-mode calls, state saving, and raw mode switching. 
  10520.  
  10521.  Real mode callback (call protected mode from real mode) 
  10522.  
  10523.   This service allocates a real mode callback breakpoint.  When this breakpoint 
  10524.   is called, the DPMI API Layer handler arranges a protect mode call. 
  10525.  
  10526.  Free real mode callback 
  10527.  
  10528.   If a real mode callback is still waiting to be completed, the callback record 
  10529.   is marked to indicate it is no longer active.  Freeing the callback record 
  10530.   and the breakpoint are done when no outstanding calls are in progress. 
  10531.  
  10532.  State save/restore for each mode 
  10533.  
  10534.   This service returns a set of addresses, one for V86 mode and one for protect 
  10535.   mode, which, if called by the client, save or restore the current register 
  10536.   state for the other mode.  This is necessary for applications which perform 
  10537.   raw mode switching, to keep them from overwriting the task state for the 
  10538.   alternate mode. 
  10539.  
  10540.  Raw mode switching 
  10541.  
  10542.   This service returns a set of addresses, one for V86 mode and one for protect 
  10543.   mode, which, if called by the client, switch to the other mode. The 
  10544.   breakpoints have the DPMI task identifier in the breakpoint data area.  When 
  10545.   the breakpoint is reached, if the ID is different from the current one, 8086 
  10546.   Emulation is called to report the switch.  A VDH service is then used to do 
  10547.   the requested mode switch. 
  10548.  
  10549. Under OS/2 Version 2.0, an extension to the DPMI specification has been 
  10550. implemented, and is known as DOS API services.  Protected mode applications 
  10551. issuing DOS or BIOS calls must pass buffers that can be accessed in V86 mode. 
  10552. The DOS API services relieve the application from having to do this work for 
  10553. DOS calls and some BIOS calls.  This permits protected mode applications to use 
  10554. protect mode buffers (referenced by protected mode selectors) in DOS service 
  10555. requests.  The translation services perform any necessary buffer copying. 
  10556.  
  10557. Applications detect the presence of a DOS API translator by performing an INT 
  10558. 2Fh multiplex passing the name "MS-DOS" as an argument.  The translator 
  10559. responds when it detects this name, indicating that translation will be 
  10560. performed.  Applications that do not require translation may simply use the INT 
  10561. 31h simulate interrupt function to avoid translation. 
  10562.  
  10563. Debug Registers 
  10564.  
  10565. The Task Management component of OS/2 Version 2.0 manages watchpoints for OS/2 
  10566. applications, the kernel debugger and VDMs.  Interfaces for allocating, setting 
  10567. and freeing watchpoints and getting the Bx bits for allocated watchpoints are 
  10568. used by the DPMI API Layer to carry out these services.  The DPMI API Layer 
  10569. keeps track of allocated watchpoints in the per DPMI task area so that it can 
  10570. clean up at termination and uses the tasking watchpoint services to manipulate 
  10571. watchpoints. 
  10572.  
  10573. Other DPMI Services 
  10574.  
  10575. A number of other services are provided under the DPMI specification. Their 
  10576. implementation under OS/2 Version 2.0 is described below. 
  10577.  
  10578.  Physical Address Mapping 
  10579.  
  10580.   In OS/2 Version 2.0, there is no way of knowing which addresses are used by 
  10581.   device drivers.  It is therefore not safe to allow direct access to devices 
  10582.   which do not have VDDs.  However, direct access from within VDMs is allowed. 
  10583.  
  10584.   VDH services for reserving linear space, mapping, and page fault handling are 
  10585.   all restricted to regions below 1MB+64KB.  As such, a VDD with a linear 
  10586.   address above 1 MB cannot virtualize hardware.  All requests to this service 
  10587.   will fail.  The DPMI specification allows this so the operating system can 
  10588.   protect devices. 
  10589.  
  10590.  Get Vendor Specific Entry Point 
  10591.  
  10592.   Vendors that add extensions to DPMI typically look for the name of their 
  10593.   extension by hooking INT 31h.  If the extension is requested by a DPMI 
  10594.   client, the vendor-supplied routine issues an IRET instruction without 
  10595.   jumping down the INT 31h protect mode chain.  If the request is for a DPMI 
  10596.   service not supplied by the vendor's routine , the routine continues down the 
  10597.   INT 31h chain.  Since the DPMI API Layer router is called at the end of the 
  10598.   chain, any unrecognized service requests are signalled to the client by 
  10599.   setting the carry flag to indicate that the call failed. 
  10600.  
  10601.  
  10602. ΓòÉΓòÉΓòÉ 19.5.2. Kernel Support ΓòÉΓòÉΓòÉ
  10603.  
  10604. As well as providing support for DPMI service requests issued by applications, 
  10605. the operating system must also provide support for the internal control 
  10606. functions of the DPMI host.  This support is provided by various components of 
  10607. the operating system kernel. 
  10608.  
  10609. 8086 Emulation 
  10610.  
  10611. The 8086 Emulation component of MVDM emulates the 8086 hardware environment, 
  10612. and therefore provides a number of services which are used by DPMI. 
  10613.  
  10614.  DPMI task entry, termination, mode tracking, control 
  10615.  
  10616.   When the application calls the protect mode entry to switch to protected 
  10617.   mode, 8086 Emulation sets up tables for reflection of interrupts and 
  10618.   exceptions.  If the DPMI API Layer fails to complete the creation call, 8086 
  10619.   Emulation cleans up and returns the error to the application. 
  10620.  
  10621.  VDH service support 
  10622.  
  10623.   All support for VDH services to the DPMI API Layer is provided through 8086 
  10624.   Emulation. 
  10625.  
  10626.  Get/set support for protected mode handler interrupt and exception handlers. 
  10627.  
  10628.   Protected mode applications get and set vectors as in DOS.  8086 Emulation 
  10629.   maintains tables of protected mode interrupt handlers and exception handlers. 
  10630.  
  10631.  Interrupt and exception reflection to protected mode 
  10632.  
  10633.   8086 Emulation virtualizes interrupts for VDMs.  The reflection of "real 
  10634.   mode" interrupts to protected mode for DPMI applications is therefore 
  10635.   performed with the aid of 8086 Emulation. 
  10636.  
  10637.  Protected mode interrupt flag virtualization 
  10638.  
  10639.   8086 Emulation virtualizes the IF flag while in protected mode.  In V86 mode, 
  10640.   IOPL is usually 3 and applications directly change IF without trapping.  IF 
  10641.   flag virtualization is not done while in V86 mode because IOPL must be 3 to 
  10642.   cut down on overhead.  In protected mode, IOPL cannot be 3; otherwise no port 
  10643.   protection is possible.  Therefore, the IF flag is virtualized.  This 
  10644.   prevents VDMs from blocking real interrupts when running in protected mode. 
  10645.  
  10646.   To determine if interrupts are allowed in a VDM that has a DPMI application 
  10647.   running, the real IF bit in the CRF is checked.  If interrupts are disabled 
  10648.   here, then they are disabled.  Otherwise, the virtual IF flag indicates 
  10649.   whether interrupts are disabled. 
  10650.  
  10651.  HW interrupt support for the Virtual Programmable Interrupt Controller 
  10652.  
  10653.   8086 Emulation exports a VDH service to accept notification from the VPIC 
  10654.   when it starts and stops hardware interrupt reflection.  8086 Emulation also 
  10655.   tracks which hardware interrupts are hooked.  The VPIC allocates and 
  10656.   initializes the buffer at creation time in each VDM. 
  10657.  
  10658.   Any VDD can use this structure to determine if a particular IRQ is hooked. 
  10659.   The timer VDD, for example, can use this to avoid delivering timer ticks when 
  10660.   the timer tick interrupts are not hooked in either protected mode or in V86 
  10661.   mode. 
  10662.  
  10663.   When software interrupts are hooked, 8086 Emulation refers to this structure 
  10664.   to determine if the interrupt is a hardware interrupt. 
  10665.  
  10666.  Services to read/write user space with exception handling 
  10667.  
  10668.  Kernel and VDH service changes for exception handling when accessing user 
  10669.   address space. 
  10670.  
  10671.   Services called when the client is in protected mode, and which manipulate 
  10672.   the protected mode client address space, must be written to handle protected 
  10673.   mode user space access exceptions.  Services that cannot be called when the 
  10674.   client is in protected mode must specify this in their headers. 
  10675.  
  10676.   When a service can fault in protected mode, it must return a failure 
  10677.   indication to the DPMI client.  The client then cleans up and exits protected 
  10678.   mode so that the exception can be reflected to the VDM (in V86 mode). This 
  10679.   error also indicates whether a protected mode exception handler will be 
  10680.   called. 
  10681.  
  10682. Debug Watchpoint Management 
  10683.  
  10684. Coordinates watchpoint use with OS/2 protected mode and kernel debugger. 
  10685.  
  10686. Memory Management 
  10687.  
  10688. Among the kernel services provided by the Virtual Memory Manager are: 
  10689.  
  10690.  Allocate VDM LDT 
  10691.  
  10692.  Free VDM LDT 
  10693.  
  10694.  Allocate contiguous set of LDT descriptors 
  10695.  
  10696.  Free descriptor 
  10697.  
  10698.  Query maximum private linear address and ranges of physical memory 
  10699.  
  10700.  Query maximum linear region and swap space available 
  10701.  
  10702.  Other memory management services generally used by the kernel, such as 
  10703.   services to allocate, free, and set sparse allocations, are also used. 
  10704.  
  10705. Once descriptors are allocated they are changed directly by the DPMI API layer. 
  10706. Applications set descriptors only through requests to the DPMI API layer, which 
  10707. prevents settings that compromise protection. 
  10708.  
  10709.  
  10710. ΓòÉΓòÉΓòÉ 19.5.3. Ring 0 Exceptions ΓòÉΓòÉΓòÉ
  10711.  
  10712. All VDM linear addresses below 1MB + 64KB can be accessed by Ring 0 code (such 
  10713. as 8086 Emulation or DOS Emulation), without any exceptions being visible to 
  10714. the V86 mode application.  This meant that there was no need to recover from 
  10715. faults at ring 0 when VDM  applications ran only in V86 mode. 
  10716.  
  10717. DPMI protected mode applications, however, do have addresses in their address 
  10718. space that can cause visible exceptions at ring 0.  Most virtual device drivers 
  10719. are not affected because they never execute while the client is in protected 
  10720. mode.  VDDs are affected only if both of the following conditions are true: 
  10721.  
  10722.  The VDD runs while the client is in protected mode. 
  10723.  
  10724.  The VDD accesses the client address space above 1MB + 64KB or using client 
  10725.   selectors while the client is in protected mode.  This can happen indirectly 
  10726.   if a VDH service is called which manipulates the client's protected mode 
  10727.   stack. 
  10728.  
  10729. In such cases, the virtual device driver must include handlers for the 
  10730. exceptions. 
  10731.  
  10732.  
  10733. ΓòÉΓòÉΓòÉ 19.5.4. DPMI API Layer Communication with the Kernel ΓòÉΓòÉΓòÉ
  10734.  
  10735. The DPMI API Layer has a small, well defined interface with the kernel.  At 
  10736. system initialization time, the DPMI API Layer is registered with the kernel 
  10737. through a VDH call and reports which version of DPMI it supports.  If the VDD 
  10738. supports only DPMI Version 0.9, the kernel (which supports DPMI Version 1.0) 
  10739. adjusts the way in which it handles certain DPMI tasks. 
  10740.  
  10741. Kernel services that may be useful to VDDs other than the DPMI API layer are 
  10742. exported as VDH services.  Services that should have use restricted only to the 
  10743. DPMI API layer are made available through structures exchanged when the DPMI 
  10744. API Layer virtual device driver is registered. 
  10745.  
  10746.  
  10747. ΓòÉΓòÉΓòÉ 19.5.5. Installation of DPMI ΓòÉΓòÉΓòÉ
  10748.  
  10749. The OS/2 Version 2.0 installation procedure copies the DPMI API Layer virtual 
  10750. device driver DPM.SYS into the \OS2\MDOS directory on the user's system.  If 
  10751. users decide to use selective install, they can choose any combination of EMM, 
  10752. XMS, or DPMI.  When they select any of these memory options, the appropriate 
  10753. DEVICE= statement is added to CONFIG.SYS.  The default memory statement in 
  10754. CONFIG.SYS is: 
  10755.  
  10756. DEVICE=C:\OS2\MDOS\VEMM.SYS
  10757.  
  10758. If the user does not select DPMI support at installation time and wishes to add 
  10759. it at a later time, CONFIG.SYS must be modified by adding the statement: 
  10760.  
  10761. DEVICE=C:\OS2\MDOS\VDPMI.SYS
  10762.  
  10763.  
  10764. ΓòÉΓòÉΓòÉ 19.5.6. DPMI and Microsoft Windows ΓòÉΓòÉΓòÉ
  10765.  
  10766. DPMI 0.9 support is necessary for Windows 3.0 to run applications in protected 
  10767. mode (that is, in Windows standard mode).  With DPMI implemented in Windows 
  10768. 3.0, Windows 3.0 applications (running in protected mode) are freed from the 
  10769. restrictive 640KB DOS address space. 
  10770.  
  10771. Windows 3.0 is not a standard DPMI client and cannot run under DPMI in a VDM 
  10772. without completely subverting the operating system's memory protection and 
  10773. thereby potentially compromising system integrity. 
  10774.  
  10775. Even with DPMI, Windows cannot run in 386 enhanced mode under OS/2 Version 2.0. 
  10776. The reason for this is that when Windows runs in enhanced mode it operates at 
  10777. Ring 0.  Running Windows in 386 enhanced mode would therefore require bypassing 
  10778. the operating system's protection mechanisms, and would potentially compromise 
  10779. the integrity of the system. 
  10780.  
  10781.  
  10782. ΓòÉΓòÉΓòÉ 19.6. Summary ΓòÉΓòÉΓòÉ
  10783.  
  10784. Applications which experience memory constraints under DOS may overcome many of 
  10785. the inherent limitations of real mode by running protected mode. However, an 
  10786. application running in protected mode cannot easily access the facilities of 
  10787. real mode software such as the DOS operating system or TSR programs.  DPMI 
  10788. provides an interface which allows an application to execute in protected mode, 
  10789. and to make DOS requests through DPMI.  All mode switching and address 
  10790. conversion is handled by DPMI on the application's behalf. 
  10791.  
  10792. DPMI resolves problems relating to device virtualization, intertask protection, 
  10793. and demand paging that occur when multiple protected mode DOS extender 
  10794. applications are run in a multitasking environment, in conjunction with memory 
  10795. managers and control programs. 
  10796.  
  10797. DPMI is implemented under OS/2 Version 2.0 using a combination of virtual 
  10798. device driver services and kernel services to provide DPMI functions to client 
  10799. applications.  The provision of these functions allows applications written to 
  10800. use DPMI services, such as applications which run under Microsoft Windows in 
  10801. standard mode, to run in a VDM under OS/2 Version 2.0. 
  10802.  
  10803.  
  10804. ΓòÉΓòÉΓòÉ 20. Running DOS Applications ΓòÉΓòÉΓòÉ
  10805.  
  10806. OS/2 Version 2.0 allows the user to run multiple DOS applications concurrently, 
  10807. with each application running in its own virtual DOS machine, with pre-emptive 
  10808. multitasking and full memory protection. 
  10809.  
  10810. This chapter describes the way in which a DOS application can be defined to the 
  10811. OS/2 Version 2.0 Workplace Shell, and the ways in which an application may be 
  10812. started. It also discusses the way in which version-specific DOS applications 
  10813. may be run in virtual DOS machines under OS/2 Version 2.0. 
  10814.  
  10815.  
  10816. ΓòÉΓòÉΓòÉ 20.1. Defining a DOS Application ΓòÉΓòÉΓòÉ
  10817.  
  10818. A DOS application is typically defined to the Workplace Shell by creating a 
  10819. representative object for the application, and configuring the properties of 
  10820. that object using the settings view.  Configuring an object in this way allows 
  10821. the application to take advantage of the many customizable properties of the 
  10822. OS/2 Version 2.0 VDM  environment, and to tailor this environment to provide 
  10823. optimum performance and application compatibility. 
  10824.  
  10825.  
  10826. ΓòÉΓòÉΓòÉ 20.1.1. Creating a Representative Object ΓòÉΓòÉΓòÉ
  10827.  
  10828. To define a DOS application as an object under the Workplace Shell, do the 
  10829. following: 
  10830.  
  10831.  1. Open the Templates folder on the desktop, and copy the Program object by 
  10832.     pointing to it with the mouse pointer, holding down mouse button 2 and 
  10833.     dragging the icon to the desktop or to the folder in which the DOS 
  10834.     application will reside. 
  10835.  
  10836.  2. The settings view for the new object will automatically open. On the 
  10837.     Program page of the settings notebook, complete the Program title and Path 
  10838.     and file name fields for the application. The Parameters and Working 
  10839.     directory fields are optional, and depend on the application being 
  10840.     installed. Users should check the documentation supplied with the DOS 
  10841.     application. 
  10842.  
  10843.     Figure "The Program Page of the Settings Notebook" 
  10844.  
  10845.  3. On the Session page, select either DOS Window or DOS Full Screen, depending 
  10846.     on how the DOS application will be run.  In most cases, it is sufficient to 
  10847.     select DOS Window since when maximized, the window will allow the full 25 
  10848.     rows by 80 columns to be displayed. 
  10849.  
  10850.     Another advantage of selecting DOS Window is that the user can use the copy 
  10851.     and paste functions of the VDM to selectively transfer data between the DOS 
  10852.     application, the clipboard, and any other application on the desktop that 
  10853.     supports the clipboard. However, some graphics applications suffer 
  10854.     performance degradation when run in windowed mode. For such applications, 
  10855.     DOS Full Screen should be selected. 
  10856.  
  10857.     Note that once the VDM is started, a user can switch between DOS Window and 
  10858.     DOS Full Screen modes by holding down the Alt key and pressing the Home 
  10859.     key. 
  10860.  
  10861.     Do not confuse running a DOS application full screen with running it in a 
  10862.     full screen window (a maximized window that fills the entire screen). There 
  10863.     can be a significant performance difference between the two. 
  10864.  
  10865.     Note that clipboard function Copy All is also available for full screen 
  10866.     virtual DOS machines. This allows the user to copy the entire DOS full 
  10867.     screen to the clipboard (there is no way to mark only a portion of the 
  10868.     screen). To perform this function, the user must press Ctrl+Esc to return 
  10869.     to the desktop, click on the application icon with mouse button 2, and 
  10870.     select Copy All. 
  10871.  
  10872.  4. On the General page, complete the Title field. The user can optionally 
  10873.     choose to display a different icon from the default DOS Window or DOS Full 
  10874.     Screen icons. 
  10875.  
  10876.     Figure "The Session Page of the Settings Notebook" 
  10877.  
  10878.  5. If you select the DOS settings push button, the system brings up another 
  10879.     dialog. In this dialog, you can setup all DOS/VDM relevant characteristics, 
  10880.     unique to this particular program object. 
  10881.  
  10882.     Figure "The DOS Settings Dialog of the Settings Notebook" 
  10883.  
  10884. When the settings notebook is closed, the application will appear on the 
  10885. desktop or in the folder, with the specified application name beneath its icon. 
  10886.  
  10887.  
  10888. ΓòÉΓòÉΓòÉ 20.1.2. Adding TSRs to the Workplace Shell ΓòÉΓòÉΓòÉ
  10889.  
  10890. TSRs (Terminate-and-Stay-Resident) are DOS programs that stay resident in 
  10891. memory after terminating. This allows another DOS application to be loaded, 
  10892. while the TSR can still be accessed by a software or hardware interrupt, such 
  10893. as a hot-key sequence. An example is the dial-up terminal emulator FTTERM. 
  10894.  
  10895. A TSR will not work if it is added to the Workplace Shell using the steps in 
  10896. the previous section. The virtual DOS machine closes when it detects the TSR 
  10897. terminating and gives it no chance to become resident. 
  10898.  
  10899. Figure "Setting Up a TSR Program" 
  10900.  
  10901. To add a TSR to the Workplace Shell, do the following: 
  10902.  
  10903.  1. Open the Templates folder on the desktop, and copy the Program object to 
  10904.     the desktop or the required folder. 
  10905.  
  10906.  2. On the Program page of the settings notebook, complete the Program title 
  10907.     field with an asterisk ("*"). 
  10908.  
  10909.  3. Fill in the Parameters field with a "/k" followed by the path and program 
  10910.     name of the TSR. 
  10911.  
  10912.  4. Complete the Session and General pages of the settings notebook as for 
  10913.     other DOS applications. 
  10914.  
  10915.  
  10916. ΓòÉΓòÉΓòÉ 20.1.3. Customizing the VDM Environment ΓòÉΓòÉΓòÉ
  10917.  
  10918. The OS/2 Version 2.0 virtual DOS machine environment may be extensively 
  10919. customized to suit the requirements of a particular DOS application.  Such 
  10920. properties as DOS device drivers, EMS/XMS memory configurations, and even the 
  10921. interface to hardware facilities can be specified individually for each VDM. 
  10922.  
  10923. This customization is achieved using the DOS Settings facility, which is 
  10924. accessed by pressing the DOS settings pushbutton on the Session  page of the 
  10925. settings notebook. 
  10926.  
  10927. The DOS Settings facility and the available settings are described in detail in 
  10928. DOS Settings. 
  10929.  
  10930.  
  10931. ΓòÉΓòÉΓòÉ 20.1.4. Using the Migrating Applications Facility ΓòÉΓòÉΓòÉ
  10932.  
  10933. Many common DOS applications can be set up on the Workplace Shell with their 
  10934. virtual DOS machine customized automatically by using the Migrate Applications 
  10935. facility of the Systems Setup. There is a file in the \OS2\INSTALL subdirectory 
  10936. called DATABASE.DAT that contains information on commonly available DOS, 
  10937. Windows V3.0 and OS/2 Version 1.3 applications. For DOS and Windows V3.0 
  10938. applications this file includes the recommended DOS settings for the virtual 
  10939. DOS machine setup for that application. 
  10940.  
  10941. After installing the DOS application, start the Migrate Applicationsfacility 
  10942. and follow the dialog boxes to select the DOS application. If the migration is 
  10943. successful, an icon will be created for the application in a folder called DOS 
  10944. Applications. 
  10945.  
  10946. Refer to Installing and Migrating Applications on using the Migrate 
  10947. Applications program. 
  10948.  
  10949.  
  10950. ΓòÉΓòÉΓòÉ 20.2. Starting a DOS Application ΓòÉΓòÉΓòÉ
  10951.  
  10952. A DOS application can be started in a virtual DOS machine by a user in one of 
  10953. several ways: 
  10954.  
  10955.  By double-clicking mouse button 1 on the application's representative object 
  10956.   on the desktop or in a folder 
  10957.  
  10958.  By starting the application from an OS/2 or DOS command line 
  10959.  
  10960.  By running an OS/2 batch file containing the Start command with the 
  10961.   appropriate switches 
  10962.  
  10963. Note that an OS/2 application may also start a DOS application by issuing a 
  10964. DosExecPgm() function call. The DOS application can be started as a dependent 
  10965. or independent child process of the OS/2 application. 
  10966.  
  10967. There are certain limitations to starting DOS programs from an OS/2 V2.0 
  10968. command prompt. For example, neither output redirection (using the ">" 
  10969. character) nor piping (using the "|" character) works as it would from a DOS 
  10970. command prompt. When starting a DOS application from the OS/2 command prompt, 
  10971. OS/2 Version 2.0 calls the DOS command processor (COMMAND.COM), which then 
  10972. receives the application's name and parameters and starts it. The OS/2 V2.0 
  10973. command processor does not start the application itself but transfers all 
  10974. control to the DOS COMMAND.COM. When we use redirection or piping from the OS/2 
  10975. command prompt, it is only effective for the OS/2 session. Since OS/2 starts 
  10976. COMMAND.COM, and not the DOS application itself, OS/2 will only redirect the 
  10977. output of COMMAND.COM, not the application. 
  10978.  
  10979. Thus with a DOS program XYZ, neither: 
  10980.  
  10981. XYZ > DUMMY.FIL
  10982.  
  10983. nor: 
  10984.  
  10985. XYZ | more
  10986.  
  10987. would work from the OS/2 command prompt the way it does from a DOS command 
  10988. prompt. 
  10989.  
  10990. One solution to the above limitation is to put the redirection or piping 
  10991. statement into a DOS batch file and call the batch file instead. 
  10992.  
  10993.  
  10994. ΓòÉΓòÉΓòÉ 20.2.1. Starting From the Workplace Shell ΓòÉΓòÉΓòÉ
  10995.  
  10996. In order for an application to be started from within the Workplace Shell, it 
  10997. must first be defined and configured as described in Defining a DOS 
  10998. Application. Once this has been done, the application may be started simply by 
  10999. double-clicking mouse button 1 on the application's icon on the desktop or in a 
  11000. folder. 
  11001.  
  11002. Note that when the application is started, the background of the icon will 
  11003. change to indicate that the application is in use. By default, if the user 
  11004. double-clicks mouse button 1 on the icon a second time, the operating system 
  11005. will not start a second instance of the application, but will simply bring the 
  11006. already started instance to the foreground. 
  11007.  
  11008. If the user wishes to create a second instance of the application, a second 
  11009. representative object can be created by copying the original instance. 
  11010. Alternatively, the user can change the default behavior in the Window page of 
  11011. the settings notebook. 
  11012.  
  11013.  
  11014. ΓòÉΓòÉΓòÉ 20.2.2. Starting From the Command Line ΓòÉΓòÉΓòÉ
  11015.  
  11016. A DOS application can also be started from a DOS or OS/2 command line. Note, 
  11017. however, that starting the application in this way provides no opportunity to 
  11018. configure the VDM environment to support particular application requirements. 
  11019. Certain settings may be changed during application execution. However, such 
  11020. settings will be saved and will remain in effect until explicitly reset by the 
  11021. user. 
  11022.  
  11023. The default settings also allocate resources for EMS, XMS and DPMI support, 
  11024. which may not be required by the DOS application. For these reasons, it is 
  11025. recommended that DOS applications which require non-default settings be 
  11026. configured and started from the Workplace Shell wherever possible. 
  11027.  
  11028. When starting the application from a DOS command line, the application loads 
  11029. and executes within the VDM which displayed the command line. All DOS 
  11030. environment settings used by the application are those in effect for the VDM 
  11031. when the application was started. When the application terminates, control is 
  11032. returned to the command line. 
  11033.  
  11034. When starting the application from an OS/2 command line, the operating system 
  11035. reads the program file from disk, and determines from the executable file 
  11036. header that the program is a DOS or Windows application rather than an OS/2 
  11037. application. The operating system then automatically creates a VDM and loads 
  11038. the application into the VDM. When the application terminates, the VDM is also 
  11039. terminated and control returns to the OS/2 command line. 
  11040.  
  11041. Note that in either case, execution is synchronous, and the command line is not 
  11042. available for use while the application is running. An application may be 
  11043. started asynchronously from an OS/2 command line using the START command. In 
  11044. this case, the operating system creates an asynchronous VDM and loads the 
  11045. application into this VDM. The OS/2 command line remains available even though 
  11046. the DOS application is still running. 
  11047.  
  11048.  
  11049. ΓòÉΓòÉΓòÉ 20.3. Applications With Special Requirements ΓòÉΓòÉΓòÉ
  11050.  
  11051. The virtual DOS machine environment normally runs a specialized version of DOS 
  11052. known as the DOS Emulation kernel, in which most DOS services are actually 
  11053. provided by components of the OS/2 operating system, transparently to the 
  11054. application and outside of the real mode address space in which the DOS 
  11055. application executes. This kernel is described in MVDM DOS Emulation. 
  11056.  
  11057. For this reason, many DOS control structures are not accessible to DOS 
  11058. applications running in VDMs. Applications which access these control 
  11059. structures cannot be run in a "normal" VDM due to the lack of these structures. 
  11060. The DOS Emulation kernel does not support the use of block device drivers, and 
  11061. applications which require such device drivers are unable to use the DOS 
  11062. Emulation kernel. 
  11063.  
  11064. In order to allow such applications to be run in VDMs under OS/2 Version 2.0, 
  11065. the Virtual Machine Boot facility is provided. This facility allows a "real" 
  11066. version of DOS to be loaded into a VDM, either from a DOS bootable diskette or 
  11067. from a diskette image stored on fixed disk. Since the real version of DOS is 
  11068. therefore running in the VDM, all features, characteristics and internal 
  11069. control structures of that version are available to an application running in 
  11070. the VDM. 
  11071.  
  11072. An example of an application that needs to be run in this way is PC 
  11073. Support/400. 
  11074.  
  11075. The Virtual Machine Boot facility is described in detail in Virtual Machine 
  11076. Boot. 
  11077.  
  11078.  
  11079. ΓòÉΓòÉΓòÉ 20.4. Summary ΓòÉΓòÉΓòÉ
  11080.  
  11081. Multiple DOS applications may be run concurrently under OS/2 Version 2.0, in 
  11082. virtual DOS machines with pre-emptive multitasking and full memory protection. 
  11083. By default, these applications access DOS and hardware services using an 
  11084. emulated version of DOS, which provides these services through the OS/2 
  11085. operating system.  Most of these DOS services are provided outside the 640KB 
  11086. real mode address space in which the DOS application executes, thereby allowing 
  11087. more memory (up to 630KB) for the application and its data. 
  11088.  
  11089. DOS applications can usually be installed by starting a virtual DOS machine and 
  11090. running the install program from the command prompt. If the installation fails 
  11091. the user can boot the system from a DOS diskette to run the install, provided 
  11092. the hard disk has at least one FAT partition. 
  11093.  
  11094. A DOS application may be defined as an object on the OS/2 Version 2.0 Workplace 
  11095. Shell desktop or in a folder, and started from the Workplace Shell. 
  11096. Applications defined in this way have their VDM environment configured to 
  11097. support particular application requirements and to allow the application to 
  11098. take full advantage of VDM features. Alternatively, the Migrate Applications 
  11099. facility can be used to place the application in the Workplace Shell and 
  11100. customize the DOS settings 
  11101.  
  11102. A DOS application may also be started from the DOS or OS/2 command line. 
  11103. However, applications started from the DOS command line inherit the DOS 
  11104. environment settings of the VDM in which the command line is executing, and 
  11105. those started from the OS/2 command line inherit the default settings. 
  11106.  
  11107. DOS Applications which require access to internal DOS control structures or 
  11108. block device drivers not supported by the DOS Emulation kernel may use the 
  11109. Virtual Machine Boot facility of OS/2 Version 2.0 to load a "real" version of 
  11110. DOS from a diskette or a diskette image stored on fixed disk.  This capability 
  11111. allows such applications to run in a VDM. 
  11112.  
  11113.  
  11114. ΓòÉΓòÉΓòÉ 21. DOS Settings ΓòÉΓòÉΓòÉ
  11115.  
  11116. In order to provide the highest possible level of compatibility with DOS 
  11117. applications which make use of particular DOS properties or attributes, MVDM 
  11118. provides virtual DOS machines with many more customizable properties than 
  11119. comparable OS/2 sessions.  MVDM provides a common mechanism which supports 
  11120. standard settings, and allows virtual device drivers to register custom 
  11121. settings. The CONFIG.SYS file contains a number of standard DOS settings; 
  11122. these are applied to all VDMs as they are created.  Other settings may be 
  11123. specified for individual VDMs. 
  11124.  
  11125. When running Windows applications in VDMs under OS/2 Version 2.0, certain DOS 
  11126. settings should be altered from their default values.  The recommended values 
  11127. for these settings when running Windows applications are discussed in DOS and 
  11128. WIN-OS/2 Settings. 
  11129.  
  11130. DOS settings are used during creation and initialization of a VDM, and certain 
  11131. settings may also be altered dynamically during VDM execution. During 
  11132. initialization of the VDM, the VDM_CREATE hooks for all virtual device drivers 
  11133. defined for that VDM are called by the Virtual DOS Machine Manager.  At this 
  11134. point, the virtual device drivers may call the VDHQueryProperty() helper 
  11135. service to get the values for required settings. 
  11136.  
  11137.  
  11138. ΓòÉΓòÉΓòÉ 21.1. Registration ΓòÉΓòÉΓòÉ
  11139.  
  11140. Information on DOS settings is stored in a "database" in the operating system 
  11141. kernel.  This database is used to support all operations related to DOS 
  11142. settings.  The following information is registered for each setting: 
  11143.  
  11144. Name         The name presented to the user.  This may contain blanks, and 
  11145.              related settings should have common prefixes so that they sort 
  11146.              together in the list presented to the user (such as Printer buffer 
  11147.              size, Printer timeout, Printer automatic close). 
  11148.  
  11149. Ordinal      For the "standard" settings, specific ordinals are used so that 
  11150.              the kernel may obtain the value independently of the name string. 
  11151.  
  11152. Help File    The name of the help file containing help information on this 
  11153.              setting. 
  11154.  
  11155. Help ID      The help ID of the main topic for this setting. 
  11156.  
  11157. Type         The setting type.  The following types are supported: 
  11158.  
  11159.     Boolean 
  11160.     Integer 
  11161.     Enumeration (list  of  valid strings) 
  11162.     Single-line strings 
  11163.     Multi-line strings. 
  11164.  
  11165.              This allows the user interface to display an appropriate control 
  11166.              for each setting. 
  11167.  
  11168. Flags        These control aspects of the setting.  In particular, the flags 
  11169.              determine whether the setting can be changed while a VDM is 
  11170.              running. 
  11171.  
  11172. Default Value If the user does not supply a value, this default value is used. 
  11173.  
  11174. Validation information This information allows the user interface (and the 
  11175.              kernel) to validate settings without involvement from the virtual 
  11176.              device driver.  For strings, this is the maximum string length. 
  11177.              For integers, this is the minimum, maximum, and step values.  For 
  11178.              enumerations, this is the list of valid strings. 
  11179.  
  11180. Function     This function is used for validating string settings, and for 
  11181.              notifying the VDD when the user has changed a setting value for a 
  11182.              running VDM. 
  11183.  
  11184.  
  11185. ΓòÉΓòÉΓòÉ 21.1.1. Changing Settings Prior to Execution ΓòÉΓòÉΓòÉ
  11186.  
  11187. The Workplace Shell enables a user to define objects which represent OS/2 and 
  11188. DOS applications, using the Settings notebook.  For DOS applications, a DOS 
  11189. Settings... button is provided in the Session page of the notebook.  Pressing 
  11190. this button causes the DOS Settings dialog box to be displayed.  The user may 
  11191. then manipulate the DOS settings (which are initially set to their default 
  11192. values), and then save them. 
  11193.  
  11194. The DOS Settings dialog box uses the DosQueryDOSProperty() function to get the 
  11195. list of settings and detailed information on each setting.  It uses the 
  11196. DosSetDOSProperty() function to validate string settings. 
  11197.  
  11198.  
  11199. ΓòÉΓòÉΓòÉ 21.1.2. Changing Settings During Execution ΓòÉΓòÉΓòÉ
  11200.  
  11201. MVDM inserts a DOS Settings... menu item on the system menu for all VDMs. 
  11202. Selecting this menu item causes the DOS Settings dialog box to be displayed, 
  11203. which in turn allows the user to modify settings for the VDM.  For full screen 
  11204. VDMs, the user must switch to the Presentation Manager Window List using the 
  11205. Ctrl+Esc key sequence, and display the context menu for the VDM session by 
  11206. clicking mouse button 2 on the VDM's entry in the Window List.  The DOS 
  11207. Settings... option is displayed in the context menu. 
  11208.  
  11209. Note that only those settings that have been registered as being modifiable at 
  11210. run time may be altered in this way; other settings are not presented in the 
  11211. dialog box. 
  11212.  
  11213.  
  11214. ΓòÉΓòÉΓòÉ 21.1.3. Starting a VDM From Another Application ΓòÉΓòÉΓòÉ
  11215.  
  11216. The DosStartSession() function under OS/2 Version 2.0 provides an environment 
  11217. pointer as one of its parameters.  This pointer references a buffer which is 
  11218. used when creating a VDM.  This buffer contains the buffer length, followed by 
  11219. one or more DOS settings.  For each setting, the buffer specifies the type, 
  11220. name and value.  The operating system parses the settings buffer as part of the 
  11221. DosStartSession() processing, in order to create initial values for these 
  11222. settings.  Default values are assumed for any registered settings not specified 
  11223. in the DosStartSession() call. 
  11224.  
  11225. For any settings which have not been registered, the information in the buffer 
  11226. is ignored.  This allows the system to run without errors in the case where the 
  11227. virtual device driver that registered a setting is not loaded (for example, 
  11228. CONFIG.SYS was changed), and yet the Presentation Manager shell has saved a 
  11229. value for that setting. 
  11230.  
  11231.  
  11232. ΓòÉΓòÉΓòÉ 21.2. Standard DOS Settings ΓòÉΓòÉΓòÉ
  11233.  
  11234. Figure "The DOS Settings Dialog of the Settings Notebook" 
  11235.  
  11236. The standard DOS settings which affect the operation of virtual device drivers 
  11237. supplied with OS/2 Version 2.0 are described on the following pages.  The 
  11238. settings are grouped according to the general DOS system function to which they 
  11239. apply. 
  11240.  
  11241. DOS settings may be changed in either of two ways: 
  11242.  
  11243.  Settings which are described as settable "at VDM creation only", may only be 
  11244.   changed prior to starting the VDM.  If the DOS application is defined as an 
  11245.   object under the Workplace Shell, this is done by selecting the DOS Settings 
  11246.   button from the Session page in the application's Settings notebook. 
  11247.  
  11248.  Settings which are described as settable at any time may be set in the manner 
  11249.   described above, or they may be changed while an application is running in a 
  11250.   VDM, using the DOS Settings.. option from the system menu. 
  11251.  
  11252. Note that certain settings may be changed in both of the above ways. 
  11253.  
  11254.  
  11255. ΓòÉΓòÉΓòÉ 21.2.1. Communications ΓòÉΓòÉΓòÉ
  11256.  
  11257. The following settings control the communications environment (COM ports) used 
  11258. by a VDM. 
  11259.  
  11260. COM_HOLD 
  11261.  
  11262. Function:    When set on, provides exclusive access to COM ports for the 
  11263.              specified VDM, preventing other processes from using the port and 
  11264.              preventing the operating system from releasing the port until the 
  11265.              VDM terminates. 
  11266.  
  11267. Advantages:  For certain applications which use COM ports and which require 
  11268.              multiple programs to access the COM port (for example, this 
  11269.              setting prevents the COM port from being released when the first 
  11270.              program terminates). 
  11271.  
  11272. Drawbacks:   If not required by the application running in a VDM, this setting 
  11273.              may prevent other applications from accessing COM ports. 
  11274.  
  11275. Default:     Off. 
  11276.  
  11277. Settable:    At VDM creation only. 
  11278.  
  11279. Examples:    Certain bulletin board applications use one program to dial the 
  11280.              BBS and another to exchange information; setting COM_HOLD on 
  11281.              prevents the operating system from releasing the COM port when the 
  11282.              first program terminates. 
  11283.  
  11284.  
  11285. ΓòÉΓòÉΓòÉ 21.2.2. DOS Environment ΓòÉΓòÉΓòÉ
  11286.  
  11287. The following settings affect the behavior of the DOS emulation environment 
  11288. within a virtual DOS machine. 
  11289.  
  11290. DOS_BACKGROUND_EXECUTION 
  11291.  
  11292. Function:    When set off, suspends execution of the program when it is in the 
  11293.              background. 
  11294.  
  11295. Advantages:  Many DOS applications are written on the assumption that they are 
  11296.              single tasking and that all the resources of the workstation can 
  11297.              be monopolized. It is not uncommon  for a DOS program to 
  11298.              continually poll for keyboard input (Examples are WordPerfect 5.1 
  11299.              and Lotus 1-2-3 R2.2). In a multitasking environment, this can 
  11300.              impact system performance, especially when more than one such 
  11301.              program is running. Turning the DOS application off when its 
  11302.              virtual DOS machine is in the background reduces its demands on 
  11303.              the system. 
  11304.  
  11305.              Also see IDLE_SENSITIVITY and IDLE_SECONDS in Idle Detection. 
  11306.  
  11307. Drawbacks:   Communications programs will fail if background execution is 
  11308.              turned off, as will DDE for Windows applications. 
  11309.  
  11310.              Try changing the values of IDLE_SECONDS and IDLE_SENSITIVITY 
  11311.              before turning DOS_BACKGROUND_EXECUTION off. 
  11312.  
  11313. Default:     On (Background execution is enabled). 
  11314.  
  11315. Settable:    At any time. 
  11316.  
  11317. Examples:    If more than two DOS programs are running and tuning with 
  11318.              IDLE_SENSITIVITY and IDLE_SECONDS does not provide sufficient 
  11319.              improvement, turn DOS_BACKGROUND_EXECUTION off for the least used 
  11320.              application. 
  11321.  
  11322. DOS_BREAK 
  11323.  
  11324. Function:    Enables or disables Ctrl+Break for the specified VDM. Also check 
  11325.              for the BREAK statement in the CONFIG.SYS. Set BREAK=ON in the 
  11326.              CONFIG.SYS to make Ctrl+Break and Ctrl+C working in addition to 
  11327.              setting DOS_BREAK on. 
  11328.  
  11329. Advantages:  Enables a DOS application running in the VDM to be interrupted 
  11330.              using the Ctrl+Break or Ctrl+C key sequences. 
  11331.  
  11332. Drawbacks:   This setting is useful only if an application must be quickly 
  11333.              interrupted; the user may easily terminate a VDM by closing it 
  11334.              from the Window List. 
  11335.  
  11336. Default:     Off (Ctrl+Break is disabled). 
  11337.  
  11338. Settable:    At VDM creation only. 
  11339.  
  11340. Examples:    If the user wishes to have the option to interrupt a DOS batch 
  11341.              file running in a virtual DOS machine, this setting should be 
  11342.              turned on. 
  11343.  
  11344. DOS_DEVICE 
  11345.  
  11346. Function:    This setting can be used to add or modify information about DOS 
  11347.              device drivers for the specified VDM, in addition to the 
  11348.              information specified in CONFIG.SYS. 
  11349.  
  11350. Default:     When this setting is selected, a list is displayed which contains 
  11351.              information about each DOS device driver specified in CONFIG.SYS. 
  11352.              The information consists of the path and file name of each DOS 
  11353.              device driver and its current parameters, if applicable.  For 
  11354.              example: 
  11355.  
  11356.                           c:\os2\mdos\ansi.sys
  11357.  
  11358.              The user may: 
  11359.  
  11360.     Type the name of a DOS device driver to add it. Typing should begin on a 
  11361.      new line. 
  11362.     Delete all the information about a device driver to remove it. 
  11363.     Type or delete to add, change, or delete a value. 
  11364.  
  11365. Settable:    At VDM creation only. 
  11366.  
  11367. Examples:    A program to support hardware such as a scanner may include a 
  11368.              device driver that is needed only for itself. The device driver 
  11369.              should be loaded with the DOS_DEVICE setting instead of in the 
  11370.              CONFIG.SYS. 
  11371.  
  11372. DOS_FCBS 
  11373.  
  11374. Function:    Specifies the maximum number of file control blocks (FCBs) which 
  11375.              may be opened by applications running in the VDM. Note that this 
  11376.              setting affects only those modules which use file-sharing. 
  11377.  
  11378. Advantages:  Reducing this setting may improve DOS application performance in a 
  11379.              resource-constrained networking environment.  When the maximum 
  11380.              number of FCBs is opened by an application, the least recently 
  11381.              used FCB is closed to allow additional files to be opened; see 
  11382.              DOS_FCBS_KEEP below. 
  11383.  
  11384. Drawbacks:   Reducing this setting to an excessively low number may inhibit the 
  11385.              performance of applications which use large numbers of files. 
  11386.              Check application documentation for recommended FCB settings. 
  11387.  
  11388. Default:     16. 
  11389.  
  11390. Settable:    At VDM creation only. 
  11391.  
  11392. Examples:    None. 
  11393.  
  11394. DOS_FCBS_KEEP 
  11395.  
  11396. Function:    Specifies the number of FCBs that will be protected against 
  11397.              automatic closure. 
  11398.  
  11399. Advantages:  If this setting is specified as "n", the first "n" files are 
  11400.              protected against automatic closure as described in DOS_FCBS 
  11401.              above. This may improve application performance. 
  11402.  
  11403. Default:     8. 
  11404.  
  11405. Settable:    At VDM creation only. 
  11406.  
  11407. Examples:    None. 
  11408.  
  11409. DOS_FILES 
  11410.  
  11411. Function:    Specifies the maximum number of file handles which may be opened 
  11412.              in a VDM. 
  11413.  
  11414. Advantages:  Setting this value higher than the default may improve performance 
  11415.              for applications which use a large number of files.  Check 
  11416.              application documentation for recommended settings. 
  11417.  
  11418. Drawbacks:   Setting the number of file handles higher than necessary reduces 
  11419.              the available memory. 
  11420.  
  11421. Default:     20. 
  11422.  
  11423. Settable:    At any time. 
  11424.  
  11425. Examples:    DBASE IV requires a DOS_FILES setting of at least 40. 
  11426.  
  11427. DOS_HIGH 
  11428.  
  11429. Function:    Determines whether DOS is loaded outside the 640KB low memory 
  11430.              address space. 
  11431.  
  11432. Advantages:  Loading DOS into high memory allows more available memory for 
  11433.              application code and data within the 640KB address space. 
  11434.  
  11435. Drawbacks:   Applications which require access to DOS internal control 
  11436.              structures require DOS to be loaded into low memory, and therefore 
  11437.              cannot use this setting. 
  11438.  
  11439. Default:     Off (DOS is loaded into low memory). 
  11440.  
  11441. Settable:    At VDM creation only. 
  11442.  
  11443. Examples:    None. 
  11444.  
  11445. DOS_LASTDRIVE 
  11446.  
  11447. Function:    Specifies the highest available logical drive letter for the 
  11448.              specified VDM. This setting is similar to the LASTDRIVE= statement 
  11449.              in a DOS CONFIG.SYS. 
  11450.  
  11451. Default:     Z. 
  11452.  
  11453. Settable:    At VDM creation only. 
  11454.  
  11455. Examples:    Each additional drive letter uses about 100 bytes. Setting the 
  11456.              LAST_DRIVE to a lower letter such as J or K provides more 
  11457.              conventional memory for an application. 
  11458.  
  11459. DOS_RMSIZE 
  11460.  
  11461. Function:    Specifies the DOS memory size.  This is the amount of memory which 
  11462.              is available to DOS applications. 
  11463.  
  11464. Advantages:  The virtual video device driver uses this setting on certain video 
  11465.              adapters to set even more than 640KB. 
  11466.  
  11467. Drawbacks:   This setting is of little use to most users as there is no point 
  11468.              specifying less than 640KB. 
  11469.  
  11470. Default:     The default is 640KB. 
  11471.  
  11472. Settable:    At VDM creation only. 
  11473.  
  11474. Examples:    None. 
  11475.  
  11476. DOS_SHELL 
  11477.  
  11478. Function:    To specify the DOS command processor, or to add parameters to 
  11479.              affect the command processor.  This setting points by default to 
  11480.              COMMAND.COM.  If a user has a different command processor, it 
  11481.              should be specified here. 
  11482.  
  11483. Advantages:  The user may specify a command processor other than the default 
  11484.              COMMAND.COM, if required by a specialized application, or may 
  11485.              alter the environment space available for the VDM. 
  11486.  
  11487. Default:     C:\OS2\MDOS\COMMAND.COM C:\OS2\MDOS /P 
  11488.  
  11489. Settable:    At VDM creation only. 
  11490.  
  11491. Examples:    C:\OS2\MDOS\COMMAND.COM /E:1024 /P 
  11492.  
  11493. DOS_STARTUP_DRIVE 
  11494.  
  11495. Function:    Specifies the location of the DOS kernel to be loaded into the 
  11496.              VDM. 
  11497.  
  11498. Advantages:  Allows specific versions of DOS to be loaded into a VDM using the 
  11499.              VMB facility, allowing the execution of version-dependent DOS 
  11500.              applications. 
  11501.  
  11502. Drawbacks:   Performance may not be as good as the VDM kernel, which is 
  11503.              optimized for the OS/2 V2.0 environment. 
  11504.  
  11505. Default:     The DOS Emulation kernel is loaded. 
  11506.  
  11507. Settable:    At VDM creation only. 
  11508.  
  11509. Examples:    See Virtual Machine Boot. 
  11510.  
  11511. DOS_UMB 
  11512.  
  11513. Function:    Specifies whether DOS owns Upper Memory Blocks (UMBs) and manages 
  11514.              the loading of device drivers and TSR programs. 
  11515.  
  11516. Advantages:  Setting DOS_UMB on allows use of the DEVICEHIGH= and LOADHIGH 
  11517.              statements, to load device drivers and TSR programs into Upper 
  11518.              Memory Blocks, thereby preserving space in low memory for use by 
  11519.              applications. 
  11520.  
  11521. Drawbacks:   Certain applications which make use of UMBs need to access and 
  11522.              manage the UMBs directly; such applications will not run when 
  11523.              DOS_UMB is set on, because DOS owns the UMBs. 
  11524.  
  11525. Default:     Off (UMBs are owned by certain types of TSR programs and DOS 
  11526.              device drivers if necessary). 
  11527.  
  11528. Settable     At VDM creation only. 
  11529.  
  11530. Examples:    None. 
  11531.  
  11532. DOS_VERSION 
  11533.  
  11534. Function:    Allows the operating system to report a "fake" DOS version number 
  11535.              in response to a request from a program in the VDM, in order to 
  11536.              support applications which check for a DOS version number. 
  11537.  
  11538. Advantages:  Allows some programs that will not start unless they detect a 
  11539.              prerequisite DOS version to run in DOS Emulation 
  11540.  
  11541. Default:     20 
  11542.  
  11543. Settable:    Before application initiation. 
  11544.  
  11545. Examples:    Lotus 1-2-3 R3+ will run in DOS Emulation if it is "fooled" into 
  11546.              thinking that it is running under DOS 3.3 by putting the following 
  11547.              lines into the DOS_Version list box: 
  11548.  
  11549.     123DOS.EXE,3,30,255 
  11550.     123.EXE,3,30,255 
  11551.     LOTUS.EXE,3,30,255 
  11552.  
  11553.  
  11554. ΓòÉΓòÉΓòÉ 21.2.3. DPMI ΓòÉΓòÉΓòÉ
  11555.  
  11556. The following settings control the DPMI interface for a VDM. 
  11557.  
  11558. DPMI_DOS_API 
  11559.  
  11560. Function:    Determines whether DOS API translation is enabled for the 
  11561.              specified VDM. 
  11562.  
  11563. Default:     AUTO (API translation is enabled if required). 
  11564.  
  11565. Settable     At VDM creation only. 
  11566.  
  11567. Examples:    None. 
  11568.  
  11569. DPMI_MEMORY_LIMIT 
  11570.  
  11571. Function:    Specifies the maximum amount of protected mode memory (in 
  11572.              megabytes) available to DPMI applications running in the VDM. 
  11573.  
  11574. Advantages:  For applications which require large amounts of DPMI memory, this 
  11575.              setting may be used to increase the amount of available memory up 
  11576.              to 512MB. 
  11577.  
  11578. Default:     2MB. 
  11579.  
  11580. Settable     At VDM creation only. 
  11581.  
  11582. Examples:    None. 
  11583.  
  11584. DPMI_NETWORK_BUFF_SIZE 
  11585.  
  11586. Function:    Specifies the size, in kilobytes (KB), of the network translation 
  11587.              buffer for DPMI programs in this session. The range is from 1 to 
  11588.              64 KB. 
  11589.  
  11590. Default:     8KB. 
  11591.  
  11592. Settable     At VDM creation only. 
  11593.  
  11594. Examples:    This setting allows you to configure the size of the translation 
  11595.              buffer for Windows programs that transfer data over a network. If 
  11596.              a network-specific Windows program does not run correctly under 
  11597.              OS/2 V2.0, increase this setting, then restart  the session. 
  11598.  
  11599.  
  11600. ΓòÉΓòÉΓòÉ 21.2.4. EMS ΓòÉΓòÉΓòÉ
  11601.  
  11602. The following settings control the behavior of EMS memory used by the VDM. 
  11603.  
  11604. EMS_FRAME_LOCATION 
  11605.  
  11606. Function:    This DOS setting allows you to change the location of the LIM EMS 
  11607.              region. LIM EMS uses a 64KB address region known as an EMS page 
  11608.              frame, through which programs can access expanded memory. (This 
  11609.              allows programs to use more than 640KB of memory.) 
  11610.  
  11611. Advantages:  If a user has problems when running a program that uses both a 
  11612.              hardware device and LIM EMS expanded memory, the problem may be 
  11613.              due to conflicting use of addresses by LIM EMS and the hardware 
  11614.              device. If this occurs, the user should first use the 
  11615.              EMS_HIGH_OS_MAP_REGION setting to set the extra address region 
  11616.              used by EMS to 0. This may solve the problem. If the problem 
  11617.              persists, the EMS_FRAME_LOCATION setting can be used to select a 
  11618.              64KB region that does not conflict with hardware. 
  11619.  
  11620.              The user can choose where to place the frame from a list of 
  11621.              choices or can choose to have no EMS frame for programs which do 
  11622.              not require a frame.  The user can also reduce the DOS Memory Size 
  11623.              setting and place the frame below 640KB. 
  11624.  
  11625. Drawbacks:   The best solution, when problems due to hardware conflicts occur, 
  11626.              is to use the MEM_EXCLUDE_REGIONS and MEM_INCLUDE_REGIONS settings 
  11627.              to specify the addresses that the hardware uses rather than using 
  11628.              this setting. 
  11629.  
  11630. Default:     The default AUTO setting will lead to correct choices of LIM EMS 
  11631.              addresses.  Most users will never need to change this setting. 
  11632.  
  11633. Settable:    At VDM creation time only. 
  11634.  
  11635. Examples:    In some cases the default choice may conflict with addresses used 
  11636.              by hardware on the machine.  This can happen only for devices that 
  11637.              are not supported by a virtual device driver. 
  11638.  
  11639. EMS_HIGH_OS_MAP_REGION 
  11640.  
  11641. Function:    In addition to the EMS page frame, some programs can use 
  11642.              additional addresses to access expanded memory.  This setting 
  11643.              gives advanced users the capability to adjust the size of the 
  11644.              additional EMS region. 
  11645.  
  11646.              See also EMS_FRAME_LOCATION above. 
  11647.  
  11648. Advantages:  An advanced user can use the MEM_EXCLUDE_REGIONS and 
  11649.              MEM_INCLUDE_REGIONS settings to specify the addresses used by 
  11650.              devices that do not have virtual device drivers, and can then set 
  11651.              the size of the EMS_HIGH_OS_MAP_REGION appropriately for their 
  11652.              program. This helps avoiding conflicts with addresses used by 
  11653.              devices and programs. 
  11654.  
  11655. Default:     The value set is the size of the region in kilobytes.  The default 
  11656.              is 32KB. 
  11657.  
  11658. Settable:    At VDM creation only. 
  11659.  
  11660. Examples:    None. 
  11661.  
  11662. EMS_LOW_OS_MAP_REGION 
  11663.  
  11664. Function:    Some programs can use remappable conventional memory. Others do 
  11665.              not use this feature.  This setting allows advanced users to set 
  11666.              the size of the remappable conventional memory available in a VDM. 
  11667.  
  11668. Default:     The value set is the size of the region in kilobytes.  The default 
  11669.              is 384KB. 
  11670.  
  11671. Settable:    At VDM creation only. 
  11672.  
  11673. Examples:    None. 
  11674.  
  11675. EMS_MEMORY_LIMIT 
  11676.  
  11677. Function:    This setting controls the amount of EMS memory available to a VDM. 
  11678.  
  11679. Advantages:  The user can set this to a higher value for running programs that 
  11680.              require a large amount of EMS memory.  Other programs do not use 
  11681.              EMS at all.  The size can be set to 0 in such cases, to disable 
  11682.              EMS support for that VDM. Programs generally state whether they 
  11683.              use EMS on the box or in their manuals. 
  11684.  
  11685. Default:     The value set is the size of the region in kilobytes.  The default 
  11686.              size is 2MB. 
  11687.  
  11688. Settable:    At VDM creation time only. 
  11689.  
  11690. Examples:    If a spreadsheet runs out of memory, the amount of EMS memory can 
  11691.              be increased and the VDM restarted. 
  11692.  
  11693.  
  11694. ΓòÉΓòÉΓòÉ 21.2.5. Hardware Environment ΓòÉΓòÉΓòÉ
  11695.  
  11696. The following settings affect the virtual hardware environment provided by the 
  11697. virtual DOS machine. 
  11698.  
  11699. HW_NOSOUND 
  11700.  
  11701. Function:    Enables or disables sound started by a DOS program. 
  11702.  
  11703. Advantage:   Any sound from a program is heard unless sound is disabled.  An 
  11704.              "x" in the check box indicates that the sound is to be heard. 
  11705.  
  11706. Drawbacks:   No error sound will be heard if HW_NOSOUND is turned on. 
  11707.  
  11708. Default:     OFF. 
  11709.  
  11710. Settable:    At any time, including while a program is running in a VDM. 
  11711.  
  11712. Examples:    Output from a music program may be disabled when the user wishes 
  11713.              to hear another music program, or switch to another process to do 
  11714.              something else. 
  11715.  
  11716. HW_ROM_TO_RAM 
  11717.  
  11718. Function:    Enabling HW_ROM_TO_RAM causes the operating system to copy 
  11719.              read-only memory (ROM) and run the copy in 32-bit random access 
  11720.              memory (RAM).  With this setting enabled, BIOS operations run 
  11721.              faster and system utilities may patch BIOS. 
  11722.  
  11723. Default:     OFF. 
  11724.  
  11725. Settable:    At VDM creation only. 
  11726.  
  11727. Examples:    This setting is useful if debugging the kernel.  The change would 
  11728.              allow normal breakpoints to be set in ROM and allow stepping over 
  11729.              calls and loops. 
  11730.  
  11731.              Warning:  If an application writes to a memory address used by the 
  11732.              ROM while this setting is enabled, it may cause unpredictable 
  11733.              results for that application and for every application run 
  11734.              thereafter in the VDM. 
  11735.  
  11736.  
  11737. HW_TIMER 
  11738.  
  11739. Function:    When enabled, allows an application to have direct access to the 
  11740.              8253 timer ports and prevents the operating system from trapping, 
  11741.              or intercepting, the timer request and emulating a timer. 
  11742.  
  11743. Advantages:  Certain timing-critical applications will not run (or will run 
  11744.              much slower) if accesses to timer ports are trapped and 
  11745.              virtualized.  In addition, the values they read do not accurately 
  11746.              reflect the amount of time passed because they do not take 
  11747.              trapping overhead into account.  Enabling this setting allows 
  11748.              certain timing-dependent code to run more effectively. 
  11749.  
  11750. Drawbacks:   Applications that change the divisor before this setting is 
  11751.              enabled and then read the timer ports after the setting has been 
  11752.              enabled may not function properly.  If the setting is enabled 
  11753.              first, the VDM will not detect changes to the divisor correctly, 
  11754.              and the simulated interrupt frequency will be incorrect.  Also, 
  11755.              multiple applications using this setting may interfere with one 
  11756.              another. 
  11757.  
  11758. Default:     Off.  Most applications will operate normally with timer 
  11759.              virtualization. 
  11760.  
  11761. Settable:    At any time.  It is useful to alter this setting dynamically and 
  11762.              watch for changes in application performance. 
  11763.  
  11764. Examples:    The ROMs on some machines implement very brief delays by polling 
  11765.              the timer ports.  These delays become unacceptably long unless 
  11766.              direct timer port access is allowed. 
  11767.  
  11768.  
  11769. ΓòÉΓòÉΓòÉ 21.2.6. Idle Detection ΓòÉΓòÉΓòÉ
  11770.  
  11771. The following settings determine the way in which the operating system detects 
  11772. that an application in a VDM is currently idle.  These settings should be used 
  11773. when an application exhibits poor performance, or where mouse movement in a DOS 
  11774. application is "jerky". 
  11775.  
  11776. IDLE_SECONDS 
  11777.  
  11778. Function:    When programs appear to be doing nothing but waiting for input, 
  11779.              the operating system gives them less time to run. This is done to 
  11780.              give preference to programs that are doing useful work.  Some 
  11781.              programs periodically appear to be waiting for input, but then 
  11782.              change their behavior and continue after a time.  This setting 
  11783.              disables the "IDLE_SENSITIVITY" function for a period of time 
  11784.              after useful work has been detected. 
  11785.  
  11786.              Also see IDLE_SENSITIVITY below for more details on idle 
  11787.              detection. 
  11788.  
  11789. Advantages:  If a program appears to run slowly when there is an option for the 
  11790.              user to provide input, this value should be increased. 
  11791.  
  11792. Drawbacks:   Setting the value too high gives the DOS program more resources 
  11793.              than it needs. 
  11794.  
  11795. Default:     This value is in seconds.  The default is no idle time allowed. 
  11796.  
  11797. Settable:    The setting can be changed while the program is running to tune it 
  11798.              to the proper value. 
  11799.  
  11800. Examples: 
  11801.  
  11802.     A game may pause, for instance, to wait for the user to make a choice, but 
  11803.      then continues if the user does not react. 
  11804.  
  11805.     When DOS 5 is run in a virtual machine boot session, (See Virtual Machine 
  11806.      Boot) the DOS shell may fail to complete displaying the directory of the 
  11807.      C: drive if IDLE_SENSITIVITY is set too low. IDLE_SECONDS should then be 
  11808.      raised. 
  11809.  
  11810. IDLE_SENSITIVITY 
  11811.  
  11812. Function:    The idle sensitivity level sets a threshold for judging when 
  11813.              applications will be considered idle.  The value is the percentage 
  11814.              of the maximum possible polling rate the application can perform. 
  11815.              If an application polls at a rate higher than this value, it is 
  11816.              considered "idle". 
  11817.  
  11818.              DOS programs often "poll" for input when they are waiting for a 
  11819.              user response.  For instance, a program may wait for a response by 
  11820.              repeatedly checking to see if the user has hit a key.  In a 
  11821.              multitasking environment such as OS/2 Version 2.0, this wastes 
  11822.              time when other programs could be running instead.  The operating 
  11823.              system detects idle programs by looking for a high rate of polling 
  11824.              for input.  When programs are judged to be waiting for input, they 
  11825.              are given less time to run. 
  11826.  
  11827.              For example, if idle sensitivity is set to 75%, then an 
  11828.              application repeatedly checking to see if input is available would 
  11829.              have to do this checking at more than 75% of the maximum possible 
  11830.              rate before it would be judged idle. 
  11831.  
  11832.              Idle detection is a "best guess" of what the program is doing.  It 
  11833.              could be that the program is polling at a very high rate, but is 
  11834.              still doing useful work in between checking.  It may be that the 
  11835.              application checks at a fairly slow rate but still is doing 
  11836.              nothing but waiting. The idle sensitivity threshold allows 
  11837.              adjustment of the threshold for a particular application. 
  11838.  
  11839.              Also see IDLE_SECONDS above. 
  11840.  
  11841. Advantages:  If an application receives input while running and seems to run 
  11842.              slower than expected, the idle sensitivity should be set to a 
  11843.              higher value.  This lets the application poll at a higher rate 
  11844.              without being judged idle.  Setting the level to 100 turns idle 
  11845.              detection off altogether.  The application will be allowed to poll 
  11846.              for input as often as it likes. 
  11847.  
  11848.              If an application is waiting for input and other applications do 
  11849.              not appear to be running, the idle sensitivity should be adjusted 
  11850.              downward.  This lowers the threshold for judging the application 
  11851.              idle. 
  11852.  
  11853. Default:     The default is 75%. 
  11854.  
  11855. Settable:    The setting can be changed while the program is running to tune it 
  11856.              to the proper value. 
  11857.  
  11858. Examples:    Overall system performance can usually be improved when there are 
  11859.              multiple DOS applications running if IDLE_SENSITIVITY is turned 
  11860.              down. 
  11861.  
  11862.              Also see Dos Environment (DOS_BACKGROUND_EXECUTION). 
  11863.  
  11864.  
  11865. ΓòÉΓòÉΓòÉ 21.2.7. Keyboard ΓòÉΓòÉΓòÉ
  11866.  
  11867. The following settings affect the behavior of the keyboard and the 
  11868. interpretation of control key sequences issued within a VDM. 
  11869.  
  11870. KBD_ALTHOME_BYPASS 
  11871.  
  11872. Function:    When enabled, prevents the Alt+Home key sequence from switching 
  11873.              the VDM between full screen and windowed mode. 
  11874.  
  11875. Advantages:  Enabling this setting allows normal behavior for applications 
  11876.              which themselves make use of the Alt+Home key sequence. 
  11877.  
  11878. Drawbacks:   When enabled, the user must use the Ctrl+Esc sequence to switch to 
  11879.              Presentation Manager from a full screen VDM, then use the context 
  11880.              menu of the class to switch the VDM to windowed mode. 
  11881.  
  11882. Default:     Off (Alt+Home will cause a switch between full screen and windowed 
  11883.              mode). 
  11884.  
  11885. Settable:    At any time. 
  11886.  
  11887. Examples:    None. 
  11888.  
  11889. KBD_BUFFER_EXTEND 
  11890.  
  11891. Function:    Increases a VDM's keyboard type-ahead buffer size. 
  11892.  
  11893. Advantages:  Provides greater keystroke buffering, consistent with the level 
  11894.              available in VIO windows.  Note that Ctrl-Break will flush the 
  11895.              entire buffer, just as it does with the standard buffer. 
  11896.  
  11897. Drawbacks:   Applications which bypass the ROM BIOS input buffer and/or INT 16h 
  11898.              may not benefit from this feature.  There is also a small amount 
  11899.              of additional memory overhead for every VDM. 
  11900.  
  11901. Default:     On.  Most applications will benefit, and those that do not should 
  11902.              not be adversely affected. 
  11903.  
  11904. Settable:    At any time.  This facilitates easy experimentation by the user in 
  11905.              the (rare) event that a problem does arise. 
  11906.  
  11907. Examples:    None. 
  11908.  
  11909. KBD_CTRL_BYPASS 
  11910.  
  11911. Function:    When enabled, inhibits one or more control key sequences, allowing 
  11912.              an application in the VDM to use these sequences for its own 
  11913.              purposes. 
  11914.  
  11915. Advantages:  Enabling this setting allows normal behavior for applications 
  11916.              which make use of control key sequences normally used by OS/2 
  11917.              Version 2.0. 
  11918.  
  11919. Drawbacks:   Enabling this setting may prevent certain operations from being 
  11920.              performed with OS/2 Version 2.0 and the Workplace Shell. 
  11921.  
  11922. Default:     NONE (All control key sequences behave in the normal manner). 
  11923.  
  11924. Settable:    At any time. 
  11925.  
  11926. Examples:    None. 
  11927.  
  11928. KBD_RATE_LOCK 
  11929.  
  11930. Function:    Prevents a DOS application in a VDM from changing the system 
  11931.              keyboard repeat rate. 
  11932.  
  11933. Advantages:  Insulates machine from applications that modify the repeat rate in 
  11934.              an uncontrolled or undesirable way. 
  11935.  
  11936. Drawbacks:   Prevents the application's repeat rate from taking effect even 
  11937.              when the application is the focus session. 
  11938.  
  11939. Default:     Off.  Most applications do not modify the repeat rate, and those 
  11940.              that do are generally in accordance with the user's wishes. 
  11941.  
  11942. Settable:    At any time. 
  11943.  
  11944. Examples:    None. 
  11945.  
  11946.  
  11947. ΓòÉΓòÉΓòÉ 21.2.8. Memory Extenders (EMS and XMS) ΓòÉΓòÉΓòÉ
  11948.  
  11949. The following settings affect the behavior of the EMS and XMS memory extenders, 
  11950. if used in the VDM.  For an explanation about the implementation of EMS and XMS 
  11951. support in VDMs, see Memory Extender Support. 
  11952.  
  11953. MEM_EXCLUDE_REGIONS 
  11954.  
  11955. Function:    This setting is used to specify address ranges which should be 
  11956.              protected from use by EMS/XMS and direct access by applications. 
  11957.              This setting is intended for experienced users who understand the 
  11958.              hardware. 
  11959.  
  11960. Advantages:  This setting restricts the use of EMS/XMS on certain ranges in the 
  11961.              region between RMSIZE and 1MB.  It also protects these ranges from 
  11962.              being touched by user applications by portraying ROM there. 
  11963.  
  11964. Drawbacks:   Some hardware adapters stop functioning if their addresses are 
  11965.              touched in random fashion.  If these ranges are defined 
  11966.              excessively, they will adversely impact the function and 
  11967.              performance of EMS and XMS services. 
  11968.  
  11969. Default:     By default, this setting is void.  Each address is specified in 
  11970.              hex and if there is no range specified, the length taken is a page 
  11971.              (4KB). 
  11972.  
  11973. Settable:    At VDM creation only. 
  11974.  
  11975. Examples:    None. 
  11976.  
  11977. MEM_INCLUDE_REGIONS 
  11978.  
  11979. Function:    Specify regions which should be made available to EMS/XMS. This 
  11980.              setting is used to specify some address ranges between RMSIZE and 
  11981.              1MB for use by EMS and XMS. 
  11982.  
  11983. Advantages:  If there is a hardware adapter in this range which the user knows 
  11984.              is not going to be used by a particular VDM session, then the 
  11985.              address range used by this adapter should be made available to EMS 
  11986.              and XMS.  This will improve the performance of EMS and XMS 
  11987.              services.  Only advanced users who know the addresses used by a 
  11988.              card should use this setting. 
  11989.  
  11990. Default:     By default, this setting is void. 
  11991.  
  11992. Settable:    At VDM creation only. 
  11993.  
  11994. Examples:    See discussion in Expanded Memory (EMS) and Upper Memory (UMB). 
  11995.  
  11996.  
  11997. ΓòÉΓòÉΓòÉ 21.2.9. Mouse ΓòÉΓòÉΓòÉ
  11998.  
  11999. The following settings affect the behavior of the mouse in a VDM. 
  12000.  
  12001. MOUSE_EXCLUSIVE_ACCESS 
  12002.  
  12003. Function:    This setting allows VDMs to run applications which maintain their 
  12004.              own mouse pointers.  Some DOS applications manage their own mouse 
  12005.              positions and movements; in many cases, the application's values 
  12006.              for mouse sensitivity and/or double speed threshold are different 
  12007.              from those of Presentation Manager.  As a result, a Presentation 
  12008.              Manager mouse pointer may be outside the VDM window while the 
  12009.              application pointer is somewhere in the window not receiving any 
  12010.              mouse events. This means having two asynchronous mouse pointers on 
  12011.              the screen. 
  12012.  
  12013. Advantages:  The user forces the physical mouse driver to send its events 
  12014.              directly to the virtual mouse driver without going through 
  12015.              Presentation Manager.  Only one mouse pointer appears when the 
  12016.              particular VDM window has the focus. 
  12017.  
  12018. Default:     OFF. 
  12019.  
  12020. Settable:    At any time. 
  12021.  
  12022.              However, this only marks the VDM window and does not actually 
  12023.              activate the setting.  In order to activate it, the user must 
  12024.              press a mouse button within the VDM window.  The Presentation 
  12025.              Manager pointer disappears, leaving only the application pointer. 
  12026.              In order to regain the Presentation Manager pointer, the user must 
  12027.              press any of the hot-keys (Alt, Ctrl+Esc, Shift+Esc). 
  12028.  
  12029. Examples:    WordPerfect 5.1 has its own block-shaped mouse pointer, which will 
  12030.              appear together with the system mouse pointer when the window has 
  12031.              the focus. Turning MOUSE_EXCLUSIVE_ACCESS on allows the user to 
  12032.              remove the system mouse pointer when in WordPerfect. 
  12033.  
  12034.  
  12035. ΓòÉΓòÉΓòÉ 21.2.10. Printer ΓòÉΓòÉΓòÉ
  12036.  
  12037. The following settings affect print functions within a VDM. 
  12038.  
  12039. PRINT_TIMEOUT 
  12040.  
  12041. Function:    Use this setting to adjust the amount of time, in seconds, that 
  12042.              the OS/2 V2.0 print subsystem waits before forcing a print job to 
  12043.              the printer. In DOS, information sent by a program for printing 
  12044.              goes directly to a printer. However, the OS/2 V2.0 print subsystem 
  12045.              assembles print information in a spool file. After a specified 
  12046.              period of time, during which the spool file does not grow larger, 
  12047.              OS/2 V2.0 print subsystem sends the information to the printer as 
  12048.              a single print job. 
  12049.  
  12050. Advantage:   There is no need to exit the DOS program before the print job is 
  12051.              released by the OS/2 V2.0 print subsystem.  This is useful for 
  12052.              applications which do not explicitly close their print jobs. 
  12053.  
  12054. Default:     15 seconds, configurable from 0 to 3600 seconds (0 seconds is no 
  12055.              timeout). 
  12056.  
  12057. Settable:    At any time. 
  12058.  
  12059. Examples:    A timeout of 1 or 2 seconds is sufficient for small print jobs, 
  12060.              such as copying the contents of the screen. However, when printing 
  12061.              large files, formatting documents, or running calculations, the 
  12062.              value must be set high enough to allow all print results to reach 
  12063.              the spooler before the time limit expires.  If not, results go in 
  12064.              two or more spool files instead of one, and the resulting output 
  12065.              may be unsatisfactory. 
  12066.  
  12067.  
  12068. ΓòÉΓòÉΓòÉ 21.2.11. Video ΓòÉΓòÉΓòÉ
  12069.  
  12070. The following settings control screen I/O operations within a VDM. 
  12071.  
  12072. VIDEO_FASTPASTE 
  12073.  
  12074. Function:    Speeds up input from other sources than the keyboard. 
  12075.  
  12076. Advantages:  Improves the speed of paste operations from the clipboard to a DOS 
  12077.              application. 
  12078.  
  12079. Drawbacks:   Does not work with all applications (in particular, some 
  12080.              applications which monitor keyboard interrupts directly may 
  12081.              experience errors). 
  12082.  
  12083. Default:     Off. 
  12084.  
  12085. Settable:    At any time.  This facilitates easy experimentation by the user. 
  12086.  
  12087. Examples:    Pasting into the DOS command prompt, or any application using DOS 
  12088.              Console I/O functions, will generally work. However, the Microsoft 
  12089.              Editor (M) and its successor, Programmer's Workbench (PWB), can 
  12090.              fail when using fast pasting because they rebuffer keystrokes in 
  12091.              an internal buffer, which can overflow. 
  12092.  
  12093. VIDEO_MODE_RESTRICTION 
  12094.  
  12095. Function:    Extends the 640KB DOS address space by limiting video mode 
  12096.              support. 
  12097.  
  12098. Advantages:  For text-based or CGA graphics based applications, the video 
  12099.              memory normally reserved just above 640KB for high-resolution 
  12100.              graphics modes can be remapped to conventional memory, providing 
  12101.              an additional 64KB (or 96KB, depending on graphics mode) for DOS 
  12102.              applications, TSRs, and other programs.  This is valuable for 
  12103.              applications that do not take advantage of EMS or XMS memory 
  12104.              extenders. 
  12105.  
  12106. Drawbacks:   It is not possible to completely hide the fact that the video 
  12107.              adapter is high-resolution graphics-capable;  some applications 
  12108.              may attempt to enable those modes and use the memory above 640KB 
  12109.              as video memory, inadvertently corrupting application data.  Care 
  12110.              must therefore be taken when using this feature. 
  12111.  
  12112. Default:     NONE.  The complete list of settings is: 
  12113.  
  12114.     None 
  12115.  
  12116.     CGA modes only (adds 96KB) 
  12117.  
  12118.     MONO modes only (adds 64KB). 
  12119.  
  12120. Settable:    At VDM creation only. 
  12121.  
  12122. Examples:    None. 
  12123.  
  12124. VIDEO_ONDEMAND_MEMORY 
  12125.  
  12126. Function:    Reduces swap space requirements for fullscreen VDMs. 
  12127.  
  12128. Advantages:  Allows a full-screen VDM to run without pre-allocating a virtual 
  12129.              video buffer for the worst-case video modes (high-resolution 
  12130.              graphics modes).  Using this setting does not prevent execution of 
  12131.              graphics applications; it simply means that allocation of the 
  12132.              buffer is delayed until it is needed.  This can save a substantial 
  12133.              amount of memory/swap space, which might be important under 
  12134.              certain low-memory conditions. It also enables you to start a 
  12135.              program quickly. 
  12136.  
  12137. Drawbacks:   If allocation of a virtual video buffer for a full-screen VDM 
  12138.              fails at the time the application changes video modes, the session 
  12139.              must be frozen and switched back to the shell.  Unless the user is 
  12140.              able to free memory from another session, he may be unable to get 
  12141.              the DOS application running again.  This is a concern if the 
  12142.              application contains unsaved data. 
  12143.  
  12144. Default:     Off. 
  12145.  
  12146. Settable:    At any time.  This allows the user to save memory the next time 
  12147.              the session is switched to full-screen. 
  12148.  
  12149. Examples:    None. 
  12150.  
  12151. VIDEO_RETRACE_EMULATION 
  12152.  
  12153. Function:    Simulates the video retrace status port to provide faster access. 
  12154.  
  12155. Advantages:  DOS applications that poll the video retrace status port often 
  12156.              write to the screen only during the retrace interval, even though 
  12157.              it is safe (on EGA and VGA adapters) to draw at any time without 
  12158.              causing interference (also known as "snow").  This feature causes 
  12159.              most applications to write to the screen more often, and 
  12160.              compensates for the performance drag imposed by monitoring the 
  12161.              port in the first place. 
  12162.  
  12163. Drawbacks:   Some applications may poll the port in such a way that overall 
  12164.              performance is worse; this is sometimes true of applications that 
  12165.              draw only during vertical (not horizontal) retrace. 
  12166.              Unfortunately, while turning off trace emulation will restore 
  12167.              performance, there is a risk that screen-switching will not be as 
  12168.              reliable. 
  12169.  
  12170. Default:     On.  Reliable screen-switching has higher priority over the 
  12171.              minority of applications that will experience some drag in 
  12172.              performance. 
  12173.  
  12174. Settable:    At any time.  This allows the user to experiment with different 
  12175.              settings in the event of a performance problem. 
  12176.  
  12177. Examples:    None. 
  12178.  
  12179. VIDEO_ROM_EMULATION 
  12180.  
  12181. Function:    Emulates selected INT 10h ROM Video functions. 
  12182.  
  12183. Advantages:  Provides faster output for selected video functions than ROM 
  12184.              services typically provide.  This also has a dramatic effect on 
  12185.              the performance of those functions in a window. 
  12186.  
  12187. Drawbacks:   Some ROMs may offer enhanced services that are not included in the 
  12188.              emulation.  Applications which rely upon these services may not 
  12189.              execute correctly. 
  12190.  
  12191. Default:     On.  Because the INT 10h ROM Video services are well-documented, 
  12192.              incompatibilities are unlikely and the performance benefits of 
  12193.              using the emulation are quite significant. 
  12194.  
  12195. Settable:    At any time.  This allows the user to experiment in the event of a 
  12196.              compatibility problem. 
  12197.  
  12198. Examples:    None. 
  12199.  
  12200. VIDEO_SWITCH_NOTIFICATION 
  12201.  
  12202. Function:    Notifies a DOS application of a switch to/from full-screen mode. 
  12203.  
  12204. Advantages:  Allows applications that monitor this notification to redraw their 
  12205.              screens as needed.  This may be necessary for some video adapters 
  12206.              that provide modes (and applications that use those modes) which 
  12207.              are not fully supported by the OS/2 video driver or which are 
  12208.              slightly incompatible.  It is also valuable in situations where an 
  12209.              OS/2 video driver has not allocated a virtual video buffer (see 
  12210.              VIDEO_8514_XGA_IOTRAP below). Use this setting if you use the 
  12211.              VIDEO_ONDEMAND_MEMORY DOS setting, because concurrent buffer 
  12212.              allocation and screen switching can make a screen go black. 
  12213.  
  12214. Drawbacks:   When used indiscriminately, this feature may cause unnecessary and 
  12215.              time-consuming screen redrawing.  For standard MONO/CGA/EGA/VGA 
  12216.              video modes, the OS/2 video driver should be able to restore 
  12217.              application screens without assistance. 
  12218.  
  12219. Default:     Off.  For standard hardware and standard video modes, this feature 
  12220.              is not necessary. 
  12221.  
  12222. Settable:    At any time.  This allows the user to experiment in the event of a 
  12223.              compatibility problem. 
  12224.  
  12225. Examples:    Windows 2.x and 3.x understand this notification and will redraw 
  12226.              themselves accordingly. For WIN-OS/2 sessions, set this setting 
  12227.              on. 
  12228.  
  12229. VIDEO_WINDOW_REFRESH 
  12230.  
  12231. Function:    Adjusts the window update frequency for a given VDM. 
  12232.  
  12233. Advantages:  For applications (particularly graphics) that write frequently to 
  12234.              video memory, this value can be increased to reduce time spent 
  12235.              updating the window and provide more processor time for the 
  12236.              application. 
  12237.  
  12238.              Note:   This has no effect on updates based on other events such 
  12239.                      as keyboard input or synchronous scrolling operations or 
  12240.                      any video events other than refresh.
  12241.  
  12242. Drawbacks:   A large refresh period can make an application unusable (or at 
  12243.              least, very hard to use). 
  12244.  
  12245. Default:     0.1 seconds.  This has been found to yield the best overall 
  12246.              performance. 
  12247.  
  12248. Settable:    At any time, in increments of 0.1 seconds.  This allows for 
  12249.              experimentation.  The range is from 0.1 to 60.0 seconds. 
  12250.  
  12251. Examples:    This setting affects normal TTY-style output.  Compare a DIR or 
  12252.              TYPE operation before and after altering this setting. 
  12253.  
  12254. VIDEO_8514_XGA_IOTRAP 
  12255.  
  12256. Function:    When set OFF, unrestricted access to 8514/A display adapter 
  12257.              hardware.  Note that this setting is only available for systems 
  12258.              with 8514/A display adapters installed. 
  12259.  
  12260. Advantages:  Achieves higher performance for 8514/A applications and eliminates 
  12261.              the overhead of the 1MB 8514/A virtual video buffer normally 
  12262.              allocated for each VDM when set OFF. 
  12263.  
  12264. Drawbacks:   Screen-switching away from the application will result in 
  12265.              immediate freezing of the application, and the system may not be 
  12266.              able to reliably switch back; that is, the screen image may not be 
  12267.              correct.  This may be overcome by setting 
  12268.              VIDEO_SWITCH_NOTIFICATION on, which notifies applications to 
  12269.              redraw their own screen images.  Note however, that not all 
  12270.              applications will take advantage of the notification. 
  12271.  
  12272.              Note:   An application with this setting enabled may not be run in 
  12273.                      windowed mode, or copied to the clipboard, because there 
  12274.                      is no complete information about its state.
  12275.  
  12276. Default:     Off. 
  12277.  
  12278. Settable:    At VDM creation only. 
  12279.  
  12280. Examples:    When executing Windows 3.0 with the 8514/A display driver, certain 
  12281.              operations such as painting dithered backgrounds will run 
  12282.              significantly faster. 
  12283.  
  12284.  
  12285. ΓòÉΓòÉΓòÉ 21.2.12. XMS ΓòÉΓòÉΓòÉ
  12286.  
  12287. XMS_HANDLES 
  12288.  
  12289. Function:    Specifies the number of XMS extended memory block (EMB) handles. 
  12290.              A handle is used with each XMS EMB.  This number is required 
  12291.              because XMS pre-allocates all the handle space to be compatible 
  12292.              with XMS specifications.  This setting should be used only if an 
  12293.              application uses a large number of handles. 
  12294.  
  12295. Advantages:  This setting restricts the number of block handles, thereby 
  12296.              reducing memory consumption. 
  12297.  
  12298. Drawbacks:   Specifying a large number of handles will increase memory 
  12299.              consumption and adversely impact system performance. 
  12300.  
  12301. Default:     The default value of this setting is 32. 
  12302.  
  12303. Settable:    At VDM creation only. 
  12304.  
  12305. Examples:    None. 
  12306.  
  12307. XMS_MEMORY_LIMIT 
  12308.  
  12309. Function:    Specifies the per VDM XMS memory limit. This setting should be 
  12310.              used under the same guidelines as described above in XMS_HANDLES. 
  12311.              The global limit is the overall maximum XMS memory consumption, 
  12312.              and the per-VDM limit is the maximum allowed for each VDM. See 
  12313.              also Extended Memory Manager (Initialization) for defining global 
  12314.              and per-VDM limit in the CONFIG.SYS. 
  12315.  
  12316. Drawbacks:   Specifying a large number may adversely affect system performance. 
  12317.  
  12318. Default:     The default value is 2MB per-VDM. 
  12319.  
  12320. Settable:    At VDM creation only. 
  12321.  
  12322. Examples:    4096; this specifies a limit for each VDM. 
  12323.  
  12324. XMS_MINIMUM_HMA 
  12325.  
  12326. Function:    Specifies the minimum HMA memory request allowed.  This setting 
  12327.              allows the user to fine tune the XMS.  HMA is slightly less than 
  12328.              64KB in size.  Only one request can be fulfilled from this area at 
  12329.              a time. 
  12330.  
  12331. Advantages:  If a TSR takes a very small allocation, then it will waste this 
  12332.              area for other applications.  In such cases a limit can be 
  12333.              specified. 
  12334.  
  12335. Default:     The default value is zero, which means all the requests will be 
  12336.              allowed. 
  12337.  
  12338. Settable:    At VDM creation only. 
  12339.  
  12340. Examples:    2048; this sets a limit of 2KB. 
  12341.  
  12342.  
  12343. ΓòÉΓòÉΓòÉ 21.2.13. WIN-OS/2 ΓòÉΓòÉΓòÉ
  12344.  
  12345. The following setting is available when the selected virtual DOS machine type 
  12346. is WIN-OS/2 full screen or WIN-OS/2 window: 
  12347.  
  12348. WIN_RUNMODE 
  12349.  
  12350. Function:    OS/2 V2.0 can use two modes to run Windows programs: 
  12351.  
  12352.     Real 
  12353.     Standard 
  12354.  
  12355.              Real mode is the mode that Windows 2.0 programs run in. Windows 
  12356.              3.0 programs usually run in standard mode. For a detailed 
  12357.              discussion, see Windows Applications. Use this setting to specify 
  12358.              WIN-OS/2 mode for your session. 
  12359.  
  12360. Default:     AUTO (the system selects standard mode as long as it has the OS/2 
  12361.              V2.0 Virtual Device Drivers required to support a standard mode 
  12362.              WIN-OS/2 session in the OS/2 V2.0 operating system). AUTO enables 
  12363.              the system to automatically choose between real and standard. 
  12364.  
  12365. Settable:    At VDM creation only. 
  12366.  
  12367. Examples:    None. 
  12368.  
  12369.  
  12370. ΓòÉΓòÉΓòÉ 21.3. Summary ΓòÉΓòÉΓòÉ
  12371.  
  12372. The DOS Settings feature of MVDM provides the user with the ability to 
  12373. selectively configure and tune the virtual DOS machine environment to meet the 
  12374. requirements of particular applications.  Since some DOS applications require 
  12375. certain features while other applications operate better without them, a VDM 
  12376. may be individually configured to provide the optimum execution environment for 
  12377. the application which will run within it. 
  12378.  
  12379. DOS settings may be set by the user when adding an application to a group on 
  12380. the desktop, or in certain cases, during execution while an application is 
  12381. running within the virtual DOS machine.  In the case where a VDM is created by 
  12382. another process using a DosStartSession() function call, a buffer may be 
  12383. provided containing the required DOS settings and their values. 
  12384.  
  12385.  
  12386. ΓòÉΓòÉΓòÉ 22. Virtual Machine Boot ΓòÉΓòÉΓòÉ
  12387.  
  12388. An important goal of OS/2 Version 2.0 is the ability to run past, current, and 
  12389. future DOS programs; indeed most DOS applications available today run unchanged 
  12390. in the MVDM environment. 
  12391.  
  12392. However, it should be remembered that the "DOS" which runs in this case is 
  12393. highly optimized for (and specific to) an OS/2 Version 2.0 virtual 8086 
  12394. machine. Because of this, there are fundamental internal differences between 
  12395. the DOS Emulation provided under OS/2 Version 2.0 and "real" DOS. Two problems 
  12396. may therefore arise: 
  12397.  
  12398.  1. Some programs may depend on specific DOS features such as internal control 
  12399.     blocks, LAN Redirector hooks, or even undocumented functions, which are not 
  12400.     present in MVDM's DOS Emulation. 
  12401.  2. Only DOS character device drivers can be loaded in MVDM's DOS Emulation. 
  12402.     The user may own a block device (such as a special disk or tape drive) for 
  12403.     which no OS/2 driver is available. (A block device is one accessed via a 
  12404.     drive letter, such as E:). 
  12405.  
  12406. Virtual Machine Boot (VMB) solves both these problems. It allows the user to 
  12407. boot "off-the-shelf" DOS and use block device drivers in an OS/2 Version 2.0 
  12408. virtual DOS machine, ensuring greater compatibility for DOS applications. 
  12409.  
  12410. Another possible use of VMB is to run DOS of a different National Language to 
  12411. that of OS/2 Version 2.0 itself. This may be useful in a multilingual 
  12412. environment. 
  12413.  
  12414.  
  12415. ΓòÉΓòÉΓòÉ 22.1. VMB Environment ΓòÉΓòÉΓòÉ
  12416.  
  12417. The 80386 processor and VDM component of OS/2 Version 2.0 together emulate a 
  12418. 8086 processor, keyboard, display, BIOS and other supporting hardware;  in 
  12419. effect, a complete "virtual Personal Computer".  It is therefore possible for 
  12420. "real" DOS to be loaded in a VDM  session.  Control is passed to the boot 
  12421. record (the first sector) of the DOS system diskette, which in turn loads and 
  12422. initializes the rest of the DOS kernel, just as it does when booting on a 
  12423. physical PC. 
  12424.  
  12425. Indeed, the VDM environment is so similar to a real PC environment that VMB can 
  12426. actually support any 8086 operating system kernel, such as Digital Research's 
  12427. DR-DOS** and CP/M**, Microsoft MS-DOS**, or even a PS/2 reference diskette (but 
  12428. do not attempt to run diagnostics or change the configuration from a VDM; the 
  12429. results are unpredictable). However, since the purpose of VMB is to run current 
  12430. DOS applications, formal IBM support is announced for IBM PC DOS 3.x, 4.0, and 
  12431. 5.0 only. 
  12432.  
  12433. Table "Free Base Memory" shows the amount of available base memory for MVDM DOS 
  12434. Emulation, DOS in a VMB session, and native DOS.  These figures show the amount 
  12435. of memory available after loading the operating system and mouse, EMS and XMS 
  12436. support. 
  12437.  
  12438. A VDM using VMB is similar in function to any other virtual DOS machine. 
  12439. Multiple VDMs may be started and operated concurrently using Virtual Machine 
  12440. Boot.  Each runs in its own virtual 8086 machine; access to hardware and other 
  12441. system resources is managed by MVDM and the underlying OS/2 Version 2.0 
  12442. operating system. 
  12443.  
  12444.  
  12445. ΓòÉΓòÉΓòÉ 22.2. Configuring Virtual Machine Boot ΓòÉΓòÉΓòÉ
  12446.  
  12447. The DOS operating system loaded into a VDM by VMB  may be: 
  12448.  
  12449.  1. An actual DOS system diskette 
  12450.  2. An image of a DOS system diskette saved to hard disk 
  12451.  3. A DOS partition on hard disk. 
  12452.  
  12453. For any of the alternatives, we need to do the following: 
  12454.  
  12455.  1. Set up the start-up batch file AUTOEXEC.BAT 
  12456.  
  12457.  2. Set up the configuration file CONFIG.SYS 
  12458.  
  12459.  3. Provide OS/2 V2.0 with the real DOS to boot. 
  12460.  
  12461.  
  12462. ΓòÉΓòÉΓòÉ 22.2.1. Preparing AUTOEXEC.BAT and CONFIG.SYS ΓòÉΓòÉΓòÉ
  12463.  
  12464. The AUTOEXEC.BAT and CONFIG.SYS that will be used by the VMB at initialization 
  12465. are not the ones found in the root directory of the OS/2 V2.0 boot drive. Table 
  12466. "Location of AUTOEXEC.BAT and CONFIG.SYS" explains which AUTOEXEC.BAT and 
  12467. CONFIG.SYS will be used for the different DOS session types under OS/2 V2.0. 
  12468.  
  12469. CONFIG.SYS requires special attention for the following reasons: 
  12470.  
  12471.  1. Write access to the hard disk is denied the Virtual Machine Boot session to 
  12472.     preserve system integrity, since the real DOS is unaware of OS/2 V2.0 and 
  12473.     the other applications running. 
  12474.  
  12475.     The OS/2 device driver FSFILTER.SYS is provided to address the above 
  12476.     problem. 
  12477.  
  12478.  2. HPFS partitions are not visible to the real DOS running. 
  12479.  
  12480.     FSFILTER.SYS allows the DOS in the Virtual Machine Boot to access HPFS 
  12481.     files. 
  12482.  
  12483.  3. OS/2 V2.0 provides its own mouse, EMS and XMS to each virtual DOS machine, 
  12484.     so there is no need to load the equivalent drivers available for native 
  12485.     DOS. Those provided with the real DOS should not be used. 
  12486.  
  12487.     However, some DOS programs test for the presence of these drivers. OS/2 
  12488.     V2.0 provides the equivalent "stub" drivers to satisfy these programs that 
  12489.     the services actually are available. 
  12490.  
  12491.     The following types of device drivers should also be omitted from 
  12492.     CONFIG.SYS: 
  12493.  
  12494.     Disk cache 
  12495.     Print spooler 
  12496.     RAM disk 
  12497.  
  12498.     These facilities are already provided by OS/2 Version 2.0 and may be 
  12499.     accessed by virtual DOS machines and VMB sessions; including them with DOS 
  12500.     leads to unnecessary duplication, and may impact overall performance. 
  12501.  
  12502. When the Virtual Machine Boot is started from a diskette image on the hard 
  12503. disk, the real DOS sees the diskette image as drive A:. The real drive A: 
  12504. cannot be accessed. OS/2 V2.0 provides a DOS program, FSACCESS.EXE, that can be 
  12505. used from the DOS command prompt or inserted in AUTOEXEC.BAT to overcome this 
  12506. problem. 
  12507.  
  12508. We will cover each of these special requirements in detail in the following 
  12509. sections. 
  12510.  
  12511. Drive Letter Allocation and Access 
  12512.  
  12513. Drive letter allocation and access is one of the more complex areas of VMB, 
  12514. mainly due to the automatic drive letter allocation performed by DOS, and the 
  12515. limitations of earlier DOS versions. The following possible areas of confusion 
  12516. may arise for the user: 
  12517.  
  12518.  If DOS is booted from an image file, it sees this image file as its A: drive. 
  12519.   This prevents access to the real A:  diskette drive. Attempts to write to the 
  12520.   apparent A: drive will fail. 
  12521.  
  12522.  Unlike the DOS Emulation kernel provided by OS/2 Version 2.0, the "real" DOS 
  12523.   booted by VMB cannot see or access an HPFS partition on the hard disk. 
  12524.  
  12525.  A DOS 3.x VDM cannot see a large (>32MB) FAT partition on the fixed disk, or 
  12526.   FAT partitions beyond an HPFS partition on the disk. 
  12527.  
  12528.  Even if the booted DOS can otherwise see the hard disk partition, it is only 
  12529.   given read access. Attempts to write will fail with simulated errors such as 
  12530.   General failure writing drive C:". The user might mistake this for a genuine 
  12531.   hardware fault. 
  12532.  
  12533.  If the booted DOS loads a block device-driver, the allocated drive letter may 
  12534.   be the same as that of a different device outside this VDM, thereby 
  12535.   preventing access to that device from within the VDM. 
  12536.  
  12537. The results could be somewhat disorienting for the user. To help resolve these 
  12538. issues, two utilities FSFILTER and FSACCESS are provided with OS/2 Version 2.0. 
  12539.  
  12540. It is recommended that disk volumes should always be given a meaningful name, 
  12541. either when formatting or later using the LABEL command. This name will remain 
  12542. constant regardless of drive letter allocation, and will aid in identifying a 
  12543. particular volume, even if the assigned drive letter is different. FSFILTER 
  12544.  
  12545. FSFILTER.SYS is a device driver which manages DOS VDM access to OS/2 disks. 
  12546. FSFILTER.SYS should be copied from the \OS2\MDOS directory to the DOS diskette, 
  12547. and the following statement added to the CONFIG.SYS file of the bootable DOS 
  12548. diskette or image. 
  12549.  
  12550. device=a:fsfilter.sys
  12551.  
  12552. This statement should precede any DEVICE= statements which load block device 
  12553. drivers. 
  12554.  
  12555. Note that FSFILTER.SYS gives DOS full access to all OS/2 partitions, regardless 
  12556. of their file system type or partition size. 
  12557.  
  12558. This is an important and somewhat surprising point. For example, DOS 3.3 (in a 
  12559. VDM) has no problem accessing a 300MB HPFS partition, once FSFILTER is loaded. 
  12560. I/O calls within the DOS virtual machine are passed transparently to OS/2 
  12561. Version 2.0. DOS itself is unaware of the underlying file system. DOS can read, 
  12562. write and modify files on the hard disk, and for most configurations the drive 
  12563. letter mapping within the VMB session will match those of OS/2 Version 2.0. 
  12564.  
  12565. The FSFILTER device driver occupies approximately 11KB of memory.  It can be 
  12566. loaded into high memory under DOS 5.0 by specifying the command DEVICEHIGH = 
  12567. FSFILTER.SYS in CONFIG.SYS. 
  12568.  
  12569. The users should also specify the path to COMMAND.COM in the SHELL= statement 
  12570. of CONFIG.SYS.  For example, if DOS files have been copied to C:\DOS, the 
  12571. CONFIG.SYS file on a diskette intended for VMB should contain the following 
  12572. statement: 
  12573.  
  12574. SHELL=c:\DOS\COMMAND.COM c:\dos /p
  12575.  
  12576. The first parameter specifies the command processor to be loaded. The second 
  12577. parameter specifies the reload path (that is, the COMSPEC path). This is 
  12578. preferable to a SET COMSPEC = command in AUTOEXEC.BAT. 
  12579.  
  12580. Each block device driver loaded in DOS CONFIG.SYS is allocated the next free 
  12581. OS/2 letter excluding LAN drives.  This can result in a drive letter clash.  An 
  12582. example may illustrate the point. OS/2 drives are: 
  12583.  
  12584. A:   Diskette drive 0 
  12585. B:   Diskette drive 1 
  12586. C:   Hard disk 
  12587. D:   External diskette drive 
  12588. E:   Remote LAN drive on a server 
  12589.  
  12590. FSFILTER will ensure that a booted DOS sees these drives by the same letter. 
  12591. The booted DOS has the same access to the external diskette drive and LAN 
  12592. resources as does OS/2 itself. This is true whether the VMB session is started 
  12593. before or after user logon to the network, when remote drive letters are 
  12594. assigned. 
  12595.  
  12596. However, a block device driver in a VMB session will also initialize as E:, so 
  12597. LAN drive access is lost. To remedy this, issue an "fsaccess f=e" command. The 
  12598. LAN drive is now accessible as F:  within the DOS session. 
  12599.  
  12600. Note that even when FSFILTER is loaded, the following restrictions still apply: 
  12601.  
  12602.  A VMB session cannot see HPFS files or directories which have: 
  12603.  
  12604.    - Long file names (9 or more characters) 
  12605.    - Invalid FAT characters (for example, plus, comma, blank) 
  12606.    - Multiple dot separators. 
  12607.  
  12608.  HPFS file names containing lowercase letters are folded to uppercase. 
  12609.  
  12610.  PC DOS commands which require low-level disk access will fail.  These 
  12611.   include: 
  12612.  
  12613.    - CHKDSK 
  12614.    - SYS 
  12615.    - UNDELETE 
  12616.    - FORMAT 
  12617.    - UNFORMAT 
  12618.    - MIRROR. 
  12619.  
  12620.   In such cases OS/2 Version 2.0 will simulate a disk error condition. DOS may 
  12621.   interpret this as a hardware fault, or report that the command is not 
  12622.   supported on a network or assigned drive. 
  12623.  
  12624. FSACCESS 
  12625.  
  12626. FSACCESS.EXE is a utility supplied with OS/2 Version 2.0 but intended to run in 
  12627. a VMB session. It cooperates with FSFILTER to manage drive letters within the 
  12628. VMB session. This serves three purposes: 
  12629.  
  12630.  1. Drives may be registered for filtering. 
  12631.  
  12632.  2. The drive letter for a device can be changed, giving consistency across 
  12633.     sessions. 
  12634.  
  12635.  3. Letters can be removed in order to hide the OS/2 device from the VMB 
  12636.     session. 
  12637.  
  12638. The syntax of the FSACCESS command is: 
  12639.  
  12640. FSACCESS ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  12641.                          Γö£ΓöÇΓö¼ΓöÇΓöÇΓöÇΓö¼ΓöÇ DOSletter ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ     Γöé
  12642.                          Γöé Γöö ! Γöÿ                         Γöé
  12643.                          Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ DOSletter - DOSletter ΓöÇΓöÇΓöñ
  12644.                          Γöé                               Γöé
  12645.                          ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ DOSletter = OS2drive  ΓöÇΓöÇΓöÿ
  12646.  
  12647. FSACCESS            Lists the current drive mapping. For example: 
  12648.  
  12649.                                                      Local C: is mapped to OS/2 C:
  12650.                                                      Local D: is mapped to OS/2 D:
  12651.                                                      Local E: is mapped to OS/2 K:
  12652.  
  12653. FSACCESS F:         Registers DOS letter F: for filtering. References to F: 
  12654.                     will be sent to OS/2 Version 2.0. 
  12655.  
  12656. FSACCESS !F:        De-registers DOS letter F: from filtering. 
  12657.  
  12658. FSACCESS F:-H:      Registers DOS letters F: through H: for filtering. 
  12659.  
  12660. FSACCESS M:=C:      Routes requests for DOS letter M: to OS/2 drive C: 
  12661.  
  12662. Parameters can be combined on a single command line, and the colon is optional. 
  12663.  
  12664. When booting from an image file, it is often desirable to issue the command 
  12665. FSACCESS A: in order to access the A:  diskette drive.  This will remove access 
  12666. to the image file, so the booted DOS will be unable to reload its COMMAND.COM 
  12667. when necessary.  It may be useful to copy all the DOS files to a subdirectory 
  12668. on hard disk, ensuring the PATH and COMSPEC point there. 
  12669.  
  12670. An alternative is to access the diskette drive via a different letter. For 
  12671. example, a user may issue the command FSACCESS G:=A, then use G: to access the 
  12672. real A:  drive.  The image file remains as A:, avoiding PATH and COMSPEC 
  12673. problems. 
  12674.  
  12675.  
  12676. ΓòÉΓòÉΓòÉ 22.2.2. Mouse, EMS and XMS Support ΓòÉΓòÉΓòÉ
  12677.  
  12678. The booted DOS in a VMB session receives XMS (HIMEM), EMS, DPMI and mouse 
  12679. support services from its VDM environment (assuming the virtual DOS machine has 
  12680. default DOS settings).  DOS should not therefore load its own HIMEM, EMS or 
  12681. mouse drivers; indeed they may cause errors in the VDM. 
  12682.  
  12683. DOS programs call these services via appropriate API register parameters and a 
  12684. designated interrupt: 
  12685.  
  12686. Mouse     INT 33h 
  12687. XMS       INT 2Fh (multiplex) 
  12688. EMS       INT 67h 
  12689.  
  12690. These interrupts are trapped by the VDM environment, routed outside the virtual 
  12691. machine and handled by the OS/2 Version 2.0 operating system itself.  This may 
  12692. present a problem for certain programs which first test for the presence of 
  12693. such services by issuing an OPEN command to the associated device driver, or 
  12694. which check that a valid interrupt handler is referenced by the Interrupt 
  12695. Vector Table. When a VMB session is started, these device driver names are not 
  12696. present, and the interrupt vectors point to null handlers. The application will 
  12697. therefore assume that the required services are not useable. 
  12698.  
  12699. In order to avoid this problem, OS/2 Version 2.0 provides three alternative 
  12700. "stub" drivers: 
  12701.  
  12702.  MOUSE.COM 
  12703.  HIMEM.SYS 
  12704.  EMM386.SYS 
  12705.  
  12706. These stub drivers are very small (and use minimal memory when loaded) but 
  12707. satisfy programs which depend on drivers with such names being present. They 
  12708. respond to OPEN commands, and also set handler addresses in the Interrupt 
  12709. Vector Table, thereby satisfying applications which check for the presence of 
  12710. the device drivers in either of these ways. 
  12711.  
  12712. The user must load these OS/2 files rather than any similarly named files which 
  12713. may be shipped with DOS or applications, such as: 
  12714.  
  12715. DOS 4.0   XMAEM.SYS, XMA2EMS.SYS 
  12716.  
  12717. DOS 5.0   HIMEM.SYS, EMM386.EXE, MOUSE.COM 
  12718.  
  12719. DR DOS    HIDOS.SYS, EMM386.SYS, EMMXMA.SYS 
  12720.  
  12721. Other     MOUSE.SYS 
  12722.  
  12723. There are two ways to achieve this. Assuming OS/2 Version 2.0 is installed on 
  12724. drive E: 
  12725.  
  12726.  1. Copy the above OS/2 files from E:\OS2\MDOS to the DOS diskette, and edit 
  12727.     CONFIG.SYS and AUTOEXEC.BAT accordingly to load these files from the A: 
  12728.     drive.  VMDISK may then be run to create a bootable image if desired. 
  12729.  
  12730.            device=a:himem.sys
  12731.            device=a:emm386.sys
  12732.            device=a:fsfilter.sys
  12733.  
  12734.     This method should be used if FSFILTER will be loaded into high memory 
  12735.     using DOS 5.0: 
  12736.  
  12737.            device=a:himem.sys
  12738.            device=a:emm386.sys
  12739.            devicehigh=a:fsfilter.sys
  12740.  
  12741.  2. Edit CONFIG.SYS and AUTOEXEC.BAT to load these files directly from 
  12742.     E:\OS2\MDOS. (FSFILTER.SYS must be loaded first if the OS/2 drive would 
  12743.     otherwise be inaccessible to the booted DOS). 
  12744.  
  12745.            device=a:fsfilter.sys
  12746.            device=e:\os2\mdos\himem.sys
  12747.            device=e:\os2\mdos\emm386.sys
  12748.  
  12749.     The second method has one notable advantage; if and when Corrective Service 
  12750.     is applied to the OS/2 Version 2.0 system, and HIMEM, EMM386 or MOUSE are 
  12751.     updated, it is not necessary to update your DOS diskettes and recreate 
  12752.     image files.  FSFILTER itself will have to be updated manually (unless the 
  12753.     OS/2 Version 2.0 partition is directly accessible to DOS and FSFILTER is 
  12754.     also loaded from here). 
  12755.  
  12756. Note that EMS memory size and frame location are determined by DOS Settings, 
  12757. and not by parameters on the DEVICE= statement for EMM386.SYS. It is 
  12758. recommended that EMS and XMS support should not be configured unless required 
  12759. by the application running in the VMB session, since this can impact overall 
  12760. system performance. 
  12761.  
  12762. We now look at the three different ways to prepare the real DOS to be booted in 
  12763. the VMB. 
  12764.  
  12765.  
  12766. ΓòÉΓòÉΓòÉ 22.2.3. Booting from Diskette ΓòÉΓòÉΓòÉ
  12767.  
  12768. The user may load a specific version of DOS or an equivalent 8086 operating 
  12769. system into a VMB session directly from  a bootable diskette, by specifying A: 
  12770. at the value for DOS_STARTUP_DRIVE under DOS Settings.  Note that this may 
  12771. affect the way in which applications in the VMB session may access the diskette 
  12772. drives;  see Preparing AUTOEXEC.BAT and CONFIG.SYS (Drive Letter Allocation and 
  12773. Access) for further discussion. 
  12774.  
  12775. Here is an example using DOS 5: 
  12776.  
  12777.  1. From a system running DOS 5, format a diskette with the /s option. 
  12778.  
  12779.  2. Copy FSFILTER.SYS from the OS/2 V2.0 subdirectory \OS2\MDOS onto the 
  12780.     diskette. 
  12781.  
  12782.  3. Create CONFIG.SYS and AUTOEXEC.BAT on the diskette. 
  12783.  
  12784.     A sample CONFIG.SYS to use is as follows (OS/2 V2.0 is installed in E: 
  12785.     drive in this example): 
  12786.  
  12787.         REM Load FSFILTER driver
  12788.         DEVICE=A:FSFILTER.SYS
  12789.         REM load the stub XMS and EMS memory drivers from OS2.
  12790.         DEVICE=E:\OS2\MDOS\HIMEM.SYS
  12791.         DEVICE=E:\OS2\MDOS\EMM386.SYS
  12792.  
  12793.     A sample AUTOEXEC.BAT to use is as follows: 
  12794.  
  12795.         @ECHO OFF
  12796.         PROMPT $P$G
  12797.         REM set the path to where the DOS files were copied
  12798.         SET PATH=C:\DOS
  12799.         SET COMSPEC=C:\DOS\COMMAND.COM
  12800.         REM load the stub mouse driver from OS/2 V2.0
  12801.         LH E:\OS2\MDOS\MOUSE
  12802.  
  12803.  4. Create a DOS subdirectory on the hard disk and copy the real DOS files 
  12804.     there. 
  12805.  
  12806.  5. Insert the DOS boot diskette in the A: drive. 
  12807.  
  12808.  6. Locate the Command Prompts folder. It is usually a folder in the OS/2 
  12809.     System icon on the Workplace Shell. 
  12810.  
  12811.  7. Open the Command Prompts  folder. 
  12812.  
  12813.  8. Locate the DOS from drive A: icon and double click on it. 
  12814.  
  12815.     The DOS_STARTUP_DRIVE setting of this icon is pre-set to the value A:. 
  12816.  
  12817. The user cannot specify "B:" or an external diskette drive as the startup 
  12818. drive. There may be situations where it is desired to boot from a 5╨╝ inch 
  12819. diskette; typically the B: drive on PS/2 systems.  One way to do this is by 
  12820. creating an image of the diskette, then booting this image (See Booting from 
  12821. Diskette Image). 
  12822.  
  12823. If a 5╨╝ inch diskette must be booted directly for some reason, this is possible 
  12824. if drive remapping is supported by the system (such as a PS/2 Model 57, 90 or 
  12825. 95). Normally A: is Drive 0 (3╨╗ inch), and B: is Drive 1 (5╨╝ inch, if fitted). 
  12826. To change this, run "Set Startup Sequence" from the reference diskette, and 
  12827. ensure Drive 1 appears before Drive 0. Then the 5╨╝  inch drive will become the 
  12828. A: drive. 
  12829.  
  12830. Some 5╨╝ inch drives (such as the IBM External 1.2MB drive and associated 
  12831. adapter) require a device driver, and are accessed as D: or higher. They cannot 
  12832. be specified as a startup drive, nor can they be readdressed as A:, but can be 
  12833. the source drive when creating a bootable image file. 
  12834.  
  12835.  
  12836. ΓòÉΓòÉΓòÉ 22.2.4. Booting from Diskette Image ΓòÉΓòÉΓòÉ
  12837.  
  12838. A user may also load a specific version of DOS or another 8086 operating system 
  12839. into a VMB session from a diskette image stored on the hard disk. This is 
  12840. achieved by specifying the fully qualified filename of the diskette image file 
  12841. as the value for DOS_STARTUP_DRIVE  under DOS Settings. 
  12842.  
  12843. Here is an example using the DOS 5  boot diskette created in the Booting from 
  12844. Diskette above: 
  12845.  
  12846.  1. Edit CONFIG.SYS on the diskette and add the following statement: 
  12847.  
  12848.         E:\OS2\MDOS\FSACCESS G: = A:
  12849.  
  12850.  2. Create the image of the boot diskette on the hard disk. 
  12851.  
  12852.     Images may be created using the VMDISK utility supplied with OS/2 Version 
  12853.     2.0. The syntax of the VMDISK command is: 
  12854.  
  12855.     vmdisk <source drive> <image filename> 
  12856.  
  12857.     For example: 
  12858.  
  12859.         VMDISK a: c:\bootimg\dos50.vmb
  12860.  
  12861.     The image file is a complete binary "dump" of the diskette, consisting of a 
  12862.     short header record followed by the diskette's boot sector, FAT(s), and all 
  12863.     data clusters.  Its file size corresponds to the size of the source 
  12864.     diskette, regardless of the amount of space actually used on the source 
  12865.     diskette.  No compression of the image is performed. 
  12866.  
  12867.     The diskette must have a standard DOS format (FAT, 512 byte sectors).  It 
  12868.     is not possible to create, then boot, an image of a copy-protected diskette 
  12869.     which has a non-DOS format. It may be possible to boot such a diskette 
  12870.     directly in a VDM. 
  12871.  
  12872.     The VMDISK utility can run under either DOS or OS/2, and supports all 3╨╗ 
  12873.     inch (720KB, 1.44MB and 2.88MB) and 5╨╝ inch (360KB and 1.2MB) source 
  12874.     diskette formats. 
  12875.  
  12876.     Note that VMDISK works one way only; it is not possible to create a 
  12877.     diskette from a VMDISK image. 
  12878.  
  12879.  3. Proceed to add an icon to the OS/2 V2.0 Workplace Shell to launch VMB. 
  12880.     Refer to Putting the Virtual Machine Boot Session in the Workplace Shell on 
  12881.     customizing the Virtual Machine Boot, in particular the DOS_STARTUP_DRIVE 
  12882.     setting. 
  12883.  
  12884.  
  12885. ΓòÉΓòÉΓòÉ 22.2.5. Booting from a DOS Partition ΓòÉΓòÉΓòÉ
  12886.  
  12887. If VMB will be used regularly, the most convenient method may be to do so from 
  12888. a DOS partition on hard disk, rather than via diskettes or diskette images. 
  12889. This may be achieved by specifying C: as the value for DOS_STARTUP_DRIVE under 
  12890. DOS Settings. Loading DOS from a DOS partition proceeds more quickly and offers 
  12891. the user a more "familiar" working environment. It is also easier to apply DOS 
  12892. Corrective Service to a disk partition than to diskettes or images. 
  12893.  
  12894. Note that this method is different from that of a single hard disk partition 
  12895. with the Dual Boot feature available under previous versions of OS/2. 
  12896.  
  12897. In order to load DOS from a DOS partition, the following requirements must be 
  12898. satisfied: 
  12899.  
  12900.  1. Boot Manager must be installed 
  12901.  
  12902.  2. DOS must be installed on a primary partition on the first hard disk in the 
  12903.     machine 
  12904.  
  12905.  3. OS/2 Version 2.0 must be installed on an extended partition on the first 
  12906.     fixed disk, or on another hard disk. 
  12907.  
  12908. This will require re-partitioning on single-drive systems if the disk initially 
  12909. contains DOS alone, or earlier versions of OS/2. 
  12910.  
  12911. Loading DOS from a DOS partition presents one significant problem.  The DOS 
  12912. partition is itself bootable directly via Boot Manager, should the user so 
  12913. choose, and there may a requirement to boot this DOS partition directly on 
  12914. occasions.  OS/2 Version 2.0 provides stub device drivers for functions such as 
  12915. EMS, XMS and mouse support in the VMB session, and these must be used in place 
  12916. of the normal DOS device drivers when DOS is booted in a VMB session. Since the 
  12917. same CONFIG.SYS  and AUTOEXEC.BAT in the C: root directory is used, the 
  12918. question arises of which drivers should be specified for functions such as EMS 
  12919. and XMS support: 
  12920.  
  12921.  If the partition is booted via VMB, the DOS drivers are inappropriate 
  12922.  
  12923.  If the partition is booted directly via Boot Manager, the OS/2 stub drivers 
  12924.   are inappropriate. 
  12925.  
  12926. It might appear that the user would have to maintain multiple configuration 
  12927. files and rename or copy them depending upon whether the partition was being 
  12928. booted into a VMB session or directly from Boot Manager.  This is clearly 
  12929. unsatisfactory. Fortunately there is a solution which avoids this. The key is 
  12930. to specify both sets of drivers, in the correct order, in CONFIG.SYS and 
  12931. AUTOEXEC.BAT. 
  12932.  
  12933. The following example assumes: 
  12934.  
  12935.  DOS 5.0 is installed on the C: Primary partition 
  12936.  OS/2 Version 2.0 is installed on the E: Extended partition 
  12937.  
  12938. CONFIG.SYS on the C: drive contains: 
  12939.  
  12940. device=c:\dos\setver.exe
  12941. device=c:\dos\himem.sys
  12942. device=c:\dos\emm386.exe noems
  12943. device=e:\os2\mdos\himem.sys
  12944. device=e:\os2\mdos\emm386.sys
  12945. dos=high,umb
  12946.    ... etc ...
  12947.  
  12948. When this file is processed in an OS/2 VMB session, the DOS HIMEM load fails as 
  12949. it sees no available extended memory. EMM386.EXE cannot load as it sees 
  12950. protect-mode software already running. Then, the OS/2 HIMEM and EMM386 stub 
  12951. device drivers load as normal. 
  12952.  
  12953. When this file is processed as part of a native DOS boot, the DOS HIMEM and 
  12954. EMM386 load as normal, but the OS/2 stub device drivers detect that they are 
  12955. not running under OS/2 and do not load themselves. 
  12956.  
  12957. A similar technique works for mouse support in AUTOEXEC.BAT: 
  12958.  
  12959. @echo off
  12960. prompt $p$g
  12961. set path=c:\dos
  12962. LH e:\os2\mdos\mouse
  12963. LH c:\dos\mouse
  12964.    ... etc ...
  12965.  
  12966. Note that here the OS/2 driver is listed first. When this file is processed in 
  12967. an OS/2 VMB session, the OS/2 stub loads first.  The DOS mouse driver sees that 
  12968. a mouse driver is already present, and hence it does not install itself.  When 
  12969. booting DOS natively, the OS/2 mouse stub device driver detects that it is not 
  12970. running under OS/2, and does not load itself. The DOS mouse driver then loads 
  12971. as normal. 
  12972.  
  12973.  
  12974. ΓòÉΓòÉΓòÉ 22.2.6. Putting the Virtual Machine Boot Session in the Workplace Shell ΓòÉΓòÉΓòÉ
  12975.  
  12976. We are now ready to put the VMB session as an object on the OS/2 Version 2.0 
  12977. Workplace Shell desktop. 
  12978.  
  12979.  1. Locate the Templates folder. It is usually an icon on the Workplace Shell. 
  12980.  
  12981.  2. Open the Templates folder. 
  12982.  
  12983.  3. Locate the Program icon template. 
  12984.  
  12985.  4. Drag the Program icon template on to the desktop. This will cause the 
  12986.     Program Settings notebook to appear. 
  12987.  
  12988.  5. Enter an asterisk "*" in the Path and file name field. 
  12989.  
  12990.     See the example as shown in Figure "The Program Page of the Settings 
  12991.     Notebook for a VMB". 
  12992.  
  12993.  6. Select the Session notebook tab. 
  12994.  
  12995.     The Session notebook allows the user to specify the session type and DOS 
  12996.     Settings  for the VMB session. 
  12997.  
  12998.  7. Select either DOS full screen or DOS window and then select the DOS 
  12999.     Settings... button. 
  13000.  
  13001.  8. Select the DOS_STARTUP_DRIVE list item. 
  13002.  
  13003.     The difference between a VMB session and a "normal" VDM is that the DOS 
  13004.     Settings value of DOS_STARTUP_DRIVE is set. This setting determines the 
  13005.     location of the DOS kernel to be booted.  By default, MVDM's DOS Emulation 
  13006.     is loaded.  However, the user may specify a location from which to load 
  13007.     DOS, in which case the version of DOS residing at that location is loaded. 
  13008.  
  13009.     Figure "DOS Settings - DOS_STARTUP_DRIVE" 
  13010.  
  13011.     Example values for DOS startup drive are: 
  13012.  
  13013.    DOS Start up setting          Meaning 
  13014.    a:                            Boot using the diskette in drive A: 
  13015.    c:\bootimg\dos50.vmb          Boot using the specified DOS image file 
  13016.    c:                            Boot using the primary partition of the C: 
  13017.                                  drive 
  13018.  
  13019.     The following restrictions apply: 
  13020.  
  13021.     A second diskette drive (B:) or hard disk (D:) cannot be specified as the 
  13022.      startup drive. 
  13023.  
  13024.     To boot DOS from the C: partition, Boot Manager must be installed, and 
  13025.      OS/2 Version 2.0 must reside in an extended partition on the first hard 
  13026.      disk, or on another hard disk. See Booting from a DOS Partition. 
  13027.  
  13028.  9. Select the Save button to save the DOS settings and return. 
  13029.  
  13030. 10. Select the General notebook tab. 
  13031.  
  13032. 11. Change the Title field to your own name describing the new object. 
  13033.  
  13034. 12. Close the Settings notebook by double clicking on the system menu in the 
  13035.     upper left corner of the window. 
  13036.  
  13037. Other DOS Settings 
  13038.  
  13039. DOS settings which control the VDM hardware environment are applicable to the 
  13040. VMB session and operate in the same way as for a DOS Emulation windowed or 
  13041. full-screen session. Those which modify the virtual DOS environment are 
  13042. ignored; the equivalent settings are instead determined by the CONFIG.SYS file 
  13043. of the booted DOS kernel. Ignored settings include: 
  13044.  
  13045.  DOS_BREAK 
  13046.  DOS_DEVICES 
  13047.  DOS_UMB 
  13048.  DOS_SHELL 
  13049.  DOS_HIGH 
  13050.  DOS_LASTDRIVE 
  13051.  DOS_VERSION 
  13052.  
  13053. The FCB limit is the lesser of either the booted DOS, or OS/2 Version 2.0 
  13054. CONFIG.SYS value.  The VMB session will by default have 640KB of real memory, 
  13055. mou se support, 2MB Expanded (EMS) memory, 2MB DPMI, and 2MB XMS memory. 
  13056.  
  13057. Booting from an OS/2 V2.0 Program 
  13058.  
  13059. By using DosStartSession it is possible to start a VMB session from an OS/2 
  13060. V2.0 program. For more details see the following sample which shows how to boot 
  13061. from the disk drive A:. Of course, by changing startd.Environment, this sample 
  13062. can also be used to start a VMB from another hard disk partition or a boot 
  13063. image file from your hard disk. 
  13064.  
  13065. Figure "VMB from an OS/2 2.0 Program" 
  13066.  
  13067.  
  13068. ΓòÉΓòÉΓòÉ 22.3. Managing the VMB Session ΓòÉΓòÉΓòÉ
  13069.  
  13070. The user may interact with a VMB session in a similar way to any other virtual 
  13071. DOS machine.  The session may be scaled, minimized, maximized and switched 
  13072. between windowed and full-screen mode, and is subject to the same graphics mode 
  13073. limitations when windowed. However, a VMB session cannot be ended by typing 
  13074. EXIT at its command prompt. The session can only be closed from its system icon 
  13075. or the Window List. 
  13076.  
  13077. Note that Ctrl-Alt-Del will reboot the entire OS/2 Version 2.0 operating 
  13078. system, not just the foreground virtual machine session. 
  13079.  
  13080.  
  13081. ΓòÉΓòÉΓòÉ 22.4. VMB Limitations ΓòÉΓòÉΓòÉ
  13082.  
  13083. VMB does not support: 
  13084.  
  13085.  VCPI and other non-DPMI DOS extenders 
  13086.  I/O to disk which bypasses the file system 
  13087.  Feature adapter sharing without a virtual device driver 
  13088.  Real-time or timing-critical DOS applications 
  13089.  Some copy-protection schemes. 
  13090.  
  13091. These limitations arise in the most part from the limitations of the MVDM 
  13092. environment, which are imposed in order to protect overall system integrity. 
  13093.  
  13094.  
  13095. ΓòÉΓòÉΓòÉ 22.5. Summary ΓòÉΓòÉΓòÉ
  13096.  
  13097. The DOS Emulation kernel which is normally used to support the execution of DOS 
  13098. applications in a VDM is exactly what its name implies; an emulation of the DOS 
  13099. operating system and associated services.  While this suffices for most DOS 
  13100. applications, certain applications exist which take advantage of unique and/or 
  13101. undocumented features which exist only in specific versions of DOS. 
  13102.  
  13103. To allow such applications to be successfully run under OS/2 Version 2.0, the 
  13104. VMB (Virtual Machine Boot) feature is provided.  This feature allows a "real" 
  13105. DOS operating system, or indeed most other 8086 operating systems, to be booted 
  13106. in a virtual DOS machine.  The operating system may be booted from either a 
  13107. diskette in drive A:, a diskette image on a hard disk, or a partition on a hard 
  13108. disk. 
  13109.  
  13110. Applications which run using Virtual Machine Boot may take advantage of the 
  13111. EMS, XMS and mouse support provided to virtual DOS machines by OS/2 Version 
  13112. 2.0.  This support is provided through stub device drivers supplied with OS/2 
  13113. Version 2.0; these should be used in preference to the device drivers supplied 
  13114. with the operating system or applications. 
  13115.  
  13116.  
  13117. ΓòÉΓòÉΓòÉ 23. Running Personal Communications/3270 Version 2 for Windows ΓòÉΓòÉΓòÉ
  13118.  
  13119. Personal Communications 3270 Version 2 for Windows offers a high-function 3270 
  13120. emulator for the Windows environment. It supports a variety of host 
  13121. connections, including DFT, LAN via IEEE 802.2 protocol, LAN via NETBIOS and 
  13122. SDLC. It is possible to run this 3270 emulator in an OS/2 V2.0 "seamless" 
  13123. WIN-OS/2 VDM. 
  13124.  
  13125. Figure "Personal Communications/3270 for Windows running under OS/2 V2.0" 
  13126.  
  13127. We will describe below the procedure for installing and running Personal 
  13128. Communications/3270 for Windows for a host connection via a LAN using the IEEE 
  13129. 802.2 protocol. We will also describe how to install any Corrective Service 
  13130. Diskettes for this emulator package. 
  13131.  
  13132.  
  13133. ΓòÉΓòÉΓòÉ 23.1. Installing PC/3270 under WIN-OS/2 ΓòÉΓòÉΓòÉ
  13134.  
  13135. You must have installed OS/2 Version 2.0, including the WIN-OS/2 support in 
  13136. order for this to work. 
  13137.  
  13138.  1. From the OS/2 Desktop: 
  13139.  
  13140.     Open the OS/2 System Folder 
  13141.     Open the Command Prompts Folder 
  13142.     Select WIN-OS/2 full-screen 
  13143.  
  13144.     This will start up the WIN-OS/2 environment. You will get the WIN-OS/2 
  13145.     Program Manager screen, just as you would if you had started Windows 
  13146.     natively. From here the installation of the product and the corrective 
  13147.     service is just as it would be under Windows. 
  13148.  
  13149.  2. From the Program Manager Menu Bar: 
  13150.  
  13151.     Select File 
  13152.     Select Run 
  13153.     Insert PC/3270 Windows Diskette 1 in the A: drive 
  13154.     On the command line enter: A:INSTALL 
  13155.  
  13156.     Now you will fill out the installation and configuration screens just as 
  13157.     you would have installing PC/3270 directly under Windows. 
  13158.  
  13159.     In this sample installation we will use the following throughout this part 
  13160.     of the document: 
  13161.  
  13162.            C:           is the drive where OS/2 Version 2.0 is installed
  13163.            C:\PC3270W   is the drive and subdirectory where PC/3270 is installed
  13164.            PC3270W      is the name of the configuration file we create
  13165.  
  13166.  3. Select OK on the PC/3270 Installation logo screen. 
  13167.  
  13168.  4. On the Installation Start screen: 
  13169.  
  13170.     Select Create New Configuration file 
  13171.     Select OK 
  13172.  
  13173.  5. On the Customize Configuration screen: 
  13174.  
  13175.     Select Connection type. 
  13176.  
  13177.      Our sample will use DFT, but you can select the one you want. We have 
  13178.      tested DFT, LAN 802.2, SDLC and IIN Async at 9600bps. 
  13179.  
  13180.      If you select other than DFT, you will need to configure your 
  13181.      communications parameters before you can continue. You will need to refer 
  13182.      to other documentation for this configuration information. 
  13183.     Select 2 for Number of Host sessions. 
  13184.      Yours will probably vary, but start simple. 
  13185.     Select OK. 
  13186.  
  13187.  6. On the Installation End screen: 
  13188.  
  13189.     Enter a Configuration File name of PC3270W 
  13190.     Select Copy Necessary Files only (or if you want: All files) 
  13191.     Enter Drive and Directory of C:\PC3270W\ 
  13192.     Select OK 
  13193.  
  13194.      (These are the defaults) 
  13195.  
  13196.  7. On the Add PC/3720 to Program Manager screen: 
  13197.  
  13198.     Select WIN-OS/2 Main in the to Group section 
  13199.     Select OK 
  13200.  
  13201.     There will be three more pop-up screens with information about the 
  13202.     installation completion, just select OK on each of them to complete the 
  13203.     installation. 
  13204.  
  13205. Note:   If you are configuring 802.2 LAN installations, you will probably get a 
  13206.         PCS121 error at the completion of the install. This is because the 
  13207.         install process is trying to update the CONFIG.SYS file and is having 
  13208.         problems. Just continue with installing the corrective service diskette 
  13209.         in the next section. 
  13210.  
  13211.  
  13212. ΓòÉΓòÉΓòÉ 23.1.1. Installing the Corrective Service Diskettes ΓòÉΓòÉΓòÉ
  13213.  
  13214. Now install the PC/3270 Corrective Service Diskette(s). 
  13215.  
  13216.  1. From the Program Manager Menu Bar: 
  13217.  
  13218.     Select File 
  13219.     Select Run 
  13220.     Insert PC/3270 Corrective Service Diskette in the A: drive 
  13221.     On the command line enter: A:INSTCSD 
  13222.  
  13223.     You will get a pop-up telling you that the CSD will replace files in the 
  13224.     C:\PC3270W\ directory, select OK to continue the update. 
  13225.  
  13226.     When the CSD installation is complete you will get a pop-up telling you 
  13227.     that it is complete, select OK. 
  13228.  
  13229.  2. Close the WIN-OS/2 full-screen session. 
  13230.  
  13231.  3. On the Program Manager menu bar: 
  13232.  
  13233.     Select the Title Bar Icon (upper left corner) 
  13234.     Select Close 
  13235.     Select OK on the Exit WIN-OS/2 pop-up 
  13236.  
  13237. Be sure to read the README.TXT file on the CSD diskette. It will have 
  13238. additional information about the corrective service that might apply to your 
  13239. installation. 
  13240.  
  13241.  
  13242. ΓòÉΓòÉΓòÉ 23.2. Creating a PC/3270 Batch File for OS/2 V2.0 ΓòÉΓòÉΓòÉ
  13243.  
  13244. You now need to check the WIN-OS/2 initialization file and create a batch file 
  13245. for PC/3270. This batch file will be used in the setup of the PC/3270 desktop 
  13246. object later. 
  13247.  
  13248.  
  13249. ΓòÉΓòÉΓòÉ 23.2.1. Checking the WIN-OS/2 Initialization File ΓòÉΓòÉΓòÉ
  13250.  
  13251. The PC/3270 Windows installation should have updated the WIN.INI file. Check 
  13252. the C:\OS2\MDOS\WINOS2\WIN.INI file for the following: 
  13253.  
  13254.  .
  13255.  .
  13256.  .
  13257. [PCS3270]
  13258. DIR=C:\PC3270W\
  13259.  .
  13260.  .
  13261.  .
  13262.  
  13263.  
  13264. ΓòÉΓòÉΓòÉ 23.2.2. Creating the PC/3270-OS/2 Batch File ΓòÉΓòÉΓòÉ
  13265.  
  13266. We will now create a new batch file that can be used to start any of the 
  13267. various PC/3270 configurations. Depending on the communications link you are 
  13268. using, you may need to execute a PC3270W.BAT file to invoke the WIN-OS/2 
  13269. environment. The other types of links invoke WIN-OS/2 directly. This batch file 
  13270. will check for the presence of PC3270W.BAT and use it if it exists. 
  13271.  
  13272. Create the file C:\PC3270W\PC3270WO.BAT 
  13273.  
  13274.    @ECHO OFF
  13275.    IF EXIST PC3270W.BAT GOTO TSR
  13276.    WINOS2.COM PCS3270.EXE
  13277.    GOTO END
  13278.    :TSR
  13279.    PC3270W.BAT PCS3270.EXE
  13280.    :END
  13281.  
  13282.  
  13283. ΓòÉΓòÉΓòÉ 23.2.3. Communications Manager Mouse Support (CMMOUSE) ΓòÉΓòÉΓòÉ
  13284.  
  13285. IBM CM Mouse Support (product 5799-PNJ, RPQ P85221) provides advanced mouse 
  13286. support for Personal Communications/3270 in the Windows environment. CM Mouse 
  13287. must be started in the same VDM (Virtual DOS Machine) as PC/3270. To achieve 
  13288. this, the batch files used to start Windows and PC/3270 must be modified as 
  13289. described in the following sections. 
  13290.  
  13291. When PC/3270 is modified as described below, CM Mouse will automatically be 
  13292. started when you start PC/3270.  CM Mouse may display a "waiting for PC/3270 to 
  13293. start..." message since both CM Mouse and PC/3270 will begin running at the 
  13294. same time.  After PC/3270 starts and the host sessions are established, CM 
  13295. Mouse will automatically continue its initialization (the message "reading BDF 
  13296. files..." will be displayed).  It is suggested that you enable the automatic 
  13297. startup feature of PC/3270 so that the host sessions are established 
  13298. automatically. 
  13299.  
  13300. Installing CM Mouse 
  13301.  
  13302. Install CM Mouse from any OS/2 or DOS command line as described in the CM Mouse 
  13303. documentation.  Note that you must have installed CSD 4002 or later for 
  13304. PC/3270. 
  13305.  
  13306. The following sections assume that you have installed CM Mouse in the default 
  13307. C:\CMMOUSE directory.  If you install CM Mouse in some other directory, change 
  13308. the directory names as necessary. 
  13309.  
  13310. Modifying the PC/3270 OS/2 V2.0 Batch File 
  13311.  
  13312. The batch file created above should be modified as follows (the file is 
  13313. C:\PC3270W\PC3270WO.BAT). The changes from above are shown with this emphasis 
  13314. below: 
  13315.  
  13316.     @ECHO OFF
  13317.     IF EXIST PC3270W.BAT GOTO TSR
  13318.     WINOS2.COM C:\CMMOUSE\CMMOUSE.EXE,C:\PC3270W\PCS3270.EXE
  13319.     GOTO END
  13320.     :TSR
  13321.     PC3270W.BAT C:\PC3270W\PCS3270.EXE
  13322.     :END
  13323.  
  13324. Modifying the PC/3270 Execution Batch File 
  13325.  
  13326. Depending on the configuration of your system, there may or may not be a 
  13327. PC/3270 execution batch file on your system.  If there is, it is named 
  13328. C:\PC3270W\PC3270WX.BAT.  If this file does not exist on your system then skip 
  13329. this section. 
  13330.  
  13331. Modify the line of this batch file which runs the WIN-OS/2 program (the 
  13332. modification is shown with this emphasis): 
  13333.  
  13334.     C:\OS2\MDOS\WINOS2\WIN C:\CMMOUSE\CMMOUSE.EXE,%1 %2 %3 %4 %5 %6 %7 %8 %9
  13335.  
  13336. Note that there must be no blank spaces on either side of the comma character. 
  13337. There may be other commands in this file; do not modify them. 
  13338.  
  13339.  
  13340. ΓòÉΓòÉΓòÉ 23.3. Setting up PC/3270 as a WIN-OS/2 Application ΓòÉΓòÉΓòÉ
  13341.  
  13342. Now we have PC/3270 installed and the batch and configuration files ready to 
  13343. go. The next step is to create an object on the desktop and set the various 
  13344. attributes of that object. 
  13345.  
  13346.  
  13347. ΓòÉΓòÉΓòÉ 23.3.1. Create a New Object on the Desktop ΓòÉΓòÉΓòÉ
  13348.  
  13349. To create an object for PC/3270, from the desktop: 
  13350.  
  13351.  Open the Template Folder 
  13352.  Select the Program folder with the right mouse button 
  13353.  Select Create Another from the pop-up 
  13354.  Select OS/2 Desktop from the list of folders 
  13355.  Select Create on the bottom the window 
  13356.  
  13357. The Program-Settings folder will now open for this new object so you can set 
  13358. the attributes in the next section. 
  13359.  
  13360.  
  13361. ΓòÉΓòÉΓòÉ 23.3.2. Setting the Attributes of the PC/3270 WIN-OS/2 Object ΓòÉΓòÉΓòÉ
  13362.  
  13363. Now we have to set the attributes of this new object so that it will start 
  13364. PC/3270 as a Windows application. 
  13365.  
  13366. The following are common to all types of connections. The LAN 802.2 and 3174 
  13367. Peer connections will require some additional steps covered at the end (they 
  13368. need some unique device drivers). 
  13369.  
  13370. You are now on the Program Settings for this Object. This is where you need to 
  13371. set up all of the various attributes that will go with this object. You move 
  13372. around by selecting the proper tab on this notebook. 
  13373.  
  13374.  1. Select the Program tab (should be selected): 
  13375.  
  13376.     Enter a Path and File name of: C:\PC3270W\PCS3270.EXE 
  13377.     Enter a Working Directory of: C:\PC3270W 
  13378.  
  13379.      The Icon should now show the PC/3270 Icon. If not then the path and/or 
  13380.      file name is entered incorrectly. 
  13381.  
  13382.  2. Select the General tab: 
  13383.  
  13384.     Enter a Title of: PC/3270 for WIN-OS/2 (or something else you want) 
  13385.  
  13386.  3. Select the Window tab: 
  13387.  
  13388.     Select Minimize window to desktop for the Minimized Button Behavior (this 
  13389.      will minimize the PC/3270 Icon on the desktop instead of the minimized 
  13390.      window viewer folder). 
  13391.  
  13392.  4. Select the Session Tab: 
  13393.  
  13394.     Select WIN-OS/2 window. 
  13395.     Select Separate session (this will allow PC/3270 to load required 
  13396.      Terminate-Stay-Resident (TSR) programs even if it is not the first 
  13397.      WIN-OS/2 session started). 
  13398.     Select WIN-OS/2 settings. 
  13399.  
  13400.  5. From the WIN-OS/2 settings screen: 
  13401.  
  13402.     Select and set COM_HOLD=ON (for async only). 
  13403.     Select and set DOS_HIGH=ON (allows DOS to be loaded above 640KB). 
  13404.     Select and set DOS_UMB=ON (allows TSR programs to be loaded in upper 
  13405.      memory blocks). 
  13406.     Select and set IDLE_SENSITIVITY=100 (disables the idle detection so 
  13407.      PC/3270 will get the maximum amount of processor time). 
  13408.     Select and set KBD_ALTHOME_BYPASS=ON (so PA2 will work). 
  13409.     Select and set DOS_SHELL to: 
  13410.  
  13411.             C:\OS2\MDOS\COMMAND.COM C:\OS2\MDOS /P  /C C:\PC3270W\PC3270WO.BAT
  13412.  
  13413.      Note:   This is the batch file we created in the previous step. 
  13414.  
  13415.  
  13416.     Select SAVE when complete. 
  13417.  
  13418.  6. Close the Settings window: 
  13419.  
  13420.     Select the Title Bar Icon (small PC/3270 Icon in upper left hand corner of 
  13421.      Settings screen), or press F10. 
  13422.     Select Close to close and save these object changes. 
  13423.  
  13424.  
  13425. ΓòÉΓòÉΓòÉ 23.4. Additional Setup for LAN Connections ΓòÉΓòÉΓòÉ
  13426.  
  13427. The LAN connections require some additional device drivers in order to 
  13428. communicate with the adapter. 
  13429.  
  13430. Note:   When PC/3270 is using a LAN Adapter, then that adapter cannot be used 
  13431.         by any other program on this workstation. At this time there is no 
  13432.         virtual IEEE 802.2 device driver available to allow adapter sharing, 
  13433.         which means that PC/3270 will have exclusive use of this adapter when 
  13434.         it is running. 
  13435.  
  13436. We will set up PC/3270 to use a Token-Ring adapter. You could set it up to use 
  13437. Ethernet, PC Network or 3174 Peer (LAN over Coax) using the same technique. 
  13438.  
  13439.  
  13440. ΓòÉΓòÉΓòÉ 23.4.1. Installing LAN Support Program and RESETOKN.SYS ΓòÉΓòÉΓòÉ
  13441.  
  13442. You must install the PC LAN Support program so that you will have the proper 
  13443. device drivers. You should use the COPY command to copy the device drivers from 
  13444. the LSP 1.2x diskette in drive A:. 
  13445.  
  13446.    MD C:\LSP
  13447.    COPY A:\DXMA0MOD.SYS C:\LSP
  13448.    COPY A:\DXMC0MOD.SYS C:\LSP
  13449.  
  13450. Additionally you should get the RESETOKN.SYS device driver and copy it into the 
  13451. C:\LSP directory. 
  13452.  
  13453.    COPY A:\RESETOKN.SYS C:\LSP
  13454.  
  13455. The RESETOKN.SYS device driver will reset the Token-Ring adapter when it is 
  13456. invoked, it is not required, but suggested. This will allow you to stop and 
  13457. restart PC/3270 in a Token-Ring environment. 
  13458.  
  13459. RESETOKN.SYS can be retrieved from: 
  13460.  
  13461.  CompuServe by issuing GO IBMOS2 and downloading RESTKN.ZIP from SECTION 17, 
  13462.   IBMFILES. 
  13463.  IBM National Support Center Bulletin Board System by downloading RESTKN.ZIP. 
  13464.  Internal IBM users can GET the RESTKN PACKAGE from OS2TOOLS. 
  13465.  
  13466.  
  13467. ΓòÉΓòÉΓòÉ 23.4.2. Updating the PC/3270 Object for LAN Device Drivers ΓòÉΓòÉΓòÉ
  13468.  
  13469. What we will be doing is updating the WIN-OS/2 session attributes to add some 
  13470. DEVICE_DRIVER statements. 
  13471.  
  13472. From the OS/2 Desktop: 
  13473.  
  13474.  Select the PC/3270 Icon with the right mouse button. 
  13475.  Select the arrow just to the right of Open. 
  13476.  Select Settings. 
  13477.  
  13478.   You are now on the Program Settings for the PC/3270 object, just like we were 
  13479.   before when we did the majority of the setup above. 
  13480.  Select the Sessions tab. 
  13481.  Select WIN-OS/2 settings. 
  13482.  From the WIN-OS/2 settings screen: 
  13483.  
  13484.    - Select and Set DOS_DEVICE and enter the following in the Value window: 
  13485.  
  13486.              C:\LSP\RESETOKN.SYS
  13487.              C:\LSP\DXMA0MOD.SYS 001
  13488.              C:\LSP\DXMC0MOD.SYS 400000010135
  13489.              C:\PC3270W\PCS802.SYS V=N
  13490.  
  13491.      Note:   "400000010135" is the locally administered address (LAA) for the 
  13492.              LAN, it may be optional and different for your installation. 
  13493.  
  13494.  
  13495.    - Select SAVE when complete. 
  13496.  
  13497.  Close the Settings window. 
  13498.  
  13499.    - Select the Title Bar Icon (small PC/3270 Icon in upper left hand corner of 
  13500.      Settings screen), or press F10. 
  13501.    - Select Close to close and save these object changes. 
  13502.  
  13503.  
  13504. ΓòÉΓòÉΓòÉ 23.5. Operating PC/3270 for Windows under OS/2 V2.0 ΓòÉΓòÉΓòÉ
  13505.  
  13506. You should now have the PC/3270 for Windows Icon on the desktop and are ready 
  13507. to start PC/3270. Just open the object and wait for the sessions to start. 
  13508.  
  13509. For some of the configurations you will get the Communications/3270 Manager 
  13510. screen, and you will have to Start Communications. If you want, you can go into 
  13511. Profile and set Start Automatically so that it will automatically start the 
  13512. sessions subsequently. 
  13513.  
  13514. You will see that you get the A, B, etc., sessions as well as a 
  13515. Communications/3270 Manager session. All of the Icons look the same, but they 
  13516. have different titles. If you minimize them, they will go to the Minimized 
  13517. Window Viewer folder. 
  13518.  
  13519.  
  13520. ΓòÉΓòÉΓòÉ 23.5.1. A Couple of Warnings and Suggestions ΓòÉΓòÉΓòÉ
  13521.  
  13522.  If you have an XGA or 8514/A display adapter, be sure that you had selected 
  13523.   VGA mode for WIN-OS/2 during OS/2 installation. This is mandatory for PC/3270 
  13524.   for Windows to run in a "seamless" WIN-OS/2 VDM. 
  13525.  
  13526.  Remember that the adapter is in use EXCLUSIVELY by PC/3270. This is true for 
  13527.   all of the adapters (DFT, SDLC, LAN). 
  13528.  
  13529.  If you included the RESETOKN.SYS mentioned earlier then you can shutdown and 
  13530.   restart PC/3270 Token-Ring connections. This package also comes with a 
  13531.   RESETOKN.EXE file that can be used to close the adapter so other applications 
  13532.   can use it, if desired. You would have to invoke this after shutting down 
  13533.   PC/3270 or it will become very upset! 
  13534.  
  13535.  If you get message PCS232 - PCS802.SYS Module not found, you probably set up 
  13536.   the DOS_DEVICE statements incorrectly, or forgot to install the LSP code. 
  13537.  
  13538.  If you get message PCS234 - The Current Configuration File Does Not Include 
  13539.   Valid TSR Information; when you click on the CM/3370 Manager Start 
  13540.   Communication Icon, then you either forgot to update the DOS_SHELL option, or 
  13541.   have a bad PC3270WO.BAT. The problem is that the PC3270W.BAT does exist, but 
  13542.   was not executed (loads the TSRs). 
  13543.  
  13544.  If you get message PCS212 - PC/3270 is installed incorrectly, you probably 
  13545.   installed PC/3270 under Windows 3.0 running in enhanced mode. You will need 
  13546.   to reinstall PC/3270. 
  13547.  
  13548.  If you open the new PC/3270 object and it closes after a few seconds, then 
  13549.   you probably have the DOS_SHELL or the PC3270 Batch file PC3270WO.BAT set up 
  13550.   incorrectly. 
  13551.  
  13552.  If you open the PC/3270 object a second time, and it just sits there or hangs 
  13553.   the machine, you might not have set Separate Session set on or you did not 
  13554.   include the RESETOKN.SYS driver. 
  13555.  
  13556.  Sometimes OS/2 does not know when a Windows application closes. Therefore 
  13557.   when you do a shutdown, the desktop thinks that the application is still 
  13558.   running. When you start OS/2 the next time, it will automatically start the 
  13559.   application again. 
  13560.  
  13561.   There is a way around this: 
  13562.  
  13563.    - Bring up the OS/2 Window List (Ctrl-Esc). 
  13564.    - Select the line that says WIN-OS/2 and has PC/3270 listed under it. 
  13565.    - Click the right mouse button. 
  13566.    - Select Close, this will close all the applications, and the WIN-OS/2 
  13567.      environment. 
  13568.  
  13569.   A side effect is that all Windows Applications that OS/2 thinks are still 
  13570.   open will be officially closed. The applications will no longer have hash 
  13571.   marks over their icons. You can now Shutdown gracefully. 
  13572.  
  13573.   You can circumvent this effect by running Personal Communications/3270 for 
  13574.   Windows a separate WIN-OS/2 session. 
  13575.  
  13576.  
  13577. ΓòÉΓòÉΓòÉ 23.5.2. Limitations ΓòÉΓòÉΓòÉ
  13578.  
  13579. The limitations of running Personal Communications/3270 for Windows under OS/2 
  13580. V2.0 should be noted: 
  13581.  
  13582.  1. If Personal Communications/3270 for Windows is started after OS/2 V2.0 LAN 
  13583.     requester is running, it will cause the LAN requester to fail. 
  13584.  
  13585.  2. File transfer can only be performed from the virtual DOS machine in which 
  13586.     Personal Communications/3270 for Windows is running. 
  13587.  
  13588.  3. The adapter card used by Personal Communications/3270 for Windows for 
  13589.     communication with the host cannot be accessed by another program. Since 
  13590.     the 802.2 device driver is not (yet) virtualized, Personal 
  13591.     Communications/3270 for Windows has direct access to the Token-Ring card. 
  13592.     No other LAN services can be made available via another program using the 
  13593.     same card. 
  13594.  
  13595.     Note:   A possible solution for this problem could be to install a second 
  13596.             Token-Ring adapter. However, this will not help because the LAN 
  13597.             Support Program will try to initialize both Token-Ring adapters, if 
  13598.             installed. This can cause trouble for OS/2 device drivers which are 
  13599.             using the second adapter at the same time. 
  13600.  
  13601.  4. You need to run the program RESETOKN.EXE before starting this virtual DOS 
  13602.     machine and after closing this virtual DOS machine. This will reset the 
  13603.     adapter and make it available to another process. If you don't use 
  13604.     RESETOKN, the Personal Communications/3270 for Windows virtual DOS machine 
  13605.     cannot be stopped and restarted, as the IEEE 802.2 device driver is not 
  13606.     (yet) virtualized. 
  13607.  
  13608.  
  13609. ΓòÉΓòÉΓòÉ 24. Running DOS PC Support/400 in OS/2 V2.0 ΓòÉΓòÉΓòÉ
  13610.  
  13611. This appendix covers the instructions for the installation of DOS PC 
  13612. Support/400under OS/2 V2.0, and the restrictions for this environment. 
  13613.  
  13614. In DOS PC Support/400, the Shared Folders device driver is a block device 
  13615. driver. Since the virtual DOS machine of OS/2 V2.0 does not support block 
  13616. device drivers, DOS PC Support/400 must be run in a Virtual Machine Boot 
  13617. session. We will describe below the setup of DOS PC Support/400 in a DOS 5.0 
  13618. Virtual Machine Boot. The process creates a DOS 5.0 boot diskette,  which is 
  13619. then copied as a diskette image to the hard disk. This enables the DOS PC 
  13620. Support/400 Virtual Machine Boot to be started from the hard disk rather than a 
  13621. diskette. 
  13622.  
  13623.  
  13624. ΓòÉΓòÉΓòÉ 24.1. Installation Preparation ΓòÉΓòÉΓòÉ
  13625.  
  13626. The following are required before starting the installation: 
  13627.  
  13628.  1. Basic DOS PC Support/400 Installation diskette(s) V2R1 or later 
  13629.  
  13630.  2. DOS 5.0 bootable diskette, formatted with the system (/S) option 
  13631.  
  13632.  3. If using a LAN, the LAN Support Program diskette 1.22 or later 
  13633.  
  13634.  4. DOS PC Support/400 Installation and Administration Guide (SC41-0006). 
  13635.  
  13636.  
  13637. ΓòÉΓòÉΓòÉ 24.2. Installation ΓòÉΓòÉΓòÉ
  13638.  
  13639. If DOS PC Support/400 is to use a LAN, we must first install the LAN device 
  13640. drivers on the DOS 5.0 diskette with the LAN Support Program diskette. This 
  13641. puts the DXMx0MOD.SYS  drivers in the CONFIG.SYS of the DOS 5.0 diskette. 
  13642.  
  13643.  1. Run the DOS PC Support/400 installation program. 
  13644.  
  13645.     a) During the installation, you will be asked which "Drive your personal 
  13646.        computer starts from?". This must be answered as "A" drive. 
  13647.  
  13648.     b) When you are asked to "Insert diskette from which you will start the 
  13649.        personal computer in drive A.", insert the DOS 5.0 diskette. 
  13650.  
  13651.        Further instructions on how to use the Install program are in the guide. 
  13652.  
  13653.  2. When the DOS PC Support/400 installation program has stopped, add the 
  13654.     following line to the top of the CONFIG.SYS file on the DOS 5.0 diskette: 
  13655.  
  13656.         DEVICE=C:\OS2\MDOS\FSFILTER.SYS
  13657.  
  13658.     NOTE: if you have installed OS/2 V2.0 on a drive other than C:, use that 
  13659.     drive letter instead. 
  13660.  
  13661.     FSFILTER.SYS is a special DOS device driver that allows a Virtual Machine 
  13662.     Boot session to access (read/write) all OS/2 V2.0 drives (both FAT and 
  13663.     HPFS). Without this driver, the Virtual Machine Boot session can only READ 
  13664.     from OS/2 V2.0 FAT drives. 
  13665.  
  13666.  3. Create a Virtual Machine Boot diskette image file from your DOS 5.0 
  13667.     diskette with the following steps: 
  13668.  
  13669.     a) Put your DOS 5.0 diskette in drive A: 
  13670.  
  13671.     b) At a OS/2 or DOS command prompt, enter: 
  13672.  
  13673.               VMDISK A: C:\PCSDOS50.DSK
  13674.  
  13675.        This will create a file that contains an image of the DOS 5.0 diskette. 
  13676.  
  13677.  4. Create a new VDM object on the Workplace Shell desktop. 
  13678.  
  13679.     a) Locate the Templates folder. It is usually an icon on the Workplace 
  13680.        Shell. 
  13681.  
  13682.     b) Open the Templates folder. 
  13683.  
  13684.     c) Locate the Program icon template. 
  13685.  
  13686.     d) Drag the Program icon template on to the desktop. This will cause the 
  13687.        Program Settings notebook to appear. 
  13688.  
  13689.     e) Enter an asterisk "*" in the Path and file name field. 
  13690.  
  13691.     f) Select the Session notebook tab. 
  13692.  
  13693.     g) Select either DOS full screen or DOS window and then select the DOS 
  13694.        Settings... button. 
  13695.  
  13696.     h) Select the DOS_STARTUP_DRIVE list item and then enter: 
  13697.  
  13698.               C:\PCSDOS50.DSK
  13699.  
  13700.        in the upper right entry field. 
  13701.  
  13702.     i) Select the Save button to save the DOS settings and return. 
  13703.  
  13704.     j) Select the General notebook tab. 
  13705.  
  13706.     k) Change the Title field to DOS PC Support/400 or your own name describing 
  13707.        the new object. 
  13708.  
  13709.     l) Close the Settings notebook by double clicking on the system menu in the 
  13710.        upper left corner of the window. 
  13711.  
  13712. Now there will be a DOS PC Support/400 icon on your desktop. Double click on it 
  13713. to bring up DOS PC Support/400. 
  13714.  
  13715.  
  13716. ΓòÉΓòÉΓòÉ 24.3. Restrictions ΓòÉΓòÉΓòÉ
  13717.  
  13718. The following general restrictions apply to this environment: 
  13719.  
  13720.  1. Only the Basic DOS (Not Extended DOS) version of DOS PC Support/400 is 
  13721.     supported. 
  13722.  
  13723.  2. Only V2R1 or greater versions of DOS PC Support/400 are supported. 
  13724.  
  13725.  3. Only a single DOS PC Support/400 virtual DOS machine(VDM) is supported. 
  13726.  
  13727.  4. If OS/2 Version 2.0 Extended Services is used, the OS/2 version of PC 
  13728.     Support must be run instead of the Basic DOS version, as the device drivers 
  13729.     used by DOS PC Support/400 requires exclusive control of any adapter used 
  13730.     for DOS communications. 
  13731.  
  13732.  5. When a Virtual Machine Boot session is started from a diskette image file, 
  13733.     the "A:" drive within the VDM will refer to the diskette image file. If you 
  13734.     would like to access the physical drive "A:", OS/2 V2.0 supplies a program 
  13735.     called FSACCESS.EXE to do this. See the online command reference for more 
  13736.     information. 
  13737.  
  13738.  6. The default hot-key of Alt-ESC is reserved for OS/2 V2.0 and must be 
  13739.     changed in order to have hot-key support. This can be done by  using the 
  13740.     Configure WorkStation Function (CFGWSF.EXE) program to create/change a 
  13741.     keyboard profile. 
  13742.  
  13743.  7. For LAN connections, only the LAN Support Program Version 1.22 or later is 
  13744.     supported. 
  13745.  
  13746.  8. If you decide to close the DOS PC Support/400 Virtual Machine Boot session 
  13747.     while the LAN router is active, you must wait two minutes before starting 
  13748.     up the VDM again. This time will allow the card to reset itself on the LAN. 
  13749.     The DOS PC Support/400 VDM will appear to hang if it is restarted too soon. 
  13750.  
  13751.  9. For an SDLC router, if you decide to close the Virtual Machine Boot session 
  13752.     while the router is active, you must stop the router or power off the modem 
  13753.     first. Failing to do so could cause a system trap to occur. 
  13754.  
  13755. 10. The ASYNC router is NOT supported at this time. 
  13756.  
  13757.  
  13758. ΓòÉΓòÉΓòÉ 25. Running Lotus 1-2-3 in a VDM ΓòÉΓòÉΓòÉ
  13759.  
  13760. Lotus 1-2-3 is one of the most popular DOS programs available. Many customers 
  13761. use one or another of the several versions on the market. Frequently, they 
  13762. encounter problems of insufficient RAM to process their large spreadsheets. 
  13763.  
  13764. This appendix discusses how to set up and run Lotus 1-2-3 Release 2.3 (which 
  13765. can use EMS memory), and Lotus 1-2-3 Release 3.1+ (which uses DPMI memory) in a 
  13766. virtual DOS machine in OS/2 V2.0 to handle large spreadsheets. 
  13767.  
  13768.  
  13769. ΓòÉΓòÉΓòÉ 25.1. Lotus 1-2-3 Release 2.3 ΓòÉΓòÉΓòÉ
  13770.  
  13771. In order to configure EMS support for the virtual DOS machine, we must ensure 
  13772. that a contiguous 64KB block of RAM is available in the address range 640KB to 
  13773. 1MB to be used as the EMS Page Frame (Refer to Memory Extender Support). Do the 
  13774. following: 
  13775.  
  13776.  1. Boot the system with the reference diskette and in Set Configuration take a 
  13777.     look at the memory map. 
  13778.  
  13779.  2. Print or make a note of the memory addresses of the different hardware 
  13780.     device drivers. For example, 3270 Connection may have an address of 0D6000H 
  13781.     (D6000 hexadecimal). 
  13782.  
  13783.     If a 64KB contiguous block cannot be found the DOS Settings for the virtual 
  13784.     DOS machine will have to be used to make a block available. 
  13785.  
  13786.  3. Reboot under OS/2 V2.0. 
  13787.  
  13788.  4. Open the Templates folder and drag a Program icon to the desktop. 
  13789.  
  13790.     The Settings notebook should open. 
  13791.  
  13792.  5. Enter the following in the Path and file name field (change the path 
  13793.     according to your installation): 
  13794.  
  13795.         D:\123r23\123.exe
  13796.  
  13797.  6. The Working Directory should be the same as the path in the Path and file 
  13798.     name field. 
  13799.  
  13800.  7. Select the Session tab. 
  13801.  
  13802.  8. Set session type as DOS Full Screen (Window will work, but slower) 
  13803.  
  13804.  9. Open DOS Settings. 
  13805.  
  13806. 10. Select DOS_UMB and set it to OFF  (default is ON) 
  13807.  
  13808. 11. Select MEMORY_INCLUDE_REGIONS and enter the addresses that you do not need 
  13809.     for this virtual DOS machine. For example, the 3270 Connection card is not 
  13810.     used by Lotus 1-2-3 Release 2.3, so the device driver address for it 
  13811.     (D6000) can be entered. Refer to the online help for the syntax. 
  13812.  
  13813. 12. Select EMS_MEMORY_LIMIT and set it to accommodate the largest expected 
  13814.     spreadsheet. 
  13815.  
  13816. 13. Select SAVE to save the settings. 
  13817.  
  13818. 14. Select the General tab and change the Title to "Lotus 1-2-3 Release 2.3". 
  13819.  
  13820. 15. Close the Settings notebook. 
  13821.  
  13822. The Lotus 1-2-3 Release 2.3 icon should now be available for use. 
  13823.  
  13824.  
  13825. ΓòÉΓòÉΓòÉ 25.2. Lotus 1-2-3 Release 3.1+ ΓòÉΓòÉΓòÉ
  13826.  
  13827. The Lotus 1-2-3 Release 3.1+ install program checks to make sure it is running 
  13828. in true DOS. The OS/2 V2.0 virtual DOS machine DOS Settings allow you to create 
  13829. a DOS session that returns a simulated DOS value to the Lotus INSTALL.EXE and 
  13830. therefore fool it into thinking it has the real DOS. 
  13831.  
  13832.  1. Open the OS/2 System folder. 
  13833.  
  13834.  2. Find and open the Command Prompts folder. 
  13835.  
  13836.  3. Drag a copy of the DOS command prompt to your desktop. 
  13837.  
  13838.  4. Open the Settings notebook. 
  13839.  
  13840.  5. Select the Sessions tab. 
  13841.  
  13842.  6. Select DOS Settings. 
  13843.  
  13844.  7. Select DOS_VERSION and enter: 
  13845.  
  13846.         INSTALL.EXE,3,30,255
  13847.  
  13848.     in the list box. 
  13849.  
  13850.  8. Save the settings and close the Settings notebook. 
  13851.  
  13852.  9. Open the new DOS command prompt session and run A:INSTALL from the prompt. 
  13853.  
  13854. 10. After installation completes, discard the icon in the shredder. 
  13855.  
  13856. Lotus 1-2-3 Release 3.1+ is usually started in DOS with the 123.EXE program. 
  13857. However, 123.EXE is a FAMILY API EXE file; it can be used to start both the DOS 
  13858. as well as the OS/2 version. Consequently, if we try to add a program icon to 
  13859. the desktop to start 123.EXE, OS/2 V2.0 will detect that it can be started as 
  13860. an OS/2 program and gray out the option to run it in a DOS session on the 
  13861. Session page of the Settings notebook. You also cannot use the Migrate 
  13862. Applications utility to add 123.EXE to the desktop, as it is detected as an 
  13863. OS/2 program. 
  13864.  
  13865. This problem is overcome by starting 123.EXE from a DOS batch file. We then 
  13866. enter the DOS batch file name in the Path and file name field of the Program 
  13867. page of the Settings notebook. 
  13868.  
  13869. Add the Lotus 1-2-3 Release 3.1+ icon to the desktop as follows: 
  13870.  
  13871.  1. Create a 123R31.BAT file with any Editor. 
  13872.  
  13873.     The batch file should contain the following (Adjust 123MEMSIZE to 
  13874.     accommodate the largest spreadsheet): 
  13875.  
  13876.             SET DOS16M = 2
  13877.             SET 123MEMSIZE=2048
  13878.             123.EXE
  13879.  
  13880.  2. Place this file in the Lotus 1-2-3 Release 3.1+ subdirectory. 
  13881.  
  13882.  3. Open the Templates folder and drag a Program icon to the desktop. 
  13883.  
  13884.     The Settings notebook should open. 
  13885.  
  13886.  4. Enter the following in the Path and file name field (change the path 
  13887.     according to your installation): 
  13888.  
  13889.         D:\123R3\123R31.BAT
  13890.  
  13891.  5. The Working Directory should be the same as the path in the Path and file 
  13892.     name field. 
  13893.  
  13894.  6. Select the Session tab. 
  13895.  
  13896.  7. Set session type as DOS full screen (Window will work, but slower). 
  13897.  
  13898.  8. Select DOS_VERSION and enter: 
  13899.  
  13900.         123DOS.EXE,3,30,255
  13901.         123.EXE,3,30,255
  13902.         LOTUS.EXE,3,30,255
  13903.  
  13904.     in the list box. 
  13905.  
  13906.  9. Save the settings and close the Settings notebook. 
  13907.  
  13908. 10. Select DPMI_MEMORY_LIMIT. Adjust the value to be about 2MB larger than 
  13909.     123MEMSIZE defined in the DOS batch file 123R31.BAT. 
  13910.  
  13911. 11. Select SAVE to save the settings. 
  13912.  
  13913. 12. Select the Generaltab and change the Title to "Lotus 1-2-3 Release 3.1+". 
  13914.  
  13915. 13. Close the Settings notebook. 
  13916.  
  13917. The Lotus 1-2-3 Release 3.1+ icon should now be available for use. 
  13918.  
  13919.  
  13920. ΓòÉΓòÉΓòÉ 26. Memory Extender Architectures ΓòÉΓòÉΓòÉ
  13921.  
  13922. This appendix provides an overview of the LIM EMS Version 4.0 and LIMAXMS 
  13923. memory extender architectures, for those readers who require an understanding 
  13924. of their implementation and who are not already familiar with the design of 
  13925. these memory extenders. 
  13926.  
  13927.  
  13928. ΓòÉΓòÉΓòÉ 26.1. Expanded Memory Specification (EMS) ΓòÉΓòÉΓòÉ
  13929.  
  13930. The expanded memory specification (EMS) was initially developed by two 
  13931. companies, Lotus and Intel.  Microsoft later joined the consortium, and the 
  13932. specification has since become known as LIM EMS. 
  13933.  
  13934. A number of versions of the EMS specification have been produced.  LIM EMS 
  13935. Version 3.0 required a 64KB window anywhere in the area between 640KB and 1MB, 
  13936. and provided up to 8MB of expanded memory.  As more hardware adapters with 
  13937. their own ROM were installed, it was often difficult to find a free 64KB 
  13938. contiguous memory area for the mappable window. 
  13939.  
  13940. A revised version of the EMS specification has been produced, known as LIM EMS 
  13941. Version 4.0.  This version allows DOS applications to allocate and access up to 
  13942. 32MB of expanded memory in up to 255 expanded memory objects. Regions of these 
  13943. objects can be mapped into the 8086 address space (below 1MB) allowing DOS 
  13944. applications to access large address spaces at the cost of having to explicitly 
  13945. remap the memory that is to be accessed.  Alternate page tables for quick 
  13946. switches among mappings, function calls with remapping, and numerous ways to 
  13947. save and update mappings or move or exchange memory contents are provided. 
  13948.  
  13949.  
  13950. ΓòÉΓòÉΓòÉ 26.1.1. EMS Overview ΓòÉΓòÉΓòÉ
  13951.  
  13952. The EMS Specification is a document that describes 30 functions and many 
  13953. subfunctions, which are called by DOS applications using software interrupt 
  13954. 67h.  EMS creates memory objects in expanded memory and then provides mappings 
  13955. such that addressing below 1MB accesses parts of these expanded memory objects. 
  13956. At any given time, the 8086 application can directly access only 1MB of memory, 
  13957. but additional expanded memory can quickly be mapped into the addressable 1MB 
  13958. range.  In effect, parts of the 8086 address space become moving "windows" into 
  13959. larger virtual memory objects. 
  13960.  
  13961. The Intel 8086/8088 processors need special EMS memory adapters and are not 
  13962. part of the following discussion.  Special EMS memory adapters are also 
  13963. required for 80286 machines.  While certain software-based EMS emulation 
  13964. packages are available, which utilize the normal extended memory area above 1MB 
  13965. for that purpose, those emulations are relatively slow and unstable compared to 
  13966. "real" EMS hardware adapters.  However, neither of the two types of EMS 
  13967. solutions was supported under previous versions of OS/2. 
  13968.  
  13969.  
  13970. ΓòÉΓòÉΓòÉ 26.1.2. EMS Functions ΓòÉΓòÉΓòÉ
  13971.  
  13972. The following is a brief summary of LIM EMS Version 4.0 functions.  Note that 
  13973. it is a summary of the EMS specification itself, and not of its implementation 
  13974. under OS/2 Version 2.0. 
  13975.  
  13976. Allocating/Reallocating/Deallocating Expanded Memory 
  13977.  
  13978. An allocation request can be made for a number of expanded memory pages and, if 
  13979. successful, a handle is returned.  This handle is then used by the application 
  13980. to reallocate or deallocate memory. 
  13981.  
  13982. Mapping Expanded Memory 
  13983.  
  13984. Logical pages in an object can be mapped into physical address ranges 
  13985. addressable by the 8086 processor.  A mapping indicates the relation between 
  13986. EMS physical pages and <EMS Handle, EMS Logical Page> pairs that the 
  13987. application requires.  One example would be to map an expanded memory video 
  13988. buffer (EMS logical pages) to the mappable window (EMS physical pages) to 
  13989. create a video image in expanded memory.  An EMS service request can then be 
  13990. used to move the image from expanded memory to screen memory. 
  13991.  
  13992. A single logical page can be mapped to multiple physical pages. This is used by 
  13993. programs such as Lotus 1-2-3. When a single logical page is mapped to multiple 
  13994. physical pages, a write to any of these physical pages writes to the same 
  13995. expanded memory.  An application can write to one address and then read the 
  13996. results from another address.  This feature can be used to provide independent 
  13997. mappings to a shared structure for multiple modules. To implement this 
  13998. aliasing, multiple page registers must all point to the same memory.  This 
  13999. leads to a requirement for the memory manager to support aliasing of page table 
  14000. entries. 
  14001.  
  14002. A physical page can be unmapped.  Reads/writes to unmapped memory do not kill 
  14003. the application, but an application cannot depend on reading what it has 
  14004. previously written.  LIM EMS specifies that a program must unmap mappable 
  14005. windows before allowing another program to run, in order to protect the memory 
  14006. mapped by the first program. 
  14007.  
  14008. The specification does not stipulate what happens to programs that touch 
  14009. unmapped memory, only that the physical pages are "inaccessible for reading and 
  14010. writing".  One possible implementation is to map unmapped pages to nonexistent 
  14011. physical pages (the Microsoft Windows/386 product does this). Another 
  14012. alternative is to map them to physical ROM.  This can lead to problems, 
  14013. however, on some machines that cache ROM.  The safest alternative is to use a 
  14014. single physical page of memory. 
  14015.  
  14016. Information Calls 
  14017.  
  14018. An application may obtain information about the EMS resources available, 
  14019. current mappings, and handle usage.  In a multiprogramming environment or where 
  14020. TSRs are loaded, however, this information may be out of date by the time it is 
  14021. used.  For instance, an application may determine the amount of LIM memory 
  14022. available, but before getting the opportunity to request an allocation, a TSR 
  14023. may request EMS memory.  The application would find less memory available than 
  14024. expected. 
  14025.  
  14026. Saving/Restoring Mappings 
  14027.  
  14028. Several calls are available for an application to obtain data that can later be 
  14029. returned to EMS to restore a mapping.  For some calls, this information is 
  14030. saved internally by the EMS driver.  For others, it is returned to the 
  14031. application. 
  14032.  
  14033. One type of save operation automatically saves the registers pointing to the 
  14034. first 64KB of the mappable window to an internal EMS buffer associated wtih an 
  14035. EMS handle supplied by the user.  Typically, this is used by a TSR to save and 
  14036. restore the current mappable window by saving to an EMS buffer associated with 
  14037. a handle owned by the TSR.  Other save operations return either complete or 
  14038. partial information to the application, which the application can later provide 
  14039. to restore memory mappings.  Still other calls allow EMS the option to store 
  14040. register information on the application's stack.  There are five different ways 
  14041. to save and restore registers in addition to techniques for setting the 
  14042. registers. 
  14043.  
  14044. Alternate Register Sets 
  14045.  
  14046. This is an optional feature of EMS.  Mapping can be done to any of a number of 
  14047. register sets.  The application can then switch the active register set. The 
  14048. effect is similar to switching page tables under OS/2 Version 2.0.  Alternate 
  14049. Register Sets can be protected by the first application to claim a protection 
  14050. key.  Only the application with the key will be allowed to claim a register set 
  14051. or switch the active one unless no one claims the key or the process with the 
  14052. key permits others to use the alternate sets. 
  14053.  
  14054. This feature is typically used by DOS extenders such as Microsoft Windows. 
  14055. Switching memory during a task switch can be accomplished by turning on 
  14056. permission for changing register sets using the permission key, switching the 
  14057. current register set, and turning alternate set permission off.  Even when 
  14058. alternate register sets are not supported, save and restore operations for 
  14059. register set 0 are simulated with data passed to and from the application. 
  14060.  
  14061. DMA Register Sets 
  14062.  
  14063. This is an optional feature of EMS.  These register sets allow association of a 
  14064. DMA channel with a register set.  All DMA on that channel is remapped through 
  14065. the associated DMA register set allowing EMS remapping during DMA. When this 
  14066. feature is not supported, remapping of register sets may be delayed until DMA 
  14067. completes. 
  14068.  
  14069. Program Execution 
  14070.  
  14071. This function allows an application to execute a procedure or subroutine which 
  14072. lies in an expanded memory area not currently mapped into the 8086 address 
  14073. space.  EMS will perform a remap to bring the procedure or routine into the 
  14074. 8086 address space, and pass control to the specified entry point. This may be 
  14075. accomplished in either of two ways: 
  14076.  
  14077.  JUMP passes control to the specified entry point but makes no provision for 
  14078.   return. 
  14079.  
  14080.  CALL passes control to the specified entry point and after the application 
  14081.   routine returns, sets up an address mapping that will be in effect when 
  14082.   control returns to the calling routine.  The return address is that of the 
  14083.   instruction following the INT 67h service request. 
  14084.  
  14085. This function allows applications to store code in expanded memory. 
  14086.  
  14087. Data Movement 
  14088.  
  14089. Copy and exchange services provide data movement between any combination of 
  14090. conventional or expanded memory.  The start of a region of expanded memory is 
  14091. indicated by handle, logical page and offset.  The memory being affected need 
  14092. not be currently mapped into the 8086 address space.  Overlapping copies 
  14093. succeed without corrupting data, and a return code indicates overlap to the 
  14094. application.  Exchange operations may not overlap. 
  14095.  
  14096. This function allows applications to conveniently move portions of expanded 
  14097. objects around in expanded memory, or move them to or from conventional memory, 
  14098. without having to first remap the objects into the 8086 address space. 
  14099.  
  14100. EMM Protection 
  14101.  
  14102. Limited protection is available.  The first application that requests a key can 
  14103. turn enable or disable access to alternate and DMA register sets. There is no 
  14104. protection for memory objects.  Any application can determine all handles in 
  14105. use and perform any operations on them.  Within a single EMS implementation, a 
  14106. badly behaved application can wreak havoc on any application using EMS. 
  14107.  
  14108. For example, one Windows application may write over the memory of any other. 
  14109. This is consistent with the general lack of protection in the DOS environment, 
  14110. where applications have free access to the machine's physical memory. 
  14111.  
  14112. OS Support 
  14113.  
  14114. On power up, an EMM implementation which supplies mappable conventional memory 
  14115. allocates all mappable conventional memory to handle 0 and maps it in.  This is 
  14116. typically all memory above the memory on the system board up to 640KB.  This 
  14117. occurs before the operating system starts up and allows programs like Windows 
  14118. to remap conventional memory.  Programs that remap conventional memory are 
  14119. required to reset the mapping before returning to the operating system.  EMS 
  14120. does not enforce this, however. 
  14121.  
  14122.  
  14123. ΓòÉΓòÉΓòÉ 26.2. Extended Memory Specification (XMS) ΓòÉΓòÉΓòÉ
  14124.  
  14125. The LIMA Extended Memory Specification (XMS) Version 2.0 provides a standard 
  14126. interface for the use of extended memory on Intel 80286, 80386, and 80486 
  14127. computers.  XMS functions allow moving code and data objects into extended 
  14128. memory, and from extended memory to base memory. 
  14129.  
  14130.  
  14131. ΓòÉΓòÉΓòÉ 26.2.1. XMS Overview ΓòÉΓòÉΓòÉ
  14132.  
  14133. LIMA XMS is a specification for an extended memory programming interface on the 
  14134. Intel 80286, 80386, and 80486 processors.  The XMS specification is a short 
  14135. document offering 18 functions which are accessed through a control function 
  14136. supplied by the XMS driver.  All XMS functions are executed by calling the 
  14137. control function, the address of which is obtained by a call to INT 2Fh. 
  14138. Arguments are passed in registers. 
  14139.  
  14140. It does not specify hardware or processor speeds and does not depend on any 
  14141. particular operating system.  (The technique for determining if XMS is present 
  14142. is based on the DOS interrupt vector 02Fh, but can be easily provided in any OS 
  14143. that supports XMS.) 
  14144.  
  14145. XMS manages three different kinds of memory: 
  14146.  
  14147.  1. High Memory Area (HMA) is the first 64KB of extended memory. By activating 
  14148.     the A20 address line, a real mode application can access memory in this 
  14149.     region as if it were conventional memory.  The HMA is exactly 65520 bytes 
  14150.     (64KB - 16 bytes) long. 
  14151.  
  14152.  2. Extended Memory Blocks (EMBs) are blocks of extended memory which lie 
  14153.     beyond the HMA.  They are not accessible from real mode and serve only for 
  14154.     data storage.  Memory can be moved between extended and conventional memory 
  14155.     by a memory move function provided by the XMS driver.  Without leaving V86 
  14156.     mode, code cannot be executed from EMBs and they serve only for data 
  14157.     storage. The specification offers up to 64 megabytes of extended memory, 
  14158.     divided into as many as 255 blocks. 
  14159.  
  14160.  3. Upper Memory Blocks (UMBs) are regions of memory between 640KB and 1MB 
  14161.     which may be used like conventional memory.  The size and number of UMBs is 
  14162.     dependent upon the hardware configuration.  XMS provides a standard means 
  14163.     of obtaining and using them.  Once a UMB is allocated, its memory is always 
  14164.     available, and since the memory lies in conventional memory, code may be 
  14165.     executed in it at any time. 
  14166.  
  14167. The major characteristics of these three types of expanded memory are 
  14168. summarized in Table "Types of Expanded Memory". The three different types of 
  14169. expanded memory are mapped into physical memory in different ways by the XMS 
  14170. driver, as shown in Figure "Memory Map of Extended Memory (HMA, UMA, and 
  14171. EMBs)". 
  14172.  
  14173.  
  14174. ΓòÉΓòÉΓòÉ 26.2.2. XMS Functions ΓòÉΓòÉΓòÉ
  14175.  
  14176. The following is a brief summary of LIMA XMA functions.  This is a summary of 
  14177. the specification itself, and not of its implementation in OS/2 Version 2.0. 
  14178.  
  14179. Determining XMS Presence 
  14180.  
  14181. Calling interrupt 2Fh with AH=43h and AL=00h will return AL=80h if an XMS 
  14182. driver is installed.  Calling interrupt 2Fh with AH=43h and AL=10h will return 
  14183. the far entry point address of the XMS control function in ES:BX.  The control 
  14184. function must be called as a far procedure. 
  14185.  
  14186. Requesting/Releasing HMA 
  14187.  
  14188. There is only one 64KB HMA and it cannot be divided.  An application which 
  14189. requests the HMA is given the entire HMA, even if it uses only part of it. When 
  14190. an application has successfully requested the HMA, it is guaranteed sole access 
  14191. to it until it is released.  As part of the request, the application indicates 
  14192. how much of the HMA it expects to use.  If this value does not exceed a 
  14193. user-specified threshhold, the request is denied.  This test is performed so 
  14194. that the HMA is given only to applications which make substantial use of the 
  14195. HMA. 
  14196.  
  14197. A20 Address Line Control 
  14198.  
  14199. Two pairs of functions are used to control the status of the A20 address line. 
  14200. The application may control the A20 address line either globally or locally. 
  14201. Global control is used by programs which have control of the HMA. Local control 
  14202. is used by programs which need to access extended memory directly.  Global 
  14203. settings are kept in a simple on/off flag, whereas local control uses a 
  14204. counter.  Hence, the number of "local disable" calls must equal the number of 
  14205. "local enable" calls before the A20 line is actually disabled, whereas a single 
  14206. "global disable" call suffices to disable the A20 address line, regardless of 
  14207. how many "global enable" calls have been made. 
  14208.  
  14209. Allocating/Reallocating/Deallocating Extended Memory Blocks 
  14210.  
  14211. An allocation request can be made for a particular-sized EMB (in kilobyte 
  14212. units) and, if successful, an EMB handle is returned.  This handle is used to 
  14213. reallocate, lock, unlock, or deallocate memory.  It is also used to move memory 
  14214. between the EMB and conventional memory or other EMBs.  An EMB may be locked 
  14215. and while locked, it may not be reallocated or deallocated, nor may its base 
  14216. address change. 
  14217.  
  14218. Allocating/Deallocating Upper Memory Blocks 
  14219.  
  14220. An allocation request can be made for a particular-sized UMB (in paragraph 
  14221. units) and, if successful, the segment number of the UMB is returned, as well 
  14222. as the actual size of the UMB.  This segment number is also used to deallocate 
  14223. the UMB.  UMBs may not be resized. 
  14224.  
  14225. Information Calls 
  14226.  
  14227. The application can obtain information about the XMS memory resources available 
  14228. and handle usage.  In a multiprogramming environment or where TSRs are loaded, 
  14229. this information may be out of date before being used. For instance, an 
  14230. application may determine the amount of XMS memory available, but before 
  14231. getting the opportunity to request an allocation, a TSR may request XMS memory. 
  14232. The application would find less memory available than expected. 
  14233.  
  14234. Data Movement 
  14235.  
  14236. A move or copy function provides data movement between any combination of 
  14237. conventional or extended memory.  The memory being affected need not be locked. 
  14238. The start of a region of extended memory is indicated by handle and offset. 
  14239. Overlapping copies will succeed provided the source address is below the 
  14240. destination address.  Moreover, blocks being moved must be of even length; word 
  14241. alignment is not required, however.  This function is the only method of 
  14242. accessing an extended memory block without leaving real mode. 
  14243.  
  14244.  
  14245. ΓòÉΓòÉΓòÉ 27. Multiple Virtual DOS Machines Lab Sessions ΓòÉΓòÉΓòÉ
  14246.  
  14247. These lab sessions provide practical demonstrations of OS/2 Version 2.0's 
  14248. Multiple Virtual DOS Machine capabilities.  The individual topics that will be 
  14249. covered in this lab are: 
  14250.  
  14251.  VDM Configuration 
  14252.  
  14253.  The Virtual DOS Machine Manager 
  14254.  
  14255.  Using the Clipboard 
  14256.  
  14257.  VDM Use of the Speaker 
  14258.  
  14259.  VDM Interprocess Communications 
  14260.  
  14261.  
  14262. ΓòÉΓòÉΓòÉ 27.1. Requirements ΓòÉΓòÉΓòÉ
  14263.  
  14264. The following are required to do the labs: 
  14265.  
  14266.  OS/2 Version 2.0 
  14267.  
  14268.  DOS Version 5.0 
  14269.  
  14270.  CLIPVIEW.EXE program, in the productivity folder 
  14271.  
  14272.  The following programs in your C:\ITSCLABS directory: 
  14273.  
  14274.    - ENVIRON.EXE program 
  14275.  
  14276.    - GRAPHIC.EXE program 
  14277.  
  14278.    - INT19.EXE program 
  14279.  
  14280.    - QENV.BAT program 
  14281.  
  14282.    - QCONFIG.EXE program 
  14283.  
  14284.    - SOUND.EXE program 
  14285.  
  14286.    - PMCHART.EXE program 
  14287.  
  14288.    - PaintBrush program 
  14289.  
  14290.    - WinGif program 
  14291.  
  14292.  
  14293. ΓòÉΓòÉΓòÉ 27.2. Lab Session 1: VDM Configuration ΓòÉΓòÉΓòÉ
  14294.  
  14295. In this exercise, students will create a new group folder and configure a VDM 
  14296. within that folder according to specified parameters. 
  14297.  
  14298. First you will create a new group named Test on the desktop. Copy the OS/2 Full 
  14299. Screen item from the Command Prompts folder to the newly created folder using 
  14300. the drag mechanism. 
  14301.  
  14302. Next, you will change the "OS/2 Full Screen" item in the folder "Test" to the 
  14303. following parameters: 
  14304.  
  14305.  Change the title to "My Window" 
  14306.  Match the parameters and the program type to start a DOS window. 
  14307.  Deselect device driver ANSI.SYS 
  14308.  512KB DOS memory size 
  14309.  Select an environment size of 200 bytes 
  14310.  1024KB expanded memory. 
  14311.  2048KB extended memory. 
  14312.  
  14313. Finally, you will perform some checks to verify the changes. 
  14314.  
  14315.  Use the QCONFIG.EXE program to check the memory size manipulation. 
  14316.  
  14317.  Verify that the environment size is approximately 200 bytes. 
  14318.  
  14319.  
  14320. ΓòÉΓòÉΓòÉ 27.2.1. Steps ΓòÉΓòÉΓòÉ
  14321.  
  14322. Create a new folder: 
  14323.  
  14324.  1. Peel off a folder from the Templates folder. 
  14325.  
  14326.  2. Rename the new folder. 
  14327.  
  14328.  3. Select an OS/2 full-screen object by single-clicking with the left mouse 
  14329.     button on "OS/2 full-screen" in the Command Prompts folder. 
  14330.  
  14331.  4. Press and hold Ctrl. 
  14332.  
  14333.  5. With the mouse pointer on OS/2 full-screen press and hold the right mouse 
  14334.     button. After pressing the mouse button release the Ctrl key. When you move 
  14335.     the mouse, you "drag" the selected application around the desktop.  As long 
  14336.     as the mouse pointer is within an area, where you might drop the 
  14337.     application, the mouse pointer appears as an icon. Otherwise, the mouse 
  14338.     pointer appears as a "No Go" sign. 
  14339.  
  14340.  6. Move the mouse pointer to the client area of your new folder and release 
  14341.     the right mouse button. 
  14342.  
  14343.  7. Bring up the "Context Menu", by clicking on it with mouse button 2. 
  14344.  
  14345.  8. Open the "Settings". 
  14346.  
  14347.  9. Change the Program Title. 
  14348.  
  14349. 10. Select "DOS Windowed" as the Program type. 
  14350.  
  14351. 11. Press push button "DOS Settings". 
  14352.  
  14353. 12. Select "DOS memory size (KB)" and change it to 512KB. 
  14354.  
  14355. 13. Append to the "DOS shell" property the following without the quotes: 
  14356.     "/E:200". 
  14357.  
  14358. 14. Change the "EMS memory limit (KB)" to 1024KB. 
  14359.  
  14360. 15. Change the "XMS memory limit (KB)" to 2048KB. 
  14361.  
  14362. 16. Press push button "Save" to save your new DOS Settings. 
  14363.  
  14364. 17. To close that window and save your changes you must double-click on the 
  14365.     system icon. 
  14366.  
  14367. Now, as your "My Window" object has been updated, proceed as mentioned in the 
  14368. Expected Results 
  14369.  
  14370.  
  14371. ΓòÉΓòÉΓòÉ 27.2.2. Expected Results ΓòÉΓòÉΓòÉ
  14372.  
  14373. After successfully completing the exercise, check the result by double-clicking 
  14374. on "My Window" in the folder Test.  A VDM should start with a DOS command 
  14375. prompt, which should look like the following example, if you have a PROMPT 
  14376. statement included in the AUTOEXEC.BAT file like the one shown on Requirements 
  14377. section of this lab. 
  14378.  
  14379. .[37;40m[DOS] C:\>
  14380.  
  14381. If the DOS prompt looks like this, the ANSI.SYS is not active.  In this case, 
  14382. you did well. Otherwise, try once more, because the ANSI.SYS driver is still 
  14383. active. 
  14384.  
  14385. Now start the program QCONFIG.EXE using the following syntax: 
  14386.  
  14387. QCONFIG /P
  14388.  
  14389. from within the DOS command prompt.  Don't worry about the appearance of the 
  14390. current command prompt.  The output of QCONFIG.EXE should look like this: 
  14391.  
  14392. Operating System: OS/2 Standard Edition Version 2.00 CSD Level
  14393. Date & Time     : 01/14/1992  17:20
  14394. Product Number  : 8573-121
  14395. Model ID        : F8            Sub-Model ID    : 0B
  14396. BIOS Revision   : 00            BIOS Date       : 01/18/89
  14397. Machine Type    : IBM PS/2 Model P70
  14398. Processor       : Intel 80386         Processor Speed : 20 Mhz
  14399. Estimated Speed : 17.6 Mhz
  14400. CoProcessor     : None
  14401. Bus Type        : Micro Channel 32-Bit Bus
  14402. Keyboard Type   : Enhanced
  14403. Mouse Type      : PS/2 Mouse
  14404. Equipment       : 1 Parallel Port(s)
  14405.                 : 1 Serial Port(s)
  14406.                 : 1 Diskette Drive(s)
  14407.                 : 1 Fixed Disk(s)
  14408.                 : Pointing Device
  14409. Primary Video   : VGA
  14410. Diskette Drive 1: 3.50"  - 1.44M - 80 Track - Type 4
  14411. Fixed Disk 1    :  115 MB  =  117760 KB  =  120586240 bytes
  14412. Local -  Drive C:  Size   5096K =    4.9M    Avail   2636K =    2.5M
  14413. Local -  Drive D:  Size  23472K =   22.9M    Avail   6126K =    5.9M
  14414. Local -  Drive E:  Size  45956K =   44.8M    Avail  16986K =   16.5M
  14415. Local -  Drive F:  Size   8152K =    7.9M    Avail   7636K =    7.4M
  14416. Total Memory    :  8064 KB = 7.8 MB
  14417. Conventional    :   513 KB      Unallocated     :   476 KB
  14418. Extended Memory :  7424 KB      Unallocated     :     0 KB
  14419. Expanded Memory :  1280 KB      Unallocated     :  1024 KB
  14420. Total Slots     : 3      System (DISK)   : 1      User Slots      : 2
  14421. Expansion Slot 1:  * No Adapter Present
  14422. Expansion Slot 2: ID E1FF - IBM 3270 Connection Version B
  14423. Expansion Slot 3: ID DF9F - IBM Integrated Fixed Disk Controller
  14424. --- QCONFIG Ver 1.47 (Jan  3 1992)  by Jeff Muir  IBM Copyright 1991 (c)---
  14425.  
  14426. C:\>
  14427.  
  14428.  1. If a base memory size of 512KB, and an expanded (EMS) memory size of 1024KB 
  14429.     is reported, then you've done well. 
  14430.  
  14431.  2. Next, check the environment size with the ENVIRON.EXE and QENV.BAT files. 
  14432.     Execute QENV.BAT shown in Figure "QENV.BAT Batch File" and the following 
  14433.     will occur: 
  14434.  
  14435.     The environment space is filled. 
  14436.     The ENVIRON.EXE file is executed. 
  14437.     The environment settings are shown. 
  14438.     The dummy environment settings are removed. 
  14439.  
  14440.  
  14441. ΓòÉΓòÉΓòÉ 27.2.3. Optional ΓòÉΓòÉΓòÉ
  14442.  
  14443. There is a way to check the environment size without the use of special 
  14444. programs like ENVIRON.EXE and QENV.BAT.  It is not simple because we cannot 
  14445. display the environment size by using a command. 
  14446.  
  14447. The SET command shows all the current settings in the environment of 
  14448. COMMAND.COM.  The environment size defaults to approximately 150 bytes. 
  14449.  
  14450.  1. To make sure that the environment buffer is full, issue some environment 
  14451.     settings like: 
  14452.  
  14453.         SET a=12345678901234567890
  14454.         SET b=12345678901234567890
  14455.         SET c=12345678901234567890
  14456.          :    :   =       :                   :
  14457.          :    :   =       :                   :
  14458.          :    :   =       :                   :
  14459.  
  14460.  2. Execute the SET commands until you encounter an error message "Out of 
  14461.     environment space". 
  14462.  
  14463.  3. Now, save the environment settings in a file.  The syntax for this action 
  14464.     is as follows: 
  14465.  
  14466.         SET  >  MYENV.TXT
  14467.  
  14468.  4. Check the size of the new file (MYENV.TXT) with the DIR command: 
  14469.  
  14470.         DIR  MYENV.TXT
  14471.  
  14472.  5. From the file size displayed by the DIR command, subtract the number of 
  14473.     lines in MYENV.TXT. 
  14474.  
  14475. This is necessary because each line in the file is terminated by CrLF (0D0A) 
  14476. characters and the environment strings are terminated by a single character 
  14477. (hex 0) only. 
  14478.  
  14479. If you can use this method and calculate a size at 200, you did very, very 
  14480. well. 
  14481.  
  14482. Figure "C Source Code for ENVIRON.EXE" 
  14483.  
  14484.  
  14485. ΓòÉΓòÉΓòÉ 27.3. Lab Session 2: Reboot Virtual DOS Machine ΓòÉΓòÉΓòÉ
  14486.  
  14487. When running DOS 3.3, 4.0, etc., if an INT 19h is called, the result is a 
  14488. reboot of the entire system.  The objective of this lab is to show that the 
  14489. execution of an INT 19h in an OS/2 VDM is handled by the Virtual DOS Machine 
  14490. Manager (VDMM).  What happens in OS/2 Version 2.0 when a program running in a 
  14491. VDM issues an INT 19h? 
  14492.  
  14493.  
  14494. ΓòÉΓòÉΓòÉ 27.3.1. Steps ΓòÉΓòÉΓòÉ
  14495.  
  14496. In this exercise, you are required to start a DOS application program that 
  14497. issues an interrupt INT 19h. 
  14498.  
  14499. Perform the following steps: 
  14500.  
  14501.  1. Open a DOS Windowed session. 
  14502.  
  14503.  2. Execute INT19.EXE. 
  14504.  
  14505.  3. When prompted, select ENTER to issue the INT 19h. 
  14506.  
  14507. Keep in mind what happened so far. Then proceed with the following steps: 
  14508.  
  14509.  1. Open an OS/2 Windowed session. 
  14510.  
  14511.  2. Execute INT19.EXE. 
  14512.  
  14513.  3. When prompted, select ENTER to issue the INT 19h. 
  14514.  
  14515. Did the results meet your expectations? 
  14516.  
  14517.  
  14518. ΓòÉΓòÉΓòÉ 27.3.2. Expected Results ΓòÉΓòÉΓòÉ
  14519.  
  14520. After you have successfully completed the exercise, please note that the 
  14521. interrupt INT 19h did not reboot the system. Instead, the interrupt was routed 
  14522. to the Virtual DOS Machine Manager (VDMM) by the General Protection Handler. 
  14523. The VDMM terminates the VDM when receiving the INT 19h. 
  14524.  
  14525. If you start a DOS application program from an OS/2 command prompt, control is 
  14526. passed to the Virtual DOS Machine Manager which then starts the VDM. Execution 
  14527. of INT 19h does NOT terminate the OS/2 session. Instead, INT 19h terminates the 
  14528. VDM session only.  Control is returned to the OS/2 session. 
  14529.  
  14530. The INT19.EXE is a compiled BASIC program.  The source code is shown in Figure 
  14531. "INT19.BAS Source Code." 
  14532.  
  14533.  
  14534. ΓòÉΓòÉΓòÉ 27.4. Lab Session 3 - The Clipboard Viewer ΓòÉΓòÉΓòÉ
  14535.  
  14536. In this exercise, you are using the clipboard support for the VDM environment. 
  14537. Partial and complete copying of text and graphical screen contents is the main 
  14538. task of this exercise as follows: 
  14539.  
  14540.  1. Fill a VDM windowed session with text data (DIR /W) and copy the screen 
  14541.     contents to the clipboard. Use the Clipboard Viewer to check your results. 
  14542.  
  14543.  2. Create some graphics in VDM windowed session (GRAPHIC.EXE) and copy a part 
  14544.     of the graphics to the clipboard.  Again check the Clipboard Viewer. 
  14545.  
  14546.  3. Copy text (more than one line!) from the clipboard into EDLIN. 
  14547.  
  14548.  
  14549. ΓòÉΓòÉΓòÉ 27.4.1. Steps ΓòÉΓòÉΓòÉ
  14550.  
  14551. First step: 
  14552.  
  14553.  Start Clipboard Viewer. 
  14554.  
  14555.  Create a VDM windowed session. 
  14556.  
  14557.  Put some text in the VDM, for example, use the DIR /W command. 
  14558.  
  14559.  Switch to the Presentation Manager screen group and click on the VDM's icon. 
  14560.  
  14561.  Select "Copy all" to copy the screen contents to the clipboard. 
  14562.  
  14563.  Check the Clipboard Viewer window which now should contain the copied text. 
  14564.  
  14565.  Check if you can paste the content of the clipboard into the PM sample 
  14566.   application PM Chart. 
  14567.  
  14568. Second step: 
  14569.  
  14570.  Start a VDM windowed session. 
  14571.  
  14572.  In the session, execute the "GRAPHIC.EXE" program. 
  14573.  
  14574.  Click on the system icon and select "Mark" 
  14575.  
  14576.  Select an area within the window with the mouse pointer. 
  14577.  
  14578.  Click on the system icon and select "Copy" 
  14579.  
  14580.  Check the Clipboard Viewer, which now should contain the copied data. 
  14581.  
  14582.  Check if you can paste the content of the clipboard into the PM sample 
  14583.   application PM Chart. 
  14584.  
  14585. Third step: 
  14586.  
  14587.  Start the famous EDLIN editor in a VDM windowed session by entering EDLIN at 
  14588.   the DOS command prompt. 
  14589.  
  14590.  Enter "i1" to put EDLIN into a mode where you can enter text. 
  14591.  
  14592.  Select "Paste" from the system or icon pull-down menu.  The text is copied 
  14593.   from the clipboard character-by-character into the input area of the editor. 
  14594.  
  14595.  
  14596. ΓòÉΓòÉΓòÉ 27.4.2. Expected Results ΓòÉΓòÉΓòÉ
  14597.  
  14598. After you have successfully completed each exercise, the Clipboard Viewer 
  14599. should have presented the text or graphical material you copied from the DOS 
  14600. VDM. 
  14601.  
  14602. GRAPHIC.BAS Source Code 
  14603.  
  14604.  
  14605. ΓòÉΓòÉΓòÉ 27.5. Lab Session 4: VDM Use of the Speaker ΓòÉΓòÉΓòÉ
  14606.  
  14607. In this exercise, you will be asked to run multiple sessions of a DOS 
  14608. application that accesses the speaker system.  The provided SOUND.EXE program 
  14609. plays music.  Note the behavior of the system's sessions in view of the fact 
  14610. that the speaker is a piece of hardware which is not virtualized. 
  14611.  
  14612.  
  14613. ΓòÉΓòÉΓòÉ 27.5.1. Steps ΓòÉΓòÉΓòÉ
  14614.  
  14615.  1. Open a VDM session. 
  14616.  
  14617.  2. Start the program in a VDM session by issuing the following command: 
  14618.  
  14619.         SOUND
  14620.  
  14621.  3. Repeat steps 1 and 2. 
  14622.  
  14623.  
  14624. ΓòÉΓòÉΓòÉ 27.5.2. Expected Results ΓòÉΓòÉΓòÉ
  14625.  
  14626. After starting the first session of the SOUND.EXE program, the speaker will 
  14627. produce some more or less beautiful noise.  Starting a new VDM session with 
  14628. SOUND.EXE will prevent the first session's SOUND.EXE from executing because it 
  14629. is switched to the background (the speaker system is not virtualized!). 
  14630.  
  14631. The second session cannot access the speaker because it is blocked until it is 
  14632. granted access to the speaker. 
  14633.  
  14634. You cannot terminate the program by pressing "Enter" because the "PLAY" 
  14635. instruction (refer to the program listing in Figure "SOUND.BAS Source Code") 
  14636. could not be completed. 
  14637.  
  14638. If the first session is switched back to the foreground, it resumes execution. 
  14639. Pressing "Enter" ends session 1 and now session 2 has access to the speaker and 
  14640. begins to play the music. 
  14641.  
  14642.  
  14643. ΓòÉΓòÉΓòÉ 27.6. Lab Session 5: VDM Interprocess Communications ΓòÉΓòÉΓòÉ
  14644.  
  14645. The objective of this lab is to show that an OS/2 session can exchange data 
  14646. with a DOS session in the same system. 
  14647.  
  14648. In this exercise, you are required to start an OS/2 application program that 
  14649. first creates a number of "named pipes".  The OS/2 application  then waits for 
  14650. a DOS BASIC program to connect to the pipe.  This connection is performed by 
  14651. one thread.  Afterward, the main OS/2 program sends data to change the screen 
  14652. colors of various (connected) DOS BASIC programs. 
  14653.  
  14654.  
  14655. ΓòÉΓòÉΓòÉ 27.6.1. Steps ΓòÉΓòÉΓòÉ
  14656.  
  14657. Perform the following steps: 
  14658.  
  14659.  1. Start the "PIPEOS2.EXE" program within an OS/2 windowed session. 
  14660.  
  14661.     Make certain that you use a numeric parameter to specify the number of 
  14662.     pipes for PIPEOS2.EXE to create. 
  14663.  2. When prompted, start a DOS windowed session. 
  14664.  3. Run the BASIC program called "PIPEDOS.BAS". 
  14665.  
  14666.     Type: 
  14667.  
  14668.         BASICA PIPEDOS
  14669.  
  14670.     at the command line prompt. 
  14671.  4. Return to the OS/2 Windowed session. 
  14672.  5. Enter the letter that corresponds to the color you want the DOS window to 
  14673.     display. 
  14674.  
  14675.     To end the DOS BASIC program, send a "Q" from the OS/2 session. 
  14676.  
  14677.     To end the OS/2 session, enter null. 
  14678.  
  14679.  
  14680. ΓòÉΓòÉΓòÉ 27.6.2. Expected Results ΓòÉΓòÉΓòÉ
  14681.  
  14682. The DOS session should have been able to connect to a single or many named 
  14683. pipe(s) that were created and maintained by the OS/2 session.  Afterward, data 
  14684. was passed to the DOS session(s) in the form of single characters that altered 
  14685. the color of the DOS screen. 
  14686.  
  14687. After you have successfully completed the exercise, please note that this is 
  14688. only one way of communicating between DOS sessions and OS/2 sessions. 
  14689.  
  14690.  
  14691. ΓòÉΓòÉΓòÉ 27.6.3. Source Code PIPEDOS.BAS ΓòÉΓòÉΓòÉ
  14692.  
  14693. 01' **********************************************************/
  14694. 02' **********************************************************/
  14695. 03' ***                                                    ***/
  14696. 04' ***  Program name: PIPEDOS.BAS                         ***/
  14697. 05' ***                                                    ***/
  14698. 06' ***  Created     : 05/10/90                            ***/
  14699. 07' ***                                                    ***/
  14700. 08' ***  Revised     :                                     ***/
  14701. 09' ***                                                    ***/
  14702. 10' ***  Author      : Tim Sennitt                         ***/
  14703. 11' ***                                                    ***/
  14704. 12' ***  Purpose     : To demonstrate the use of a named   ***/
  14705. 13' ***                pipe to communicate to an OS/2      ***/
  14706. 14' ***                session.                            ***/
  14707. 15' ***  Compile     : none                                ***/
  14708. 16' ***                                                    ***/
  14709. 17' ***  Input param : none                                ***/
  14710. 18' ***                                                    ***/
  14711. 22' **********************************************************/
  14712. 23' **********************************************************/
  14713. 30 CLS:KEY OFF
  14714. 40 COLOR 7,0
  14715. 50 OPEN "r",1,"\PIPE\TIMSP",1
  14716. 60 FIELD 1,1 AS A$
  14717. 70 GET 1
  14718. 80 IF A$="B" OR A$="b" THEN BKGRND =  9:GOTO 90   ' Blue
  14719. 81 IF A$="C" OR A$="c" THEN BKGRND =  3:GOTO 90   ' Cyan
  14720. 82 IF A$="G" OR A$="g" THEN BKGRND = 10:GOTO 90   ' Green
  14721. 83 IF A$="P" OR A$="p" THEN BKGRND =  5:GOTO 90   ' Purple
  14722. 84 IF A$="R" OR A$="r" THEN BKGRND = 12:GOTO 90   ' Red
  14723. 85 IF A$="W" OR A$="w" THEN BKGRND =  7:GOTO 90   ' White
  14724. 86 IF A$="Y" OR A$="y" THEN BKGRND =  6:GOTO 90   ' Yellow
  14725. 87 IF A$="Q" OR A$="q" THEN SYSTEM                ' exit system
  14726. 90 COLOR 0,BKGRND:CLS:GOTO 70
  14727.  
  14728.  
  14729. ΓòÉΓòÉΓòÉ 27.6.4. Source Code PIPEOS2.C ΓòÉΓòÉΓòÉ
  14730.  
  14731. /**********************************************************/
  14732. /**********************************************************/
  14733. /***                                                    ***/
  14734. /***  Program name: PIPEOS2.C                           ***/
  14735. /***                                                    ***/
  14736. /***  Created     : 16th May 1990                       ***/
  14737. /***                                                    ***/
  14738. /***  Revised     : 26th February 1992                  ***/
  14739. /***                                                    ***/
  14740. /***  Author      : Tim Sennitt, Dorle Hecker           ***/
  14741. /***                                                    ***/
  14742. /***  Purpose     : To demonstrate the use of an OS/2   ***/
  14743. /***                created named pipe connecting to    ***/
  14744. /***                many DOS sessions                   ***/
  14745. /***                                                    ***/
  14746. /***  Compile     : icc /O+ pipeos2.c                   ***/
  14747. /***  or          : cl386 pipeos2.c                     ***/
  14748. /***                                                    ***/
  14749. /***  Input param : A number between 1 and 255          ***/
  14750. /***                (number of pipe instances)          ***/
  14751. /***                                                    ***/
  14752. /**********************************************************/
  14753.  
  14754. /**********************************************************/
  14755. /***  DEFINES                                           ***/
  14756. /**********************************************************/
  14757. #define INCL_DOS
  14758. #define INCL_DOSNMPIPES
  14759. /**********************************************************/
  14760. /***  INCLUDES and VARIABLES                            ***/
  14761. /**********************************************************/
  14762. #include <os2.h>
  14763. #include <stdlib.h>
  14764. #include <string.h>
  14765.  
  14766. #ifdef __IBMC__
  14767.    void     _System NewThread(ULONG threadArg);
  14768. #else
  14769.    void     NewThread(ULONG threadArg);
  14770. #endif
  14771.    TID      threadID[512];
  14772.    HPIPE    piphand[255];
  14773.    ULONG    threadArg, threadFlags, stack_size;
  14774.    ULONG    outbuffer, inbuffer, timeout, BytesWrit;
  14775.    USHORT   rc, loopsize, i;
  14776.    char     prep_string[11];
  14777. /**********************************************************/
  14778. /***  MAIN PROGRAM                                      ***/
  14779. /**********************************************************/
  14780. main(argc, argv, envp)
  14781. int argc;
  14782. char *argv[];
  14783. char *envp[];
  14784. {
  14785.    BOOL fEnd_Correct=FALSE;
  14786.    threadFlags = 0;          /* start thread immediatly    */
  14787.    stack_size  = 1024;       /* give stack size in bytes   */
  14788.    threadArg   = 1;
  14789.  
  14790.    if ( argc != 2 || (loopsize = atoi(argv[1])) == 0 )
  14791.      { printf("You have not specified the correct bacon size !\n");
  14792.        printf("The syntax is PIPEOS2 NNNN (where NNNN is a \
  14793. number between 1 and255)\n");
  14794.        exit(0);
  14795.       } /*end-if*/
  14796.    for (i = 1; i < loopsize+1; i++)
  14797.      {
  14798.        rc = DosCreateThread(&threadID[i], NewThread, i,
  14799.                             threadFlags, stack_size);
  14800.        if (rc != 0)
  14801.          { printf("DosCreateThread error = %d\n",rc);
  14802.           exit (1);
  14803.          } /*end-if*/
  14804.        printf("Pipe-Thread number %d created\n",i);
  14805.        printf("Please start the DOS client\n");
  14806.      } /*end-for*/
  14807.  
  14808.    printf("Now lets send some data to it......\n");
  14809.  
  14810.    /****************************************************************/
  14811.    /* At this point we will loop getting keyboard input            */
  14812.    /* and writing this to our named pipe (until we enter null)     */
  14813.    /****************************************************************/
  14814.    printf("ENTER\n [B]lue, [C]yan, [G]reen, [P]urple, \
  14815. [R]ed, [W]hite, [Y]ellow or [Q]uit\n");
  14816.    gets(prep_string);
  14817.    while (prep_string[0] != 0)
  14818.      {
  14819.       if (prep_string[0] == 'q' || prep_string[0] == 'Q')
  14820.         { for (i = 1; i < loopsize+1; i++)
  14821.              { rc = DosWrite(piphand[i],
  14822.                              (PVOID)prep_string,
  14823.                              strlen(prep_string),
  14824.                              &BytesWrit);
  14825.                if (rc !=0) printf("Return code from DosWrite=%d\n",rc);
  14826.              } /* end-for */
  14827.           prep_string[0]=0; fEnd_Correct=TRUE;
  14828.         }
  14829.       else
  14830.         { for (i = 1; i < loopsize+1; i++)
  14831.              {
  14832.                rc = DosWrite(piphand[i],
  14833.                              (PVOID)prep_string,
  14834.                              strlen(prep_string),
  14835.                              &BytesWrit);
  14836.                if (rc !=0) printf("Return code from DosWrite=%d\n",rc);
  14837.               } /* end-for */
  14838.           printf("ENTER\n [B]lue, [C]yan, [G]reen, [P]urple, \
  14839. [R]ed, [W]hite, [Y]ellow or [Q]uit\n");
  14840.           gets(prep_string);
  14841.  
  14842.         } /* endif */
  14843.      } /* endwhile */
  14844.  
  14845.    if (!fEnd_Correct)
  14846.      { prep_string[0]='q';
  14847.        rc = DosWrite(piphand[i],
  14848.                      (PVOID)prep_string,
  14849.                      strlen(prep_string),
  14850.                      &BytesWrit);
  14851.        if (rc !=0) printf("Return code from DosWrite=%d\n",rc);
  14852.      }
  14853.  exit(0);
  14854. }
  14855.  
  14856. /****************************************************************/
  14857. /* This is our thread process which creates N named pipes then  */
  14858. /* waits for the DOS sessions to connect to them.               */
  14859. /****************************************************************/
  14860. void NewThread(ULONG threadArg)
  14861. {
  14862.  
  14863. outbuffer = 25;
  14864. inbuffer  = 25;
  14865. timeout   = 200;
  14866.  
  14867.   rc = DosCreateNPipe("\\PIPE\\TIMSP\0",      /* create pipe    */
  14868.                       &piphand[threadArg],
  14869.                       0x4081,
  14870.                       0x0008,
  14871.                       outbuffer,
  14872.                       inbuffer,
  14873.                       timeout);
  14874.   if (rc != 0)
  14875.     { DosBeep(300,200); DosBeep(100,200);
  14876.       exit(1);
  14877.     }
  14878.   DosBeep(300,200); DosBeep(600,200);
  14879.  
  14880. /****************************************************************/
  14881. /* now we wait for our DOS session to connect to us             */
  14882. /****************************************************************/
  14883.  
  14884.   rc = DosConnectNPipe(piphand[threadArg]);
  14885.   if (rc != 0)
  14886.     { DosBeep(100,200);
  14887.       exit(1);
  14888.     }
  14889.   DosBeep(600,200);
  14890.   printf("DOS Session number %d connected\n",threadArg);
  14891. }
  14892.  
  14893.  
  14894. ΓòÉΓòÉΓòÉ 27.7. Lab Session 6: VDM Boot ΓòÉΓòÉΓòÉ
  14895.  
  14896. In this exercise, the student will create a new DOS Full Screen item in the 
  14897. command prompts folder.  This new DOS session will be configured so as to boot 
  14898. a "shrink wrap" version of DOS 5.0 instead of utilizing OS/2 2.0s emulated 
  14899. version of DOS. 
  14900.  
  14901. In order to boot an 8086 kernel into a VDM, that kernel's boot record must be 
  14902. obtained from either a bootable diskette, an image file of that diskette, or a 
  14903. DOS hard disk partition. 
  14904.  
  14905. The student will be required to configure a VDM which can, in turn, boot DOS 
  14906. from any of these sources. 
  14907.  
  14908.  
  14909. ΓòÉΓòÉΓòÉ 27.7.1. Steps ΓòÉΓòÉΓòÉ
  14910.  
  14911.  1. Ask your instructor for a bootable DOS 5.0 diskette. 
  14912.  
  14913.  2. Create an image of this diskette, using the VMDISKS utility. 
  14914.  
  14915.  3. Copy a DOS session object onto the desktop. 
  14916.  
  14917.  4. Change the "DOS_STARTUP Drive" setting for it. 
  14918.  
  14919.  5. Try to boot this image. 
  14920.  
  14921.  6. Create another DOS object, using the C:\ITSCLABS\IBMDOS33.VMB image. 
  14922.  
  14923.  7. Boot this one as well. 
  14924.  
  14925.  8. Study the CONFIG.SYS of these DOS diskettes. 
  14926.  
  14927.  9. Check things like HPFS, XMS, EMS, mouse, etc. 
  14928.  
  14929.  
  14930. ΓòÉΓòÉΓòÉ 27.7.2. Expected Results ΓòÉΓòÉΓòÉ
  14931.  
  14932. The student should learn: 
  14933.  
  14934.  That different versions of DOS can be booted from a VDM. 
  14935.  
  14936.  That these versions can all run parallel. 
  14937.  
  14938.  That these VMBOOT sessions have access to all OS/2 resources. 
  14939.  
  14940.  
  14941. ΓòÉΓòÉΓòÉ 27.8. Lab Session 7: Windows Clipboard ΓòÉΓòÉΓòÉ
  14942.  
  14943. In this exercise, the student will get a feeling for the different clipboard 
  14944. environments and data formats. 
  14945.  
  14946.  
  14947. ΓòÉΓòÉΓòÉ 27.8.1. Steps ΓòÉΓòÉΓòÉ
  14948.  
  14949.  1. Repeat the steps from lab session 3. 
  14950.  
  14951.  2. Start a Windows session. 
  14952.  
  14953.  3. Check the content of the Windows clipboard view utility. 
  14954.  
  14955.  4. Check the content of the PM clipboard view utility. 
  14956.  
  14957.  5. Issue the following commands: 
  14958.  
  14959.           COPY C:\ITSCLABS\PBR*.* C:\OS2\MDOS\WINOS2
  14960.           COPY C:\ITSCLABS\WING*.* C:\OS2\MDOS\WINOS2
  14961.  
  14962.  6. Register the Windows programs PaintBrush and WinGif under the Windows 
  14963.     Program Manager. 
  14964.  
  14965.  7. Start these two programs. 
  14966.  
  14967.  8. You can also install the same program directly under the Workplace Shell. 
  14968.  
  14969.  9. Try to start them as SAVDM, versus MAVDM, and check out the differences. 
  14970.  
  14971. 10. Try to modify the pasted data and copy it back into the clipboard. 
  14972.  
  14973. 11. Try to do the same with metafiles. 
  14974.  
  14975. 12. Try to do the same with text files. 
  14976.  
  14977. 13. Try to pass data from Windows to PM. 
  14978.  
  14979. 14. Start a second Windows Session and repeat the same steps. 
  14980.  
  14981. 15. Switch off the "public clipboards" and check if you can transfer data. 
  14982.  
  14983. 16. Check out the "import" and "export" features of the clipboard viewers. 
  14984.  
  14985. 17. Also check out the system editor, the picture view utility and some other 
  14986.     programs, installed in your productivity folder. 
  14987.  
  14988.  
  14989. ΓòÉΓòÉΓòÉ 27.8.2. Expected Results ΓòÉΓòÉΓòÉ
  14990.  
  14991. The student should gain a better understanding of: 
  14992.  
  14993.  The clipboard architecture. 
  14994.  
  14995.  The different data formats. 
  14996.  
  14997.  Their implications. 
  14998.  
  14999.  What can and what cannot be transferred. 
  15000.  
  15001.  The local versus the public clipboard. 
  15002.  
  15003.  The different capabilities and functions among different PM and Windows 
  15004.   programs. 
  15005.  
  15006.  Starting Windows applications from Windows versus Workplace Shell. 
  15007.  
  15008.  
  15009. ΓòÉΓòÉΓòÉ 28. Glossary ΓòÉΓòÉΓòÉ
  15010.  
  15011.  
  15012. ΓòÉΓòÉΓòÉ 28.1. aliased page ΓòÉΓòÉΓòÉ
  15013.  
  15014. aliased page 
  15015.  
  15016. Under the 80386 paged memory implementation, a physical page in memory which is 
  15017. referenced by two or more sets of page directory/page table entries, thereby 
  15018. enabling different memory addresses to reference the same physical memory 
  15019. location.  This technique is used to implement the 64KB wraparound feature for 
  15020. virtual 8086 mode, and for shared memory implementation. 
  15021.  
  15022.  
  15023. ΓòÉΓòÉΓòÉ 28.2. ANSI ΓòÉΓòÉΓòÉ
  15024.  
  15025. ANSI 
  15026.  
  15027. American National Standards Institute; U.S.-based organization which defines 
  15028. standards for computing devices, protocols, programming languages, etc. 
  15029.  
  15030.  
  15031. ΓòÉΓòÉΓòÉ 28.3. API ΓòÉΓòÉΓòÉ
  15032.  
  15033. API 
  15034.  
  15035. Application Programming Interface; term used to describe the set of functions 
  15036. by which an application may gain access to operating system services. 
  15037.  
  15038.  
  15039. ΓòÉΓòÉΓòÉ 28.4. A20 address line ΓòÉΓòÉΓòÉ
  15040.  
  15041. A20 address line 
  15042.  
  15043. The 21st address line of 80x86 CPUs; the first 20 address lines are numbered 0 
  15044. to 19.  Enabling the A20 address line allows access to the HMA. Note, however, 
  15045. that many applications assume that the A20 address line  is permanently 
  15046. disabled, so all programs which use the A20 address line should disable it when 
  15047. they terminate. 
  15048.  
  15049.  
  15050. ΓòÉΓòÉΓòÉ 28.5. BIOS ΓòÉΓòÉΓòÉ
  15051.  
  15052. BIOS 
  15053.  
  15054. Basic Input/Output System; code which controls the interface between a system 
  15055. and its attached devices, at the hardware level. 
  15056.  
  15057.  
  15058. ΓòÉΓòÉΓòÉ 28.6. bit ΓòÉΓòÉΓòÉ
  15059.  
  15060. bit 
  15061.  
  15062. A binary digit, which may be either zero or one.  Bits are represented within a 
  15063. computing device by the presence or absence of an electrical or magnetic pulse 
  15064. at a particular point, indicating a one or a zero respectively. 
  15065.  
  15066.  
  15067. ΓòÉΓòÉΓòÉ 28.7. block device driver ΓòÉΓòÉΓòÉ
  15068.  
  15069. block device driver 
  15070.  
  15071. A device driver for a block device, which, like a disk drive, reads and writes 
  15072. blocks of data identified by some form of block address. Block devices are 
  15073. identified by a drive letter that DOS assigns (D:, E:, and so on). 
  15074.  
  15075.  
  15076. ΓòÉΓòÉΓòÉ 28.8. Boot Manager ΓòÉΓòÉΓòÉ
  15077.  
  15078. Boot Manager 
  15079.  
  15080. Feature of OS/2 Version 2.0 which allows multiple partitions to exist on fixed 
  15081. disks in the same machine, with a separate operating system on each partition. 
  15082. At boot time, the user may select the desired operating system with which to 
  15083. start the machine. 
  15084.  
  15085.  
  15086. ΓòÉΓòÉΓòÉ 28.9. byte ΓòÉΓòÉΓòÉ
  15087.  
  15088. byte 
  15089.  
  15090. A logical data unit composed of eight binary digits (bits). 
  15091.  
  15092.  
  15093. ΓòÉΓòÉΓòÉ 28.10. CD-ROM ΓòÉΓòÉΓòÉ
  15094.  
  15095. CD-ROM 
  15096.  
  15097. Compact Disk Read-Only Memory; technology where data is stored on an optical 
  15098. disk for reading by a computer system equipped with an appropriate reading 
  15099. device.  CD-ROM storage media may not be updated by the computer system, 
  15100. although certain implementations allow the media to be erased and re-written. 
  15101.  
  15102.  
  15103. ΓòÉΓòÉΓòÉ 28.11. DDE ΓòÉΓòÉΓòÉ
  15104.  
  15105. DDE 
  15106.  
  15107. See Dynamic Data Exchange. 
  15108.  
  15109.  
  15110. ΓòÉΓòÉΓòÉ 28.12. debugging ΓòÉΓòÉΓòÉ
  15111.  
  15112. debugging 
  15113.  
  15114. The process of removing "bugs" or errors from application code. 
  15115.  
  15116.  
  15117. ΓòÉΓòÉΓòÉ 28.13. device driver ΓòÉΓòÉΓòÉ
  15118.  
  15119. device driver 
  15120.  
  15121. Code which handles the translation of generic device commands into specific 
  15122. commands for the required physical device and vice versa, allowing operating 
  15123. system interaction with physical devices attached to the system. 
  15124.  
  15125.  
  15126. ΓòÉΓòÉΓòÉ 28.14. DLL ΓòÉΓòÉΓòÉ
  15127.  
  15128. DLL 
  15129.  
  15130. Dynamic link library; application module containing routines and/or resources, 
  15131. which is dynamically linked with its parent application at load time or runtime 
  15132. rather than during the linkage editing process. The use of DLLs enables 
  15133. decoupling of application routines and resources from the parent program, 
  15134. enhancing code independence, facilitating maintenance and reducing resident 
  15135. memory consumption. 
  15136.  
  15137.  
  15138. ΓòÉΓòÉΓòÉ 28.15. DMA ΓòÉΓòÉΓòÉ
  15139.  
  15140. DMA 
  15141.  
  15142. Direct memory addressing; technique by which transfers to and from system 
  15143. memory are made by an independent control chip rather than by the system's main 
  15144. processor, thereby resulting in improved overall performance. 
  15145.  
  15146.  
  15147. ΓòÉΓòÉΓòÉ 28.16. DOS ΓòÉΓòÉΓòÉ
  15148.  
  15149. DOS 
  15150.  
  15151. Disk operating system; generally used in reference to IBM DOS, the 
  15152. single-tasking 16-bit real-mode operating system designed for Intel 8086 
  15153. processors, and developed by Microsoft Corporation as MS DOS in the early 
  15154. 1980s.  IBM subsequently licensed MS DOS for use on IBM Personal Computer and 
  15155. Personal System/2 machines, and has since undertaken joint development of later 
  15156. versions of the operating system in conjunction with Microsoft. 
  15157.  
  15158.  
  15159. ΓòÉΓòÉΓòÉ 28.17. DOSEM ΓòÉΓòÉΓòÉ
  15160.  
  15161. DOSEM 
  15162.  
  15163. See DOS Emulation. 
  15164.  
  15165.  
  15166. ΓòÉΓòÉΓòÉ 28.18. DOS Emulation ΓòÉΓòÉΓòÉ
  15167.  
  15168. DOS Emulation 
  15169.  
  15170. Subcomponent of the Multiple Virtual DOS Machines component of OS/2 Version 
  15171. 2.0, which provides emulation of DOS software services to applications running 
  15172. in virtual DOS machines. DOS Emulation either provides an equivalent service or 
  15173. invokes the appropriate protected mode service within the OS/2 Version 2.0 
  15174. kernel.  Also known as DOSEM. 
  15175.  
  15176.  
  15177. ΓòÉΓòÉΓòÉ 28.19. DOS partition ΓòÉΓòÉΓòÉ
  15178.  
  15179. DOS partition 
  15180.  
  15181. Fixed disk partition which is formatted for the DOS operating system, typically 
  15182. using the FAT file system. 
  15183.  
  15184.  
  15185. ΓòÉΓòÉΓòÉ 28.20. DOS Protected Mode Interface ΓòÉΓòÉΓòÉ
  15186.  
  15187. DOS Protected Mode Interface 
  15188.  
  15189. Architecture whereby real mode applications may gain access to protected mode 
  15190. services in 80286, 80386 or 80486 systems, by acting as "clients" and making 
  15191. requests to a protected mode "server" task.  DPMI is typically used to enable 
  15192. DOS applications and DOS extenders to function correctly in a multitasking, 
  15193. protected mode environment. 
  15194.  
  15195.  
  15196. ΓòÉΓòÉΓòÉ 28.21. DOS Settings ΓòÉΓòÉΓòÉ
  15197.  
  15198. DOS Settings 
  15199.  
  15200. Function provided by the Multiple Virtual DOS Machines component of OS/2 
  15201. Version 2.0 which allows a user to customize the behavior of a virtual DOS 
  15202. machine to suit the application running in that virtual DOS machine. Settings 
  15203. may be configured once by the user and saved, or applications may provide their 
  15204. own configuration information which is used by the virtual DOS machine upon 
  15205. startup. 
  15206.  
  15207.  
  15208. ΓòÉΓòÉΓòÉ 28.22. DPMI ΓòÉΓòÉΓòÉ
  15209.  
  15210. DPMI 
  15211.  
  15212. See DOS Protected Mode Interface. 
  15213.  
  15214.  
  15215. ΓòÉΓòÉΓòÉ 28.23. dynamic data exchange ΓòÉΓòÉΓòÉ
  15216.  
  15217. dynamic data exchange 
  15218.  
  15219. Interprocess communication protocol used by applications to define dynamic 
  15220. links.  Information updated in one application is automatically reflected in 
  15221. other applications linked to the first application via DDE.  DDE is supported 
  15222. under OS/2 Version 2.0 between Windows applications, between Presentation 
  15223. Manager applications, and between a Windows application and a Presentation 
  15224. Manager application. 
  15225.  
  15226.  
  15227. ΓòÉΓòÉΓòÉ 28.24. EMM ΓòÉΓòÉΓòÉ
  15228.  
  15229. EMM 
  15230.  
  15231. See Expanded Memory Manager. 
  15232.  
  15233.  
  15234. ΓòÉΓòÉΓòÉ 28.25. EMS ΓòÉΓòÉΓòÉ
  15235.  
  15236. EMS 
  15237.  
  15238. Expanded Memory Specification; term used to describe the standard developed by 
  15239. Lotus, Intel and Microsoft for access to expanded memory by real mode 80x86 
  15240. applications. 
  15241.  
  15242.  
  15243. ΓòÉΓòÉΓòÉ 28.26. EMS handle ΓòÉΓòÉΓòÉ
  15244.  
  15245. EMS handle 
  15246.  
  15247. EMS implementations must provide for between 64 and 255 virtual memory objects 
  15248. that can be allocated by EMS applications.  Each memory object is referred to 
  15249. by an associated EMS handle.  A handle to an object is returned when an 
  15250. allocation request is granted.  Allocation is in page sized units.  Handles can 
  15251. be named, allowing sharing between processes. 
  15252.  
  15253.  
  15254. ΓòÉΓòÉΓòÉ 28.27. EMS logical page ΓòÉΓòÉΓòÉ
  15255.  
  15256. EMS logical page 
  15257.  
  15258. Each memory object that is allocated is divided into logical pages. To refer to 
  15259. a particular piece of allocated memory, an application uses a handle to point 
  15260. to the object and a logical page number (starting from 0) to indicate the 
  15261. offset into the object.  Logical pages are always relative to a handle. 
  15262.  
  15263.  
  15264. ΓòÉΓòÉΓòÉ 28.28. EMS page ΓòÉΓòÉΓòÉ
  15265.  
  15266. EMS page 
  15267.  
  15268. Memory is allocated by EMS in page sized units; the standard page size is 16KB. 
  15269. Optionally, an implementation can also offer "raw" pages at whatever size is 
  15270. convenient, although 16KB pages must always be supported.  The raw page size 
  15271. can be set to 16KB to provide only a single page size. 
  15272.  
  15273.  
  15274. ΓòÉΓòÉΓòÉ 28.29. EMS physical page ΓòÉΓòÉΓòÉ
  15275.  
  15276. EMS physical page 
  15277.  
  15278. Just as EMS object handles use logical pages indexed from 0, EMS Physical 
  15279. Segments are also numbered from 0.  A particular address that can have expanded 
  15280. memory mapped into it can be referred to either by the address of a physical 
  15281. segment or by a physical page number.  These are two alternate ways to refer to 
  15282. the same location in the 8086 addressable space.  By convention, physical page 
  15283. 0 is the beginning of the mappable window and succeeding physical pages occupy 
  15284. contiguous pages in the window.  Mappable physical pages in conventional memory 
  15285. (<640KB) follow the mappable window in this numbering scheme.  Note that in EMS 
  15286. terminology a "physical page" does not mean physical memory; it is a way to 
  15287. refer to a particular address below 1MB. 
  15288.  
  15289.  
  15290. ΓòÉΓòÉΓòÉ 28.30. EMS physical segment ΓòÉΓòÉΓòÉ
  15291.  
  15292. EMS physical segment 
  15293.  
  15294. EMS works by remapping addresses in the 1MB 8086 addressable space to expanded 
  15295. memory.  An EMS physical segment is a 16KB block of addresses in the 1MB 8086 
  15296. address space, that can be mapped to part of an expanded memory allocation. 
  15297. When a physical segment is mapped to an EMS logical page, accessing the 
  15298. physical segment accesses the logical page.  Logical pages can only be accessed 
  15299. through physical segments. 
  15300.  
  15301.  
  15302. ΓòÉΓòÉΓòÉ 28.31. EMS register set ΓòÉΓòÉΓòÉ
  15303.  
  15304. EMS register set 
  15305.  
  15306. EMS memory mapping is accomplished by a set of registers, one for each mappable 
  15307. physical page.  A register specifies the current associated logical page. 
  15308. Registers can be unmapped.  EMS optionally offers multiple alternate register 
  15309. sets and DMA register sets.  A register set is, in essence, a page table for 
  15310. mappable windows.  Alternate register sets then, are multiple page tables, only 
  15311. one of which is active at any given time. 
  15312.  
  15313.  
  15314. ΓòÉΓòÉΓòÉ 28.32. enhanced mode ΓòÉΓòÉΓòÉ
  15315.  
  15316. enhanced mode 
  15317.  
  15318. See 386 enhanced mode. 
  15319.  
  15320.  
  15321. ΓòÉΓòÉΓòÉ 28.33. expanded memory ΓòÉΓòÉΓòÉ
  15322.  
  15323. expanded memory 
  15324.  
  15325. Memory in 80x86 processors, typically on special hardware adapters, which is 
  15326. accessed by real mode 8086 applications using the LIM EMS specification.  Up to 
  15327. 32MB of expanded memory are supported by EMS Version 4.0. 
  15328.  
  15329.  
  15330. ΓòÉΓòÉΓòÉ 28.34. Expanded Memory Manager ΓòÉΓòÉΓòÉ
  15331.  
  15332. Expanded Memory Manager 
  15333.  
  15334. Virtual device driver which provides emulation of LIM EMS Version 4.0 services 
  15335. to DOS applications running in virtual DOS machines.  Unlike most virtual 
  15336. device drivers, the Expanded Memory Manager does not use a physical device 
  15337. driver, but interacts directly with the operating system's memory manager to 
  15338. map EMS memory requests into the system's linear address space.  Also known as 
  15339. EMM. 
  15340.  
  15341.  
  15342. ΓòÉΓòÉΓòÉ 28.35. extended memory ΓòÉΓòÉΓòÉ
  15343.  
  15344. extended memory 
  15345.  
  15346. Memory in 80286, 80386, and 80486-based machines which is located above the 1MB 
  15347. address boundary and accessed using the LIMA XMS specification. 
  15348.  
  15349.  
  15350. ΓòÉΓòÉΓòÉ 28.36. extended memory block (EMB) ΓòÉΓòÉΓòÉ
  15351.  
  15352. extended memory block (EMB) 
  15353.  
  15354. Under the XMS specification, a block of extended memory located at or above 1MB 
  15355. + 64KB, which can only be used for data storage. 
  15356.  
  15357.  
  15358. ΓòÉΓòÉΓòÉ 28.37. Extended Memory Manager ΓòÉΓòÉΓòÉ
  15359.  
  15360. Extended Memory Manager 
  15361.  
  15362. Virtual device driver which provides emulation of LIMA XMS services to DOS 
  15363. applications running in virtual DOS machines.  Unlike most virtual device 
  15364. drivers, the Extended Memory Manager does not use a physical device driver, but 
  15365. interacts directly with the operating system's memory manager to map XMS memory 
  15366. requests into the system's linear address space.  Also known as XMM. 
  15367.  
  15368.  
  15369. ΓòÉΓòÉΓòÉ 28.38. FAT ΓòÉΓòÉΓòÉ
  15370.  
  15371. FAT 
  15372.  
  15373. File Allocation Table; term used to describe the file system implemented by DOS 
  15374. and also supported by OS/2.  This file system uses a file allocation table to 
  15375. contain the physical sector addresses of all files on the disk.  The FAT file 
  15376. system is supported by OS/2 Version 2.0, along with the newer HPFS and other 
  15377. installable file systems. 
  15378.  
  15379.  
  15380. ΓòÉΓòÉΓòÉ 28.39. flat memory model ΓòÉΓòÉΓòÉ
  15381.  
  15382. flat memory model 
  15383.  
  15384. Conceptual view of real memory implemented by OS/2 Version 2.0, where the 
  15385. operating system regards memory as a single linear address range of up to 4GB. 
  15386.  
  15387.  
  15388. ΓòÉΓòÉΓòÉ 28.40. FSACCESS ΓòÉΓòÉΓòÉ
  15389.  
  15390. FSACCESS 
  15391.  
  15392. Utility provided with the VMB component of OS/2 Version 2.0, which allows the 
  15393. user to redirect logical drive letters in a VMB session, in order to avoid 
  15394. clashes and ensure compatibility with drive letters used by other processes. 
  15395.  
  15396.  
  15397. ΓòÉΓòÉΓòÉ 28.41. FSFILTER ΓòÉΓòÉΓòÉ
  15398.  
  15399. FSFILTER 
  15400.  
  15401. Utility provided with the VMB component of OS/2 Version 2.0, which allows the 
  15402. operating system loaded within the VMB session to recognize and access HPFS 
  15403. drives and large partitions which would otherwise not be accessible by that 
  15404. operating system.  FSFILTER traps and redirects all disk I/O through OS/2 
  15405. Version 2.0's own device drivers. 
  15406.  
  15407.  
  15408. ΓòÉΓòÉΓòÉ 28.42. GB ΓòÉΓòÉΓòÉ
  15409.  
  15410. GB 
  15411.  
  15412. Gigabyte; 1024 megabytes, or 1024 x 1024 x 1024 bytes. 
  15413.  
  15414.  
  15415. ΓòÉΓòÉΓòÉ 28.43. high memory area ΓòÉΓòÉΓòÉ
  15416.  
  15417. high memory area 
  15418.  
  15419. The first 64KB of extended memory above 1MB.  The High Memory Area (HMA) is 
  15420. unique in that code can be executed in it while in real mode, using the A20 
  15421. address line wraparound.  The HMA officially starts at FFFF:0010h and ends at 
  15422. FFFF:FFFFh, making it slightly less than 64KB in length. 
  15423.  
  15424.  
  15425. ΓòÉΓòÉΓòÉ 28.44. HIMEM.SYS ΓòÉΓòÉΓòÉ
  15426.  
  15427. HIMEM.SYS 
  15428.  
  15429. The Extended Memory Manager in general use for DOS. 
  15430.  
  15431.  
  15432. ΓòÉΓòÉΓòÉ 28.45. HMA ΓòÉΓòÉΓòÉ
  15433.  
  15434. HMA 
  15435.  
  15436. See high memory area. 
  15437.  
  15438.  
  15439. ΓòÉΓòÉΓòÉ 28.46. HPFS ΓòÉΓòÉΓòÉ
  15440.  
  15441. HPFS 
  15442.  
  15443. High performance file system; file system first implemented under OS/2 Version 
  15444. 1.2, offering enhanced performance over the original FAT file system 
  15445. implemented in DOS and prior versions of OS/2.  HPFS is an optional 
  15446. installation item under OS/2 Version 2.0; the FAT system may also be used to 
  15447. retain compatibility with DOS. 
  15448.  
  15449.  
  15450. ΓòÉΓòÉΓòÉ 28.47. Interrupt ΓòÉΓòÉΓòÉ
  15451.  
  15452. Interrupt 
  15453.  
  15454. An electrical signal generated by a device or adapter within the system, to 
  15455. inform the operating system that an event, such as the completion of an I/O 
  15456. operation, has occurred.  The operating system then processes the interrupt by 
  15457. passing control to a particular piece of code which handles the appropriate 
  15458. action in response to the event indicated. 
  15459.  
  15460.  
  15461. ΓòÉΓòÉΓòÉ 28.48. I/O ΓòÉΓòÉΓòÉ
  15462.  
  15463. I/O 
  15464.  
  15465. Input/Output; term used to collectively describe the techniques and devices 
  15466. through which a computer system interfaces with storage devices, external 
  15467. systems and the user. 
  15468.  
  15469.  
  15470. ΓòÉΓòÉΓòÉ 28.49. IOPL ΓòÉΓòÉΓòÉ
  15471.  
  15472. IOPL 
  15473.  
  15474. Input Output Privilege Level; term used in Intel 80x86 processor terminology to 
  15475. refer to tasks executing at privilege level 2, which have the authority to 
  15476. directly access physical I/O devices. 
  15477.  
  15478.  
  15479. ΓòÉΓòÉΓòÉ 28.50. KB ΓòÉΓòÉΓòÉ
  15480.  
  15481. KB 
  15482.  
  15483. Kilobyte; 1024 bytes. 
  15484.  
  15485.  
  15486. ΓòÉΓòÉΓòÉ 28.51. LIM ΓòÉΓòÉΓòÉ
  15487.  
  15488. LIM 
  15489.  
  15490. Lotus-Intel-Microsoft; term used in reference to the consortium which developed 
  15491. the Expanded Memory Specification (EMS), which provides a standard interface 
  15492. for the use of expanded memory by real mode 80x86 applications. 
  15493.  
  15494.  
  15495. ΓòÉΓòÉΓòÉ 28.52. LIMA ΓòÉΓòÉΓòÉ
  15496.  
  15497. LIMA 
  15498.  
  15499. Lotus-Intel-Microsoft-AST;  term used in reference to the consortium which 
  15500. developed the Extended Memory Specification (XMS), which provides a standard 
  15501. interface for the use of extended memory by real mode 80x86 applications. 
  15502.  
  15503.  
  15504. ΓòÉΓòÉΓòÉ 28.53. mappable window ΓòÉΓòÉΓòÉ
  15505.  
  15506. mappable window 
  15507.  
  15508. Under EMS, the mappable window is composed of EMS physical segments. Called the 
  15509. page frame in normal EMS terminology, this is the range of real mode addresses 
  15510. used by most applications to reference expanded memory.  The window must be at 
  15511. least 64KB and located between 640KB and 1MB. 
  15512.  
  15513.  
  15514. ΓòÉΓòÉΓòÉ 28.54. MAVDM ΓòÉΓòÉΓòÉ
  15515.  
  15516. MAVDM 
  15517.  
  15518. See Multiple Application VDM. 
  15519.  
  15520.  
  15521. ΓòÉΓòÉΓòÉ 28.55. MB ΓòÉΓòÉΓòÉ
  15522.  
  15523. MB 
  15524.  
  15525. Megabyte; 1024 kilobytes, or 1024 x 1024 bytes. 
  15526.  
  15527.  
  15528. ΓòÉΓòÉΓòÉ 28.56. Multiple Application VDM ΓòÉΓòÉΓòÉ
  15529.  
  15530. Multiple Application VDM 
  15531.  
  15532. Method of running Windows applications under OS/2 Version 2.0, whereby the 
  15533. Windows Program Manager is started in a virtual DOS machine, and Windows 
  15534. applications are started using the Program Manager.  Errors in any Windows 
  15535. application may potentially result in termination of the entire VDM  This is 
  15536. method of running Windows applications is not recommended unless applications 
  15537. require communication using shared memory. 
  15538.  
  15539.  
  15540. ΓòÉΓòÉΓòÉ 28.57. Multiple Virtual DOS Machines ΓòÉΓòÉΓòÉ
  15541.  
  15542. Multiple Virtual DOS Machines 
  15543.  
  15544. Feature of OS/2 Version 2.0 which enables multiple DOS applications to execute 
  15545. concurrently in fullscreen or windowed mode under OS/2 Version 2.0, in 
  15546. conjunction with other 16-bit or 32-bit applications, with full pre-emptive 
  15547. multitasking and memory protection between tasks.  See also virtual DOS 
  15548. machine. 
  15549.  
  15550.  
  15551. ΓòÉΓòÉΓòÉ 28.58. MVDM ΓòÉΓòÉΓòÉ
  15552.  
  15553. MVDM 
  15554.  
  15555. See Multiple Virtual DOS Machines. 
  15556.  
  15557.  
  15558. ΓòÉΓòÉΓòÉ 28.59. NPX ΓòÉΓòÉΓòÉ
  15559.  
  15560. NPX 
  15561.  
  15562. Numeric Processor Extension; term used in reference to the exception condition 
  15563. generated by the 80386 processor when an application issues a numeric 
  15564. coprocessor instruction in a machine with no coprocessor installed.  Note that 
  15565. OS/2 Version 2.0 will trap the NPX exception and emulate the numeric 
  15566. coprocessor function within the operating system, returning the result to the 
  15567. application exactly as if a physical coprocessor were installed. 
  15568.  
  15569.  
  15570. ΓòÉΓòÉΓòÉ 28.60. NULL ΓòÉΓòÉΓòÉ
  15571.  
  15572. NULL 
  15573.  
  15574. A binary zero.  In "C" programming terms, NULL is typically used to refer to a 
  15575. pointer which is set to the binary zero value. 
  15576.  
  15577.  
  15578. ΓòÉΓòÉΓòÉ 28.61. Object Linking and Embedding ΓòÉΓòÉΓòÉ
  15579.  
  15580. Object Linking and Embedding 
  15581.  
  15582. Protocol for linking multiple data formats (such as text, image, voice etc.) to 
  15583. create a compound document, which may be viewed and manipulated as a coherent 
  15584. whole. 
  15585.  
  15586.  
  15587. ΓòÉΓòÉΓòÉ 28.62. OLE ΓòÉΓòÉΓòÉ
  15588.  
  15589. OLE 
  15590.  
  15591. See Object Linking and Embedding. 
  15592.  
  15593.  
  15594. ΓòÉΓòÉΓòÉ 28.63. OS mappable window ΓòÉΓòÉΓòÉ
  15595.  
  15596. OS mappable window 
  15597.  
  15598. In addition to the normal mappable window, additional memory below 1MB can also 
  15599. be remapped.  This is typically all memory from 256KB to 640KB.  This is used 
  15600. by task management programs (such as Microsoft Windows) to map a different 
  15601. section of expanded memory to this region for each application it runs.  An 
  15602. application can, however, remap this memory.  No protection is provided.  This 
  15603. memory is automatically allocated to a special handle and is mapped when EMS 
  15604. starts, before the operating system touches the memory. 
  15605.  
  15606.  
  15607. ΓòÉΓòÉΓòÉ 28.64. page ΓòÉΓòÉΓòÉ
  15608.  
  15609. page 
  15610.  
  15611. Granular unit for memory management using the 80386 and 80486 processors.  A 
  15612. page is a 4KB contiguous unit of memory, which the processor manipulates as a 
  15613. single entity for the purpose of memory manipulation and swapping. 
  15614.  
  15615.  
  15616. ΓòÉΓòÉΓòÉ 28.65. physical device driver ΓòÉΓòÉΓòÉ
  15617.  
  15618. physical device driver 
  15619.  
  15620. Protected mode device driver used by the OS/2 Version 2.0 operating system and 
  15621. protected mode processes to access hardware devices.  DOS applications running 
  15622. in virtual DOS machines do not directly access physical device drivers; virtual 
  15623. device drivers are utilized by these applications, and the virtual device 
  15624. driver in turn communicates with the physical device driver. 
  15625.  
  15626.  
  15627. ΓòÉΓòÉΓòÉ 28.66. PIC ΓòÉΓòÉΓòÉ
  15628.  
  15629. PIC 
  15630.  
  15631. Programmable Interrupt Controller; component of the 80386 processor complex 
  15632. which handles interrupts generated by devices within the system. 
  15633.  
  15634.  
  15635. ΓòÉΓòÉΓòÉ 28.67. POST ΓòÉΓòÉΓòÉ
  15636.  
  15637. POST 
  15638.  
  15639. Power-On Self-Test; code typically stored on ROM (although the IBM PS/2 Model 
  15640. 90 and 95 allow POST code to be stored on fixed disk) which is invoked when a 
  15641. machine is powered on, in order to test the hardware. 
  15642.  
  15643.  
  15644. ΓòÉΓòÉΓòÉ 28.68. privilege level ΓòÉΓòÉΓòÉ
  15645.  
  15646. privilege level 
  15647.  
  15648. In the context of the Intel 80386 processor architecture, the level of 
  15649. authority at which a task executes.  There are four available privilege levels; 
  15650. under OS/2 Version 2.0, Level 0 is used for operating system kernel code; Level 
  15651. 1 is not used; Level 2 is used for applications which directly address I/O 
  15652. devices (such as communications applications); Level 3 is used for general 
  15653. application code.  In many publications, these protection levels are referred 
  15654. to as "rings", since the protection scheme of the 80386 is often depicted 
  15655. diagrammatically as a series of concentric circles. 
  15656.  
  15657.  
  15658. ΓòÉΓòÉΓòÉ 28.69. protected mode ΓòÉΓòÉΓòÉ
  15659.  
  15660. protected mode 
  15661.  
  15662. Mode of operation for the Intel 80286 and 80386/80486 processors, whereby the 
  15663. address space is expanded to 16MB (80286) or 4GB (80386/80486), and memory 
  15664. references are translated via segment selector and offset, enabling full memory 
  15665. protection between processes executing in the system.  With the 80386/80486, 
  15666. paging is available in protected mode. 
  15667.  
  15668.  
  15669. ΓòÉΓòÉΓòÉ 28.70. RAM ΓòÉΓòÉΓòÉ
  15670.  
  15671. RAM 
  15672.  
  15673. Random Access Memory; term used to describe memory which may be dynamically 
  15674. read and written by a processor or other device during system operations.  RAM 
  15675. is typically used to store program instructions and data which not being 
  15676. operated upon by the processor at the current moment in time, but which are 
  15677. required for the logical unit of work currently being carried out. 
  15678.  
  15679.  
  15680. ΓòÉΓòÉΓòÉ 28.71. real mode ΓòÉΓòÉΓòÉ
  15681.  
  15682. real mode 
  15683.  
  15684. (1) Default mode of operation for the Intel 80286 and 80386/80486 processors, 
  15685. and the only mode of operation for the 8086 processor.  In real mode, the 
  15686. processor acts as a 16-bit device, its physical memory address space is limited 
  15687. to 1MB, and memory references translate directly to physical addresses.  With 
  15688. the 80386 and 80486, paging is not supported in real mode. (2) Execution mode 
  15689. for Windows 3.0, which provides applications with up to 640KB of conventional 
  15690. memory (384KB after loading DOS, Windows and other memory-resident software) 
  15691. and which supports expanded memory using LIM EMS Version 4.0 specifications. 
  15692.  
  15693.  
  15694. ΓòÉΓòÉΓòÉ 28.72. ROM ΓòÉΓòÉΓòÉ
  15695.  
  15696. ROM 
  15697.  
  15698. Read-Only Memory; term used to describe memory which may be read, but not 
  15699. written to, during system operations.  ROM is typically used to store basic 
  15700. hardware initialization instructions, BIOS or self-testing code, which is 
  15701. required to be available prior to accessing the disk subsystem. 
  15702.  
  15703.  
  15704. ΓòÉΓòÉΓòÉ 28.73. SAVDM ΓòÉΓòÉΓòÉ
  15705.  
  15706. SAVDM 
  15707.  
  15708. See Single Application VDM. 
  15709.  
  15710.  
  15711. ΓòÉΓòÉΓòÉ 28.74. Seamless Windows ΓòÉΓòÉΓòÉ
  15712.  
  15713. Seamless Windows 
  15714.  
  15715. Method of running Windows applications under OS/2 Version 2.0, whereby the 
  15716. application runs on the Workplace Shell in a similar manner to a normal 
  15717. Presentation Manager application.  The user is not normally aware that the 
  15718. application is a Windows application.  This is the preferred method of running 
  15719. Windows applications, and is similar to the Single Application VDM method. 
  15720.  
  15721.  
  15722. ΓòÉΓòÉΓòÉ 28.75. segment ΓòÉΓòÉΓòÉ
  15723.  
  15724. segment 
  15725.  
  15726. Unit of memory addressable by the Intel 80x86 processors.  With the 8086 and 
  15727. 80286 processors, a segment may be from 16 bytes to 64KB in size.  With the 
  15728. 80386 and 80486 processors, a segment may be up to 4GB in size. 
  15729.  
  15730.  
  15731. ΓòÉΓòÉΓòÉ 28.76. segment selector ΓòÉΓòÉΓòÉ
  15732.  
  15733. segment selector 
  15734.  
  15735. Field which specifies the base address of a memory segment when using the 
  15736. segmented memory model.  The selector is 16 bits in length on an 80286 
  15737. processor, and 32 bits in length on an 80386 or 80486 processor. 
  15738.  
  15739.  
  15740. ΓòÉΓòÉΓòÉ 28.77. service layer ΓòÉΓòÉΓòÉ
  15741.  
  15742. service layer 
  15743.  
  15744. Executable code which performs the operating system function requested by an 
  15745. application using an API. 
  15746.  
  15747.  
  15748. ΓòÉΓòÉΓòÉ 28.78. signal ΓòÉΓòÉΓòÉ
  15749.  
  15750. signal 
  15751.  
  15752. An event occurring within the operating system which will effect the execution 
  15753. of the current process; for example, the user may hit the Ctrl+Break key 
  15754. combination, which would result in a signal being generated, instructing the 
  15755. operating system to terminate the current process.  Signals typically override 
  15756. the dispatching algorithms of the operating system. 
  15757.  
  15758.  
  15759. ΓòÉΓòÉΓòÉ 28.79. Single Application VDM ΓòÉΓòÉΓòÉ
  15760.  
  15761. Single Application VDM 
  15762.  
  15763. Method of running Windows applications under OS/2 Version 2.0, whereby a 
  15764. virtual DOS machine is created for each Windows application.  The application 
  15765. runs within this VDM, and is protected from any other application running in 
  15766. the system.  This is the recommended way to run Windows applications if not 
  15767. running seamlessly on the Workplace Shell desktop. 
  15768.  
  15769.  
  15770. ΓòÉΓòÉΓòÉ 28.80. standard mode ΓòÉΓòÉΓòÉ
  15771.  
  15772. standard mode 
  15773.  
  15774. Execution mode for Windows 3.0, available when running on 80286, 80386 or 80486 
  15775. systems.  Standard mode makes use of these processors' protected mode to 
  15776. provide access to up to 16MB of extended memory. Windows applications must 
  15777. conform to memory management rules in order to use standard mode. 
  15778.  
  15779.  
  15780. ΓòÉΓòÉΓòÉ 28.81. stub device driver ΓòÉΓòÉΓòÉ
  15781.  
  15782. stub device driver 
  15783.  
  15784. Virtual device drivers include a stub so that the DOS application can detect 
  15785. and address the device driver.  This stub device driver executes in V86 mode 
  15786. within each VDM, while the main portion of the virtual device driver executes 
  15787. in protected mode. 
  15788.  
  15789.  
  15790. ΓòÉΓòÉΓòÉ 28.82. stub virtual DOS kernel ΓòÉΓòÉΓòÉ
  15791.  
  15792. stub virtual DOS kernel 
  15793.  
  15794. Portion of the MVDM component's DOS kernel which is loaded into each VDM.  DOS 
  15795. services are either provided directly by the stub virtual DOS kernel, or are 
  15796. routed to the OS/2 protected mode kernel. 
  15797.  
  15798.  
  15799. ΓòÉΓòÉΓòÉ 28.83. task state segment ΓòÉΓòÉΓòÉ
  15800.  
  15801. task state segment 
  15802.  
  15803. Area of memory containing information relating to the current machine state, 
  15804. including CPU register contents, and the current software state of a task, such 
  15805. as file descriptors and priority information. 
  15806.  
  15807.  
  15808. ΓòÉΓòÉΓòÉ 28.84. TSR ΓòÉΓòÉΓòÉ
  15809.  
  15810. TSR 
  15811.  
  15812. Terminate and Stay Resident; term used to describe DOS applications which 
  15813. modify interrupt vectors to insert their own interrupt processing code.  This 
  15814. technique is used frequently by low-level utility programs, device drivers and 
  15815. other system code such as network drivers.  TSR programs use memory within the 
  15816. DOS address space, thus leaving less memory available for application use. 
  15817.  
  15818.  
  15819. ΓòÉΓòÉΓòÉ 28.85. TSS ΓòÉΓòÉΓòÉ
  15820.  
  15821. TSS 
  15822.  
  15823. See task state segment. 
  15824.  
  15825.  
  15826. ΓòÉΓòÉΓòÉ 28.86. UMB ΓòÉΓòÉΓòÉ
  15827.  
  15828. UMB 
  15829.  
  15830. See upper memory block. 
  15831.  
  15832.  
  15833. ΓòÉΓòÉΓòÉ 28.87. upper memory block ΓòÉΓòÉΓòÉ
  15834.  
  15835. upper memory block 
  15836.  
  15837. Under XMS, a block of memory available on some 80x86-based machines, and 
  15838. located between DOS's 640KB limit and the 1MB address space boundary.  The 
  15839. number, size, and location of these blocks may vary widely depending on the 
  15840. types of hardware adapter cards installed in the machine. 
  15841.  
  15842.  
  15843. ΓòÉΓòÉΓòÉ 28.88. VDDM ΓòÉΓòÉΓòÉ
  15844.  
  15845. VDDM 
  15846.  
  15847. See Virtual Device Driver Manager. 
  15848.  
  15849.  
  15850. ΓòÉΓòÉΓòÉ 28.89. VDM ΓòÉΓòÉΓòÉ
  15851.  
  15852. VDM 
  15853.  
  15854. See Virtual DOS Machine. 
  15855.  
  15856.  
  15857. ΓòÉΓòÉΓòÉ 28.90. virtual device driver ΓòÉΓòÉΓòÉ
  15858.  
  15859. virtual device driver 
  15860.  
  15861. Form of device driver used by DOS applications executing in a virtual DOS 
  15862. machine, in order to access devices which must be shared with other processes 
  15863. in the system, such as the screen or mouse.  A virtual device driver typically 
  15864. maps DOS device commands to the physical device driver in the protected mode 
  15865. environment under OS/2 Version 2.0. 
  15866.  
  15867.  
  15868. ΓòÉΓòÉΓòÉ 28.91. Virtual Device Driver Manager ΓòÉΓòÉΓòÉ
  15869.  
  15870. Virtual Device Driver Manager 
  15871.  
  15872. Subcomponent of the Multiple Virtual DOS Machines component of OS/2 Version 
  15873. 2.0, which loads, initializes, and communicates with virtual device drivers. 
  15874. Also known as the VDDM. 
  15875.  
  15876.  
  15877. ΓòÉΓòÉΓòÉ 28.92. Virtual Device Helper ΓòÉΓòÉΓòÉ
  15878.  
  15879. Virtual Device Helper 
  15880.  
  15881. Set of operating system services used by virtual device drivers to request, 
  15882. release and manipulate system resources. 
  15883.  
  15884.  
  15885. ΓòÉΓòÉΓòÉ 28.93. virtual DOS machine ΓòÉΓòÉΓòÉ
  15886.  
  15887. virtual DOS machine 
  15888.  
  15889. A protected mode process under OS/2 Version 2.0 which emulates a DOS operating 
  15890. system environment, such that DOS applications executing within the virtual 
  15891. machine operate exactly as if they were running under DOS. DOS virtual machines 
  15892. support both text and graphics applications. Virtual DOS machines make use of 
  15893. the virtual 8086 mode of the 80386 and 80486 processors. 
  15894.  
  15895.  
  15896. ΓòÉΓòÉΓòÉ 28.94. Virtual DOS Machine Manager ΓòÉΓòÉΓòÉ
  15897.  
  15898. Virtual DOS Machine Manager 
  15899.  
  15900. Subcomponent of the Multiple Virtual DOS Machines component of OS/2 Version 
  15901. 2.0, which provides the ability to start and interact with DOS applications 
  15902. running in virtual DOS machines. The virtual DOS machine manager operates in 
  15903. conjunction with the Virtual Device Driver Manager. 
  15904.  
  15905.  
  15906. ΓòÉΓòÉΓòÉ 28.95. VEMM ΓòÉΓòÉΓòÉ
  15907.  
  15908. VEMM 
  15909.  
  15910. See Virtual Expanded Memory Manager. 
  15911.  
  15912.  
  15913. ΓòÉΓòÉΓòÉ 28.96. Virtual Expanded Memory Manager ΓòÉΓòÉΓòÉ
  15914.  
  15915. Virtual Expanded Memory Manager 
  15916.  
  15917. Virtual device driver which provides emulation of LIM EMS Version 4.0 services 
  15918. to DOS applications running in virtual DOS machines.  Unlike most virtual 
  15919. device drivers, the Virtual Expanded Memory Manager does not use a physical 
  15920. device driver, but interacts directly with the operating system's memory 
  15921. manager to map EMS memory requests into the system's linear address space. 
  15922. Also known as VEMM. 
  15923.  
  15924.  
  15925. ΓòÉΓòÉΓòÉ 28.97. virtual machine ΓòÉΓòÉΓòÉ
  15926.  
  15927. virtual machine 
  15928.  
  15929. See virtual DOS machine. 
  15930.  
  15931.  
  15932. ΓòÉΓòÉΓòÉ 28.98. VMB ΓòÉΓòÉΓòÉ
  15933.  
  15934. VMB 
  15935.  
  15936. Component of OS/2 Version 2.0 which operates in conjunction with MVDM component 
  15937. to allow a real copy of DOS or another real mode operating system to be loaded 
  15938. into a virtual DOS machine.  VMB allows the execution under OS/2 Version 2.0 of 
  15939. applications which exploit specific features of an operating system or version, 
  15940. and which cannot be supported using DOS Emulation. 
  15941.  
  15942.  
  15943. ΓòÉΓòÉΓòÉ 28.99. VMB session ΓòÉΓòÉΓòÉ
  15944.  
  15945. VMB session 
  15946.  
  15947. A virtual DOS machine in which an operating system has been loaded using the 
  15948. VMB component of OS/2 Version 2.0. 
  15949.  
  15950.  
  15951. ΓòÉΓòÉΓòÉ 28.100. virtual machine monitor ΓòÉΓòÉΓòÉ
  15952.  
  15953. virtual machine monitor 
  15954.  
  15955. Routine supplied by operating systems which utilize the virtual 8086 mode of 
  15956. the 80386 processor, to provide emulation of interrupts and exceptions 
  15957. resulting when an 8086 application issues an instruction which cannot be 
  15958. executed in virtual 8086 mode.  The 8086 Emulation component of MVDM is a 
  15959. virtual machine monitor. 
  15960.  
  15961.  
  15962. ΓòÉΓòÉΓòÉ 28.101. Virtual Programmable Interrupt Controller ΓòÉΓòÉΓòÉ
  15963.  
  15964. Virtual Programmable Interrupt Controller 
  15965.  
  15966. Virtual device driver used in the Multiple Virtual DOS Machines component of 
  15967. OS/2 Version 2.0 to emulate DOS interrupt services, allowing DOS applications 
  15968. running in virtual DOS machines to issue and receive interrupts. 
  15969.  
  15970.  
  15971. ΓòÉΓòÉΓòÉ 28.102. virtual 8086 mode ΓòÉΓòÉΓòÉ
  15972.  
  15973. virtual 8086 mode 
  15974.  
  15975. Mode of operation of the Intel 80386 and 80486 processors, which allows the 
  15976. processor to execute multiple concurrent tasks with each regarding the 
  15977. processor as its own distinct 8086 processor.  This mode of operation provides 
  15978. full pre-emptive multitasking and full memory protection between the virtual 
  15979. 8086 tasks.  Also known as V86 mode. 
  15980.  
  15981.  
  15982. ΓòÉΓòÉΓòÉ 28.103. VMDISK ΓòÉΓòÉΓòÉ
  15983.  
  15984. VMDISK 
  15985.  
  15986. Utility provided with the VMB component of OS/2 Version 2.0, which allows the 
  15987. user to create diskette images which may then be used to load specific versions 
  15988. of DOS or other real mode operating systems into a virtual DOS machine using 
  15989. VMB. 
  15990.  
  15991.  
  15992. ΓòÉΓòÉΓòÉ 28.104. watchdog timer ΓòÉΓòÉΓòÉ
  15993.  
  15994. watchdog timer 
  15995.  
  15996. Hardware timer provided by the 80386 processor to ensure that 8086 applications 
  15997. running in virtual 8086 mode do not disable interrupts for an unnecessarily 
  15998. long period.  Such lengthy disabling may cause unrecoverable system errors. 
  15999. The watchdog timer generates periodic non-maskable interrupts which allow an 
  16000. operating system to detect an errant 8086 application and terminate it. 
  16001.  
  16002.  
  16003. ΓòÉΓòÉΓòÉ 28.105. windows ΓòÉΓòÉΓòÉ
  16004.  
  16005. windows 
  16006.  
  16007. In this document, generally refers to Microsoft Windows 3.0. Exceptions are 
  16008. noted in the text. 
  16009.  
  16010.  
  16011. ΓòÉΓòÉΓòÉ 28.106. WIN-OS/2 kernel ΓòÉΓòÉΓòÉ
  16012.  
  16013. WIN-OS/2 kernel 
  16014.  
  16015. Portion of MVDM which services Windows function calls from applications running 
  16016. within a VDM.  The WIN-OS/2 kernel provides support for Windows applications in 
  16017. VDMs under OS/2 Version 2.0. 
  16018.  
  16019.  
  16020. ΓòÉΓòÉΓòÉ 28.107. Workplace Shell ΓòÉΓòÉΓòÉ
  16021.  
  16022. Workplace Shell 
  16023.  
  16024. Standard user interface component of OS/2 Version 2.0 that provides an 
  16025. object-oriented interface for the end user.  The implementation of the 
  16026. Workplace Shell is based upon the system object model. 
  16027.  
  16028.  
  16029. ΓòÉΓòÉΓòÉ 28.108. Workplace Shell object ΓòÉΓòÉΓòÉ
  16030.  
  16031. Workplace Shell object 
  16032.  
  16033. An object created by the Workplace Shell, typically at the request of the user 
  16034. or an application.  A Workplace Shell object is very similar in concept to an 
  16035. application object, in that it possesses data and methods that operate upon 
  16036. that data.  See also application object. 
  16037.  
  16038.  
  16039. ΓòÉΓòÉΓòÉ 28.109. XMM ΓòÉΓòÉΓòÉ
  16040.  
  16041. XMM 
  16042.  
  16043. See Extended Memory Manager. 
  16044.  
  16045.  
  16046. ΓòÉΓòÉΓòÉ 28.110. 386 enhanced mode ΓòÉΓòÉΓòÉ
  16047.  
  16048. 386 enhanced mode 
  16049.  
  16050. Execution mode for Windows 3.0, available when running on 80386 or 80486 
  16051. systems only.  386 enhanced mode makes use of the virtual memory capabilities 
  16052. of the the processor, and allows use of certain 32-bit functions.  Applications 
  16053. must conform to memory management rules in order to use 386 enhanced mode. 
  16054.  
  16055.  
  16056. ΓòÉΓòÉΓòÉ 28.111. 80386 ΓòÉΓòÉΓòÉ
  16057.  
  16058. 80386 
  16059.  
  16060. Intel 80386 microprocessor; the 32-bit processor upon which the OS/2 Version 
  16061. 2.0 operating system is based. 
  16062.  
  16063.  
  16064. ΓòÉΓòÉΓòÉ 28.112. 80486 ΓòÉΓòÉΓòÉ
  16065.  
  16066. 80486 
  16067.  
  16068. Intel 80486 microprocessor; a 32-bit processor which implements a superset of 
  16069. the 80386 processor instruction set. 
  16070.  
  16071.  
  16072. ΓòÉΓòÉΓòÉ 28.113. 8086 Emulation ΓòÉΓòÉΓòÉ
  16073.  
  16074. 8086 Emulation 
  16075.  
  16076. Subcomponent of the Multiple Virtual DOS Machines component of OS/2 Version 
  16077. 2.0, which provides emulation of Intel 8086 processor services by utilizing the 
  16078. virtual 8086 mode of the 80386 processor. 
  16079.  
  16080.  
  16081. ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ
  16082.  
  16083. Accessible only if the A20 address line is active 
  16084.  
  16085.  
  16086. ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ
  16087.  
  16088. These are values implied by the specifications.  Values in practice will be 
  16089. considerably lower.  More reasonable values are 1MB for EMBs and 0KB to 32KB 
  16090. for UMBs. 
  16091.  
  16092.  
  16093. ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ
  16094.  
  16095. OS/2 VIO applications may also use the Presentation Manager clipboard, by using 
  16096. the appropriate Win calls; for example, CTC's SPF/2** editor provides this 
  16097. function.