(Maybe it’s considered bad to revive old threads/posts like this?)
Getting a 64 bit version of Winbox should be more pressing now,
as more Linux distros talked about ditching 32 bit x86,
and macOS is dropping 32 bit support if I understood correctly …
That is probably a lot more work than a 64-bit version! (which should just be a re-compile when the code is written well)
However, I don’t think it is a good idea to continue on the winbox path. It would be better to improve webfig so it is completely on-par with winbox (using modern HTML5 features), and then only have a small agent that can be used when it is required/desired to connect via MAC instead of IP address. This could be integrated with netinstall if desired. It would only translate connections to localhost into MAC level connections, all the config functionality would be in the webpage which can be opened in a modern browser. The agent (and netinstall) could be written in a language like Python and be made available as source, so it can run on many platforms as well.
That way, the OS running on the computer (and its number of bits) does not matter. One can use a Chromebook if desired.
Don’t touch my WinBox, it’s one of the best tools invented by mankind, and it’s perfect as it is now. It’s like trying to reform hammer, sure you can come up with something else that’s not bad either, but it still won’t be good replacement for the simple and reliable tool in all cases. Native WinBox is exactly the right way to go.
Previously I wasn’t very excited about browser-based UIs, but since I’ve been forced by VMware to abandon their native client for ESXi and use the new html-based UI in browser, I’ve turned into enemy of such solutions. You can say that it’s just one case and it doesn’t prove anything. But is there any, where someone had perfectly good native application, created new html-based one and all users were excited, because it was so much better?
I’d argue that since WinBox is pretty stable and doesn’t change much, it would now make sense to make native LinBox, MacBox or WhateverBox. It would be some extra initial work, but once done, further required changes would be small and infrequent. Regular support for new RouterOS versions is now done using definition files shared by WinBox and WebFig, so nothing special for that would be required. Only for things like for example recent change in authentication.
Maybe as an alternative, it could be re-written as a cross platform electron framework application. Then it could have a client for windows/mac/Linux. Just an idea.
If winbox / netinstall / dude client could be cross platform i could loose almost everything i have left running in wine lol
As i said before, it’s just an idea. From my understanding it should be able to access the network card to be able to do mac telnet/winbox, which is one of the most awesome features of winbox.
VMware shot their foot with that stupid Flash interface that they forced on everyone, and then their HTML5 interface which (at the time - I don’t know what they’ve done in 6.7) was not even on par with the Flash interface. What a total waste of man hours to build both interfaces… and eventually lose customers because of it.
Maybe as an alternative, it could be re-written as a cross platform electron framework application. Then it could have a client for windows/mac/Linux. Just an idea.
Well… if you want to use 1-2GB or RAM just to configure your router, javascript/electron is the way to go.
Regardless, it will still be way worse than Winbox, even if they manage to make the UI identical.
Webfig works well on the Chromebook, but it needs a some work to become more like Winbox.
And in my opinion (apparently not for others), it would be perfect when that work would be done to replace Winbox.
No more 2 (3) interfaces to maintain, and easier to use for non-windows users.
Of course it is important that the Webfig interface be as much as possible as it is now in Winbox, possibly even a bit better (e.g. movable columns).
It’s still the same old problem. Having to write something several times for different OSes sucks. It’s extra work, so it costs more, the code is different, there will be different bugs, etc. It’s logical that there were always attempts to have solution that would allow to write the thing only once and still make it run everywhere. There was Java and it worked, but the result always felt out of place, and requirements were higher. Various cross-platform frameworks are slightly better, but still not great, there are always some compromises. And web interfaces brought it to whole another level. It’s great that as programmer you can write it once and it works everywhere, but…
As user, I don’t want everything in browser. That’s what operating system is for, optimized environment to run stuff. I hate that I need to get the latest and fastest multi-core computer, in order to not have the web stuff terribly slow, especially when I know that proper native executable would run snappy even on 486. And not only that, it’s always limited, the technology was simply not made for this, attempts to “emulate desktop” in browser are basically an abuse, it can never work well.
I think we should all avoid getting caught up on how a rewrite could be made in some local side web app
The request is for a recompile of winbox into 64bit
If the recompile is not possilble, it would be fantastic for Mikrotik to take a leaf from their heritage (Linux) and open source atleast the details of how the MAC protocols work
I could maybe deal with Webfig, but the lack of MAC is the biggest pain point, imagine if we could have a simple command line version of MAC-Telnet
Normally when compiler supports both 32 and 64 bits, source code is very similar, only some data types are different, and for newer stuff it’s handled transparently with proper definitions. Older sources need adjustments, but it’s still mostly the same. Of course with older and larger sources, it could take more work. And it applies to used libraries too. Nobody except MikroTik can know how long would it take for WinBox.
On Linux, f.ex. in Debian, you can use the package mactelnet-client, binary named mactelnet to access by the MAC address.
Also, Codeweaver claimed they will release a Crossover (Wine) version that will be able to run the 32-bit binary on macOS 10.15. I hope it’s true.
(Otherwise running a small ReactOS VM in Virtualbox, running Winbox, is an option …)