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

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.
 
 
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

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.
 
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!
 

That's now 404, not found.

… I tried i386-wine it works but then when i uninstall it and installed wine64 it has problems. …

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

winecfg
wine: could not load ntdll.so: (null)

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:
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:

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.
 
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.
😢
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.
 
maybe Wine should get that info in some other way instead ("procstat binary" by the looks of it).
Code:
int name[] = {
  CTL_KERN,
  KERN_PROC,
  KERN_PROC_PATHNAME,
  -1
};

sysctl(name, nitems(name), buf, &bufsize, NULL, 0);
and so on.
 
😢
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.

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.
 
Back
Top