tungsim
asked on
error "Division by zero"
Declaring unit CRT("uses CRT;") cause my program error "Division by zero" when running.(not in compling)
declare other units don't cause that error.
Thanks.
declare other units don't cause that error.
Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Right Omsec, that is what I mean.. Thanks..
Motaz.
Motaz.
My friend also get the same problem with you, but he don't used pentium II processor only about Pentium 200 MMX the oldest one? How about that? he used Windows 98 as his operating system. is that a problem in Windows 98?
During initialization phase of the program, CRT unit tries to evaluate a time-base in order to have a proper delay value to deal with Delay() procedure. That is accomplished by counting hoy many times an integer value is increased during one millisecond of time.
In faster processors, since approximately 300 MHz os more, that gives as a result a value greater than 65535, which is greater enough to cause on overflow condition, which is interpreted as a "Division by zero" by initializing routine, thus avoiding the program to run.
The (partial) solution) I've found is to patch the object code of the CRT unit in order to modify this instruction:
DIV CX,37h ; Divide by 55 (dec.), the quantity of
; times the system clock interrupts, at
; 1/18 of a second
by this one:
DIV CX,226h ; Divide by 550 (dec.)
That avoids the overflow; but the subtle effect is that the so-obtained base-time is 10 times smaller. Thus, every time the Delay() procedure is used, it's argument must be 10 times greater to achieve the same results, i.e.:
Delay(x);
must be changed by
Delay(x*10);
For a softwre developer, it's not so terrible. There's another solution, in which the program itself (using the patched CRT unit) can disregard the use of CRT's Delay() procedure, but programmer has to write its own code to get the right time-base (I've done it) the get the same results without having to multiply by 10 the argument.
In faster processors, since approximately 300 MHz os more, that gives as a result a value greater than 65535, which is greater enough to cause on overflow condition, which is interpreted as a "Division by zero" by initializing routine, thus avoiding the program to run.
The (partial) solution) I've found is to patch the object code of the CRT unit in order to modify this instruction:
DIV CX,37h ; Divide by 55 (dec.), the quantity of
; times the system clock interrupts, at
; 1/18 of a second
by this one:
DIV CX,226h ; Divide by 550 (dec.)
That avoids the overflow; but the subtle effect is that the so-obtained base-time is 10 times smaller. Thus, every time the Delay() procedure is used, it's argument must be 10 times greater to achieve the same results, i.e.:
Delay(x);
must be changed by
Delay(x*10);
For a softwre developer, it's not so terrible. There's another solution, in which the program itself (using the patched CRT unit) can disregard the use of CRT's Delay() procedure, but programmer has to write its own code to get the right time-base (I've done it) the get the same results without having to multiply by 10 the argument.
Motaz from Sudan.
motaz1@yahoo.com