user1311286
user1311286

Reputation:

WinDef.h why are far and near still here? C++

I was going through some code when I stumbled upon the far qualifier for the first time, now it makes sense to me why these used to be used. But with the memory model we use today why are these even in place anymore? Do people actually use these in practice, or are they just there as a trinket from the past?

What would even be the difference between using typedef BOOL near *PBOOL; and typedef BOOL far *LPBOOL;?

Is there any real use for these still? Or should I just look the other way.

// WinDef.h ~Line 144
#undef FAR
#undef  NEAR
#define FAR                 far
#define NEAR                near
#ifndef CONST
#define CONST               const
#endif

typedef unsigned long       DWORD;
typedef int                 BOOL;
typedef unsigned char       BYTE;
typedef unsigned short      WORD;
typedef float               FLOAT;
typedef FLOAT               *PFLOAT;
typedef BOOL near           *PBOOL;
typedef BOOL far            *LPBOOL;
typedef BYTE near           *PBYTE;
typedef BYTE far            *LPBYTE;
typedef int near            *PINT;
typedef int far             *LPINT;
typedef WORD near           *PWORD;
typedef WORD far            *LPWORD;
typedef long far            *LPLONG;
typedef DWORD near          *PDWORD;
typedef DWORD far           *LPDWORD;
typedef void far            *LPVOID;
typedef CONST void far      *LPCVOID;

EDIT: The first comment makes a good point too, what does this mean now if far and near are defined to nothing?

// WinDef.h: Lines 91-91
#define far
#define near

Upvotes: 14

Views: 6769

Answers (2)

Hans Passant
Hans Passant

Reputation: 941665

Microsoft carries a great burden, they do everything possible to make programs that were written 35 years ago still compile and run on modern Windows versions. No sane company would ever try to so something as silly as that, it is however the core reason that they were successful. Once a declaration makes it into a Windows SDK header, it takes a very, very good reason to get it removed again.

And yes, that really does mean that some ancient 16-bit C program somewhere can still be maintained and re-compiled. Which uses near and far pointers, that was necessary back then. That it still works on 32-bit and 64-bit versions of Windows after being recompiled is no accident.

This kind of back-compat exists in a language like C as well. To this day, a string literal is not a const char*, just char*. Makes no sense whatsoever but fixing it would break way too many existing programs.

Upvotes: 18

josh poley
josh poley

Reputation: 7479

Correct, they are not currently used for anything.

  1. Its not worth the effort to manually remove them (especially when the compiler can do it for you).
  2. Keep in mind that Windows supports multiple architectures, and it would suck to have to go add them back in if it were ported to an architecture where they made sense again.

Upvotes: 2

Related Questions