Integer conversions too pedantic in 64-bit

[dsimcha]

This whole conversation makes me feel like The Naive Noob for 
complaining about how much 32-bit address space limitations suck and we 
need 64 support.

On 2/16/2011 8:52 PM, Walter Bright wrote:
> 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>.