home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / msdos / programm / 8034 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  3.3 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!apple!apple!netcomsv!proto!joe
  2. From: joe@proto.com (Joe Huffman)
  3. Newsgroups: comp.os.msdos.programmer
  4. Subject: DOS extenders (Was: Re: C/C++ <--> Turbo C/C++ whats the difference?)
  5. Message-ID: <1992Jul23.180021.8345@proto.com>
  6. Date: 23 Jul 92 18:00:21 GMT
  7. References: <7406@public.BTR.COM> <11740002@hpfcbig.SDE.HP.COM>
  8. Organization: Prototronics @ Sandpoint, Idaho
  9. Lines: 56
  10.  
  11. fritz@hpfcbig.SDE.HP.COM (Gary Fritz (tmp)) writes:
  12.  
  13. >In comp.os.msdos.programmer, timlee@public.btr.com writes:
  14. >>Others, using MSDOS extenders, avoid the 640K limit and segmented
  15. >>pointers, and have 32 bit ints.
  16.  
  17. >Are you saying that the "32-bit" compilers you list do NOT have to deal
  18. >with the near/far/huge stuff?  Do they do this by always generating the
  19. >worst-case "far" code?  From my (admittedly limited) understanding of
  20. >the DOS world, the braindead segmented Intel architecture forces you to
  21. >either pay attention to segmentation, or accept fairly serious efficiency
  22. >losses.  Or am I misunderstanding you?
  23.  
  24. >Maybe I need a clearer understanding of what an "MSDOS extender" is...
  25.  
  26. Yes.  You need a little bit more information... It's a rather common 
  27. situation too so don't think you are the only one that missed out.  
  28. I get a lot of technical calls at work from people asking "how can I do
  29. [something]" where [something] is best done with a DOS extended application.
  30. DOS extenders exist in two forms, 16-bit and 32-bit.  
  31.  
  32. The 16-bit extenders allow you to run on '286 and above machines and 
  33. access up to 16 Mbytes of memory, all just as if you were compiling 
  34. with a standard large memory model.  You can malloc up to 64K in any 
  35. single block, but instead of being limited to 10 or less such mallocs
  36. (640K), you can keep on requesting heap up to the actual physical 
  37. available RAM (2M?  8M?) up to 16M.  Similar things are possible with
  38. the code size, all without overlays.
  39.  
  40. The 32-bit extenders allow you to run on '386 and above machines and
  41. access up to about 4 Gbytes of memory (some extenders are intentionally
  42. 'crippled' and only allow something like 16 M).  These extenders let you
  43. malloc up to the physical available memory in a single call -- 
  44. malloc(1000000) is entirely reasonable.  Some 32-bit DOS extenders have
  45. virtual memory capability too (in their uncrippled form).  You can 
  46. malloc() (or run code) larger than physically available memory, up to 
  47. approximately the amount of free disk space you have available.  Also,
  48. the pointers are typically near pointers, but they are 32-bit near 
  49. pointers (far pointers are 48-bits).  These 32-bit near pointers mean 
  50. that access to data via this pointers runs much faster and with smaller 
  51. code size because the segment registers don't have to be loaded everytime
  52. you access a different pointer.
  53.  
  54. The drawback to 32-bit DOS extenders is that 1) Microsoft and Borland
  55. don't currently have compilers that support 32-bit DOS extenders (16-bit
  56. extenders -- yes, 32-bit -- no).  2) Many of the uncrippled 32-bit 
  57. extenders have royalties associated with them.
  58.  
  59. FlashTek (the company I work for) sells one of the few uncrippled, royalty
  60. free, 32-bit DOS extenders available.  Currently, it only supports
  61. Zortech, but other compiler support will be available soon.  You can get 
  62. a free demo disk by sending me some email and your snail mail address.
  63.  
  64. -- 
  65. netcom!proto!joe
  66. joe@proto.com
  67.