the LTO stuff was just Arch’s makepkg.conf injecting -flto=auto into the default CFLAGS/LDFLAGS which is different behavior than what was happening in my ubuntu environment. I got a mix of LTO-IR objects and regular objects that couldn’t link together. The fix was to export -fno-lto in CFLAGS/LDFLAGS in the project’s PKGBUILD file.
did not tested it before you asked 
the menu u shown is working fine, the middle click and submenus are not hide in seconds and the help text is not black as in rhino7 on the same device. all i see it is much better than in rhino7
but…
the optionmenu of the gumball is all black
ok really strange that i do not needed it. but since now you have a segfault again maybe it is not the right fix?
Check out my edit. I forgot to apply the .dll patch (worked once I did that) but prior to applying it I actually saw different behavior which I’m investigating now. The LTO stuff was just for the installer not working.
Ok, I’ve got it working in a seemingly stable state on Arch at the moment. No UI glitches so far to note CC @ThomasAn. There seems to be some weirdness going on when i run a command & actually seeing the result. For example - I did a boolean diff on these objects and the command executed successfully however the viewport didn’t show the result until i rotated the screen with right click, so potentially some issue with how wayland interacts with how Rhino wants to render the frame? Will investigate further…
The weird behavior I saw when first testing it on Arch seems to confirm that the initial stack overflow crash was the result of the darkmode infinite recursion issue, however the darkmode overflow caused the wine signal handler to overflow as well. Adjusting the stack size without fixing the darkmode recursion results in a cleaner exception handling: virtual_setup_exception vs the original STATUS_STACK_OVERFLOW. I’m posting these details to the repo & all other changes I did to get it working on Arch.
@atelierkirchhof I’d love to see what changes you needed to make to get the installer working, if you wanted to make an issue on the repo! And it makes sense now that you didn’t run into any issues with launching it since those steps were sound.
My system info:
Operating System: Arch Linux
KDE Plasma Version: 6.6.5
KDE Frameworks Version: 6.26.0
Qt Version: 6.11.1
Kernel Version: 7.0.10-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7800X3D 8-Core Processor
Memory: 64 GiB of RAM (61.9 GiB usable)
Graphics Processor 1: NVIDIA GeForce RTX 4070 SUPER/PCIe/SSE2
Graphics Processor 2: NVIDIA GeForce RTX 4070 SUPER/PCIe/SSE2
Manufacturer: ASUS
With these mods to wine, if Rhino8 runs then Rhino9 would too ? Have you guys tried it ?
If Rhino9 runs too, then I may be tempted to upgrade for the first time in years.
Haven’t tried it with Rhino9 yet, if i have time this week I’ll give it a shot now that this is in a decent spot.
Depending on what that fix looks like, can look into requesting to merge into wine mainline.
The other topic mentioned several fixes, however they depend on the graphics driver and/or display manager, so results may vary. At least these didn’t work for me using Arch/Wine/Rhino7/Wayland/Nvidia
- disable theming in winecfg/regedit
- disable vblank
Also maybe worth trying:
- “Wine experimental Wayland mode” (instead of XWayland)
- Rhino 9 WIP with Direct 3D instead of OpenGL (if it even runs - maybe needs a similar patch to Rhino 8)
Thanks for figuring all this out @ItHasLegs! I applied the patches and was able to run Rhino 8 in NixOS with Hyprland as the wm. Some things (like the C# code editors) don’t seem to be working, but from clicking around I think it is 80% of the way to something I would use and trust. (For some reason I no longer have to hover over a viewport for it to update, they all do it instantly).
I had limited success running Rhino 9 so far and the patched darkmode function is at a different location. I found that applying the same patch at file offset 0x136040 allows you to get to the license screen. After clicking continue there is a new unhandled exception, I’ll have to look through that later to see whats going on, but in the meantime it seems like R9 can likely happen too!
Okay, to follow up on myself here: Rhino 9 WIP launches fine if you set WINEDLLOVERRIDES="wbemprox,wmiutils,wminet_utils=" and do the patch at the offset in my last comment. Changes to the prefix will have to be made to support the new graphics system, as can be seen with the mesh confetti in the viewport (it should look the same as the last scene, both are the default arcade grasshopper example). Grasshopper 2 seems promising, I have a visual bug (and then sometimes a crash) when trying to use the menu bar dropdowns, but playing around with components showed very few other broken issues, and arguably better rendering than the grasshopper canvas.
Edit: Added another image of viewport showing meshes and points in default mode, everything in rendered mode, and all objects in render preview. It could be an integrated graphics issue, if someone with AMD could test it out that may shed some light.
It took some real banging on other errors with Claude, but @ItHasLegs work got me 90% of the way there. It still has the same viewport weirdness common to many people using Rhino via Wine, and the same focus issues of any TWM (like my Sway), but Rhino works as does Grasshopper - this is truly a momentous day!
Now to see if the same process will get the WIP up and running. Thank you so much again, @ItHasLegs !
I copied my Rhino 8 prefix (in other words I’m using the wine build from ), applied some of the magic patches provided by Claude and GOT RHINO WIP WORKING AS WELL. I’m having some input issues, but that’s all due to the way Sway handles pop-ups. I’ll sort it out.
Grasshopper runs fine, just like in 8. And Grasshopper 2 seems to work well when you pick components from the menus, but crashes when you try to use the double-click search bar. Rhino also crashes when you try to change the color of a layer or the default material.
But nonetheless, a big day again!
Do you mind sharing system specs / specific patches you used to get WIP working? It looks like your viewports are displaying geometry a lot better than mine were!
i have added some errors on the github issue-tracker about some problems i run into it. maybe it would be the best to collect the errors and fixes there to have a clean separation of with error is already fixed somewhere or is just happen on some setups and so on:
sadly there still some deal breakers for me. Some menus are all black. I really like to know if this is just on my system or on any system.
Tantalus was a king in a Greek myth where he was punished by the Gods to being perpetually thirsty while tied waist deep in a pool of clear water. When he bent to drink, the water would drop.
Rhino runs on Wine just enough to tease you, but not enough (by a hair) to trust it for work projects.
I have used 7 quite extensively in production work.
I had to get into the habit of clicking on the view name to get the viewport to regenerate, and had to set up a keyboard shortcut to bring back focus when it got weirdly stolen (because I use a TWM which does that kind of thing). Oh, and the open/save dialog sucks. But with those small caveats or workarounds, I’ve been able to work quite effectively in 7, even doing some pretty intense grasshopper. From what little I’ve used it, 8 seems to function almost identically.
Would a Linux-native version be ideal? Absolutely. But I am at least able to do real work with it via wine.
With enough determination we can pretend a lot of things are good enough.
Okay, I had Claude gather together all the steps it had to help me take to get Rhino 8 working smoothly on Debian (Trixie) via wine. Note that the patches are per-release, so these might need adjusted when McNeel releases a new version. (I don’t know if that applies to minor releases, I guess we’ll see.)
My 9 WIP is currently broken due to something with contacting the McNeel servers that I haven’t had time to iron out yet. But as you can see form above, it was displaying at first. Even though it had the material / color change issues that make it unusable. I will update as fixes are found.
Mind you everything below (other than the fetch screenshot) is directly generated by Claude. I have reviewed it to ensure it’s the process I followed and that the scripts it generates are the ones I used successfully. Many steps below may be duplications of the excellent work done by @ItHasLegs , so follow that guide first and foremost. Most of these steps are probably required by my specific distro and display system. You may not need to take some of these steps, but you may have to take others not included here. So PLEASE review which steps you need to take on YOUR system. Anthropic, McNeel, and I are not liable for any issues caused by using the code below without reviewing for fitness to your own system and application.
–Duane McLemore, AIA
Xover0 dot com
Running Rhino 8 (and Rhino 9 WIP) on Debian Trixie — Supplementary Notes
Beyond the rhino8-wine instructions
These notes document additional steps required to get Rhino 8.32 and Rhino 9 WIP running on Debian GNU/Linux 13 (Trixie) x86_64, Sway 1.10.1 (Wayland), with an NVIDIA RTX 4070 + AMD Ryzen 9 9950X.
Part 1: Build Dependencies
The following packages differ from what the rhino8-wine README specifies on Debian Trixie:
vulkan-headers does not exist — replace with:
libvulkan-dev
libgstreamer1.0-dev and libgstreamer-plugins-base1.0-dev — these names are correct for Trixie but require apt update to run cleanly first. Any 404 errors during update will cause packages to appear missing.
Part 2: Wineprefix Setup
After building and installing /opt/wine-rhino8, create the prefix:
mkdir -p ~/.local/share/wineprefixes/rhino8
export WINEPREFIX=~/.local/share/wineprefixes/rhino8
export WINE=/opt/wine-rhino8/bin/wine
WINEPREFIX=$WINEPREFIX WINEDEBUG=-all $WINE wineboot
Set Windows version to Windows 10 in winecfg:
WINEPREFIX=$WINEPREFIX $WINE winecfg
Part 3: Dependencies via Winetricks
Use the patched Wine binary explicitly:
WINEPREFIX=$WINEPREFIX \
WINE=/opt/wine-rhino8/bin/wine \
WINESERVER=/opt/wine-rhino8/bin/wineserver \
winetricks corefonts dotnet48 vcrun2022 gdiplus
Note: winetricks will report a SHA256 mismatch for vc_redist.x86.exe — this is a stale checksum for a legitimately updated Microsoft package. Answer Y to continue.
Part 4: Manual DLL Installation
Winetricks only installs the x86 vcredist. Extract and install x64 dlls manually:
# Extract x64 vcredist
wget -O ~/Downloads/vc_redist.x64.exe \
"https://download.visualstudio.microsoft.com/download/pr/64760cc4-228f-48e4-b57d-55f882dedc69/b181f927cb937ef06fbb6eb41e81fbd0/windowsdesktop-runtime-8.0.14-win-x64.exe"
mkdir /tmp/vcredist_x64 /tmp/vcredist_inner
cabextract -d /tmp/vcredist_x64 ~/Downloads/vc_redist.x64.exe
for f in /tmp/vcredist_x64/a*; do
cabextract -d /tmp/vcredist_inner "$f" 2>/dev/null
done
SYSTEM32=$WINEPREFIX/drive_c/windows/system32
for dll in msvcp140 msvcp140_1 msvcp140_2 vcruntime140 vcruntime140_1 concrt140 mfc140 mfc140u; do
cp "/tmp/vcredist_inner/${dll}.dll_amd64" "$SYSTEM32/${dll}.dll" 2>/dev/null
done
Extract and install x86 dlls into syswow64:
mkdir /tmp/vcredist_x86 /tmp/vcredist_x86_inner
wget -O ~/Downloads/vc_redist.x86.exe "https://aka.ms/vs/17/release/vc_redist.x86.exe"
cabextract -d /tmp/vcredist_x86 ~/Downloads/vc_redist.x86.exe
for f in /tmp/vcredist_x86/a*; do
cabextract -d /tmp/vcredist_x86_inner "$f" 2>/dev/null
done
SYSWOW64=$WINEPREFIX/drive_c/windows/syswow64
for dll in msvcp140 msvcp140_1 msvcp140_2 vcruntime140 concrt140 mfc140 mfc140u; do
cp "/tmp/vcredist_x86_inner/${dll}.dll_x86" "$SYSWOW64/${dll}.dll" 2>/dev/null
done
Copy gdiplus to syswow64 (required for the Rhino installer):
cp $WINEPREFIX/drive_c/windows/system32/gdiplus.dll \
$WINEPREFIX/drive_c/windows/syswow64/gdiplus.dll
Set gdiplus dll override:
WINEPREFIX=$WINEPREFIX $WINE reg add \
"HKCU\\Software\\Wine\\DllOverrides" \
/v "gdiplus" /t REG_SZ /d "native,builtin" /f
Part 5: .NET 8 Runtime
The Rhino installer cannot install .NET 8 successfully under Wine. Install manually by extracting the zip directly into the prefix:
wget -O ~/Downloads/dotnet8-desktop.zip \
"https://builds.dotnet.microsoft.com/dotnet/WindowsDesktop/8.0.14/windowsdesktop-runtime-8.0.14-win-x64.zip"
DOTNET_DIR="$WINEPREFIX/drive_c/Program Files/dotnet"
mkdir -p "$DOTNET_DIR"
unzip ~/Downloads/dotnet8-desktop.zip -d "$DOTNET_DIR"
Verify all three runtime packs are present:
ls "$DOTNET_DIR/shared/"
# Should show: Microsoft.AspNetCore.App Microsoft.NETCore.App Microsoft.WindowsDesktop.App
Part 6: Rhino Installer
WINEPREFIX=$WINEPREFIX $WINE ~/Downloads/rhino_en-us_8.32.26160.13001.exe
After installation completes, restart the wineserver:
WINEPREFIX=$WINEPREFIX /opt/wine-rhino8/bin/wineserver -k
Part 7: rhcommon_c.dll Binary Patches (Rhino 8.32)
The rhino8-wine README documents the dark mode patch offset for an earlier build. Rhino 8.32 requires patching at different offsets. Find the correct offsets using:
DLL="$WINEPREFIX/drive_c/Program Files/Rhino 8/System/rhcommon_c.dll"
objdump -p "$DLL" 2>/dev/null | grep -E "DarkMode|ObjectIterator_Initialize"
objdump -p "$DLL" 2>/dev/null | grep "Export RVA" | sed -n '<ordinal>p'
objdump -h "$DLL" | grep "\.text"
# file_offset = RVA - 0xc00 (for standard .text section layout)
For Rhino 8.32, the correct file offsets are:
| Export | File Offset |
|---|---|
RHC_RhOSInDarkMode |
0xdf410 |
CRhAdvancedSettings_DarkMode |
0x97920 |
RhColors_GetDefaultWindowsDarkMode |
0x97930 |
RhColors_GetDefaultDarkOrLightColor |
0x97980 |
CRhinoObjectIterator_Initialize |
0xae070 |
Apply all patches:
DLL="$WINEPREFIX/drive_c/Program Files/Rhino 8/System/rhcommon_c.dll"
cp "$DLL" "$DLL.bak"
for offset in df410 97920 97930 97980 ae070; do
printf '\x31\xc0\xc3\x90\x90\x90\x90' | \
dd of="$DLL" bs=1 seek=$((16#$offset)) conv=notrunc
done
Why CRhinoObjectIterator_Initialize? In Rhino 8.32, the Layers panel calls this function during OnNewDocument to iterate objects in a new empty document. Under Wine, this causes an access violation. Patching it to return 0 immediately prevents the crash with no visible side effect on an empty document.
Part 8: OAuth Licensing
The browser won’t open automatically under Sway/Wayland. Capture the OAuth URL manually:
WINEPREFIX=$WINEPREFIX \
WINEDEBUG=+exec \
$WINE "$WINEPREFIX/drive_c/Program Files/Rhino 8/System/Rhino.exe" \
> /tmp/rhino-auth.log 2>&1 &
sleep 45 && grep -i "accounts.rhino" /tmp/rhino-auth.log | head -3
Check that port 1717 is listening before opening the URL:
ss -tlnp | grep 1717
Then paste the URL into your browser and complete the McNeel login. If port 1717 never binds, kill the wineserver and relaunch with --fresh.
Part 9: Launch Script
The original run-rhino.sh works but add WINIT_UNIX_BACKEND=x11 for correct window placement under Sway:
DISPLAY="${DISPLAY:-:0}" \
WINIT_UNIX_BACKEND=x11 \
WINEPREFIX="$WINEPREFIX" \
WINEDEBUG=-all \
"$WINE" "$RHINO" 2>/tmp/rhino.log
Part 10: Rhino 9 WIP (Bonus)
Copy the working Rhino 8 prefix as a base:
cp -r ~/.local/share/wineprefixes/rhino8 ~/.local/share/wineprefixes/rhino9
export WINEPREFIX9=~/.local/share/wineprefixes/rhino9
Install Rhino 9 WIP into it:
WINEPREFIX=$WINEPREFIX9 $WINE ~/Downloads/rhino_9.0.26160.12305.exe
Fix ICU dll forwarding issue (Rhino 9 specific):
cp /opt/wine-rhino8/lib/wine/x86_64-windows/icuuc.dll \
$WINEPREFIX9/drive_c/windows/system32/icuuc.dll
cp /opt/wine-rhino8/lib/wine/x86_64-windows/icuin.dll \
$WINEPREFIX9/drive_c/windows/system32/icuin.dll
# Copy icu.dll from rhino8 prefix
cp $WINEPREFIX/drive_c/windows/system32/icu.dll \
$WINEPREFIX9/drive_c/windows/system32/icu.dll
cp $WINEPREFIX/drive_c/windows/syswow64/icu.dll \
$WINEPREFIX9/drive_c/windows/syswow64/icu.dll
Apply rhcommon_c.dll patches for Rhino 9 WIP (9.0.26160):
DLL9="$WINEPREFIX9/drive_c/Program Files/Rhino 9 WIP/System/rhcommon_c.dll"
cp "$DLL9" "$DLL9.bak"
for offset in e84e0 1018b0 136040 e8540 e84f0; do
printf '\x31\xc0\xc3\x90\x90\x90\x90' | \
dd of="$DLL9" bs=1 seek=$((16#$offset)) conv=notrunc
done
Fix GH2 search bar / WPF text crash (PresentationNative_cor3.dll):
PNDLL="$WINEPREFIX9/drive_c/Program Files/dotnet/shared/Microsoft.WindowsDesktop.App/10.0.2/PresentationNative_cor3.dll"
cp "$PNDLL" "$PNDLL.bak"
printf '\x31\xc0\xc3\x90\x90\x90\x90' | \
dd of="$PNDLL" bs=1 seek=$((16#3c740)) conv=notrunc
Known remaining issues with Rhino 9 WIP:
- Wireframe/Shaded/Rendered viewports don’t display geometry (OpenGL mode works)
- GH2 color picker dialogs crash (WPF text rendering limitation)
- Occasional startup hang requiring wineserver restart
Finding Patch Offsets for Future Rhino Versions
When McNeel releases a new build, offsets will change. Find them with:
# Get ordinals for dark mode and iterator exports
objdump -p "$DLL" 2>/dev/null | grep -E "DarkMode|ObjectIterator_Initialize|GetDefaultDarkOrLightColor|GetDefaultWindowsDarkMode"
# Get RVA for ordinal number N (replace N with the number from above)
objdump -p "$DLL" 2>/dev/null | grep "Export RVA" | sed -n 'Np'
# Get section offset mapping
objdump -h "$DLL" | grep "\.text"
# file_offset = RVA - (VMA - fileoff)
# For standard layout this is typically RVA - 0xc00
# Verify it's a function prologue before patching
xxd -s <file_offset> -l 16 "$DLL"
# Should start with 48 89, 40 53, 55 48, or similar x64 prologue bytes
# If it looks like garbage or data, the offset is wrong — do not patch
The patch bytes \x31\xc0\xc3\x90\x90\x90\x90 decode as xor eax, eax; ret; nop; nop; nop; nop — they make the function immediately return 0 (false/null), breaking recursive calls and preventing crashes from unimplemented Wine stubs.
Nice stuff everyone 
I just tested Rhino9 WIP as well and ran into almost the same issues as everyone else here that’s tried rhino9 so far. Also needed to change the darkmode offset to 0x136040 like @dkeners mentioned. I also had a graphics issue that I maybe fixed by switching the GPU technology option from Direct3D to OpenGL. That seemed to bring me back to the viewport delay issue I was experiencing with rhino8. Haven’t had time to test that yet. But the overall fix seems to be pretty similar. Rhino9 seems to have more bugs for me though, I didn’t push it too hard but I got some weirdness when running commands and clicking through the options. Didn’t investigate too much though.
I pushed an update to the repo including a script to find the memory offset. Claude had the same idea as @duanemclemore’s for this.
@atelierkirchhof thanks for adding your issues. If I have time I’ll try and go through and test other systems like those mentioned in this thread to document the various minor differences & fixes required.
I’ll keep tinkering with improving the performance when I have time. The next thing I want to do however is to investigate why the darkmode API call in the rhcommon_c.dll file causes an infinite recursion. I’m curious what the actual issue is here.
Another update - I spent some time figuring out the actual reason for the darkmode infinite recursion and was actually able to narrow the patch scope a bit. We don’t need to patch any .dll files from Rhino at all.
I followed the problem call in rhcommon_c.dll to Rhino’s OS dark-mode probe (RhOSInDarkMode in RhinoCore.dll) which resolves four undocumented uxtheme.dll immersive-color exports (ordinals) at runtime. Wine doesn’t seem to have a mapping for these set up so the probe fell back to its own managed callback that re-entered it, recursing until stack overflow. The fix was adding a reference to the missing exports in Wine’s uxtheme. The result is Rhino launches cleanly without needing to apply any .dll patches. Also, I checked where else these ordinals were referenced (wondered if this also could be impacting some other visual weirdness others experienced) and they were called a few times elsewhere, but not sure in what way.
I pushed the fix to the repo which slims down the instructions to run a bit which is nice. This is also seems like a more specific issue with Wine that might be worth trying to open a pull request for. I’ll keep working on this though and see if there are any other issues since the memory allocation stack changes in virtual.c and thread.c might be different problems. virtual.c is likely a non-issue anymore and can be reverted (but still testing this). However the thread.c (installer) issue is a bit more weird and I need to check that more.
Here are the missing ordinals:
| field | uxtheme export | how it’s looked up |
|---|---|---|
| +0x18 | GetImmersiveColorFromColorSetEx |
by name |
| +0x20 | GetImmersiveUserColorSetPreference |
by name |
| +0x28 | GetImmersiveColorTypeFromName (ordinal 96) |
by ordinal |
| +0x30 | GetImmersiveColorNamedTypeByIndex (ordinal 100) |
by ordinal |