WPF program crashes when started from within a 16-bit DOS program

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!

WinMed Connect preferences & setup

Situation: A client computer that were running the WinMed healthcare software application had been replaced and an attempt had been made to transfer the software to the new computer. The WinMed program and data files all reside on a server network share with no values stored in registry, so apparently recreating the shortcuts to the server located apps on the new computer should do the trick.

Problem: The WinMed Connect program was asking for path specifications every time it was run.

Solution: The WinMed Connect shortcut points to a program called xmlparse.exe in the xml subfolder of the WinMed system files. There was also a xmlparse.ini file in this folder. This needed to be copied to the Windows folder and modified with the right paths. Also the winmed.ini file located in the WinMed folder on the server had to be copied to the local Windows folder. Both files had to be given change permissions to the user who was running the program.