4 ms·

But that's one thing to maintain. With every game you port to Linux, you have one more thing to maintain and update to whatever shit breaks it on the userspace

But that's one thing to maintain. With every game you port to Linux, you have one more thing to maintain and update to whatever shit breaks it on the userspace side 3 years from now. That's O(n) while maintaining wine is O(1). Yes this is oversimplified as wine is more complex than most games, and also there will be regressions and stuff as you can't test every Windows game ever every time you change something in wine, but still.

nobodyandproud 3y ago
Then maintaining Wine is more like O(lg n).
shmerl 3y ago
It would be nice actually to have a Linux own compatibility layer similar to Wine, that preserves old APIs same way Wine does for Windows ones. But so far no one is really planning to make such.
AshamedCaptain 3y ago
This is a bad analogy, because Wine also has dependencies on various "Linux APIs". So technically if you maintain Wine you are also maintaining all the libraries Wine depends on, and so on. It would probably be easier for a game to just target the libraries Wine depends on, or even better, some smaller and more "least common denominator" abstraction layer (e.g. think libao for audio) sitting on top of the same libraries. While you can see Wine as de facto providing such an abstraction layer (e.g. you can switch audio drivers, video drivers, etc. in Wine), they are forced to expose an API whose evolution they don't control (Win32), which is something that long-term is doomed to fail.
- shmerl 3y ago
  The problem is maintaining long term compatibility which is what Wine is doing. Native Linux ABIs can break (soname changes and etc.) and unless someone keeps translating old ones into newer ones, it won't work. I.e. something Wine-like for Linux ABIs themselves that games use would be great.
  - shmerl 3y ago
    The good example of that idea is translating older SDL into newer one.
- iforgotpassword 3y ago
  > So technically if you maintain Wine you are also maintaining all the libraries Wine depends on, and so on. You are confirming that it is a good analogy. If some lib changes its ABI, in the wine case you need to fix it once: in wine. If you have 2000 Linux ports of games, you need to fix it 2000 times. Your libao example is exactly the problem we currently have on Linux. Nothing is really stable, api and abi breakages happen almost everywhere. You can be careful and pick projects that promise to never break abi compat only to still get disappointed by at least one eventually. And while win32 is not under your control regarding new features, it is by far the most stable userspace api and abi in existence. See also: https://news.ycombinator.com/item?id=32471624 https://news.ycombinator.com/item?id=32471624 (article and comments)
  - shmerl 3y ago
    So something like Wine can be developed for Linux with focus on gaming.

nobodyandproud 3y ago

Then maintaining Wine is more like O(lg n).

shmerl 3y ago

It would be nice actually to have a Linux own compatibility layer similar to Wine, that preserves old APIs same way Wine does for Windows ones. But so far no one is really planning to make such.

AshamedCaptain 3y ago

This is a bad analogy, because Wine also has dependencies on various "Linux APIs". So technically if you maintain Wine you are also maintaining all the libraries Wine depends on, and so on. It would probably be easier for a game to just target the libraries Wine depends on, or even better, some smaller and more "least common denominator" abstraction layer (e.g. think libao for audio) sitting on top of the same libraries. While you can see Wine as de facto providing such an abstraction layer (e.g. you can switch audio drivers, video drivers, etc. in Wine), they are forced to expose an API whose evolution they don't control (Win32), which is something that long-term is doomed to fail.

shmerl 3y ago
The problem is maintaining long term compatibility which is what Wine is doing. Native Linux ABIs can break (soname changes and etc.) and unless someone keeps translating old ones into newer ones, it won't work. I.e. something Wine-like for Linux ABIs themselves that games use would be great.
- shmerl 3y ago
  The good example of that idea is translating older SDL into newer one.
iforgotpassword 3y ago
> So technically if you maintain Wine you are also maintaining all the libraries Wine depends on, and so on. You are confirming that it is a good analogy. If some lib changes its ABI, in the wine case you need to fix it once: in wine. If you have 2000 Linux ports of games, you need to fix it 2000 times. Your libao example is exactly the problem we currently have on Linux. Nothing is really stable, api and abi breakages happen almost everywhere. You can be careful and pick projects that promise to never break abi compat only to still get disappointed by at least one eventually. And while win32 is not under your control regarding new features, it is by far the most stable userspace api and abi in existence. See also: https://news.ycombinator.com/item?id=32471624 https://news.ycombinator.com/item?id=32471624 (article and comments)
- shmerl 3y ago
  So something like Wine can be developed for Linux with focus on gaming.