Scenario: I am programming a Windows application in VB.NET using Windows Presentation Foundation. My program is going to be started from within another old-style 16-bit program, hence this starter program runs in NTVDM (NT Virtual Dos Machine - the way Windows creates backwards compatibility with Windows 3.x/MS-DOS programs). Yes, they are actually still being used out there - the app I am programming is a helper app for the medical journal system WinMed.
Problem: Starting my app by double-clicking its EXE file is no problem, neither is starting it from a command prompt - from a cmd.exe command prompt, that is. But starting the program from within the 16-bit WinMed (it has a customizable menu for starting external programs) or from a command.com (=16-bit) command prompt, immediately results in a crash simply stating: "A problem caused the program to stop working correctly. Please close the program". Why it stopped working is kept a secret.
Cause: I had a strong hunch that NTVDM has something to do with it, since starting my app from both command.com and from within the WinMed program fails. Then I found this post: The environment variable WINDIR is missing from the NTVDM environment. This can be easily checked by running a command.com window and type the set command - all environment variables are then listed. I found that no WINDIR setting was present in this list of environment variables.
Solution: To run the program from the command.com command prompt, I had to first run the following command:
set windir=c:\windows
Now I was able to start the program from within command.com. To ensure that the environment variable was always set when running NTVDM programs, I edited the c:\windows\system32\autoexec.nt file by adding the above command to the end of it - making sure I had no spaces before or after the equal sign. Now my app starts even from within WinMed!
1 comment:
We are in progress of converting an old legasy system using 16-bit Windows forms to WPF apps. I have spent couple of days investigating a problem when starting a WPF app from 16-bit app causes the WPF app to crash. I discover that the a windir environment variable is not inherited in WinExec call and now found a fix.
Thank you for your post. You saved my day!
Post a Comment