From: utzoo!decvax!harpo!npois!ucbvax!C70:info-cpm Newsgroups: fa.info-cpm Title: block size Article-I.D.: ucb.1289 Posted: Sat Jun 5 00:48:12 1982 Received: Sat Jun 5 05:25:19 1982 >From lauren@Ucla-Security Sat Jun 5 00:47:54 1982 Oops. I don't want to be misleading. Simply reducing the block size down to 256 on a typical CP/M system would have rather negative effects since the support for accessing the file in reasonable ways is essentially non-existent. In order to get away with such a block size, you really have to switch over to a more complex environment where most disk file management is within the OS, where uniform buffer management can be enforced. An unfortunate aspect of CP/M is that every user program must contain all disk I/O buffer management -- since CP/M has no such functionality built in. Subjectively, I have found that similar programs running under MARC and CP/M seem to run faster under MARC -- even given disk I/O to arbitrary pathnames at various levels in the filesystem tree. Part of the gain appears to be from the adoption of the Unix "sync" mechanism for flushing some blocks to disk only when required by the program (or internal system requirements). On text files, the use of a single newline character rather than CR/LF (and that inane ^Z business) seems to buy even more efficiency in most cases. Personally, the single aspect of CP/M that has irked me the most is the crock of putting ^Z at the end of text files ... SOMETIMES. Of course, if you HAPPEN to end up on an even sector boundary, you might not find a ^Z. This single fact has probably caused me the most headaches in finding a reasonable way to allow CP/M programs (which often don't seem to care how many files they open or if they ever bother to close them) to operate reasonably under a "real" OS (as opposed to a glorified file-"manager"). End of flame. --Lauren--