------------------------------------------------------------------------------
------------------ Frequently Asked Questions About PMODE/W ------------------
------------------------------------------------------------------------------
----------------------------- Updated 2/11/95 --------------------------------
------------------------------------------------------------------------------


Q: Is PMODE/W 100% compatible with DOS/4GW?
A: PMODE/W is compatible with most Watcom C/C++ functions. However, PMODE/W
   does not support all of the extensions and API functions which DOS/4GW
   does. DOS/4GW does a number of things that we feel are quite unnecessary
   for most applications and most likely you will never miss them (especially
   since they waste a lot of your precious memory and disk space). Why extend
   something, wasting system resources, when you may not even be using it in
   your program? So remember: before blaming a problem with your program on
   PMODE/W, make sure that what you are doing is indeed supported by our
   system. Read PMODEW.DOC for more information.

Q: What does not having an exception handler do to my program?
A: If it's properly coded, absolutely nothing. An exception should only occur
   in the event that your program has a bug. Exception handlers may provide
   a minimal degree of security to your program, but in the long run end up
   slowing it down. Installing exception handlers means having to take control
   of any IRQ that goes off first, examine it, and then pass it down to its
   appropriate handler. We would rather not slow down IRQ processes in this
   way because our goal here is to run your code as fast as possible. If you
   require exception handling while developing, you can compile your program
   using DOS/4GW and test it with that. Just about anything that is not
   out of the ordinary which you do under PMODE/W should work correctly under
   DOS/4GW. PMODE/W is designed in such a way that you can even execute a
   PMODE/W executable under DOS/4GW without the need to recompile. Simply
   typing "DOS4GW PROGRAM.EXE" (where "PROGRAM.EXE" is your program) will run
   any PMODE/W executable under DOS/4GW. This is an excellent way to still use
   DOS/4GW for debugging, and PMODE/W for the finished product.

Q: Can I still debug PMODE/W programs under the Watcom debugger?
A: Yes you can. You can debug your PMODE/W programs in exactly the same manner
   you would debug a DOS/4GW program (using the /TR=RSI switch of course).

Q: Why can't I get more than about 15 megs of extended memory under my VCPI
   server when there is more than that available in my system?
A: You must increase the maximum number of VCPI page tables PMODE/W will
   manage using the PMWSETUP program. Each page you add will give you another
   4 megs of memory (provided that it is physically available of course).

Q: How come PMODE/W takes a little while to load under EMM386?
A: PMODE/W allocates all of its extended memory pool during initialization
   whereas DOS/4GW allocates memory every time you (or the C libraries) call
   the DPMI memory allocation functions. The delay is caused by EMM386's
   slowness in allocating pages. PMODE/W may take a little longer than DOS/4GW
   at startup in this case, but it will be much faster during the execution
   of the program since it does not need to call EMM386 for memory again
   after that. If the delay is a problem, you can adjust the amount of
   extended memory to allocate in PMWSETUP. The less memory there is to
   allocate, the faster loading will be under EMM386. However, keep in mind
   your memory requirements when changing that setting.

Q: How come DOS/4GW, Pharlap, or other 32bit DOS applications don't work using
   spawn() under PMODE/W?
A: Some other DOS extenders require extended memory to initialize. Also, the
   program you are trying to run may require extended memory. To remedy this,
   you can change the maximum amount of extended memory to allocate using
   PMWSETUP. Set the value to something you feel meets the requirements of
   your program instead of the default (which allocates ALL memory). This will
   make sure that your program does not allocate any more memory than it
   needs, therefore leaving whatever memory is left over for the program you
   are trying to execute.