far_malloc() for SCO Xenix 2.2
Earl H. Kinmonth
ked at garnet.berkeley.edu
Tue Feb 14 14:12:58 AEST 1989
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)
More information about the Comp.unix.xenix
mailing list