DOS/16M FAQ:
Compatibility

1. My DOS/16M program won't run in a Windows 95 DOS box. When I start the program, I get a popup in Win95 that says Windows needs DOS16M.DLL in order to run this program?
2. Why won't Windows 95/98 run my application -- it says it needs NELOAD.EXE?
3. Why won't Windows NT run my application -- it says it needs DOS16M.DLL?
4. Why won't Windows NT run my application -- it says it needs NELOAD.EXE?
5. How does a protected mode program that calls a real mode TSR provide access to the protected mode program's environment?
6. I'm running DOS/16M programs from a batch file. While some returns are not errors, General Protection Faults seems to mess things up. Does DOS/16M send back a return code to DOS that I can trap on?
7. I'm having a problem getting my program to run in an OS/2 Warp 3.0 DOS Box. I get DOS16M Error [16] : Cannot run under OS/2?
8. I recently installed Windows 95. Whenever I run the Instant-D debugger, single-stepping resumes execution as if GO had been invoked. Is the Instant-D debugger compatible with Windows 95?
9. Why am I getting error 32 (DPMI host error) when I try to run a DOS/16M program from within NMAKE?
10. How can I load and access a real mode DLL from a DOS/16M program?
11. Why can't I look at the ROM BIOS from my DOS/16M program with QEMM stealth mode active?
12. Do you know of any problems with INT 24h, which misbehaves in somewhat different ways under DOS, the Windows DOS box and the OS/2 DOS box?
13. I have a program built with your 32 bit extender that spawns a DOS/16M application. This arrangement works works fine, except in a Windows DOS box?
14. Is DOS/16M compatible with Linux DOS emulation?
15. Why does my DOS/16M program run perfectly on some machines and hang on others?

1. My DOS/16M program won't run in a Windows 95 DOS box. When I start the program, I get a popup in Win95 that says Windows needs DOS16M.DLL in order to run this program?

The error message is a bit misleading. There is no separate DOS16M.DLL file. Windows 95 and NT can run command-line programs in several different environments. Two of them are '16-bit Windows' and 'DOS'. Windows 3.x only runs command-line programs in the 'DOS' environment. Windows 95 and Windows NT are trying to be helpful by allowing you to start Windows applications from the command line. Windows 95 and NT look at the executable file that you name in the command line to decide which environment to use for the program. Since Microsoft is trying to be more helpful in later versions of Windows, what is actually happening is that the program is built as a SEGEXE-type (NE) executable which Windows 95/98/NT is trying to run as a '16-bit Windows' app, not a 'DOS' app. Because it is actually a DOS application, the '16-bit Windows' environment is missing pieces necessary to run the program.

To eliminate this problem, we provide users of DOS/16M with a utility called NTPATCH, which alters the 'NE' signature to something the Windows loader doesn't recognize as a '16-bit Windows' executable, so it doesn't run the file in a '16-bit Windows' environment -- rather, it runs the file in the 'DOS' environment, which then causes our loader to run and load the actual application. You should use NTPATCH on any DOS/16M SEGEXE you wish to run in a DOS box of either Windows 95 or Windows NT. To use NTPATCH:

    NTPATCH -T     to toggle the signature bytes

    NTPATCH -DX    set signature bytes to DX for NT or Win95 DOS box

    NTPATCH -NE    set signature bytes to NE for normal DOS

2. Why won't Windows 95/98 run my application -- it says it needs NELOAD.EXE?

See the answer above for Windows 95 and DOS16M.DLL.

3. Why won't Windows NT run my application -- it says it needs DOS16M.DLL?

See the answer above for Windows 95/98 and DOS16M.DLL.

4. Why won't Windows NT run my application -- it says it needs NELOAD.EXE?

See the answer above for Windows 95/98 and DOS16M.DLL.

5. How does a protected mode program that calls a real mode TSR provide access to the protected mode program's environment?

Get the real mode paragraph of the environment and put it into the PSP before you call the TSR. Don't forget to restore the protected mode environment selector immediately after you return to the protected mode program.

6. I'm running DOS/16M programs from a batch file. While some returns are not errors, General Protection Faults seems to mess things up. Does DOS/16M send back a return code to DOS that I can trap on?

Yes, DOS/16M returns FF on a General Protection Fault (if errorlevel FF goto errorlabel).

7. I'm having a problem getting my program to run in an OS/2 Warp 3.0 DOS Box. I get DOS16M Error [16] : Cannot run under OS/2?

Try increasing the DPMI_MEMORY_LIMIT and giving access to HW_TIMER.

8. I recently installed Windows 95. Whenever I run the Instant-D debugger, single-stepping resumes execution as if GO had been invoked. Is the Instant-D debugger compatible with Windows 95?

Contact us and request the Win 95 bug fix disk. This disk contains an Instant-D that works around a Windows 95 trap flag bug, and a version of our device file, DOS16M.386, that works around some differences in memory mapping between Windows 3.x and Windows 95.

9. Why am I getting error 32 (DPMI host error) when I try to run a DOS/16M program from within NMAKE?

The Visual C++ version of NMAKE is not compatible with any non-Microsoft DOS extender. Try the real mode version of NMAKE, NMAKER.

10. How can I load and access a real mode DLL from a DOS/16M program?

There are a couple of ways to do this: you can allocate a real-mode callback, then pass the callback in a spawn or exec of the real mode program; or install the real mode code as a TSR.

11. Why can't I look at the ROM BIOS from my DOS/16M program with QEMM stealth mode active?

Stealth mode is incompatible with looking at the ROM BIOS via a pointer; stealth mode maps out the BIOS to use that memory space.

12. Do you know of any problems with INT 24h, which misbehaves in somewhat different ways under DOS, the Windows DOS box and the OS/2 DOS box?

There are problems, but as best we can tell they are inside Windows. Windows seems to not let you switch back and forth between hooking INT 24h and not hooking it - Windows gets stuck in a state where it will stop sending them to you. Perhaps the thing to do is hook once and use a switch to determine whether to respond or chain, or perhaps always respond.

13. I have a program built with your 32 bit extender that spawns a DOS/16M application. This arrangement works works fine, except in a Windows DOS box?

You can't run 32 and 16 bit apps at the same time in a Windows DOS box. This is a limitation that Microsoft has deliberately inserted.

14. Is DOS/16M compatible with Linux DOS emulation?

Although we do not currently QA any of our products against the Linux DOSEMU package, and cannot promise that it will work, we have been following the DOSEMU development. It appears that most programs built with DOS/16M do, in fact run under Linux, particularly with versions of DOSEMU of .60 or later.

Several different programs built with DOS/16M, are on the 'success' list of DOSEMU.

It appears that DOSEMU provides a good DPMI host, and that's all DOS/16M needs to work successfully.

There may be other DOS and/or BIOS and/or hardware features that are not supported under DOSEMU, so your application may not work without modification, but DOS/16M itself seems to work very well. .

15. Why does my DOS/16M program run perfectly on some machines and hang on others?

It can be difficult to determine the cause of a system hang, because the system freezes before you can get any real information about the problem. A system hang often indicates a problem in real mode code, or that DOS has been corrupted somehow.

If the program runs on other machines, compare the configuration of the two machines to find the source of the problem. Pay particular attention to make sure that any drivers required by the program are properly loaded. For example: if DOS/16M attempts to handle mouse interrupts without a mouse driver having been loaded, the results may vary from a General Protection Fault to a system hang -- depending on the condition of the system at the time the interrupts were generated.