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