Quote - kawecki - Did you disassemble the resulting binary correctly?  Some disassemblers default to 16 bit unless you specify otherwise. > Quote -

The opcode for a call segment:16bit is different from call segment:32bits.
The sample code can be so small that you can even can disassemble it by hand with a text editor. The only problem is to find where WinMain starts because the compiler adds a prolog and an epilog.
You will find that the function call in this case MessageBox is a two steps call, first is done a normal relative call to the end of the code where you find a list of far calls in the form segment:32 bit address.
All function calls of the same function points to the same far call, so it is only needed to relocate the values at the end of the code.
Not all the disassemblers generate this last part of the code, but you can find where it is and disassemble this fraction of code or just look at the hexadecimal values.

Quote -   (also what operating system are you running under?)

Depend on the disassembler that you use, they are many for DOS, Win16 or Win32. You can disassemble 32 bit code under DOS, the only problem is that DOS has problems with large size code, but for some few hundreds there's no problem.
Do you know some disassembler runing under Linux?

Quote - There is no need for far procedure calls under Win32, as everything fits under the linear 4 GB address space in a single segment.

Yes, I know that there's no need, but this is the way as Windows works!!!! as it was in the old Windows 3.0.
If Windows worked different there would be no needs for relocation!!!

Quote -   Segmentation doesn't even extend the address space because you are still limited to a 32 bit linear address.

Yes it does, you can address with segmentation a 40 bit address space, but each segment can have only 4GB size maximum.
With CPU64 this 40 bit address space was extended to 48 bits and not to 64 bit as you think.
Probably in the next following years the new CPUs will extend this 48 bits to 64 bits.

Quote - (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 Intel 8086 used a very primitive segmenting system without any kind of segment management, they only added addresses with the segment data shifted with a stupid 4 bit shift. 80286 added a more intelligent 8 bit shift.
Motorola 68000 was built from the begining with 32 bit registers and a 4GB address space, even it was a 16 bit processor!!
Zilog Z8000 used an intelligent segment management as used in the next decade 80386.
All these three CPU were built almost at the same time, I don't know if 8086 or 68000 was the first. IBM picked the worst processor of these three and it was even worst because they used 8088 that was a 8 bit bus version of the 8086 (16 bit bus).

Quote - 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.

In Windows all your code and all the DLLs run at the same priviledge level. Only in Windows XP were added some functions that can run only in the supervisor mode, but if you login as supervisor your almost all run in the same level. The only thing that you cannot access are the descriptor table (I suppose, maybe it can be done too!).
The 30386 ++++++, provided a lot of security tools, but almost none is used by Windows and you can access all you want.

Quote - 64 bit systems don't use the entire 64 bit address space (yet)

Only it is 48 bits.

Quote - .  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).

Exactly the same limit as for 32 bit processors!!!!

Stupidity also evolves!