Hacker News new | past | comments | ask | show | jobs | submit login
Wine 4.0 released (winehq.org)
452 points by KindOne 3 months ago | hide | past | web | favorite | 155 comments



Having used Wine for a lot of late '90s / early '00s Windows games, I think Win32-on-Wine is possibly the best, most stable game platform in history. Modern laptops run games of this era without breaking a sweat, publishers couldn't assume users had the bandwidth to patch everything after release, so there's a playable game right there on the CD. Many CD-ROM games didn't bother with copy protection (after all, who would copy a whole CD full of data?), so you can play straight from an iso.


> publishers couldn't assume users had the bandwidth to patch everything after release, so there's a playable game right there on the CD

A reminder that Daggerfall (aka Buggerfall, aka the game that had a game-breaking bug in the very first dungeon at the beginning of the map) shipped in 1996.


Ah Bethesda, great games but holy shit, if it weren't for the mod community fixing them every time I swear I'd hate them.


Their most recent game is an example of what happens when they remove the mod community. A lot of people were very upset with FO76, but it being MMO disallowed mods, so game breaking bugs existed weeks into the game's release.


>Many CD-ROM games didn't bother with copy protection (after all, who would copy a whole CD full of data?), so you can play straight from an iso.

Please insert correct disc into the cd drive. Please enter your cd-key. Please type the third word from line 42 on page 13 of the manual.


Just Press Enter

~ CRACKED BY HeXPHReAK ~


Warning multiple threats detected on file keygen.exe

Quarantine or ignore

Meh...it's probably fine.


I was super surprised my university pirated PuTTY. I knew it because I saw the "PuTTY keygen" app on the desktop. Only years later I realized it's an app for generating ssh keys...


8-bit techno music playing the background



rotating_skull.gif


Doesn't sound like a private enough community to me.


C'mon, we can do better: Phrozencrew


You can get many DRM-free games on GOG. Most work fine in Wine on Linux.


Many are actually DOS games running on Dosbox, so you don't even need Wine, just re-wrap them in a native Dosbox feon your distros' repository.


I'm talking about Windows games obviously. Many have native Linux releases there as well and don't need Wine.


I just bought Heroes of Might and Magic 2. A pirated version came on my first pc, a 133mhz Pentium. Blast from the past, this game.


One of my personal favorites and a great example of a game that works well under Wine.


> Many CD-ROM games didn't bother with copy protection (after all, who would copy a whole CD full of data?)

Many early 2000 games I'm fond of used SecuROM. That's always a fun one.


True. Fortunately by now there are cracks for most of those games. And those cracks are relatively simple by modern standards. Maybe a few hex edits and/or a replacement DLL.


They already were commonplace back then. Common "performance hacks" involved simply installing the no-cd crack.


Back then even some audio CDs had copy protect. A certain Céline Dion CD was infamous for wrecking CDROMs.


Yup, there was also that time Sony rootkitted everyone's PCs.


If nothing before would teach people that Windows AutoRun for CDs were a bad thing, this one certainly did.


Unfortunately the feature is crucial on home PCs meant for the mass consumer market.

To the typical consumer, the action of inserting the DVD should communicate to the computer their intended action.

Every additional step, especially if it requires reading, pushes them further to just using a dedicated device for CD/DVD consumption.

To someone like you and me that might seem like an ideal practice, but to the typical consumer it's a usability problem.


This was actually the last time I rented a DVD.


I realize it's a bit different, but have you considered something like the NES, in terms of "what's the most stable platform?"

NES emulators have been ported to basically everything, which in turn makes NES games playable anywhere. And this includes modern NES games as well, as long as they were tested against either super-accurate emulators or real hardware (to ensure no reliance on specific emulator quirks).


Funny how Wine has implemented Windows APIs on top of Linux (and Mac), and Microsoft has implemented Linux APIs on top of Windows.


Or sad. As a user and developer, 98% of the differences between these operating systems don't really matter to me at all. They only exist because of historical accident, desire for proprietary lock-out, or other pointless reasons like ego. For anyone who didn't believe it, they've finally gone and given a proof by construction.

We've abstracted over the CPU nicely. Without even thinking about it, my software will compile and run on any modern CPU just fine. Excellent! But it's dumb that we still have to learn about the specifics of the OS, just to write a simple application. I wish they'd just pick some kernel-level API, some common formats (filesystem, executables), some UI-level APIs, etc., and then everyone could just write to that.

(That's basically what the web is, except the API is in terms of HTML/CSS/JS, rather than CPU/RAM/disk/devices. You know you suck at standardization when you're getting lapped by the web standards committees. It's easier for me to cross-compile C to JS than to compile C on all the different platforms I use. What happened?)

It seems like every couple decades, a few companies get together to try to make a standard operating system (Multics, Taligent), and it always falls apart. We're just about due for another doomed effort!


> some UI-level APIs

This assumes that there is agreement on what the UI experience should be. Navigation patterns, menu bars, keyboard shortcuts, touch gestures.. But there is still active competition between OS vendors on UI. Just in the last decade, the most common form of interaction with a computer has changed from mouse and keyboard to touch and speech recognition.

> It's easier for me to cross-compile C to JS than to compile C on all the different platforms I use. What happened?

The web is a lowest common denominator. A web app is still missing a lot of affordances that users take for granted in a native app on their given OS. That is why still in 2019, there are new native iOS and Android apps being developed. Look, there are even entirely new programming languages being invented (Swift) or integrated (Kotlin) for the purpose of writing native apps for those platforms.

Specifically regarding compile C, I don't see what your problem is compiling C. You can even compile C11 on windows with Clang. Yes you may choose to include a OS-specific header and it won't compile, but also your JS doesn't necessarily run if you call some browser specific function.


> This assumes that there is agreement on what the UI experience should be. Navigation patterns, menu bars, keyboard shortcuts, touch gestures..

We had that for a while.

https://en.wikipedia.org/wiki/IBM_Common_User_Access

And most DEs even implemented it to some extent. But they didn't converge as a result of that.


> The web is a lowest common denominator.

Yes, it is, but why? HTML/JS has a LCD interface. x86 has a LCD interface. Even filesystems sort of have an LCD (some superset of MS-DOS FAT). Shouldn't the OS have one, too?

If we standardized filesystems, executables, and syscalls, I don't see how our world would be any worse, and I can think of many in which it would be better.


If you write standard compliant C, don't use platform specific headers, and use some kind of cross-platform build system (I can't recommend CMake enough here), it's easy to use C/C++ across platforms. UI/graphics is harder, but cross-platform solutions do exist here (Qt, GTK, WxWidgets, OpenGL).


> I can't recommend CMake enough here

I've used CMake for many years. But now that I've discovered Meson, I cry a little every time I have to edit a CMakeLists.txt file.


The biggest issue with CMake is how many libraries seem to have really low quality CMakeLists.txt's.

CMake is very easy to use, if you do things properly with targets. include_directories and link_libraries should never never ever be used, use target_include_directories and target_link_libraries instead. This way there is no need to mess about with shell script style variables for dependencies. But so many resources online explain to people how to do things the wrong way, and so their libs end up being a pain to build or depend on.


IME the documentation is great at a command level but does a poor job of explaining how things fit together at a macro level.

I did a large project conversion last year and was well into it before I started getting a feel for how everything fit together with Public/Private.


But meson used pkg-config under the hood, which looks very unusual/like alien creation for Windows Devs.


These days with stuff like MSYS2 readily available, it's not really as alien as one might think.


If your using stuff like MSYS2 does cmake/meson have a big advantage over old make/autoconf? I thought cross platform was the biggest selling point for these tools.


For me, sanity is the main selling point. Make has meaningful space/tab distinction - that's quite enough to disqualify it as hopelessly mad in my book. And then autoconf is just baroque.

CMake only helps a little bit (it's still very old and has way too many warts). But Meson is very pleasant to work with.


One selling point seems to be speed: https://mesonbuild.com/Performance-comparison.html


> don't use platform specific headers

Which is often unavoidable if you want to do filesystem stuff.


Qt and Gtk (or just glib) can handle file systems identically across platforms.


I prefer using boost, if UI is not required


I wouldn't argue that we should be happy about how the web turned out.

It always feels like computers are stuck in the same place because every time we improve CPU performance, we end up adding more layers of abstraction so the whole thing is moot.


> We're just about due for another doomed effort!

It seems Google will take a shot at it: https://en.wikipedia.org/wiki/Google_Fuchsia


That screenshot looks like Android 2.0. I'll pass, having 1 Android is already too much.


The important part of Fuchsia is not the UI at this point, it's the kernel.


Sounds like you might be interested in POSIX.


One OS. One UI. One experience. One problem if it has a bug or sn architectural deficiency. Zero choice.


No, I definitely don't want one OS, or one UI or experience. I want one interface. We've already got architectural similarity between operating systems. The part that's different is the interfaces between them, for completely arbitrary reasons.

We've done this for layers below the OS (x86) and layers above it (HTML, JS). There's just this one layer in the middle which we missed.


"Or sad."

No mate it isn't sad. There is always going to be a scrap between things, whether they be OSs or iguanas and snakes on the Galapagos islands.

I'm going in with a penguin myself and I will win.


Funny I was just wondering if you could run Wine on the Linux subsystem for Windows and run Windows apps in that environment. A complete waste of time and energy so little chance I will try.


It may be funny but it may be a way to support certain older games/applications that don't run well on Windows 10. For example in order to run Dracula 3 on Windows 10 one has to use the Wine implementation of Direct3D: https://fdossena.com/?p=wined3d/index.frag


Or you can just build wine on Windows for Windows. I've done that long time ago for Yuri's Revenge.


I've actually tried to run HeidiSQL through Wine on Windows and I succeeded.

The tricky part was the X11 server. X.org doesn't seem to work on the Linux subsystem, but there are a few X11 servers for Windows. If you install one of them, you can run Linux GUI programs.


Xorg works in WSL, it just doesn't have any backing graphics driver to actually render anything. But if you install XRDP, you can connect to your Linux desktop using the usual Windows remote desktop client.

But yes, there are better options. You can run Xming or other X server and configure it yourself. Or you can buy X410 in the app store, and then the only configuration needed is DISPLAY=:0 in your shell.

https://token2shell.com/x410/


I guess that would be helpful if you wanted to run 16 bit software on 64 bit Windows.


There's NXVDM which is a port of the i860/Alpha/MIPS/PPC NTVDM compiled for AMD64. https://sourceforge.net/projects/nxvdm/


Few use cases I can think of:

Testing across multiple .net frameworks without containers or virtual machines.

It's a lot faster to initiate an app inside wine on Linux then start up a VM and launch it on Windows. I think it's even faster than containers on Windows but don't have any data to back it up.

Lastly, for sandboxing applications (not a great security layer of course, but safer than running natively) so they don't pollute the registry or access sensitive files.

Wondering if it's possible to play dx12 games on older versions of Windows that don't officially support it.


Funnily enough, there was an article about malware doing exactly this for AV evasion some time last year. Existing behavioral analysis wouldn't be effective since they were looking at Linux syscalls.


Well, you can run Wine on Windows (which makes sense if you think about it).


IIRC you can run wine on cygwin, so I wouldn't be terribly surprised if wine on WSL worked.


Also Docker for Windows can run Windows and Linux containers.


Would be a strong contender for "turtles all the way down" of the year.


I'd suggest running an Amiga emulator. There was a Mac "emulator" for Amiga that required Mac ROMs to function.

Sadly, the Apple II emulator for Macs was real hardware.


If Microsoft wanted to be clever, they would have called their thing Line.


Microsoft bought the term "Lindows" in 2004 for around $20 million.

https://en.wikipedia.org/wiki/Microsoft_Corp._v._Lindows.com....


In retrospect, prescient and especially useful when they will release their own Linux distribution.

I'd bet on them forking or outright buying Ubuntu.


> outright buying Ubuntu.

Calm down there Satan.


I've always preferred mslinux http://www.mslinux.org/


> Microsoft Invades Cuba

> Microsoft's plan to invade cuba and overthrow the government has succeeded. One Microsoft official said "It's a win-win situation. The US Government is happy and shuts up the DOJ while Microsoft institutes a monopoly within Cuba for everything from computer software to toilet paper. One more step closer to world domination. Heck, we could feed a whole development department for the cost of one developer's salary in the US. They may not know how to create an Operating System very well, but neither do our US developers."

Oh my. I wasn't sure what I was looking at and then I read that to the right of the link.


Sounds like Amazon


who owns Ubuntu?


Canonical


The name has already been taken: https://sourceforge.net/projects/line/


It takes an incredibly talented developer or team thereof to build such a reimplementation. I wonder how much talent has been wasted chasing competitors' implementations in this way. That's talent that could have been spent improving the state of the art, given a different history. Ah, well.


Even funnier is that often Wine has better performance than native Windows.


Will Wine run on top of Windows Subsystem for Linux?


to me this just proves that linux has won. (no this is not about the year of the linux desktop). for as long as wine exists we have been looking for ways to run windows software on linux, but now microsoft is trying to run linux software on windows.

quite obviously linux has something that they want.


same with programming languages, js/python/perl cross pollinated each others a lot


I've been a fulltime Linux user for 15+ years, and up until last year I avoided using Wine (because I didn't require it -- I didn't need any Windows tools, and I wasn't a gamer).

On my last holiday break I wanted to install and play a few games, which included using Wine to play Windows games. I was pleasantly surprised at how well it worked. Out of the ~10 games from GOG that I installed, all of them worked.

Great work.


WINE is so great.

I wish there were a more user-friendly way for people to use it, without the command-line and winetricks. I use wine on macOS, but I usually hesitate before diving in, because I know it inevitably involves some gymnastics. Even with Wineskin Winery (which is no longer maintained?).

Will WINE ever be at a point where it would be stable enough to make the case for non-technical users? Another comment joked about public offices -- would it be absurd to think offices could run linux instead of windows, saving licensing costs, using WINE where legacy software is necessary?

I would have started using WINE even earlier if the documentation were more approachable. I think they've improved over the last few years, though the site still looks like an antique forum system rather than cutting-edge tech + design, like you would see from a startup's website.


Valve has been doing a lot of work here lately, they've essentially made Wine into a first party citizen of Steam (in the form of Proton). So Wine is stable & easy enough for non-tech users - at least for gaming purposes. But there isn't the equivalent for general software yet.


They just opened proton to non steam software in the latest beta. And from what people have been posting it works with a lot of windows applications.


That said, I was attempting to run a Proton game a few weeks back and it kept failing silently. Running from the terminal revealed a missing dependency, which I apt-getted and now it works fine. So while I agree that Proton is fantastic, there's still some work to be done in making it more friendly for "non-tech" users.


Is it not the case that if you use the steam runtime then libraries should be there? Ultimately valve are targeting steamOS not linux as a whole. Some linux distros (eg arch) have a package that bundles the steam runtime which should make such issues go away.


Steam runtime doesn't have every lib ever made, can collide with libraries in the system, and game devs might not include some dependencies because of licenses without notice. I think GP had the latter case.


Lutris is a popular Wine prefix manager. There is also PlayOnLinux.

> Will WINE ever be at a point where it would be stable enough to make the case for non-technical users?

On Linux - yes, on macOS - not likely, given the waning interest of Wine developers in doing it for macOS, thanks to Apple's sabotage of OpenGL, Vulkan and 32-bit support there.


If you are willing to fork some money, you can try crossover, these people contribute to wine project.


Buy Crossover - it employs a pile of the WINE developers, and their changes are fed back into the main codebase.


> Will WINE ever be at a point where it would be stable enough to make the case for non-technical users?

IMO for everyday use it pretty much already is.

Example: I installed MS Office 2010 using the official MS office installer, in a specially isolated Wine environment using a somewhat cumbersome command-line. This is expert-stuff, I agree, but what follows is not.

After the installer had completed Wine had picked up the application installations inside Windows and made them available (through wine) in my regular Linux application launcher with nice icons and everything.

I didn't lift a finger, and now I could use MS Word like any native Linux app anywhere in Gnome, even associate it with DOCX-files in Nautilus.

Call me easily impressed, but I found that above and beyond what I expected wine to do for me.


I wrote an app to do this on Mac several years ago, then abandoned it for lack of users. Crossover from CodeWeavers is a great GUI wrapper, but it's not free.


PlayOnMac is fairly user-friendly, relatively speaking. You do still have to interact with winetricks via a GUI, but I've been able to achieve everything I've wanted without ever using a CLI. Worth trying if you haven't, it's quite a lot smoother of an experience than Wineskin Winery.


Sure, there's Lutris or Steam's Proton to help with that. I wanted to try out Magic the Gathering Arena a few weeks ago. All I had to do was install Lutris, and that automatically set up Wine configs, installed dependencies, and even downloaded and installed the game.


I've found WineBottler on Mac to be fairly easy to use... you use it to install your program then it creates a standalone Mac executable which runs it in future


I guess it involves some freedesktop.org stuff so I'm not sure what happens in Mac OS, but when I install games with WINE I get a XDG menu item on my DE.


On macOS you install Wine then Wine runs all .exe files. Is that hard? If .exe files aren't associated with Wine then you can do that yourself from Get Info panel.

In Finder you can use Go to Folder. Just type ~/.wine/drive_c and add Program Files to the sidebar.


Find how your favorite apps do - link to Wine application support db: https://appdb.winehq.org/objectManager.php?sClass=applicatio...

I'd like to really Thank Wine developers! Because of your efforts pretty much only time I need to use Windows desktop is when I need Adobe Lightroom CC and Premere Pro and it looks like v4 is improving on that as well.


I remember first trying Wine - I actually installed (well, compiled) XFree86 just to try it - I was proper cli-only in those days. After a long weekend of compiling, I was finally able to run a very slow instance of mIRC - for less than a minute, then it crashed. I was amazed.

2 decades later, my Wife + kids are now able to enjoy The Sims 4 and SimCity on their Linux machines, thanks to the hard work of the Wine team!

And with the additional work of Crossover, Word & Excel too.

These four non-trivial applications, built without any portability in mind, work flawlessly.


I think Wine and Samba played a pivotal role in Linux adoption to those who are in someway tied to Windows land.

Of all the memories with Wine, the best one is still how Red Alert 2 worked flawlessly.


Some major games seems to not be working because of the anti-cheat system: https://bugs.winehq.org/show_bug.cgi?id=41670 (PUBG, Fortnite, etc.)


Some of the anti-cheat hindered games started working recently with Steam's Proton 3.16 beta build.


That stinks. Considering how well Fortnite is doing, I am a bit surprised that they haven't made a Linux version.

IDK how much it would cost to make a Linux version, but I would think the amount of money from microtransactions they would be getting would make up for it


It must have to do with the lack of profitability, especially after developing an anti-cheat solution.

I'm not 100% certain if EasyAntiCheat supports Wine at all, or even Linux at all, but that's what they (Epic Games) use. If not, they'd have to write an in-house solution that probably won't work.

In the past (again, I'm not sure about the present), CS:GO was victim to having a Linux client; rather, people figured out that it was much more vulnerable to exploits due to it not having a working anti-cheat solution.


> I'm not 100% certain if EasyAntiCheat supports Wine at all, or even Linux at all, but that's what they (Epic Games) use.

It does. EAC detects Wine, and can load a Wine version if the developers enable it. There have also been a few cases where they enabled it upon player requests (without dev involvement).


EasyAntiCheat and BattlEye rely on kernel drivers, which WINE has no support for.


One of the leads of fortnite has made a disappointing anti linux tweet recently in my memory.


Fortnite is mostly a kids game, who tend to not be running Linux (yet!).


My son plays Fortnite, and would love to play on a PC. My old MacBook Air doesn't support the game, and our next home laptop with be a Linux machine.

Not being able to play Fortnite on Linux is probably my son's current, great disappointment. :-P


Get him a Switch. Has Fortnite and other great games like Splatoon 2. Then he can take it around, put in on the TV, etc.


Switch being mobile is probably why I haven't bought it; we have WiiU, Wii, Gamecube, N64, but my kids if allowed would eschew being sociable in favour of playing Switch everywhere.

We could get it and not let them take it anywhere, but we moved to Steam on Linux pretty much.


That's when you use the Nintendo Switch Parental Controls app, with its charming video to introduce it. https://www.youtube.com/watch?v=03bAayBtcb0

Plus, it's nice to play in the lounge with all the family. I'm glad to hear you have the previous consoles and can do so!


Wine has progressed quite a lot in the last year. Paired with dxvk especially, many quite demanding Windows games became completely playable on Linux.

The next big missing thing now is Wayland support (though it already works through XWayland).


It didn’t have game controller support before? I’m surprised and seem to recall game controllers working before.


It had the support, from /dev/input/js? or /dev/input/event?. Now it also supports leveraging libsdl's joystick support.


Wait - Wine is available on Android? I use Wine for a few things - would be great to have those apps on my Android device!


Wine Is Not an Emulator - but to run x86 Windows applications on an ARM Android device with Wine you will need to use emulation.

Wine is essentially just a userspace implementation of the Windows API. Outside of API functions & syscalls, the actual instructions of the application are still running on bare metal.


It's available on Android but still pretty broken. You can CD to your SD Card but not list the directory content. You can run executables but dependencies are an issue if you don't know which ones you need to have installed in advance. I bought an x86 Android Notebook/Tablet with the purpose of hoping to be able to run some old Win32 games within Wine on Android and nothing worked.

As one of my buddies said about a laptop I had issues with getting hardware recognized correctly in Linux: Put it in the drawer for 6 months and hope it's fixed by then.


Last time I checked it worked for Android on x86, since wine is not an emulator. I do recall there being some experiments with wine running on arm via. A x86 emulator.


There's ExaGear, which is basically Wine with an x86-to-ARM translation layer running underneath. Note that the app is quite pricey at $30.

https://play.google.com/store/apps/details?id=com.eltechs.ed


I'm Debian user and I usually install the packages, and the shipped version of the software is just fine for me.

Occasionally I may want to use the newest version of a particular application and I've found that instead of installing dependencies and compiling myself the Linux version, it is way easier to download the Windows binaries and run them with WINE. In some cases, it even works better! (e.g. full screen support)


Back in the day, I dreamt of being able to run Cubase on Wine, and not have to deal with Windows at all, but I remember being told (this was maybe 2002?) by someone who claimed to have the inside line that there was the possibility that Cubase would run on Linux 'soon', natively.

That became less of an issue when Windows 7 came along as it worked so well, but now I know the next hardware revision of my studio PC will probably need to run Windows 10 (which I detest using), I'm looking misty-eyed at it again. But I know that Cubase is immensely demanding, and no doubt uses lots of odd Windows APIs that Wine doesn't cover (or cover fully), so that's just a pipe dream which gets awoken every time I see a new release of Wine come along and I somewhat foolishly check the app database only to find the last versions to test were years ago and were 'garbage'!


Have you tried Ardour? I'm definitely just an amateur, but it has worked fine for my needs (coming from Cubase LE).


I'm sure you have your reasons (no pun intended) but given all you've said here I'm curious as to why your studio PC isn't a Mac? I've done a bit of recording with bands and have never come across anyone running a recording studio on Windows.

FWIW I'm a Linux user too and as a musician I would love Steinberg et al to pull their fingers out so I can have a dabble in that world. We can but dream.


Am I the only one testing software libraries cross-compiled to windows on wine? I do use Appveyor native, but for debugging tricky issues I rather use wine on Linux or macOS, than spinning up a Windows VM and try to debug it there. I just have to maintain seperate win32 and win64 registries and ENV vars.


I'm very curious of your setup. Do you use wine to cross-compile your windows binaries?


No, just to test the mingw compiled libraries. The old tea.org CI was doing it similar.

setups: https://github.com/LibreDWG/libredwg/blob/master/build-aux/s... https://github.com/rurban/safeclib/blob/master/build-tools/s...


Why is this not working even though the new binaries are already available at https://dl.winehq.org/wine-builds/ubuntu/dists/cosmic/?

``` $ sudo apt update $ apt-cache policy winehq-stable winehq-stable: Installed: (none) Candidate: 3.0.4~cosmic Version table: 3.0.4~cosmic 500 500 https://dl.winehq.org/wine-builds/ubuntu cosmic/main amd64 Packages ```


Anyone using Wine to run Adobe softwares (Photoshop, PPro, AEfx...)?


Photoshop works great with it. I used it for years before switching to Gimp.


So you only experienced the old Photoshop under Wine. I hear the latest Photoshop CC doesn't work well under Wine.


No I used CC. Maybe not the latest CC since it's always updating but in like 2017 I was using CC on Linux.


Oh I heard that was specifically one of the big steps forward in was it Wine 3.

Keen to know if anyone’s experiences with Adobe CC products.


Did you check the db at WINEhq.com, IIRC it used to work really well but is problematic now.


Many.


I'm looking forward to getting 3d acceleration in ChromeOS this year so I can try stuff like this (albeit without audio for now).


I was pretty happy when I found out Lead Pursuit Falcon 4.0 Allied Force works perfectly on wine


Is there any way to run Wine on 64-bit MacOS? Wine seems to be stuck on 32-bit.



When I ran 'port install wine,' I got the "error wine cannot be installed for the configured build_arch 'x86_64' because it only supports the arch(s) 'i386'."


I guess whatever is your source, they didn't build 64-bit one. So you can ask those who maintains that repo.

It clearly should be buildable for 64-bit.

See:

https://wiki.winehq.org/MacOS

https://dl.winehq.org/wine-builds/macosx/download.html


Their installer says "64 bit support (optional)". It's not selected by default.


I'm no MacPorts guru, but it looks to me like the package doesn't support building the mixed-arch version (which is a practical requirement for 64-bit Wine, although it's technically possible to build a pure 64-bit version) on newer versions of MacOS (I'm not sure what marketing version "18" corresponds to). Maybe this is related to 32-bit support being deprecated in Mojave?

    if {${build_arch} eq "x86_64" && ${os.major} < 18} {
        default_variants            +universal
    }

    if {[variant_isset universal]} {
        supported_archs         i386 x86_64
    } else {
        supported_archs         i386
    }


try `brew install wine`

https://formulae.brew.sh/formula/wine


Fantastic !

At this point, there is very little reason for federal, state and local government to be saddled with millions in license costs


The "game support" they're talking about is not what you're probably thinking of - Wine has been able to run Solitaire and Minesweeper for quite a while already.


True. I admit. I was just looking for an an inroad, thanks for calling me out :)


A decade ago one major local government agency did in fact move away from Windows in the hope of avoiding those costly license fees.

They found out it can also be quite costly to run Linux as an alternative:

https://www.techrepublic.com/article/ditching-windows-for-li...


Let's be more specific.

Microsoft didn't like the fact that Munich switched to Linux, so they moved their headquarters to Munich to gain political clout, ushered in a more favorable mayor, and then hired Accenture to release a report claiming that Windows would be more cost-effective.

It worked.

https://www.techrepublic.com/article/linux-in-munich-no-comp...


Most likely there were just bribed by one unnamed company, or promised some investments - the time correlates with expanding their office in Munich. So I would not trust Munich's claims at all. Despite recent whitewashing of Microsoft image they were never practicing a fair business.


If you read some more about the issue, it becomes clear that after an election, the conservative party with long-term ties to Microsoft was happy to reverse the decision.


But they said their problem was that they also needed Windows machines to run line-of-business apps and that it wasn't cost effective, something that Wine is supposed to help with (running Windows apps in Linux).


Turns out, using something other than Windows doesn't equate to using something that requires no support. And support is not free.


Irrespective of what system is in place there will always be support/training/running costs associated with managing a big IT system.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: