Hi! On Sun, Nov 15, 2009 at 07:05:45PM +0100, Christian Grössler wrote: > DYNAMIC_DD should be easily possible to make a contructor > of open(). Then its size impact would only affect programs > which really open files. > > UCASE_FILENAME is a different thing, though. Despite its > name it not only uppercases file names at open() time (needed > for DOS 2.5 which only accepts file names in uppercase), it > also prepends a "Dx:" to the file name. Because of this one > can open "BLA.TXT" instead of "D0:BLA.TXT". "BLA.TXT" alone > is no valid string for the DOS open routine. I cannot really comment on these two. But uppercasing file name string literals in the source code is not really a problem. And, browsing through crt0.s and ucase_fn.s, I can see a few places where it is possible to save a few bytes of code. The code could also be written simpler, if the options are always assumed to be enabled (that is, with the .if's removed). For example in ucase_fn: Always allocate enough stack space for the length of the string + the three bytes for drive and terminator. > The file descriptor initialization is done in order > to have stdin/stdout/stderr implicitly available. > I think I could move it to a contructor for open/close/read/write. > Then programs which use conio and/or joysticks to get their > input and use conio for output shouldn't be affected. That is how it works on the CBMs. Regards Uz -- Ullrich von Bassewitz uz@musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Sun Nov 15 21:29:43 2009
This archive was generated by hypermail 2.1.8 : 2009-11-15 21:29:45 CET