StillDepressedMan

Methylphenidate, Clonazepam, Alprazolam, Pregabalin, Alcohol ahh and Oxycodone.

So the best way you can help is by reporting bugs to the Bugzilla and adding test reports with workarounds to the AppDB. I understand your anger, but the development of such a complex tool takes time, sometimes requires a few steps back, and may involve breaking backward compatibility. There is still a long road ahead, so grit your teeth and hang in there.

Edit: and don’t forget to toss a coin to your developer the unsung hero who braves endless bugs, slays the monstrous legacy code, and keeps the realm of software safe from chaos.

I have been using this application for years. I convert some games since 10 years from Wine version to wine Version and most of work i had to get it run again is because of wine does nothing to support me.

Do you mean you were writing installers for different frontends?

I also used PlayOnLinux and other bottle software and after they died, I had again a lot of work to convert it to other helper software.

I don't think Bottles will vanish. Yes, there are some problems. The main programmer is doing something else. Running stuff from the console doesn't work. But I think it's too good to die.

And really I do not wish to need them.

In my honest opinion, I think Wine developers don't want to build a global database on how a given game should be installed and have it done automatically. Wine is like a kernel—they don't want to touch "user space." They want to create an engine that works exactly like Windows, and no workarounds would be needed.

I think the best way to add workarounds is the WineHQ AppDB.

I’m not sure what you mean about ‘can’t download the newest Mono’; because I’m not sure when / what might be trying to download Mono.

When you switch Wine to a newer version, if the Wine developers have updated Mono or Gecko, Wine will show a popup asking if you want to download them. That happens when your version is outdated or missing.

002c:err:wineboot:process_run_key Error running cmd L"C:\windows\system32\winemenubuilder.exe -r" (126).

Thats tatally normal.

but not the latest vkd3d (there seems to be a problem with the download of this in bottles at the moment. I have 2.10.).

For your information, the current version is something like 2.14. But never mind, I don’t think this is related to the Directx3D implementation, wine or Mono if these things did not help. I just wanted to know if everything was up to date, because always is possibility that could help.

Wine is far from perfect and sometimes things just break—sometimes because of a system update, sometimes because of a Bottles update, sometimes due to changes in the prefix settings, game update or just bug in wine causing data corruption.

You’re in a good position since reinstalling actually helped you. That’s not always the case. Sometimes you need to wait months—or even years—for regressions to be fixed.

Appendix

I don’t know how familiar you are with Wine, but for the future remember: dxvk is not the default Wine implementation for DirectX 9–11. By default Wine uses wined3d, which is slower but often more robust. So if something doesn’t work, just try disabling dxvk.

However, in Bottles there’s currently a bug (I think) where to switch properly you first need to change the Wine version to an older one, and then back to the version you actually want to use.

It’s best to enable performance monitoring and check whether the game is running with dxvk, vkd3d, or wined3d to be sure.

Anyway, after experimenting with different settings without success, I tried creating a fresh bottle – and that worked. The game in the new bottle launches fine.

That’s good, it’s working now after reinstall. At this point, without logs, it could be anything. Maybe you changed the runner (wine version), or the game received some internal update that went wrong. Without logs, it’s hard to say.

If you want to restore the old bottle state, for the furure just export the bottle and restore it if needed. If you are sandboxing your bottle from internet access, it can’t download the newest Mono (.NET). To prevent that issue, I recommend disabling the sandbox temporarily, switching the runtime to the latest Wine, and if nothing else works—just keep the sandbox enabled and reinstall Mono manually.

Another thing: one directory above the C: dir or in the same level (IDK) there is a cache directory. Try deleting it—sometimes it prevents the game from running.

Whenever something doesn’t work, make sure you are on the newest possible versions of dxvk, vkd3d, and Wine (there are multiple options—if you want “clean” Wine, you can use Kron4ek builds + Kron4ek staging with additional patches or just system wine, though system versions may be outdated depending on your distro).

And one more personal tip: I never advise putting multiple games into the same wine prefix (called “bottle” in Bottles). Tweaking the settings often breaks compatibility: one game works, another stops. It’s much safer to keep one game per prefix.

And if your game doesn’t need DirectX 12, disable vkd3d and see if it helps.

but cmd from wine is even more worse than cmd from Windows.

Haha, that’s true.

A Wine Prefix should only contain the installed application and nothing from the system. Wine imitates Windows, so applications behave just like they would on real Windows — basically, one prefix is like one Windows installation. And in many cases, users even replace Wine’s built‑in DLLs with native ones from Windows, so those files can’t really be hidden because applications expect to see them.

Wine imitates Windows, so applications behave just like they would on real Windows — basically, one prefix is like one Windows installation. And in many cases, users even replace Wine’s built‑in DLLs with native ones from Windows, so those files can’t really be hidden because applications expect to see them.

I like Steam’s approach where game files are stored separately together with the prefix settings, and when you launch a game it just runs inside its own Wine prefix. Still, I can easily imagine cases where this setup doesn’t really make sense — for example when you need several programs working together in the same prefix, like some mod installers that expect the main game to be there as well.

If you’re interested in Steam’s approach, you should also check out UMU launcher and more here bottles UMU integration

PS: Wine itself is a general‑purpose engine, while the frontends are meant for regular users. Even though I compile it regularly, I haven’t really used plain Wine directly in a long time.

I don’t know. If by usability you mean a better user experience, I don’t think so. I haven’t noticed many improvements in this area for years. That’s why many wine wrappers exist, and I’m fine with that. Personally, I value it more when the wine team focuses on improving the common virus library APIs for better application compatibility.

What's new in this release:

• Bundled vkd3d upgraded to version 1.17.
• Mono engine updated to version 10.2.0.
• Support for ping on IPv6.
• Gitlab CI now running on Debian Trixie.
• Various bug fixes.

The source is available at https://dl.winehq.org/wine/source/10.x/wine-10.14.tar.xz

Binary packages for various distributions will be available from the respective download sites.

You will find documentation here.

Wine is available thanks to the work of many people. See the file AUTHORS for the complete list.---------

Exactly.

No, it has never happened to me. I think the software somehow detected when the phone was in a hand. But when I ran while holding the phone, it sometimes turned on.

Holding the power button when the screen is off works pretty great and won’t ever activate on accident. It is also a default Android feature I believe.

It seems okay.

It’s a Motorola gesture. I don’t have a Motorola anymore, but I think shaking is the best gesture for turning on the flashlight.

Why is the microphone running after launching the app? I built the flatpak from the instructions.