This falls in the realm of issue #30. While the current implementation allows complete freedom in file numbering, the linked list has a performance penalty especially for the first OPENed. All of the BASICs I've used have a limited set of file numbers available and they are basically statically allocated, usually based on a CLI argument. Putting them in an array that is allocated at start and never altered is a fast way to handle files and limit the amount of wasted RAM in low memory environments like DOS. The default allocation could be determined by platform to prevent maxing out architecture limits yet taking advantage of more generous environments. A CLI argument would allow the programmer to balance needs with resources. A hybrid mechanism could be to allocate an array of pointers based on a default max or CLI argument. Then allocate the actual FILE structures on an as needed basis stuffing the pointer into the array. This would minimize the RAM impact of large file counts, if they aren't actually used. But I don't know that the added complexity has enough offseting value and prefer a more KISS approach. Bottom line: using the file # as an index into an array is **MUCH** faster than searching a list for a matching number, especially if a lot of files are open and the one you're looking for happens to be at the tail of the stack.