컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 袴袴袴袴袴袴袴袴袴� The OS2DOS Frequently Given Answers 袴袴袴袴袴袴袴袴袴� 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� A selection of some of the frequently asked questions from the International FIDONET OS2DOS echo, and, more importantly, their frequently given answers. Preliminary version 0.01. 19950205. Introduction 컴컴컴컴컴컴 The International FIDONET OS2DOS echo is one of a family of several echoes on FIDONET dealing with OS/2. OS2DOS deals specifically with DOS and Windows programs running under OS/2, and anything to do with OS/2's Virtual DOS Machines. The FIDONET OS/2 Echo Family are backboned in all zones, and should be available from locally all around the world. If you cannot find an echo from the family, ask your sysop or your echomail feed. This selection of Frequently Given Answers is by no means exhaustive, but is meant to cover some of the more popular topics that regularly come up in the echo. Readers of the FGA are reminded to *ALWAYS READ THE OS/2 USER GUIDE*. Neither the OS2 family of echoes, nor the FGA are meant as a substitute for the user guide, and many topics that people regularly ask about are in fact covered extensively in the user guide and the on-line help for OS/2. The manual *is* your friend. The OS2DOS FGA document is archived on DoNoR, one of the larger OS/2 sites in the United Kingdom. It is available for File Request 24 hours per day, every day of the year as OS2D-FGA.ZIP from 2:440/4.0. Applications 컴컴컴컴컴컴 � What sorts of DOS and DOS+Windows applications will work under OS/2 ? Almost all of them. The exceptions are detailed in the next answer, and are actually restricted to a couple of specialised areas, as you will see. � What sorts of DOS and DOS+Windows applications will not work under OS/2 ? There are essentially two sorts of softwares that will, by design, not work under OS/2. The first are those that attempt to write to the hard disc at a low level, such as disc doctoring programs. Low level writes to the hard disc from Virtual DOS Machines under OS/2 are not allowed, because DOS disc doctoring programs are written with the assumption that nothing else will be be accessing the disc at the same time as they are. Since OS/2 is a multitasking system, this becomes a possibility. DOS disc doctoring programs could thus cause consistency problems leading to severe filesystem corruption were they allowed to write to the disc directly at a low level. Native OS/2 programs are allowed to write to the hard disc directly, but they use OS/2 services (for which there are no DOS equivalents) to negotiate obtaining exclusive access to the disc whilst doing so. The second sort of software that will not by design work under OS/2 are those softwares that use the VCPI standard for DOS extenders. VCPI is a dead standard, which died years ago. No-one supports it these days, and programs that use it will only work on raw DOS. Most DOS memory managers will prevent VCPI programs from running as well, because VCPI demands total control of the entire machine. If you find that software that you have bought relies on VCPI, send it back *directly to the manufacturer* demanding a full refund. Don't support authors of VCPI software by continuing to give them money. Programs that use the newer DPMI DOS extender standard will not have any such trouble under OS/2, as DPMI programs do not require total control over the entire machine. � VxDs don't run under OS/2, do they ? No they do not. VxDs are drivers for Windows that require the ability to run in real mode when they start up. OS/2 *always* runs the Windows kernel in v8086 protected mode. Running in real mode would disable multitasking, and bypass all system protection, so OS/2 does not support VxDs. Most VxDs are kludges, written to provide support for unusual devices to DOS boxes within Windows. Under OS/2, hardware support for unusual devices in VDMs is provided by proper protected mode virtual and physical device drivers, supplied by the manufacturer. Check with your manufacturer for native driver support. All good manufacturers can supply VDDs and PDDs for their hardware nowadays. � AutoCAD for DOS doesn't work under OS/2! Oh yes it does. AutoCAD uses the Phar Lap DOS extender. Prior to release 12c2 of AutoCAD, this DOS extender used VCPI. Subsequent releases of the Phar Lap DOS extender use DPMI, and work under OS/2. AutoDesk has been supplying an update to the Phar Lap DOS extender almost since that release of AutoCAD. Call AutoDesk and ask for it. While you are talking to them, ask them whether they've finished a native OS/2 version of AutoCAD yet. � Microsoft Visual C++ for DOS doesn't work under OS/2! Oh yes it does. Microsoft Visual C++ also uses the Phar Lap DOS extender. However, Microsoft's tech support runs true to form, and only makes fixes for its software available under protest. So your best route is to obtain the fix from Phar Lap's BBS directly, or from your nearest FIDONET site that is part of the Fernwood file distribution system. The Phar Lap DOS extender bugfix cures the problem with the command-line tools in MSVC++ and allows them to run properly. The Visual Workbench, however, uses a VxD as a back door into the internals of the Windows kernel, allowing it to start up and control DOS sessions under DOS+Windows, in particular for running NMAKE "seamlessly". When you come to generate programs in Visual Workbench, when you receive the error message that VWB could not run NMAKE, simply start another VDM within OS/2, and run NMAKE from there. You can even set up a Workplace Shell program object to run NMAKE if you like. VWB will have created the makefile properly for you. This has the advantage of allowing you to compile and edit simultaneously, which you normally cannot do with Visual Workbench. Just FYI, you are suffering from always having to play catch-up by using MSVC++. By past record, it is usually the last to adopt any changes to the C++ language ("Not Invented At Microsoft"), and bugfixes are rarely published ("Wait for the next version"). There are far better C++ compilers available, such as Watcom C++ or Metaware High C++, with much better update and bugfix policies. Watcom C++ can even cross-compile DOS+Windows programs from a native OS/2 hosted environment. But this is straying into the realms of the FIDONET C_PLUSPLUS echo. � Doom for DOS doesn't work under OS/2! Oh yes it does. Unfortunately, ID Software suffers from the sort of tunnel vision that afflicts most games software houses. They like to hit the hardware directly instead of using the device drivers. ID accesses the sound card directly, and doesn't quite get it right. Under DOS, this is unnoticable. Under OS/2, however, because of multitasking the timing code goes wrong. This causes problems, and sends ID's code into a flat spin. To run any game that uses the ID Software game engine, such as Doom or Heretic, switch the sound off and use the PC Speaker. If you find that this spoils your enjoyment of the game, send the game back *directly to the manufacturer* asking for a full refund, and explain that you find it unsatisfactory that their sound facilities don't work in the OS/2 multitasking environment. � I have a DOS application written by Borland. When it starts I get half a page of gibberish, then the VDM ends with a SYS3176. Borland's interpretation of the DPMI standard differs from that of most other software manufacturers. In particular, Borland's software initialises DPMI in a way different to the way that most other people do it. The rights and wrongs of it aside, the cure is easy. Go to the VDM settings for that session object and change DPMI_DOS_API from AUTO to ENABLED. This will work for any Borland application that uses the Borland DPMI DOS extender (look for a DPMILOAD.EXE or RTM.EXE file). � I cannot install my Borland DOS program as a program object on the Workplace Shell desktop. All of the buttons on the [Session] page of the settings notebook are greyed out. This is an artifact of Borland's proprietary DPMI DOS extender. Its DOS extended programs are in the 16-bit New Executable EXE file format, but they have a meaningless value in the "target operating system" field in the executable file header. This means that when Workplace Shell comes to inspect the executable file header to determine what sort of session it needs to start the program in, it finds illegal values and becomes confused. The simple solutions are either to use a short batch file, or to use "*" as the program name and "/C C:\BORDIR\BORPROG.EXE" as the program parameters. By the way, this information is in the Borland manuals for all of the individual Borland DOS products. Why didn't you read the manual ? The manual *is* your friend. � I have a game that doesn't work properly under OS/2! Although it is not possible to provide a catch-all for DOS games softwares (see the FGA for Doom for a note on the programming ethos of some games software houses) some avenues to explore follow that often yield results. Try the memory settings. If the game says on the box that it requires a minimum amount of extended memory, ensure that the extended memory settings in the VDM settings dialogue are above that minimum. Do the same for expanded memory. If the expanded memory settings are set unreasonably high, and the game still reports a problem with being unable to initialise expanded memory, you may have a game written using VCPI. Check the documentation for this, and if it turns out to be so, return it *directly to the manufacturer* asking for a full refund. Try the video settings. Some games require unusual video modes. Since the video hardware is virtualised in VDMs, you may be required to alter the VIDEO_8514A_XGA_IOTRAP and VIDEO_RETRACE_EMULATION settings in the VDM settings dialogue for that session. Incidentally, if you have not installed your video drivers properly in the first place, DOS games will usually "discover" your error for you. � My DOS comms application has lots of errors. What can I do ? Really, this is one of the Frequently Given Answers in the FIDONET OS2DOSBBS echo. Very briefly: you need a proper buffering 16550 UART when doing interrupt-driven comms, and you may also like to try Ray Gwinn's SIO serial device drivers. � My DOS comms application is dead slow/slows down other applications. What can I do to make things faster ? This too is one of the FGAs in the FIDONET OS2DOSBBS echo. However, here is an example of how to tune TELIX, which may help. TELIX is a very poorly behaved application. It polls the keyboard and the comms port almost continuously, and so wastes a lot of valuable CPU time that could be used more productively by other applications. Installing OSTSR or OS2SPEED helps somewhat, because TELIX knows how to perform DesqView timeslice release calls. However, TELIX still consumes a disproportionate amount of CPU time when doing file transfers. To reduce the impact of TELIX on other applications, leave it idle and offline, and bring up Pulse. Gradually adjust the IDLE_SENSITIVITY setting for the VDM running TELIX until Pulse falls to zero (which will usually be around the 33 mark). This is by no means perfect, but is the best general rule of thumb for TELIX that there is. Of course, if you use TELIX, you might as well do the sensible thing and upgrade to LiveWire for OS/2. After doing so, you'll realise just how bad TELIX really was. Of course, native OS/2 comms softwares are properly the subject of a different Frequently Given Answers document. Utilities 컴컴컴컴� � How do I start another session from within a VDM ? There are several utilities available to do this. JP Software's excellent 4DOS replacement command interpreter comes complete with a START command, that mirrors most of the function of the START command available at a native OS/2 command line. The /DOS switch, that is used to start VDMs, can take an optional argument to specify the name of a file containing the VDM settings to use. Other utilities include STARTD, DSTART, and HSTART, which all behave similarly to 4DOS' built-in START command, and all of which are widely distributed on file sites across FIDONET. � My software knows how to release timeslices to DesqView, but not to OS/2. What can I do ? There are two utilities available to convert DesqView timeslice releases into OS/2 timeslice releases, namely OS2SPEED and OSTSR, both of which are widely available on FIDONET OS/2 file sites. You can File Request OSTSR and its companion program OSTITLE from Jay Clegg's home node, 1:360/12.0, as OSTSR12.ZIP (14Kb). If you do, please drop him a short note just to say hello as well. � I've installed OS2SPEED, and 4DOS now causes my VDMs to abort! Really you should read the 4DOS on-line documentation, because this is explained there. 4DOS is DesqView aware, and is fooled by OS2SPEED into thinking that it is running under DesqView. It attempts to hook into DesqView, and goes haywire because it isn't actually there. You need to adjust the DVCleanup setting in your 4DOS.INI file. Now go and read 4DOS.DOC. The manual *is* your friend. � How do I defragment or repair my SuperFAT partitions under OS/2 ? If you want an OS/2 solution, there are SuperFAT defragmentation utilities available for OS/2. GammaTech sell a SuperFAT defragmentation tool as part of their suite of disc maintenance utilities. The Graham Utilites apparently come with a SuperFAT defragmenter. SafePack for OS/2 is a SuperFAT defragmentation tool. As for DOS defragmentation utilities, there are two problems. The first is that DOS programs are not allowed to write to the hard disc at a low level when run on OS/2, even though they are allowed to read from it. This means that DOS defragmentation utilities must be run by booting from a DOS boot disc. This is not such a major problem. The second is that not many defragmentation utilities are aware of extended attributes. In SuperFAT partitions, the directory records contain extra information for each file, pointing to its extended attribute information. Some defragmentation utilities, most notably PC-Tools COMPRESS, will complain that extended attribute pointers are actually "errors" in the filesystem, and will "fix" them by wiping them completely. This will cause severe problems. People have reported good results with Norton SpeedDisk, and the DEFRAG utility that comes with Novell DOS. However, it seems that different versions of these softwares behave differently. Certainly their behaviour with respect to extended attributes is not guaranteed by the manufacturers. It is wise *not* to run defragmentation utilities on a SuperFAT partition if it is the OS/2 boot partition unless you are *sure* that they will not zap EA pointers (or unless you have full backups), because the Workplace Shell desktop depends heavily from EAs. By far the best solution is to make the OS/2 boot partition an HPFS partition. You won't need to run defragmentation software (you won't be *able* to run *DOS* defragmentation softwares against an HPFS partition), and in the event of an error HPFS will be more recoverable than SuperFAT. � What are 4DOS and 4OS2 anyway ? 4DOS and 4OS2 are replacement command interpreters from JP Software, that provide *many* features and improvements over the standard command interpreters. 4DOS replaces COMMAND, and runs both on DOS and in an OS/2 Virtual DOS Machine. 4OS2 is 4DOS' big brother, and replaces CMD, the native command interpreter for OS/2. This FGA won't go on at length about the many improvements and facilities available in 4DOS and 4OS2, because there is not the room. Suffice it to say that they make whole piles of extra utilities unnecessary, and make life a lot more pleasant for the command line or batch file user. Both 4DOS and 4OS2 are discussed in the FIDONET 4DOS echo. The author hangs out there as well. You can obtain 4DOS and 4OS2 from many FIDONET file sites (ask in FIDONET 4DOS for your nearest one) and try them yourself, since they are available on a try-before-you-buy basis. The filenames to look out for are 4DOS55A.ZIP, 4DOS55B.ZIP, 4OS232A.ZIP, 4OS225B.ZIP, and JP4REF.ZIP. Full OS/2 installation instructions for 4DOS and 4OS2 are contained in the package. Configuration 컴컴컴컴컴컴� � Do I need the Windows permanent swap file, 386SPART.PAR ? No. When Windows is run in OS/2, all swapping is done by OS/2 to its own (dynamically sized) swapfile, because OS/2 handles all memory management. The Windows permanent swapfile may be deleted, since it is just taking up valuable disc space for nothing. � What is WINDOS.COM ? OS/2 needs to adjust the Windows kernel "on the fly" in order to make it use an external DPMI server (i.e. OS/2) for its DOS extender. It does this by using its own loader program, WIN.COM, to start the Windows kernel on top of the VDM kernel. The loader program for running the Windows kernel on top of a raw DOS kernel, that is supplied with Windows itself, is renamed to WINDOS.COM. When the OS/2-supplied WIN.COM detects that it is running on raw DOS (as will happen in Dual Boot setups), it simply executes WINDOS.COM, and the Windows kernel is loaded using the DPMI server built-in to Windows for its DOS extender. � What is SuperFAT ? Is that like FAT ? SuperFAT is a superset of the old FAT filesystem format. It includes extra facilities for the storage of extended attributes for files. The "EA DATA. SF" file in the root directory may look like a normal file, and appears that way when using DOS+Windows (which expects the old FAT format), but in fact it is maintained by the SuperFAT filesystem driver to contain EA data for all files on the partition. You cannot delete "EA DATA. SF" by the way, because when a file is deleted the SuperFAT filesystem driver opens "EA DATA. SF" to delete any extended attributes for the file. When you try to delete "EA DATA. SF" itself, it is found to be already open, and the delete operation fails. In other words, leave "EA DATA. SF" alone. Contrary to popular belief, the "WP ROOT. SF" file is not part of the SuperFAT format. It is maintained by Workplace Shell, not OS/2 itself, and stores some WPS desktop settings for each drive. If you delete "WP DATA. SF", Workplace Shell will re-create it next time that you use WPS to access that drive. � Should I choose HPFS or SuperFAT ? If you are free to make a choice, then HPFS is much the better choice. It supports long filenames; it can handle partition sizes up to two Terabytes; and especially it doesn't have the ridiculously large cluster overheads when used on large partitions that SuperFAT does. Most importantly, perhaps, is that HPFS is more recoverable than SuperFAT. There is a lot more redundancy in the filesystem structure for HPFS, and CHKDSK is thus far more capable of recovering lost data on HPFS partitions in the event of errors or dirty shutdowns. For the full HPFS/FAT discussion, and incidental discussions covering partition size limitations, there are separate FGAs available in the FIDONET OS2 echo covering these subjects. � Can I switch to HPFS without repartitioning ? Well, yes and no. You must repartition, because HPFS is a different partition type to SuperFAT. However, if you do not wish to lose data, then you may wish to investigate Partition Magic, which is a commercially available utility designed to enable you to alter the partitioning of your hard disc without losing data. Alternatively, you could take the opportunity to ensure that you have proper off-line backups of all of your data. � Can DOS and DOS+Windows programs run from and use HPFS ? When running under OS/2, yes, of course they can. Any partition that OS/2 can read natively is available to DOS and Windows applications running on OS/2, and will look like just another drive letter. This covers HPFS, CD-ROM filesystems, and even network drives. Unfortunately, the 8.3 filename limit is hard-coded into the vast majority of DOS and Windows applications, so they won't be able to "see" any filenames that are not in that format on partitions that support long filenames (such as HPFS, NETWARE and LAN SERVER filesystems). Many OS/2 users are happily running their DOS and DOS+Windows applications on all-HPFS systems. � Should I use Dual Boot or Boot Manager ? Again, if you are free to make a choice, then Boot Manager is the way to go. Not only does it give you more flexibility (it allows you boot from partitions on your secondary disc units), but it also protects you from yourself to some extent. The dangers of Dual Boot are twofold. Firstly, it plays musical chairs with your boot sector and configuration files every time that you switch operating systems. This can, and does, cause confusion. Virus detection softwares that checksum the boot sector will go barmy every time that you use Dual Boot. Secondly, Dual Boot tacitly encourages the mistaken belief that it is all right to run DOS disc maintenance programs on an OS/2 SuperFAT boot partition. Apart from the considerations mentioned in another answer, even simply using some versions of DOS to manipulate files and directories on SuperFAT partitions can mess up EA pointers (Novell DOS file passwords will corrupt EA information on SuperFAT partitions, for example). � What can I do to `tune' OS/2 in general ? Chris Johnson of 1:208/610.0 maintains a list of "Performance Tips for Power Users". Currently this is not yet available for File Request, but if you netmail him at that address he should be happy to netmail you a copy. There are other documents and tools widely available that detail the settings in CONFIG.SYS, although no information on their whereabouts was available at the time of going to press. If you have such a document, please netmail the details to the FGA maintainer for inclusion here. Hardware and drivers 컴컴컴컴컴컴컴컴컴컴 � My soundblaster doesn't work from Windows under OS/2! The SoundBlaster drivers that shipped with Windows 3.1x are the ones that were available several years ago. They had bugs in. In particular, the Voyetra MIDI drivers as supplied with Windows 3.1x will not work under OS/2. You can obtain updated versions of these drivers from Creative Labs BBS or via Creative Labs Tech Support. You should also note two further things. Firstly, the DOS+Windows SoundBlaster drivers are written assuming that they are running on a bare DOS machine. This means that when they initialise (i.e. each time that a Windows VDM starts), they reset the sound hardware. If your soundblaster is on a non-standard port or interrupt, you *may* (depending from your exact hardware configuration) need to run a utility from AUTOEXEC.BAT (which runs every time that a VDM starts) to reconfigure your SoundBlaster. Usually you will be using the OS/2 Multimedia SoundBlaster drivers, of course. Secondly, the SB hardware was not designed to be used by more than one thing at once. If OS/2 is playing sounds, Windows within OS/2 will not be able to, and vice versa. OS/2's multitasking is nice, but it doesn't magically cure hardware deficiencies. Sound hardware like the PAS16 can be used from OS/2 and Windows under OS/2 simultaneously, because it contains two sets of circuitry. Configure Windows to use the SoundBlaster circuitry, and OS/2 to use the PAS circuitry. � I cannot get MSCDEX to work under OS/2! You're doing things wrong. MSCDEX is the DOS way of doing things. OS/2 has proper native protected mode device drivers for accessing CD-ROM devices. Just go into Selective Install and install them, and all applications under OS/2 will be able to see your CD-ROM. It used to be the case that some popular CD-ROM drives (mainly those with proprietary non-SCSI interfaces) did not have OS/2 device drivers. This was back in 1993, though. OS/2 now has device drivers for the vast majority of CD-ROM drives. With WARP, they come right in the box, and they are also available as packs from the various manufacturers for users of older versions of OS/2. For DOS programs, access to files on CD-ROM will be through normal filesystem calls, which will be routed to OS/2, and the OS/2 CD-ROM device drivers. Access to audio services, which is the other half of what MSCDEX does for raw DOS, is provided by the VCDROM.SYS virtual device driver, which is installed automatically when you install CD-ROM support. The only DOS program that cannot use CD-Audio without MSCDEX is Terminate. Bo is checking for MSCDEX incorrectly, apparently. Complain to him to get it fixed, or just ignore the CD features of Terminate (why does a terminal program need this stuff anyway?) and use the native OS/2 CD-Audio players. ( Before the advent of the CD-ROM device drivers in late 1993, the Frequently Given Answer for MSCDEX use to explain at great length all about how MSCDEX is one of the most ill-behaved DOS programs ever, since it hooks into all sorts of version-specific back doors in the DOS kernel, and how it is possible to patch it to skip the version check. That is now not the best answer to the question. ) Programming 컴컴컴컴컴� � How do I detect when my DOS programs are running under OS/2 ? The official method has always been to check the DOS version number. OS/2 returns version numbers that are greater than 9. DOS version 20.x is OS/2 version 2.x, for instance. You should always check that the version number is greeater than or equal to a given number, and never for an exact match. This only works in a VDM, naturally, since a VMB runs a real DOS kernel, which will report its real version number. There is no reliable way to determine that you are running in a VMB. � How do I release timeslices under OS/2 ? The call that you want is the standard INT 0x2F AX=0x1680 call, which will release timeslices back to OS/2. Only use this call when your program is really doing nothing other than polling, though. Rely on the OS/2 scheduler to determine a priority for the VDM when your program is actually doing useful work. It almost always gets things right, and second guessing it usually makes things worse, not better. Thank you for writing OS/2 friendly DOS programs. Please take the next step and write proper native OS/2 programs. The people in the FIDONET OS2PROG echo will be happy to help you with porting. � Anything else that I can do from DOS programs running under OS/2 ? Well, yes. A lot of the old 16-bit OS/2 API is available via semi-documented calls from within VDMs. You can find a list of them in Ralph Brown's interrupt list. But this is really making life too complex for yourself. If you want to take advantage of OS/2 facilities such as semaphores and named pipes, then write a native OS/2 program. The API is much easier to call than messy DOS interrupts, and is exceedingly well documented. There are a wide range of languages available for OS/2, from C++ to FORTH, as well. Technical Concepts 컴컴컴컴컴컴컴컴컴 � How does OS/2 support DOS and DOS+Windows applications ? A normal OS/2 process runs in protected mode, and sees a simple, flat, linear virtual memory space, which can be up to 512Mb. However, OS/2 can use the v8086 protected mode of the 386/486/586 CPUs to emulate the environment and memory map that an ordinary DOS application would see. This is what allows DOS and DOS+Windows applications to run under OS/2. Extended DOS applications usually run in `normal' protected mode, very similar to normal OS/2 processes, in fact, except DOS extenders expect the bottom megabyte of the virtual address space to contain a DOS environment. OS/2 acts as a DOS Protected Mode Interface (DPMI) server, to allow DOS programs to switch between normal and v8086 protected mode, and to manage memory in both. The Windows kernel itself is architecturally no more than a DPMI DOS extender. Windows applications run in normal protected mode, but rely on the underlying DOS services for things like file access. Windows uses the DOS Protected Mode Interface to switch back and forth between normal protected mode and v8086 mode in order to service DOS calls from Windows applications. � What about virtual memory ? The memory map of a v8086 protected mode process has the same conventional/upper/high/extended memory map that a machine actually booted into DOS has. However, all of this is in fact virtual memory. OS/2 pages the memory of any and all v8086 processes to and from disc transparently. DOS and DOS+Windows applications are unaware of this. Unlike DOS+Windows, under OS/2 the address spaces of all v8086 processes are entirely distinct. This prevents one session from interfering with another, and also allows multiple sessions to be configured differently. � What are VDMs and VMBs ? Both VDMs and VMBs are OS/2 processes, and use normal OS/2 services. However, they rely on translation layers to convert DOS services requested by DOS or DOS+Windows applications into calls to OS/2 services. A Virtual DOS Machine is colloquially known as "a DOS session", and is where OS/2 emulates the complete DOS environment, including all DOS services. It uses a built-in version of the DOS kernel, that maps most DOS services directly onto their OS/2 equivalents. A Virtual Machine Boot only emulates the BIOS portion of a DOS environment, and `boots' a real DOS kernel on top. This kernel is either an actual disc partition, a floppy disc, or an image file of a disc partition or floppy disc. � When would I need a VMB instead of a VDM, and how do I go about creating one ? It is rare that you would need a VMB. The main reason for needing a VMB is when a program requires access to the undocumented internals of the DOS kernel. Since the DOS kernel used in a VDM merely translates DOS services to OS/2 services, many of the undocumented internals of the DOS kernel are absent. Programs that rely on these internals require a `vanilla' DOS kernel, hence the reason for VMBs. Fortunately, such programs are very rare. The most common ones are DOS client networking softwares, and in most cases it is often simpler to obtain the OS/2 client versions of the softwares (most networks, including Netware and LANTastic, supply OS/2 client softwares, often as part of the package). To create a VMB, you simply change the DOS_STARTUP setting in the VDM settings for that program object to point either to a driver letter or to an image file. To find out how to create an image file, read both the section in the Master Help Index entitled "starting a specific version of DOS", and the on-line help in the Command Reference under VMDISK. � What is the VMM and what are VDDs ? The Virtual Machine Manager is the part of the OS/2 kernel that handles setting up the v8086 process itself, and administering the Virtual Device Drivers and, if necessary, the built-in VDM kernel. Virtual Device Drivers are in control of emulating hardware and device services for a VDM or VMB. The VCOM.SYS virtual device driver, for example, emulates the physical UART hardware in each VDM/VMB, translating all low level UART accesses into normal OS/2 API accesses to the COM device. Virtual Device Drivers are in fact what provide and interpret the "VDM settings" that you see in the settings dialogue on the desktop. For more information on VDDs and the internals of a VDM/VMB, consult the Virtual Device Driver Reference published by IBM, which can be found (along with a whole heap of other technical reference books) in electronic form on the OS/2 Online Book Collection CD-ROM (IBM part number 53G2166, costing roughly �30). 컴컴� (c) Copyright 1995. All Rights Reserved. Permission is hereby granted to redistribute this document in original form without modification, as long as no fee is charged, and as long as you realise that I take no responsibility whatsoever for what it does to your machine, data, cat, or marital status. Jonathan de Boyne Pollard Moderator, International FIDONET OS2DOS echo FIDONET 2:440/4.3