Hacker News Reader

Comment by chocolatebunny | Hacker News Reader

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.

View on HN

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.

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

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

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.

Reply on news.ycombinator.com