2

I was looking up examples containing “NEAR PTR”, but they were easily replaceable with “PTR”. Is there any advantage for using “NEAR PTR”?

Jonathan Southern
  • 1,121
  • 7
  • 22
  • Possible duplicate of [Near and Far pointers](https://stackoverflow.com/questions/3869830/near-and-far-pointers) – phuclv Apr 25 '19 at 11:10

1 Answers1

2

NEAR is a legacy from 16-bit past. Assuming your code is 32-bit or 64-bit, they are the same.

This is about memory segments (Wikipedia link to x86 32-bit and to 64-bit).

In LABEL statement both PTR and NEAR PTR just store a 32/64 bit memory address without segment.

If compile next code under 64-bit MASM:

_DATA SEGMENT
    justPtr LABEL PTR db
    nearPtr LABEL NEAR PTR db

    justPtrSize dd SIZEOF justPtr
    nearPtrSize dd SIZEOF nearPtr
_DATA ENDS

and check under Visual Studio debugger the sizes:

?justPtrSize
8
?nearPtrSize
8

Indeed PTR occupies 8-byte (64 bit), same way as NEAR PTR does.

Renat
  • 7,718
  • 2
  • 20
  • 34
  • 2
    You can have far pointers in 32 and 64 bit code, they just usually don't make much sense. One case where they do is accessing TLS data through `fs` and `gs`. – fuz Apr 25 '19 at 07:52
  • @fuz, thanks for comment. But the question was about difference NEAR PTR vs PTR, not FAR PTR vs PTR. As I understand NEAR PTR doesn't involve storing segment address, neither does PTR (in 32/64). – Renat Apr 25 '19 at 09:14
  • 1
    @Rent Indeed! I just wanted to clarify that far pointers still exist in 32 and 64 bit code. – fuz Apr 25 '19 at 11:58
  • 2
    @fuz There were OSs that used segmented (16:32) code and data. The Watcom C/C++ compiler (a commercial compiler in that times, now it is free and open-source) was able to compile code for such OSs. In this case, `sizeof(void *)` was 6. – Martin Rosenau Apr 25 '19 at 18:15
  • 1
    @MartinRosenau - what was unique about Watcom C/C++ 10.0 is that it included full support for winmem32, a 32 bit flat address space model for Windows 3.1. I don't recall a 16:32 segmented model. Microsoft (and probably other) 16 bit tool sets included support for Windows 3.1 variation of huge model, globalalloc() and globallock(), which used selectors instead of segments, with each selector "pointing" to a 64KB block of memory, with an increment of _AHINCR == 8, to advance from 64KB block to 64KB block, a 16:16 segmented model. – rcgldr Apr 26 '19 at 14:46
  • 1
    @MartinRosenau - Windows 3.1 also had [win32s](https://en.wikipedia.org/wiki/Win32s), a 32 bit flat address space subset of Windows NT 3.1 32 bit API, but apps for that were generally built with 32 bit toolsets, that included the "thunk" libraries for win32s. – rcgldr Apr 26 '19 at 14:52
  • @rcgldr I have worked with win32s, too. This extension was designed to allow writing programs optimized for Windows NT but also running under Windows 3.1. Therefore win32s used linear memory, not 16:32. The Watcom compiler (and linker) could generate executable files for various OSs and platforms, not only for Windows (but Novell Netware modules, for example). Some of these platforms used 16:32 pointers. – Martin Rosenau Apr 26 '19 at 20:17