Protel dos and NTVDM

PROTEL Autotrax/Easytrax and NTVDM

The information provided here is courtesy of Mark van der Eynden

There seem to be a number of problems being experienced by people trying to run Easytrax and Autotrax under windows XP, and it seems that the root cause of the problem is actually quite simple - the path statement is getting too long for the combination of windows NTVDM and legacy DOS programs to handle.

The issues we describe here are specifically in relation to easytrax/autotrax and XP, but my suspicion is they probably apply (atleast in part) to other programs and platforms as well.

Further:
If running Autotrax and schmatic at the same time, note that they each want a seperate copy of the video driver. The easiest way to do this is to have one copy each named "Graph.drv" in the respective executables directory (eg c:\autotrax and c:\schmatic)

If you want to stop reading here, just write a batch file to run your Autotrax/ Easytrax program with the line "Path C:\autotrax" (or other directory, for instance c:\graphdrv, as required) prior to executing the trax program. Otherwise, read on, use the tool provided to prove the problem, and edit the path manually.

Programs referenced:
Tool to test path length
Source code for path length test tool

Mark van der Eynden writes:
"From posts here and elsewhere it is apparent that some of you are having trouble running Easytrax under windows XP.

Symptoms include:-
Spontaneous exits (or darn thing just won't start)
NTVDM messages about invalid instructions
General lockup
(sometimes) other totally erroneous behaviour

From searching the Internet it appears that Easytrax is not the only 16 bit, real mode, program that has these problems and I suspect all have the same cause.

Having the same problem myself, and considering myself to be capable of getting to the source of the problem I have spent a somewhat intense couple of days debugging the issue and now believe it is solved. I will attempt to write up the full exercise for a 'Serviceman' article in SC, however, I will not go into full details here.

Suffice to say, the problem is caused by the 'Path' in the system environment variables, combined with NTVDM's translation of this for use by 16 bit programs.

NTVDM translates the path into short 8.3 filenames as much as it can, however, if it finds an error, or a path that does not exist, it just copies the text until the next semi-colon into the 16 bit path.

Thus
C:\program files\common files
(probably) becomes C:\progra~1\common~1

Whereas
C:\program files\an invalid directory
Becomes c:\progra~1\an invalid directory

NTVDM does not report this error (MSDOS never reported errors in path either, if you were lucky your program did, or at least ignored the errors).

NTVDM also does not report Paths longer than the MSDOS limit (127 bytes), or individual directory paths that are longer than the MSDOS limit (66 bytes give or take a byte as tested in MDSOS 5).

It is the combination of the translation and the 66 byte limit that is breaking Easytrax, however in Easytrax's case the limit is 56 bytes (who would ever come close to this in the MSDOS days?).

The error causes stack corruption in Easytrax that causes a wild branch that results in errors as described above.

I have already documented the easy solution. I have also written a program to identify the existence of the problem that I have emailed to Steve Murray so that he can put it on his website - (See the "tools" link above)

In my specific case I had in my XP path a directory called:

C:\WINDOWS\System32\WbemC:\Program Files\Common Files\Borland Shared\BDE

which was stuffing up Easytrax.

Adding the semicolon in the correct place enabled Easytrax to work. I did not enter this myself, so some install program did the stuff up, I didn't even know where I could change the XP path, so I guess I'd better let you all know....

In Control Panel double click on
System click on
advanced then
Environment Variables
The first User Variables path is appended to the System Variables path to arrive at the path in the MSDOS box.

The NTVDM ('Virtual DOS Manager') does a pretty good job of enabling all 'well behaved' 16 bit programs to work under XP. See
http://support.microsoft.com/default.aspx?scid=kb;en-us;314106 half way down the article.

If you cannot get the VESA display drives to work you probably have
a display that does not support VESA, or
a BIOS that does not support VESA.

The NTVDM detects the VESA call, puts the display into 'full screen' mode and passes the call to the BIOS, what could be simpler? A tool is available to check the VESA modes to further isolate such problems.