Linux
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
view the rest of the comments
Haha, that’s true.
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.
@StillDepressedMan
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.
It is not just about being able to use it.
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.
They are not compatibility. And really I do not wish to need them.
Do you mean you were writing installers for different frontends?
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.
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.
@StillDepressedMan No im not able to develop Aplication.
I'm a user.
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.