home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / mswindo / programm / win32 / 3023 < prev    next >
Encoding:
Text File  |  1993-01-23  |  1.5 KB  |  32 lines
  1. Newsgroups: comp.os.ms-windows.programmer.win32
  2. Path: sparky!uunet!microsoft!hexnut!alistair
  3. From: alistair@microsoft.com (Alistair Banks)
  4. Subject: Re: 16-bit Windows 3.1 vs Win32s thunking
  5. Message-ID: <1993Jan22.080936.23324@microsoft.com>
  6. Date: 22 Jan 93 08:09:36 GMT
  7. Organization: Microsoft Corporation
  8. References: <1993Jan21.020250.29619@emr1.emr.ca>
  9. Lines: 21
  10.  
  11. In article <1993Jan21.020250.29619@emr1.emr.ca> jagrant@emr1.emr.ca (John Grant) writes:
  12. >Windows 3.1
  13. >-----------
  14. >In Windows 3.1, I can use huge pointers for large objects.  Somewhere
  15. >in the compiled code, these are 32-bit pointers which are switched
  16. >back and forth between linear 32-bit addresses and segmented 16/16-bit
  17. >addresses as they are used in computations and for dereferencing things.
  18. >At least, that's my understanding of huge pointers.
  19.  
  20. You're assumptions about Win32s are quite wrong, and in general about
  21. the operation of 32-bit code on Intel x86. The huge pointers you refer
  22. to are quite different from the 32-bit addressing used by Windows NT
  23. and Win32s+Win3.1 - the 386 in fact has 16-bit segments, and optionally
  24. 16-bit or 32-bit offset registers. The huge mode you refer to uses
  25. 16:16 addressing, while Windows NT & Win32s use 16:32 - but that would
  26. be 48-bit addressing, right? Well no, because we set the 16-bit
  27. segment registers to zero, so cs=ds=es=gs=fs=0, and we just use
  28. 32-bit addressing - this is a portable concept, particularly to
  29. RISC systems which don't have "segment" registers a la x86
  30.  
  31. Hope this makes more sense now -- Alistair
  32.