Wine 1.9.13 Continues Working On Shader Model 5, Direct3D Command Stream

[phoronix]

Phoronix: Wine 1.9.13 Continues Working On Shader Model 5, Direct3D Command Stream

The Wine camp is out with their latest bi-weekly development release where they have continued focusing on some of the same work items they've been trying to address the past few releases...

http://www.phoronix.com/scan.php?page=news_item&px=Wine-1.9.13-Released

[eydee]

will the wine work ever be included and automated in the nativ-linux-steam clind? to support windows only games in steambox and linux in generall?

Probably not, for 3 reasons:

1. Valve provides official "support" for Steam. Wine is too complex, too unstable and ever-changing to include official support for it. While a company built completely around it can do it (Codeweavers), Valve has no manpower for it and has a lot more to do.

2. Licensing, Wine is LGPL software, including any portion in the client would have serious consequences for Steam licensing and source code.

3. DRM, Windows games in Steam are usually built using Steam DRM and require a running Windows client logged into an account that owns the game. While making a windows-linux bridge may be technically possible (there's even an open source project attempting to do that), this is once again an unstable, unreliable thing that cannot have official support. What if Linus decides to change something on Linux side that breaks everything?

[boxie]

Just idly pondering - is it possible to flatpack wine+installed windows app?

i.e. distribute a windows app, on linux and "it just works" with no need to fiddle around?

[Mystro256]

Just idly pondering - is it possible to flatpack wine+installed windows app?

i.e. distribute a windows app, on linux and "it just works" with no need to fiddle around?

In theory yes, but I would think it would need to make a copy of the wine prefix into your home directory (or wherever flatpack puts the user specific config files) before running to avoid things being owned by root and thus readonly.

So distribute a copy of wine and libs, compressed archive of a preconfigured prefix, then a script that checks if prefix was copied, if not, extract it the archive, then execute the binary in extracted prefix with bundled wine.

That's my best guess. There were some games distributed with crossover in humble bundle with deb's and rpm's (LIMBO I believe?), maybe we can look at that for an example.

[Chewi]

Maybe you guys aren't aware of SteamBridge. It kinda died though.

[adler187]

Maybe you guys aren't aware of SteamBridge. It kinda died though.

That only makes it so you don't need to start the Windows Steam client under WINE (which would be nice, all things considered). It still requires WINE to actually run the game.

It would be nice to have Valve integrate SteamBridge, since right now I have to launch both clients to be able to play all the games I want and whenever I launch the second one, it seems to "disconnect" the first one (still online, but can't download anything or launch games which require connecting). I have to disconnect and reconnect the Steam client when I want to switch between them.

[Mystro256]

Maybe you guys aren't aware of SteamBridge. It kinda died though.

Oh wow, I didn't know this existed... I'm going to go take a look at the source right now.

Having both Steam and a wine Steam is annoying, this would make things easier.

[Denon]

Just idly pondering - is it possible to flatpack wine+installed windows app?

i.e. distribute a windows app, on linux and "it just works" with no need to fiddle around?

I think it is better to make your windows app work flawless with wine.
I'm using HeidiSQL for years with MSSQL, MYSQL and PostgreSQL on linux.

Quote: HeidiSQL runs fine on Windows (XP, Vista, 7, 8, 10) and - with Wine - on any Linux and newer MacOS X versions.

[starshipeleven]

Just idly pondering - is it possible to flatpack wine+installed windows app?

i.e. distribute a windows app, on linux and "it just works" with no need to fiddle around?

Afaik yes, PlayOnLinux does already use different pre-configured/hacked Wine runtimes to run stuff (to use the wine that works best with that application, or to avoid regressions)

In theory yes, but I would think it would need to make a copy of the wine prefix into your home directory (or wherever flatpack puts the user specific config files) before running to avoid things being owned by root and thus readonly.

wine can be instructed to go read wineprefix from other places with an environmental variable. I suspect this is what PlayOnLinux does already, see above.

faq link
https://wiki.winehq.org/FAQ#Can_I_st....7E.2F.wine.3F

[Mystro256]

wine can be instructed to go read wineprefix from other places with an environmental variable. I suspect this is what PlayOnLinux does already, see above.

Indeed, I'm aware of that, but the issue is that if root owns the folder, it may cause permission issues for write access of configuration files. I can imagine that if a package had a prebuilt prefix, it would probably have 755/644 permissions on it's files.

I guess if the wine is configured to treat the home folder as "My Documents" and the program is adapted to write all configuration into there, if it doesn't already, it wouldn't be an issue, and you wouldn't need to copy the prefix or use 777/666 permissions.