Porteus

When I activate a wine module (for example, wine-2.4-x64-3.2-GeckoMono-1.xzm), and try to run a windows program, wine first takes several minutes to create a huge (~500MB) configuration folder called .wine in my home directory.

When I deactivate the module the .wine folder stays in my changes.

Couldn't we merge the .wine folder into the module somehow? So that when it's activated, a pre-deployed .wine is installed (mounted) too, and is removed (unmounted) when the module is deactivated?

@rych
Before you log out simply delete the file .wine and you are done!

Regards!

@wread, yes, but then the next time I run a windows program, I'll have to wait again for quite a while for it to be rebuilt. It's also unfortunate that it has to be so large, I wonder if it's because it carries the whole 32bit sub-system.

Do you really need the GeckoMono part of Wine? If not, you can simply try this version: https://sourceforge.net/projects/wine/f ... 0Packages/ (need to convert from txz to xzm). After executing it for the first time, just cancel all the dialogs and you're good to go.

@rych
I have the Wine module in "modules" as you, and when I am going to run a windows program, I go to Start>Applications>Settings>Wine to load the .wine folders. This folder by me is over 600 MB and contains the basic windows operating system, file manager, etc. and the register. Thank God that it is not loaded permanently! (the Wine-Gecko module takes away already 900 MB of your ram!; you will need a supercomputer to have them both in ram all the time!)

It takes about 1 minute to load, not bad! But it occupies 600 MB of your ram! when you are done with your windows program, simply take .wine out!

Regards!

@fulalas, indeed, I don't need that bloat. I now have a 60MB wine-2.18-x86_64-1sg.xzm and a 20MB folder .wine.

The only problem is that this (and any other) 64bit Wine module also installs a /usr/bin/wine that doesn't work and confuses other Wine components, wincfg, for example. If I simply delete /usr/bin/wine then wincfg uses the /usr/bin/wine64 and starts up. But other places are still broken. I guess /usr/bin/wine calls something that doesn't exist without 32bit subsystem.

Yeah, you need lib32-compatible: http://www.mediafire.com/file/61cm1x2dw ... bs-x86.xzm

I have a bigger version (45 MB) of this module. I can upload it if this one doesn't work for you.

@fulalas, thank you. Indeed could you upload a larger version of the 32bit libraries, because with this I'm getting `Could not find dependent assembly L"Microsoft.Windows.Common-Controls"` when I try to run a 32bit WinDjview (wine64 WinDJview64.exe crashes, so I'm trying to see if I can use a 32 bit WinDjView).

Sorry for the delay! Try this one: http://www.mediafire.com/file/jzc4evenj ... ib-ftw.xzm

Thank you, @fulalas. The 32 subsystem of wine and friends now works. But if I put it into modules folder, for an automatic activation, then my system DPI settings (?!) get damaged for some reason. Maybe the order of modules activation matters. For now I put it into "optional" and activate this module, "0050-compat32-multilib-ftw.xzm", manually. Inconvenient, but then again I hope not to use 32bit windows programs that often. Sadly though wine64 itself isn't completely 64 it seems.

Yeah, rych, these multi-lib32 have this side effects sometimes. And, believe me, the full package is ever worse -- it breaks my system even activating it after the boot

Sadly though wine64 itself isn't completely 64 it seems

Nope, to have easy only 64bit wine try packages that are only 20-30MB large (together 32bit and 64bit are 40-50MB), for example this package: http://slack.conraid.net/repository/sla ... 64-1cf.txz. I will share my compat32-libraries in another post.