raab@novavax.UUCP (Moshe Raab) (11/08/90)
I am developing a program (to run under DOS) that uses third party libraries (C-scape, Paradox and Metawindows). Because of the nature of what I am doing and of the libraries I have run out of conventional memory (I estimate that I need about 500K of conventional RAM just for data). I have looked at several options: 1) RTLINK plus: this overlay linker really helps only in the code area. it does not virtualize any data segements. virtualizing third party libraries is not always possible. 2) Rational Systems DOS/16M. this is a "DOS Extender". By switching to protected mode, all of memory is addressable and the 640K boundary goes away. I am pretty sure that this is what I will need, but i can't afford the $5000 (starting) price tag. 3) Coding for EMS support. Since almost all of the memory is being used by the third party libraries, I have no control of the memory allocation. I am looking for suggestions on how to solve this problem. If there are reasonably priced packages, heap managers or other tips that you may know about I would appreciate if you could let me know. Thank you very much. Moshe Raab raab@novavax
bright@nazgul.UUCP (Walter Bright) (11/13/90)
In article <2078@novavax.UUCP> raab@novavax.UUCP (Moshe Raab) writes:
/(I estimate that I need about 500K of conventional RAM just for data).
/1) RTLINK plus
/2) Rational Systems DOS/16M
/3) Coding for EMS support
Zortech C/C++ has an additional pointer type, called a __handle pointer,
which is used like a conventional pointer, but instead points into data
that is in EMS. The swapping of EMS pages in and out is handled
transparently.
kaiser@ananke.stgt.sub.org (Andreas Kaiser) (11/17/90)
In your msg to All, dated <16 Nov 90 19:00>, it said: WB> Zortech C/C++ has an additional pointer type, called a __handle WB> pointer, which is used like a conventional pointer, but instead points WB> into data that is in EMS. The swapping of EMS pages in and out is WB> handled transparently. Beautiful feature. Except that handle pointers with static scope do not reserve storage... It took an aweful lot of time to find this bug experimenting with a MicroEmacs version using handle pointers for text storage. BTW: There is a problem with these handle pointers: It should not be possible to convert a normal far pointer to a handle pointer. It's just too easy to write silly code like: char __handle *p; ... p = strchr(p, '.'); where p looses it's virtual memory property. Andreas reas -- :::::::::::::::::::: uucp: kaiser@ananke.stgt.sub.org :: Andreas Kaiser :: fido: 2:509/5.2512 & 2:507/18.7206 ::::::::::::::::::::
bright@nazgul.UUCP (Walter Bright) (11/21/90)
In article <7.2744358B@ananke.stgt.sub.org> kaiser@ananke.stgt.sub.org (Andreas Kaiser) writes:
/Beautiful feature. Except that handle pointers with static scope do not reserve storage... It took an aweful lot of time to find this bug experimenting with a MicroEmacs version using handle pointers for text storage.
I have never been able to duplicate this problem you had. Could you perhaps
email me a file which demonstrates it? Thanks.