home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / mswindo / programm / win32 / 3019 < prev    next >
Encoding:
Text File  |  1993-01-23  |  2.0 KB  |  49 lines
  1. Newsgroups: comp.os.ms-windows.programmer.win32
  2. Path: sparky!uunet!charon.amdahl.com!netcomsv!netcom.com!hill
  3. From: hill@netcom.com (Tom Hill)
  4. Subject: Re: 16-bit Windows 3.1 vs Win32s thunking
  5. Message-ID: <1993Jan22.193712.19398@netcom.com>
  6. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  7. References: <1993Jan21.020250.29619@emr1.emr.ca>
  8. Date: Fri, 22 Jan 1993 19:37:12 GMT
  9. Lines: 38
  10.  
  11. In article <1993Jan21.020250.29619@emr1.emr.ca> jagrant@emr1.emr.ca (John Grant) writes:
  12. >My question focuses on the 16-bit code vs 32-bit code.
  13. >
  14. >Windows 3.1
  15. >-----------
  16. >In Windows 3.1, I can use huge pointers for large objects.  Somewhere
  17. >in the compiled code, these are 32-bit pointers which are switched
  18. >back and forth between linear 32-bit addresses and segmented 16/16-bit
  19. >addresses as they are used in computations and for dereferencing things.
  20. >At least, that's my understanding of huge pointers.
  21.  
  22. I don't think it works quite the way you are thinking. in Windows 3.1
  23. the only translation to 32 bit flat is done inside the CPU. i.e. huge
  24. pointers still consist of segment:offset, and offset is still 64k. The
  25. compiler generates code to deal with offset overflow by checking every
  26. time you add to offset, and moving to the next segment (enough segments
  27. to cover the huge object [size/64k] are created when the object is created).
  28. This is much slower than 32-bit flat.
  29.  
  30. >
  31. >Windows NT+Win32s
  32. >-----------------
  33. >So now if I have a Windows NT app, I can take it along with the Win32s
  34. >library to Windows 3.1 and it should run, right?  Apparently the 32-bit
  35. >pointers are thunked down to segmented 16/16-bit pointers by the library.
  36. >(I hope I'm getting this more or less correct).
  37.  
  38. Yes, for Win32s applications.
  39.  
  40. >
  41. >So what's the difference?
  42.  
  43. The difference is the speed at which your code can access large objects.
  44. If you code is more window intensive than memory intensive, you will
  45. be faster with native 3.1. If you use objects larger than 64k frequently
  46. you may be faster with win32s.
  47.  
  48. Tom Hill
  49.