won't start on macOS 12.6.8

[ssstain]

• macOS version: 12.6.8
• macOS language English
• Winbox-mac version 3.39

After the upgrade to macOS 12.6.8 the winbox-mac won't start anymore.
The window hangs with input fields inaccessible.

[belthesar]

macOS Version: 13.5.1
macOS Language: English
Winbox-mac version: 3.39

Unfortunately, I can replicate this issue. I attempted to remedy this by deleting the WINE prefix stored at ~/Library/Application Support/com.mikrotik.winbox, but that does not seem to have remedied the issue. When launched normally, the AppIcon bounces in the tray consistently, even after the UI appears, leading me to believe the app never registers a "fully launched" state.

I did however discover a workaround - If one right-clicks on the launcher icon and closes it, then waits, Winbox will launch, and allow for user input. The AppIcon from the bundle disappears, and the icon from the Winbox executable then shows up in the tray with the app title "wine64-preloader". Alternatively, once can edit the launcher script at /Applications/Winbox-mac.app/Contents/MacOS/winbox-mac and change line 19 to: "$BUNDLERESOURCEPATH/wine/bin/wine64" "winbox64.exe" "$@" &, which effectively performs the same action by backgrounding the WINE thread. Not the greatest user experience, as we see an AppIcon appear in the Dock and then disappear, leading the user to think the app crashed, but still better than having to perform manual steps in the interim.

[ssstain]

reinstalled the inbox and it solved the issue
I should have tried that first.
Closing.
@belthesar thank you for the hint. Next time it hangs, I will try yours.

[darkguy2008]

I can confirm this fixes the broken mouse/keyboard input inside the MDI container in Ventura. I applied @belthesar's fix and it began to work as usual.

Thanks for creating this!

[belthesar]

I would encourage reopening this issue, as while I have provided a workaround, I would not consider this a "fix". Something about the upgrade between versions has introduced undesirable behavior. Unless something has fundamentally changed about Winbox and the WINE wrapper that this is the best method of addressing this behavior change, addressing the root cause for this behavior is likely the better choice. Leaving the issue open surfaces visibility to the workaround in the interim, and encourages the maintainer to delve further.

[jacuinde]

11.6.8 Mac Big Sur and current version

When i open winbox it starts jumping on the Dock but closes itself, tried solution indicated here but it doesnt work, used to work with old version

[michaldejmek]

You need to delete the application completely (~/Library/Application Support/com.mikrotik.winbox)and reload the device list and everything works as it should :)

[jacuinde]

theres no com.mikrotik.winbox folder inside Application Support

[belthesar]

Out of curiosity, for those of you having issues launching Winbox-mac, are you on Apple Silicon hardware, and have you installed bash via Homebrew? I've identified an issue where the launcher expects to use bash, but if bash is installed via Homebrew, bash will only install binaries for the platform architecture. Turns out we don't need bash with the launcher script, so I'm working on a release that gets around this.

Also, I've noted that there's a difference in launch behavior when Winbox-mac is launched via Spotlight vs. Launched via Finder or a Dock shortcut. When launched via Spotlight, this seems to cause the infinite bouncing Dock icon issue, which also prevents input in the window. Looking into this one more.

[darkguy2008]

@belthesar just FYI this issue should not be closed, I'm experiencing the same thing with the 3.40 release.

Again, the same fix of adding & to the end of the command works. And yes I'm on M1 hardware.

How do I know if I have bash installed through homebrew? I haven't done so that I remember, but another package may have?

[belthesar]

@darkguy2008 fast way to check is to do a brew list -1 | grep bash to list all packages installed by homebrew, filtering with grep for mentions of bash.

To everyone et al: we've consolidated tracking of bad launches to #137. At this point though, the nuances of this bug seem hard to trace, aren't remediated with newer Wine versions, and Mikrotik has announced a new Winbox version that runs natively on Windows, Mac and Linux, which is slated to release soon (for various definitions of soon, as Mikrotik generally operates on id Software time, as in, "when it's done").

[Negmus]

@belthesar I found easy way to fix the problem with disappearing Winbox after adding &.
I added to your fix nohup on start of line 19
nohup "$BUNDLERESOURCEPATH/wine/bin/wine64" "winbox64.exe" "$@" &
I'm using this solution for about a week and Winbox is working every time.

[belthesar]

Nice workaround @Negmus. I'm reticent to add this as a released workaround though, as this also disowns the process. The underlying issue is that, for some reason, we're not getting a proper "process started" notification. When I originally posted this workaround, I was unaware of the implications. Things "mostly work", but this continues to treat symptoms instead of problems. Curious that nohup, which blocks sighup signals, is giving you more consistent execution.