Earlier quoted context omitted.
> This only works in real mode, where the segment is shifted and directly added to the offset. In protected mode, it goes through a selector table. Of course this is true. You wrote further above: > In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. I wanted to outline that whether this is a problem or not depends a lot on the concrete 16 bit architecture.
Are you thinking of a specific concrete 16-bit architecture where it's easy to access data objects larger than 64K? I'd be interested to hears... I really can't. Probably the most capable architecture I'm familiar with that has a native 16-bit pointer type is the 80286, which provides 24-bit physical addressing, virtualizatoin, protections, etc. Even then, at least on Windows, key local heaps within the OS were confi…
Your question implies that you want one piece > 64 KiB of flat memory. With this you already stated a very strong implicit assumption about the data layout and the kind of algorithm that you want to use. My point rather is: Consider the capabilities that the 16b machine has and try to fit the data representation and algorithms that you use around it instead of wining about lack of machine capabilities. One will often find a solution using clever tricks that one would not have considered otherwise, which will often turn out to be surprisingly elegant and much better than the "naive" solution.
This way to program is of course nothing for the kind of programmer that want to write an unelegant and just working program in a short amount of time, I know. :-)