OS/2 Professional

home *** CD-ROM | disk | FTP | other *** search

/ OS/2 Professional / OS2PRO194.ISO / os2 / info / faq / os2_20 / os2help / vmb.fax < prev next >

Wrap

Text File | 1992-09-17 | 33.9 KB | 756 lines

VIRTUAL MACHINE BOOT -------------------- The following is an excerpt from Chapter 12 of the IBM OS/2 Version 2.0 Technical Redbooks, Volume 2: DOS and Windows Environment (Document Number GG24-3731-00), published by the IBM Corporation. This document describes the ability of OS/2 to run Virtual DOS Machines using a feature called Virtual Machine Boot (VMB). An important goal of OS/2 Version 2.0 is the ability to run past, current, and future DOS programs; indeed most DOS applications available today run unchanged in the MVDM environment. However, it should be remembered that the "DOS" which runs in this case is highly optimized for (and specific to) an OS/2 Version 2.0 virtual 8086 machine. Because of this, there are fundamental internal differences between the DOS Emulation provided under OS/2 Version 2.0 and "real" DOS. Two problems may therefore arise: 1. Some programs may depend on specific DOS features such as internal control blocks, LAN Redirector hooks, or even undocumented functions, which are not present in MVDM's DOS Emulation. 2. Only DOS character device drivers can be loaded in MVDM's DOS Emulation. The user may own a block device (such as a special disk or tape drive) for which no OS/2 driver is available. (A block device is one accessed via a drive letter, such as E:). Virtual Machine Boot (VMB) solves both these problems. It allows the user to boot "off-the-shelf" DOS and use block device drivers in an OS/2 Version 2.0 virtual DOS machine, ensuring greater compatibility for DOS applications. Another possible use of VMB is to run DOS of a different National Language to that of OS/2 Version 2.0 itself. This may be useful in a multilingual environment. 12.1 VMB Environment The 80386 processor and VDM component of OS/2 Version 2.0 together emulate a 8086 processor, keyboard, display, BIOS and other supporting hardware; in effect, a complete "virtual Personal Computer." It is therefore possible for "real" DOS to be loaded in a VDM session. Control is passed to the boot record (the first sector) of the DOS system diskette, which in turn loads and initializes the rest of the DOS kernel, just as it does when booting on a physical PC. Indeed, the VDM environment is so similar to a real PC environment that VMB can actually support any 8086 operating system kernel, such as Digital Research's DR-DOS** and CP/M**, Microsoft MS-DOS**, or even a PS/2 reference diskette (but do not attempt to run diagnostics or change the configuration from a VDM; the results are unpredictable). However, since the purpose of VMB is to run current DOS applications, formal IBM support is announced for IBM PC DOS 3.x, 4.0, and 5.0 only. A VDM using VMB is similar in function to any other virtual DOS machine. Multiple VDMs may be started and operated concurrently using Virtual Machine Boot. Each runs in its own virtual 8086 machine; access to hardware and other system resources is managed by MVDM and the underlying OS/2 Version 2.0 operating system. 12.2 Configuring Virtual Machine Boot The DOS operating system loaded into a VDM by VMB may be: 1. An actual DOS system diskette 2. An image of a DOS system diskette saved to hard disk 3. A DOS partition on hard disk. For any of the alternatives, we need to do the following: 1. Set up the start-up batch file AUTOEXEC.BAT 2. Set up the configuration file CONFIG.SYS 3. Provide OS/2 V2.0 with the real DOS to boot. 12.2.1 Preparing AUTOEXEC.BAT and CONFIG.SYS The AUTOEXEC.BAT and CONFIG.SYS that will be used by the VMB at initialization are not the ones found in the root directory of the OS/2 V2.0 boot drive. The following table explains which AUTOEXEC.BAT and CONFIG.SYS will be used for the different DOS session types under OS/2 V2.0. +------------------------------------------------------------------------+ | Table 7. Location of AUTOEXEC.BAT and CONFIG.SYS | |------------------------------------------------------------------------| | VDM Type | Location | | | | | Virtual Machine Boot from diskette | drive A: | | | | | Virtual Machine Boot from diskette | imbedded in diskette image file | | image | on the hard disk | | | | | Virtual Machine Boot from DOS boot | DOS boot partition | | partition | | | | | | OS/2 V2.0 DOS emulator | root directory of OS/2 boot drive | +------------------------------------+-----------------------------------+ CONFIG.SYS requires special attention for the following reasons: 1. Write access to the hard disk is denied the Virtual Machine Boot session to preserve system integrity, since the real DOS is unaware of OS/2 V2.0 and the other applications running. The OS/2 device driver FSFILTER.SYS is provided to address the above problem. 2. HPFS partitions are not visible to the real DOS running. FSFILTER.SYS allows the DOS in the Virtual Machine Boot to access HPFS files. 3. OS/2 V2.0 provides its own mouse, EMS and XMS to each virtual DOS machine, so there is no need to load the equivalent drivers available for native DOS. Those provided with the real DOS should not be used. However, some DOS programs test for the presence of these drivers. OS/2 V2.0 provides the equivalent "stub" drivers to satisfy these programs that the services actually are available. The following types of device drivers should also be omitted from CONFIG.SYS: - Disk cache - Print spooler - RAM disk These facilities are already provided by OS/2 Version 2.0 and may be accessed by virtual DOS machines and VMB sessions; including them with DOS leads to unnecessary duplication, and may impact overall DOS leads to unnecessary duplication, and may impact overall performance. When the Virtual Machine Boot is started from a diskette image on the hard disk, the real DOS sees the diskette image as drive A:. The real drive A: cannot be accessed. OS/2 V2.0 provides a DOS program, FSACCESS.EXE, that can be used from the DOS command prompt or inserted in AUTOEXEC.BAT to overcome this problem. We will cover each of these special requirements in detail in the following sections. 12.2.1.1 Drive Letter Allocation and Access Drive letter allocation and access is one of the more complex areas of VMB, mainly due to the automatic drive letter allocation performed by DOS, and the limitations of earlier DOS versions. The following possible areas of confusion may arise for the user: - If DOS is booted from an image file, it sees this image file as its A: drive. This prevents access to the real A: diskette drive. Attempts to write to the apparent A: drive will fail. - Unlike the DOS Emulation kernel provided by OS/2 Version 2.0, the "real" DOS booted by VMB cannot see or access an HPFS partition on the hard disk. - A DOS 3.x VDM cannot see a large (>32MB) FAT partition on the fixed disk, or FAT partitions beyond an HPFS partition on the disk. - Even if the booted DOS can otherwise see the hard disk partition, it is only given read access. Attempts to write will fail with simulated errors such as "General failure writing drive C:". The user might mistake this for a genuine hardware fault. - If the booted DOS loads a block device-driver, the allocated drive letter may be the same as that of a different device outside this VDM, thereby preventing access to that device from within the VDM. The results could be somewhat disorienting for the user. To help resolve these issues, two utilities FSFILTER and FSACCESS are provided with OS/2 Version 2.0. It is recommended that disk volumes should always be given a meaningful name, either when formatting or later using the LABEL command. This name will remain constant regardless of drive letter allocation, and will aid in identifying a particular volume, even if the assigned drive letter is different. 12.2.1.2 FSFILTER FSFILTER.SYS is a device driver which manages DOS VDM access to OS/2 disks. FSFILTER.SYS should be copied from the \OS2\MDOS directory to the DOS diskette, and the following statement added to the CONFIG.SYS file of the bootable DOS diskette or image. device=a:fsfilter.sys This statement should precede any DEVICE= statements which load block device drivers. Note that FSFILTER.SYS gives DOS full access to all OS/2 partitions, regardless of their file system type or partition size. This is an important and somewhat surprising point. For example, DOS 3.3 (in a VDM) has no problem accessing a 300MB HPFS partition, once FSFILTER is loaded. I/O calls within the DOS virtual machine are passed transparently to OS/2 Version 2.0. DOS itself is unaware of the underlying file system. DOS can read, write and modify files on the hard disk, and for most configurations the drive letter mapping within the VMB session will match those of OS/2 Version 2.0. The FSFILTER device driver occupies approximately 11KB of memory. It can be loaded into high memory under DOS 5.0 by specifying the command DEVICEHIGH = FSFILTER.SYS in CONFIG.SYS. The users should also specify the path to COMMAND.COM in the SHELL= statement of CONFIG.SYS. For example, if DOS files have been copied to C:\DOS, the CONFIG.SYS file on a diskette intended for VMB should contain the following statement: SHELL=c:\DOS\COMMAND.COM c:\dos /p The first parameter specifies the command processor to be loaded. The second parameter specifies the reload path (that is, the COMSPEC path). This is preferable to a SET COMSPEC = command in AUTOEXEC.BAT. Each block device driver loaded in DOS CONFIG.SYS is allocated the next free OS/2 letter excluding LAN drives. This can result in a drive letter clash. An example may illustrate the point. OS/2 drives are: A: Diskette drive 0 B: Diskette drive 1 C: Hard disk D: External diskette drive E: Remote LAN drive on a server FSFILTER will ensure that a booted DOS sees these drives by the same letter. The booted DOS has the same access to the external diskette drive and LAN resources as does OS/2 itself. This is true whether the VMB session is started before or after user logon to the network, when remote drive letters are assigned. However, a block device driver in a VMB session will also initialize as E:, so LAN drive access is lost. To remedy this, issue an "fsaccess f=e" command. The LAN drive is now accessible as F: within the DOS session. Note that even when FSFILTER is loaded, the following restrictions still apply: - A VMB session cannot see HPFS files or directories which have: - Long file names (9 or more characters) - Invalid FAT characters (for example, plus, comma, blank) - Multiple dot separators. - HPFS file names containing lowercase letters are folded to uppercase. - PC DOS commands which require low-level disk access will fail. These include: - CHKDSK - SYS - UNDELETE - FORMAT - UNFORMAT - MIRROR. In such cases OS/2 Version 2.0 will simulate a disk error condition. DOS may interpret this as a hardware fault, or report that the command is not supported on a network or assigned drive. 12.2.1.3 FSACCESS FSACCESS.EXE is a utility supplied with OS/2 Version 2.0 but intended to run in a VMB session. It cooperates with FSFILTER to manage drive letters within the VMB session. This serves three purposes: 1. Drives may be registered for filtering. 2. The drive letter for a device can be changed, giving consistency across sessions. 3. Letters can be removed in order to hide the OS/2 device from the VMB session. The syntax of the FSACCESS command is: FSACCESS ----------------+-------------------------+-----+ |-+---+- DOSletter -------+ | | | ! | | |------ DOSletter - DOSletter --+ | | +------ DOSletter = OS2drive --+ FSACCESS Lists the current drive mapping. For example: Local C: is mapped to OS/2 C: Local D: is mapped to OS/2 D: Local E: is mapped to OS/2 K: FSACCESS F: Registers DOS letter F: for filtering. References to F: will be sent to OS/2 Version 2.0. FSACCESS !F: De-registers DOS letter F: from filtering. FSACCESS F:-H: Registers DOS letters F: through H: for filtering. FSACCESS M:=C: Routes requests for DOS letter M: to OS/2 drive C: Parameters can be combined on a single command line, and the colon is optional. When booting from an image file, it is often desirable to issue the command FSACCESS A: in order to access the A: diskette drive. This will remove access to the image file, so the booted DOS will be unable to reload its COMMAND.COM when necessary. It may be useful to copy all the DOS files to a subdirectory on hard disk, ensuring the PATH and COMSPEC point there. An alternative is to access the diskette drive via a different letter. For example, a user may issue the command FSACCESS G:=A, then use G: to access the real A: drive. The image file remains as A:, avoiding PATH and COMSPEC problems. 12.2.2 Mouse, EMS and XMS Support The booted DOS in a VMB session receives XMS (HIMEM), EMS, DPMI and mouse support services from its VDM environment (assuming the virtual DOS machine has default DOS settings). DOS should not therefore load its own HIMEM, EMS or mouse drivers; indeed they may cause errors in the VDM. DOS programs call these services via appropriate API register parameters and a designated interrupt: Mouse INT 33h XMS INT 2Fh (multiplex) EMS INT 67h These interrupts are trapped by the VDM environment, routed outside the virtual machine and handled by the OS/2 Version 2.0 operating system itself. This may present a problem for certain programs which first test for the presence of such services by issuing an OPEN command to the associated device driver, or which check that a valid interrupt handler is referenced by the Interrupt Vector Table. When a VMB session is started, these device driver names are not present, and the interrupt vectors point to null handlers. The application will therefore assume that the required services are not useable. In order to avoid this problem, OS/2 Version 2.0 provides three alternative "stub" drivers: - MOUSE.COM - HIMEM.SYS - EMM386.SYS These stub drivers are very small (and use minimal memory when loaded) but satisfy programs which depend on drivers with such names being present. They respond to OPEN commands, and also set handler addresses in the Interrupt Vector Table, thereby satisfying applications which check for the presence of the device drivers in either of these ways. The user must load these OS/2 files rather than any similarly named files which may be shipped with DOS or applications, such as: DOS 4.0 XMAEM.SYS, XMA2EMS.SYS DOS 5.0 HIMEM.SYS, EMM386.EXE, MOUSE.COM DR DOS HIDOS.SYS, EMM386.SYS, EMMXMA.SYS Other MOUSE.SYS There are two ways to achieve this. Assuming OS/2 Version 2.0 is installed on drive E: 1. Copy the above OS/2 files from E:\OS2\MDOS to the DOS diskette, and edit CONFIG.SYS and AUTOEXEC.BAT accordingly to load these files from the A: drive. VMDISK may then be run to create a bootable image if desired. device=a:himem.sys device=a:emm386.sys device=a:fsfilter.sys This method should be used if FSFILTER will be loaded into high memory using DOS 5.0: device=a:himem.sys device=a:emm386.sys devicehigh=a:fsfilter.sys 2. Edit CONFIG.SYS and AUTOEXEC.BAT to load these files directly from E:\OS2\MDOS. (FSFILTER.SYS must be loaded first if the OS/2 drive would otherwise be inaccessible to the booted DOS). device=a:fsfilter.sys device=e:\os2\mdos\himem.sys device=e:\os2\mdos\emm386.sys The second method has one notable advantage; if and when Corrective Service is applied to the OS/2 Version 2.0 system, and HIMEM, EMM386 or MOUSE are updated, it is not necessary to update your DOS diskettes and recreate image files. FSFILTER itself will have to be updated manually (unless the OS/2 Version 2.0 partition is directly accessible to DOS and FSFILTER is also loaded from here). Note that EMS memory size and frame location are determined by DOS Settings, and not by parameters on the DEVICE= statement for EMM386.SYS. It is recommended that EMS and XMS support should not be configured unless required by the application running in the VMB session, since this can impact overall system performance. We now look at the three different ways to prepare the real DOS to be booted in the VMB. 12.2.3 Booting from Diskette The user may load a specific version of DOS or an equivalent 8086 operating system into a VMB session directly from a bootable diskette, by specifying A: at the value for DOS_STARTUP_DRIVE under DOS Settings. Note that this may affect the way in which applications in the VMB session may access the diskette drives; see "Drive Letter Allocation and Access" in topic 12.2.1.1 for further discussion. Here is an example using DOS 5: 1. From a system running DOS 5, format a diskette with the /s option. 2. Copy FSFILTER.SYS from the OS/2 V2.0 subdirectory \OS2\MDOS onto the diskette. 3. Create CONFIG.SYS and AUTOEXEC.BAT on the diskette. A sample CONFIG.SYS to use is as follows (OS/2 V2.0 is installed in E: drive in this example): REM Load FSFILTER driver DEVICE=A:FSFILTER.SYS REM load the stub XMS and EMS memory drivers from OS2. DEVICE=E:\OS2\MDOS\HIMEM.SYS DEVICE=E:\OS2\MDOS\EMM386.SYS A sample AUTOEXEC.BAT to use is as follows: @ECHO OFF PROMPT $P$G REM set the path to where the DOS files were copied SET PATH=C:\DOS SET COMSPEC=C:\DOS\COMMAND.COM REM load the stub mouse driver from OS/2 V2.0 LH E:\OS2\MDOS\MOUSE 4. Create a DOS subdirectory on the hard disk and copy the real DOS files there. 5. Insert the DOS boot diskette in the A: drive. 6. Locate the Command Prompts folder. It is usually a folder in the OS/2 System icon on the Workplace Shell. 7. Open the Command Prompts folder. 8. Locate the DOS from drive A: icon and double click on it. The DOS_STARTUP_DRIVE setting of this icon is pre-set to the value A:. The user cannot specify "B:" or an external diskette drive as the startup drive. There may be situations where it is desired to boot from a 5Ñ inch diskette; typically the B: drive on PS/2 systems. One way to do this is by creating an image of the diskette, then booting this image (See "Booting from Diskette Image" in topic 12.2.4). If a 5Ñ inch diskette must be booted directly for some reason, this is possible if drive remapping is supported by the system (such as a PS/2 Model 57, 90 or 95). Normally A: is Drive 0 (3ç inch), and B: is Drive 1 (5Ñ inch, if fitted). To change this, run "Set Startup Sequence" from the reference diskette, and ensure Drive 1 appears before Drive 0. Then the 5Ñ inch drive will become the A: drive. Some 5Ñ inch drives (such as the IBM External 1.2MB drive and associated adapter) require a device driver, and are accessed as D: or higher. They cannot be specified as a startup drive, nor can they be readdressed as A:, but can be the source drive when creating a bootable image file. 12.2.4 Booting from Diskette Image A user may also load a specific version of DOS or another 8086 operating system into a VMB session from a diskette image stored on the hard disk. This is achieved by specifying the fully qualified filename of the diskette image file as the value for DOS_STARTUP_DRIVE under DOS Settings. Here is an example using the DOS 5 boot diskette created in the "Booting from Diskette" in topic 12.2.3 above: 1. Edit CONFIG.SYS on the diskette and add the following statement: E:\OS2\MDOS\FSACCESS G: = A: 2. Create the image of the boot diskette on the hard disk. Images may be created using the VMDISK utility supplied with OS/2 Version 2.0. The syntax of the VMDISK command is: vmdisk <source drive> <image filename> For example: VMDISK a: c:\bootimg\dos50.vmb The image file is a complete binary "dump" of the diskette, consisting of a short header record followed by the diskette's boot sector, FAT(s), and all data clusters. Its file size corresponds to the size of the source diskette, regardless of the amount of space actually used on the source diskette. No compression of the image is performed. The diskette must have a standard DOS format (FAT, 512 byte sectors). It is not possible to create, then boot, an image of a copy-protected diskette which has a non-DOS format. It may be possible to boot such a diskette directly in a VDM. The VMDISK utility can run under either DOS or OS/2, and supports all 3ç inch (720KB, 1.44MB and 2.88MB) and 5Ñ inch (360KB and 1.2MB) source diskette formats. Note that VMDISK works one way only; it is not possible to create a diskette from a VMDISK image. 3. Proceed to add an icon to the OS/2 V2.0 Workplace Shell to launch VMB. Refer to "Putting the Virtual Machine Boot Session in the Workplace Shell" in topic 12.2.6 on customizing the Virtual Machine Boot, in particular the DOS_STARTUP_DRIVE setting. 12.2.5 Booting from a DOS Partition If VMB will be used regularly, the most convenient method may be to do so from a DOS partition on hard disk, rather than via diskettes or diskette images. This may be achieved by specifying C: as the value for DOS_STARTUP_DRIVE under DOS Settings. Loading DOS from a DOS partition proceeds more quickly and offers the user a more "familiar" working environment. It is also easier to apply DOS Corrective Service to a disk partition than to diskettes or images. Note that this method is different from that of a single hard disk partition with the Dual Boot feature available under previous versions of OS/2. In order to load DOS from a DOS partition, the following requirements must be satisfied: 1. Boot Manager must be installed 2. DOS must be installed on a primary partition on the first hard disk in the machine 3. OS/2 Version 2.0 must be installed on an extended partition on the first fixed disk, or on another hard disk. This will require re-partitioning on single-drive systems if the disk initially contains DOS alone, or earlier versions of OS/2. Loading DOS from a DOS partition presents one significant problem. The DOS partition is itself bootable directly via Boot Manager, should the user so choose, and there may a requirement to boot this DOS partition directly on occasions. OS/2 Version 2.0 provides stub device drivers for functions such as EMS, XMS and mouse support in the VMB session, and these must be used in place of the normal DOS device drivers when DOS is booted in a VMB session. Since the same CONFIG.SYS and AUTOEXEC.BAT in the C: root directory is used, the question arises of which drivers should be specified for functions such as EMS and XMS support: - If the partition is booted via VMB, the DOS drivers are inappropriate - If the partition is booted directly via Boot Manager, the OS/2 stub drivers are inappropriate. It might appear that the user would have to maintain multiple configuration files and rename or copy them depending upon whether the partition was being booted into a VMB session or directly from Boot Manager. This is clearly unsatisfactory. Fortunately there is a solution which avoids this. The key is to specify both sets of drivers, in the correct order, in CONFIG.SYS and AUTOEXEC.BAT. The following example assumes: - DOS 5.0 is installed on the C: Primary partition - OS/2 Version 2.0 is installed on the E: Extended partition CONFIG.SYS on the C: drive contains: device=c:\dos\setver.exe device=c:\dos\himem.sys device=c:\dos\emm386.exe noems device=e:\os2\mdos\himem.sys device=e:\os2\mdos\emm386.sys dos=high,umb ... etc ... When this file is processed in an OS/2 VMB session, the DOS HIMEM load fails as it sees no available extended memory. EMM386.EXE cannot load as it sees protect-mode software already running. Then, the OS/2 HIMEM and EMM386 stub device drivers load as normal. When this file is processed as part of a native DOS boot, the DOS HIMEM and EMM386 load as normal, but the OS/2 stub device drivers detect that they are not running under OS/2 and do not load themselves. A similar technique works for mouse support in AUTOEXEC.BAT: @echo off prompt $p$g set path=c:\dos set path=c:\dos LH e:\os2\mdos\mouse LH c:\dos\mouse ... etc ... Note that here the OS/2 driver is listed first. When this file is processed in an OS/2 VMB session, the OS/2 stub loads first. The DOS mouse driver sees that a mouse driver is already present, and hence it does not install itself. When booting DOS natively, the OS/2 mouse stub device driver detects that it is not running under OS/2, and does not load itself. The DOS mouse driver then loads as normal. 12.2.6 Putting the Virtual Machine Boot Session in the Workplace Shell We are now ready to put the VMB session as an object on the OS/2 Version 2.0 Workplace Shell desktop. 1. Locate the Templates folder. It is usually an icon on the Workplace Shell. 2. Open the Templates folder. 3. Locate the Program icon template. 4. Drag the Program icon template on to the desktop. This will cause the Program Settings notebook to appear. 5. Enter an asterisk "*" in the Path and file name field. 6. Select the Session notebook tab. The Session notebook allows the user to specify the session type and DOS Settings for the VMB session. 7. Select either DOS full screen or DOS window and then select the DOS Settings... button. 8. Select the DOS_STARTUP_DRIVE list item. The difference between a VMB session and a "normal" VDM is that the DOS Settings value of DOS_STARTUP_DRIVE is set. This setting determines the location of the DOS kernel to be booted. By default, MVDM's DOS Emulation is loaded. However, the user may specify a location from which to load DOS, in which case the version of DOS residing at that location is loaded. Example values for DOS startup drive are: DOS Start up setting Meaning a: Boot using the diskette in drive A: c:\bootimg\dos50.vmb Boot using the specified DOS image file c: Boot using the primary partition of the C: drive The following restrictions apply: - A second diskette drive (B:) or hard disk (D:) cannot be specified as the startup drive. - To boot DOS from the C: partition, Boot Manager must be installed, and OS/2 Version 2.0 must reside in an extended partition on the first hard disk, or on another hard disk. See "Booting from a DOS Partition" in topic 12.2.5 . 9. Select the Save button to save the DOS settings and return. 10. Select the General notebook tab. 11. Change the Title field to your own name describing the new object. 12. Close the Settings notebook by double clicking on the system menu in the upper left corner of the window. 12.2.6.1 Other DOS Settings DOS settings which control the VDM hardware environment are applicable to the VMB session and operate in the same way as for a DOS Emulation windowed or full-screen session. Those which modify the virtual DOS environment are ignored; the equivalent settings are instead determined by the CONFIG.SYS file of the booted DOS kernel. Ignored settings include: - DOS_BREAK - DOS_HIGH - DOS_DEVICES - DOS_LASTDRIVE - DOS_UMB - DOS_VERSION - DOS_SHELL The FCB limit is the lesser of either the booted DOS, or OS/2 Version 2.0 CONFIG.SYS value. The VMB session will by default have 640KB of real memory, mou se support, 2MB Expanded (EMS) memory, 2MB DPMI, and 2MB XMS memory. 12.3 Managing the VMB Session The user may interact with a VMB session in a similar way to any other virtual DOS machine. The session may be scaled, minimized, maximized and switched between windowed and full-screen mode, and is subject to the same graphics mode limitations when windowed. However, a VMB session cannot be ended by typing EXIT at its command prompt. The session can only be closed from its system icon or the Window List. Note that Ctrl-Alt-Del will reboot the entire OS/2 Version 2.0 operating system, not just the foreground virtual machine session. 12.4 VMB Limitations VMB does not support: - VCPI and other non-DPMI DOS extenders - I/O to disk which bypasses the file system - Feature adapter sharing without a virtual device driver - Real-time or timing-critical DOS applications - Some copy-protection schemes. These limitations arise in the most part from the limitations of the MVDM environment, which are imposed in order to protect overall system integrity. 12.5 Summary The DOS Emulation kernel which is normally used to support the execution of DOS applications in a VDM is exactly what its name implies; an emulation of the DOS operating system and associated services. While this suffices for most DOS applications, certain applications exist which take advantage of unique and/or undocumented features which exist only in specific versions of DOS. To allow such applications to be successfully run under OS/2 Version 2.0, the VMB (Virtual Machine Boot) feature is provided. This feature allows a "real" DOS operating system, or indeed most other 8086 operating systems, to be booted in a virtual DOS machine. The operating system may be booted from either a diskette in drive A:, a diskette image on a hard disk, or a partition on a hard disk. Applications which run using Virtual Machine Boot may take advantage of the EMS, XMS and mouse support provided to virtual DOS machines by OS/2 Version 2.0. This support is provided through stub device drivers supplied with OS/2 Version 2.0; these should be used in preference to the device drivers supplied with the operating system or applications. ------------------------------------------------------------------------------- Thank you for calling the OS/2 2.0 Support Line. Regarding the problem reported to the Support Line, we feel that this information may assist you in resolving your problem. If you still require assistance, please call 1-800-237-5511, and reference your customer number and problem (PMR) number. Your Problem Record Number (PMR) should appear on the cover page of this faxed document.