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.
This page was last updated 01 February 2010