I can't run windows applications with wine(64bit)

christhegeek

christhegeek

I can't run windows applications with wine(64bit)

I've got the error message "not supported on this system"
I can run 32bit applications when i install i386-wine
 
Currently the 32-Bit and 64-Bit versions of Wine are seperated, this means that the respective programs that you want to use, should have only 32-Bit processes or only 64-Bit processes but not both together.
 
forums.freebsd.org

wine wow64 and winetricks at x64 wine

Is wow64-support for wine in the works? Wine supports wow64 since years but many distro's didn't seem to implement this very well or not yet. Winetricks is also not working for 64-bit wine, since there is more and more applications who drop x86 support i start to need it. There is no...
forums.freebsd.org forums.freebsd.org
 
I tried i386-wine it works but then when i uninstall it and installed wine64 it has problems.
Doesn't seem to work for some reason

Alexander88207 said:
Currently the 32-Bit and 64-Bit versions of Wine are seperated, this means that the respective programs that you want to use, should have only 32-Bit processes or only 64-Bit processes but not both together.
Click to expand...
 
Having the same problem in FreeBSD 13. Running Rimworld (GOG installer) with wine on an amd64 system:

Code: 
[hunter@bsd /usr/home/hunter/Downloads/RimWorld]$ wine64 rimworld.exe
001b:err:heap:HEAP_GetPtr Invalid heap 0x440000!
001b:err:heap:HEAP_GetPtr Invalid heap 0x440000!
001b:err:plugplay:get_device_instance_id Failed to get device ID, status 0xc0000017.
001b:err:heap:HEAP_GetPtr Invalid heap 0x440000!
001b:err:heap:HEAP_GetPtr Invalid heap 0x440000!
0009:err:module:__wine_process_init L"Z:\\usr\\home\\hunter\\Downloads\\RimWorld\\rimworld.exe" not supported on this system
[hunter@bsd /usr/home/hunter/Downloads/RimWorld]$ 001c:err:heap:HEAP_GetPtr Invalid heap 0x440000!
001c:err:heap:HEAP_GetPtr Invalid heap 0x440000!
001c:err:heap:HEAP_GetPtr Invalid heap 0x440000!
001c:err:heap:HEAP_GetPtr Invalid heap 0x440000!
001c:err:heap:HEAP_GetPtr Invalid heap 0x440000!
001c:err:heap:HEAP_GetPtr Invalid heap 0x440000!
 
… Superseded by https://gist.github.com/shkhln/3d0856683e1fc029d64cdaa6ba3e9393.
Click to expand...

That's now 404, not found.

christhegeek said:
… I tried i386-wine it works but then when i uninstall it and installed wine64 it has problems. …
Click to expand...

If there's a change of architecture, removal of the ~/.winecfg ~/.wine directory may be appropriate. If not removal, you can set it aside.

Alexander88207 said:
winecfg
wine: could not load ntdll.so: (null)
Click to expand...

Do you still get a null there?

Cross-reference: <https://bugs.winehq.org/show_bug.cgi?id=50257#c35>


For myself, assuming some other people are affected:
 
Last edited:
grahamperrin said:
That's now 404, not found.



If there's a change of architecture, removal of the ~/.winecfg directory may be appropriate. If not removal, you can set it aside.



Do you still get a null there?

Cross-reference: <https://bugs.winehq.org/show_bug.cgi?id=50257#c35>


For myself, assuming some other people are affected:
Click to expand...

Hello, I do have currently lost the interest in running wine-devel 64-Bit because they get more and more busted. But the workaround for this error is to mount procfs on /proc.
 
Alexander88207 said:
Hello, I do have currently lost the interest in running wine-devel 64-Bit because they get more and more busted. But the workaround for this error is to mount procfs on /proc.
Click to expand...
?
Sorry to hear that.

How is it busted now?

I've done a lot to fix the FreeBSD-specific Wine problems. I have a preliminary mingw-w64 port and with it, the PE build of Wine working, through both that port and Debian's mingw-w64 in Linuxulator, and the PE build is not just unaffected by https://bugs.winehq.org/show_bug.cgi?id=50257 but also more compatible with some Windows apps. Our current ELF build bug is some kind of /libexec/rtld-elf bug, and I've already helped debug and fix 2 other rtld-elf bugs affecting Wine, so I could take a look at some stage, but I thought the Wine ports already worked around it internally with LD[_32]_BIND_NOW=1?

I didn't realize /proc was such a problem. I've now documented that important fact on the wiki. Wine uses our /proc/curproc/file a lot. Since FreeBSD apparently doesn't have /proc mounted by default (why?), maybe Wine should get that info in some other way instead ("procstat binary" by the looks of it).

As an upstream Wine contributor since 2006, I take Wine on FreeBSD seriously, and hope there aren't too many of you "running windows 64 in bhyve" because of FreeBSD-specific Wine problems ?‍♂️. That's acceptable when Wine doesn't work on Linux either, but not when it's only broken on FreeBSD.
 
dj015 said:
?
Sorry to hear that.

How is it busted now?

I've done a lot to fix the FreeBSD-specific Wine problems. I have a preliminary mingw-w64 port and with it, the PE build of Wine working, through both that port and Debian's mingw-w64 in Linuxulator, and the PE build is not just unaffected by https://bugs.winehq.org/show_bug.cgi?id=50257 but also more compatible with some Windows apps. Our current ELF build bug is some kind of /libexec/rtld-elf bug, and I've already helped debug and fix 2 other rtld-elf bugs affecting Wine, so I could take a look at some stage, but I thought the Wine ports already worked around it internally with LD[_32]_BIND_NOW=1?

I didn't realize /proc was such a problem. I've now documented that important fact on the wiki. Wine uses our /proc/curproc/file a lot. Since FreeBSD apparently doesn't have /proc mounted by default (why?), maybe Wine should get that info in some other way instead ("procstat binary" by the looks of it).

As an upstream Wine contributor since 2006, I take Wine on FreeBSD seriously, and hope there aren't too many of you "running windows 64 in bhyve" because of FreeBSD-specific Wine problems ?‍♂️. That's acceptable when Wine doesn't work on Linux either, but not when it's only broken on FreeBSD.
Click to expand...

Hello, Damjan

The following problems are: tested with 6.12 wine-devel (non-staging) wine expects the 86_64 folders although the libs are packed in amd64 folders

Code: 
wine64 winecfg
wine: could not load ntdll.so: Cannot open "/usr/local/bin/../lib/wine/x86_64-unix/ntdll.so

The workaround is to simply link the stuff which then points us to kernel32.dll problem which seems to be a gstreamer problem.

I am just quite little instructed on 64-bit will use from therefore 32-bit on 64-bit wine. But I am not one of those who have Windows sitting in dual boot or something like that.

The i386-wine ports are currently maintained by me and have the workarounds in them and work as expected but the normal wine ports do not have anything of that.

This is not meant to be offensive and i do not want impute anything to him but unfortunately it seems the maintainer of th main wine ports doesn't seem to be as enthusiastic as we are, only compilation bugs are fixed but runtime bugs like this one are simply ignored even the PRs where the bugs are reported are not answered by him. I am sure that he can do more if he wants to.

I do not want to blame on him now but this generally pulls the mood down a bit and protrudes into the frustrating because you just get the feeling of being left in the dark. This has now fired up the fact that 64-bit has now become like mold here because no one wants to deal with it almost anymore and can leads to statements like mine above.

Although i understand that almost everything here runs under no warranty and even if I have less knowledge of the stuff than him but as a maintainer he should give more effort or not?

Otherwise, I can not complain and thank you for your work and appreciate it very much that you are committed to us, you should not forget that.
 
You must log in or register to reply here.
Back
Top