Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

EMS memory and XP - DependancyWalker+DrWatson (Users)

posted by Arjay, 24.03.2013, 10:08

> OK, opening NTVDM.EXE in Dependency Walker shows, apparently, 2 files
> missing. I have the message "Error opening file.
> system cannot find the file specified" for each of IESHIMS.DLL and WER.DLL.
Ok, both should be "optional" Internet Explorer related files. Yes, this is DOS related but there are IE links all over the place. You should be able to live happily without both of them, e.g. IESHIMS.DLL was missing on a machine I quickly tested this on myself before then suggesting you gave it a try to see if it threw up anything. DependancyWalker is a very well written easy to use tool to fire up in situations when all else has failed.

> Below them is file MPR.DLL with an hourglass icon and a shaded red square.
The MPR.DLL warning shouldn't be a problem as per Dependency Walker FAQ.

> Does this help?
Yes, in eliminating likely causes. I am pretty sure that based on everything you've written and the tests we've done that the problem you have is now entirely now with 16-bit app console handling with the likes of CMD.EXE breaking at the point that they are handing over 16-bit app handling to NTVDM and it's components. What DependancyWalker has just told us is the files that NTVDM's requires are pretty much present. That doesn't mean the right versions are present or that they've not been damaged in some way. We can forget IESHIMS.DLL as it's optional. Off the top of my head I'm pretty sure WER.DLL is as well but it might not be a bad thing to replace that.

FYI, due to the way DLL error handling works and the fact that often programmers are lazy.... It is possible for an application to report DLL 1 as missing when DLL 1 is present and DLL 1 is reporting that a DLL it requires ( DLL 2 ) as missing. So you end up with the weird situation where people are going but DLL 1 is present... when what is missing is DLL 2.
It is possible to obviously resolve those kind of complex problems by hand (I have) but Dependancy Walker does a good job of cutting out a lot of the pain.

So believe it or not this could even be a weird situation that say because WPR.DLL is missing that this is then reported back to another DLL used by NTVDM which in turn is reported back to the Win32 side which for whatever reasons doesn't now know how to handle that situation due to the update....
...You can have hours of fun with missing DLL's - many are not required tho!

Still I doubt the weird situation described is the cause, but you never know. DOSBox (as someone elese has suggested) should give you an immediate workaround fix since it has it's own 16-bit virtual machine independant of NTVDM's. What Japheth has suggested regarding running a debugger might be worthwhile since the NTVDM does feedback messages to a kernel level debugger. Before jumping in with a heavy weight one, have you tried running Dr Watson then seeing what happens?

In the meantime I've got other things to do but will give this some more thought and ways that we can quickly narrow this down/hopefully get it fixed.

 

Complete thread:

Back to the forum
Board view  Mix view
22762 Postings in 2122 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum