[H8crilA]

First, WINE = Wine Is Not an Emulator. And it's not an emulator, the PE code runs directly on the host CPU. All you really need to implement is the OS API (on Windows the official API is with DLLs, such as KERNEL32.DLL, which in turn issue syscalls, and you're not generally supposed to do syscalls yourself).

Second, it runs 32 bit and even 64 bit too.

[Dwedit]

KERNEL32 is mainly implemented through calls to NTDLL. NTDLL is the one that triggers the actual system calls or thunks, the actual implementation is in NTOSKRNL.exe

Meanwhile USER32 used to do system calls to Win32k, but then they changed it to call Win32U, and have Win32U be all system calls to Win32k.

[bitwize]

But it does emulate the 16-bit x86 instructions from really old-school Windows code.

[rep_lodsb]

No it doesn't. 16-bit protected mode code will run natively even on 64-bit kernels - and there is a system call that can create the segment descriptors needed for that: https://man7.org/linux/man-pages/man2/modify_ldt.2.html

[chungy]

Missed the point. Wine runs Win16 binaries on 32- and 64-bit hosts, effectively by rethunking them to run in 32-bit mode. This can be viewed as a form of emulation.

Wine 9.0 can likewise rethunk 32-bit applications to run in 64-bit mode, but this is only the default on Mac OS X (where Apple removed 32-bit support), because it still introduces more compatibility problems on Linux than just running 32-bit code natively. (And thunking Win16 to 64-bit mode is not yet done.)

[rep_lodsb]

I'm not familiar with what exactly Wine does to run 32-bit code under OS X, but it would already have to do emulation / binary translation. Because some opcodes have been repurposed for the REX prefix in 64-bit mode, and any absolute 32-bit address would be interpreted as relative to RIP instead.

And 16-bit would be completely impossible, first there's the default operand size and then the completely different encoding for memory addressing.