I'm curious how WINE accomplishes that, since my understanding was that the reason it can't be done on Windows x64 is because there is no way to switch the processor back to 16 bit mode from long mode. Is this incorrect or does WINE just go ahead and emulate 16 bit x86?

IIRC 16bit code on a 32bit version of windows runs in 32bit mode with some thunking for selectors. The issue is more that HANDLEs can have values up to half the sizeof(HANDLE) and supporting 16bit would have significantly harmed the value of 64bit code or required special consideration of where a HANDLE was getting allocated. Then you have to deal with a 64bit process creating a HANDLE and giving it to a 16bit process. Very quickly it turns into a corner case nightmare.

This is the correct answer. There's nothing stopping you from setting up a 16 bit protected mode descriptor in your GDT and using it. The issue was in thunking HANDLEs.

https://msdn.microsoft.com/en-us/library/aa384249.aspx

> Note that 64-bit Windows does not support running 16-bit Windows-based applications. The primary reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data. Attempts to launch 16-bit applications fail with the following error: ERROR_BAD_EXE_FORMAT.

Do you have a source for that? running 16 bit code in 32bit mode doesn't sound like it would work. All the instructions would do 32bit operations instead of 16bit operations. So if a program did what it thought was a 16bit write to a memory location it would actually end up doing a 32bit write and would clobber the adjacent 16bit memory location.

I know nothing about the topic. I'll only point out that https://bugs.winehq.org/show_bug.cgi?id=36664 says ".. the reality in the past the 16 bit code was not a issue because the [Linux] kernel always supported it." and "...3.15 after 16 bit support by [Linux] kernel is optional on 64 bit systems."

That links to lmkl posts like https://lkml.org/lkml/2014/4/14/207

>> Afaik 64-bit windows doesn't support 16-bit binaries, so I just assumed Wine wouldn't do it either on x86-64. Not for any real technical reasons, though.

> Yes, there is still a significant number of users, and we still regularly get bug reports about specific 16-bit apps. It would be really nice if we could continue to support them on x86-64, particularly since Microsoft doesn't ;-)

I would not be surprised to see MS introduce a dockerized '16bit compatibility' mode for Enterprise versions of windows. The only reason 32bit windows is still around is to support 16bit apps for these companies.

They previously had their "Windows XP Mode"[1], run via the Windows Virtual PC[2]. Obviously not a container and it's dead now but yeah...

[1] https://www.microsoft.com/en-nz/download/details.aspx?id=800... [2] https://en.wikipedia.org/wiki/Windows_Virtual_PC

> The only reason 32bit windows is still around is to support 16bit apps for these companies.

Pretty sure it's also used in some Atom tablets.

Atoms have been 64bit since 2010.

The HP Stream 7, a tablet released in late 2014 on the 64-bit Atom Z3735G, shipped with 32-bit Windows. This was presumably to avoid the memory overhead of 64-bit pointers, as it came with 1GB of RAM, so every bit counted.

Inferences from https://blogs.msdn.microsoft.com/oldnewthing/20081020-00/?p=... . I also know that 32bit programs could load 16bit modules without issue. In fact that was one of the things that MS was harping on people to not do; was stop using 16bit modules in their 32bit applications (which would have otherwise run fine on 64bit systems). I'm pretty sure it worked because 32bit system DLLS all got a 32 appended to them so the linker and loader would know which version they were going to and ensure that call was routed appropriately.

Edit: It's also worth noting that 32bit and 16bit instructions are different because of register size operands.

So to speak you're absolutely right... a 16bit read/write COULD do that... but it's a feature, not a bug.

Whether instructions operate on 32b or 16b quantities is not dependent on mode the processor is in, but on combination of bits in code segment descriptor, in essence these bits can change on every far call. In native long mode descriptor tables have different format, but these bits are still there and have effect.

This is one issue, another issue is that the method used to implement 16-bit compatibility in 32b windows involves virtual 8086 mode and running instance of DOS inside of that even for native 16b windows applications.

In all, I assume that it was droped mostly because it involved too much work for somewhat questionable benefit.

That won't have been the issue. Win16 programs never ran in v8086 mode, even on DOS-Windows 3.1. They ran in the normal 16-bit protected mode.

If I recall correctly, you can still switch the processor to 16-bit mode but virtual 8086 mode is not available from x86-64. So more recent 16-bit Windows applications can be made to work but DOS applications and older 16-bit Windows applications that rely on more legacy DOS-style APIs don't work.

The "older 16-bit Windows applications" (actually a misnomer because there isn't this distinction in practice) actually used DPMI, which does not involve v8086 mode.

well which is probably only possible if you don't run on efi only hardware. (no cs/m, which sometimes happens, especially on mac hardware)

The actual machine firmware has been irrelevant for v8086 ever since the time of OS/2 2.0 and DOS-Windows 3.1. Both used virtualized machine firmwares to run in the v8086 virtual machines. OS/2's was dealt with by a virtual device driver called VBIOS.SYS, for example.

This is precisely why DOSBox took a significant performance hit when going from x86 to amd64 back in the day.

Apparently it's a Windows limitation, rather than hardware one, since Linux supports it on x86_64. It got broken at one point, but then Linux kernel developers enabled it back, with even Linus Torvalds himself inquiring about this issue.

See https://lkml.org/lkml/2014/4/14/207

IIRC Wine is still typically installed as a i386 binary these days, so 16 bit compatibility is still an option.

64-bit Wine prefixes are perfectly capable of running Windows programs in all varieties from 16-, 32-, and 64-bit.

wine-devel discussion around 16bit support[1].

[1]https://www.winehq.org/pipermail/wine-devel/2017-January/115...