Wine 8.5
winehq.org
winehq.org
I would not have been able to move to Linux full-time without Wine. Thanks!
I think that there's still a ways to go for Wine on MacOS at least, like for instance I don't think playing No Man's Sky on MacOS via Wine is viable (or at least it wasn't when I tried a few years ago). I think that's more a limitation of the graphics API MacOS uses though. Supposedly a native port is on the way anyway.
That would be a big deal and if true embarrassing I didn’t know about it.
In a vacuum, what Excel does is straightforward, and there's lots of free alternatives. Don't get me wrong -- I think it's a great program, but I don't see anything unique about it.
That's true in theory, but Excel executes it so much better than Google Sheets or LibreOffice Calc.
* - LO Calc and MS Excel.
Having used Excel, Numbers, OpenOffice (since back when it was still StarOffice), and Google Sheets, I find it to be a mixed bag. For example, there are certain things which Numbers does way better (drag&drop rows to reorder them, for example) and I personally prefer it for my work. But most importantly, I haven't found Excel to be "way above the rest" at all.
Meanwhile Numbers can have field types like star ratings. It uses a fundamentally different visual abstraction. Numbers focuses more on appearance and makes better looking graphs easily out of the box. At the limits of their feature sets though, these are really tools aimed at different audiences. For basic spreadsheet functionality, all of the major spreadsheet programs in the last 2 decades are serviceable.
Excel is great software, truly, what it enables people to do is impressive (and awful sometimes).
But once you have convinced yourself that its industry standard, why look as deeply into alternatives to even figure out if there are better tools? all of them will have quirks, some will certainly be more powerful in some areas (google docs has the ability to read data direct from bigquery for example).
Many already convinced themselves that excel is the one true format and there is no reason to look hard at anything else.
Others don't want their investment in learning to be wasted.
Theres a lot of people who are genuinely not incentivised to look at the ecosystem critically.
I suppose that's true to an extent. However one of the reasons spreadsheets in general are so popular is their fluid accessibility. Just about anybody can get right to work even in Excel. Once you've gotten started in Excel there's little incentive to leave. That it offers a full blown powerful programming environment (which is definitely not the best in almost any area) erases much reason to seek alternatives. It's not a situation where Excel is meaningfully less accessible than the alternatives.
> Many already convinced themselves that excel is the one true format and there is no reason to look hard at anything else.
I mean this is sort of true. It's simple enough and good enough and actually insanely powerful on top of all that. What is the compelling reason to even seek an alternative? (saying this knowing full well that people often do, and usually it's Sheets).
And lack of external data sources is not a small potatoes feature (speaking in reference to Numbers here) - I think that alone puts Excel and Sheets way above Numbers. (And personally I can die happy not seeing another line of AppleScript for the rest of my days).
At least GSuite gives you browser accessibility - and even Excel to a large extent. Numbers ties you to the Mac desktop and iOS crowd. That seems like an already poor incentive to switch. It's great that it works for some people - but it's a niche product, where Excel simply isn't, period.
Excel on Linux doesn't exist of course.
The only winning move is not to play.
On the other hand, I do work (daily) on reasonably sized financial spreadsheets, with complex formulas, which also contain graphs, and use "pivot tables" (although I like the naming in Numbers much better, I never quite understood the name "pivot table"), things like conditional highlighting, etc.
I'm just saying that this isn't as clear-cut as some Excel users make it out to be.
We have a stable binary format for Linux! It's Windows.
Altough you can install guix on any GNU/Linux distro, on top:
https://guix.gnu.org/manual/en/html_node/System-Installation...
Then, run
guix pull
as a non root, and next,
guix package -i lmms
But the rollback features from the Grub menu and ensuring no dependency hell, ever, can be golden for production cases and for reproducibility in science, for instance.
I know clang supports Windows, but I haven't heard anyone have a crosscompilation setup like that (sounds handy!)
1) install wine. Normally, you would do `brew install --cask --no-quarantine wine-stable`; however, if you managed to update to ventura 13.3, you will need wine 8.4 or newer, so `brew tap homebrew/cask-versions && brew install --cask --no-quarantine wine-staging`.
2) if you installed brew without `--no-quarantine`, try launching it now. The point is to appease Gatekeeper, so launching it in the future won't fail. It will also create a wineprefix, if you don't have one.
3) save your winbox64.exe binary somewhere. M1 doesn't support 32-bit mode (not even ARM one), so make sure it is 64-bit one.
4) launch it; wine64 /path/to/your/winbox64.exe. It will be handled by Rosetta automatically.
It should work now. In the past, with some older wine version, it failed, because some wine script called 32-bit binary somewhere down the chain; since I don't remember what version it was and what exactly it did, suffice to say that it was enough to add '64' in the script to the name of the binary called. With wine 8.0 and newer, it should not be a problem.
There are some fine details you can make it slightly better:
5) package it into MacOS app. Create the basic bundle structure (`mkdir -p WinBox.app/Contents/{MacOS,Resources}`), put:
#!/bin/bash
/Applications/Wine\ Staging.app/Contents/Resources/wine/bin/wine64 "$(dirname "$0")/../Resources/winbox64.exe
Put winbox64.exe into `Contents/Resources`, some nice icon into `Contents/Resources/Icon.icns` (if you google, you can find winbox icon in the right format), and some basic metadata into `Contents/Info.plist`:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>WineProgramPath</key>
<string>winbox64.exe</string>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>WinBox</string>
<key>NSHumanReadableCopyright</key>
<string>© MikroTik</string>
<key>CFBundleIdentifier</key>
<string>com.MikroTik.WinBox</string>
<key>CFBundleName</key>
<string>WinBox</string>
<key>CFBundleVersion</key>
<string>3.37.0</string>
<key>CFBundleShortVersionString</key>
<string>3.37.0</string>
<key>CFBundleIconFile</key>
<string>Icon.icns</string>
<key>LSApplicationCategoryType</key>
<string>public.app-category.utilities</string>
</dict>
</plist>
6) You will have a problem saving a session state. This is again gatekeeper; if I run winbox from a terminal with developer tools privilege, it will work. If I run it as the above app package, it will silently fail at saving. You can play around with granting privileges, but I prepared my sessions throught the terminal launch instead, and by running it via app package, they are read only, so I don't accidentally rearrange something.
The word "still" in your post suggests you expect F/OSS software to eventually become available for all fields of application. But that's not what I see happening; instead, there's no new desktop (as opposed to cloud) software being released at all, much less on Linux. So Wine is here to stay with us to (increasingly) run old Win software out of maintenance, and works surprisingly well. Of course, that's made possible by Win32 itself having excellent binary compatibility in the first place, as opposed to the Linux user land.
Runs most of my windows software with little to no issue, and is more compatible with older games than Windows 10/11 itself!
Wine and proton frontends are becoming so friendly too. Setting things up on e.g. steam deck is extremely easy, not just for wine but even for emulators (emudeck). Just click some buttons and you get everything set up for you and auto-updated.
There's a ton of titles from the late 90s onwards to ~2010 that don't work correctly on modern Windows - either very unreliable, have something fundamental broken, or don't start at all.
This especially applies to games from the from the pre-Vista era - things like DirectSound & DirectDraw being rewritten in Vista broke a lot. In addition, newer GPUs & drivers have broken older games - even big names like The Sims 2 have graphical artifacting - unless you use DXVK! I understand that sometimes this is due to the game doing something incorrect that happened to work okay at the time, but that's still unhelpful if I want to get something to run.
Running games from my childhood requires a mix of dosbox (for most classic DOS titles), PCem/86box (for really weird old titles that don't run on anything that isn't win95/98, or DOS titles that relied on 3dfx hardware).
Get a bit newer and it's dgVoodoo2 (for games that use old DirectX or Glide), DXVK (even on windows!), or I just give up and run them on Linux with Wine - which usually just works. The odd title still needs some patching (like eg Max Payne, but that's because of a CPU incompatibility with AMD Zen CPUs) - but it's nearly always less hassle than trying to run older titles on Windows 10 or 11.
Every other time I try to do something the dependencies fails to download or there are bugs preventing stuff from installing.
What am I missing? Maybe games happens to bundle most they need themselves?
(disclaimer: also a CodeWeavers employee)
What's new in this release:
- Bundled vkd3d upgraded to version 1.7.
- Better error reporting in the IDL compiler.
- Support for shared Wow64 Classes registry key.
- More cleanups in IME support.
- Support for configuring a WinRT dark theme.
- Various bug fixes.In practice Proton and CrossOver tends to have rather different sets of needs. Proton only supports Linux and is only focused on gaming. CrossOver exists for a handful of platforms, most notably macOS (which has a number of intricacies: missing 32 bit libraries, Apple Silicon, missing Vulkan drivers which requires MoltenVK, but MoltenVK itself cannot really offer all the features standard Vulkan drivers have on Linux), and is also used for non-gaming applications. CrossOver also lives in the form of specialized branches we develop for specific applications, on request of their developers. So while of course we share everything that can be shared, in my experience this tends to be not that much (except what goes upstream, of course). In pratice CrossOver and Proton live in different repositories, have independent build systems and independent release schedules.
I know people use CrossOver with Steam on macOS, though that requires a rather intricate setup I don't know much about. I guess what you'd like to have is the kind of seamless integration that Proton has with Steam on Linux.
note that I commonly buy all games that run on linux :)