4 ms·

One big issue from what I read are installers for Windows software running in WINE. The installers are often still 32bit, and without 32bit support they won't w

One big issue from what I read are installers for Windows software running in WINE. The installers are often still 32bit, and without 32bit support they won't work anymore. So even if the actual Windows application is 64bit, you can't run it in WINE because you can't install it. This doesn't really surprise me, one big specialized software I used a while ago couldn't be installed under Windows 7 64bit because the installer still was 16bit. I don't think anyone wants to touch a still working installer unless they have to, so they stay behind in technology.

badsectoracula 7y ago
FWIW Wine can also install 32bit software with 16bit installers since it does support protected mode 16bit code (which is the vast majority of 16bit Windows code anyway). Also on modern 64bit Windows you can use https://github.com/otya128/winevdm/ https://github.com/otya128/winevdm/ to run some 16bit programs. It is hit and miss, but most 16bit installers work fine.
rvp-x 7y ago
Worth noting that removing 16bit support in windows is an enormous security win, because the DOS stuff relied on things that are really bad for security. 32-bit support is a lot more sustainable.
- asveikau 7y ago
  Citation needed. 16 bit code is fairly well isolated in NT-based Windows.
  - yegle 7y ago
    Wiki suggest 16bit of Address Space Layer Randomization can be bruteforced in minutes, citing source: Shacham, H.; Page, M.; Pfaff, B.; Goh, E.J.; Modadugu, N.; Boneh, D (2004). On the Effectiveness of Address-Space Randomization. 11th ACM conference on Computer and communications security. pp. 298–307.
    - badsectoracula 7y ago
      What sort of security critical software will run as a 16bit Windows program and be the target for an attack accessible from wherever those attacks enter the system?
    - asveikau 7y ago
      Nobody expects aslr from 16 bit legacy code with only 1mb of address space. I think you are describing 16 bits of randomization on a 32 or 64 bit process though. What I mean is that the virtualization of 16 bit code (using vm86) is isolated from a security perspective, it won't violate process boundaries or kernel security features like ACLs. I believe this was less true in 9x which might be where the confusion comes from.
- makomk 7y ago
  Dunno about on Windows, but the Linux kernel support for 16-bit code has lead to some nasty, subtle privilege escalation exploits due to the really gnarly processor state changes required.
  - masterchill 7y ago
    Didn't know Linux kernel had 16-bit support.
overgard 7y ago
To add to that, the reason these installers are 32 bit isn’t necessarily legacy or laziness. If you’re packaging your software to run on both 32 bit and 64 bit it makes sense to make your installer run on the lowest common denominator and install the appropriate version, as opposed to providing two installers and leaving it up to the user. So 32 bit is the obvious choice. On windows this isn’t a problem because Microsoft rarely drops support for things.
- buckminster 7y ago
  This is kind of the same reason 16-bit installers were a thing for NT software. In the mid 90s when NT ran on four different processor architectures all of the non-x86 platforms had emulation for 16-bit x86. So MS recommended that you bootstrap your install with a 16-bit process that checked it was running on a 32-bit platform (i.e. not 16-bit Windows) and then launched the appropriate 32-bit installer for the CPU.
markbnj 7y ago
It's been a few years since I wrote one but at least back then windows installers were an amazing mess. We used Wix as an abstraction on top of the underlying libraries (which at the time were still win32, not sure what's happened since). I'm not sure if any progress has been made since but it was a pretty painful experience, especially localization.
kurtisc 7y ago
Every Proton incompatibility I've faced so far has been something like this. e.g. it can't boot because the DRM doesn't work, or the paths don't resolve properly. If I can get to the options screen it's plain sailing.

badsectoracula 7y ago

FWIW Wine can also install 32bit software with 16bit installers since it does support protected mode 16bit code (which is the vast majority of 16bit Windows code anyway). Also on modern 64bit Windows you can use https://github.com/otya128/winevdm/ https://github.com/otya128/winevdm/ to run some 16bit programs. It is hit and miss, but most 16bit installers work fine.

rvp-x 7y ago

Worth noting that removing 16bit support in windows is an enormous security win, because the DOS stuff relied on things that are really bad for security. 32-bit support is a lot more sustainable.

asveikau 7y ago
Citation needed. 16 bit code is fairly well isolated in NT-based Windows.
- yegle 7y ago
  Wiki suggest 16bit of Address Space Layer Randomization can be bruteforced in minutes, citing source: Shacham, H.; Page, M.; Pfaff, B.; Goh, E.J.; Modadugu, N.; Boneh, D (2004). On the Effectiveness of Address-Space Randomization. 11th ACM conference on Computer and communications security. pp. 298–307.
  - badsectoracula 7y ago
    What sort of security critical software will run as a 16bit Windows program and be the target for an attack accessible from wherever those attacks enter the system?
  - asveikau 7y ago
    Nobody expects aslr from 16 bit legacy code with only 1mb of address space. I think you are describing 16 bits of randomization on a 32 or 64 bit process though. What I mean is that the virtualization of 16 bit code (using vm86) is isolated from a security perspective, it won't violate process boundaries or kernel security features like ACLs. I believe this was less true in 9x which might be where the confusion comes from.
makomk 7y ago
Dunno about on Windows, but the Linux kernel support for 16-bit code has lead to some nasty, subtle privilege escalation exploits due to the really gnarly processor state changes required.
- masterchill 7y ago
  Didn't know Linux kernel had 16-bit support.

overgard 7y ago

To add to that, the reason these installers are 32 bit isn’t necessarily legacy or laziness. If you’re packaging your software to run on both 32 bit and 64 bit it makes sense to make your installer run on the lowest common denominator and install the appropriate version, as opposed to providing two installers and leaving it up to the user. So 32 bit is the obvious choice. On windows this isn’t a problem because Microsoft rarely drops support for things.

buckminster 7y ago
This is kind of the same reason 16-bit installers were a thing for NT software. In the mid 90s when NT ran on four different processor architectures all of the non-x86 platforms had emulation for 16-bit x86. So MS recommended that you bootstrap your install with a 16-bit process that checked it was running on a 32-bit platform (i.e. not 16-bit Windows) and then launched the appropriate 32-bit installer for the CPU.

markbnj 7y ago

It's been a few years since I wrote one but at least back then windows installers were an amazing mess. We used Wix as an abstraction on top of the underlying libraries (which at the time were still win32, not sure what's happened since). I'm not sure if any progress has been made since but it was a pretty painful experience, especially localization.

kurtisc 7y ago

Every Proton incompatibility I've faced so far has been something like this. e.g. it can't boot because the DRM doesn't work, or the paths don't resolve properly. If I can get to the options screen it's plain sailing.