VOGONS

Common searches


First post, by captain_koloth

User metadata
Rank Newbie
Rank
Newbie

I'm trying to install an ancient, extremely obscure game (Anesthesia Simulator Consultant 2... not really a game, more of a sim for medical training) which I used to run on Win 95. I still have my original Win 95 PC on which I used to run it and it works, but I don't think that machine has long to live so I'm trying to install the software on a newer PC.

The manual says it works on Win 3.1 and I have the original floppies so I installed it in DOSBox. However, while I can get it to run, I get an error pretty quickly saying that MFC250.DLL has caused a general protection fault at 0012: 2382. I tried a Win 95 PCEm machine and got a very similar error. I tried placing a new copy of MFC250.dll on both of the virtual machines without luck, and then I even copied the mfc250.dll directly from my real Win 95 machine via a floppy and tried using that version, but I keep getting the error.

I suspect the combination of the program and error is so obscure as to defy solution by humans, but I thought I'd give it a try... any ideas?

Reply 1 of 11, by akula65

User metadata
Rank Oldbie
Rank
Oldbie

Is it possible that the application requires something like Win32s or WinG which is installed on your Win95 machine, but not in your virtual environments?

Reply 2 of 11, by captain_koloth

User metadata
Rank Newbie
Rank
Newbie
akula65 wrote on 2020-05-20, 21:59:

Is it possible that the application requires something like Win32s or WinG which is installed on your Win95 machine, but not in your virtual environments?

Maybe. Any way to tell? Any common dlls I could try?

Reply 3 of 11, by spiroyster

User metadata
Rank Oldbie
Rank
Oldbie

MFC250.dll sounds like it could be Microsoft Foundation Classes v2.5 runtime.. or part of it. Run dependancy walker on your program exe (https://www.dependencywalker.com/) to see which other dll's your program requires. Having the dll locally (same dir as program exe) might not be enough, it would need to be registered as it may depend on other runtime dll's and would go via the registry to find them.

Reply 4 of 11, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

I might also suggest using Filemon from https://sysinternals.d4rk4.ru/Utilities/Filemon.html on your Win95 machine. With luck, you can track exactly which files the program is trying to access, and then put the files in the appropriate locations in your PCem machine. (Filemon is a little tricky to use; you will probably have to set up filters to exclude Explorer background processes.)

Other thoughts:
How much RAM do you have in your old Windows machine? Do you have a similar amount in your emulated PCem machine? How about hard drive space?
Is the clock on your old Windows machine up-to-date, or set to some time in the distant past?
Is your old Windows machine using any unusual locale settings?
Are you running the program on your PCem machine at a similar resolution to what you were using on your old machine?

Reply 5 of 11, by akula65

User metadata
Rank Oldbie
Rank
Oldbie

Ugh, something else just occurred to me. If you are using floppies, you might consider the possibility that you have data corruption in one or more locations on the floppies themselves. It might pay to do some kind of checksum (MD5, SHAxxx, etc.) for all of the application's files on both your old Win95 machine and your virtual environments and see if there is a discrepancy.

Reply 6 of 11, by captain_koloth

User metadata
Rank Newbie
Rank
Newbie

Ugh... this just doesn't seem meant to be. I tried:

Dependency Walker, but it doesn't do 16-bit exe's
Scanbin, which seems to be sort of a 16-bit version of Dependency Walker but I couldn't get it to install on 3.1 or 95
Filemon, but I couldn't get THAT to work on real or virtual 95
Tried a box of NOS floppies to recopy the files
Same RAM and HDD on real and virtual Win 95 machines
Clock on Win 95 machine is set to the stone age but didn't affect the virtual machine
Same resolution

I'm about on the verge of giving up. Any other ideas? I assume posting my directory structure with the exe for others to try is not kosher.

Reply 7 of 11, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
captain_koloth wrote on 2020-05-21, 03:46:

Filemon, but I couldn't get THAT to work on real or virtual 95

Well, what happened when you tried it? Did you download the right version?

Are the locales the same? I ran into a program once that crashed mysteriously because it expected Windows to provide the date and time in a particular format that wasn't the typical North American standard.

I'm about on the verge of giving up. Any other ideas?

If all else fails, you can try copying the entire contents of the old hard drive to a new HD image and booting that in PCem. The Windows 95 installation will almost certainly complain vehemently about being run on completely different hardware, but at least then you might be able to rule some things out.

Another possibility is to try running the program through a debugger, but I'm not sure what debugger options are available for 16-bit programs.

You might also want to check if mkcompat.exe has been used on the executable in your old Windows 95 machine.

I also agree that verifying the checksums is a good idea. The quick way of doing that is to zip up the files on your WIndows 95 machine with an archiver that can display the CRC32 of files within the archive. Then do the same thing with the files in your PCem installation of the program and quickly check that the CRC32 values match.

Reply 8 of 11, by captain_koloth

User metadata
Rank Newbie
Rank
Newbie

I FIGURED IT OUT. I FIGURED IT THE F*&# OUT!!!

I took another look at filemon and found that the download of it i was using was missing the critical file filevxd.vxd. I got a copy of this and ran it on the virtual Win 95 machine. This indicated that the program was trying and failing to call a file called ANESPIN.VBX. I went and copied this file from the system folder on the real Win 95 machine, then actually tried copying it to the DOSBOX/3.1 machine (I find it easier to use DOSBox than PCEm if I need to transfer files since I can mount folders directly) and... VICTORY! ! The sweet smell of success. Thanks all for recommending Filemon, I would never have known about it or thought to look for such an application.

So for the thousands of other people out there who are doubtless trying to install ASC 2.0 in virtual machines tonight, I offer you the solution- find ANESPIN.VBX! 😁

Reply 9 of 11, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

Cool. It's satisfying to solve a problem like that. I wonder why ANESPIN.VBX wasn't properly copied from the floppies by the installation program?

Did you get Filemon from that link I posted before? The official Sysinternals website stopped offering legacy Filemon years ago, so that was the first promising site I found on Google.

Reply 10 of 11, by captain_koloth

User metadata
Rank Newbie
Rank
Newbie
Jorpho wrote on 2020-05-21, 05:01:

Cool. It's satisfying to solve a problem like that. I wonder why ANESPIN.VBX wasn't properly copied from the floppies by the installation program?

Did you get Filemon from that link I posted before? The official Sysinternals website stopped offering legacy Filemon years ago, so that was the first promising site I found on Google.

An excellent question. I was wondering the same thing.

And yes, it is indeed immensely satisfying. I guess that's why we all come to a place like Vogons in the first place...

I did but that archive actually wasn't complete- I had to get a version from github which had the other libraries I needed for filemon to work.

Reply 11 of 11, by collector

User metadata
Rank l33t
Rank
l33t

Since you got it working this may be of no use, but someone else may need it. The copy of Scanbin I grabbed from the author's site seems to be corrupted. I found it on https://www.sac.sk/files.php?d=17&l=S and that one works.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers