Walter Bright wrote:
> Frits van Bommel wrote:
>> Some testing shows that all DMD-frontend based compilers (i.e. DMD, GDC and LDC) seem to produce that error message for any version identifier starting with "D_" (Including "D_" itself).
> 
> The point of that is to ensure that the D_ name space is reserved for predefined version identifiers. This check is done in VersionCondition::checkPredefined() in cond.c.

I figured as much, and probably should have mentioned that for clarification.

Walter Bright wrote:
> Frits van Bommel wrote:
>> [1]: Hey, x86 technically has 6-byte pointers if you count segments as part of the pointer (which would be mostly useless on currently popular operating systems though).
> 
> It does, but I know of no compiler that supports that (C, C++, or any other), and code that needs to deal with that tends to be assembler.

Shouldn’t most (ancient) 16-bit x86 compilers have support for “near” and “far” pointers? Seems this should just require some updating of that concept.

—Joel Salomon

Joel C. Salomon wrote:
> Walter Bright wrote:
>> Frits van Bommel wrote:
>>> [1]: Hey, x86 technically has 6-byte pointers if you count segments as part of the pointer (which would be mostly useless on currently popular operating systems though).
>>
>> It does, but I know of no compiler that supports that (C, C++, or any other), and code that needs to deal with that tends to be assembler.
> 
> Shouldn’t most (ancient) 16-bit x86 compilers have support for “near” and “far” pointers? Seems this should just require some updating of that concept.

The 16 bit compilers (like Digital Mars C++ for DOS) do have such support. Just not the 32 bit ones (which the 6 byte pointers would be). It could be added to DMC for 32 bits, but there is no point to it because there's no demand for it.

DMC++ still supports 16 bit targets, but frankly, about 1 person a year gets it for that purpose. 16 bits is dead, dead, dead.

Walter Bright wrote:

> The 16 bit compilers (like Digital Mars C++ for DOS) do have such support. Just not the 32 bit ones (which the 6 byte pointers would be). It could be added to DMC for 32 bits, but there is no point to it because there's no demand for it.

FWIW, Open Watcom supports far (48 bit) pointers in 32 bit code. However, since the feature sees almost no use it is probably buggy.

> DMC++ still supports 16 bit targets, but frankly, about 1 person a year gets it for that purpose. 16 bits is dead, dead, dead.

There is a community of 16 bit DOS users out there. Some of those folks are using 16 bit x86 devices in small embedded systems. It's a small community to be sure, but not zero sized.

Peter

Peter C. Chapin wrote:
> There is a community of 16 bit DOS users out there. Some of those folks
> are using 16 bit x86 devices in small embedded systems. It's a small
> community to be sure, but not zero sized.

Back in the bad old DOS days, the 8 bit CPM computers suffered a similar fate. The CPM programmers were a bit upset that their computers, software, expertise, was no longer wanted. They were also upset that their dev tools were no longer being developed, but understood that was because none of the CPM programmers wanted to pay any money for them. All the software for CPM had reverted to free and essentially abandoned.