winbox-mac
winbox-mac copied to clipboard
nrlquaker
Winbox just sits bouncing in the dock
Checklist
- [ x ] I understand that if I ignore these instructions, my issue may be closed without review.
- [ x ] I made sure this is not the original Winbox issue.
Describe the bug Upon opening Winbox just site bouncing in Dock. 2 or 3 attempts to open will eventually get it working.
To Reproduce Double click to open
Expected behavior It should open first go :D
Screenshots
Desktop (please complete the following information):
- macOS version: 13.6
- macOS language English
- Winbox-mac version 3.39.0
- Winbox version ?? can't open it to find out
Additional context
I have a same trouble (m1pro)
macOS version: 14.1.1 (23B81)
macOS language English
Winbox-mac version 3.39.0
Winbox version 3.39.0
I'm experiencing problems launching (icon keeps bouncing forever, window is hidden), then when launched, I often can't click any element of the window (which is buried under everything else). This is new behaviour after years of use with no problems. (love the project, thanks so much!
macOS version: 13.4.1 (c) (22F770820d) macOS language: English Winbox-mac version: 3.40
Checklist
- [ x ] I understand that if I ignore these instructions, my issue may be closed without review.
- [ x ] I made sure this is not the original Winbox issue.
Describe the bug Upon opening Winbox just site bouncing in Dock. 2 or 3 attempts to open will eventually get it working.
To Reproduce Double click to open
Expected behavior It should open first go :D
Screenshots
Desktop (please complete the following information):
- macOS version: 13.6
- macOS language English
- Winbox-mac version 3.39.0
- Winbox version ?? can't open it to find out
Additional context . Open the folder with Winbox application (/Applications/), hold ctrl + shift and double click on Winbox-mac.app. For me this workaround works for now.
Updated today (using brew) from 3.38 to 3.40 and now I have the same problem. Can't click anywhere in the window:
❯ brew info --cask nrlquaker-winbox ==> nrlquaker-winbox: 3.40.0 https://github.com/nrlquaker/winbox-mac/ /opt/homebrew/Caskroom/nrlquaker-winbox/3.40.0 (124B) From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/n/nrlquaker-winbox.rb
❯ sw_vers
ProductName: macOS
ProductVersion: 14.1.1
BuildVersion: 23B81
Additional info: Tried completely removing it and installing from 0 , now it works. This leads me to think, it is somehow related to the "winbox settings migration" that happened between these versions.
When killed it leaves behind all these processes:
xxx 27571 2.3 0.1 36576292 8872 ?? Ss 3:03pm 0:02.42 /Applications/Winbox-mac.app/Contents/Resources/wine/lib/wine/../../bin/wine64-preloader C:\windows\system32\winedevice.exe
xxx 27643 0.0 0.0 408626896 1392 s000 S+ 3:04pm 0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox wine
xxx 27563 0.0 0.1 36559404 5576 ?? Ss 3:03pm 0:00.15 /Applications/Winbox-mac.app/Contents/Resources/wine/lib/wine/../../bin/wine64-preloader C:\windows\system32\plugplay.exe
xxx 27561 0.0 0.0 36508140 3728 ?? Ss 3:03pm 0:00.03 /Applications/Winbox-mac.app/Contents/Resources/wine/lib/wine/../../bin/wine64-preloader C:\windows\system32\svchost.exe -k LocalServiceNetworkRestricted
xxx 27526 0.0 0.1 36545960 5096 ?? Ss 3:02pm 0:00.07 /Applications/Winbox-mac.app/Contents/Resources/wine/lib/wine/../../bin/wine64-preloader C:\windows\system32\winedevice.exe
xxx 27522 0.0 0.2 36662772 17452 ?? S 3:02pm 0:00.42 /Applications/Winbox-mac.app/Contents/Resources/wine/lib/wine/../../bin/wine64-preloader C:\windows\system32\explorer.exe /desktop
xxx 27508 0.0 0.0 36509244 4084 ?? Ss 3:02pm 0:00.08 /Applications/Winbox-mac.app/Contents/Resources/wine/lib/wine/../../bin/wine64-preloader C:\windows\system32\services.exe
which I kill with:
sudo killall -9 wine64-preloader
I tried brew remove and brew install but it still bounces. What would be the steps to fully purge-remove the app and any dependencies and reinstall from scratch? It does seem that stale processes of wine64-preloader may be the cause. Why are these getting left running?
I tried brew remove and brew install but it still bounces. What would be the steps to fully purge-remove the app and any dependencies and reinstall from scratch? It does seem that stale processes of wine64-preloader may be the cause. Why are these getting left running?
I had my first installation on a clean system, I got the problem right away :(
Have same problem on M1 Mac's and Intel as well. Winbox often starts bouncing few times in a row and then start fine..
Hey y'all -
Appreciate everyone's feedback on this. This has been hard to reproduce as it's been so inconsistent. Prior to joining the project, I too was having this issue, but now I don't, and I'm not doing any hacks or workarounds to get around it these days. There may be some race condition with the Rosetta 2 JIT that's causing headaches with Wine, which also might explain why things start working okay after a few launches. That might explain why a quick kill of the Dock icon after launching causes the app to load (but then leaves around disowned Wine process remnants).
For folks watching this issue:
- Please report whether your Mac is an Apple Silicon or Intel Mac. This will help us figure out if this is related to Rosetta 2 at all.
- If you are encountering the bouncing icon, try the following:
- Open the app, then leave it bouncing for a good minute, then Force Close the process. This is an attempt to build the Rosetta 2 JIT cache
- Check for remnant Wine processes. Fastest way is via terminal -
ps ax | grep wine, then issuekills for every process ID that shows up. Note, this will show any other Wine processes you're running, so if you run more Wine-wrapped apps on macOS, be careful here. If you're not comfortable with this, you can restart your computer to achieve the same goal. - Relaunch the app, and see if it now launches appropriately.
Intel Mac, Ventura 13.6.4
Faced with forever bouncing icon and ran through these steps:
- removed with brew
- removed folder
~/Library/Application Support/com.mikrotik.winbox - reinstalled with brew
- cleared quarantine attribute with
xattr -d com.apple.quarantine /Applications/Winbox-mac.app
It started on the first run, but on the next launch got bouncing icon again
@belthesar I have this issue sometime. I'm on M1. I just force close and launch the app again and its working fine.
@belthesar I have this issue sometime. I'm on M1. I just force close and launch the app again and its working fine.
Same here.
EDIT: Interesting: I update to 3.40 and on first time i got Privacy dialog. Maybe i do not have some privacy rights done right?
Now i cant got bouncing again. I will see.
EDIT: Ok i got bouncing again after 5 reopens.
All, Facing the same issue, seems to be introduced after upgrade wine and/or to winbox 3.40.... It has something to do with the network connectivity, when you disable network connections, start winbox-mac and then re-enable network it keeps working. Did not have the change to narrow it down to wine or winbox.
When killed it leaves behind all these processes:
xxx 27571 2.3 0.1 36576292 8872 ?? Ss 3:03pm 0:02.42 /Applications/Winbox-mac.app/Contents/Resources/wine/lib/wine/../../bin/wine64-preloader C:\windows\system32\winedevice.exe xxx 27643 0.0 0.0 408626896 1392 s000 S+ 3:04pm 0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox wine xxx 27563 0.0 0.1 36559404 5576 ?? Ss 3:03pm 0:00.15 /Applications/Winbox-mac.app/Contents/Resources/wine/lib/wine/../../bin/wine64-preloader C:\windows\system32\plugplay.exe xxx 27561 0.0 0.0 36508140 3728 ?? Ss 3:03pm 0:00.03 /Applications/Winbox-mac.app/Contents/Resources/wine/lib/wine/../../bin/wine64-preloader C:\windows\system32\svchost.exe -k LocalServiceNetworkRestricted xxx 27526 0.0 0.1 36545960 5096 ?? Ss 3:02pm 0:00.07 /Applications/Winbox-mac.app/Contents/Resources/wine/lib/wine/../../bin/wine64-preloader C:\windows\system32\winedevice.exe xxx 27522 0.0 0.2 36662772 17452 ?? S 3:02pm 0:00.42 /Applications/Winbox-mac.app/Contents/Resources/wine/lib/wine/../../bin/wine64-preloader C:\windows\system32\explorer.exe /desktop xxx 27508 0.0 0.0 36509244 4084 ?? Ss 3:02pm 0:00.08 /Applications/Winbox-mac.app/Contents/Resources/wine/lib/wine/../../bin/wine64-preloader C:\windows\system32\services.exewhich I kill with:
sudo killall -9 wine64-preloader
Thank you！
The newest version is on the verge of being unusable. It freezes all the time requiring a restart of the application, which in 90% of the cases results in just bouncing in the dock.
As a workaround, downgrading to v3.38.0 seems to be working:
brew install --cask \
https://raw.githubusercontent.com/Homebrew/homebrew-cask/654e2ee813639bb419344999a6207bcefd072954/Casks/nrlquaker-winbox.rb
The newest version is on the verge of being unusable. It freezes all the time requiring a restart of the application, which in 90% of the cases results in just bouncing in the dock.
As a workaround, downgrading to v3.38.0 seems to be working:
brew install --cask \ https://raw.githubusercontent.com/Homebrew/homebrew-cask/654e2ee813639bb419344999a6207bcefd072954/Casks/nrlquaker-winbox.rb
@belthesar Can you please check this?
Seems like 3.38.0...3.40.0 diff have only this critical update update Wine to devel 8.10..
Maybe its worth to update to wine 9.0 stable.
@Gcenx can you pease provide latest minimal build?
I actually stopped using this bottled app due to stability problems, and also accessibility reasons (maximum font size was occasionally too small for me depending on how long I'd been awake / how tired my eyes are).
I just installed Wine 9 (which is current "stable"), and continued to have stability problems, although seemingly less of them. The benefit is with my own full Wine environment, I can use "winecfg" and set the window/font scaling factor, which helps immensely with readability. (I'm using 120dpi instead of whatever the default is, I think 96 or 72?)
However, I'm still having stability issues when using winbox64 on my own installation of wine9 stable.
It seems like 32-bit Winbox behaves a little better, so far, for reasons I can't explain?? (I've only been testing it for about an hour now so I can't be 100% sure yet.)
Worth noting that under wine9 "stable," when loading winbox64 from CLI, Wine throws up some warning messages saying that "wow64 mode is still in testing" or something along those lines... so maybe it would behoove this project to fall back to using the 32-bit winbox? I don't believe there are any feature differences between the two builds.
@belthesar Can you please check this? ...
The app does seem to launch fine, but oddly enough, I've also been having fine launches every time I've been using 3.40, and I've been in and out of Winbox quite regularly, which has made finding the root of this all the more frustrating. I'll play with bringing in Winbox 3.40 into this version of Wine to see if I get any issues.
I actually stopped using this bottled app due to stability problems, and also accessibility reasons (maximum font size was occasionally too small for me depending on how long I'd been awake / how tired my eyes are).
I'm really sorry to hear that. This is a bit of a passion project, and not officially supported, but trying to provide good support is important. It's worth noting that it is possible to launch winecfg.exe inside of the project's Wine prefix, but we don't really expose an ergonomic way to do it. In your case, I do think it's probably better to use a home grown Wine setup for this. I'm glad you found a way to get what you need done while also having the interface at a size that is useful for your setup.
I won't lie, with the advent of the new REST API, I've tinkered with the idea of building a wholly separate app to Winbox using that API instead of shoehorning the use of Winbox in Wine, but to be honest, I just don't use the hardware enough to justify it. If I was supporting a fleet of Tiks in production for work, I could justify it, but I largely use it for personal networking gear, and as such, I have other projects that need the time I'd dedicate to writing and supporting an alternative Mikrotik admin app.
maybe it would behoove this project to fall back to using the 32-bit winbox?
I believe the reason the project switched to the winbox64 over winbox was the lack of 32-bit libs in macOS user space since Catalina. @Gcenx does have a wine32on64 compatibility shim that could potentially be used to make this work, but that would be a tradeoff with the minimal WINE install that is shipped with the app bundle. It would require some testing to see if it's useful. As it stands today, we can't simply drop in winbox.exe into the bundle and use it with the current Wine version.
I actually stopped using this bottled app due to stability problems, and also accessibility reasons (maximum font size was occasionally too small for me depending on how long I'd been awake / how tired my eyes are).
I'm really sorry to hear that. This is a bit of a passion project, and not officially supported, but trying to provide good support is important. It's worth noting that it is possible to launch
winecfg.exeinside of the project's Wine prefix, but we don't really expose an ergonomic way to do it. In your case, I do think it's probably better to use a home grown Wine setup for this. I'm glad you found a way to get what you need done while also having the interface at a size that is useful for your setup.
My comments were not meant as a slight against the project at all, I'm truly sorry if they came off that way! I really love the nice "bottled" aspect of it and not having to screw with Wine directly, but I went off on my own primarily for the visual aspect (which isn't a huge problem until I've been working for too long and trying to stare at the poorly differentiated lines in Winbox output...) . 😄 I'm with you 100% on the frustrating nature of the problems with it, too. My employer uses Mikrotik extensively so I am in Winbox a lot, and the weird behaviors of what I would think should be a simple app to run are frustrating.
I won't lie, with the advent of the new REST API, I've tinkered with the idea of building a wholly separate app to Winbox using that API instead of shoehorning the use of Winbox in Wine, but to be honest, I just don't use the hardware enough to justify it. If I was supporting a fleet of Tiks in production for work, I could justify it, but I largely use it for personal networking gear, and as such, I have other projects that need the time I'd dedicate to writing and supporting an alternative Mikrotik admin app.
If I had coding chops I would be onboard to help here, but I'm strong on networking / server admin / troubleshooting and not so great on development. :p My Winbox "devices list" has ~145 items in it, all for work...
maybe it would behoove this project to fall back to using the 32-bit winbox?
I believe the reason the project switched to the winbox64 over winbox was the lack of 32-bit libs in macOS user space since Catalina. @Gcenx does have a wine32on64 compatibility shim that could potentially be used to make this work, but that would be a tradeoff with the minimal WINE install that is shipped with the app bundle. It would require some testing to see if it's useful. As it stands today, we can't simply drop in winbox.exe into the bundle and use it with the current Wine version.
Hmm. I'm on Sonoma 14.3.1 with an M1 Pro MBP, and it seems like 32-bit winbox has no problems running on Wine9. But, I'm also seeing background processes starting under the "wine64-preloader" rather than just "wine-preloader," so maybe I am actually "thunking" rather than running 32-bit native (makes sense, given what you said about lack of 32-bit macOS libs). This doesn't explain why the 32-bit winbox seems more stable than 64-bit though. I was originally thinking that when running a 32-bit Windows exe, Wine would run all of the necessary fake Windows pieces in 32-bit mode, and maybe this was a better-tested codepath than running the Windows emulation in 64-bit mode.
If I had coding chops I would be onboard to help here, but I'm strong on networking / server admin / troubleshooting and not so great on development. :p My Winbox "devices list" has ~145 items in it, all for work...
Heard! I'm an infrastructure engineer at $dayjob, but spending more of my time in public clouds than I am on physical infra these days. Still trying to keep things hybrid and cost effective, but in general I'm definitely spending less time on networking hardware than I used to be. That said, I've been doing a lot more software work and I enjoy it, so while I'm not scared of the work, I also know that I likely wouldn't be able to release it, or if I did, with huge caveats.
Hmm. I'm on Sonoma 14.3.1 with an M1 Pro MBP, and it seems like 32-bit winbox has no problems running on Wine9.
My guess is that gcenx's full Wine for Mac builds come with the wine32on64 subsystem necessary to make this work, and it's by virtue of it that it runs, because Rosetta 2 doesn't provide 32-bit x86 emulation. It might be worthwhile to see if the slimmed down Wine is actually causing harm here (although it still seems like it's a mixed bag given how inconsistent this has been). And while Rosetta 2 might seem to be some sort of smoking gun, we've had reports of users experiencing this on Intel Macs as well, so it's certainly not there either.
Your thoughts on wine32 being far more battle tested are sound, although especially with the flood of new exercise it's been getting thanks to Proton, wine64 is a pretty solid option.
I think we may need to try and attach a debugger to actually see what's going on here, and that's a mixed bag with Wine on Linux, let alone macOS, but I think it's about the best chance that we have to see what the heck is actually happening under the hood, since when I have been able to reproduce the issue, logs emitted related to Winbox have been less than helpful.
If it helps at all, I can tell you that my failure points have been all over the map, too. Sometimes it will be connected to a router and running fine, and then the GUI just freezes and I can't do anything with it. I have to force quit the main "app" from the Dock, and it then leaves lots of wine64-preloaders sitting around that are chewing CPU for no reason. sudo killall -9 wine64-preloader, and then I can usually fire it up again and it works correctly... until it freezes again. I've even had it "freeze" while just sitting at the address chooser (although I expect it might still be refreshing the "neighbors" tab in the background in that case, so maybe that is contributing to it?)
Other times it will simply never load the initial winbox chooser GUI...
When it freezes up, the outer window still moves, and MacOS doesn't think the process is hung. But you can't click into the Winbox GUI, no controls react, and if there was something displaying info, it stops refreshing. I've also seen weirdness with the "open in new window" checkbox from the main address chooser - when you enable it, it's like Winbox tries to spawn a new window but that window never gets a GUI/frame from Wine, and eventually it self-disconnects from whatever router it was on (because no window appears?) and you're back at the Addresses list again.
It's really a shame that Mikrotik can't put some of their own development resources into making a proper cross-platform app for this.
I did just get a hang/freeze while sitting at the address list for a while on the 32-bit winbox, so I guess that's no panacea here either. :(
It's really a shame that Mikrotik can't put some of their own development resources into making a proper cross-platform app for this.
Funny you mention this, I just started perusing the Winbox 3.40 thread on the Mikrotik forums, and they seem to be teasing a cross platform Winbox replacement. While I imagine this is likely an Electron app, it also explains why there has been an effort to create a robust REST API for the platform after so long. Perhaps eventually we'll all be able to migrate over to the new app to do everything we need to? 😅
Since version 3.36.1 I have been observing problems, before everything was great. 3.38.0 - problem with scaling the window with the list of saved connections, sometimes it scales correctly, but usually not. 3.40.0 - same symptoms as most describe, quick shutdown tips do not work.
Great project. Thank you for your involvement... but maybe due to the problems, I suggest releasing a package like 3.36.0 with the replaced winbox64.exe file for a newer version as a solution for all those with problems and calmly solve the problem with the new wine? Maybe it's a problem that wine should have additional permissions in the system?
I have currently installed version 3.36.0 and manually replaced winbox64.exe with a newer version - it works properly again.
CPU: Intel ProductName: macOS ProductVersion: 14.4 BuildVersion: 23E214
@belthesar I think we should update Wine to 9.0 stable and check if it will help.
Unfortunately it doesn't seem to help too much; as I mentioned I'm running a standalone copy (not the bottled version y'all have produced here) and still get the same sort of random freezing and/or bouncing with no start, when using Wine 9.
It does seem like using 32-bit winbox.exe has at least lessened the problems somewhat, although I can't explain why. I can keep a session open for a much longer period of time without it freezing up, most of the time.
@nrlquaker I do not, but I also have not gone back and tried older stuff (yet). ISTR having occasional issues with this bottled version in the past as well, usually along the lines of "it bounces forever" or "it bounces, the GUI appears, but then I can't actually interact with the GUI and it seems frozen." In the latter case, sometimes I could get it to come back to life by clicking another window, and then clicking back to Winbox, and cycling that a few times, but that wasn't a guaranteed fix.
As I mentioned above, I originally tried using my own copy of Wine and a separately downloaded exe because I wanted to adjust the "Windows" DPI settings, and didn't want to break anything in your bottled copy. 😉
I truly don't understand what this exe is doing behind the scenes that apparently causes so many problems for Wine... unless Wine is just always this buggy? I've never really touched it outside of this scenario.