Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!pacbell.com!decwrl!bacchus.pa.dec.com!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Editing Files larger than available memory Message-ID: Date: 8 Oct 90 20:07:30 GMT References: <924@ucsvc.ucs.unimelb.edu.au> <6694@sugar.hackercorp.com> <6708@sugar.hackercorp.com> Sender: news@wrl.dec.com (News) Organization: Missionaria Phonibalonica Lines: 61 In-Reply-To: peter@sugar.hackercorp.com's message of 6 Oct 90 01:46:25 GMT In article <6708@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: For allocating fixed size blocks like this, I'd call AllocMem and FreeMem myself. Using fixed-size blocks is a major lose. You either wind up breaking large files into small chunks, or having small files chew up large chunks of memory. Neither is acceptable in a buffer gap editor, and it's even less acceptable if you use a linked list of lines. > So you have to implement your own memory allocation > strategy, that supports giving freed memory back to the system. Why? It's already there. Yes - and you get to choose one of two. The portable one that may or may not actually give blocks back to the OS, or the non-portable one. Some choice. > This > is going to add confusion to the editor, and is a worse than useless > for systems that have real VM. #ifdef Amiga freeblock(b) { FreeMem(b, BLOCKSIZE); } #else freeblock(b) { free(b); } #endif Simply shocking! Yeah, I'd expect you to produce useable code samples. I also figured you wouldn't recommend writing a memory allocation system after pointing out that one is already in place. As previously mentioned, you really can't use a fixed size blocks. You're also making the code uglier, and adding more code to the set of things that must be explicitly dealt with for a port. Obviously, _anything_ the machine can do can be made to work, if you're willing to make the cord sufficiently painfull to port. I've looked at and rejected making mg hand back unused buffers always. The only way I've found to do it is to create a special type of memory (which you apparently want to call a "block"), and add a memory allocation manager that can (if possible) give back the memory to the system. That's _exactly_ what you're doing above, though you forgot the part of the code. The code is simple, but it is more code that needs to be debugged. It's also in the non-portable section of the code, which means that _everyone_ who wants to port the editor has to at least decide whether to use the "portable" version, and possibly debug their own versions. That's a non-trivial hit on portability for a trivial functionality. You want the editor to give all it's memory back to the system? Hit the close gadget; it works like a charm. If you're running the editor resident, then your code even stays in memory.