4 ms·

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

by leeter 9y ago

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.

chocolatebunny 9y ago
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.
- eesmith 9y ago
  I know nothing about the topic. I'll only point out that https://bugs.winehq.org/show_bug.cgi?id=36664 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 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 ;-)
  - leeter 9y ago
    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.
    - yjftsjthsd-h 9y ago
      > 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.
      - monocasa 9y ago
        Atoms have been 64bit since 2010.
        TheKitchenSinc 9y ago
        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.
    - doesnt_know 9y ago
      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=8002 https://www.microsoft.com/en-nz/download/details.aspx?id=800... [2] https://en.wikipedia.org/wiki/Windows_Virtual_PC https://en.wikipedia.org/wiki/Windows_Virtual_PC
- leeter 9y ago
  Inferences from https://blogs.msdn.microsoft.com/oldnewthing/20081020-00/?p=20523 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.
- dfox 9y ago
  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.
monocasa 9y ago
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 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.
dfox 9y ago
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.
- JdeBP 9y ago
  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.

by leeter 9y ago

chocolatebunny 9y ago

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.

eesmith 9y ago
I know nothing about the topic. I'll only point out that https://bugs.winehq.org/show_bug.cgi?id=36664 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 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 ;-)
- leeter 9y ago
  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.
  - yjftsjthsd-h 9y ago
    > 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.
    - monocasa 9y ago
      Atoms have been 64bit since 2010.
      - TheKitchenSinc 9y ago
        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.
  - doesnt_know 9y ago
    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=8002 https://www.microsoft.com/en-nz/download/details.aspx?id=800... [2] https://en.wikipedia.org/wiki/Windows_Virtual_PC https://en.wikipedia.org/wiki/Windows_Virtual_PC
leeter 9y ago
Inferences from https://blogs.msdn.microsoft.com/oldnewthing/20081020-00/?p=20523 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.
dfox 9y ago
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.

monocasa 9y ago

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

dfox 9y ago

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.

JdeBP 9y ago
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.