That would be great. I did hear the news of their joint venture, but have not heard anything since. If anything comes out of this, that would be great

what does that mean

fair point, you currently have to compromise on either “ethics” (a bit stronger word than I would like to use) or result quality. My only try is to promote independent engines in hope to improve them such that market gets more competitive

I can only suggest you to try the engines in the linked article, maybe something serves your wants better

i have tried them, but can not use them as first either. but it is fun to sometimes search stuff on it and it goes off the rails

thanks, fixed

i have not tried any others (just don’t “pillage” enough). But my wild guess would be no, mostly because others do not compress that much or use freearc. fitgirl compresses a bit more than others. I prefer their repacks because of their great repuatation, large amount of seeders, and small size (i have terrible internet).

This is not a huge problem, you can still get wine builds with older lib32 implementations (for example on arch, you can check aur (and by extension chaotic aur), most other distros would have not changed yet), so you do not have to install on windows and move over.

If only I could

i will check it out, but eventually they will also drop lib32-* libs and will get the same problem. I want to solve the root problem

WoW64 is a Windows subsystem for running 32-bit stuff on 64-bit Windows. You’re talking about Wine’s implementation of WoW64 - there’s the old one which needs 32-bit Linux libraries and the new one which doesn’t.

I do know about this. to be specific, wine team since 9.0 stablised using there newer wow64 stuff (iirc, this was one of the blockers to use wine on non x86-64 architechtures), and since then, there has been aur package to play around it. I used to only use it, but receently i wanted to download a game, and faced this bug. then I reverted back to normal arch package which is in multilib repo and depends on lib32-*. Now the main arch package is using the newer wow64 implementation.

I did hint at the the fact that I did not find much in logs. I have not checked the verbose logging (which shows each dll involved, each bit of memory read, etc), but with regular logging,

0130:fixme:win:WINNLSEnableIME hwnd 00010108 enable -1: stub!
0158:err:environ:init_peb starting L"C:\\users\\sg\\AppData\\Local\\Temp\\is-SE85P.tmp\\FlushFileCache.exe" in experimental wow64 mode
0158:fixme:ntdll:NtSetSystemInformation (0x00000015,0x40bb84,0x00000024) stub
0158:fixme:ntdll:NtSetSystemInformation (0x00000050,0x40bba8,0x00000004) stub
0170:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION

these are the only lines that come when actual installation starts. The installer stays stuck at at some percentage (varies depending on total game size, and size of compressed binaries)

I think it is related to freearc decompression, because at this point in installer, the various .bin files (the compressed files are named like fg-*.bin, where * is some number, they are FreeArc archive files) are decompressed when using older wine version, with this, they are just stuck. I can not C^c the proceess, I have to pkill all the running wine processes. There is something related to wine written in fitgirl faq, which also hints at replacing the dlls for this, but that does not work for me

India

it is not caching related, it happens for a game installer of size 100 mib, and i have plenty of ram (24 gb)

bottles uses its own version of wine (i think it is called something like soda) which is older and would probably still have lib32 stuff. I prefer distro packages.

that explains it

lemmings.world or pifed.social both are general purpose, and relatively small

I feel you. Not a american.

by a very specific definition of “inside”

had almost the same line of thought, that some leader’s term got over