7 ms·

Hardly surprising. Your typical WINE user playing C&C will notice if an update in WINE breaks it, and report it to winehq. EA don't give two shits about legacy

by nly 5y ago

Hardly surprising. Your typical WINE user playing C&C will notice if an update in WINE breaks it, and report it to winehq. EA don't give two shits about legacy C&C games that aren't making them money.

bennysomething 5y ago
Can I run wine on windows then? Only semi joking!
- __s 5y ago
  Yes: https://www.reddit.com/r/bashonubuntuonwindows/comments/6joykc/running_wine_on_wsl https://www.reddit.com/r/bashonubuntuonwindows/comments/6joy... Give it time, WSL support for graphics is in preview: https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-a...
  - mwcampbell 5y ago
    I think it would be interesting to package up ReactOS [1], which shares a lot of code with Wine, as a VM that could be shipped with an application along with something like QEMU. If I'm not mistaken, QEMU supports virtualization through the Windows Hypervisor Platform and macOS's Hypervisor.framework. Could be a good way for GOG to sell old Windows games. [1]: https://reactos.org/ https://reactos.org/
    - Koshkin 5y ago
      Not to take away from ReactOS as a project, this somehow doesn’t make much sense to me, as WINE (and its spin-offs, like Valve’s Proton) is already good enough as a portable gaming platform.
      - mwcampbell 5y ago
        I was thinking in particular about the Wine on Windows use case. Running ReactOS in a VM seems a more direct route than running Wine in a Linux VM (e.g. via WSL 2). Edit: I also think it would have made a lot of sense for Valve to invest in getting ReactOS running on their Steam Deck hardware, so they could use that instead of Linux. They're clearly a Windows-first shop, and ReactOS is modeled on NT right down to the kernel. Having a Unix-like OS running underneath, when one really just wants to run Windows code, adds an extra translation layer and impedance mismatches that might even be user-visible.
        usrusr 5y ago
        About the ReactOS on Steam Deck bit: I'd suspect that this might be a bit too much for what looks like a fragile peace between Microsoft and Valve. Doing Deck on Linux is one thing (in the days of Linux on Azure it can't be much of a provocation), but ReactOS could still be too much I think. "If you want Windows, ask us for a good offer!" Technically Proton on Linux might be very similar (even the same code in key parts?), but on a subjective level, I could easily see one trigger a red line reaction the other would not.
        seba_dos1 5y ago
        You don't need a VM or WSL to run Wine, you can run it on Windows. Sometimes even WineD3D alone is enough to fix issues with old games. Also, Valve's interest in GNU/Linux is broader than just Deck.
        Koshkin 5y ago
        Actually, WINE works in WSL 1, too.
        LeFantome 5y ago
        WINE is Windows APIs running on the Linux kernel ( host OS kernel ). The Linux kernel is already high quality and high performance. ReactOS is Windows APIs running on the from-scratch ReactOS kernel that is not very good. The ReactOS project is not the source for most of the APIs a game is going to use. Many of the come from WINE. Using ReactOS instead of WINE on Linux makes little sense at this point. It would certainly be a lot more expense and time to create a commercial quality product. Most of the work creating API support to WINE / Proton is portable to ReactOS of the kernel ever gets there.
- hedgewitch 5y ago
  Not sure if this would help in this exact case, but I've used OTVDM to run some old games successfully. https://github.com/otya128/winevdm https://github.com/otya128/winevdm
- lmm 5y ago
  I actually did that and solved a real problem with it (being able to run the Riven installer on a newer windows), by building Wine under SFU/SUA (I don't know if that still exists or has been removed in favour of WSL) and running it against XMing32. I never got freetype working so all the text was monospace and overflowing the dialogue boxes, but it was enough to run basic programs.
wongarsu 5y ago
Microsoft used to be quite dedicated to this too. If you look at the leaked Windows XP source code you can find compatibility shims to ensure that older Versions of Quicken or Acrobat Reader or Settlers 3 still work. A "don't break userland" policy is part of the reason they became so popular in businesses. Since then times seem to have changed somewhat.
- stevefan1999 5y ago
  That changed because they have a major refactor starting from Windows 7. They have it up to the spec and not so much more ad-hoc behavior this time. To me it seems like cutting the compatibility arm is worth the price of having to keep a shitty, inconsistent behavior. Apple has nailed it so well (don't make it backward compatible) for the last decade afterall, since Apple realized one the internet is so much better and source code management (and repository, backup, disaster recovery) became more accessible so that the cost of port became much lower.
  - unicornfinder 5y ago
    To be fair though I think there's a happy medium. For a while I really loved Apple's approach of just not giving a damn about backwards compatibility but I have to say using Windows did make me realise just how wonderful it is not worrying about whether the software I want to use will work.
    - saagarjha 5y ago
      Apple ships hundreds of workarounds for specific apps.
    - stormbeta 5y ago
      Yeah - as a user, I specifically _don't_ like Apple's approach of breaking things all the time.
    - Pxtl 5y ago
      Let's not even start about Android's approach to backwards compatibility. There's a very long list of stuff I loved that no longer runs.
hedgewitch 5y ago
I think this is the wrong way to be looking at it. WINE is an open-source project that explicitly wants to run as much Windows software as accurately as possible on non-Windows systems. If something's broken, anyone can fix it. This isn't true for the proprietary software that is Windows and C&C, albeit C&C Remastered is partially source-available now, so that could improve matters somewhat.

by nly 5y ago

bennysomething 5y ago

Can I run wine on windows then? Only semi joking!

__s 5y ago
Yes: https://www.reddit.com/r/bashonubuntuonwindows/comments/6joykc/running_wine_on_wsl https://www.reddit.com/r/bashonubuntuonwindows/comments/6joy... Give it time, WSL support for graphics is in preview: https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-a...
- mwcampbell 5y ago
  I think it would be interesting to package up ReactOS [1], which shares a lot of code with Wine, as a VM that could be shipped with an application along with something like QEMU. If I'm not mistaken, QEMU supports virtualization through the Windows Hypervisor Platform and macOS's Hypervisor.framework. Could be a good way for GOG to sell old Windows games. [1]: https://reactos.org/ https://reactos.org/
  - Koshkin 5y ago
    Not to take away from ReactOS as a project, this somehow doesn’t make much sense to me, as WINE (and its spin-offs, like Valve’s Proton) is already good enough as a portable gaming platform.
    - mwcampbell 5y ago
      I was thinking in particular about the Wine on Windows use case. Running ReactOS in a VM seems a more direct route than running Wine in a Linux VM (e.g. via WSL 2). Edit: I also think it would have made a lot of sense for Valve to invest in getting ReactOS running on their Steam Deck hardware, so they could use that instead of Linux. They're clearly a Windows-first shop, and ReactOS is modeled on NT right down to the kernel. Having a Unix-like OS running underneath, when one really just wants to run Windows code, adds an extra translation layer and impedance mismatches that might even be user-visible.
      - usrusr 5y ago
        About the ReactOS on Steam Deck bit: I'd suspect that this might be a bit too much for what looks like a fragile peace between Microsoft and Valve. Doing Deck on Linux is one thing (in the days of Linux on Azure it can't be much of a provocation), but ReactOS could still be too much I think. "If you want Windows, ask us for a good offer!" Technically Proton on Linux might be very similar (even the same code in key parts?), but on a subjective level, I could easily see one trigger a red line reaction the other would not.
      - seba_dos1 5y ago
        You don't need a VM or WSL to run Wine, you can run it on Windows. Sometimes even WineD3D alone is enough to fix issues with old games. Also, Valve's interest in GNU/Linux is broader than just Deck.
      - Koshkin 5y ago
        Actually, WINE works in WSL 1, too.
      - LeFantome 5y ago
        WINE is Windows APIs running on the Linux kernel ( host OS kernel ). The Linux kernel is already high quality and high performance. ReactOS is Windows APIs running on the from-scratch ReactOS kernel that is not very good. The ReactOS project is not the source for most of the APIs a game is going to use. Many of the come from WINE. Using ReactOS instead of WINE on Linux makes little sense at this point. It would certainly be a lot more expense and time to create a commercial quality product. Most of the work creating API support to WINE / Proton is portable to ReactOS of the kernel ever gets there.
hedgewitch 5y ago
Not sure if this would help in this exact case, but I've used OTVDM to run some old games successfully. https://github.com/otya128/winevdm https://github.com/otya128/winevdm
lmm 5y ago
I actually did that and solved a real problem with it (being able to run the Riven installer on a newer windows), by building Wine under SFU/SUA (I don't know if that still exists or has been removed in favour of WSL) and running it against XMing32. I never got freetype working so all the text was monospace and overflowing the dialogue boxes, but it was enough to run basic programs.

wongarsu 5y ago

Microsoft used to be quite dedicated to this too. If you look at the leaked Windows XP source code you can find compatibility shims to ensure that older Versions of Quicken or Acrobat Reader or Settlers 3 still work. A "don't break userland" policy is part of the reason they became so popular in businesses. Since then times seem to have changed somewhat.

stevefan1999 5y ago
That changed because they have a major refactor starting from Windows 7. They have it up to the spec and not so much more ad-hoc behavior this time. To me it seems like cutting the compatibility arm is worth the price of having to keep a shitty, inconsistent behavior. Apple has nailed it so well (don't make it backward compatible) for the last decade afterall, since Apple realized one the internet is so much better and source code management (and repository, backup, disaster recovery) became more accessible so that the cost of port became much lower.
- unicornfinder 5y ago
  To be fair though I think there's a happy medium. For a while I really loved Apple's approach of just not giving a damn about backwards compatibility but I have to say using Windows did make me realise just how wonderful it is not worrying about whether the software I want to use will work.
  - saagarjha 5y ago
    Apple ships hundreds of workarounds for specific apps.
  - stormbeta 5y ago
    Yeah - as a user, I specifically _don't_ like Apple's approach of breaking things all the time.
  - Pxtl 5y ago
    Let's not even start about Android's approach to backwards compatibility. There's a very long list of stuff I loved that no longer runs.

hedgewitch 5y ago

I think this is the wrong way to be looking at it. WINE is an open-source project that explicitly wants to run as much Windows software as accurately as possible on non-Windows systems. If something's broken, anyone can fix it. This isn't true for the proprietary software that is Windows and C&C, albeit C&C Remastered is partially source-available now, so that could improve matters somewhat.