Devide by Zero. 1

[TiteLoop]

Hello,

This question is less about XP and more about Windows.

I am trying to get Autocad 12 to run on a newer computer. It installs just fine but when you go to run it you get an [purple]Divide by zero or overflow error![/purple]

It runs fine on an old computer under Windows 98.

In looking everywhere the general consensus seems to be "it is because the computer is running too fast". I could more easily understand that it is because we've gone to non 8087 math co-processors, or operating system changes, but speed?!?!

I am trying to understand why/how code could be written that would allow an answer that came back more quickly from math hardware to cause this problem. I could image the opposite, an answer that came back too slowly, but too fast?

Anybody know the reason or could illuminate how speed would play in this?

 

[Freestone]

Almost all code that causes the Divide By Zero error on faster machines is due to the use of software timing loops rather than the use of hardware based timing. These loops were almost always used to introduce a delay in processing so something else in hardware could finish. Since new PCs are now vastly faster than the platform the code was originally written for, these software timing loops are running that much quicker. Consequently code following the loop is executed sooner than what was intended, and erroneous values are being obtained from the hardware and used by the program.

 

[linney]

This does not refer to your application, but does support the "too fast" scenario.


Error: Divide by Zero

When Foxpro for Windows is launched, a timing loop is executed. On fast computers (Pentium 333Mhz+ machines), the timing count can become huge, resulting in a 'divide by zero' error. Thus preventing you from running FPW. Microsoft offers a utility to patch Foxpro 2.6a for Windows and it's asssociated runtime. Called PATCH_26.EXE, you can find it on the Microsoft download site,

http://www.microsoft.com/downloads/search.asp.

Search in the "Foxpro 2.6 for Windows" area for "Fix for Divide by Zero on Fast Computers".

PATCH: Patch_26.exe Fixes Divide by Zero Error on Fast Computers

http://support.microsoft.com/kb/240982/en-us?FR=1&PA=1&SD=HSCH

These might be more helpful to you?

http://www.google.com/search?source...2005-48,GGLG:en&q="Divide+by+Zero"+Autocad+12

http://groups.google.com/groups?q="Divide+by+Zero"+Autocad+12&start=0&scoring=d&ie=UTF-8&

 

[Frank4d]

Have a look here:

http://discussion.autodesk.com/thread.jspa?threadID=457826

 

[TiteLoop]

Thanks for your help guys! I have got it licked!! BOOYAH!!

Essentially all apps written using a particular form of Pascal had this problem. The error is actually an overflow rather than a divide by zero. What happens is the software tries to take the measure of the system so it can adjust the functional speed of the product to keep it looking approximately the same on different speed systems. On computers over a certain speed the hardware timer used over-flows because of the high instruction speed of the faster processor. Sadly this feature probably wasn't even used in most products but the test was automatically done.

The Foxpro problem was remedied by actually hacking/patching that bit of code. That means that fix won't work on other things in-fact not even on some versions of Foxpro.

I found my way to Mo'Slo:

http://www.hpaa.com/moslo/

This guy makes a tiny tight app that allows you to change the comps speed. It has a huge range from 0.01% up to 99%.

This did the trick on any computer I tried it on!

Furthermore it only slows the computer for individual apps that you run under Mo'slo. Also you can have it stop slowing the app after a set time. So now Acad 12 really rips after the 5sec slow period needed to hurtle the speed test.

Thanks for your links they helped me draw out the solution.

 

[Glenn9999]

To be more specific, the Pascal CRT unit had a timing loop in it for various purposes. Any software that used direct video writes under DOS used the CRT unit and therefore these timing functions. Not ALL old Pascal apps, but ones that used the CRT unit.

If you want to try it, if you can verify the executable is a Pascal one (as opposed to other compilers), you can try applying some of the various execution-time fixes for this problem that were produced.

 

[TiteLoop]

Thanks for those details Glen as it makes even more sense now. That era ACAD was heavy into unique video drivers and later versions flipped to using native Windoz stuff.