Based on Wine Mono test results, it's likely this is still an issue, as various socket tests are flaky. I'd been assuming it was the tests at fault.

The 32-bit and 64-bit libraries are combined in one package. Most of it is shared between cpu architectures.

Not really, that "Desktop"="shell" setting is how the "Emulate a virtual desktop" checkbox works, and as you can see the real setting in the registry is a string, not a boolean.

I guess someone could add another setting to winecfg for the taskbar.

The interesting part happens in the explorer process when something is copied (you should see a trace from request_selection_contents), and in response to WM_RENDERFORMAT when the first attempt is made to paste.

0510:err:environ:init_peb starting L"C:\\Program Files\\nqc-win-3-1-r6\\nqc.exe" in experimental wow64 mode That line suggests you don't have a 32-bit install of Wine to run 32-bit applications, so it's using the 64-bit one (which should work in theory but is not well-tested). I don't know...

It's probably in ~/.wine/drive_c/Program Files (x86)/Steam.

This behavior is hard-coded and would have to be changed in the source code.

I agree that it's not realistic, but that's not because of updates to Windows. It's the complexity and scope of the Windows API, combined with the unimaginable volume of Windows software that exists. There are simply too many ways that a Windows program can accidentally depend on implementation deta...

Hi,

Can you double-check by running 'wine uninstaller'? If things are set up correctly, it can do the per-prefix configuration silently.

I think the correct fix requires Wine to use this interface when running in flatpak: https://docs.flatpak.org/en/latest/port ... icLauncher

It may be possible to work around it for now by giving wine permission to access ~/.local/share.

It's not possible with Winelib.

You would essentially need the reverse of what Wine does - instead of a PE loader on Linux, you need an ELF loader on Windows, as well as replacements for whatever APIs the .so uses. It sounds possible to me, but I don't know of any project that does it.

It's not meaningful on its own. You'd need some sort of log to figure anything out, or examine ibrowse.dll but that approach tends to be harder.

I don't know how to gather logs on Android.

This is probably a bug in wmp. If you file a report on Bugzilla, maybe someone will be able to fix it.

There are probably alternatives that work, but I don't know any specific ones.

The only way I can find to do this is to query the internal "__wine_x11_whole_window" property using the GetProp function. The X11 driver also has some custom commands that can be passed to ExtEscape, one of which seems to return a Drawable, but I don't know if this is useful for your purp...

I looked up 0x80040273 and it's VFW_E_DDRAW_CAPS_NOT_SUITABLE. I think this may be an issue with your graphics drivers.

Hi, can you post the console output from your program? I'm just curious what's causing it to crash.

Installing .NET Framework might help.

Proton has a work-around that does this, but it's handled by the proton script (in Python) rather than Wine itself, and has some problems. The symlinks are visible to Windows programs, and in particular there's a way of getting file size that does not work for symlinks on Windows. Any installer that...

I don't think that's true, certainly there's no support for UWP applications. If it did have such a thing, it'd be in the modified wine tree which is LGPL and publicly available.

I don't think it makes much sense as long as the only supported way to obtain the software is using proprietary code that's part of Windows.

Uh, because that's how the Unix shell works. Shell variables aren't visible to programs as environment variables unless you use the export command (which applies to subsequent commands) or specify them on the same line (which is temporary). Wine also has no way of knowing what your working directory...

Not sure about return values, but I think it just takes the lower 8 bits. I should've just said "undefined". A C developer might declare their main method as "void main" or leave out the return statement. In practice it probably means whatever was in some hardware register when i...

One problem with checking the return value is that on Linux return values range from 0-255 while Windows has them as 32-bit values (you'd need to start the program from a Wine process to get the full return value). Also, the application could return any value under normal circumstances, and if the d...

Well, a single Wine process crashing doesn't necessarily mean the program you directly called will exit, and it appears the return code is determined by the exception code.

You can look for "wine: %s (thread %04lx), starting debugger..\n" from the start_debugger function.

I think you would have to modify or replace winedbg. Or do it less perfectly by scanning logs.

Exiting silently is the normal behavior, the msi has no GUI. You can run "wine uninstaller" to check if it installed.

I'm surprised it couldn't install the msi without a mapped drive though. Maybe it needs an absolute path since the working directory is wrong?