4 ms·

'Recently' meaning about the past 10 years or so. Windows 8 broke a lot of software for me that runs in Wine.

justsomehnguy 4y ago
In 2016 I was asked to install some software on a WinSvr2012R2. I was forced to install it on my Win8.1 tablet first, because the 16-bit stub didn't work on x64 2012R2. After install I copied the files to the server and the software brazenly showed "XXX for Windows 95" in the Help->About. On a 2012R2 x64 server. In the year 2016. There was (and is) a lot of shit which developers did wrong (including writing directly to C:\WINDOWS). Yet if they did stick to the basics (GDI output and so on) that worked for decades. I abandoned Corel PhotoPaint 3 (with (c) 1992) only after moving to Vista in 2008.
- BlueTemplar 4y ago
  Yeah, I have Windows 98 in a VirtualBox for those 32 bit programs using a 16 bit installer...
  - justsomehnguy 4y ago
    Hah! That's even better (and you can have snapshots and all benefits of VM), but in case you don't know - for InstallShield stubs there are replacements which allows the installer to run on WOW64 systems.
Arainach 4y ago
[[Citation Needed]]. Other than 16-bit software on 64-bit Windows, do you have an example?
- monocasa 4y ago
  A lot of games, Red Alert 2 off the top of my head. Never got it running even in compatibility mode and changing the bit depth.
  - kgeist 4y ago
    According to Raymond Chen, this usually happens when software relies on undocumented APIs or undefined behavior. When Windows removes undocumented APIs or changes behavior not covered by the documentation, such apps break and people blame Microsoft. For example, I remember one app used to programmatically find some kind of "Print" menu in Windows' desktop environment and call it to implement printing functionality. When Microsoft changed the UI of the desktop (shuffled the menu items around) the app broke and people immediately blamed Microsoft, even though the app is to blame because the exact location of the menu item was never supposed to be a public contract. If an app is a widely used one, Microsoft usually used to create "shims" which detected funky behavior like that and corrected it to make the app work again. I think they don't do it anymore after Windows 8, that's why apps started breaking more frequently.
    - rcoveson 4y ago
      If your plan is to maintain decades of backwards compatibility with software from thousands of third parties, it's going to involve maintaining some originally-undocumented behaviors that people exploited. That's what the wine developers got themselves into willingly, and it's what the Windows devs are increasingly shirking.
      - lozenge 4y ago
        It's a question of priorities. Microsoft must have realised these edge cases were slowing development down and how many people really want to run a game or a CD burner software from 1998? Of course, this could all have been avoided with a proper universally understood spec like POSIX but it's too late for that now. (And POSIX never had graphics or sound support, which shows how big that project would be, with the churn of the PC hardware from 2D to 3D &etc) The hardware is also starting to protest - no way to run 16 bit instructions in x86_64 mode on a 64 bit processor.
        monocasa 4y ago
        You can run 16 bit code in long mode just fine. It's just a different GDT entry like 32 bit code is. Windows didn't cut 16 but mode because of the processor ut because they took the opportunity to increase the max HANDLE table size greater than 16 bit code can address.

In 2016 I was asked to install some software on a WinSvr2012R2. I was forced to install it on my Win8.1 tablet first, because the 16-bit stub didn't work on x64 2012R2. After install I copied the files to the server and the software brazenly showed "XXX for Windows 95" in the Help->About. On a 2012R2 x64 server. In the year 2016. There was (and is) a lot of shit which developers did wrong (including writing directly to C:\WINDOWS). Yet if they did stick to the basics (GDI output and so on) that worked for decades. I abandoned Corel PhotoPaint 3 (with (c) 1992) only after moving to Vista in 2008.

BlueTemplar 4y ago
Yeah, I have Windows 98 in a VirtualBox for those 32 bit programs using a 16 bit installer...
- justsomehnguy 4y ago
  Hah! That's even better (and you can have snapshots and all benefits of VM), but in case you don't know - for InstallShield stubs there are replacements which allows the installer to run on WOW64 systems.

Arainach 4y ago

[[Citation Needed]]. Other than 16-bit software on 64-bit Windows, do you have an example?

monocasa 4y ago
A lot of games, Red Alert 2 off the top of my head. Never got it running even in compatibility mode and changing the bit depth.
- kgeist 4y ago
  According to Raymond Chen, this usually happens when software relies on undocumented APIs or undefined behavior. When Windows removes undocumented APIs or changes behavior not covered by the documentation, such apps break and people blame Microsoft. For example, I remember one app used to programmatically find some kind of "Print" menu in Windows' desktop environment and call it to implement printing functionality. When Microsoft changed the UI of the desktop (shuffled the menu items around) the app broke and people immediately blamed Microsoft, even though the app is to blame because the exact location of the menu item was never supposed to be a public contract. If an app is a widely used one, Microsoft usually used to create "shims" which detected funky behavior like that and corrected it to make the app work again. I think they don't do it anymore after Windows 8, that's why apps started breaking more frequently.
  - rcoveson 4y ago
    If your plan is to maintain decades of backwards compatibility with software from thousands of third parties, it's going to involve maintaining some originally-undocumented behaviors that people exploited. That's what the wine developers got themselves into willingly, and it's what the Windows devs are increasingly shirking.
    - lozenge 4y ago
      It's a question of priorities. Microsoft must have realised these edge cases were slowing development down and how many people really want to run a game or a CD burner software from 1998? Of course, this could all have been avoided with a proper universally understood spec like POSIX but it's too late for that now. (And POSIX never had graphics or sound support, which shows how big that project would be, with the churn of the PC hardware from 2D to 3D &etc) The hardware is also starting to protest - no way to run 16 bit instructions in x86_64 mode on a 64 bit processor.
      - monocasa 4y ago
        You can run 16 bit code in long mode just fine. It's just a different GDT entry like 32 bit code is. Windows didn't cut 16 but mode because of the processor ut because they took the opportunity to increase the max HANDLE table size greater than 16 bit code can address.