Integer conversions too pedantic in 64-bit

[Walter Bright]

Don wrote:
> Walter Bright wrote:
>> Don wrote:
>>> [1] What was size_t on the 286 ?
> 
>>
>> 16 bits
>>
>>> Note that in the small memory model (all pointers 16 bits) it really 
>>> was possible to have an object of size 0xFFFF_FFFF, because the code 
>>> was in a different address space.
>>
>> Not really. I think the 286 had a hard limit of 16 Mb.
> 
> I mean, you can have a 16 bit code pointer, and a 16 bit data pointer. 
> So, you can concievably have a 64K data item, using the full size of 
> size_t.
> That isn't possible on a modern, linear address space, because the code 
> has to go somewhere...

Actually, you can have a segmented model on a 32 bit machine rather than a flat 
model, with separate segments for code, data, and stack. The Digital Mars DOS 
Extender actually does this. The advantage of it is you cannot execute data on 
the stack.

>> There was a so-called "huge" memory model which attempted (badly) to 
>> fake a linear address space across the segmented model. It never 
>> worked very well (such as having wacky problems when an object 
>> straddled a segment boundary), and applications built with it sucked 
>> in the performance dept. I never supported it for that reason.
>>
>> A lot of the effort in 16 bit programming went to breaking up data 
>> structures so no individual part of it spanned more than 64K.
> 
> Yuck.
> I just caught the very last of that era. I wrote a couple of 16-bit 
> DLLs. From memory, you couldn't assume the stack was in the data 
> segment, and you got horrific memory corruption if you did.
> I've got no nostalgia for those days...

I rather enjoyed it, and the pay was good <g>.