Wine 3.11 Brings Debugging Support For WoW64 Processes, Better Reporting Of HT CPUs

[Weasel]

I'm just pointing out that even reinstalling applications it's not that bad. Also because you need to install the distro anyway. For the sake of giving the whole picture.

It can be very bad, what if you have 1000 applications? You can't even place them on a USB stick and share them between your PCs without installing on each of them. Even worse: assuming you install them only as you need them, what if your internet connection is gone when you need to do that? It's still relying on someone else (package maintainer, etc) and I want to be in control of my own life.

So Wine it is.

I don't disagree with this, but I'll just say that in my experience the only applications on Linux that do that consistently are web browsers. I've never had such issues with updates of Libreoffice, Okular, Kwrite or notepad++ (both linux and windows version), LibreCAD, uGet and Krita, which is what I use.
Other applications I use rarely can be updated all they want, I don't remember how to use them anyway and I have to guess from their GUI every time I open them. But I've never seen massive changes in open applications.

It's not about whether they do it or not. It's about the fact that they can do it and it's out of your control. I don't like to rely on someone else and try to keep it minimally, as everyone should. If the new update is good, then sure go ahead and update, you can do that with Wine portable apps too you know. But what IF it's bad? You have no "insurance" on Linux.

But I do agree it's far more common on Windows apps to revamp the stupid UI, thankfully old versions are just as functionality as they were before in 99.9% of cases and they can run just fine on Windows or Wine, so I don't mind "Windows-only apps that revamp UI every major version".

Sometimes I even keep two versions or more of the same app and use them both!

I mean, "Almost everything that runs equally or almost as good as the native alternative (obviously, also those which have no native alternative in the first place)." Has superlatives but what is this "almost everything" actually? Alone it would look like you said most Windows applications. But just after it there is the caveat "that runs equally or almost as good as the native alternative", which again looks good as it seems at first read like you said most windows applications run as good as native, but if someone reads it properly it actually means you run only the applications that run well, which again tells us nothing about either wine or your favourite applications run through it.

Huh?

I'll short-hand it to: "I use Wine for almost every app that runs as good as the native alternative" (though it's less true, sometimes I tolerate small insignificant hiccups, clearly it's my own metric). I said "almost" because there are exceptions, especially those dealing with Linux quirks (filesystem-specific stuff or permissions and the like).

For example, I use Total Commander (best file manager, period!), but sometimes I have to resort to Linux alternative when dealing with some Linux quirks and permissions (and I don't want to use the terminal). So "almost everything", because even though TC runs well under Wine, it can't do some of that.

In context, with the question posed, it meant the same thing, but it was more detailed before.

[Weasel]

You can do the same thing with flatpak, zeroinstall, nix/guix in home directory. There is a catch the ones I just list don't explode and fail due to copy protection or applications optimising to cpu/gpu on install as some windows applications do. Yes since I do support with wine I do get uses coming to me complain that their programs have failed when they have done exactly what you said and having to tell the to reinstall those applications. Of course with my background I know they would not be having that problem if they had used on of the Linux Distribution neutral solutions that are truly designed to be distribution neutral. Wine is not designed to be truly portable.

Really this has been some of your failure with me I guess. You have never really done portable applications on Linux. I have done that quite a bit over the years.

Flatpak is not portable though, it's a semi-VM (or container like LXC). It's like shipping the entire OS (minus kernel) with the app, which is more like a Live CD than a portable app. However I did mention that flatpak *may* change this situation if it's not too bloated (Wine is only ~100MB-200MB squashfs'd, depending on compression etc). But for now, Wine it is.

[oiaohm]

Flatpak is not portable though, it's a semi-VM (or container like LXC). It's like shipping the entire OS (minus kernel) with the app, which is more like a Live CD than a portable app. However I did mention that flatpak *may* change this situation if it's not too bloated (Wine is only ~100MB-200MB squashfs'd, depending on compression etc). But for now, Wine it is.

Wine program made distribution portable with everything it uses kiss good by to 8G of harddrive space. Flatpak executable with addons like bubblewrap can be made portable at the cost of only 20megs with only dependency being modern enough kernel with required features turn on(basically any distribution running systemd) and setting permissions to use those feature. Hope with user namespace feature being worked on that in future the permissions will not be required. Please note I have been doing portable versions of programs for a very long time. Wine does reach out to a lot of libraries and other parts.

Wine WINEPREFIX is not design to be portable and wine it self is absolutely not designed to be portable between distributions. Even if you just reduce wine down to just the ABI unstable stuff you still cross 1G of disc space required. There is a lot stuff wine does in background to prep stuff up just in case applications wish to look that up. That prep stuff ends up with insane number of dependancies and some of the stuff is like 1 in 1000 applications even need to know about it. Basically wine is a absolutely horrible solution for portable.

[Weasel]

Wine program made distribution portable with everything it uses kiss good by to 8G of harddrive space. Flatpak executable with addons like bubblewrap can be made portable at the cost of only 20megs with only dependency being modern enough kernel with required features turn on(basically any distribution running systemd) and setting permissions to use those feature. Hope with user namespace feature being worked on that in future the permissions will not be required. Please note I have been doing portable versions of programs for a very long time. Wine does reach out to a lot of libraries and other parts.

Wine WINEPREFIX is not design to be portable and wine it self is absolutely not designed to be portable between distributions. Even if you just reduce wine down to just the ABI unstable stuff you still cross 1G of disc space required. There is a lot stuff wine does in background to prep stuff up just in case applications wish to look that up. That prep stuff ends up with insane number of dependancies and some of the stuff is like 1 in 1000 applications even need to know about it. Basically wine is a absolutely horrible solution for portable.

You misunderstood what I meant. Wine has to be installed on the system, yes, but not the applications. The applications are portable (which run in Wine), not Wine itself. I consider Wine "part of the system" just like the other userland libraries, you know...

Since I compile Wine often anyways, I already have it installed on all my PCs, because I would use it *anyway* even without the portable apps (you know, for Windows-only apps), so to me it can be considered "installed". Even so, it's still much better to compile (or install) just 1 package (Wine) than to install 100 different ones for each app. The beauty with Wine is that it's one package so it's one thing to compile or install, and then all of your apps work (that work in Wine obviously).

Of course Wine itself is not portable, that would need something like winepak. But I'm not doing that.

[ssokolow]

You misunderstood what I meant. Wine has to be installed on the system, yes, but not the applications. The applications are portable (which run in Wine), not Wine itself. I consider Wine "part of the system" just like the other userland libraries, you know...

Since I compile Wine often anyways, I already have it installed on all my PCs, because I would use it *anyway* even without the portable apps (you know, for Windows-only apps), so to me it can be considered "installed". Even so, it's still much better to compile (or install) just 1 package (Wine) than to install 100 different ones for each app. The beauty with Wine is that it's one package so it's one thing to compile or install, and then all of your apps work (that work in Wine obviously).

Of course Wine itself is not portable, that would need something like winepak. But I'm not doing that.

While I sympathize, Wine gets to be an annoyance on that front if your application loadout varies over time because you either need to trust the application uninstallers or use multiple WINEPREFIXes... and, as I can attest, if you've got multiple WINEPREFIXES, the boilerplate adds up even before you factor in that some applications may still require winetricks. (Which means writing a script to hardlink duplicate files and then accounting for the complexity that adds to migrating or backing up your WINEPREFIXes without converting the hardlinks back to duplicated files and causing the size to explode.)

[oiaohm]

You misunderstood what I meant. Wine has to be installed on the system, yes, but not the applications. The applications are portable (which run in Wine), not Wine itself. I consider Wine "part of the system" just like the other userland libraries, you know...

Since I compile Wine often anyways, I already have it installed on all my PCs, because I would use it *anyway* even without the portable apps (you know, for Windows-only apps), so to me it can be considered "installed". Even so, it's still much better to compile (or install) just 1 package (Wine) than to install 100 different ones for each app. The beauty with Wine is that it's one package so it's one thing to compile or install, and then all of your apps work (that work in Wine obviously).

Of course Wine itself is not portable, that would need something like winepak. But I'm not doing that.

There are specialist portable versions of windows applications for a reason. If you choose random applications soon or latter you will hit one that does not work right. And as ssokolow states wine with multiple wineprefixs starts exploding in size between multi users. Wine WINEPREFIX are not designed to be shareable between users. appimage and flatpak can be.

Flatpak is smaller install size to have installed and you can back up the system wide ostree and when you run flatpak it remakes any of the missing desktop intergration.

If you have the appimage service installed it also remake any of the desktop integration and appimage if made following advice work without service installed. https://appimage.github.io/apps/ Yes over 300 applications are shipped this way.

Then you have Nix where you can copy the Nix directory system to system with the package management and have it all work.

Please note all these can be shared between users where wine cannot be. You don't have user account bloat you don't have user vs user conflicts.

Nix and flatpak are all nice on disc usage if you can use them over using wine. In fact Nix and Flatpak with their storage formats contain auto deduplication. So only 1 copy of libraries. You have to work very hard to bring wine up to the same level as Nix or Flatpak. Appimage is about as bad as a wine solution on disc usage.

Also note wine prefixes are not promised to remain working when you change wine versions either. As this is treated the same as copying application to a new install of windows. So if application is not portable and it in wine and you transport it to a different wine version it may completely break.

Reality wine as a solution does not work. Only those who have never really used it for long enough suggest wine as solution. Between Nix, Appimage and flatpak its not too hard to make something that is properly portable or at least reasonably portable for the Linux desktop and be way more reliable than the wine solution.

[theriddick]

45294 64-bit Mod Organizer 2.1.2 dev6-Silarn-prerelease fails to load 'usvfs_x64.dll', needs 'ntdll.RtlReleaseRelativeName'

Sadly this does not fix the usvfs system fully allowing it to mount files correctly. Its like 99% of the way there but something is missing. Maybe next time.

[Weasel]

While I sympathize, Wine gets to be an annoyance on that front if your application loadout varies over time because you either need to trust the application uninstallers or use multiple WINEPREFIXes... and, as I can attest, if you've got multiple WINEPREFIXES, the boilerplate adds up even before you factor in that some applications may still require winetricks. (Which means writing a script to hardlink duplicate files and then accounting for the complexity that adds to migrating or backing up your WINEPREFIXes without converting the hardlinks back to duplicated files and causing the size to explode.)

You can squashfs the WINEPREFIX itself along with Wine and use overlayfs and they will share the base... (just use symlinks to link to the squashfs's windows dir) of course after installing some essential things via winetricks (e.g. msvcrt libs) but not more than that.

And for portable apps it doesn't even change from the default so it doesn't matter.

There are specialist portable versions of windows applications for a reason. If you choose random applications soon or latter you will hit one that does not work right.

For freeware there's sites like https://www.portablefreeware.com/ so you don't have to guess. (these don't have any portable wrappers/launchers, unlike portableapps.com)

Also note wine prefixes are not promised to remain working when you change wine versions either. As this is treated the same as copying application to a new install of windows. So if application is not portable and it in wine and you transport it to a different wine version it may completely break.

But I never said it is? In fact I always recreate the entire wineprefix on each new version of Wine...?

Mind you, the wineprefix contains just the wine base files. ALL my apps and other stuff are symbolic linked (e.g. C:\Programs -> somewhere where I have the apps). To me a wineprefix is "volatile" and easily changeable, it doesn't hold any important data, I can remove and recreate it and I do it everytime I recompile Wine.

You guys are way too lazy to even setup your system and want a 1-click solution that does it for you. I can't stand someone else configuring my directories and paths, I want to place them how I want them. But you only have to do this once (or when updating Wine, which I automated with a very simple shell script), not for EACH application. The "maintaining effort" is tiny because it doesn't scale with time or number of apps. And I've even automated it now.

Removing the wineprefix should never touch any files you cannot possibly restore via Wine itself or winetricks or w/e, otherwise that's so... dumb. (btw I even cache/store the msvcrt installers, I don't want to rely on Microsoft or my internet connection for having them available they're pulled locally)

[oiaohm]

You can squashfs the WINEPREFIX itself along with Wine and use overlayfs and they will share the base... (just use symlinks to link to the squashfs's windows dir) of course after installing some essential things via winetricks (e.g. msvcrt libs) but not more than that.

R
Overlayfs has more overhead than bind mounting. As I said a lot of work to get something close to what Nix and flatpak naturally do.

There are a lot of users who don't put that effort into there system.

[Weasel]

Well first overlayfs is probably not even needed for 99% of applications written in the past decade or two, because really it's only the windows directory that would get changed, and how many apps change the windows directory? (except installation which is out of the scope of "portable apps"). On Windows they're not allowed to write to it, anyway, so it's no big deal. (many apps write to C:\users, but those are even symlinked by default to your home dir outside the prefix... I of course symlink them to some other place manually where I prefer to, but that's not needed)

And overlayfs is pretty light mind you. Since this is for the wineprefix, which is very low overhead and loaded just once or on startup. I use it for the "less trustworthy" users because I use even the browser (as a different, untrusted user) with Wine sharing the common wineprefix base and it works just fine and also launches as fast as on Windows (~1 second), so the overhead is minimal.

Note that for the registry (which is not shared), Wine even handles symlinks to it just fine, if you replace the registry files with symlinks to some other place, it's specifically coded to handle that case properly. So even with a "Read only" wineprefix, if you put symlinks to the few files that need modifications (i.e. registry and dosdevices), it will work and in fact that's how i use it without fuss.