home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!wupost!uwm.edu!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!ralf
- From: ralf+@cs.cmu.edu (Ralf Brown)
- Newsgroups: comp.os.msdos.programmer
- Subject: Re: XMS memory manager for C/C++ needed
- Message-ID: <Bu3465.33I.2@cs.cmu.edu>
- Date: 5 Sep 92 02:56:28 GMT
- Article-I.D.: cs.Bu3465.33I.2
- References: <1992Sep03.051903.110369@zeus.calpoly.edu> <1992Sep4.065429.25559@zooid.guild.org>
- Sender: news@cs.cmu.edu (Usenet News System)
- Organization: School of Computer Science, Carnegie Mellon
- Lines: 25
- Nntp-Posting-Host: b.gp.cs.cmu.edu
-
- In article <1992Sep4.065429.25559@zooid.guild.org> ross@zooid.guild.org (Ross Ridge) writes:
- }cambler@zeus.calpoly.edu (Christopher J. Ambler, Phish) writes:
- }>I'm looking for an XMS memory manager package that can make XMS available
- }>to the heap via malloc() or new calls transparently. Protected mode
- }>interfaces do not qualify for my application.
- }
- }Protected mode interfaces are really your only choice to do this
- }transparently.
-
- You can do it at least semi-transparently in C++; there's a virtual array
- class on SIMTEL20, though I forget the name.
-
- }The problem is that XMS memory isn't in the 8086's addressing space,
- }so you can't access it directly in real mode, only through handles and
- }XMS service requests. It is in theory possible to write a compiler
- }that could hide all this for you, and I believe MAC compilers do
-
- It's already been done for EMS with a special pointer type (Zortech C and
- I believe MS C 7.0), and shouldn't be much more complex for XMS.
-
- --
- Internet: RALF+@CS.CMU.EDU |The University would disclaim this if it knew...
- FIDO: Ralf Brown 1:129/26.1 |
- BIT: RALF%CS.CMU.EDU@CARNEGIE|"Success has a simple formula: do your best,
- AT&Tnet: (412)268-3053 school| and people may like it." -- Sam Ewing
-