
					 
   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
