alamanos opened this issue on Jan 29, 2007 · 127 posts
Talain posted Fri, 09 February 2007 at 6:49 PM
kawecki - Did you disassemble the resulting binary correctly? Some disassemblers default to 16 bit unless you specify otherwise. (also what operating system are you running under?)
There is no need for far procedure calls under Win32, as everything fits under the linear 4 GB address space in a single segment. Segmentation doesn't even extend the address space because you are still limited to a 32 bit linear address. (under 16 bit, segmentation was the only way to address memory past 64K, which was too small an amount even way back when. 8086 real mode calculated the linear address by segment * 16 + offset; the 80286 allowed up to 16 MB of physical RAM to be addressed, but only in segments of 64 K. The 386 extended the address space up to 4 GB and added 32 bit mode as well. From the 386 onward, the maximum segment size for 32 bit mode was the same as the linear address space).
Furthermore, in protected mode, the privilege level is determined by the code segment selector. Being able to call into another segment could allow a process to elevate its privilege level, which is a clear no-no.
Besides, all this would result in a great increase in complexity which is simply not necessary. Simply mapping a DLL into the address space of a process that wants to load it is all that is needed.
It is also not possible to extend the address space past 4GB under 32 bit mode, as linear addresses are 32 bits, period. There is something called PAE (physical address extensions), which has existed for awhile that allows for up to 64 GB of physical RAM to be installed in a system, though any one process is still limited to addressing 4GB of that.
64 bit systems don't use the entire 64 bit address space (yet). I think that Vista only uses 40 bits of it, for up to 1 TB of addressable memory per process (an amount unlikely to be exceeded in Vista's operational lifetime).