ked@garnet.berkeley.edu (Earl H. Kinmonth) (02/14/89)
Several days ago, I posted an item asking for (a) a working equivalent to far*malloc of the Misery DOS world or (b) suggestions on how to get the K & R alloc() to work with brkctl() of SCO Xenix 2.2. The response was underwhelming. I the meantime I continued working on K & R and now have what seems to be a working far*malloc using brkctl(). The main trick was to use huge pointers in maintaining the free list. While I'm sure bugs will show up, the routine as it stands is quite useful. It gives conventional malloc() behavior for far * memory blocks. The few Turbo C programs I have that use its farmalloc() work properly with my far_malloc() when compiled under Xenix. Although no one block can be more than 64 k, it seems to properly manage multiple blocks. I've had 750K of strings in one program! If anyone would like a copy of the allocator, request it by e-mail. Requests giving an address relative to ucbvax will be MOST appreciated. Requests mailed to the proper address (below) will be even more appreciated. PS: The _ffmalloc() and _ffree() routines suggested by the one and only respondent to my query core dump on my system. QUESTION: Does anyone know of a GOOD discussion concerning segmented addressing in C? RHETORICAL QUESTION: Has anyone calculated the person-hours and millions of dollars that have been wasted because of Intel's decision to make its "advanced" processors backasswards compatible (the usual excuse given for segmented addressing)? If segmented addressing really was for backasswards compatability, I wonder why they did not put filaments in their chips for those more familiar with vacuum tubes? Earl H. Kinmonth History Department University of California, Davis Davis, California 95616 916-752-1636 (day: voice, 2300-0700 PST: fax) 916-752-0776 (secretary) ucbvax!ucdavis!ucdked!cck (email) cc-dnet.ucdavis.edu (request ucdked, login as guest)