home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / msdos / programm / 10558 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  1.7 KB

  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!darwin.sura.net!jvnc.net!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!skitzo.dseg.ti.com!frampton
  2. From: frampton@skitzo.dseg.ti.com
  3. Newsgroups: comp.os.msdos.programmer
  4. Subject: Re: 'new'ing >64K Objects in BC++
  5. Message-ID: <1992Nov12.074204.799@skitzo.dseg.ti.com>
  6. Date: 12 Nov 92 07:42:04 CDT
  7. References: <1992Nov8.181852.21103@piccolo.cit.cornell.edu> <83366@ut-emx.uucp>
  8. Followup-To: comp.os.msdos.programmer
  9. Organization: Texas Instruments Component Test Facility
  10. Lines: 23
  11.  
  12. > compiler extensions.  Btw, PharLap sells a DOS Extender that works
  13. > with BC++ or MSC.  I believe that a 16-bit Extender allows you to
  14. > access all your machine's memory (up to 16MB), but size_t and int are
  15. > still 16-bits, so each object is limited to 64K.  A 32-bit Extender
  16. > (like the one in DJGPP) makes them 32-bits so there are no 64K limits.
  17.  
  18.   My current work group is looking into buying me an extender for analysis
  19.   apps programs as the data is getting monsterous now.  I might then add
  20.   that PharLap is our best choice since our work stations are mixed (2/3)86s.
  21.   However it is rumored that BC++ 4.0 will have its own extender built in.
  22.   The 3.1 upgrade is also said to have PharLap Lite (up to 2 meg only).
  23.  
  24. > Currently I just don't use single arrays larger than 64K.  I do most
  25. > of my programming under MS Windows (which is why I don't use DJGPP),
  26. > so at least I have access to all my machines memory (Windows functions
  27. > as a 16-bit DOS Extender).  A 16-bit Extender requires a 286 or
  28. > better; a 32-bit extender requires a 386 or better.  Let me know if
  29. > I'm wrong about any of this.
  30.  
  31.   In wonderment...  Should it not be an option to force 16-bit addressing
  32.   out of a 32 bit extender?
  33.  
  34.