Free Pascal Error 200
Contents |
errors and gives information on why they might be produced. 1 Invalid function number An invalid operating system call was attempted. 2 File not found Reported when trying to erase, rename or open a non-existent file. 3 Path not found Reported by the directory handling routines when a path does not pascal exit code 201 exist or is invalid. Also reported when trying to access a non-existent file. 4 Too many
Runtime Error 2 Pascal
open files The maximum number of files currently opened by your process has been reached. Certain operating systems limit the number of files which
Pascal Error Codes
can be opened concurrently, and this error can occur when this limit has been reached. 5 File access denied Permission to access the file is denied. This error might be caused by one of several reasons: Trying to open for
Runtime Error 106 Pascal
writing a file which is read-only, or which is actually a directory. File is currently locked or used by another process. Trying to create a new file, or directory while a file or directory of the same name already exists. Trying to read from a file which was opened in write-only mode. Trying to write from a file which was opened in read-only mode. Trying to remove a directory or file while it is not possible. No permission to access the pascal runtime error 216 file or directory. 6 Invalid file handle If this happens, the file variable you are using is trashed; it indicates that your memory is corrupted. 12 Invalid file access code Reported when a reset or rewrite is called with an invalid FileMode value. 15 Invalid drive number The number given to the Getdir or ChDir function specifies a non-existent disk. 16 Cannot remove current directory Reported when trying to remove the currently active directory. 17 Cannot rename across drives You cannot rename a file such that it would end up on another disk or partition. 100 Disk read error An error occurred when reading from disk. Typically happens when you try to read past the end of a file. 101 Disk write error Reported when the disk is full, and you're trying to write to it. 102 File not assigned This is reported by Reset, Rewrite, Append, Rename and Erase, if you call them with an unassigned file as a parameter. 103 File not open Reported by the following functions : Close, Read, Write, Seek, EOf, FilePos, FileSize, Flush, BlockRead, and BlockWrite if the file is not open. 104 File not open for input Reported by Read, BlockRead, Eof, Eoln, SeekEof or SeekEoln if the file is not opened with Reset. 105 File not open for output Reported by write if a text file isn't opened with Rewrite. 106 Invalid numeric format Reported when a non-numeric value is read from
CRT.ASM unit included with these compilers. DOS based programs that were compiled using these buggy versions of the CRT unit will generate the RTE200 error when started on a CPU pascal exit code 106 that is faster then 200 Mhz (though some non-Intel CPU's would avoid the error up runtime error 103 pascal to 350 Mhz). One solution is to recompile the source code using a later version of Pascal, or a fixed CRT.ASM unit. Obviously that's types of errors in pascal programming only possible if you have the source code available. The more common solution is to patch the .EXE file to disable the bug. There are several programs that allow this. The one I recommend is PatchCRT by Kennedy Software. http://www.freepascal.org/docs-html/user/userap4.html This one is more compatible then most others, including TPPatch (which is less effecent, and uses German results and error text). I'd suggest keeping PatchCRT.exe in your path, so that you can run it from any directory simply by typing it followed by the name of the .EXE to be patched. PatchCRT will only be able to patch .EXE files which have not been compressed by an EXE compressor, such as aPACK, Diet, LZEXE, PKLite, Petite, UPX, etc. If http://www.pcmicro.com/elebbs/faq/rte200.html PatchCRT fails to patch the .EXE, there is a good chance it is because the .EXE has been compressed. The best tool I have found to uncompress .EXE files is UNP. This has worked for about 80% of the compressed .EXE files I have encountered. The nice thing about UNP is it runs well under Windows. My second choice would be CUP386, but this works best in a plain DOS environment without any extended memory manager (including himem.sys or emm386.sys) installed. I have used this tool to uncompress several .EXE's which UNP was unable to do. Once you have sucessfully uncompressed a compressed .EXE file, you should then be able to run PatchCRT on it to remove the RTE200 bug. If all the above fails, the other option is to run a TSR (Terminate and Stay Resident) utility that will provide a kluge to the division by zero issue by catching this error as the .EXE is being run, and telling DOS to ignore it. The best TSR I have found to do this is TP7p5fix. Simply run the TP7P5.EXE to load the TSR into memory, and any programs being run in that DOS window will avoid the RTE200. Keep in mind that once you close this DOS Window, or open other DOS Windows the TSR will not be active unless you load it again. Be sure to read our Disclaimer Re
MSS03USA 2006South Africa 2008 Last updated: July 18th, 1999(Uploaded May 17th, 1998) Runtime Error 200 running a Pascal program on fast systems (PII 266+) Contents of this document General information Programmers information Programmers Option 1: Enhancing the Delay-routine Programmers Option 2: Removing the Delay-routine Optional replacement delayloop Users Patch-program http://mtech.dk/thomsen/program/pasbug.php General information The Runtime Error 200 (Division by zero) bug is not part of the Pentium Errors. It's a mistake Borland made. The initialization part of the CRT unit has a calibration loop for the procedure DELAY. The resulting value of a counter depends on the speed of the cpu. This counter has an overflow on high speed cpu's, including Pentium II 266 Mhz and faster. Actually it is runtime error the same bug that on earlier processors caused Delay to be inaccurate, that now causes programs to fail with a runtime error if they use the CRT unit! Some (earlier?) compiler versions mysteriously seem to go free of this bug - Delphi doesn't have them, for instance, and Turbo Pascal 6 seems to work too. Please note: I take no responsibility for the potential damage people may do to their pascal exit code RTL's, working programs or vital data while using the instructions in this document. Keep backups of the appropriate files! (and then some...) Programmers As a programmer you have several different options. First of all you can disable the delay-routine completely. If you need a delay routine you can use the one found in this document, you can create your own, or you can find another one somewhere on the web. Another solution is to change the Delay-routine so it will work on todays fast systems. This solution found in this document should push the problem about 10 years into the future if we assume that Moores Law is correct. If you're having Borland Pascal, you also have the sources of the runtime library. Just make the following changes and recompile the complete runtime library. A MAKEFILE is included with the sources. If you have Turbo Pascal only, it's a bit more complicated. You'll need the sources of unit CRT. At least the files CRT.PAS, CRT.ASM and SE.ASM. They are the same in 7.0 and 7.01. Unfortunately copyright laws prevent me from letting you download the patched CRT.TPU file from this server, so please change it yourself (it is pretty easy): Implement the changes, and assemble (TASM 3.2 pref