Betreff: runtime error 200
Datum: Fri, 11 Sep 1998 10:58:41 -0700
Von: Werner Teichert
Foren: comp.lang.pascal.borland
Here is some information on how to manually generate a crt.tpu file
excactly as it is in the turbo.tpl file.
Using BP 7.0 the well known runtime error 200 occurs when the crt unit
is included and the compiled program is started on a fast pc.
There are good solutions for this problems, mainly in modifying the
crt.asm file in the included runtime library of the bonus disk.
At first my task was to prove that the original crt.tpu file is the same
as the file that will be generated using the sources in the rtl.
So, before modifying the crt.asm I tried to genereate the same crt unit
that is included in the turbo.tpl file. Using TPUMOVER I extracted the
original crt unit by entering TPUMOVER TURBO.TPL *crt. I kept this file
in a special directory to compare it to the one I would generate.
Then I assembled the file crt.asm using tasm 3.2. Next was to compile
crt.pas with the Pascal compiler. At first there were many differences
including different file length.
I changed all compiler options to OFF except WORD ALIGN to ON and
compiled again. This time only four bytes were different. Klaus Hartnegg
gave me the idea that these four bytes could be the date and time of the
pascal source . Spending a few time to compare I found the solution.
These four bytes really include time incl. seconds and date of the
pascal source.
So I changed the date and time of the crt.pas file to AUG - 8 - 1992
17:00:26 and recompiled it. The result was that the file I generated did
not differ from the original crt.tpu within the turbo.tpl file.
I hope this would help someone.
---------------------------------------------------------------
Betreff: Re: yet another runtime error 200 prob...
Datum: 11 Oct 1998 22:01:49 GMT
Von: "Frank Peelo"
Firma: Indigo
Foren: comp.lang.pascal.borland
Pedt Scragg wrote in article
<5AviLEAeqCI2Yw+B@pedt.demon.co.uk>...
> In comp.lang.pascal.borland, Jamie Rosner uttered:
> >I am running Borland's turbo pascal 7.0 on a pII 300Mhz, Win98.
> >I've tried all of the patches (newdelay, tpbug, Fdelay, etc.)
> >Still I get that BLEEDING ERROR!
> >The programs work normally unless i try to read in a dat file, and then
it's
> >200....200....200....200.....Arrrggghhh!
> >the error occurs at 099B:0091
>
> It *cannot* be the delay calibration bug as your program is getting past
> this point. Therefore there is an error in your code leading to "divide
> by zero"
If that is true, then the error address is a strange coincidence, 0091
being the address that would be expected for the delay calibration bug. Can
the question be reinterpreted to allow that bug?
"unless i try to read in a dat file" - I assume that means reading a data
file, using Reset etc. (long shot/wild guess: if it means shelling to a
program that reads a file, maybe that program would have the bug?)
Could there be multiple TURBO.TPLs available to the machine? I'm wondering
about a scenario something like this: copy TURBO.TPL into a temp directory
and patch it. Write a small test program to see if the patch works. It
does. Go back to the directory where the program which reads the data file
and recompile, try to run _that_ program, and of course you "Still get that
BLEEDING ERROR!", because the patched TURBO.TPL, being in the temp
directory, is not the one being read by the compiler. Or you copy TURBO.TPL
back to the directory where TURBO.EXE or BP.EXE is but you have _another_
one in the directory you would be working from. Could that be the problem?
FP
(
geocities.com/siliconvalley/2926) (
geocities.com/siliconvalley)