home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / msdos / programm / 8025 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  1.5 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!hpscdc!hplextra!hpfcso!hpfcbig!fritz
  2. From: fritz@hpfcbig.SDE.HP.COM (Gary Fritz (tmp))
  3. Newsgroups: comp.os.msdos.programmer
  4. Subject: Re: Re: C/C++ <--> Turbo C/C++ whats the difference?
  5. Message-ID: <11740002@hpfcbig.SDE.HP.COM>
  6. Date: 20 Jul 92 21:25:04 GMT
  7. References: <7406@public.BTR.COM>
  8. Organization: HP SESD, Fort Collins, CO
  9. Lines: 26
  10.  
  11. In comp.os.msdos.programmer, timlee@public.btr.com writes:
  12. >Some MSDOS C compilers are limited to 640K, use messy segmented
  13. >pointers ("void far *foo" and things like that), and have only
  14. >16 bit ints, which are bound to annoy many UNIX C programmers.
  15. >Others, using MSDOS extenders, avoid the 640K limit and segmented
  16. >pointers, and have 32 bit ints.
  17.  
  18. >16 bit compilers:
  19. >Borland C/C++
  20.  
  21. I'm running from a very limited knowledge base, but...
  22.  
  23. From my brief perusal of Borland C++ 3.0 manuals, it appeared to me that
  24. while they DO have such cruft as near/far/huge/etc, they weren't limited
  25. to 16-bit ints.  Or was that "long"s that were 32 bits?  Hmmm.
  26.  
  27. Are you saying that the "32-bit" compilers you list do NOT have to deal
  28. with the near/far/huge stuff?  Do they do this by always generating the
  29. worst-case "far" code?  From my (admittedly limited) understanding of
  30. the DOS world, the braindead segmented Intel architecture forces you to
  31. either pay attention to segmentation, or accept fairly serious efficiency
  32. losses.  Or am I misunderstanding you?
  33.  
  34. Maybe I need a clearer understanding of what an "MSDOS extender" is...
  35.  
  36. Gary
  37.