Is PMODE/W 100% compatible with DOS/4GW?

PMODE/W is compatible with nearly all 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.

Why doesn't my PMODE/W program work with DOS/4GW?

You can not run a compressed PMODE/W program with DOS/4GW. The program may be using a DPMI function which PMODE/W supports but DOS/4GW does not. You may also be using 16 bit code directly instead of allocating DOS memory, copying the code, and using it. PMODE/W always loads 16 bit real mode code into low memory, thus enabling you to use it directly. DOS/4GW loads all code into extended memory, where you can not use real mode code.

Why doesn't my DOS/4GW program work with PMODE/W?

Almost any program that works with DOS/4GW will run correctly with PMODE/W as long as it does not use any DOS/4GW specific functions. If a program does not work at first, you may have to tweak the PMODE/W system variables using PMWSETUP. For example, you may try setting the maximum low memory to reserve to 0FFFFh to force PMODE/W to load all 32 bit code and data into extended memory like DOS/4GW (16 bit code will still be loaded into low memory). You may also try increasing the number and/or nesting of the protected and real mode stacks.

What does not having an exception handler do to my program?
NOTE: PMODE 1.30 includes exception handling, this question only applies to earlier versions of PMODE/W.

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 uncompressed 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.

Can I still debug PMODE/W programs under the Watcom debugger?

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). You cannot, however, debug programs which have been compressed using PMWLITE. You also cannot debug PMODE/W programs that do not run under DOS/4GW.

Why can't I access more than 16 megs of memory under my VCPI server when there is more than that available in my system?

You must increase the maximum number of VCPI page tables PMODE/W will manage using the PMWSETUP program. Each page table you add will give you another 4 megs of memory (provided that it is physically available of course).

Why can't I map more than 4 megs of address space of a physical device using DPMI function 0800h?

You must increase the maximum number of physical address mapping pages in PMODE/W using PMWSETUP.

How come PMODE/W takes a little while to load under EMM386?

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.

How come DOS/4GW, Pharlap, or other 32bit DOS applications don't work using spawn() under PMODE/W?

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 for PMODE/W 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.

If you have a question that was not answered here, please drop a note to Charles Scheffold at daredevi@dorsai.org

PMODE/W is Copyrighted (C) 1996 by Charles Scheffold & Thomas Pytel
Web site by Ryan Cramer