>Wine's approach seems overly complicated and unreliable
>Wine seems like a dead end.
Why do you say so? In terms of technical architecture wine is as good as you can get. If it's the UI underpinning you're concerned about, it's true that wine isn't the most userfriendly. I know on osx codeweavers (who are one of the primary contributors to wine) makes a slick ui.

For linux, I remember steam contributed a lot of graphics related patches for proton. It seems online that you proton within steam should work for playing non-steam games as well. You can also try playonlinux which is a frontend for wine I've found online.

>reliability and ease of use of wine compared to ReactOs in a vm
IIRC wine just translates the syscalls whereas reactos is an entire reimplementation of the nt kernel. But some of the userspace libraries may be shared between the two. For things like accelerated graphics wine is probably better here since that's where the effort has been in terms of gaming.

>>2468
>Why do you say so?
Wine both tries to reverse engineer how windows programs interact with the os, AND translate those calls into something the linux kernel can understand. Both of these steps have plenty of room for error. There are errors and issues, and I suspect there always will be.

Removing the second step would simplify things. Better if both steps were removed. VMs are already better than Wine in every way except performance.

>If it's the UI underpinning you're concerned about
A ui shouldn't even be necessary outside of an initial set-up. No client, no manager. Nothing like that. It should just be right clicking a folder you downloaded, pressing "run in windows container", and then that windows program would run.

>>2469
>Wine both tries to reverse engineer how windows programs interact with the os, AND translate those calls into something the linux kernel can understan
Fair point, and I guess Microsoft actually arrived at a similar conclusion since they abandoned the WSL1 approach in favor of just hyper-v for WSL2. But I don't see why you think the second step (translating those calls into a linux equivalent) is the bottleneck for wine. Granted I don't use wine that much but from my impression command-line programs, basic win32 apps, etc. work perfectly fine – the only real "bottleneck" from a technical standpoint is in the graphics emulation (directx -> vulkan or whatever, I haven't followed this too much). There are separate issues around optimizations to avoid slowdowns from trying to shoehorn windows behavior onto linux (futex2 syscall), as well as issues around applications that call into NT directly instead of going through the DLLs, but these are edge-cases.

I'm also not sure what you're suggesting as the alternative? If you want VMs, you can use vmware, virtualbox or qemu coupled with a stripped down windows (e.g. one of the windows distros meant for POS applications, or there are 3rd party redistributions that strip out as much as possible). Or as you mentioned there's reactOS but I think there's little to no graphics acceleration there.

>A ui shouldn't even be necessary outside of an initial set-up. No client, no manager. Nothing like that. It should just be right clicking a folder you downloaded, pressing "run in windows container", and then that windows program would run.
That's how codeweeaver's crossover or wineskin wrappers on osx work. It essentially does exactly what you suggest – I can download an arbitrary exe, and either open it in an existing environment (what crossover calls "bottles", somewhat hand-wavily analogous to a docker container) or create a new environment to run it in. I'd imagine playonlinux is similar, but I haven't tried that.

>>2470
>I don't see why you think the second step (translating those calls into a linux equivalent) is the bottleneck for wine
I asked on the irc, and somebody had this to say
>Xoro: My experience with running VNs in WINE was; Bizarre glitches
>Xoro: Shit would launch, but there was kernel freezing, disappearing sprites and unsolvable resolution issues
I don't know whether the first or second step is to blame for this, or graphics emulation

>I'm also not sure what you're suggesting as the alternative?
A more integrated vm that runs a windows version so stripped down it can start in seconds. With no graphical start up, account log in, or desktop environment.

>I'd imagine playonlinux is similar
No, it has its own repository.
https://wiki.playonlinux.com/index.php/First_Use
>Installing an application is as simple as searching for it and following the installation wizard. To install an application:
>Click "Install" on the main window
>Either search for your program in the search bar, or choose from a category along the top

Look at vndb. There's thousands of games on there. Most of which only run on windows. Any solution that requires configuring every single program in wine is not viable as a means to make every single one of those seamlessly usable on linux.

>>2471
>>2471
I think in that case it might be related to directx issues, some weird multimedia APIs, and/or font rendering libraries. Usually in order to gets things to work properly you have to install winetricks which swaps out some of the reverse-engineered libraries with official MS ones (which can't be distributed as part of Wine proper due to obvious reasons). Also by "kernel" I assume that he's referring to the VN engine (because if not and it's causing linux kernel freezes, that would be a great bug report right there since userspace applications should not be able to do that). If you haven't already, check the https://appdb.winehq.org/ for that application and create an entry? I'm also not sure when the person you mentioned tried running wine (and which version he tried), since most of the proton improvements contributed by Steam have been in the past year. I found this guide [1] which also mentions the resolution issues caused by some WMs, and a workaround.

>A more integrated vm that runs a windows version so stripped down it can start in second, with no graphical start up
Hm this should theoretically be possible doing something like WSL2 where you run NT kernel + minimal userspace in a VM and then maybe make use of RDP to proxy the drawing. I don't know enough about windows internals to comment any further, other than it seems possible (especially with leaked XP source and previous NT kernel leaks). I guess the reason why no one has bothered is that the people who know enough about windows internals to try this would rather just contribute to wine?

>No, it has its own repository.
Per [1] below, it seems you can install your own applications into "bottles" just as with crossover?

[1] https://fglt.nl/guides/visual-novels-on-gnu-linux.html

>>2472
Here's something interesting I found.
https://www.ntlite.com/discussions/#/discussion/666/whats-the-smallest-install-size-for-w10-that-i-could-expect
>for an offline pc, just used for audio editing, playing music, dvd's etc, i can go manic and get around 2.3gb without updates, but i wont be able to use the internet
>after few tests, here a new preset for Windows 10 TH2 Pro x64 with classic start menu. iso filesize is 1086MB and installed is 2613MB without pagefile and swapfile.
No networking is perfectly acceptable and even desirable.

>the people who know enough about windows internals to try this would rather just contribute to wine
I don't get why unless wine actually has some advantage over that approach(besides legality). People pirate windows ISOs all the time, so I don't see how that would be much different.

Post edited on 3rd Nov 2021, 6:47pm

>>2473
>Here's something interesting I found.
Oh you can do far better than that. I remember reading somewhere that people used to make heavily stripped down versions of windows 98 and xp for the sole purpose of running a single program.

>I don't get why unless wine actually has some advantage over that approach(besides legality)
You can read the discussion on pros vs. cons with WSL1 vs WSL2 since the same basically applies. Wine approach is a lot more efficient, less resource intensive, and allows win32 apps to play nicely with your own window manager.

>>2474
>Wine approach is a lot more efficient, less resource intensive
So it's a "bloat" thing. Okay. Microsoft chose the other approach in the end despite more overhead.

I looked more into it, and I've seen plenty of people bitch about Playonlinux and recommend Lutris instead, but from what I can see, Lutris is totally dependent on game specific scripts.

Post edited on 3rd Nov 2021, 8:06pm

>>2467
ReactOS is extremely unreliable. Try installing it in a VM, it's absolutely not at the point where you can use it for anything productive, much less games that don't run on Wine.

>>2476
I'll take your word for it, but I have tried Reactos in vm before.

I've tried playing Cave Story both in Debian on a vm using wine and playonlinux, and Reactos in a vm. While I couldn't get sound to work in Reactos, it was otherwise fine. In Debian, I got nothing but a black screen. In fact the whole machine crashed every time I tried.
>>/ot/34974

Katawa Shojo was a similar experience on CentOs, though the flatpak for that did at least work when started from a terminal emulator. Maybe this was all my fault for doing things wrong, but I've had more positive experiences with Reactos when it comes to running windows software.
>>/ot/35455

Post edited on 4th Nov 2021, 1:09pm

I've yet again attempted to run cavestory using wine in a vm, this time using this guide I saw recommend here or another imageboard. https://fglt.nl/guides/visual-novels-on-gnu-linux.html

First I get a million dll errors. So I try using playonlinux's own script for cavestory specifically. It freezes sometimes, other times crashes and give me a registry error. It does not work.

Using wine directly on the executable also results in freezing. If this is how wine performs for a program this simple, I can only imagine it's totally unusable for anything more complex like a VN. It's awful. Wine absolutely sucks. There's nothing easy or convenient about it.

Post edited on 7th Jan 2022, 2:30am

>>2564
I've got video evidence
https://anonfiles.com/xcm9C65fx5/2022-01-07_05-37-50_mkv

>>2565
>>2564
And for the record, it worked flawlessly in a reactOS vm. Even if reactOS uses a lot of wine code and vice versa, there's clearly an important enough distinction between the two for this difference in result. I didn't have to install any drivers, or fiddle with vbox's display settings or install any guest additions. It just worked, in a vm.

Post edited on 7th Jan 2022, 4:15pm

Did you try proton (via steam(? Not sure which version of wine you installed but some repos have old versions

>>2567
Nah. The problem seems more likely to be related to drivers and hardware acceleration. I didn't have Mesa-32bit installed.

After I installed that, it would immediately crash and give some sort of registry error I can't understand in the slightest. It's possible on real hardware this wouldn't be an issue.

Maaaaybe, proton would somehow rectify this, but I don't even feel like trying. This was on void linux.

>>2568
Wine 7 is out. Any improvement using this newest release?

>>2564
You're making life a lot more difficult than it needs to be
Just use Bottles, it's on Flathub
Basically a wrapper for handling wineprefixes at its core with a bunch of other useful features
Since I moved my desktop back to Linux a few weeks back I've been using it and have had basically no issues running VNs with it
The only real issue that you can't handle through the GUI in terms of dependencies is Windows fonts, but if you just grab those somewhere yourself and dump them into the wineprefix I've had good success with a lot of things just running out of the box

>>2680
For context, that was my experience using wine in a void virtual machine. Since then, I've learned there's a big difference between a real gpu and virtualized one. I've also started using vmware instead of vbox, which has been quite the improvement.

I haven't tried cavestory in wine again, but nxengine works easily. And following this(admittedly lengthy) guide https://learnjapanese.moe/vn-linux/ (minus the lutris steps) has led to good results with visual novels, even in a vmware virtual machine(kubuntu).

I haven't seen a case where Bottles would improve things. Just using the same prefix for everything seems better to me.