DOS program won't run in 98--it does in 95

[jepeters]

Our school has an OLD grading and report card program that we have been running on a Windows 95 machine. The program is 100% DOS, I just have a shortcut to the DOS batch file on the Windows 95 desktop and get to the program from there.

We are replacing this Win95 machine with a Win98. I copied the entire grade program folder (and the shortcut) to the server, then copied it back to the Win98 machine. But whenever I try to run the program, I get a 'Division by 0' error in the DOS window.

I've tried copying this folder to several Win98 machines and get the same error on each one. Then I copied it to another machine with Win95 and it worked perfectly.

Is there something else I must do in Win98 to run a DOS program?

(don't suggest that we buy a Windows program--the good ones are way too expensive for a small rural school)

[jepeters]

I started up the computer with a DOS floppy, then tried to run the program. It looked like it might work, but then it gave an error number and said 'Conventional Memory Exhausted'.

Is this a problem with Extended or expanded memory? I really doubt that the program uses it. It's been a long time since I ever dealt with a PIF file. Could it be that I need to make some settings in such a file? I did check all the properies of the shortcut icon to the batch file and made sure that they matched (as far as I could tell) between the Win95 and Win98 versions of the shortcuts.

[cunnings]

Can you reinstall the program from scratch on the win98 machine? You are probably missing drivers, ini files, etc. that may be in windows directories and not in the program directory.

When booting from floppy you probably need to put himem.sys and some of the other memory management programs in your autoexec and config.sys files.

[glc]

Drivers and ini files are a nonissue with a 100% DOS program.

You are running out of conventional memory - 98's DOS has a larger footprint than 95's. Try the following lines in the config.sys on the 98 machine:

device=c:\windows\himem.sys
device=c:\windows\emm386.exe noems
dos=high,umb

If there are any device= lines in config.sys, change them to devicehigh=

If there are any drivers loading in autoexec.bat, put a LOADHIGH in front of it.

[jepeters]

well, that got me past the 'out of conventional memory' error, but brought me right back to the 'divide by 0' error.

I'll try installing the program from the floppy disks (once I find them) and see if a new installation on a Win98 machine will start up.

thanks for the help

[onyx]

Is the Win98 machine the same hardware as the Win95? We run a lot of old 16-bit apps written in Clipper, and I have seen that "divide by 0" error frequently when we install them on machines with faster processors.

[jepeters]

onyx

the win98 machines are 466 mhz or higher. The original Win95 machine is 166 mhz, but I also got it to work on a 233 Mhz win95 machine.

Have you found a 'fix' for the problem in your case?

[glc]

You can try CPU Killer to test this theory -

http://members.xoom.com/robyrobo/cpukiller/cpukil20.zip

[Felix]

Have a look to your DOS bootdisk: Does it have any handling for extended memory in it? I guess no. -> Look in config.sys for lines such as
device=c:\windows\himem.sys
DOS=HIGH,UMB

I suggest you to copy himem.sys and emm386.exe from c:\windows to the bootdisk and then make the config.sys reading this:

device=himem.sys /testmem: off
device=emm386.exe noems
dos=high,umb

Give it a try. Good luck!

[jepeters]

Felix

The second DOS disk that i tried had those lines in it, except for the 'testmem off' part. I'll put that in and see what happens.

[Felix]

"testmem: off" just makes booting a little faster, nothing that would make your program run better.

[Felix]

BTW it can be that your new machine is just too fast for the old DOS program. The "division by zero" error does suggest this...

We have a test bench program that doesn't run on any machine faster than a 386 (sic!) and thus we run now in very troubles when the old 286 and 386 styled hardware breakes. We are in rewriting the software totally under windows, but it still needs some further time.

In that case, your best bet is to keep the old P133 to run your DOS program. If space on the desk is an issue, get a KVM switch, but take care of its maximum resolution and refersh rate. If this is a good (high) value, they are pretty useful.

[jepeters]

GLC

when i tried to go to the page with the CPU Killer, it said I did not have access to it. How do I get it?

[onyx]

jepeters,

Yes, I did find a fix for it, BUT I am not savvy enough to know exactly why the fix works, and we use strictly NT (which uses a DOS emulation instead of real DOS), so I don't know if a similar fix would work on your system. One of these other people who is more knowledgeable could probably tell you.

What I did was to play around with the "buffers= " line in config.nt (on your system would be config.sys). The faster the processor was, the more I had to increase the buffers. It didn't completely solve the problem, but I did some elementary testing: Before I increased the buffers, we got the "divide by 0" error 34 tries out of 35; after, 3 tries out of 35. But this was on an 800Mhz processor. On a slower one, it might have been better results.

[LawyerRon]

I could be totally out in left field on this one but I had an old DOS program that would'nt run under the newer DOS version in WIN 95. So I used "setver" in dos to emmulate an "older" version of dos and the program worked fine. I don't know if that's even possible anymore under WIN 98.

[glc]

JEP - You have mail. If your server rejects the attachment, let me know and I can put it on my FTP for you.

[jepeters]

got it. thanks

[jepeters]

CPU Killer did the job! Just had to reduce the speed by only 2% and everything works fine. Thanks