Well, I searched more on it, and it turns out it’s not supported with windows either way. It works mainly with linux inside linux. I will at some point do a gpu passthrough on my main desktop, which right now has Windows. I just can’t do it right now because my laptop only has an igpu and my desktop only has one gpu (the cpu has no igpu).
I don’t really care about having great gpu performance inside the VM because I render with blender, which works beautifully on Linux. I just want Rhino to be good enough that I can visualize arctic and “rendered” viewport without it being laggy. I actually need windows for 3 software. Rhino/Grasshopper, Affinity (the wine stuff is not there yet) and Ableton. When I upgrade the cpu I will purposely get one with a decent igpu so I can pass it through a windows VM.
I’ve gotten Rhino 7 to work under wine a handful of times. It is definitely usable, but I’ve gotten too used to all the improvements Rhino 8 has provided that it feels backwards. Anyways, since I went through the trouble of setting up QEMU/KVM I’m going to set up a Linux VM and test wine configs to try and make Rhino 9 work. I have given up on making 8 work, the closest I’ve gotten to it is to completing the installation.
I hope that I will come back to this thread that isn’t the classic “buffer overflow” issue.
if not for window vm qemu/kvm virtualization can be still useful if you want to safely isolate a program, I use that for running claude code, which may be useful for figuring out why rhino 8 and 9 are failing to start under wine
I’d imagine that whatever is crashing under rhino 8 is probably also going to be crashing under rhino 9, so either way
Can confirm - this is exactly what happened when I tried to get WIP working, it just failed at the same point. @Winer your suggestion to let Claude have access and really go to town is an interesting one - at least for one person to do to work out the process.
I am waiting with bated breath though. I don’t know the FIRST thing about this side of programming, but this just feels right - now that the .NET that Rhino is built on is cross-platform native to Linux, there HAS to be a way for wine to reference the Linux native code and dispense with a lot of the dll’s completely…
Okay, the failure point in attempting to run Rhino 8 seems to be an infinite loop in .net at the globalization/ICU code. I -think- this is just getting the language, right? Is there a way to get past this? Is there a way to set Rhino / wine not to check? @Winer
I’ve made some progress I’d like to share with everyone here, I cloned the wine repo and threw claude code at the problem and was able to get Rhino 8 working in an Ubuntu 24.04 VM. I haven’t tested it too much, just tried out some basic stuff but I intend to see how usable this is soon.
Claude made a few changes to wine’s source code having to do with the reserved stack size & also found an issue with dark mode detection in one of rhino’s .dll’s causing infinite recursions. I’ve not worked much with .NET before so this is relatively new stuff for me, so not sure if these fixes are more of a bandaid type vibe or if they actually do make sense. They seem to work for now. Claude did hallucinate some “fixes” that didn’t seem necessary, like it blew up the stack size to 512mb to try and get around the stack overflow issue.
@ItHasLegs that is huge! Congratulations! Using Claude Code definitely sounds like the right idea - do you think this would also work with Rhino 9? @duanemclemore reported an infinite loop a few months ago, perhaps that was it.
Interesting, maybe something to do with different dependencies on Debian Trixie vs Ubuntu. If you want you can open an issue on my repo and include the full error you’re getting & check if libicuuc and libicu74 is installed on your system, although I would assume claude already had you check this.
ldconfig -p | grep libicuuc
dpkg -l | grep libicu
This is different than that globalization/ICU code infinite loop you were getting right?
on a tangent in January there was a lot of noise about these wine patches that added support for Adobe Photoshop installer (and it looks like by now they have been mostly merged), maybe I’m asking something obvious, but are you considering submitting your changes upstream after other users confirm that they can get rhino running as well?
sorry for not replying sooner, architects exams took all my time in March/May, ItHasLegs put the idea of using Claude Code into practice with great results already
Honestly was feeling a bit daunted about submitting changes to a project so big as Wine (and not wanting to add yet another AI generated bug fix for already overwhelmed open source maintainers to deal with). At least not until I’ve nailed down the actual fixes and not any AI hallucinations. Like I’m still not 100% sure if that dark mode infinite recursion thing is a bug in the Rhino .dll or something that can be handled with a change to Wine. But I was thinking about submitting a change to Wine depending on how much traction this got here. I was also going to post this to the Rhino subreddit as well. Nice to see something similar was done for that Adobe Photoshop installer. I’ll look into that.
That’s fair, process of submitting to wine was said to be quite involved, developer of these patches to adobe submitted them first to proton actually before getting redirected to wine. But as you can see from the main Rhino On Linux thread this topic attracts attention, so it’s definitely worth publicizing it once ready.
PS I brought it up not because of technical similarities, but because Rhino users are also often Photoshop users, if next month someone announced that they also got Revit to work under wine I think that would open a lot of doors.
this is a really nice progress. I am more than interested to get it running on Arch-Linux and will test the repo and the PKGBUILD in the next weeks. At the moment i need to fix a other project but i am capable of debug the PKGBUILD to get it build on Arch if there is no deep bug in the chain of dependencies.
It is working on arch… kind of… the patch for the installer isnt working for me.
i needed to install dotnet8.0.14, dotnetdesktop8.0.14 and aspnet8.0.14 manually by downloading it from the microsoft site and i also needed to install vcrun2022 and dotnet48 via winetricks since the installer will crash else. i also need to install it twice since the install of EdgeWebView will take extremly long and will trow a error in the installer. i needed to wait that the webview install is finished and than restart the installer a second time to complete it.
That’s awesome! nice job I’ve also been troubleshooting on arch over the last few days, nice to see you got it figured out on your box.
I actually didn’t have many issues getting the installer working, just some minor changes to how LTO was set up on arch vs ubuntu. I’m currently running into another stack overflow when trying to launch it. Did you encounter any runtime errors?
Edit: Also just got Rhino8 launched on Arch! The stack overflow was a total layer 8 issue - forgot to apply the .dll patch after focusing on the installer launch issue for too long However I did observe some different behavior (an unhandled exception was thrown instead of a stack overflow) which was pretty interesting. Doing some more testing with the reserved stack space to confirm why that happened.
i first need to port my own plugins to rhino-8 before i really could use it on daily base and test if anything breaks. this will take some weeks since i will rework many old code on the way.
At the moment i only tried to create some simple geometries, starting grasshopper, use quadremesh and render using the cpu.
grasshopper example 1 is working but miss some font (i think this could easy be fixed with winetricks -q corefonts)
raytracing on a intel cpu is not really working. it is more than just slow. but this has not worked any way better in rhino 7 for me. since i do not need raytracing it is no big problem for me.
while porting my plugins to it i will sure test some more.
what do you mean with “LTO was set up”
oh and edgeWebViewUpdater will stay active if rhino 8 is closed and the wineserver will not shutdown until it is killed manually. This is a little annoying but could be worked around by kill it in the shell script with is starting rhino.
I’ve also been troubleshooting on arch over the last few days, nice to see you got it figured out on your box.
However I did observe some different behavior (an unhandled exception was thrown instead of a stack overflow) which was pretty interesting. Doing some more testing with the reserved stack space to confirm why that happened.