4 ms·

That seems like a pretty bizarre plan to me. The 32-bit emulator is going to be way bigger than the code that handles IA-32e mode. I think it's more likely that

That seems like a pretty bizarre plan to me. The 32-bit emulator is going to be way bigger than the code that handles IA-32e mode. I think it's more likely that they'll reduce the amount of system libraries for which they ship 32-bit variants and/or require separate downloads of them. That's the real cost of keeping 32-bit support, and an emulator doesn't help on that front at all.

MBCook 9y ago
It seems odd, but I wonder if it would be useful in some way. At that point you could buy chips that have no 32 bit mode at all. Or you could MAKE them. Or maybe you could make ARM chips and run a Rosetta like thing to run the 64-bit code, but since 64-bit x86 is so much cleaner it's not much of a problem compared to the whole 32-bit mess. This is all pure speculation. I thought the way they phrased things with a little odd. It may simply be that they don't intend to update any libraries in 32 bit mode so stuff will just stop working as libraries change. It may be everything's going to start going through some layer that thinks 32-bit calls into 64-bit calls thus possibly reducing performance. I don't know… I just feel like that statement meant something interesting and I am coming up with fun guesses.
- mikeash 9y ago
  My guess is that the "compromise" will be some fugly alert that pops up when you run a 32-bit app, saying that it's degrading system performance and you should update it and be ashamed of yourself. This is what iOS currently does, so there's precedent.
- wolfgke 9y ago
  > but since 64-bit x86 is so much cleaner it's not much of a problem compared to the whole 32-bit mess. I would not call x86-64 "cleaner" than x86-32. In many senses it is much more messy than x86-32.
  - MBCook 9y ago
    I remember people saying that, but I don't have experience with it myself. I'll take your word for it. They may have been referring to the fact that 64-bit runs in 65-but only, no choice to drop into/out of 16-bit, etc.
    - wolfgke 9y ago
      > They may have been referring to the fact that 64-bit runs in 65-but only, no choice to drop into/out of 16-bit, etc Even in 64 bit mode it is possible to drop into 16 bit (protected) mode (code) if one wants to. What does not work is dropping into Virtual 8086 mode. GNU/Linux never supported 16 bit code. For Windows it would be possible in principle (and it even would IMHO sense to support this feature on 64 bit versions of Windows). On > https://news.ycombinator.com/item?id=14246521 https://news.ycombinator.com/item?id=14246521 I wrote something about this topic. TLDR: 64 bit Windows uses 32 bit handles, which will cause problems with 16 bit applications. But there are also people on HN who stated the opinion that while this makes implementing support for 16 bit applications on 64 bit Windows harder for Microsoft, it would have been far from impossible, thus this technical reason is a mere convenient pretense not to implement this feature.
      - my123 9y ago
        Actually, NTVDM on 64-bit Windows is implemented as a prototype - and it works.

MBCook 9y ago

It seems odd, but I wonder if it would be useful in some way. At that point you could buy chips that have no 32 bit mode at all. Or you could MAKE them. Or maybe you could make ARM chips and run a Rosetta like thing to run the 64-bit code, but since 64-bit x86 is so much cleaner it's not much of a problem compared to the whole 32-bit mess. This is all pure speculation. I thought the way they phrased things with a little odd. It may simply be that they don't intend to update any libraries in 32 bit mode so stuff will just stop working as libraries change. It may be everything's going to start going through some layer that thinks 32-bit calls into 64-bit calls thus possibly reducing performance. I don't know… I just feel like that statement meant something interesting and I am coming up with fun guesses.

mikeash 9y ago
My guess is that the "compromise" will be some fugly alert that pops up when you run a 32-bit app, saying that it's degrading system performance and you should update it and be ashamed of yourself. This is what iOS currently does, so there's precedent.
wolfgke 9y ago
> but since 64-bit x86 is so much cleaner it's not much of a problem compared to the whole 32-bit mess. I would not call x86-64 "cleaner" than x86-32. In many senses it is much more messy than x86-32.
- MBCook 9y ago
  I remember people saying that, but I don't have experience with it myself. I'll take your word for it. They may have been referring to the fact that 64-bit runs in 65-but only, no choice to drop into/out of 16-bit, etc.
  - wolfgke 9y ago
    > They may have been referring to the fact that 64-bit runs in 65-but only, no choice to drop into/out of 16-bit, etc Even in 64 bit mode it is possible to drop into 16 bit (protected) mode (code) if one wants to. What does not work is dropping into Virtual 8086 mode. GNU/Linux never supported 16 bit code. For Windows it would be possible in principle (and it even would IMHO sense to support this feature on 64 bit versions of Windows). On > https://news.ycombinator.com/item?id=14246521 https://news.ycombinator.com/item?id=14246521 I wrote something about this topic. TLDR: 64 bit Windows uses 32 bit handles, which will cause problems with 16 bit applications. But there are also people on HN who stated the opinion that while this makes implementing support for 16 bit applications on 64 bit Windows harder for Microsoft, it would have been far from impossible, thus this technical reason is a mere convenient pretense not to implement this feature.
    - my123 9y ago
      Actually, NTVDM on 64-bit Windows is implemented as a prototype - and it works.