none
Running DOS applications requiring device drivers in CONFIG.NT that load DLLs from the search path RRS feed

  • Question

  • We are trying to get an older 16-bit DOS application running on Windows 8.
    - Yes, I know that it won't run on a 64-bit installation of the OS.
    - Yes, I know that Microsoft has been trying to kill off DOS applications for years.

    Anyway, the crux of the problem comes down to what appears to be a bug in the Windows Command prompt environment, confirmed through using Process Monitor to watch the startup sequence.  Here's a step-by-step description of the issue:

    1) When the application starts, it builds the 16-bit DOS environment and loads the drivers indicated in C:\Windows\System32\config.nt as directed.  This part works perfectly.
    2) One of the device drivers, called BTRDRVR.SYS is loaded from C:\Windows\System32.  This works fine.
    3) The driver calls a "helper DLL" (also located in C:\Windows\System32) called BTRVDD.DLL, which loads as expected.
    4) the helper DLL attempts to call another DLL located in the current path, called W3BTRV7.DLL.

    This is where it breaks.  In Windows 7 (and every earlier version back to Windows NT, I think), when the file W3BTRV7.DLL cannot be found in the System32 folder, the normal search path is eventually searched, and the file is located in its proper location (in this case, C:\Program Files\Pervasive Software\PSQL\bin).  Subsequent DLL's are also loaded from this location, and the entire component chain works perfectly.

    In Windows 8, things are not so nice.  When the system attempts to load W3BTRV7.DLL, it attempts to load it ONLY from the C:\Windows\System32 folder -- it does NOT search the path.  Copying this file to the System32 folder allows it to find the DLL -- but it then fails on the next downstream DLL (in this case, PSCORE3.DLL).  This continues for each downstream DLL.

    The solution is fairly simple:  Copy the ENTIRE set of related DLL's from their location, safely ensconced in the application's "Program Files" folder, back into the C:\WINDOWS\SYSTEM32 folder!  Argh!  We went through this very same DLL Hell with Windows 3.1, Windows 95, Windows 98 -- where developers started copying DLL's into the Windows folder because they didn't know any better.  Now that the developers know better, Windows 8 breaks the entire process yet again?

    I tried several other solutions, including forcing the system to load the device driver from the proper Program Files folder didn't work -- it still tried to load the helper from the System32 folder.

    Any ideas to fixing this, other than polluting the Windows folder with application DLL files?
    Tuesday, March 5, 2013 12:24 AM

All replies

  • have you tried DOSBox?

    http://www.dosbox.com/


    "A programmer is just a tool which converts caffeine into code"

    Tuesday, March 5, 2013 6:50 PM
  • Yes, and it does not help.  I don't need a "native DOS environment", but rather I need an "integrated MS DOS environment".  As the original post indicates, the DOS component being used includes a device driver that allows the DOS application to connect to the Windows 32-bit Client DLL's, which then allows it to connect to the rest of the networking environment, like shared drives, access rights, etc.  DOSBox seems to create a complete standalone environment that offers none of this connectivity, so it breaks the app completely. 
    Monday, March 11, 2013 1:45 PM
  • Run it in a Win9x/XP VM. Is this possible for your environment?

    "A programmer is just a tool which converts caffeine into code"

    Monday, March 11, 2013 8:02 PM