Hacker News Reader

Comment by fabian2k | Hacker News Reader

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.

View on HN

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.

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.

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/ to run some 16bit programs. It is hit and miss, but most 16bit installers work fine.

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.

Citation needed. 16 bit code is fairly well isolated in NT-based Windows.

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.

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?

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.

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.

Didn't know Linux kernel had 16-bit support.

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.

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.

Reply on news.ycombinator.com