home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / msdos / programm / 10877 < prev    next >
Encoding:
Internet Message Format  |  1992-11-24  |  4.7 KB
  1. Path: sparky!uunet!cs.utexas.edu!ut-emx!jamshid
  2. From: jamshid@ut-emx.uucp (Jamshid Afshar)
  3. Newsgroups: comp.os.msdos.programmer
  4. Subject: FAQ CORRECTION: there is no BC++ 4.0
  5. Summary: Don't believe everything you read, even if I wrote it
  6. Message-ID: <84236@ut-emx.uucp>
  7. Date: 23 Nov 92 23:19:07 GMT
  8. References: <msdos-faq.921115.1@NCoast.ORG> <msdos-faq.921115.3@NCoast.ORG>
  9. Reply-To: jamshid@emx.utexas.edu
  10. Organization: The University of Texas at Austin; Austin, Texas
  11. Lines: 80
  12.  
  13. The FAQ List Part 3 says:
  14. >Q609. How can I access memory beyond 640K?
  15. >    I'm outside my expertise on this one, but in November 1992 Jamshid
  16. >    Afshar (jamshid@emx.utexas.edu) kindly supplied the following:
  17. >    ...........................(begin quote)............................
  18. >    [...]
  19. >    3. Use a DOS extender.  This is definitely the best solution from
  20. >    [...]
  21. >    - Wait for Borland's DOS extender package (in BC++ 4.0) that is
  22. >      supposed to be released at the end of this year.  I believe MS is
  23. >      also doing the same.  [...]
  24.  
  25. The references to BC++ 4.0 and its release date were COMPLETE
  26. SPECULATION on my part which I wrote up several months ago.  I
  27. sincerely apologize for not editing the information I sent to Stan for
  28. correctness and for not removing my speculations and personal bias.  I
  29. honestly have no inside information about Borland's or MS's plans for
  30. their future DOS products.  A Borland employee has recently posted
  31. that BC++ 4.0 is not even a product.  I'm appending what I should have
  32. sent to Stan.  Please ignore the answer in the current (Nov. 15) FAQL.
  33.  
  34. --Jamshid's answer to the FAQ "Is there any way to access over 640k in DOS?"--
  35.  
  36. You have several options.
  37.  
  38. 1. Use XMS memory (don't bother with EMS).  There are some libraries
  39. available at Simtel to access XMS.  The disadvantage is that you don't
  40. allocate the memory as you would with malloc() (or `new' in C++).  I
  41. believe it also requires that you lock this memory when in use. This
  42. means your code is not easily ported to other (and future) operating
  43. systems and that your code is more convoluted than it would be under a
  44. "real" os.  The advantage is that the library works with compilers
  45. since Turbo C 2.0 (I think) and that your program will easily run on
  46. even 286s.
  47.  
  48. 2. Program under MS Windows.  MS Windows functions as a 16-bit DOS
  49. Extender (see #3).  Borland/Turbo C++ 3.x includes EasyWin which is a
  50. library that automaticly lets you compile your current code using
  51. C/C++ standard input or <conio.h> into a MS Windows program so your
  52. code can immediately allocate many MBs of memory (Windows enhanced
  53. mode even does virtual memory).  The disadvantage is that like any
  54. 16-bit Extender a single malloc() is restricted to 64K (unless you
  55. want to mess with huge pointers in Windows).  Also, EasyWin's screen
  56. output is significantly slower than a DOS character-mode program's
  57. and you must of course run the program from Windows.
  58.  
  59. 3. Use a 16-bit or 32-bit DOS Extender.  This is definitely the best
  60. solution from the programmer's standpoint.  You just allocate as much
  61. memory as you need using malloc() or `new'.  A 16-bit Extender still
  62. has 16-bit 'int's and restricts arrays to 64K, but a 32-bit Extender
  63. has 32-bits 'int's (which makes porting a lot of UNIX code easier) so
  64. there are no 64K limits.  A 32-bit Extender requires a 32-bit compiler
  65. and the program will not run on 286s.  Some Extenders also do virtual
  66. memory.  Using an Extender doesn't require source code changes and
  67. unlike option #1 your code is portable and not obsolete in a few
  68. months.  Your options for this solution are:
  69.    a. Buy PharLap's 16-bit Extender that works with BC++ 3.0+ and MSC
  70.       (just requires a relink).  Note, the BC++ 3.1 upgrade came with
  71.       PharLap "lite".  Pharlap's 32-bit Extender works with 32-bit
  72.       compilers like [?]
  73.    b. Get the GNU (free,copylefted) gcc 2.x compiler which DJ Delorie
  74.       ported from UNIX and which uses his 32-bit Extender.  It supports
  75.       C and C++, but the Extender is VCPI which means neither the compiler
  76.       nor programs it produces will run in a DOS session under Windows.
  77.       FTP to barnacle.erc.clarkson.edu and get pub/msdos/djgpp/readme.
  78.    c. Get a 32-bit compiler or one that comes with a DOS Extender.
  79.       Zortech comes with 16-bit and a 32-bit Extenders (no debugger for
  80.       32-bit programs, but Flashtek sells one).  Watcom also makes a
  81.       C [and C++?] 32-bit compiler.  [If anyone else has products or
  82.       plans to announce, please let me know.]
  83.  
  84. 4. This option doesn't really count since it's not a solution in DOS,
  85. but you could switch to a full 32-bit operating system like OS/2 2.0
  86. or UNIX (or NT when it comes out).  I believe Win32 will allow you to
  87. write 32-bit Windows programs. [can someone fill me in on what exactly
  88. Win32 is?]
  89.  
  90. Jamshid Afshar
  91. jamshid@emx.utexas.edu
  92.  
  93.