Hi,

When will appear winbox for MacBook m1, this is not serious ???

Already there: viewtopic.php?f=2&t=169541

Already there: viewtopic.php?f=2&t=169541

For M1 macOS Monterey did work

Is time to you to use some serious PC instead of one Apple device.

Is time to you to use some serious PC instead of one Apple device.

If a simple software was created only for one OS it's not serious... Why Mikrotik app exist on android and iOS ??

Apps are cool. That's why they are developed.

Apps are cool. That's why they are developed.

Should be also Winbox for macOS

Is time to you to use some serious PC instead of one Apple device.

sorry but this is a *really* stupid answer.

I hope this is some kind of joke, however inappropriate.

Well said..

I just moved from Intel to M2 ... and solved the display problem by updating winbox4mac to WINE 8 and Winbox 3.37.
Works fine, but is not yet tested in all directions :-p

I just moved from Intel to M2 ... and solved the display problem by updating winbox4mac to WINE 8 and Winbox 3.37.
Works fine, but is not yet tested in all directions :-p

I managed to update the exe in the package of the app.
can you help me to update the wine version ?

I just moved from Intel to M2 ... and solved the display problem by updating winbox4mac to WINE 8 and Winbox 3.37.
Works fine, but is not yet tested in all directions :-p

or can you upload the app updated ? I

DO NOT USE ANY PACKAGES WITH WINBOX, this is dangerous.

To use Winbox on Mac with M1/M2 processor you only need two things:

1) install Wine from here https://github.com/Gcenx/macOS_Wine_bui ... x64.tar.xz
2) download winbox64.exe https://mt.lv/winbox64
3) open winbox64.exe with Wine

Not working on latest macOS Ventura 13.2.1. I tried also with latest wine-devel.

works with Ventura 13.3

Not working on latest macOS Ventura 13.2.1. I tried also with latest wine-devel.

Works for me. I installed wine with brew. Started wine and from the new terminal I started winbox64.
Tested on M1 macOS Ventura 13.2.1

DO NOT USE ANY PACKAGES WITH WINBOX, this is dangerous.

@normis, I just like to understand what's "dangerous" about use a package manager?

I can see y'all not wanting to support it. Or that redistribution violates Mikrtik copyright/IP/etc. But "dangerous" is a strong claim.

To be clear, nothing has passed Apple's verification to be in the App Store, and even the document approach requires ignoring OS security warnings.

The problem in the recommend way is that wine is never checked for updates if you just directly installed wine from @gcenx GitHub – so if wine has a vulnerability that's fixed in a newer version, there is nothing that flag you'd need to update it.

If the Homebrew package(s) are dangerous, someone should report them to the brew team:
https://github.com/Homebrew/brew/security/policy
I'd be happy to make a report myself, but there are no fact to backup the assertion.

On the past some "ready package" posted from users, not only for macos have surpriseS inside...

On the past some "ready package" posted from users, not only for macos have surpriseS inside...

@normis has repeated this claim a few times. See viewtopic.php?t=185030

Mikrotik certainly does recommend downloading other third-party things (e.g. Cloudflare, which creates a tunnel to internet using closed-source software and third-party networks) without much warning. So what's the difference with auditable public GitHub project that redistributed by brew?

The executable doesn't make it on github, but the user loads it...
Users don't check what's written at all, but they love copy-and-pasting...
Leave it alone if there is someone who reads everything and compiles things on their own ...

But this refers to anything, in a general way, not in the specific "GitHub", "brew" or other cases.

Since 13.3 released today:

wine64 /Users/ordghio/Downloads/winbox64.exe
0074:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\wineusb": c0000142
003c:fixme:service:scmdatabase_autostart_services Auto-start service L"wineusb" failed to start: 1114
009c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
009c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
009c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
009c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0024:err:dnsapi:DllMain No libresolv support, expect problems
0024:err:module:LdrInitializeThunk "ws2_32.dll" failed to initialize, aborting
0024:err:module:LdrInitializeThunk Initializing dlls for L"Z:\\Users\\ordghio\\Downloads\\winbox64.exe" failed, status c0000142

When will be NORMAL native application for mac?

Normis have Ventura 13.3 and work, probably your fault on the config of something.
Ask Normis....

Works with Wine-devel (8.4), not Wine-stable (8.0) under Macos 13.3
Anyway, native application required...

So what's the difference with auditable public GitHub project that redistributed by brew?

Not only is Homebrew all but unimpeachable as a source of trustworthy binaries, the same source of those tarballs Normis is recommending we use instead has a "How to Install Wine on Mac" guide that tells you to use Homebrew.

probably your fault

Nope. I can confirm the symptom: upgrading to macOS 13.3 on Apple Silicon machines breaks winbox under wine if you're using Homebrew's wine-stable package. Switching to wine-devel or wine-staging fixes it.

Oddly, macOS 13.3 on Intel boxes doesn't show the same problem.

native application required...

"Required?" Otherwise what?

"Desired" I get, but "required?"

So what's the difference with auditable public GitHub project that redistributed by brew?

Not only is Homebrew all but unimpeachable as a source of trustworthy binaries, [...]

It does check hashes automatically. But @normis is always belaboring this point that packages == bad. No idea why.

As a Mac + winbox user for 7+ years...a native Mac app would be near the bottom of my feature request list. A @normis-approved brew package would be welcomed however.

It does check hashes automatically.

Not quite my point. By "unimpeachable," I mean that Homebrew has a track record of many years of providing trustworthy packages, and they've got a a reasonable governance model to protect that reputation. If anyone ever did push something harmful into Homebrew, I'm confident it would quickly be found, fixed, and prevented from happening again.

I trust Homebrew to nearly the same extent as, say, Fedora's package repo.

A @normis-approved brew package would be welcomed however.

Maybe this detail slipped by, too, then. I'm pointing out that the same guy provides both @normis' tarball and the Homebrew instructions I pointed to. If one is trustworthy, then why not the other?

@tangent, I think we're making the same point

It's this commentary in a locked thread that had me curious, where @normis ends with:

That's it. No need to risk installing pre-packaged apps by unknown people

And if one looks, also same wine dude (@Gcenx) that provides the binaries to the nlquaker brew package too.

@tangent, I think we're making the same point

I don't, because "hashes" prove nothing unless you trust the source of the hashes.

If the hashes come from the same source a the packages, why are you trusting the hashes to prove the trustworthiness of the packages?

At best, all checking SHA sums of binaries can do is prove that the package wasn't corrupted, and that's on top of all the other data transport layer checksums.

Public key signatures are more useful, but then you need to trust the PKI, which is why Debian makes people literally show up at a meeting and present a government ID in order to get the rights to push packages into the repo.

I use brew for everything myself.

He seems dead set against https://github.com/nrlquaker/winbox-mac specifically, which is my concern. I use that. And it is in mainline brew, no tap. So if it's a problem (i.e. "dangerous"), just asking "Why?"

And all chains of trust go through the same wine package maintainer was my main point.

Packages = bad, because some people learn that using any kind of pre-packaged winbox is fine, and then get it from somewhere else, which includes unexpected bonuses inside.
So the less unknown factors, the better.
Official Wine64 from official repository + Official Winbox64 from official webpage. No unknowns in between, no other parties involved.
Security first.

Official Wine64 from official repository

Then you should be pointing people here, not at the personal GitHub repository of Dean M Greer, alias Gcenx, who merely happens to be the current macOS port maintainer for Wine.

Or, you could point people here, the macOS page in the official Wine Wiki, where among other options they include installing from Homebrew.

Solved by upgrading wine to wine-devel
https://www.reddit.com/r/wine_gaming/co ... cos_after/